HID Prox - raw vs. UID vs. printed number on the card?

[XEMON]

Hello y’all,

Not sure if it’s the right spot for this … But here we go

I know it’s probably a trivial/dumb question, but what’s the correlation between the raw data, the UID, and the print d number on the card?

I tried to throw them in a hex converter and never got back anything matching…

PS: I can digg up an original HID card (that’s out of use/circulation) and post actual number.

Thanks for your help,
X

[amal]

The Ultimate Question of Bases, Binary, and Everything

It has come to my attention that the terms and formats used when talking about RFID IDs among other things needs some clarification. Well @amal… [giphy (12)] To try and keep this balanced between detail and “brain dumping everything into a single run-on sentence” I have split this into vaguely structured sections. Each section will start with an overview, a simple explanation, and then dive into more details. I have also linked some resources that will be much better than my drivel. Most o…

[XEMON]

Thanks for the wiki, it helps a lot and confirm some of the tings i noticed.

I did some digging and found this:
an0109_a.1_card_identification_markings_an.pdf (195.0 KB)

Here is where the fun begin …
(PS: I feel OK sharing this card as it it for a commercial access control for a company that doesnt exist anymore …)

Here is whats on the card"
On card:
HID iClass Px D9P
+393531 11101916132-1

So:

And here is the proxmark reading:
[usb] pm3 → lf search

[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags…
[=]
[+] [H10302 ] HID H10302 37-bit huge ID CN: 706609467 parity ( ok )
[+] [H10304 ] HID H10304 37-bit FC: 1347 CN: 393531 parity ( ok )
[+] [MDI37 ] PointGuard MDI 37-bit FC: 1 CN: 169738555 parity ( ok )
[=] found 3 matching formats
[+] DemodBuffer:
[+] 1D55565566655AA555596A69

[=] raw: 0000000000000010543c0276

[+] Valid HID Prox ID found!

[=] Couldn’t identify a chipset

[usb] pm3 → lf hid reader
[+] [H10302 ] HID H10302 37-bit huge ID CN: 706609467 parity ( ok )
[+] [H10304 ] HID H10304 37-bit FC: 1347 CN: 393531 parity ( ok )
[+] [MDI37 ] PointGuard MDI 37-bit FC: 1 CN: 169738555 parity ( ok )
[=] found 3 matching formats
[+] DemodBuffer:
[+] 1D55565566655AA555596A69

[=] raw: 0000000000000010543c0276

So:

That doesnt seam to help …

I did found the “card ID” in the read, but how does any of this corelate to the written code?

Ps: let me rephrase what I’m wondering
Is there a correlation between the card ID and the raw data?
Wondering if/how I could generate a card from a picture with the info printed on it.

[amal]

@XEMON

Is there a correlation between the card ID and the raw data?

yep there is… but to get there you have to deconstruct the hex data into binary and then pick your format.

• Raw data as one big binary; 0001000001010100001111000000001001110110
• H10302 is 37 bits 706609467 = 00101010000111100000000100111011

Notice that it’s 37 bits and not 32 or 40? That means 8 bit byte boundaries do not apply. The relevant data bits for a 37 bit ID in H10302 format are easily found in the raw binary;

• H10304 37 bit FC 1347 + CN 393531 = 010101000011 + 01100000000100111011

The FC is easily found…

The CN is tricky because the binary conversion from decimal puts a leading 0 and in binary, all leading 0s can be ignored… so now without the leading zero we can see it immediately follows the FC…

How and where to split these up is defined in HID documentation, but as you can see you could make several different demarcations of the same binary data based on different HID specifications to arrive at different FC and CN values. That’s why when exploring this stuff you will pretty much always need to break everything down to the binary level first, then build it back up in the shape of the data format you’re looking for.

@XEMON

Wondering if/how I could generate a card from a picture with the info printed on it.

Many cards print the full data on them or the FC and CN on them… but this card looks to obfuscate the FC data behind a sales order number… so an HID rep would need to look up that sales order printed on the card in their sales database to find the correct FC.

[kooswillem]

There is no guarantee that there is a relation with the printed number and the internal bits. However, making a lot of illogical jumps and really tring to find the number I have come up with this:
If you split 1110191632-1 into parts 11101 91632 1 and we convert 91632 into binary 1101 1111 1010 1010 0100 we can do this:

31-35 => 11101 for the first part
36 => 1 for the end

for 91632:
36-33 (going backwards) => 1101 (or using 31-35 again)
16-19 => 1111
07-10 => 1010
07-10 => 1010
27-30 => 0100

Now this will get you this number from the internal number but is highly unlikely to be the solution, to solve this we will need more examples at least three, at most ten.

Index:	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37
Bits:	1	0	0	0	0	0	1	0	1	0	1	0	0	0	0	1	1	1	1	0	0	0	0	0	0	0	0	1	0	0	1	1	1	0	1	1	0