HID Prox ID - Failed Parity

Support
1

Hi,

Recently got a PM3 easy and successfully cloned my work HID prox card to T5577 chip.

Interestingly, reading the source tag would give a parity error.

[=] Session log C:\ProxSpace\pm3/.proxmark3/logs/log_20240805161134.txt
[+] loaded `C:\ProxSpace\pm3/.proxmark3/preferences.json`
[+] Using UART port COM4
[+] Communicating with PM3 over USB-CDC

[ Proxmark3 RFID instrument ]

    MCU....... AT91SAM7S512 Rev A
    Memory.... 512 KB ( 64% used )

    Client.... Iceman/master/v4.18589-165-g9057371b2 2024-08-01 18:50:16
    Bootrom... Iceman/master/v4.18589-165-g9057371b2-suspect 2024-08-01 18:48:39
    OS........ Iceman/master/v4.18589-165-g9057371b2-suspect 2024-08-01 18:49:12
    Target.... PM3 GENERIC


[usb] pm3 --> lf search

[=] Note: False Positives ARE possible
[=]
[=] Checking for known tags...
[=]
[+] [H10306  ] HID H10306 34-bit                FC: xxxxx  CN: yyyyy  parity ( fail )
[+] [N10002  ] Honeywell/Northern N10002 34-bit FC: xxxxx  CN: yyyyy  parity ( fail )
[+] [Optus34 ] Indala Optus 34-bit              FC: xxxxx  CN: yyyyy
[+] [SMP34   ] Cardkey Smartpass 34-bit         FC: xxxx  CN yyyyy :  Issue: z
[+] [BQT34   ] BQT 34-bit                       FC: xxx  CN: yyyyy  parity ( fail )
[=] found 5 matching formats
[+] DemodBuffer:
[+] 00000000000000000000000

[=] raw: 000000000000001234567

[+] Valid HID Prox ID found!

[+] Chipset detection: EM4x05 / EM4x69
[?] Hint: try `lf em 4x05` commands
[usb] pm3 --> lf hid reader
[+] [H10306  ] HID H10306 34-bit                FC: xxxxx CN: yyyyy  parity ( fail )
[+] [N10002  ] Honeywell/Northern N10002 34-bit FC: xxxxx  CN: yyyyy  parity ( fail )
[+] [Optus34 ] Indala Optus 34-bit              FC: xxx  CN: yyyyy
[+] [SMP34   ] Cardkey Smartpass 34-bit         FC: xxxx  CN: yyyyyy  Issue: z
[+] [BQT34   ] BQT 34-bit                       FC: xxx  CN: yyyyy  parity ( fail )
[=] found 5 matching formats
[+] DemodBuffer:
[+] 000000000000000000000000

[=] raw: 000000000000001234567

Nontheless, I cloned the source tag with “lf hid clone -r” and “lf search” of the clone generated identical readout (with same parity failure) as the source. And the clone works flawlessly.

Happy with the result but want to learn more. How come the source tag has parity fail in a functional card? I also scanned another HID prox card from a co-worker and it showed the same parity failure.

Thanks a lot.

2 Likes
2

because parity is a format by format decision of how the bits are laid out and which bits are used for parity.

TLDR; it looks incorrect to the proxmark using the open 34bit H10306 but if they’re using a custom implementation, the parity is correct for them.

basically nothing you need to be worrying about

3 Likes
3

Thanks a lot @Equipter. That makes sense. It explains why a trial clone did not work when I specified H10306 as the format.

Just for my own learning. Out of the 5 matching formats that PM3 found, which one is the actual format that my company assess control adopts? Or is it possible the actual format is not even on the list because it is a custom implementation that does not match any existing known HID format?

I am almost certain my company uses HID system.

Thanks again for taking the time replying.

Cheers

2 Likes
4

what the proxmark shows are just the decoding options which is why it gives you multiple different potential chipsets, the data received can be correctly decoded into all of those formats.

as for the one that matches you system, without knowing all of the data i couldn’t say. if you know your internal card number, that should match up to one of the formats, or not. there isn’t particularly any reason the proxmark would have your custom implementation

2 Likes
5

Amazing. Thanks for your help. :pray:

1 Like