We 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.)
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.
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.
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.
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.
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.
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.
so cool! anyone have any recs for cheap cards (or hardware) that is scannable on iphones?
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" :)
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.
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!
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.
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/
(glances at chip on my desk)
..yes.
Hopefully getting that installed later this week :)
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).
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...
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.
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.
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?
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).
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.
