<div dir="ltr">Integration is definitely doable. The problem is that the previous scancode_decode.js (the one we currently use) was very incomplete and could not interpret the characters that inform about errors. In order to detect the errors the new scancode_decode.js must be used (from the commit I previously mentioned) but using that scancode_decode means breaking compatibility. The solution is to use the improved scancode_decode first and if there are no errors but none of the hashes in the database matched then retry with the old scancode_decode.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 29, 2017 at 5:00 PM, Jake <span dir="ltr"><<a href="mailto:jake@spaz.org" target="_blank">jake@spaz.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">i definitely do not want to break compatibility with existing codes.<br>
<br>
if the commit below can distinguish error codes, it should be integrated with<br>
the present code purely to prevent error codes from being passed along as valid<br>
card reads, is there any reason that can't be done?<br>
<br>
does anyone here want to try?<div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, 29 Nov 2017, Marc Juul wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you look at this commit:<br>
<br>
<br>
<a href="https://github.com/sudoroom/doorjam/tree/208acdc836af3d50baade168366f920f455c5b42" rel="noreferrer" target="_blank">https://github.com/sudoroom/do<wbr>orjam/tree/208acdc836af3d50baa<wbr>de168366f920f455c5b42</a><br>
<br>
I actually fixed this problem but unfortunately the fix broke compatibility<br>
with existing hashes so we never switched over. What is needed is to<br>
integrate the old hashing code with this new code so we're backwards<br>
compatible. The magic code that ignores errors properly is the `magParse`<br>
function in this file:<br>
<br>
<a href="https://github.com/sudoroom/doorjam/blob/208acdc836af3d50baade168366f920f455c5b42/bin/doorjam.js" rel="noreferrer" target="_blank">https://github.com/sudoroom/do<wbr>orjam/blob/208acdc836af3d50baa<wbr>de168366f920f455c5b42/bin/<wbr>doorjam.js</a><br>
<br>
On Wed, Nov 29, 2017 at 4:46 PM, Jake <<a href="mailto:jake@spaz.org" target="_blank">jake@spaz.org</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it's still the case that error codes reported by the magnetic stripe<br>
reader are<br>
being used as peoples' card hashes.  this means that a random person<br>
swiping a<br>
random card can get access to omni if the error code matches that hash.<br>
<br>
since the data from the card reader is scrambled and randomized, there's no<br>
easy way to discern "ERROR - CARD NOT READ" or whatever it's trying to say<br>
from<br>
")!#@@@449492837203804720_05/2<wbr>0_" or whatever a normal card would be<br>
reporting.<br>
<br>
substack and i tried to fix this a while ago by counting the number of<br>
bytes<br>
coming from the reader but it wasn't enough.  so blah, now everybody here<br>
knows<br>
and so if you care to look into it we can do that.<br>
<br>
-jake<br>
______________________________<wbr>_________________<br>
access mailing list<br>
<a href="mailto:access@lists.sudoroom.org" target="_blank">access@lists.sudoroom.org</a><br>
<a href="https://sudoroom.org/lists/listinfo/access" rel="noreferrer" target="_blank">https://sudoroom.org/lists/lis<wbr>tinfo/access</a><br>
<br>
</blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br></div>