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.
On Wed, Nov 29, 2017 at 5:00 PM, Jake <jake(a)spaz.org> wrote:
i definitely do not want to break compatibility with
if the commit below can distinguish error codes, it should be integrated
the present code purely to prevent error codes from being passed along as
card reads, is there any reason that can't be done?
does anyone here want to try?
On Wed, 29 Nov 2017, Marc Juul wrote:
If you look at this commit:
> I actually fixed this problem but unfortunately the fix broke
> with existing hashes so we never switched over. What is needed is to
> integrate the old hashing code with this new code so we're backwards
> compatible. The magic code that ignores errors properly is the `magParse`
> function in this file:
> On Wed, Nov 29, 2017 at 4:46 PM, Jake <jake(a)spaz.org> wrote:
> it's still the case that error codes reported by the magnetic stripe
>> reader are
>> being used as peoples' card hashes. this means that a random person
>> swiping a
>> random card can get access to omni if the error code matches that hash.
>> since the data from the card reader is scrambled and randomized, there's
>> easy way to discern "ERROR - CARD NOT READ" or whatever it's trying
>> ")!#@@@449492837203804720_05/20_" or whatever a normal card would be
>> substack and i tried to fix this a while ago by counting the number of
>> coming from the reader but it wasn't enough. so blah, now everybody here
>> and so if you care to look into it we can do that.
>> access mailing list