Proxmark3 community

adelie

Contributor

Registered: 2021-10-26

Posts: 6

Trouble reading a MFC card

I have a stack of hotel keycards that I've saved from traveling over the last few years. I recently got a Proxmark3 and decided to have a look at them to see what I can learn.

Most of the Mifare Classic cards I have are pretty straightforward.  But I ran across a few where I am having trouble reading the data, even with what I believe is a valid keyB.

Here is an example.

[usb] pm3 --> hf 14a info

[+]  UID: A2 C4 E9 83 
[+] ATQA: 00 04
[+]  SAK: 08 [2]
[+] Possible types:
[+]    MIFARE Classic 1K
[=] proprietary non iso14443-4 card found, RATS not supported
[+] Prng detection: hard
[=] 
[=] --- Tag Signature
[=]  IC signature public key name: NXP Mifare Classic MFC1C14_x
[=] IC signature public key value: 044F6D3F294DEA5737F0F46FFEE88A356EED95695DD7E0C27A591E6F6F65962BAF
[=]     Elliptic curve parameters: NID_secp128r1
[=]              TAG IC Signature: 1A025FADD1CCC6BE0503EE2E1D2679494F426E139949ED9B4A3407366360DA6A
[+]        Signature verification: successful
[?] Hint: try `hf mf` commands

Okay, a regular MFC 1k.

usb] pm3 --> hf mf autopwn
...
[=] Chunk: 2.0s | found 18/32 keys (23)
[+] target sector   0 key type B -- found valid key [ FFFFFFFFFFFF ] (used for nested / hardnested attack)
...
 time    | #nonces | Activity                                                | expected to brute force
         |         |                                                         | #states         | time 
------------------------------------------------------------------------------------------------------
       0 |       0 | Start using 4 threads and AVX2 SIMD core                |                 |
...
      27 |    1775 | (Ignoring Sum(a8) properties)                           |       441222848 |    0s
      28 |    1775 | Brute force phase completed.  Key found: e2744d1f22aa   |               0 |    0s
[+] target sector   0 key type A -- found valid key [ E2744D1F22AA ]

[+] found keys:

[+] |-----|----------------|---|----------------|---|
[+] | Sec | key A          |res| key B          |res|
[+] |-----|----------------|---|----------------|---|
[+] | 000 | e2744d1f22aa   | H | ffffffffffff   | D |
[+] | 001 | 2a2c13cc242a   | H | ffffffffffff   | D |
[+] | 002 | ffffffffffff   | D | ffffffffffff   | D |
[+] | 003 | ffffffffffff   | D | ffffffffffff   | D |
[+] | 004 | e2744d1f22aa   | R | ffffffffffff   | D |
...

And autopwn works to recover all of the keys, great.

Now, here are the access rights for sector 0:

[usb] pm3 --> hf mf rdbl --blk 3 -v -k E2744D1F22AA

[=]   # | sector 00 / 0x00                                | ascii
[=] ----+-------------------------------------------------+-----------------
[=]   3 | 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF | .........i......

[=] ----------------------- Sector trailer decoder -----------------------
[=] key A........ 000000000000
[=] acr.......... FF0780
[=] user / gpb... 69
[=] key B........ FFFFFFFFFFFF

[=]   # | Access rights
[=] ----+-----------------------------------------------------------------
[=]   0 | read AB; write AB; increment AB; decrement transfer restore AB
[=]   1 | read AB; write AB; increment AB; decrement transfer restore AB
[=]   2 | read AB; write AB; increment AB; decrement transfer restore AB
[=]   3 | write A by A; read ACCESS by A write ACCESS by A; read B by A; write B by A
[=] ----------------------------------------------------------------------

Shows all 00 for keyA, but that's fine as we know the actual keyA is E2744D1F22AA from cracking earlier.

According to this, I should be able to read blocks 0-2 with either keyA (E2744D1F22AA) or keyB (FFFFFFFFFFFF).

But this is what actually happens:

[usb] pm3 --> hf mf rdbl --blk 0 -v -b -k FFFFFFFFFFFF
[#] Cmd Error 04
[#] Read block error

KeyB fails.

[usb] pm3 --> hf mf rdbl --blk 0 -v -a -k E2744D1F22AA

[=]   # | sector 00 / 0x00                                | ascii
[=] ----+-------------------------------------------------+-----------------
[=]   0 | A2 C4 E9 83 0C 88 04 00 C8 24 00 20 00 00 00 18 | .........$. ....

KeyA works.

Any thoughts on why?  I have about 5 that act like this and probably 20+ that work exactly as expected, allowing me to read with either key.

iceman

Administrator

Registered: 2013-04-25

Posts: 9,537

Website

Re: Trouble reading a MFC card

interesting,  don't look like a genuine block0 from NXP.

14a usually needs some distance between card and pm3,  so it could be bad coupling when running the commands.

adelie

Contributor

Registered: 2021-10-26

Posts: 6

Re: Trouble reading a MFC card

I don't think it is bad coupling.  It happens consistently with a few cards from my collection, and they read just fine when I use KeyA.  If it were a coupling problem, I would think it would happen regardless of which key was being used.

Can you think of anything I could do to test this further or get more information to share?