Proxmark3 community

ImSchatten360

Contributor

Registered: 2018-06-21

Posts: 12

Simulation of Legic Prime unsegmented user-credential tag

Hello,

I just recently started to analyse RFID tags. One of my current project is the simulation of some Legic Prime tags which are used for access control. I read the content of four tags by doing the following:

proxmark3> hf legic reader
#db# setting up legic card          
#db# MIM 256 card found, reading card ...          
#db# Card read, use 'hf legic decode' or          
#db# 'data hexsamples 256' to view results   

In all cases only the first 16 bytes seem to have any content (see below, some bytes are disguised). Everything else is 0 as far as I can tell. The first two tags and the last two tags look similar and the UIDs of each of those pairs are the same. Probably because they are from the same batches. Byte 13 and Byte 14 hold the ID of the tag that is written on it. So if the ID would be "1234" Byte 13 is "12" and Byte 14 is "34". In another thread it was stated that Byte 15 is the crc8 of Bytes 00-03 + Byte 07 + Bytes 08-14. However, I am not sure about how the perform the calculation in detail and therefore was not able to obtain the required value.

bytes
00 01 02 03 04 05 06 07
08 09 10 11 12 13 14 15

tag 1-1
ss xx xx tt a3 60 ea 09          
02 00 mn op 00 xx xx 13 

tag 1-2
ss xx xx tt 38 60 ea 09
02 00 mn op 00 xx xx 08

tag 2-1
uu xx xx vv b5 60 ea 09          
02 00 mn op 00 xx xx fe

tag 2-2
uu xx xx vv 05 60 ea 09
02 00 mn op 00 xx xx 71

I tried to simulate the tags but the reader did not respond to my attempts. I assume that the "hf legic sim" function is not working properly. In some posts "timing" issues are mentioned. Did anyone make any progress and did successfully simulate a legic prime tag or can give me any hints how to proceed?

Cheers

ImSchatten360

Last edited by ImSchatten360 (2018-10-01 20:58:20)

Jason

Contributor

Registered: 2016-07-21

Posts: 55

Re: Simulation of Legic Prime unsegmented user-credential tag

Simulation is not really working. You have to write your desired data to a new media.

The dump shows a standard KABA segment layout, called KGH (KABA Group Header). The CRC is normally calculated by the Legic reader itself while segment creation, but the algorithm is known (search the Proxmark Source, there you will find the Legic 8 bit CRC stuff).

The CRC calculation of the requested byte is done this way:

		buf[0] = UID1;
		buf[1] = UID2;
		buf[2] = UID3;
		buf[3] = UID4;
		buf[4] = WrpValue + StampSize;
		buf[5] = 0x00;                                   // Always zero
		buf[6] = WrcValue;                            // WRC, 4 as always on KABA segments
		buf[7] = RdFlag;                                // RD=1 -> 0x01 / RD=0 -> 0x00
                buf[8] = [... all other data bytes until CRC byte itself]

It is possible to use other CRC generation methodes, not even CRC16. The reader chip can generate CRCs by excluding some data, the WRC/WRP/RD stuff for example. The above methode is valid for KABA segments (and most other).

Edit: BTW the 2 bytes followed the 02-00 in stamp is the project code fo the specific project this cards are used in (and restricted to). With a little bit of effort someone can find out on which location they are used... less clever to just hide the card number itself...

Last edited by Jason (2018-07-26 14:34:16)