Different readers return different value

[iBobik]

I tried to read tags with different readers, but it seems like decoding is reader-specific.

This two values are the same tag, but different reader:
7384CF
8C7B30

For both readers it prints W26 reader type.

Is there some way how to recalculate it, so I can use different readers in one access system?

[jpliew]

Hi @iBobik ,
Please provide a screen capture from an oscilloscope for D0 and D1 for both readers. The screen should look like this.

An example of data captured, 10000100100111011100000110, after removing the leading and trailing parity, the data is 000010010011101110000011, and equals to 0x93B83.

From the image, I can then see how many 0 and how many 1 and compare with the two readers.

Some readers have different specifications, even though they send data in wiegand, but the way the data is organised might be different.

Hope this helps.

[jpliew]

@iBobik do you still need help? If not I will close this issue.

[iBobik]

I postponed it on my side, but thank you for help. I will use it but do not know when.

…

19. 7. 2019 v 10:05, JP Liew ***@***.***>: @iBobik <https://github.com/iBobik> do you still need help? If not I will close this issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#36?email_source=notifications&email_token=AAEV6WADUOXPEMM3FXRWGBLQAFYVXA5CNFSM4HPZZ2JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2K5GCQ#issuecomment-513135370>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEV6WG74SMLJNIDRQ3JPADQAFYVXANCNFSM4HPZZ2JA>.

[JohnMcLear]

I can replicate this bug.

1. Plug in a reader, scan Mifare enabled card that has secure element (IE Mifare enabled P5/6//SLE77/78)
2. Get ID
3. Unplug Wiegand reader ~~~~ Don't restart usage logic or reload module / library etc.
4. Plug in different Wiegand reader
5. Scan same card. You will notice a different ID.

First scan will be Mifare ID (4 bytes)

Second scan will be non-Mifare ID (one assumes ~NTAG ID) which is longer in length (Documented as 7 but displays as 5).

To add to this, this library completely fails to scan UID or a non-Mifare enabled tag. While this is probably a separate issue it is something that needs documenting clearly in the README to ensure users who have non Mifare enabled Secure Element based cards (IE P5,6,77,78 -- which make up a huge amount of cards in circulation) are supported.

The correct patch fix here is to query the SEID through an applet for a usable UID. The correct long term fix is to bring in support for additional cryptographicly signed methods for getting a UID IE something that returns UID (from SEID) after 3Des handshake. This may be out of scope for this library though as IMHO this library has a primary use case of just returning UID and supporting any logic provided by third party smart card applets may be on a per applet basis.

So to summarize:

1. This library fails to consistently gather the correct UID of any Mifare enabled tag should the Wiegand connected device be changed (I didn't check power drops or reconnecting same device).
2. This library fails to gather the correct UID of some cards in circulation at current (namely smart cards without Mifare support)

Thanks to the author for his work so far and ongoing, I hope we can prioritise these fixes because IMHO they are quite critical to a lot of use cases currently consuming this library.

@jpliew If you want a proxmark dump I can probably get one but it might take me a month or so, it's likely you can replicate this bug much quicker by following the above steps <3

[jpliew]

Hey @JohnMcLear,

Thanks for your comment.

I am actually a bit confused here.

This library only reads wiegand data, it is not aware of what card being scanned. The card reader reads the card, process the ID and then send the value out as wiegand pulses.

It is the responsibility of the card reader to negotiate the RF part of the protocol with the card being scanned.

Hope this clears up the confusion.

Cheers
JP

[JohnMcLear]

I commented here but including copy/paste here.

#40

@jpliew Oh. So the wiegand device is the limitation, very interesting and this would explain why certain readers read different values from the same card. Wow, what a fucked up situation to be in!

So TLDR; if you use Wiegand, you can't be consistent w/ UIDs if you use different makes/models of readers because the Wiegand logic implemented changes between devices (Despite being a standardized protocol [citation needed]).

This has to be flagged as "wont fix" because you can't fix. Basically the only fix here is for whoever consumes this software to ensure that the same exact make/model/software version of the Wiegand device is used upon replacing a reader, anything else might return a different value :(

The crux of the problem is due to Wiegand protocol being ?improperly? implemented on the reader

[iBobik]

Is it theoritecally possible to investigate reader’s encoding algorithm from returned values of known card? Then we can implement converting of UIDs, so we can use different readers in one system without maintaining multiple UIDs for one user for each type of reader.

[jpliew]

Before we go nuts over the this, it is better to checkout the specification of the card readers. As far I as know, there are card readers that will be able to be reconfigured for different types of data.

In this industry, the card readers (mostly high end type) has to be reprogrammed to suit the different systems use to ensure consistency.

[JohnMcLear]

Yeah I imagine that's the problem. I'm using super sketchy / budget readers.

…

________________________________ From: JP Liew <[email protected]> Sent: Tuesday, August 27, 2019 00:19 To: monkeyboard/Wiegand-Protocol-Library-for-Arduino Cc: John McLear; Mention Subject: Re: [monkeyboard/Wiegand-Protocol-Library-for-Arduino] Different readers return different value (#36) Before we go nuts over the this, it is better to checkout the specification of the card readers. As far I as know, there are card readers that will be able to be reconfigured for different types of data. In this industry, the card readers (mostly high end type) has to be reprogrammed to suit the different systems use to ensure consistency. - You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#36?email_source=notifications&email_token=AABV5QEZQ3LLBWAUVBHTZ5DQGRQJFA5CNFSM4HPZZ2JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5F65MQ#issuecomment-525070002>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AABV5QCWFJKANM6STBUJXCTQGRQJFANCNFSM4HPZZ2JA>.

[jpliew]

@iBobik I double check your data again and I can confirm that when you switched over the reader, the D0 and D1 are swapped.

7384CF
8C7B30

these values are NOT of each other, see binary data below

011100111000010011001111
100011000111101100110000

So your two readers producing the same data.

[iBobik]

Wow, I feel so stupid now. :-) Thank you a lot Jan Pobořil https://honza.poboril.cz/ 9. 9. 2019 v 0:26, JP Liew <[email protected]>:

…

@iBobik I double check your data again and I can confirm that when you switched over the reader, the D0 and D1 are swapped. 7384CF 8C7B30 these values are NOT or each other, see binary data below 011100111000010011001111 100011000111101100110000 So your two readers producing the same data. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.