Proxmark3 community

dgood71

Contributor

Registered: 2020-11-05

Posts: 6

[solved] Old 34 bit HID prox card not able to be sucessfully cloned

I have an extremely old (at least 21 years old) HID Proximity card that's labeled Northern Computers Proximity on one side and has the HID logo and "HID Corporation" on the other side. This original card works fine in all HID readers I've tried it on.

I've attempted to clone this card in various ways to a T5577 fob but the cloned fob does not work.  I've successfully cloned other newer HID Prox cards and those clones work fine, but this Northern card seems to be different in some way and I cannot make a working clone of it.

lf search shows the following on the original card:

[=] Checking for known tags...
[=]
[+] [N10002] - HID N10002 34-bit;  FC: 193  CN: 45193
[+] [Optus34] - Indala Optus 34-bit;  FC: 137  CN: 193
[+] [Smartpass] - Cardkey Smartpass 34-bit;  FC: 24  CN: 45193  Issue 1

[usb] pm3 --> data print x
[+] DemodBuffer: 1D5559655556955A6956565A

And on my non-working clone, here's what I see:
[=] Checking for known tags...
[=]
[+] [N10002] - HID N10002 34-bit;  FC: 193  CN: 45193
[+] [Optus34] - Indala Optus 34-bit;  FC: 137  CN: 193
[+] [Smartpass] - Cardkey Smartpass 34-bit;  FC: 24  CN: 45193  Issue 1

[usb] pm3 --> data print x
[+] DemodBuffer: 1D5559655556955A69565659

You'll notice that everything appears to be identical except the very last digit in the demod buffer -- the original is an A and the clone is a 9.

I suspect that this might be part of my problem, but I'm not 100% sure as this is all pretty new to me and I'm trying to learn.  I tried cloning into a different format (-w H10301) thinking that might work, and here's how that goes:
=] Checking for known tags...
[=]
[+] [H10301] - HID H10301 26-bit;  FC: 193  CN: 45193    parity: valid
[usb] pm3 --> data print x
[+] DemodBuffer: 1D5559555566955A69565659

Again, the last hex character is a 9 instead of an A like the original card.  Same result if I try to write in the Optus34 format.

So, 2 questions.  1)  Am I correct in assuming that the 9 instead of an A as the last character in the data is probably the reason why my clone doesn't work?

2) If my assumption is correct, is there a way I can get the data 1D5559655556955A6956565A written into the T5577 chip so it would read identically to the original card? 

If this is really obvious to everyone but me I apologize, I'm trying to learn the PM3 commands and I haven't yet found a way to make the PM3 do what I think I need it to do.

thanks for any help you can give!

PS, just in case it helps, here's my PM3 RDV2 version info, you'll see I'm on a very recent Iceman build:
[ CLIENT ]
  client: RRG/Iceman/master/v4.9237-1961-gf63cf021-dirty...-unclean 2020-11-06 22:55:51
  compiled with GCC 10.2.0 OS:Linux ARCH:x86_64

[ PROXMARK3 ]
  firmware.................. PM3OTHER

[ ARM ]
  bootrom: RRG/Iceman/master/v4.9237-1961-gf63cf021-dirty...-unclean 2020-11-06 22:56:32
       os: RRG/Iceman/master/v4.9237-1961-gf63cf021-dirty...-unclean 2020-11-06 22:56:51
  compiled with GCC 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

[ FPGA ]
  LF image built for 2s30vq100 on 2020-07-08 at 23: 8: 7
  HF image built for 2s30vq100 on 2020-07-08 at 23: 8:19
  HF FeliCa image built for 2s30vq100 on 2020-07-08 at 23: 8:30

Last edited by dgood71 (2020-11-15 00:59:14)

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: [solved] Old 34 bit HID prox card not able to be sucessfully cloned

1. yes,    there seems to be a bug in the wiegand decoding part, where it have to detect the sentinel bit vs length of data.
2. just write that raw data to your tag using the t55xx commands instead.

dgood71

Contributor

Registered: 2020-11-05

Posts: 6

Re: [solved] Old 34 bit HID prox card not able to be sucessfully cloned

OK, after a little more research, I've figured out the commands to fix the issue by writing directly to the T55 chip as Iceman suggested.  Thank you for that guidance, Iceman! 

For others like me who might be scratching their heads, NO, don't use the  dangerraw command.  Use LF T55 write.

In my case, I had to write 2 blocks of data since the code in my T5577 was already *mostly* correct.  I was able to write blocks 2 and 3 to fix my specific problem.   But if I did have to write all the blocks, here are the 4 commands I would have used:

lf t55 write b 0 d 00107060
lf t55 write b 1 d 1D555965
lf t55 write b 2 d 5556955A
lf t55 write b 3 d 6956565A

Blocks 1-3 contain the hex string that I needed to write.  So now when I do a lf search and then data print x on the clone I get the same hex string as the original card has.  Problem solved. 

I don't know whether there's a formal way to report the bug in the weigand decoding that Iceman mentioned, but I suspect that since he's aware of it it's already on "the list".  If there is an official way to report bugs I'm happy to do it if that needs to be done.  I'm also not sure whether to put [solved] in the title as *my* specific issue is resolved but the underlying code bug isn't.  Guidance on that from a mod, please?  I'm not sure what the protocol is.

Thanks!

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: [solved] Old 34 bit HID prox card not able to be sucessfully cloned

You use the issues on  Github repo to report stuff.
And I may I suggest you edit your first post and add the prefix  "[solved]" to your title.