Emulating Mifare Classic with 5 sectors

[ghost]

Hello,

I have a dump of a Mifare Classic tag which oddly only has 5 sectors (0-4)? (This tag was read by Mifare Classic Tool, on Android and I have dumped it multiple times with the same result).

I can seem to only get the Chameleon Mini to emulate the tag as if it has 16 sectors (0-15), so it isn't a perfect clone. I am using Chamgo-QT ( https://github.com/WolfgangMau/chamgo-qt ) on Manjaro Linux to write my dumps to the device.

Is it possible to add emulation support for tags that have abnormal sector counts?

I have attached the dumps of the tag: Dump_5sec.zip

[fptrs]

Hi @lavanoid,

I think your tag is a Mifare Classic Mini. Currently it is not a supported configuration. We are always happy about contributions and if you send us a tag, we can help you with the development.

[ghost]

Thanks for that! I wasn't aware that Mifare Classic Mini was a thing.

I would love to send a tag, but I no longer have access to the one that I obtained the dump from. I copied it with MCT on Android, back in 2017 and have since lost it ._.

I would assume that we could just modify the current code base for the Mifare Classic and make the Chameleon present only 5 sectors instead of the usual 16, right?

[ghost]

Found some useful information here: https://www.badge-vigik-selecta-copie.fr/index.php/forum/selecta/41-mifare-mini-0-3k-atqa-sens-res-00-04-sak-sel-res-09 and http://newffr.com/viewtopic.php?&forum=235&topic=16208

MFCM ATQA: 0004 MFCM SAK: 09 EEPROM: 320 bytes

Places to purchase:

• https://www.aliexpress.com/item/32812111828.html

Way out of my price range and probably not worth the price since we'd only need a few tags at best.

[ceres-c]

Last time I had a Mifare Mini on hand it looked like your average Mifare Classic, so I guess you don't need a sample. The datasheet should be enough :-)

[timokasper]

So probably, duplicating the mf_classic_1k configuration and setting to 5 sectors instead of 16 will result in a suitable "mifare Mini S20" emulation.

[ghost]

🐱 Most likely! Also, I should probably open another issue for this next thing I've encounterd:

When setting a slot to READONLY=1, it doesn't stick when the device is powered off and powered back on. To get around this, I have to use the RECALL command if memory serves correctly for it to save properly?

The READONLY option also seems to apply itself to all slots, meaning that I cannot write to any of my saved tags when I just want one of the slots to be set as read-only.. I don't know if this is reproducible on your end? Some readers check if the UID part of the tag is writable, to determine if it is a clone. And if possible, add an option to make only the UID part of the tag readonly whilst having the other blocks read/write?

[ghost]

For testing purposes, I assume there is more involved than just changing MIFARE_CLASSIC_1K_MEM_SIZE 1024 to MIFARE_CLASSIC_1K_MEM_SIZE 320 ?

[ceres-c]

For testing purposes, I assume there is more involved than just changing MIFARE_CLASSIC_1K_MEM_SIZE 1024 to MIFARE_CLASSIC_1K_MEM_SIZE 320 ?

Well you should create a MIFARE_CLASSIC_MINI config and modify accordingly at least the following files (I might have missed some)

• https://github.com/emsec/ChameleonMini/blob/master/RevE/Firmware/Chameleon-Mini/Configuration.c Here you add the MIFARE_CLASSIC_MINI configuration itself alike CONFIG_MF_CLASSIC_1K_SUPPORT and CONFIG_MF_CLASSIC_4K_SUPPORT
• https://github.com/emsec/ChameleonMini/blob/master/Firmware/Chameleon-Mini/Application/MifareClassic.h Here you add new memory size constants
• https://github.com/emsec/ChameleonMini/blob/master/Firmware/Chameleon-Mini/Application/MifareClassic.c Here you create the MifareClassicAppInitMini function. You'll probably have to check if everything else in this file is already correct or have to be tweaked

[ghost]

Changes made. The ChameleonMini just freezes when setting a UID for the MifareClassicMini configuration.

These are the changes I made: https://github.com/lavanoid/ChameleonMini/commits/master

[ghost]

Here is a pre-compiled firmware, with the above changes. MifareMini-Chameleon-Mini.zip

[ceres-c]

Spotted the bug, I guess. You missed the full configuration in Configuration.c, you could use CONFIG_MF_CLASSIC_4K_SUPPORT as a reference. I mean the bottom part of the file starting on row 93. It freezed since there were no pointers to functions related to your new config

[ghost]

Fixed. Now for some reason the emulated tag still has 16 sectors.

[ceres-c]

It might be due to ATQA and SAK values in MifareClassic.c which identify your CONFIG_MF_CLASSIC_MINI as a Mifare classic for the reader. Set proper values in MifareClassicAppInitMini This document might help: http://www.bdtic.com/DataSheet/NXP/AN10833.pdf

PS Please note there are Mifare Mini with 7 Byte UIDs, so you might want to specify this is a 4 Byte UID version in your config names

[ghost]

It seems that both the 4 byte and 7 byte Mifare Mini cards have the same SAK and ATQA values? Unless I'm missing something?

4. 4 The 7 byte UID MIFARE Mini has bit 7 = 1, even if the 4 byte NUID mapping is enabled. Not sure what that means exactly.

[ceres-c]

It might be possible. I'm no way expert in ISO14443 since I did not implement anything about it, but if I'm not mistaken the reader gets to know the UID is 7 bytes long during the transmission of the first 4 bytes themselves. So it can be that they have the same SAK/ATQA. Nonetheless, I'd explicitly mark the configuration as being 4 bytes only, since the UID is hardcoded to be 4 bytes long

[ghost]

Okeydoke, I'll change the configuration name to reflect the fact that it is 4 bytes long.

Not sure if those error messages are normal.

[ceres-c]

Have you had similar errors with an emulated Mifare Classic 1K or with a real Mifare Mini on the same reader? If any of the two is true I guess we could consider your patches as good, otherwise this has to be digged into

[ghost]

Seems to do it even on a 1K config, so I would assume it has something to do with libnfc not knowing the A and B keys. So that means my patches are fine.

[ceres-c]

Then it's good, I guess :-)

[ghost]

I wonder if we could use the source code for this (when released) to add support for more tags on the Chameleon: https://cyberise.me/multipassme/26-multiclonerv2.html

[ceres-c]

The fact itself that it's using an ESP32 does not make me fond of it, actually... Apart from personal preferences, the different architecture means it won't probably have any common point with this project so it won't be of any use. It seems to be mainly geared towards programming human implants which can't be produced by your average joe. In fact, if you have a look at their website they're selling normal RFID tags, a dumb chinese tag cloner and this product. I could bet this will be just another half-working tag copier...

Also they say it's derived from Proxmark3 Lite which I, honestly, don't know what it is.

[fptrs]

Hi guys, I have quickly tested your contribution with the NXP TagInfo app and it recognized the Chameleon as a valid MF1S20 tag 👍 Nice work!