Proxmark3 community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.


"Learn the tools of the trade the hard way." +Fravia

You are not logged in.

Announcement

Time changes and with it the technology
Proxmark3 @ discord

Users of this forum, please be aware that information stored on this site is not private.

#1 2016-04-01 17:24:03

ntk
Contributor
Registered: 2015-05-24
Posts: 701

[resolved] 50 bits AWID RBH format and raw binary data mapping....

reading the thread http://www.proxmark.org/forum/viewtopic.php?id=2203 I understand the tag upgrade has is a "
If this is 50 bit AWID RBH format, then the FC would be 4000 and the ID would be 2229977." like HKplus has said. Through the conversation between Marshmellow and HKplus I understand 50bit is an overgrown 26 bit wiegand frmt, with 16 bits for FC, 32 bits for CN; bit0 is EP and the last bit is OP. So that makes a 50 bit wiegand sequence, which then will be Manchester coded (1 to 10 and 0 to 01 to build the final raw binary data blocks.

Also with PM3 we can extract for this tag:
AWID Found - BitLength: 50 -unknown BitLength- (1753) - Wiegand: 1f4000440db2, R
aw: 128817e4111121817772111

and if you manually clone to T55x7 not by a direct command you would need
Block 0 0x00107060
Block 1 0x0128817e
Block 2 0x41111218
Block 3 0x17772111

That is the status from 2014. Nowadays we maybe have already the command for direct cloning AWID to T55x7.

BUT could someone explain how the binary raw coding could happen here. I tried to retracing the calculation, and fail
to get even block 0 configuration unchanged\intact, because of the length 50bit sequence wiegand frmt, after Manchester coded it become 100bits.

Each block we count with bit 0 and have 32 bit for raw binary data, so if I fill and perform the "Manchester" coding for the 50 bits sequence,  result would appear as follow:
block3 fully filled 32 bits used
block2 fully filled so 64 bits used
block1 fully filled so 96 bits used, but I still have 4 bits more on my hand

AND, so I must borrow the last 4 bits from block zero to completete the raw coding to binary. Or is it wrong? In the case my block zero is hard to stay 001007060, but change to 001007069, due to changing in the last four bits.

I could attach the excel sheet for mapping raw data for FC =4000 and CN=2229977. but you dont need to go to details, just fundamentally only from the bit length 32 bits for each blocks, and the length of the AWID sequence (50 bits) could you explain how block zero can stay 00107060, or where I misunderstood the concept.

Thanks

Last edited by ntk (2016-04-28 01:46:14)

Offline

#2 2016-04-28 01:58:10

ntk
Contributor
Registered: 2015-05-24
Posts: 701

Re: [resolved] 50 bits AWID RBH format and raw binary data mapping....

Although it is Wiegand format, using FC and CN (and tag format ID), It is AWID: The mapping follow different rule. It is basically similare to AWID_FSK 26-bit, but with 16bit FC, 32bit CN, one EP and OP, make 50bit AWID

There is no Manchester coding in AWID, hence no doubling of bits and there is no intruding of bits into block 0. I was mistaken.

Offline

Board footer

Powered by FluxBB