Key 000000000000

[alfs]

There's something strange with key 000000000000, probably in relation to specific phone models (I'm using a Z3 Compact, which works fine otherwise with regards to mifare operations).

I have a factory new, standard mifare 1k tag, with default access conditions (all F's.).
It can be read with a keyfile consisting of two keys:
FFFFFFFFFFFF
000000000000

However if I reverse the keys:
000000000000
FFFFFFFFFFFF

then MCT now reports the key as being 0s, not Fs.
If swap the last digit from a 0 to a 1, then the F key is found correctly.

Even more strange:

I saved a dump of a reading with 0 keys, and write it back to the card, i.e., access key is 000000000000 for A and B for all sectors. Now I cannot read it back (no valid keys found). So I try changing the order in the keyfile (first F, then 0), some other variants, no luck, card cannot be read.

Using another phone, same MCT version, the card can be read using key 0, then reprogrammed using key F, and then read by the first phone again.

MCT version 2.0.4, first phone is Xperia Z3 Compact, Android 5.0.2 (21.1.A.1.28) which had problems.

Working phone was MCT 2.0.4, Samsung Galaxy S3 (i9300), Android 4.4.4 (CM11-M12) which worked OK.

It would be interesting to hear if other Z3/Z3C users experience the same. Simple test is to just use a keyfile with 0's, and try reading a card programmed with F-keys.

[alfs]

Interestingly the Hagenberg NFC TagInfo tool is also unable to read sectors with key 0, but works fine with key F after rewriting on the Galaxy S3. So it seems to be a phone model issue in combination with a specific key.

[ikarus23]

... Aaaand another strange issue with the Z3 :). There is definitively something wrong with this device/rom...
Maybe it is somehow related to issue 64. Could you try the testing version of issue 64?

However, this is really a strange issue. I think I heard of another user having the same trouble. Hopefully we can track this down.

[alfs]

I tested the testing version, it still had the same problems as described, although I noted that it sometimes was successful identifying the F key. It was never able to read a sector with 0 key though.

[ikarus23]

Hi there, I'm found a little bit of time for looking into unsolved issues ;)
Therefore: Are the issues still present within the latest software version?
Android 6.0 (Marshmallow) was release this moth for the Z3 Compact.

[raitoX]

I am facing this issue as well. Z5 Compact, Android 6.0.1 (Marshmallow).
It can't seem to read sector with 000000000000 key, and sometimes misidentifies FFFFFFFFFFFF key as all 0s.
No issue with Z1 Compact, Android 4.4.
Edit:
Upon further testing, it seems i can so far avoid this issue by removing 000000000000 from the keyfile.

Summary:

1. Not able to read blocks with key 000000000000 at all. (even when keyfile only has 000000000000)
2. Sometimes displays key FFFFFFFFFFFF as 000000000000, when keyfile has the both keys.
3. (number 2) also happens when both is split into 2 different keyfiles and selecting those 2 keyfiles when reading card.
4. Displays key FFFFFFFFFFFF correctly when keyfile does not include 000000000000.

[ikarus23]

Some news from #129:

It looks like having issues with Mifare Classic on a Xperia device is nothing new: https://forum.xda-developers.com/xperia-z2-tablet/help/mifare-classic-support-z2-t2874883

It would be really interesting to see if this issue is fixed in CyanogenMod / LinageOS >= 13.x. @ArchangeGabriel reported in #127 that CM fixes the Mifare Classic compatibility issues on the OnePlus One. Maybe it's the same here.

[tomvleeuwen]

I experience exactly the same issue with my LG G4 (h815) (can't read sectors with all-0 key, sometimes all-0 key is displayed i.s.o. FFFFFFFFFFFF when both are included in keyfile).
I am running the latest LineageOS nightly build (30-05-2017).

Additionally, if I only have the all-0 key in my keyfile, I can succesfully read sectors with key FFFFFFFFFFFF. It always shows the all-0 key in that case. Therefore, it seems to me that somewhere Android or the NFC chip is mapping the all-0 key to the all-1 key.

[ikarus23]

This really sounds like an Android/NFC-Stack related issue, not MCT...

[ikarus23]

According to #129 this is an Android issue that was fixed by some vendors. Does anyone of you have any news on that?

[tomvleeuwen]

On the latest release of LineageOS on my G4, this bug is still present. Same behavior is present in NFC TagInfo and RFID NFC Tool (Unable to read sector with all-zero key, all-zero key can be used to read sector with all-f key)

[ikarus23]

Hmpf. Too bad.

[mrlmj]

I meet the problem too. Thanks to the issue, I save my card back by using another phone.

[moliata]

Exactly the problem I had. It seems that sometimes reading the card it randomly shows that key is 0000... instead of FFFFFFF, while this happens like 2 times in a 100 tries, it does happen. Afterwards, writing the dump to another card it makes it impossible to read it. As well, I have thought that I just broke 4 tags, but as others said, with an Android 4.4 phone I can revert changes.
EDIT: I have Google Pixel 2 with Android Pie.

[lss4]

It seems I got myself caught into this bug as well, and probably the M1 part on my brand new JAKCOM R3 ring is now permanently broken because of this. I'm using Sony Xperia XZ Premium (G8142, 47.2.A.6.30, stock Android Pie) with the latest version on F-Droid.

I did have some simple readers but they couldn't connect to the M1 part of the ring probably due to the ring's small antenna. My phone's NFC contact is the only one where it could be detected and accessed.

Before writing it was accessible and the write operation succeeded without reporting any errors. After writing and trying to read it again, the app said no keys are found (after taking a long while). Apparently the dump file I wrote showed all 0 keys and was incomplete. It was missing the 4th sector (that sector was encrypted with something else which is irrelevant to this issue), so that sector was not written to and could still be read. It seems from the read results the app is getting different keys on the still readable sector, being either all 0 or all F.

Reading on the source card also yielded different keys. With a keyfile like this, it has a 50/50 chance of getting either all 0 or all F keys from the source card (on readable sectors). Precisely, if this time I get all 0, the next time I'll get all F, and the third time I'll get all 0 again. Now I'm worried about what I've really written to my ring (now that I couldn't read anything from it I can never know)...

000000000000
FFFFFFFFFFFF

Right now I'm more concerned about how to revert the ring's sectors to the original state and start over...

EDIT: I tried NXP TagInfo and on the untouched sector of the ring (and also the unencrypted sectors on the source card) it always returned all F keys (the sectors programmed using all-zero keys remained inaccessible). It's likely that on some devices, an all-zero key bear a different meaning.

EDIT 2: Regarding the comments that CM/Lineage has fixed the issue (on some other devices)... is there any commit we can look at to see how the issue was fixed there? Since there's no custom Android Pie ROM out for XZ Premium yet I don't think I can test it myself for now.

EDIT 3: Was able to recover and perform a full clone of the ring's M1 using ACR122U. Now the sectors have all F keys and can be read by MCT. When using ACR122U, the "unreadable" sectors were indeed having all 0 keys.

[ikarus23]

Some devices seem to have issues with keys being all 0/F. Until now I don't know if there is anything I can do. I think some part of the Android ROM is broken (NFC driver?). I'm happy to hear you were able to recover your ring with an ACR122u.

[tomvleeuwen]

Is it not possible to just ignore the key that was used to unlock the sector and read the keys directly (when allowed by the access bits)?

[ikarus23]

You can never read key A. And if you can read key B it can not be used as key (it is considered user data then).

[tomvleeuwen]

To work around this issue, you could always try the default all-1 key before trying the all-0 key, even if the all-1 key is not in the keyfile. If a phone suffers from the issue, it won't be able to read the card anyway if the key is all-0, so it will always correctly show the all-1 key.

If the phone doesn't suffer from the issue, it will also work correctly except that it might show the all-1 key even though it's not in the keyfile.

I understand that this is a dirty hack, so just consider it and decide for yourself if you think worth implementing. You could also add a comment in the COMPATIBLE_DEVICES.md.

[ikarus23]

So do I get you right: as long as the key FFFFFFFFFFFF is tested before the key 000000000000 devices with this issue are able to operate correctly (except for tags with 0 keys)? If so, it might be a dirty hack but I think I'm willing to implement it.

[ikarus23]

Also, what about a tag with all keys e.g. AAAAAAAAAAAA? Is it important for the key file to be

AAAAAAAAAAAA
000000000000

and not

000000000000
AAAAAAAAAAAA

?

In other words: Do I have to read the key 000000000000 always last or is it sufficient to read the key FFFFFFFFFFFF fist?

[tomvleeuwen]

I will conduct some experiments let you know my results. It's been a while since I was playing with this issue. But I'm quite sure only the all-zero key is problematic.

[ikarus23]

Thank you. I really appreciate it. I can easily change the key order. If the all-zero key has to be last, it should be easy to do. However, it does slows down the mapping process for tags with all-zero keys and a large key file.

[tomvleeuwen]

Hi,

Here are my test results (only 1 key in keyfile):

Situation     | Card Key     | Keyfile key  | Result         |
--------------------------------------------------------------
A: Read using | FFFFFFFFFFFF | FFFFFFFFFFFF | Read OK        |
all-1 key     |              |              |                |
--------------------------------------------------------------
B: Read using | FFFFFFFFFFFF | 000000000000 | Read OK, but   |
all-0 key     |              |              | zero-key shown |
--------------------------------------------------------------
C: Read card  | 000000000000 | 000000000000 | No keys        |
with 0-key    |              |              | found          |
--------------------------------------------------------------
D: Read card  | 000000000000 | FFFFFFFFFFFF | No keys        |
with 0-key (2)|              |              | found          |
--------------------------------------------------------------

I only tested key A and have the access bits left to default (FF078069).
Any other key just works as expected. I could not find any other key where MiFare Classic Tool would not behave as expected.

I can't force NFC TagInfo to use key 000000000000, but in the other cases it behaves the same as MiFare Classic Tool.

Writing works correctly with the 000000000000 key (it writes the 000000000000 key to the card).

The main problem is that if situation B occurs, and someone saves the dump to a file (now falsely containing the 000000000000 key) and writes the file back to the card, it will jump to situaion C and people will think the card is broken.

I think you don't have to use key 000000000000 at last, just make sure you use it after testing key FFFFFFFFFFFF.

So my suggestion would be:

If key 000000000000 is in the keyfile, always prepend it with FFFFFFFFFFFF, even if it is not in the keyfile at all. In that case, situation B can never occur since you have already found the correct key if the card indeed has key FFFFFFFFFFFF. If the card does not have key FFFFFFFFFFFF, reading always works as expected, except when the card has key 000000000000 which is simply not readable by phones that suffer from the issue. For people with correctly working phones, it just means that MiFare Classic Tool will try key FFFFFFFFFFFF even if it is not in the keyfile.

If you want me to do some more testing, just let me know what you'd like to have tested.

[ikarus23]

I've implemented your suggestions and build a testing version. Can you try it?

[ikarus23]

Also, after all these years I've managed to reproduce this issue. However, I don't think it is the device. It's the tag! I have exactly one tag which can be read with key 000000000000 even though the key is FFFFFFFFFFFF. I never saw something like this. Maybe it's a cheap clone.

For me, the testing version fixes the faulty behavior of the tag.

[tomvleeuwen]

I first tested the old version with a couple of tags. In my case, the issue is not in the tag. I can reproduce it with an original MiFare 1K, a 7-byte UID Mifare 1K with signature, a UID writeable 1K and a Infineon SLE-77 in Mifare 4K emulation (Dutch OV-chipcard, entirely unreadable by my phone since it uses the all-0 key for the 'unencrypted' sectors). And I can read and write the cards fine with libnfc and a cheap pn532 reader.

The new version seems to work as expected in most circumstances. It will return the FFFFFFFFFFFF key instead of the incorrect 000000000000. However, I found 1 case where it would alternate between the FFFFFFFFFFFF and 000000000000 for every next sector. The card has a random key for sector 0 and 1 (unreadable) and the FFFFFFFFFFFF key for every next sector (with default access bits). My keyfile only contains the 000000000000 key. Sector 2 (the first readable) shows the FFFFFFFFFFFF key, but the next sector shows 000000000000 as A-key. If I add another key to the keyfile, it works correctly.

[ikarus23]

Interesting. So it seams like the authentication count (amount of keys in key file) have something to do with this as well?!

[ikarus23]

Ok, I've succeeded in reproducing what you described. Don't know why it works if there are more keys present.

[ikarus23]

I found why my workaround did not work. And it's even worse. It cause the app to crash under certain circumstances. I will implement a better fix and release as soon as possible

[ikarus23]

The new workaround has be release with version 2.3.1. If it's not already on Google Play you can get it here. @tomvleeuwen Please tell me if it works.

[tomvleeuwen]

I tested it with my G4 and it works as expected, also with only 1 key in the keyfile. (It does not alternate anymore)

[ikarus23]

Great! In this case I will close this issue. There is nothing more I can do.