Need help figuring out Mifare classic format

[Lars Kvanum]

Hi.

I'm playing around with my building's access cards and want to clarify a few things that are unclear to me (I'm a rank beginner).

These are the contents of one of sectors 0 and 3 on my card:
Sector 0:
12e4c35e6b880400c185149551604911
00000000000000000000000000000000
00000000000000000000000000000000
ffffffffffffff078069ffffffffffff

Sector 3:
1826e4472b9160018e001984a0fb0000
0000000000ffffffcd00010000000000
00000000000000000000000000000000
xxxxxxxxxxxx7f078800xxxxxxxxxxxx

Now, for block 0 of sector 0, the 12e4c35e6b88 is the UID of the card, right? The next bytes, 0400c185, are the same for all my keyfobs and the 149551604911 part is different on one of my keyfobs butequal on two of them. I guess this is regular data?

For block 3 of sector 0 (trailer), ffffffffffff is both the A and B key, ff0780 is the access bytes and 69 is user data? Does each block have an access section? According to http://cache.nxp.com/documents/data_sheet/MF1S50YYX_V1.pdf, 8.7.1, they all have. According to this section, the bits are C2C1C1C3C3C2 (four bits each), but wouldn't that require byte 2 and 3, 4 and 5, 1 and 6 to be equal? I have the following access blocks:
Sector 0, block 0: 0000 0100 0000 0000 1100 0001
Sector 0, block 3: 1111 1111 0000 0111 1000 0000
Sector 3, block 0: 0110 0000 0000 0001 1000 1110
Sector 3, block 3: 0111 1111 0000 0111 1000 1000
I cannot seem to grasp how the access conditions can be calculated if fig 10 in the pdf is correct.

Could someone please elaborate for me?

Thanks!

---

+ 0  |  - 0

[TapLinx Support]

Hi Lars,

Yes, the first block contains the UID In the first bytes and manufacturer data. Block 0 cannot be written.

Each sector contains a sector trailer with the keys and access condition bits. For a blank card, these keys are FFFFFFFFFFFF and the condition allows to read and write. If you are the card issuer, which means personalize the card with content, you change the default keys. You may also change the access condition bits.

There are conditions possible where you can write with key A and B, but read only with key B or where you can read, but the writing is impossible. Be careful, if you write an access condition where a write is impossible, you will never re-write the sector again!

The byte 9 in the sector trailer is not used and you can write custom data to it.

Regards,
The TapLinx team

---

+ 1  |  - 0

[Lars Kvanum]

Thanks for the input :) My cards are "magic", so block 0 is writable :)

If I set the access bytes incorrect, won't I even be able to format the cards to make them writable again?

Also, is there a good editor for creating my own data? I'm playing around with the access tokens for the building and reverse engineering them is a fun way of learning :D

---

+ 0  |  - 0

[TapLinx Support]

Hi Lars,

Ok, you are not using MIFARE Classic plastic cards, you use something different, something “magic”. A Classic cannot be formatted! Maybe your “magic device” can. There is no “reverse engineering” required, just only read the datasheet:

http://cache.nxp.com/documents/data_sheet/MF1S50YYX_V1.pdf

Please read section 8.7 about the access conditions.

Regards,
The TapLinx team

---

+ 0  |  - 0

[Lars Kvanum]

Thanks :)

By reverse engineering I'm not talking about the card, but the access scheme set by the company that handles our security cards. Thing is they'll take upward of $50 for a keyfob I can make for less than $1. As the card readers aren't connected to a central server they're not checking uid and they're not logging anything. If I can reverse engineer the scheme I can set up fascilities for our janitor to create keyfobs and save the building cooperative (?) a #¤%load of money :)

---

+ 0  |  - 0

[Author]

Posts