Set SAK not from Block0 value

[tokamac]

Some tag reader manufacturers do not follow the Mifare spec and use tags with a different value for SAK (e.g. 08) and the byte value written in block 0 (e.g. 0x88)

For all UID/SAK modifiable Chinese tags, the SAK value is taken from the block 0 byte value , e.g. XXXXXXXXXX88 written in block 0 will automatically set SAK at 88, but XXXXXXXXXX08 in block 0 will return SAK 08.

Currently it is not possible to have a SAK value (the one reported with nfc-list) different from the byte of block0. Because if you manually modify the value in block 0 in the dump file and copy it back to the tag, the SAK value is modified too.

This problem has already been exposed two years ago by @0ut0fb0unds in issue #336 but incorrectly answered as being a simple question about various tag behaviors, some having a read-only SAK and others a R/W SAK, and consequently the issue was closed. This is a mistake, as it's a common issue with various known brands that should trigger an upgrade feature in libnfc.

See for example comment 2189127 from @tinue

The solution is to be able to modify the SAK while keeping a different value in block 0, where the SAK is usually set from.

This behavior is something that can be achieved using a Proxmark3, so it should be doable with libnfc too.

[nospam2000]

For all UID/SAK modifiable Chinese tags, the SAK value is taken from the block 0 byte value

This is wrong. My UID writable cards always return SAK as 0x08 even if byte 5 in block 0 is set to 0x88. As the comment from quantum-x in #336 says: "There are many variations of badges floating around" and yours are different from mine.

I need cards which return SAK 0x88 and have SAK 0x08 you need cards with SAK 0x08 and have SAK 0x88, so we should just exchange our cards :-) I ordered my cards on eBay from sunset-clouds as "10pcs 13.5MHZ UID Changeable M1 S50 1K NFC Card Copy Rewritable Blank IC Card ^ V ^"

Can you tell me which cards your ordered?

This behavior is something that can be achieved using a Proxmark3

Can you please quote where this information comes from and what specific command is used to change the SAK to a value independent from block0/byte5?

In https://github.com/Proxmark/proxmark3/blob/master/client/cmdhfmf.c I found the following commands specific to chinese cards, but no specific command to set the SAK:

  {"csetuid",          CmdHF14AMfCSetUID,       0, "Set UID for magic Chinese card"},
  {"csetblk",          CmdHF14AMfCSetBlk,       0, "Write block - Magic Chinese card"},
  {"cgetblk",          CmdHF14AMfCGetBlk,       0, "Read block - Magic Chinese card"},
  {"cgetsc",           CmdHF14AMfCGetSc,        0, "Read sector - Magic Chinese card"},
  {"cload",            CmdHF14AMfCLoad,         0, "Load dump into magic Chinese card"},
  {"csave",            CmdHF14AMfCSave,         0, "Save dump from magic Chinese card into file or emulator"},

The proxmark3 command hf mf csetuid <UID 8 hex symbols> [ATQA 4 hex symbols SAK 2 hex symbols]

internally uses int mfCSetUID(uint8_t *uid, uint8_t *atqa, uint8_t *sak, uint8_t *oldUID) {

which just sets byte 5 of block0 when SAK is specified:

        if (sak != NULL)
                block0[5] = sak[0];

Don't get me wrong, I want to have the functionality of modifying SAK independently of block0/byte5 but I haven't found a way to do it and how to get cards which support this feature.

Michael

[ensingerphilipp]

Something interesting to Note:

My Chinese Magic Cards do send 0x08 SAK even when changed to 0x88, but the same tag - when give SAK 0x89 will send 0x89 and not 0x09.

[RaJiska]

Any news on this ? Is there a way of emulating the behavior of the original tag by returning 08h when 88h is actually written to it ?

[jimkid202]

Agree -did anyone solve this? My clone was perfect except for the 08/88 error. When I change the UID to 08 it flows through to Block 0. Perhaps it's just a limitation of the infineon card?