Weird authentication behavior with Mifare Classic 4K

[vers4ce]

Trying to emulate a Mifare Classic 4K card. Although the sector trailer seems to be configured correctly, the auth fails (see below).

However, with a key FFFFFFFFFFFF it authenticates, as it shouldnt. This ofcourse leads to the card being rejected.

The first 32 sectors work fine, but have a key FFFFFFFFFFFF anyway by default.

Using both stock and latest firmware the issue was the same. Using the GUI to upload dump.

proxmark3> hf mf rdsc 33 A FFFFFFFFFFFF
--sector no:33 key type:A key:ff ff ff ff ff ff

isOk:01
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
trailer: b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11
Trailer decoded:
Access block 144+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 149+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 154+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 159: write A by B; read ACCESS by AB; write B by B
UserData: 5a
proxmark3> hf mf rdsc 33 A b67816f4a142
--sector no:33 key type:A key:b6 78 16 f4 a1 42

#db# Auth error
isOk:00
proxmark3>

[iceman1001]

lets take a step back.

1. you configured the chameleon mini how?
2. you used a proxmark3 to read a sector from a chameleon mini simulating 4k where FFFFFFFFFFFF works but the sector trailer data is wrong?

Seems like one of the two involved devices is wrong. Can you use another reader against the chameleon mini? like android phone with MCT?

[vers4ce]

Sorry for the missing information.

1. The Chameleon mini now runs stock firmware (used to run your latest firmware, same behavior) I got a dump from MCT, which i converted to .eml, .mfd, .bin using the MCT and proxmark3 scripts respectively. All same behavior. I wrote the dumps to the chameleon mini using the provided windows GUI. I inspected all three (eml, mfd, bin), they were perfectly fine. I tried to download them back from the chameleon and check them, they were as they should be.

2. Yes. I have a dump that has empty sectors with keys FFFFFFFFFFFF from sector 0 to 31. Then sectors 32 to 39 have different keys (the ones I show) with data on them. The one I show again is emtpy, but other sector have data.

The sector trailer seems correctly written in b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11. But when I try to read it with the key that is in the sector trailer, it doesnt auth. Instead it auths with an irrelevant default key (FFFFFFFFFFFF) that I found out while fiddling around. The original card doesnt have this behavior.

3. Unfortunately my phone doesnt read the Chameleon, MCT is really sketchy. It detects the UID and thats all. I tried to downgrade to stock firmware but it didn't solve the problem (as proposed elsewhere). I will try to commission a PN532 that I am currently using for an IFTTT switch but it may take some time.

I am pretty sure this is not a proxmark3 problem (although I cant prove it unless I can read it with a different reader, which might take some time).

Thank you for your time.

[iceman1001]

...did you compile and enable 4K support on the stock firmware? since thats not enabled...

[vers4ce]

I did compile the firmware on my own too. Do you have somewhere to point me to read about that? Because i could select 4K on the GUI and the

SETTINGS    += -DCONFIG_MF_CLASSIC_4K_SUPPORT

is enabled by default in your makefile. Do I need to do something more?

[vers4ce]

This is with the latest firmware I compiled from this repo today.

--sector no:32 key type:A key:b6 78 16 f4 a1 42

#db# Auth error
isOk:00
proxmark3> hf mf rdsc 32 B c9227efa0b11
--sector no:32 key type:B key:c9 22 7e fa 0b 11

#db# Auth error
isOk:00
proxmark3> hf mf rdsc 32 A ffffffffffff
--sector no:32 key type:A key:ff ff ff ff ff ff

#db# Auth error
isOk:00
proxmark3> hf mf rdsc 32 B ffffffffffff
--sector no:32 key type:B key:ff ff ff ff ff ff

#db# Auth error
isOk:00
proxmark3> hf mf rdsc 32 A 000000000000
--sector no:32 key type:A key:00 00 00 00 00 00

isOk:01
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
trailer: b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11
Trailer decoded:
Access block 128+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 133+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 138+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 143: write A by B; read ACCESS by AB; write B by B
UserData: 5a
proxmark3> hf mf rdsc 32 B 000000000000
--sector no:32 key type:B key:00 00 00 00 00 00

isOk:01
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
trailer: b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11
Trailer decoded:
Access block 128+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 133+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 138+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 143: write A by B; read ACCESS by AB; write B by B
UserData: 5a

Isnt it weird behavior, to address a command "read block with key A 000000000000" and return a key block "b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11"? I am putting it simplisticly, but you get what I mean.

[vers4ce]

And then this:

proxmark3> hf mf wrbl 142 A b67816f4a142 b67816f4a142f78f005ac9227efa0b11
--block no:142, key type:A, key:b6 78 16 f4 a1 42
--data: b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11
#db# Cmd send data2 Error: 03
#db# Write block error
isOk:00

Writes with the block specifically with the correct key. (it sent the command correctly, connection is very spotty for some reason, but you can see the "CMD send data2" that means it sent it)

It also:

proxmark3> hf mf rdbl 141 A b67816f4a142
--block no:141, key type:A, key:b6 78 16 f4 a1 42
isOk:01 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
proxmark3> hf mf rdbl 142 A b67816f4a142
--block no:142, key type:A, key:b6 78 16 f4 a1 42
isOk:01 data:b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11
proxmark3> hf mf rdbl 142 B 000000000000
--block no:142, key type:B, key:00 00 00 00 00 00
#db# Auth error
isOk:00

reads with the correct key and not the generic key that the sector is read by.

[vers4ce]

@iceman1001 Ok, I got it figured out. The last half of the mifare classic 4K is made up of 16-block sectors instead of 4-block sectors in the first half (and the 1K). The Chameleon Mini erroneously requires the first 6 bytes from the 4th block of the sector (that would be the trailer block IF it was a 4-block sector and not a 16-block sector).

proxmark3> hf mf rdsc 32 A f1f1f1f1f1f1
--sector no:32 key type:A key:f1 f1 f1 f1 f1 f1

isOk:01
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : f1 f1 f1 f1 f1 f1 aa aa aa aa f2 f2 f2 f2 f2 f2
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11
trailer: b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11
Trailer decoded:
Access block 128+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 133+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 138+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 143: write A by B; read ACCESS by AB; write B by B
UserData: 5a

Since the wrbl command also requires the wrong authentication bytes, I guess that this is a Chameleon Mini problem and not a proxmark3 problem

proxmark3> hf mf wrbl 131 A 000000000000 f1f1f1f1f1f1aaaaaaaaf2f2f2f2f2f2
--block no:131, key type:A, key:00 00 00 00 00 00
--data: f1 f1 f1 f1 f1 f1 aa aa aa aa f2 f2 f2 f2 f2 f2
#db# Cmd send data2 Error: 0c
#db# Write block error
isOk:00

[iceman1001]

Aha! Yup, i looked quickly in the code and verified it doesn’t take in consideration the 4K setting.
@bogiton @mceloff ? Feel like making a fix?

On 30 Jul 2019, at 07:31, vers4ce notifications@github.com wrote:

@iceman1001 Ok, I got it figured out. The last half of the mifare classic 4K is made up of 16-block sectors instead of 4-block sectors in the first half (and the 1K). The Chameleon Mini erroneously requires the first 6 bytes from the 4th block of the sector (that would be the trailer block IF it was a 4-block sector and not a 16-block sector).

proxmark3> hf mf rdsc 32 A f1f1f1f1f1f1 --sector no:32 key type:A key:f1 f1 f1 f1 f1 f1

isOk:01 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : f1 f1 f1 f1 f1 f1 aa aa aa aa f2 f2 f2 f2 f2 f2 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data : b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11 trailer: b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11 Trailer decoded: Access block 128+: read AB; write AB; increment AB; decrement transfer restore AB Access block 133+: read AB; write AB; increment AB; decrement transfer restore AB Access block 138+: read AB; write AB; increment AB; decrement transfer restore AB Access block 143: write A by B; read ACCESS by AB; write B by B UserData: 5a — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[McEloff]

PR #107

[iceman1001]

@vers4ce A fix was merge, would you mind testing ?

[vers4ce]

@McEloff @iceman1001

I just tested it, implementing the memory offset for the larger sector apparently fixed it. Thank you.

proxmark3> hf mf rdsc 32 A b67816f4a142
--sector no:32 key type:A key:b6 78 16 f4 a1 42

isOk:01
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : f1 f1 f1 f1 f1 f1 a0 a0 a0 a0 f2 f2 f2 f2 f2 f2
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
trailer: b6 78 16 f4 a1 42 f7 8f 00 5a c9 22 7e fa 0b 11
Trailer decoded:
Access block 128+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 133+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 138+: read AB; write AB; increment AB; decrement transfer restore AB
Access block 143: write A by B; read ACCESS by AB; write B by B
UserData: 5a
proxmark3> hf mf rdsc 32 A f1f1f1f1f1f1
--sector no:32 key type:A key:f1 f1 f1 f1 f1 f1

#db# Auth error
isOk:00