MIFARE Classic – FmTag is always nil

[MorganParticipant]

Hey guys,

Wondering how to get started with a MIFARE classic 1K card? I’m using the FloBLE Noir and I’ve got the cards being recognised, but in terms of actually reading data off them I’m drawing a blank. Reading the data using the excellent Arduino NFC library was a breeze, but I’m completely stuck on where I’m supposed to put in my authentication key.

The key, as it happens, is not really a key at all – it’s all 1s – but MIFARE doesn’t have a notion of unencrypted data so everything needs some kind of key.

On the FloJack, this was accomplished using the mifare_GeneralAuthenticate command… looking back through the release notes, it seems like MIFARE authenticate was achieved way back in version 0.1… but I’m totally lost on how to make it work.

Any help would be appreciated.

[ScottKeymaster]

Hi Morgan,

Currently our latest iOS SDK only supports reading MIFARE classic 1K tags with FF FF FF FF FF FF as the key. Support for more popular tag types have been made a priority within our SDK. If this is a business critical issue, consider purchasing Flomio Service Hours to add support for our newer readers to facilitate changing the key for mifare classic 1k authentication.

Kind Regards,
Scott

[MorganParticipant]

Yeah – that is the key. Like I said, all ones. It still doesn’t work. Is there a function to read a specific block? Some blocks are encrypted with a different key.

Like I said in the title – the FmTag is always nil when I get my delegate callback, so it seems like I can’t interact with the card at all.

[ScottKeymaster]

I am trying recreate your problem here but not receiving a nil FmTag. What SDK version are you using?
A possibility is that there is a different ATR on your tag than the ones we’ve tested. Do you know the ATR of your tag?
Scott

[MorganParticipant]

I’m on 3.0.0, though I see there’s been a couple of releases that might be specifically addressing MIFARE Classic.

But I’ve found something even weirder – I opened up the example project to make sure I wasn’t just doing something stupid in my project, and lo and behold, it finds the tag (though it can’t read the NDEF because it’s not supported on this card type). I tried to set a breakpoint in the method, but for whatever reason the breakpoint just wouldn’t trigger…

I eventually realised that the configuration was set to “Release” not “Debug” for the Run command. That’s weird, but whatever, sometimes people change it.

It doesn’t work when you set it to Debug.

Not only does it not work, but didFind(_:fromDevice:) is never even called. didChange(_:fromDevice:) is never called either.

I’m scratching my head over this one. What’s so different about the Debug build vs the Release build that it seems to completely break the SDK? I’ve just downloaded the latest stable release, 3.0.2, and confirmed that it still happens – the card isn’t recognised unless you’re in the Release configuration. (Also, the example app still won’t build, and when you fix those problems, still crashes on launch. Why do I have to include the ScanSound.caf file when I’ll never use it?)

This is getting weirder and weirder. I’m going to investigate.

[MorganParticipant]

Figured it out, I think – the “Validate Built Product” setting must be set to “Yes” for both Debug and Release configurations.

Why? I have no idea. But it made the example project work.

Now, there’s the problem that readNdef is nothing like granular enough, slowly crawls through every sector of the card instead of allowing me to specify a block… I ended up putting a breakpoint in sendApdu: to figure out exactly what messages I needed to send.

It would be really nice if you provided some kind of resources for APDU commands, considering that it seems like a large chunk of your use cases depend on dropping down to them… finding this stuff on the internet is difficult at best.

[ScottKeymaster]

Glad you got it sorted. Just to confirm, when “Validate Built Product” was set to yes, were both Debug and Release builds working for you?

The ScanSound file should be sorted now automatically when using Cocoapods.
Thanks for the suggestion on adding methods for specific APDU commands, it’s something that makes sense for us to expose to users as you may not want NDEF messages.
Let us know if you have any more issues and we’ll be happy to help.
Scott

[Author]

Posts