LG G3 Mifare Classic read failure

[PinkFreud]

With Metrodroid 2.9.29 (the latest as of yesterday, apparently), reading a Niagara Falls Adventure Pass (for the city of Niagara Falls, ON, CA) results in IOException: Transceive failed for each sector. Expanding any of the sectors results in Metrodroid force closing.

The card is a Mifare Classic 1k, and I've successfully dumped the card contents with mfoc. This dump is attached, along with a screenshot of the failed read.

My phone is an LG G3. Other NFC apps on this same device are able to read this card without issue.
Likewise, I'm able to use Metrodroid to read the contents of another Mifare Classic that I have - this issue appears to be solely limited to Metrodroid reading this specific card.

nfap.zip

[micolous]

The card you've attached uses a Mifare Application Directory (MAD) key, so that should just work. The error you're seeing looks like it's hitting an authentication failure. I found an issue in the authentication function where the wrong key was selected for MAD (it authenticated with Key B twice, instead of trying Key A), but this is probably not the root cause.

The normal Metrodroid authentication process is that it:

1. Tries the custom key for that sector up to 5 times.
2. Tries other custom sector keys.
3. Tries a key with all nulls as Key A and B.
4. Tries a key with all 0xFF as Key A and B.
5. Tries the MAD key as Key A and B.
6. Tries the NFC Forum key as Key A and B.
7. Repeats steps 2-6 an additional 4 times.

I've seen authentication and transceive failures where the card didn't accept the key, or when the card is just out of the field of the phone (because the case is too thick). But that you're able to read the data with other applications suggests that this isn't the root cause.

I have attached a key file which you can add to Metrodroid which only contains the MAD key, which is used in Key B according to the card dump you've supplied. This will cause Metrodroid to try authenticating with the MAD key first 6 times (retry_count + 1). Can you give it a try with this card, and see if this helps?

mad.farebotkeys.zip

If you get a permissions error, you'll need to allow Storage permission to the application manually. I've fixed that bug yesterday in the current master branch, but not published this to the Play Store yet.

[micolous]

Also curiously, I see multiple references that the LG G3 doesn't support Mifare Classic.

But those same sites say that the HTC M8 doesn't support Mifare Classic, when I have one that does.

shrug

[PinkFreud]

The G3 definitely supports Mifare cards:

I'll give the keys you attached to your previous post a try in the morning and let you know how it went.

[PinkFreud]

I was able to add the key successfully to Metrodroid, but IOException is still thrown when attempting to read the card afterwards.

The FC still occurs when attempting to expand any one of the sectors as well.

We can compare this with the behavior seen with the other two Mifare Classic cards that I have:
My MARTA Breeze card (also a Mifare Classic 1K, for Atlanta's public transit system) has all sectors locked. Metrodroid simply throws the 'Card is fully locked!' error for this card, with no IOException or FC.

I have an old hotel room key for a major chain hotel which only has sector 1 locked (which I was able to dump the keys for via mfoc, no less). Metrodroid detects this as a Bilhete Único card with R$0.00 remaining on it - apparently, the card ID matches that used by São Paulo's public transit system, which I have never visited nor used, but otherwise, it works fine with Metrodroid. :)

[micolous]

Alright, so your phone is definitely able to read the sectors on the card and not only identify them.

When you use the Niagara Falls card on other applications, you're able to see the content of the sectors as well, and not only the UID/ATQA/SAK?

The screenshot you're showing there only shows that a card was detected in the field, which is still a few steps before what Metrodroid tries to do.

You should be able to do this NXP TagInfo, and enable "full scan" in the settings, then you should see sector content like this:

https://lh3.ggpht.com/7HP2IrZXrU75ylrJHeuh3A9l9NnteVWzcSU-0j_DdSu4jgi-UIPJT0pCCuOiIo21PqQ=h900

As it uses the MAD keys you should be able to see sector content without adding anything else.

NFC TagInfo also tries to read the memory (see the "Memory Information"), but doesn't give an indicator as to what the error condition is (that'll be either "transceive failure" or "wrong key").

Regarding the Bilhete Único issue, they also use Mifare Classic cards. There is a standard way to declare what vendor the card is for, but many agencies don't implement this. It looks like it tries to detect manufacturer data being set to bcdefghi, which is a trait of Fudan Microelectronics FM11RF08 cards.

That's probably not the best thing to check up on, but as that's code from Farebot and I've never had one of those to test, I don't have a good way to improve that. It looks like this also would hit a few other places that use the Fudan cards.

I'll open up a new bug for that one.

[PinkFreud]

If you'd like, I can attach a dump of the hotel roomkey to the new bug.

As for NXP Taginfo, here's a screenshot. All 16 sectors show the same thing in this app:

Also, that tidbit about Futan Microelectronics is interesting. Thanks!

[PinkFreud]

Curious. I've entered key A into Taginfo, and it's still unable to read data from the sectors, despite recognizing the key. Perhaps it's something to do with the reader on this phone?

I was able to dump this card's data using a SPI/I2C/UART PN532 reader from Itead connected to a Raspberry Pi. I'll have to see if I can find my wife's card to see if it exhibits similar symptoms on my phone.

[PinkFreud]

One more note: My wife's phone, an LG G Stylo, exhibits the same behavior when reading this card.

[micolous]

The fact that NXP TagInfo has problem also suggests to me that there is an issue with either the NFC hardware or software stack on this phone.

I've had some phones be fussy about cards, sometimes the first authentication would fail, so I implemented a bunch of retry logic to help sort that out. But it looks like even this doesn't help.

Unfortunately, I don't think there's much I can do to resolve this issue for you.

You could manually side-load the card dumps using the mfcdump_to_farebotxml.py tool in "extras", but this is more for allowing you to test and develop new readers in the Android Emulator.

I suspect you've already tried these things, but common problems can include:

• a case on the phone being too thick (so the card is too far from the reader)

• the NFC antenna is damaged or not connected properly (particularly if the antenna is part of the back cover, and only attached with pins contacting pads)

• if the NFC antenna is part of the battery, some very convincing looking counterfeit batteries can include a poor quality antenna, or none at all. There are 6 blog posts here which tear down some counterfeit and genuine Samsung batteries in extreme detail.

[PinkFreud]

The NFC antenna on both of these phones are part of the back cover, not the battery. I haven't tried to remove the case yet, though the fact that every other NFC operation I try on here works with the cover (AndroidBeam, Mifare cards, NFC vicinity tags, etc) tells me I'm not liable to see a change if I remove the case - but I'll give that a try tomorrow in any case, as it's an easy test. :)

While software stack can be suspect here (we are both running stock LG images), I'm also noting that we're using different Android releases, and there's no guarantee LG modified the NFC stack from stock in any case. I wonder if we're just seeing LG's NFC reader misbehave with certain cards.

I'll update this bug report with the results of removing the case tomorrow. Otherwise, thank you for your assistance!

[micolous]

No worries.

Given that other cards work, I was thinking of it being more of a marginal thing -- you're getting a strong enough signal to interface with most cards, but not good enough for some lower quality cards.

[PinkFreud]

I've removed the case on my phone, but the read issue still persists. I think it's safe to call this a problem with LG's reader or software stack.