Help: Unable to recover sector keys on genuine MIFARE Classic EV1 with Proxmark3

[Heisenbug]

Hello everyone,

I am trying to recover the keys of a genuine MIFARE Classic EV1 card using my Proxmark3, but I am running into several issues and I need guidance. Here is a detailed description of what I have tried so far:

---

Card detection

hf search 

• Result: MIFARE Classic 1K detected.

• UID detected correctly.

---

Initial attempt with hf mf autopwn

hf mf autopwn

• Detected the card as MIFARE Classic EV1.

• Loaded 5 user keys and 61 hardcoded keys.

• Targeted sectors 0, 16, 17 successfully and found some valid keys:

  • Sector 0 Key A: A0A1A2A3A4A5

  • Sector 16 Key A: 5C8FF9990DA2

  • Sector 16 Key B: D01AFEEB890A

  • Sector 17 Key A: 75CCB59C9BED

  • Sector 17 Key B: 4B791BEA7BCC

• Attempted further attacks on other sectors but encountered repeated errors:

[#] AcquireEncryptedNonces: Can't select card (UID)
[#] AcquireEncryptedNonces: Auth1 error
[-] No match for the First_Byte_Sum (127), is the card a genuine MFC Ev1?

---

Hardnested attack attempts

• Commands used:

hf mf hardnested --blk 0 -a -k A0A1A2A3A4A5 --tblk 1 --ta
hf mf hardnested -r --tk A0A1A2A3A4A5 --i2

• Observations:

  • PM3 successfully detected the EV1 card and loaded nonces from file.

  • Attack tried all guesses for Sum(a8) with bitflip properties applied.

  • None of the attempts recovered the key for sector 1.

  • Final result:

[-] Failed to recover a key...

• All logs indicate Auth1/Auth2 errors and inability to select the card for certain operations.

---

Attempts at brute-force with user/hard keys

• I have tried loading user keys and hard keys files with hf mf setuserkeys and hf mf sethardkeys.

• Commands like:

hf mf autopwn --blk 1 --ta
hf mf autopwn --blk 1 --tb

• The brute-force attempts with known keys did not succeed.

• Likely cause: genuine EV1 uses random keys per sector, and software-only attacks cannot derive them.

---

Side-channel consideration

• I understand that software attacks fail on genuine EV1.

• I am aware that side-channel attacks (power analysis, EM analysis, or fault injection) are theoretically effective but require additional lab equipment (and i dont have it).

---

Summary of the problem

• Sectors like 0, 16, 17 are readable with known keys.

• Sector 1 (and likely others) cannot be accessed: all hardnested, nested, or brute-force attacks with keys known online fail.

• PM3 errors observed:

  • Auth1 error / Auth2 error len=1

  • Can't select card (UID)

  • Failed to recover a key

• Goal: Recover keys for sector 1 (and possibly others) of a genuine EV1.

---

Questions / Help requested

1. Is there any software-only method to recover sector keys on a genuine EV1?

2. Are there special tricks or advanced PM3 features that I might not be aware of?

3. Don’t tell me the only option is to do a side-channel attack (or attacks that include other hardware) because I don’t have the tools and I’m broke asf .

Thank you in advance for your guidance!

[Aoxhwjfoavdlhsvfpzha]

You might try re-running autopwn with a dictionary:

hf mf autopwn -f mfc_default_keys

If that doesn’t work you may be able to sniff the keys from the reader, here’s some more info:

Dealing with MIFARE Classic 1k static encrypted nonces (Sniffing w/Proxmark 3 Easy)

Version Used This comes up now and again and has been sorted on the forum but I found a method that I feel is quite clear. I ran into this when playing with the SwitchBot Keypad. So, if you see this: [Screenshot 2024-05-06 112821] Follow these steps: Put the tag on your proxmark and run the following command hf 14a sniff Scan the tag with the reader while its up against the proxmark. Let it register a few times for good measure then press the button on the side of your proxmark to stop th…

[Iceman]

the output from the following commands is very helpful when trying to understand:

hf 14a info
hf mf info

Normally with a genuine NXP MIFARE Classic 1K Ev1, you can try

• Distance between tag and antenna
• slow parameter, hf mf autopwn --slow

[Heisenbug]

Hi, thanks for the suggestions. I’ve tried re-running hf mf autopwn -f mfc_default_keys as well as using the --slow parameter, but it just keeps running for hours without finding any keys.

[Heisenbug]

I’ve also checked the outputs from:

hf 14a info
hf mf info

but that hasn’t helped me identify the missing keys.

Using brute-force, I’ve only managed to recover 5 keys out of 32 sectors so far.

Basically, I’m trying to do a full dump of a genuine NXP MIFARE Classic 1K EV1, but I need a reliable way to find the remaining keys for the protected sectors. Any advice would be greatly appreciated.

[Iceman]

That was me who wanted to see the output of those commands.

[Heisenbug]

Sorry I didn’t understand, anyway, here it is.

[Iceman]

hf mf autopwn should do the trick.

try some distance between tag and antenna

[Heisenbug]

I tried 2 times with the command hf mf autopwn --slow, and both times after some time it crashes.

after a while…

[Iceman]

tried some distance between tag and antenna?

and try the mfc_default_keys option to autopwn aswell.

you seem to have MFC card with a MAD on it.

[Heisenbug]

It worked, thanks. The first attack I did with autopwn didn’t work because I was trying different positions during the attack, to see where was more signal. Then I tried hf mf autopwn --slow with the tag under pm3 (where there was more signal) and it worked, giving all the keys successfully. Thanks again for your help!

[Heisenbug]

Hello again!
After running hf mf autopwn on a test card, the software detected 71 blocks, but when I exported the dump, using hf mf dump, it only showed 64 actual blocks.

How is it possible that blocks beyond the tag’s physical capacity are displayed? I understand that autopwn probably also displays virtual or control blocks to analyze sector patterns and authentication, but I’d like to better understand what they represent and whether they have any real role in reading/writing the tag. To clone it perfectly so that it functions like the original, do I need to include those blocks as well?