• Andy
  • Member
  • Offline
  • Registered: 2009-11-11
  • Posts: 18

Topic: Mifare data analysis

Thanks to all in libnfc community I was able to read and analyze to some
extend Mifare classic 4K card used in public transport.

In my case:
Sector 0, Block 1&2 Mifare Application Directory (MAD)
http://www.nxp.com/acrobat_download2/ot … ad0107.pdf
Sector 1 (administration code 0x00 0x04) contains card holder information.
The recommented format for storing card holder information is Run-Lenght-Coding.
Sector 2 card publisher information (code 0x00, 0x15).
Sector 3 electronic purse, city traffic
These sectors don't change during card usage.
Sectors 4 and 5 - prepaid coupon, city traffic

I suspect that every administation code has a registered format.

Sector 4, Block 2 contains information about last travel.
Format type:
00 aa 00 bb 01 00 cc cc dd dd dd dd 00 ee 00 ff
aa = line number
bb = tram/trolley bus
cc cc  =  car number (dec)
dd dd dd dd = time and date
lower 14 bits = number of days since 01.01.1997
higher bits = number of minutes since the start of the day
ff = some sort of check sum

Is there a way to figure out what method is used to calculate check sum?

Sector 5 Block 0 and 1 Value blocks.

I would be happy if someone shared his observations. Regards
Andy

  • yosh
  • New member
  • Offline
  • Registered: 2010-05-10
  • Posts: 1

Re: Mifare data analysis

Have you done some more work on this? I'd like to know more smile

  • Andy
  • Member
  • Offline
  • Registered: 2009-11-11
  • Posts: 18

Re: Mifare data analysis

Yes, I have some progress.
Expiration date is written in block 0,sector 4. I cannot figure it out the format of the date.
Example:
41 00 00 44 00 00 10 1e 71 0a 00 00 00 00 00 00 (empty card)
41 00 00 44 00 41 10 1e 71 2a 3c 02 00 8f  f4 59 (14.07.2009-13.10.2009)
41 00 00 44 00 41 10 1e 71 2a 53 02 80 bc f4 59 (14.01.2010-13.04.2010)
So it seems that only the red bytes are significant.

I suppose that the next block 1,sector 4 verify content of block 0.
At the moment I'm collecting data and looking for patterns. I'd appreciate some help. Andy

Last edited by Andy (2010-06-13 15:13:41)

  • Andy
  • Member
  • Offline
  • Registered: 2009-11-11
  • Posts: 18

Re: Mifare data analysis

OK, I found out how to calculate the start and end date:
start date: byte9/0x20 + 1 + byte10*8 = days since 19.03.2008
end date: ((byte12 + (byte13 << 8))/0x40 + 1 = days since 19.03.2008

I need some help with next block that protects data integrity and its authenticity.
This document guides me to Message Authentication Code calculation.
Sector 4, block 2 format:
aa aa bb 00 00 00 00 00 00 00 cc 00 dd dd dd dd
aa aa - Line number
bb - 01=Trolley-bus/02=Tram/03=Bus/04=Subway/FF=All
cc - byte0 form sector 3, block 2
dd dd dd dd - ??? MAC

  • Andy
  • Member
  • Offline
  • Registered: 2009-11-11
  • Posts: 18

Re: Mifare data analysis

OK, some progress with checksums.
I found a C routine for MAD and NSCP Directories in NSCP_Mifare4k_Spec_V2.
CRC8-SAE J1850: polynom = 0x1D, Initial = 0xC7, Final Xor = 0
This function is used in Sector 4, block 2 (last trip) and whole sector 3 too.

Now the final challenge is to understand how the last 4 byte from sector 4, block 2 is calculated .
Standart CRCs-32 don't work.  If someone is interested in this just let me know. Regards, Andy

  • Registered: 2010-09-30
  • Posts: 1

Re: Mifare data analysis

Hey Andy,

Got any progress on the MAC? I came across a similar 4 bytes in Mifare card user for transportation, and I think they are some sort of MAC. Very similar to what you're describing.


However there are lot's of uncertainties:

- How much data is used to calculate the MAC: the whole sector or just the block?
- Does it use 3DES, DES or something else?
- How is the key used for encryption (assuming 3DES is used) derived from Key A or Key B (length differs)?
- What's the IV (0x00000000 or the UID, or else)?


Kung Lao

  • Andy
  • Member
  • Offline
  • Registered: 2009-11-11
  • Posts: 18

Re: Mifare data analysis

Hi Kung Lao,
yes, there are lots of uncertainties.
I can manipulate:
- sector 0: block 1 and block 2
- sector 1: all blocks
- sector 2: block 2
I can replace sector 2, block 0&1 (together) with the same blocks from another card.
I can't manipulate sector 3, althought I know checksum algoritm for this sector.
So in my case these 4 byte may protect data integrity and authenticity in:
- sector 0: block 0 (this block can't be changed but can be used for IV)
- whole sector 3
- sector 4: block 1 and block 2
Maybe someone will point us to some simpler algoritm.
I found this guide and try to brute force CRC16 and CRC32 again. It was easy with so called "difference message" but without success.

Last edited by Andy (2010-10-02 16:33:51)