Coercing a Magic MIFARE credential into being an iPhone-compatible NFC tag
ewpratten.comWe did extensive research on the subject, there is no mystery. iOS will only read MIFARE tags with NDEF formatted data. If you write NDEF data to a formatted MIFARE card, it will be 'compatible' with iOS.
Otherwise, only the UID can be detected. The real mystery is why Apple refuses to open the low-level read commands. (To read NDEF, or determine that the data is _not_ NDEF, you need to read the card.)
It's not a mystery - it's anti-competitive behavior where they only want to give access to low-level NFC access (required to enable things like door locks, car keys, payment/loyalty card systems, transport, etc) to "partners" who sign an NDA and agree to a rev-share.
For all the things wrong with/bad about Apple's iron grip on low-level interfaces, in this case that's not the only reason:
MIFARE Classic uses a mandatory, proprietary (presumably still patented) encryption algorithm even for "world-readable" cards, on top of the ISO 14443-3 standard. I'm not even sure whether Apple could legally offer that capability without licensing it from NXP.
On Android, only devices with an NXP chip support these tags for the same reason.
You could argue that Apple could just provide even lower layer access to the contactless interface to allow apps to implement it in software, but I'm not sure if that's feasible (due to timing constraints).
(Note that the article doesn't specify which MIFARE tags it is about. If it's MIFARE Classic, something must have changed, and maybe Apple has licensed the required NXP patents? DESfire should work with iOS without jumping through any hoops, since that implementation is ISO 14443 compliant all the way up to -4.)
Seconded. There’s almost certainly NXP IP used in nearly all NFC implementations which makes them subject to their terms.
Those terms are in turn set by the partners that asked for these technologies to be developed in the first place. And so any development gets slowed to a crawl in this space.
Didn't apple announce earlier this year they were going to open NFC up more? What ever happened to that?
It’s open to developers as of iOS 18.1:
That's for card emulation. This article is about using iOS devices as readers.
ISO 14443 card reader functionality has been made available some iOS versions before, but it's still restricted (e.g. you can't select any "payment" ISO 7816 applications, you have to predefine the list of AIDs you want to be able to select, and you don't have lower layer access to ISO 14443).
I'm not aware of any announcements to further open up "reader" mode.
Agreed, but it’s certainly more open than it used to be. At least now you can emulate a variety of cards directly in an app.
Big companies that can afford to pay the certification fees maybe can; I definitely can’t. The entitlement is not available to regular app developers, unfortunately.
In the EU, maybe. And even then you will most likely need to beg for an "entitlement" to use it which may have requirements around being a registered business, etc so hobby apps are still excluded.
There's two versions of access to "card emulation" mode:
- The EEA-only HCE (which lets you emulate the card in your app in software, for a limited list of use cases, which makes it a non-starter for fully offline systems unfortunately, as there's no protection against exfiltrating any keys from the app), and
- The some-non-EEA-countries-only "full smartcard access" solution, which requires you to pay Apple and do a ton of (presumably also very expensive) certification.
So for different reasons, neither is something in scope for hobbyists at the moment, unfortunately.
Ah - this brings back memories.
Back in 2015 I was tech lead for a modern (web based) SaaS library management system and getting it to work with RFID tags with a wrapper application was all sorts of fun and games.
We got RFID library tags working on Android, but with iOS locking down NFC access it turned out to be impossible and we had to get libraries to buy bluetooth connected RFID scanners.
It's not a mystery - NFC features are cool but contactless payments are valuable. Nothing that could possibly interfere with that will be tolerated.
This is cool, but the most interesting part is the part that requires investigation, i.e., what do the compatibility tools write to the card to make it iOS-compatible? I've done some work with iOS NFC, but not enough to have experienced the undocumented quirks.
My read of the proxmark code (https://github.com/RfidResearchGroup/proxmark3/blob/master/c...) is that the `ndefformat` formatted the tag MAD (https://www.nxp.com/docs/en/application-note/AN10787.pdf), which you'd do for NDEF, then had a single TLV TERMINATOR at the block where the NDEF message starts. Then he used NFC Tools to write on an NDEF text record (which iOS background reading would ignore) and maybe something else? After that he then used `ndefwrite` to write on a URL record. I wonder if he could have skipped the NFC Tools and written the URL record and gotten the same result. Proxmark dumps before and after using NFC Tools would be insightful.
Ya, I have no clue tbh.
This is one of those cases where I know I really should investigate further, but I'm taking this one step at a time. Perhaps digging in to the "why" will become a follow-up post
I didn't intend for what I wrote to be a criticism; that's on me. I just found it funny the most interesting step was akin to "... and now you've drawn the animal", if you understand the reference.
But what happens if you dump the card with the Proxmark? Surely you should be able to see some differences.
Actually, I have all the components, so I'll try this now and report back.
My quick eye-skim didn't see much, but I'll do a byte-for-byte diff. I imagine its a difference in the NDEF headers? (but even that doesn't make sense, since I wrote the headers again from the pm3)
Well it turns out I'm much worse at this than I thought, as I can't even figure out what kind of cards I have. I'm learning, though!
HN formatting is going to do bad things here..
Here's the first 6 blocks of the card after I ran through the instructions of the post, then a ndefformat-only card (that never touched an iphone).
[=] 0 | 0 | 00 56 78 BB 95 08 04 00 02 B2 1E 24 23 27 1E 1D | .Vx........$#'.. [=] | 1 | 14 01 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 | ...�.�.�.�.�.�.� [=] | 2 | 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 | .�.�.�.�.�.�.�.� [=] | 3 | A0 A1 A2 A3 A4 A5 78 77 88 C1 89 EC A9 7F 8C 2A | ......xw.......* [=] 1 | 4 | 00 00 03 12 D1 01 0E 55 04 65 77 70 72 61 74 74 | ....�..U.ewpratt [=] | 5 | 65 6E 2E 63 6F 6D FE 00 00 00 00 00 00 00 00 00 | en.com�.........
[=] 0 | 0 | 00 56 78 BB 95 08 04 00 02 B2 1E 24 23 27 1E 1D | .Vx........$#'.. [=] | 1 | 14 01 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 | ...�.�.�.�.�.�.� [=] | 2 | 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 | .�.�.�.�.�.�.�.� [=] | 3 | A0 A1 A2 A3 A4 A5 78 77 88 C1 89 EC A9 7F 8C 2A | ......xw.......* [=] 1 | 4 | 03 00 FE 00 00 00 00 00 00 00 00 00 00 00 00 00 | ..�............. [=] | 5 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
Here's mine:
Ya, looks like the iPhone is tinkering with the NDEF message itself.
If my Android phone wasn't dead, I'd love to compare an iPhone's write against the Android NFC Tools app's write.
If anyone else has an iPhone, an Android phone, and a Proxmark, I'd be interested in seeing a three-way diff between them all.
EDIT: I'm going to try to cross-post to the DT forum to see if anyone has ideas.
I've got both phones next to me, what do you want me to do exactly?
Wipe the card.
Make a dump after doing "hf mf ndefformat".
Then make a dump after writing a payload from an iPhone. (since iPhone seems to want ndefformat anyways)
Then wipe again and make a dump after writing from Android.
Here you go: https://www.pastery.net/xajezk+gbkqqz+aqwygg+ukrdad/
Thank you very much!
Something's clearly up there. You can see that even IOS and Android disagree with each other on what NDEF should look like by a few bytes. Very interesting.
Yep, 89 EC A9 7F 8C 2A 00 00 on iOS versus FF FF FF FF FF FF on Android. Interesting how the number of bytes is different, I should play with them a bit.
There's lots of info about the NDEF "packet" format online.
I used this page as reference when I was putting together the "magic bytes" in the final section of the blog post: https://www.oreilly.com/library/view/beginning-nfc/978144932...
This is fantastic, thanks!
Also, one thing that might be of interest: Even after a wipe and an ndefformat, my Android-written tag can be read by my iPhone 15.
NFC tools will only read it in compatibility mode, though.
Are you sure? The NFC app for iPhone can always read tags. Its specifically getting phones without the app to read them.
Try wiping, then writing a URL from Android.
Then just tap to the iPhone and see if Safari opens or not. It shouldn't
Yes:
I don't know if it's Vivaldi doing that, but I can't imagine they would have added NFC tag reading capability to the browser specifically.
Feel free to email me if you want, btw, as this thread is getting a bit too deep.
If a URL is written using NFCTools on iPhone, iOS will open it in the default browser without using NFCTools, or in the related app (eg Instagram) if there is one.
I find this only to be true when used on the same iPhone where NFCTools was used.
If you try to have another iPhone detect the badge, it appears not to work - unless you use NFCTools on that iPhone, too. I don't have conclusive proof but that's what the evidence seems to indicate.
Are you seeing something different?
Proxmark's "auto" command should get you most of the way to knowing. Then check if any of the "hf mf c*" commands work on it (in which case, you have a gen1a magic card)
Nice, I didn't know about auto, thanks! It turns out I have some Gen 1a "magic" cards (as in, actually in a card form factor), and some tags that seem to be Gen 3, but not magic?
There's approx 4 generations of "Magic".
Gen 1, 1a, 3 and 4 all use special commands to unlock and edit block 0.
Gen 2 treats block 0 as always being r/w. This allows Android phones to directly write to it (but also makes it possible to lock the card).
In terms of pm3 commands, "auto" tries everything. You might also want to use "lf search" or "hf search" to only try one of your antennas and not the other.
The actual Magic part isn't really important here, since my phone doesn't even care about block 0. It just makes it easier to read and wipe the card when you have the extra command set at your disposal.
This is great, thanks! Do you know of any resource to learn more about Mifare cards? Is "beginning NFC" that you linked me to a good general resource?
All my knowledge is trial & error.
I've found the people over in the DT forum are pretty helpful with the cloning and usage aspect of things: https://forum.dangerousthings.com
Additionally, Iceman's Discord people has tons of smart people: https://discord.com/invite/iceman
Thank you!
Hm, its definitely blocks 0-2. All remaining blocks after that are identical.
Going to look further at the actual data in the first 3 blocks momentarily.
I suspect the comment (above, at the time I wrote this), where they mention that Apple only wants partners to be usable, is the Ockham's Razor answer.
Probably some "magic key" ID.
But this is not my area of expertise. It's a cool story, though, and why I like hanging here. Considering getting a Proxmark and the NFC Tools app, just to play around.
so cool! anyone have any recs for cheap cards (or hardware) that is scannable on iphones?
The cheapest RFID/NFC "card" tag is an expired tap-to-use transit ticket. It has a unique ID that can be used to trigger an iOS Shortcut to take any action, e.g. speak an audio description, open URL, open app, etc.
For purchase, there are many form factors: https://store.gototags.com/nfc-tags
On Amazon, search NTAG215.
If your city doesn't use NFC transit, you can also buy a box of blank cards. They have unique IDs like transit tickets, even without being programmed.
NTAG215 isn't "magic", right? I have a bunch of NTAG215 stickers and I'm not entirely sure what their difference is with magic cards.
Think of it like a subset of MIFARE.
In a simple sense, NTAG cards can do NFC things, but MIFARE can do lots more (access control for example)..and also NFC things..somewhat.
Magic mifare refers to special cards that let you bypass the write-lock of genuine mifare cards. These are mostly used for cloning keys (either for red-team pentesting or for people who want a copy of an office key for whatever reason)
It's not really a subset:
MIFARE Classic uses a proprietary and mandatory encryption/authentication algorithm and is therefore not ISO 14443-4 compliant. As a result, NFC-compliant readers don't need to support it, and in fact non-NXP ones (including many popular Android phones) usually don't.
On the other hand, as you say, MIFARE Classic supports capabilities beyond NFC/NDEF, but there are fully NFC-compliant tags that do so as well (e.g. MIFARE DESfire, which properly stacks encryption in an ISO 14443-4 compliant way).
Ah, thanks, so I guess to write tags like URLs and things I don't really need Mifare cards, the NTAG cards are fine. Thanks for the info!
Many of my cards are just repurposed from other things. Lots of hotel keycards can be rewritten to open URLs on phones for example.
I actually have a hotel keycard taped to my washing machine to do some laundry-based automation with my phone. Maybe I should write about that sometime..
Have you thought about getting one implanted?
If you're getting an implant already, why not make it an actual smartcard that you can use for WebAuthN, GPG, SSH etc.? :)
On the other hand, the fear of permanently bricking it or messing up the GlobalPlatform card management key has so far prevented me from doing it myself...
Because those cost $350 as opposed to $89, and the install only costs $60, and there is no stopping you from implanting more than one in different locations.
Many people get the small xEM or xM1 first to play with.
* https://dangerousthings.com/product/apex-flex/ * https://dangerousthings.com/product/xm1/
> there is no stopping you from implanting more than one in different locations.
Good point, although at some point you'll want to make sure your reader implements anticollision properly :)
(glances at chip on my desk)
..yes.
Hopefully getting that installed later this week :)
If you only care about static data that you can optionally freeze to a permanent read-only mode, NTAG21[3|5|6] tags are probably among the cheapest ones that reliably work with all iOS and most Android devices.
MIFARE Classic supports (completely broken and for this use case) useless encryption and doesn't work with some Android devices, as they're not really a part of the standardized NFC stack.
If you want to get really fancy, you can also get a Java Card based smartcard and install an NDEF application yourself. You could then also install a FIDO application and use the same card as a "homebrew Yubikey" :)
https://www.amazon.com/dp/B0C49SVTCT
are the tags I have, and https://apps.apple.com/us/app/nfc-tools/id1252962749 is the app I used (which is the same as the one used in the post).
In my experience, the notification you see at the end of article was used to advertise your brand/site.
The number of obnoxious people/guerilla ad companies that printed and programmed NFC tags and stuck them in random places was way too high. In some cases, they would replace the businesses QR code with the NFC tag. In some cases that NFC notification would pop up instead of the business’s menu. Quite annoying.
Then there was a case where the person stuck the raw tags _under the table_, so putting your phone down in random places would spam this notification on your screen.
Ah, we did the under-the-table thing with NFC stickers in school! Love rickrolling a well-placed phone on a classroom desk lol.
I'm personally not a huge fan of needing to use NFC tags in the real world (parking meters use them for payment around here), but I do like creating tags.
Has anyone managed the opposite feat, i.e. made a piece of hardware that can recognise an iPhone over NFC? I'm trying to design control system that relies on you touching your phone to various hardware readers (with some kind of unchanging key/identity), but off-the-shelf MFRC522 etc don't seem to work, and the 'official' Apple way requires an NDA...
NFC has been opened up more in iOS 16 and 17.
Card emulation is a thing now: https://developer.apple.com/documentation/corenfc/cardsessio... (edit: only in the EU)
And iOS as well as iPadOS now also support USB smart card readers. iPads can actually use them to access NFC FIDO tokens. (Why iPads don't have native NFC is completely beyond me, there are so many obvious use cases for it)
> And iOS as well as iPadOS now also support USB smart card readers.
Oh, that's very cool!
Apple seems to silently be implementing more and more features to make iOS/macOS a full-fledged smart card OS; I've also noticed that FIDO over CCID is now available natively on macOS, and by extension in Firefox and Safari via WebAuthN (which finally lets me use my smartcard form factor FIDO authenticator).
Here you go: https://github.com/kormax/apple-vas
If you can send/receive APDUs you're good to go.
Wow, that's neat!
Do you know if Apple requires any special permissions/entitlements to create VAT passes, or does a normal pass certificate suffice?
I think you're supposed to make a "Pass", load it on Wallet app, then load the card with double press of side button. You can't just tap a blank iPhone and get its raw hardware ID.
At least Suica train cards(based on FeliCa/NFC-F) on iOS can be read from third party Android apps, and Apple do advertise iPhone feature to store corporate IDs, so the idea of using iPhone for gate tap-in card should be completely fine.
None of this is accessible to hobbyists, unfortunately – you'll need a special entitlement, certification, your use case to be an approved one etc.
It's not accessible to "regular" app developers in the way it is for Android.
Without getting into the weeds of programming for the secure element (some non-EEA markets only, NDAs, tons of certifications etc.) or restricting yourself to HCE (available only in the EEA), you could also "flip the model around":
ISO 14443 reader access has been available globally, so if you're fine with having to open an app before an interaction with a reader, you could have the reader perform card emulation, and the phone "read/write" it like a tag, i.e. send APDUs which the device behind it then interprets.