Support for MIFARE Plus cards

[dev-zzo]

Another tracking item for more card types to be emulated. It seems Plus cards slowly replace Classics just like the vendor wants it, so it would be nice to have this supported too.

[martinbeier]

+1

maybe first could be MIFARE Plus in SL1 -> "MIFARE Classic Mode"

[david-oswald]

Note that there is already the config MF_CLASSIC_1K_7B which at least supports long UID for MFClassic (not sure what SL1 implies besides this).

[ccb3b72]

Hi,
I would like to ask some help.
I have an NXP Mifare Plus card. I tried the following tools / hardwares / readers:

Readers: TWN4 and Samsung S8
Although TWN4 reader seems to handle NFC, nor in HID or CDC mode I tried, the applications said no NFC device found...

Tools:

• NFC-tools (windows/linux/andriod mobil app)
• Mkeys (mobile app)
• MTools (mobile app)
• Proxmark RDV2
• ChameleonMini

1.: Anybody could suggest me a solution/approach to be able to read (and maybe modify) the content of the card? Or to clone the card...

2.: According to http://nfc-tools.org/index.php/Devices_compatibility_matrix , the well-known ACR122U NFC reader is not good enough, since it has massive technical impediments. I was thinking in Arygon, but it seems you definitely have to be lucky to be able to buy one :)
So what could you guys suggest me? I want to change my TWN4 reader...

Many thanks!
Richard

[ceres-c]

@ccb3b72 I'm not totally sure I understood correctly the issue here.
Could you please elaborate on what you're trying to do and which part the ChameleonMini takes in it?
Thanks

[ccb3b72]

At first, Thanks for the quick reaction @ceres-c

Actually I started with Chameleon Revg and Tera Term. It was smooth to read out the UID, ATQA and SAK. The Type was not recognized but I did some research and learned that it must be Mifare Plus.

Then I tried every possibility given to change the CONFIG parameter and tried to dump the file content. The dump file containted or 00 or FF bytes only. Also tried to clone the card.
I googled a lot and followed some descriptions, but I could not do any progress.

Like: https://rawgit.com/emsec/ChameleonMini/master/Doc/Doxygen/html/_page__command_line.html#Anchor_TimeoutCommands

I am not sure whether I could answer your question properly :) I just wanted be really precise in my first email and describe what I have tried. Sorry if it was confusing.

Do you have any idea, how should I approach a Mifare Plus card, which has (probably) AES encrypted content? Any idea would be great.

Thank you

[ceres-c]

So you're trying to use the Chameleon as a reader, am I correct?
To be honest I've never used in in that way and then can't help you, since I have other tools, which you have too (most notably the proxmark), to read and fiddle with real cards.
That said, is that a Mifare Plus card used to emulate a Mifare Classic or not? You should be able to infer it from the SAK. Refer to this NXP Application Note, page 7.
I don't remember attacks against pure Mifare Plus cards (but I could be wrong), while Mifare Plus in Emulation mode are still vulnerable to Hardnested and Reader attacks. As @geo-rg said in other places here, we can't provide you a step to step guide in performing such attacks.

[ccb3b72]

Of course I did not want to ask step by step howto. ;)
Thanks the hint, I will check them.

The thing is, I am just not sure what kind of NFC reader should I use for Mifare Plus , since ACS ACR122U got not so nice reputation by nfc-tool compatibl. matrix.

[ceres-c]

Start off by identifying the card with a hf search through the proxmark. Once you have done that you shouldn't need much more, actually. You could also use NFC Tools application for Android and, if your phone supports it, the Mifare Classic Tool, only if that is a Mifare plus in emulation mode.
If you have any further question or need some more precise information you can write me an email ;-)

[ccb3b72]

I will do that. At first I am doing my own research/homework ;)
Thanks

[ccb3b7]

Hi. I would like to ask some help.

I have a Mifare Plus SL3 card. No default keys. Normal Mifare attacks (which are well documented) are not effective here. Even mfcuk does not work.

I sniffed a transaction with ChameleonMini. I know, In theory 1 key can be extracted from that bin file... so far so good.
With Chameleon how should I proceed?

So far I converted my bin into eml and load it into proxmark. But only lots of 7e7e values were the content (hf mf list). So I googled further and could see that I should open the eml file in notepad++.? :)
At least I can see that the sniffing yielded something which is not 7e7e7e....

So my question, could you tell me what should I do now? Because what I could see on many places "you just need to sniff one transaction and here you go...".

And how should I proceed with ChameleonMini? I would like to use it further. :)
Thanks for your help!

[ceres-c]

Search for mfkey32/mfkey64 tools and how to use them. You should find some information on proxmark forums

[ccb3b72]

Thanks for your hint. I checked it. It seems mfkey64 will be okay for me. Anyway, I realized that I am stucked because I am not able to identify the nt, nr, ar, at values, because I sniffed with chameleonmini. After I used the chamlog.py I have result, but unfortunately I have not got the last column (what is provided by proxmark) where it can be seen the exact meaning. For example I cannot see the AUTH-A value, which would indicate me that the next X bytes are high likely the NT value.
I used in proxmark the convert LUA script, but the result is not so nice. Is it possible to find out the field what are needed for mfkey64? How ChameleonMini users are doing this "clarification"?

[ceres-c]

There are example usages on pm3 forum. Or you could read mifare docs/attacks

[jtoddowen]

miLazyCracker worked great on a MiFare Plus (7 byte UID) 2K SL1 card I had (ATQA: 00 40, UID size: double, SAK: 08), although it took over an hour to extract all the keys—dependent on CPU cores/speed. Contrary to your experience, I did use an ACR122U without issue. Depending upon which key it was working on, the card was read up to several thousand times before it could proceed.

I am yet to find a card the output (oddly a 1K mfc file) that mfoc (called by miLazyCracker) can write to. This is why I’m looking into the Chameleon.

[ceres-c]

If you were able to use milazicracker on a Mifare Plus that meant you had at least a known key. The Darkside Attack (implemented in MFCUK) does not work against Mifare Plus since NXP solved the issue it was relying on. On the other side Mifare Plus are still affected by a variant of Nested Attack (implemented in MFOC) which is known as HardNested Attack (implemented in milazycracker)

To the best of my knowledge there is no "zero knowledge" attack on Mifare Plus. You need at least a key (which you can still sniff)

[jtoddowen]

@ceres-c, I believe the card is a MiFare Plus based solely on the ATQA and SAK data I mentioned above. The Darkside Attack didn’t work, but the HardNested Attack did. Looking over the log file, all but three sectors use the all-Fs key for Key A and Key B and contain the same data (virtually all zeros). Sectors 01, 14 and 15 use unique keys for Key A and Key B.

[ceres-c]

Ok, that's totally plausible. You already had some keys (the Fs) and milazycracker could indeed recover the remaining keys with the hardnested attack. But that did work only because you already had some keys. If you did not, there would have been no other way than sniffing two failed authentications or a successful one.

[jtoddowen]

Based on the ATQA and SAK the card is 2K. Do you know why the mfd file would only be 1024 bytes? Also, would the Chameleon Mini be able to play this tag?

[ceres-c]

Mifare Plus 2K cards emulate Mifare Classic 1K cards, since there were no Mifare Classic 2K cards, so you're reading everything :-)

The Chameleon would be of course able to emulate the emulated Mifare Classic (pardon the repetition) but to my knowledge there is no Mifare Plus support. As David wrote in #44 (comment), 7 bytes UID are already supported so you could try and modify the Mifare Classic application in order to have the right ATQA/SAK. Honestly I don't know wether there are other differences detectable by the reader, you'd be better off reading the Mifare Plus datasheet.

[jtoddowen]

The only 7-byte cards I have are 4K, but I’m getting a “Could not read dump file: _____.mfd” error when I try to use them, which I assume is because the mfd file is 1024 bytes. The card identifies as ATQA: 00 42 and SAK: 18. Although unrelated to Chameleon, is there a way to flash the file to the 4K card to see if it works?

[ceres-c]

Well, you don't have to use 7-bytes UIDs, standard 4-bytes UIDs are supported as well, it depends on what you have to do, just choose the right configuration.

Where are you using the .mfd file? mfd are binary files, so probably the software you're using accepts data in some other format.

I've never used Mifare Plus cards first hand, so I can't help you more.

[jtoddowen]

At the end of miLazyCracker, it executes $ nfc-classic W a $TMPFILE_MFD which is where the mfd comes in.

[ceres-c]

In libnfc's changelog at a certain point was indeed specified:

nfc-mfclassic: detect MIFARE Plus 2K as 2K instead of 1K

So you might be right about the size mismatch. I don't know...

[jtoddowen]

I am pleased to say I successfully used a Proxgrind Chameleon Mini RevG RDV2 (using the MF_CLASSIC_1K_7B mode) to emulate the aforementioned card. I used the 1k dump file from miLazyCracker via the Chameleon Android App (2020-06-03_1803, code 105) to get the card data installed. None of the “magic” cards I tried worked. Since I now have all the card keys, I check my real card periodically and none of the data ever changes.

I do find the MIFARE Classic Tool Android App an invaluable companion to the Chameleon App. The App / Chameleon’s MF_DETECTION_1K mode doesn’t seem to like 7-byte tags, but I’m still looking into this.

To me this is just a cybersecurity endeavor, but I do see how this could be exploited for nefarious reasons. The more you know as a security professional, the more you can defend against it.

[n4ru]

Any luck getting MF_DETECTION_1K to work with 7-byte UIDs? Need to crack keys for a card I own that uses 7-byte UIDs but detection/sniffing seems to only support 4-byte IDs, rendering the device useless to me. Tried both the Android app and the GUI.