rfidmifare

What determines the SAK of a Mifare device?

I have a Mifare fob and a magic Mifare Classic card. When I fully clone the fob onto the card, the SAK found from the card is 0x88, despite a SAK of 0x08 on the fob.

If I change the sixth byte of block 0 on the card from 0x88 to 0x08, the SAK changes accordingly. However, the fob holds a value of 0x88 at that position whilst reporting a SAK of 0x08. So, what determines the SAK such that two cards with supposedly identical data can report different values for it?

Solution

  • I had the same problem. I had:

    From the Rfid Research Group documentation we can found this information:

    MIFARE Classic block0:

11223344440804006263646566676869
^^^^^^^^                         UID
        ^^                       BCC
          ^^                     SAK(*)
            ^^^^                 ATQA
                ^^^^^^^^^^^^^^^^ Manufacturer data
(*) some cards have a different SAK in their anticollision and in block0: +0x80 in the block0 (e.g. 08->88, 18->98)

    so usually the SAK is determined by the bytes #6 of the block 0.

    But as specified in the doc, some cards have a different SAK in their anticollision and in block0.

    So unfortunately my chinese TAG gen1a was unable to reproduce the same behavior of my original TAG. Also a gen1a TAG accept magic command, which means that a backdoor exist with those tags and you can read or write a block without using the access key, this backdoor is now well known and some reader can detect that.

    The solution was to use a gen2 TAG aka CUID card, with block 0 rewritable. This TAG add a 08 SAK, by default, that did not change, even if a rewrite the byte #6 of the block 0.