Maybe found a card disguising it self as a mifare classic 1k 14443-A tag or I'm missunderstanding something, please advice

Zkink · February 11, 2024, 10:06pm

I was trying to clone my work badge to my newly installed xMagic but I’ve run into a few snags, just goes to show that the Proxmark3 is an awesome tool that should be used before ordering and installing implants, story time.

So I had a thought of cloning the access badge for work out of convenience and cool to have, since I got my flipper a while ago I’ve been diving more and more into a lot of things, anyhow, either I’m missing something or the flipper isn’t as capable yet in the ways of NFC reading as one could want it to be, Proxmark3 reigns supreme.

So neither with the flipper or MCT app could I read that my “clearly” work badge was anything else than a mifare classic 1k 14443-A tag, 1024 byte and 16 (0-15) sectors.
We got the 0-15 sectors and everything looks great, the xMagic was perfect with it’s capabilities and T5577 for emulating the RFID part as well, hence I ordered and have now installed it with help of a professional.

Everything is healing well and feels ok, no issues there.

That’s untill I tried cloning the badge onto my xMagic, when writing the cloned work badge, I saw that it was missing 2 sectors from my dump of the existing badge, 16 and 17 (18 in total).

Running “hf mf info” generated this output:
[=] — ISO14443-a Information ---------------------
[+] UID: XX XX XX XX [detected but hidden by me]
[+] ATQA: 00 04
[+] SAK: 08 [2]
[=]
[=] — Tag Signature
[=] IC signature public key name: NXP MIFARE Classic MFC1C14_x
[=] IC signature public key value: [got it but hidden by me]
[=] Elliptic curve parameters: NID_secp128r1
[=] TAG IC Signature: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX [got it but hidden by me]
[+] Signature verification: successful

[=] — Keys Information
[=] [0] key FF FF FF FF FF FF
[+] loaded 1 keys supplied by user
[+] loaded 61 keys from hardcoded default array
[+] Sector 0 key A… FFFFFFFFFFFF
[+] Sector 0 key B… FFFFFFFFFFFF
[+] Sector 1 key A… FFFFFFFFFFFF
[+] Block 0… [got it but hidden by me]

[=] — Magic Tag Information
[=] <N/A>

[=] — PRNG Information
[+] Prng… hard

So when I did clone it with the “hf mf autopwn” I at first didnt react to the two extra sectors for key A and B until I wrote it to my xMagic, did a clone of my implant and compared the two results out of habit.

A little googling led me to the github thread: Tag RFID 1K with 16 & 17 sectors · Issue #1010 · Proxmark/proxmark3 · GitHub

Where they had a similar issue and tried “hf mfp info” to see that they had a SL1 card on their hands, so I tried it my self and got this output:
[=] — Tag Information ---------------------------
[!!] No card response

[+] UID: XX XX XX XX [detected but hidden by me]
[+] 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: [detected but hidden by me]
[=] Elliptic curve parameters: NID_secp128r1
[=] TAG IC Signature: [detected but hidden by me]
[+] Signature verification: successful
[?] Hint: try hf mf commands

[!!] No card response
[=] — Fingerprint
[=] Size… 2K (4 UID)
[=] SAK… 2K 7b UID
[=] — Security Level (SL)
[+] SL mode… SL1
[=] SL 1: backwards functional compatibility mode (with MIFARE Classic 1K / 4K) with an optional AES authentication

They suspect that in their case it’s a “Mifare Plus EV1 Desfire 2k” tag in reality, but acting like a mifare classic 1k.

I went back to both my flipper and MCT on my phone, verified that they did not see this at all but the 1024 byte data and 16 sectors.

Have I stumbled upon something similar here?
Any comment is appreciated so I can understand what I’m working with here, and it’s ok to call out something completley obvious since I’m still learning my ways around this.

amal · February 11, 2024, 10:24pm

can you scan with taginfo ? my hunch is it may be a smartcard with mifare classic emulation turned on

Zkink · February 12, 2024, 5:28am

Yeah, here is the info I got using a pixel 7.

** TagInfo Scan (version 4.29.0) 12-feb.-24 06:20:53 **
Report Type: – IC INFO ------------------------------

IC Manufacturer:

NXP Semiconductors

IC Type:

MIFARE Classic EV1 (MF1S50)

– NDEF ------------------------------

No NDEF Data Storage Present:

Maximum NDEF storage size after format: 716 bytes

– EXTRA ------------------------------

Memory Information:

1 kB

16 sectors, with 4 blocks per sector
64 blocks, with 16 bytes per block

IC Information:

Full product name: MF1S503xX/V1

Block 0 analysis:

UID: XX XX XX XX [detected but hidden by me]

NXP Semiconductors
Re-used (Old) Non-Unique ID
Check Byte: 0x47
SAK: 0x88
ATQA: 0x0400
Manufacturer data:
C8 44 00 20 00 00 00 22 |.D. …"|
- Revision: C8
- Fab: TSMC
- Production date: week 44, 2022
  ~ PQE0/1: 44 22

Originality Check (asymmetric):

Signature verified with NXP public key

TagInfo Version:

Version :4.29.0

Device Info:

Device Model :Google ( Pixel 7 )
Android OS Version :14

– FULL SCAN ------------------------------

Technologies Supported:

MIFARE Classic compatible
ISO/IEC 14443-3 (Type A) compatible
ISO/IEC 14443-2 (Type A) compatible

Android Technology Information:

Tag description:

TAG: Tech [android.nfc.tech.NfcA, android.nfc.tech.MifareClassic, android.nfc.tech.NdefFormatable]
Maximum transceive length: 253 bytes
Default maximum transceive time-out: 618 ms

Detailed Protocol Information:

ID: XX XX XX XX [detected but hidden by me]
ATQA: 0x0400
SAK: 0x08

Memory Content:

Sector 0 (0x00)
[00] r-- BA C1 E0 DC 47 88 04 00 C8 44 00 20 00 00 00 22 |…G…D. …"|
[01] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[02] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[03] wxx FF:FF:FF:FF:FF:FF FF:07:80 69 FF:FF:FF:FF:FF:FF
Factory default key Factory default key (readable)

Sector 1 (0x01)
[04] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[05] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[06] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[07] wxx FF:FF:FF:FF:FF:FF FF:07:80 69 FF:FF:FF:FF:FF:FF
Factory default key Factory default key (readable)

Sector 2 (0x02)
[08] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[09] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[0A] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[0B] wxx FF:FF:FF:FF:FF:FF FF:07:80 69 FF:FF:FF:FF:FF:FF
Factory default key Factory default key (readable)

Sector 3 (0x03)
[0C] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[0D] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[0E] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[0F] wxx FF:FF:FF:FF:FF:FF FF:07:80 69 FF:FF:FF:FF:FF:FF
Factory default key Factory default key (readable)

Sector 4 (0x04)
[10] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[11] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[12] rwi 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
[13] wxx FF:FF:FF:FF:FF:FF FF:07:80 69 FF:FF:FF:FF:FF:FF
Factory default key Factory default key (readable)

Sector 5 (0x05)
[14] ??? – – – – – – – – – – – – – – – –
[15] ??? – – – – – – – – – – – – – – – –
[16] ??? – – – – – – – – – – – – – – – –
[17] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 6 (0x06)
[18] ??? – – – – – – – – – – – – – – – –
[19] ??? – – – – – – – – – – – – – – – –
[1A] ??? – – – – – – – – – – – – – – – –
[1B] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 7 (0x07)
[1C] ??? – – – – – – – – – – – – – – – –
[1D] ??? – – – – – – – – – – – – – – – –
[1E] ??? – – – – – – – – – – – – – – – –
[1F] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 8 (0x08)
[20] ??? – – – – – – – – – – – – – – – –
[21] ??? – – – – – – – – – – – – – – – –
[22] ??? – – – – – – – – – – – – – – – –
[23] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 9 (0x09)
[24] ??? – – – – – – – – – – – – – – – –
[25] ??? – – – – – – – – – – – – – – – –
[26] ??? – – – – – – – – – – – – – – – –
[27] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 10 (0x0A)
[28] ??? – – – – – – – – – – – – – – – –
[29] ??? – – – – – – – – – – – – – – – –
[2A] ??? – – – – – – – – – – – – – – – –
[2B] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 11 (0x0B)
[2C] ??? – – – – – – – – – – – – – – – –
[2D] ??? – – – – – – – – – – – – – – – –
[2E] ??? – – – – – – – – – – – – – – – –
[2F] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 12 (0x0C)
[30] ??? – – – – – – – – – – – – – – – –
[31] ??? – – – – – – – – – – – – – – – –
[32] ??? – – – – – – – – – – – – – – – –
[33] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 13 (0x0D)
[34] ??? – – – – – – – – – – – – – – – –
[35] ??? – – – – – – – – – – – – – – – –
[36] ??? – – – – – – – – – – – – – – – –
[37] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 14 (0x0E)
[38] ??? – – – – – – – – – – – – – – – –
[39] ??? – – – – – – – – – – – – – – – –
[3A] ??? – – – – – – – – – – – – – – – –
[3B] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

Sector 15 (0x0F)
[3C] ??? – – – – – – – – – – – – – – – –
[3D] ??? – – – – – – – – – – – – – – – –
[3E] ??? – – – – – – – – – – – – – – – –
[3F] ??? XX:XX:XX:XX:XX:XX --:–:-- – XX:XX:XX:XX:XX:XX
(unknown key) (unknown key)

r/R=read, w/W=write, i/I=increment,
d=decr/transfer/restore, x=r+w, X=R+W
data block: r/w/i/d:key A|B, R/W/I:key B only,
I/i implies d, *=value block
trailer (order: key A, AC, key B): r/w:key A,
W:key B, R:key A|B, (r)=readable key
AC: W implies R+r, R implies r

A thing I havent seen before is that it now read this:
MIFARE Classic compatible
ISO/IEC 14443-3 (Type A) compatible
ISO/IEC 14443-2 (Type A) compatible

So that would explain the two other sectors, but my phone couldn’t see them in the full scan mode.

Zkink · February 12, 2024, 5:32am

To be clear about the two extra sectors I was writing about, hf mf autopwn generated this:

Jirvin · February 12, 2024, 12:45pm

I believe the card you have is a genuine Mifare Classic Ev1 1k.

After various academic papers were published showing how vulnerable the original Mifare Classic was, NXP (the manufacturing company) released a ‘new and improved’ Mifare Classic that addressed the issues outlined in the academic papers.
Three key differences stand out:

7 byte UID
‘Hardened’ PRNG
On card signature

Shortly after the release of the ‘new and improved’ card came more academic papers showing that NXP didnt fix any of the original issues. Plus they were always hiding behind ‘security through obscurity’ which is terrible security design easily proven by the number of academic papers published on the subject.

The card/tag signature needs to be stored on the card somewhere but NXP didnt want to reduce the available customer accessible memory on its most popular card from 1k. Thus it added a little extra memory to house the functionality of the signature. This came in the form of two additional sectors added to the bottom/end of the existing 1k memory; which is what you are seeing as sector 16 & 17. We found these additional sectors, understood how they worked and added the signature validation to the proxmark client.

The extra two sectors was undocumented addition to the Ev1 cards and no datasheet acknowledges the existence of the additional two sectors. And, since this was an ‘improvement’ change that was backwards compatible, no access control systems were updated/configured to use the new signature feature as part of their access conditions. However, in present day there may be some new readers that are checking for a valid signature in addition to correct user access before deciding on access.

The one thing I was unsure about from your command outputs is whether the UID of the card was 4 bytes or 7 bytes. This is important as most magic cards have only 4 byte (N)UID but Ev1 cards should have a 7 byte UID. Meaning that youre not able to clone a 7 byte UID Ev1 to a magic 4 byte UID card.
Can you confirm if the source card has a 7 byte or 4 byte UID?

Zkink · February 12, 2024, 5:29pm

Thank you for explaining that!
And yes I have been wondering to, cause I get UID with 4 bites one way and 7 bite the other.

The different commands produce these different outputs:
hf mf info - UID: XX XX XX XX
hf mfp info - UID: XX XX XX XX
With — Fingerprint
[=] Size… 2K (4 UID)
[=] SAK… 2K 7b UID ← This I dont understand

Double checked taginfo app:
UID: XX XX XX XX

Same outcome as before.

And I think they use the two extra sectors at work in some way, cause I can let my self in through the door with the implant, but I can’t “clock in” at the reader by the door, once inside and clocked in, the implant works with all the doors it needs to work with, but not unless I have clocked in.

It’s still a partial win for me.

Jirvin · February 16, 2024, 12:15am

I wouldnt use the mfp command set since it’s very likely you’ve got a MFC this the mfp commands may produce false positives.

If taginfo and hf 14a info produce a 4 byte uid then I’d suggest it’s a 4 byte uid. Which is very odd as I’ve never seen a MFC with signature and 4B UID; I’ll double check some of my card to make sure.

Would you be able obtain a photo of the readers?
In particular, the ‘clock in/out’ reader and a door access reader.

You could be correct that one is performing some kind of signature check and the other isnt. Another possibility is that the clock in/out reader is writing a small amount of data to the genuine card which is checked at next clock in/out; like a form of CRC. I don’t think it’s this as we could easy check card dumps before the start of work day and end. Plus, the cloned card is less likely to work for the doors as it’s ‘outdated’ but those readers may not care for the CRC type data (may use UID only).

amal · February 16, 2024, 12:30am

actually you can take a chip like the pP60 or P71 and load the mifare classic emulator on it and it will read as a 4 byte UID and a mifare classic chip, and respond to all of the ISO14444A transponder commands you’d expect… But also it will respond to APDUs and you can use a series of commands to get the chip to report its “real” UID which is a full 7 bytes. I believe the command is the same that you would use to get a chip with the privacy mode randomized UID feature turned on to report its real ID.