uidCRC

mosci · 2016-02-10 22:45:25

the 8-bit uidCRC (address 0x04 on every MIM-Tag - aka legic prime) ...
who can (help me to) reverse-engineer those credentials?
I can provide a lot of uid/crc pairs, but I'm not able to reverse-engineer the credentials on my own (for now - but I'm working on it)
even reveng didn't helped me out here
might be that the byte-order isn't 0,1,2,3 it's possible that the crc gets calculated in a different order like 0,3,2,1

the below UIDs are in byte-order 0,1,2,3

   UID   | CRC
3ea284e2   c0
3e5183e2   5f
3eba85e2   44
3eed85e2   9b
3e9585e2   c2
3ef385e2   9c
3ece84e2   45
3e1787e2   64
3e9783e2   ab
3e3984e2   30
3e5385e2   36
3e7c85e2   b0
3eab86e2   e5
3e4b84e2   b2
3e7a82e2   67
3e4786e2   42
3e0e86e2   9a
3e8385e2   23
3e9e87e2   da
3e6c84e2   d2
3e7983e2   31
3e9384e2   41
3e1784e2   cc
3e2e85e2   ba
3e6284e2   a6

Last edited by mosci (2016-02-12 18:24:29)

iceman · 2016-02-11 07:30:40

Is it mentioned somewhere in the documents how the UID-crc is calced?

mosci · 2016-02-11 08:09:15

no, unfortunately not - it is just mentioned that it can be 'easily' reverse-engineered (1bit-wise)
the sm-4500 (legic-chip) calculates that crc (in the official/confidential legic-reference are two functions regarding crc mentioned: 'make_crc and check_crc) - but therefore I need a valid Master-Token, which can not be created without a valid CRC.
uidCRC and MT-Segment-CRC are calculated with the same credentials

Last edited by mosci (2016-02-11 08:24:57)

mosci · 2016-02-11 08:19:22

any 'cloned' tag get's not accepted from the sm-4500 (my valid tag get fully accepted and I can fire all (read) cmd's against it without errors) so, I guess the segmentCRC can also not be simply copied which only makes sense to me if it gets calculated over the obfuscated content - otherwise a clone should have a valid segmentCRC as well - but it has not because of the different uidCRC?!? (I guess)
the pm3 didn't check that CRC - it just deobfuscate it on a decode

Last edited by mosci (2016-02-11 08:21:40)

mosci · 2016-02-11 08:34:06

the deobfusecated content of both segment00 (on my valid tag and on the clone) are totally identical.
both tags behave identical on read commands until the segment00 gets selected (on a official reader).
so, from my point of view the segmentCRC must be recalculated on a clone.

Last edited by mosci (2016-02-11 08:47:47)

mosci · 2016-02-11 12:40:24

so, theory confirmed ... since it is only a 8-bit crc, I started at 0x00 and increased the crc bit by bit until the
legic-reader founds a valid segment 00 (at 0xd6 ) ... so, I wonder if that tag will open the door tomorrow
but that crc-credentials have to be reverse-engineered anyway

iceman · 2016-02-11 17:39:01

In this paper, they mention the following about UID crc, they call it storage CRC

ref: Peeling Away Layers of an RFID Security System

 By looking for these two properties
in our tables we found the transport CRC polynomial to be 0xc and the
storage CRC polynomial to be 0x63 (but with a reversed shift direction)

mosci · 2016-02-11 18:13:24

maybe 0x63 is the right poly ... and the storageCRC is likely the uidCRC - but unfortunately that's not all ...
the init-value & the final-xor-value also needed .. and will it be reversed or not ... big-endian or little-endian ...
thera are so many combinations possible
... I have tried several combinations of all values that I found so far also shifted 0x63 in both direction
but nothing brings me to the wanted result ...
so try and error is not a good way - this should be reverse-engineering by a man who speaks fluent binary/crc ;-)

I will not give up until someone stops me (should be my wife)

Last edited by mosci (2016-02-11 23:31:06)

Proxmark3 community

Announcement

#1 2016-02-10 22:45:25

uidCRC

#2 2016-02-11 07:30:40

Re: uidCRC

#3 2016-02-11 08:09:15

Re: uidCRC

#4 2016-02-11 08:19:22

Re: uidCRC

#5 2016-02-11 08:34:06

Re: uidCRC

#6 2016-02-11 12:40:24

Re: uidCRC

#7 2016-02-11 17:39:01

Re: uidCRC

#8 2016-02-11 18:13:24

Re: uidCRC

Board footer