iCopy-X / iCopy-XS — HF Tag Families in Scope, Part 1: the MIFARE Family

1. Scope of this volume

This is the first of two HF-tag-families volumes in the iCopy-X series. It covers the MIFARE family — the NXP-and-imitator product line that, more than any other single technology, established what an HF RFID access card is. Vol 6 covers the rest of the HF landscape that the iCopy-X reaches: HID iCLASS Legacy / Elite / SE / SEOS, ISO 15693 tags (iCODE SLI / SLIX, Tag-it HF-I, Picopass for SE), FeliCa, and Legic. The split is by lineage, not by ISO standard: the MIFARE family is all ISO 14443A at the wire level (with the exception of DESFire which extends 14443A with its own application protocol on top), and the volume’s spine is the cipher and authentication mechanics each variant adds on top of that wire layer.

The reader is assumed to have read Vol 3 (the HF physics primer — ISO 14443A anticollision, the REQA / ATQA / SAK / UID exchange, the modulation scheme at 13.56 MHz). What this volume adds on top of Vol 3 is the authentication and crypto layer: what bits are on the card, how the reader proves it knows the keys, how those proofs leak information, and what the iCopy-X firmware does about all of that for the operator who just wants a clone.

The volume is structured as a tour of the family — Classic 1K, Classic 4K, Ultralight (three generations), NTAG, DESFire, Plus — followed by a deep treatment of the four key-recovery attacks the iCopy-X firmware implements (darkside, nested, hardnested, dictionary). The closing sections wire the attacks back into the cloning workflow: when does Auto Clone reach for which attack, when must the operator drop to Sniff mode, when is the card simply not cloneable on this device at all.

2. MIFARE — the family in 2026

MIFARE is NXP Semiconductors’ family of contactless smart cards, originating in the early 1990s under Mikron Graz (acquired by Philips Semiconductors in 1995, spun out as NXP in 2006). The brand covers a wide product range, but for our purposes the relevant axis is what authentication mechanism the variant uses to gate read/write access:

Variant	Year	Authentication	Approx. units shipped lifetime	iCopy-X clones?
MIFARE Classic 1K (MF1ICS50)	1994	Crypto1 (broken 2007)	>10 billion	Yes — fully, via dictionary / darkside / nested / hardnested
MIFARE Classic 4K (MF1ICS70)	mid-1990s	Crypto1 (broken 2007)	several billion	Yes — fully, same attacks as 1K
MIFARE Classic Mini (MF1ICS20)	2000s	Crypto1 (broken 2007)	hundreds of millions	Yes — same attacks
MIFARE Ultralight (MF0ICU1)	2001	None	several billion	Yes — trivial, no crypto
MIFARE Ultralight C (MF0ICU2)	2009	3DES (write-protect only)	hundreds of millions	Yes — read is unauth; write to magic blank works
MIFARE Ultralight EV1 (MF0UL11/21)	2013	32-bit PWD	hundreds of millions	Yes — unauth read; PWD-protected pages need key
NTAG 213/215/216	2013	32-bit PWD optional	several billion (NDEF NFC tags)	Yes — read; clone constrained by lock-bits
MIFARE Plus (SL1/SL2/SL3)	2008	AES-128 (or Crypto1 in SL1)	hundreds of millions	SL1 only — drops back to Classic-equivalent
MIFARE DESFire EV1/EV2/EV3	2008/2016/2020	3DES / 3K3DES / AES-128	billions	UID read only — encrypted content is opaque without keys

The headline observation: the MIFARE Classic family is end-to-end broken for any operator who can hold the card against an antenna for a minute. The crypto failed in 2007, the cloning workflow is mature, and the iCopy-X automates it into a push-button experience. The Ultralight and NTAG variants are even simpler — there is no meaningful crypto to break, only memory layout to copy. The Plus and DESFire variants are where modern crypto actually does what it is supposed to do, and the iCopy-X can copy the UID but not the application data; cloning those requires either key compromise through other channels (a stolen reader, a leaked HSM, a corrupted personalisation database) or moving to a different attack class entirely.

This volume’s load-bearing case is therefore the Classic. The other variants are either trivial (Ultralight, NTAG) or unreachable for cloning (DESFire, Plus SL2/SL3), and the prose volume tightens around them accordingly.

3. MIFARE Classic 1K — anatomy

The MIFARE Classic 1K (MF1ICS50) is the original mainstream MIFARE product. Released in 1994, it has been deployed in literally billions of cards: corporate badges, hotel keys, transit passes, university IDs, library cards, parking passes, vending-machine payment cards, gym memberships. As of 2026 NXP has been actively discouraging new deployments for nearly two decades — MIFARE Plus and DESFire are the official upgrade paths — but legacy 1K deployment continues at scale because every embedded reader installed before about 2015 supports it natively and the card stock is the cheapest credentialing technology on the market.

3.1 Memory layout

A Classic 1K has exactly 1024 bytes (hence “1K”) of EEPROM, organised as 16 sectors of 4 blocks of 16 bytes each:

Sector 0:                                                Sector 1:
  Block 0  [UID + manufacturer data, READ-ONLY]            Block 4  [user data]
  Block 1  [user data]                                     Block 5  [user data]
  Block 2  [user data]                                     Block 6  [user data]
  Block 3  [KeyA | Access Bits | GPB | KeyB]   ← trailer   Block 7  [KeyA | Access Bits | GPB | KeyB]   ← trailer
...
Sector 15:
  Block 60 [user data]
  Block 61 [user data]
  Block 62 [user data]
  Block 63 [KeyA | Access Bits | GPB | KeyB]   ← trailer

The last block of every sector is the sector trailer, a 16-byte structure with a rigid layout:

Offset	Length	Field
0–5	6 bytes	Key A
6–8	3 bytes	Access Bits
9	1 byte	General Purpose Byte (GPB)
10–15	6 bytes	Key B (or extension of user data when access bits permit)

The Access Bits encode the four-block sector’s read / write / increment / decrement permissions for each of Key A and Key B independently. The encoding is not intuitive — the three bytes encode the same logical permissions twice with one copy bit-inverted as a redundancy check — but for cloning purposes the operator does not usually need to manipulate Access Bits directly. The iCopy-X reads them, writes them, and unless the operator is deliberately trying to change a card’s access policy, leaves them alone.

3.2 Block 0 and the manufacturer block

Block 0 of Sector 0 is the manufacturer block and has a special meaning:

Offset	Length	Field
0–3	4 bytes	UID (the 4-byte serial number)
4	1 byte	BCC — XOR of bytes 0–3 (anticollision parity check)
5	1 byte	SAK (Select Acknowledge — type indicator)
6–7	2 bytes	ATQA (Answer to Request — Type A)
8–15	8 bytes	Manufacturer data (date code, lot, NXP-specific fields)

On a genuine NXP MIFARE Classic card, Block 0 is read-only, set at the foundry, and cannot be rewritten by any standard MIFARE command. This is the foundation of the “the UID cannot be changed” property that early access-control systems relied on for uniqueness. The MIFARE Magic chinese-clone family — Gen1a, Gen2, Gen3, Gen4 — breaks this property in different ways; that is the entire point of magic cards and the reason they exist. Vol 9 covers magic-card chemistry in operational detail.

For cloning purposes, the practical consequence is: an iCopy-X cannot clone a genuine MIFARE Classic 1K onto another genuine MIFARE Classic 1K, because the destination card’s UID is fixed at the foundry and will not match the source. The destination must be a magic card — and the iCopy-X firmware knows this and selects the appropriate write strategy (Gen1a’s backdoor commands, Gen2’s special block-0 write, Gen3’s APDU dialect) based on what kind of magic card is held against the antenna. The clone-to-genuine-NXP path is closed by physics and silicon, not by firmware.

3.3 The Crypto1 cipher

Each sector’s access is gated by two 48-bit keys, Key A and Key B, both stored in the sector trailer. To read or write any block in the sector, the reader must first complete a three-pass mutual authentication with the card, using one of the two keys, after which a Crypto1 stream cipher initialised from the authentication state encrypts every subsequent byte until the next anticollision cycle.

The authentication protocol, simplified:

1. Reader sends AUTH(sector, A_or_B).
2. Card responds with a 32-bit card nonce n_T (transmitted in cleartext on the first authentication of a session; encrypted with the running cipher state on subsequent re-authentications within a session — this distinction is what makes the nested attack work).
3. Reader generates a 32-bit reader nonce n_R, computes a 32-bit answer a_R = f(n_T) under the cipher, transmits n_R || a_R encrypted with the cipher’s keystream initialised from key || n_T || UID.
4. Card decrypts, verifies a_R, computes a 32-bit response a_T, transmits a_T encrypted.
5. From this point onward the cipher’s keystream is XORed with every byte in both directions.

The 48-bit key, the 32-bit nonces, and the cipher’s internal state together form what Crypto1 protects. The cipher itself is a 48-bit LFSR with a nonlinear filter function producing one keystream bit per shift, plus a feedback function mixing the LFSR state with the nonces. The full state is exactly 48 bits at all times.

For 1994, this was a defensible design. By 2007, every assumption it was built on had crumbled.

4. MIFARE Classic 4K and Mini

The MIFARE Classic 4K (MF1ICS70) extends the 1K to 4096 bytes by adding sectors with larger blocks. The memory layout is:

Sectors 0–31:    4 blocks of 16 bytes each       (same as 1K — 32 × 4 × 16 = 2048 bytes)
Sectors 32–39:   16 blocks of 16 bytes each      (8 × 16 × 16 = 2048 bytes)
                                                  total = 4096 bytes

The sector trailer in the larger sectors is the last 16-block region — same layout, same Key A / Access Bits / GPB / Key B. The Crypto1 cipher is identical; every attack that works on a 1K works on a 4K at the cost of needing to recover more keys (40 sector keys instead of 16). The iCopy-X firmware handles this transparently; the Auto Clone time budget is just longer.

The 4K is common in hotel-key applications (where the room and timeslot data live in dedicated sectors), transit cards in mid-sized cities, and university ID systems where the same card carries building access, library, meal-plan, and laundry-card functions in separate sectors. The sector segmentation is the architectural feature 4K deployments depend on — one application per sector, with its own pair of keys, so a hotel cannot accidentally read the library balance and vice versa.

The MIFARE Classic Mini (MF1ICS20) is a 320-byte variant: 5 sectors of 4 blocks of 16 bytes each. It appears in low-cost token applications — disposable event passes, single-room hotel keys. The iCopy-X handles it identically to a small 1K.

5. MIFARE Ultralight family

The Ultralight family is what NXP shipped when the customer needed contactless memory but did not need crypto: museum tickets, transit single-ride passes, event wristbands. Each Ultralight chip is built around an extremely small EEPROM array and the ISO 14443A wire layer; there is no sector concept, no Crypto1 cipher, and (in the original Ultralight) no authentication at all.

5.1 MIFARE Ultralight (MF0ICU1) — original

64 bytes total, organised as 16 pages of 4 bytes each:

Page 0:  UID bytes 0–2 + BCC0
Page 1:  UID bytes 3–6
Page 2:  BCC1 + internal + lock bytes
Page 3:  OTP (One-Time Programmable) — 32 bits
Pages 4–15: user memory, 48 bytes total

No authentication. No cipher. The reader sends READ(page) and gets four bytes back; sends WRITE(page, data) and the page is updated, subject to the lock bytes in Page 2 (which can be set to prevent further writes, irrevocably). The UID is split across Page 0 and Page 1 — bytes 0–2 in Page 0 with a BCC checksum, bytes 3–6 in Page 1.

Cloning an Ultralight onto a UID-writable blank is trivial: read all 16 pages, write all 16 pages to the destination, done. The iCopy-X completes this in under five seconds. The destination must support UID write (which standard NXP Ultralight chips do not — same Block 0 issue as Classic) so the blank stock is “UID-writable Ultralight clones” available from the same chinese supply chain as MIFARE Classic Magic cards.

5.2 MIFARE Ultralight C (MF0ICU2)

The Ultralight C adds 3DES write protection to the original Ultralight’s memory model. Memory expands to 192 bytes (48 pages of 4 bytes), with the last several pages serving as the authentication-key storage and the protection-pointer page. The 3DES key (16 bytes) protects writes — reads remain unauthenticated by default unless the card has been configured to require authentication for reads as well.

For cloning, the practical situation is: reads succeed without authentication, the iCopy-X dumps all the page contents, and writes to a magic Ultralight-C blank also succeed because the blank’s keys are still at the factory default (typically BREAKMEIFYOUCAN! ASCII, or all zeros, depending on the supplier). The 3DES is not broken in any cryptographically interesting way — it is bypassed by the fact that the operator is writing to a fresh blank whose keys haven’t been changed.

If the operator wants to re-secure the clone with the original card’s key, that’s a separate workflow that requires extracting the key from the source — which the iCopy-X cannot do, because that would require breaking 3DES, which is a different category of problem entirely. In practice, almost no Ultralight-C deployment uses the read-authentication option, and the write-authentication option is irrelevant to cloning because the clone is a fresh blank.

5.3 MIFARE Ultralight EV1

The Ultralight EV1 family — MF0UL1101 (48 user pages, 144 bytes) and MF0UL2101 (32 user pages, 80 bytes) — adds 32-bit password protection (the PWD mechanism) in place of the Ultralight C’s 3DES. The PWD model is simpler: a 4-byte password and a 2-byte response (PACK — Password Acknowledge). The reader sends PWD_AUTH(pwd) and the card replies with the PACK if the password matches; subsequent access to protected pages is then permitted.

PWD protection can be configured to gate reads, writes, or both, on a configurable per-page boundary (AUTH0 register). EV1 also adds counter pages — three 24-bit monotonic counters useful for ride-counting on transit applications where each tap decrements a balance.

For cloning, the iCopy-X reads the unprotected pages and the user-memory pages without authentication; the PWD-protected pages require the password, which is sometimes recovered by sniffing a legitimate reader-card transaction (the password is sent in cleartext on the air — the protection is access-control, not confidentiality), and sometimes recovered by dictionary attack against the typical EV1 default passwords (FF FF FF FF, 00 00 00 00, the card UID, the four ASCII bytes of the vendor name). The iCopy-X firmware automates the dictionary attempt as part of Auto Clone; if the dictionary fails, the operator drops to Sniff mode to capture a real reader’s exchange (Vol 7 §6).

6. NTAG family

The NTAG series — NTAG213, NTAG215, NTAG216 — is NXP’s NFC Forum Type 2 product line, architecturally an Ultralight EV1 variant optimised for NDEF (NFC Data Exchange Format) record storage and the smartphone NFC-tap use case. The user memory sizes:

Variant	User memory	Total memory	Typical use
NTAG213	144 bytes	180 bytes	NFC business cards, smart posters, URL tags
NTAG215	504 bytes	540 bytes	Larger NDEF payloads, simple amiibo-style tokens
NTAG216	888 bytes	924 bytes	Wider NDEF payloads, multi-record applications

All three use the same PWD mechanism as Ultralight EV1 (32-bit password + 16-bit PACK), the same lock-bit model, and the same per-page protection boundary (AUTH0). The differentiation is purely memory size and the NDEF-friendly default formatting NXP ships from the foundry.

The cloning situation for NTAG matches Ultralight EV1: the iCopy-X reads the pages, attempts dictionary on the PWD, writes to a magic NTAG blank or a Magic Ultralight EV1 (which supports the NTAG command set with the larger memory). The complication that recurs in NTAG deployments is lock bytes set after personalisation: many real-world NTAG cards (especially Nintendo amiibo, which use NTAG215) have the lock bytes set to make the card permanently read-only post-encoding. The iCopy-X can read the source, but writing to a destination that won’t accept the manufacturer-block changes requires a magic NTAG with explicit lock-bit-bypass capability, which not every supplier provides.

For NFC Forum applications — URL tags, smart posters, business cards — the NDEF content is the load-bearing data, not the card’s serial number, and cloning the content (without preserving the exact UID) is usually sufficient. For amiibo / token applications where the UID is part of the cryptographic identity, the operator needs the UID-writable magic NTAG and the firmware support to write the locked pages.

7. MIFARE Plus and DESFire — what the iCopy-X cannot clone

Both MIFARE Plus and MIFARE DESFire are NXP’s response to the Crypto1 break: contactless cards using modern crypto (AES-128 or 3K3DES) instead of the broken proprietary stream cipher. From the iCopy-X’s perspective, both are read-the-UID, encrypted-content-is-opaque territory.

7.1 MIFARE Plus

MIFARE Plus has three Security Levels:

Level	Authentication	Notes
SL1	Crypto1 (Classic-compatible)	Drops back to MIFARE Classic behaviour — same attacks work
SL2	AES-128 for authentication, Crypto1 for transport	Transition state; rare in deployment
SL3	AES-128 end-to-end	The intended modern mode

A Plus card in SL1 mode is effectively a MIFARE Classic 1K or 4K — same memory layout, same Crypto1 cipher, same vulnerabilities. The iCopy-X clones it identically to a Classic. The catch: a Plus card can be upgraded from SL1 to SL3 at any time by an authorised reader (with the AES master key). Many “Plus” deployments in the field are still running at SL1 because the integrator never finished the migration, and those clone normally; some have been upgraded, and those become DESFire-equivalent (the iCopy-X reads the UID, the rest is encrypted noise).

7.2 MIFARE DESFire

DESFire is architecturally different from Classic: it has a filesystem (Master File, Application files, Data files), per-application keys, ISO 7816-class APDUs on top of ISO 14443A, and a choice of 3DES, 3K3DES, or AES-128 for authentication depending on the EV generation:

Variant	Year	Crypto options
DESFire EV1	2008	3DES, 3K3DES
DESFire EV2	2016	3DES, 3K3DES, AES-128
DESFire EV3	2020	AES-128 (and stronger transaction MACs)

The authentication is a three-pass challenge-response using the symmetric block cipher in CBC mode with random nonces, with the keystream-leakage vulnerabilities of Crypto1 simply not present. Academic attacks exist against specific EV1 implementations (the 2011 Oswald / Paar side-channel paper on the EMS2 silicon, the 2016 Choudary differential-power-analysis paper) but those require physical access to a sacrificial card and lab-grade SCA equipment — not something an iCopy-X is doing in a hallway.

For cloning, the iCopy-X reads the UID (4 or 7 bytes, depending on the card’s UID-mode configuration), reads the AID list (which applications are on the card), and reads any public file metadata. The encrypted file contents are opaque without the application keys, and the iCopy-X has no facility for guessing or attacking those keys. In practice this means DESFire-protected access-control systems are not clonable with this device. The operator’s options are: obtain the keys through other means (a corrupted personalisation database, a leaked HSM, a stolen reader with the keys still loaded), or treat the DESFire deployment as out of scope for this engagement.

This is a genuine wall, not a “the iCopy-X happens not to support it” wall. Modern cryptographic primitives, used correctly, do what they are supposed to do.

8. The Crypto1 break — how MIFARE Classic fell

The story of how Crypto1 was broken is one of the cleaner case studies in the modern history of applied cryptanalysis, and the operational consequences live inside the iCopy-X firmware. The chronology and the technical points worth knowing:

8.1 The cipher under the hood

Crypto1 is a 48-bit synchronous stream cipher built around:

• A 48-bit Linear Feedback Shift Register (LFSR), with a primitive polynomial driving the feedback.
• A nonlinear filter function f that takes 20 bits from selected LFSR positions and produces one keystream bit per clock.
• An initial loading procedure that mixes the 48-bit key with the 32-bit card nonce n_T and the 32-bit UID, advancing the LFSR by 96 clocks during the authentication setup.

The cipher’s design was kept secret — security-by-obscurity — and licensed only as part of the MIFARE silicon. Through the 1990s and early 2000s the cipher’s internals were unknown outside NXP, and no public cryptanalysis was possible because there was nothing to analyse.

8.2 2007 — Nohl and Plötz, hardware reverse-engineering

At 24C3 (the 24th Chaos Communication Congress, December 2007), Karsten Nohl and Henryk Plötz presented “Mifare — Little Security, Despite Obscurity.” The technique was silicon reverse-engineering: they decapped MIFARE Classic chips, polished the die layer by layer, photographed each layer under a microscope, and traced the gate-level structure of the Crypto1 module by hand. The result was the first public reconstruction of the cipher’s LFSR taps and filter function.

Within hours of the talk, several groups had implementations. The cipher’s 48-bit keyspace, which had seemed irrelevant when nobody knew the structure, was suddenly the headline weakness: 2^48 brute-force is achievable on contemporary GPUs in a few days, and on dedicated FPGA clusters in hours. NXP’s defense had collapsed at the gate level.

8.3 2008 — the Radboud University team and “Dismantling MIFARE Classic”

The Radboud University Nijmegen team — Gerhard de Koning Gans, Flavio Garcia, Peter van Rossum, Ravindra Verdult, Roel Verdult, Wouter Teepe, and Jovan Sić — published “Dismantling MIFARE Classic” at ESORICS 2008. The paper did three things:

1. Confirmed the Nohl / Plötz reverse-engineering of the cipher against a fresh independent reconstruction.
2. Identified the filter function’s weakness: the filter has differential biases that cause certain input differences to map predictably to output differences, which combined with the LFSR linearity allows the cipher state to be partially recovered from a sufficient observation of keystream.
3. Introduced the nested attack — given one known key, recover all the other sector keys in the card by exploiting the fact that re-authentications within a session use cipher-encrypted nonces and the cipher state at re-authentication is partially predictable from the previous sector’s session state.

The Radboud team followed up in 2009 with “Wirelessly Pickpocketing a MIFARE Classic Card” (Garcia, van Rossum, Verdult, Schreur), which demonstrated the full attack chain against a real London Oyster card and a real Dutch OV-chipkaart, showing that the academic break was an immediate operational reality. The Dutch government’s reaction — a several-year delay before forcing migration to DESFire — made the legal envelope around MIFARE research a matter of explicit national policy.

8.4 2009 — Courtois and the darkside

Nicolas Courtois (then at University College London) published “The Dark Side of Security by Obscurity: And Cloning MIFARE Classic Rail and Building Passes Anywhere, Anytime” in 2009. The paper’s central contribution was the darkside attack — a technique to recover a sector key without needing any other key to be known first. The earlier nested attack required one known key (typically a default like FFFFFFFFFFFF or A0A1A2A3A4A5); the darkside attack works against cards where no default key is set anywhere on the card.

The darkside exploits a specific protocol-level leakage: the MIFARE Classic implementation, on receiving a malformed authentication response from the reader, replies with an 8-bit error code that is the keystream-encrypted version of a known plaintext. By forcing the card into the malformed-response state repeatedly with selected reader nonces, the attacker collects enough partial keystream observations to constrain the 48-bit key to a manageable candidate set, then verifies each candidate with a normal authentication. The whole attack takes seconds to minutes on adequate hardware.

The combination of darkside + nested means: given an arbitrary MIFARE Classic card and a Proxmark3-class reader, every sector key on the card is recoverable in under five minutes total. The card’s authentication mechanism has been completely defeated. The iCopy-X implements both attacks in the STM32 firmware and the on-device application layer orchestrates them automatically.

8.5 The “hardened” cards — FM11RF08S and friends

In the mid-2010s, several Chinese chip manufacturers — most prominently Fudan Microelectronics with the FM11RF08S — began shipping MIFARE Classic clones with hardened nonces: the card nonce generation was modified so that nonces were filtered to be statistically harder to use for the nested attack. The “encrypted nonce” wasn’t more secret in any cryptographic sense — the LFSR-derived keystream still applied — but the unpredictability of the underlying nonce values broke the assumption the original nested attack relied on for state-space reduction.

The community response was the hardnested attack, developed by Carlo Meijer and Roel Verdult (Radboud team alumni) in 2015. Hardnested is more computationally intensive than nested — it builds larger candidate-state tables and does more exhaustive verification — but it works against the hardened nonces. The runtime climbs from ~5 minutes per card (nested) to ~30+ minutes per sector (hardnested), and the storage requirements grow into the hundreds of megabytes of intermediate tables.

The iCopy-X NanoPi NEO is not as compute-rich as a modern laptop, but it has enough RAM and enough Cortex-A7 cycles to run hardnested at the cost of patience. Firmware support was added in the iCopy-X 1.x series and refined in 2.0; the Auto Clone mode includes hardnested as a fallback after darkside and nested both fail, and the user sees a “this may take a while” indicator on the LCD when the device is in the hardnested phase. In the field, the operator’s heuristic is: if a card has been sitting on the antenna for more than ten minutes and nothing has shown up on the screen, the card is probably a hardened FM11RF08S clone and the operator should expect another twenty to thirty minutes per remaining sector.

The further “encrypted nonce” variants — FM11RF08S with static encrypted nonces, where the card’s nonce is the same constant every time — required a separate technique (staticnested or the “Mifare Classic Tool” team’s static-encrypted variant), which the iCopy-X 2.0 firmware also handles automatically. The decision tree is firmware-internal; the operator sees the Auto Clone progress indicator and waits.

9. The four attacks in iCopy-X firmware — operational depth

The iCopy-X automates four key-recovery attack categories. The decisions about which to use are made by the firmware in Auto Clone mode and exposed manually in Sniff mode (Vol 7 §6); the operator’s mental model needs to cover all four so they understand what the device is doing and when to stop waiting.

9.1 Dictionary attack

The first thing the iCopy-X firmware does on encountering a MIFARE Classic is try the dictionary of common keys. The default dictionary shipped with the iCopy-X 2.0 firmware contains roughly 1500 keys, drawn from the Iceman Proxmark3 repository’s mfc_default_keys.dic plus Lab401’s own field-observed additions. The dictionary is heavily front-loaded with the keys that actually appear in deployment:

Key	Where it appears
FFFFFFFFFFFF	NXP factory default; ~30 % of field-encountered MIFARE Classic cards
A0A1A2A3A4A5	NXP-recommended default for Sector 0 Key A in early documentation
D3F7D3F7D3F7	NXP-recommended default for Sector 0 Key B in early documentation
B0B1B2B3B4B5	Common transit-system testing key
4D3A99C351DD	A widely-used vendor default in access-control integrations
1A982C7E459A	Another vendor default; integrator-specific
AABBCCDDEEFF	Common test/demo key
714C5C886E97	A specific brand’s factory key
587EE5F9350F	Another commonly-leaked key
0F0F0F0F0F0F etc.	Pattern keys; small but worth trying

Trying 1500 keys against 16 sectors × 2 keys (A and B) per sector is 48,000 authentication attempts. At ~10 ms per attempt, that’s ~8 minutes on a single attempt-per-key worst case — but the firmware bails out per-sector the moment a key works, so the median case for a card with any defaults at all is a few seconds. The dictionary attack is the cheapest possible attempt and the firmware always runs it first.

Empirically, on the kinds of cards an authorized physical-pentest commonly encounters (corporate badges, hotel keys, transit cards), the dictionary attack alone recovers all the keys on roughly 40 % of cards. Another ~30 % have one or two keys covered by the dictionary, leaving the rest for nested. The remaining ~30 % need either darkside (no defaults at all) or hardnested (Fudan-clone hardened nonces).

9.2 Nested attack — when one key is known

After the dictionary exhausts, if at least one key on the card was found (any sector’s Key A or Key B), the firmware switches to the nested attack. The mechanics:

1. The reader authenticates with the known key (call it K_known).
2. The reader requests a second authentication within the same session, but for a different sector with an unknown key.
3. The card sends its second-authentication card nonce encrypted with the running Crypto1 state — but the encryption is over a predictable nonce sequence because the LFSR is in a known state at this point in the protocol.
4. The reader observes the encrypted nonce, knows the LFSR state, and can recover the new sector’s key by working out which 48-bit key would produce the observed encrypted nonce.

The math is more involved than this sketch — there are parity bits, there are multiple authentication rounds needed to constrain the candidate space, the LFSR state must be tracked through the cipher operations between authentications — but the load-bearing point is that once any key is known, all the other keys fall in roughly two to three minutes per sector. For a 1K with one known key, that’s ~30 to 45 minutes total. The iCopy-X tightens this with optimized implementations (the STM32 does the per-nonce work in hardware-accelerated tight loops) so the actual observed time is ~5 minutes for a complete 1K crack.

The nested attack’s failure modes are: the card uses hardened nonces (move to hardnested), the card uses static encrypted nonces (move to staticnested — automatic in iCopy-X 2.0), or no key was found in the dictionary (move to darkside).

9.3 Darkside attack — when no key is known

The darkside attack is what runs when the dictionary finds nothing. The mechanics:

1. The reader sends an authentication request with a deliberately malformed reader response.
2. The card replies with an 8-bit error code (NACK), which is the Crypto1-encrypted form of the constant 0x05 (the NACK plaintext).
3. By varying the reader nonce systematically and collecting the encrypted NACK values, the attacker observes a sequence of one-byte keystream samples taken from different LFSR states.
4. The structural weaknesses of the filter function — specifically, the fact that the filter has odd-parity output for certain input patterns — let the attacker constrain the LFSR state from these samples.
5. After enough samples (typically a few thousand), the candidate state space for the 48-bit key is reduced to a manageable set (on the order of 2^16 to 2^20 candidates), which is then verified by attempting normal authentications.

The darkside attack on the iCopy-X takes ~30 seconds per sector. For a 1K with no dictionary hits, that’s ~8 minutes total to recover all 16 sectors’ Key A’s (Key B is recovered by nested from any one recovered Key A, dropping the total time further). For a 4K with no dictionary hits, ~20 minutes total. The Auto Clone progress indicator updates per sector so the operator can see the device working.

The darkside attack does not work against hardened-nonce cards. The hardened nonce filtering removes the systematic biases the attack depends on. If darkside fails after attempting all sectors, the firmware drops to hardnested.

9.4 Hardnested attack — hardened nonce cards

The hardnested attack is the heavyweight of the four. It applies when the card’s nonces are hardened — typically because the card is an FM11RF08S Fudan clone, but increasingly because newer NXP MF1 silicon (the EV1-revision Classic, which NXP shipped briefly to address darkside) uses hardened nonce generation as well. The hardened-nonce countermeasure does not patch the cipher — Crypto1 is still Crypto1 — but it removes the statistical bias that nested and darkside relied on for state-space reduction.

Hardnested compensates by brute force on a larger candidate space, with the LFSR linearity still exploited to make the search tractable. The actual implementation builds large precomputed tables of “candidate keystream samples that match observed parity bits,” then sieves them against further observations. The iCopy-X NanoPi NEO has 256 MB of RAM, which is enough for the smaller-table variants of hardnested but not for the lab-grade GPU-table approach that runs on a tethered Proxmark3 with a laptop’s RAM behind it.

In practice, hardnested on the iCopy-X takes ~30 minutes per sector, sometimes longer for the more aggressive hardening variants. A full 1K hardnested crack is therefore an 8-hour overnight operation, not a 5-minute in-hallway one. The iCopy-X firmware will run it automatically as part of Auto Clone, but the operator’s planning needs to account for the time: a card known to be a Fudan clone should be brought back to a desk environment where the device can sit on a charger and complete the crack unattended, not held against the antenna in front of a client.

9.5 Combinatorial and rainbow-table approaches

For completeness, the iCopy-X firmware does not include classical rainbow-table approaches to Crypto1. Rainbow tables for 48-bit Crypto1 exist (the Iceman repository ships them), and the Proxmark3 RDV4 with the laptop client can use them — but they are several gigabytes per table and the iCopy-X’s microSD is not large enough to hold the comprehensive set with the rest of the firmware overhead. The dictionary attack is the operationally-useful subset of “known-key” attacks; rainbow tables are a research-lab tool, not a field-portable one.

Brute force of 48-bit Crypto1 — exhausting all 2^48 candidates — is academic. At ~10 ms per attempt on the device, 2^48 attempts would take ~89,000 years. The Iceman Proxmark3 GPU-cluster benchmarks bring this down to about a day on a single high-end GPU, which is useful in a lab but not on an iCopy-X. The operator’s understanding should be: brute force does not exist as a strategy on this device; if dictionary, nested, darkside, and hardnested all fail to recover a key, the card cannot be cracked on this device and the workflow moves to the Proxmark3 RDV4 at a desk with a GPU.

10. Attack time-budget summary

The operationally useful summary, all on one page:

Attack	Precondition	Time per sector	Total for full 1K	Total for full 4K
Dictionary	None	< 1 s if hit, ~10 s if miss	seconds (any defaults)	seconds (any defaults)
Nested	One key known	~30 s (well-optimised)	~5 min	~20 min
Darkside	None (no key needed)	~30 s	~8 min (16 sectors A only, then nested for B)	~20 min
Hardnested	None (against hardened nonces)	~30 min	~8 hours	~20 hours
Staticnested	None (against static encrypted nonces)	~5 min	~80 min	~3 hours
Brute force (off-device)	None	impractical on iCopy-X	n/a	n/a

The Auto Clone firmware orchestrates these in the order: dictionary → (if any keys found) nested → (else) darkside → (if both fail) hardnested → (if hardnested detects static encrypted) staticnested. The operator’s mental model is “the device tries the cheap things first and only commits to the long-running attacks when the cheap ones don’t work.”

11. Cloning workflow for MIFARE Classic — what happens in Auto Clone

When the operator holds a MIFARE Classic card against the iCopy-X antenna and presses the Auto Clone key sequence, the firmware executes the following workflow. The exact UI is in Vol 7; this is the conceptual model:

Phase 1 — Identification. The firmware sends REQA (the ISO 14443A wake-up), receives ATQA, runs the anticollision loop, receives UID + BCC + SAK. The SAK byte tells the firmware what kind of MIFARE chip it’s looking at: 08 for 1K, 18 for 4K, 09 for Mini, 00 for Ultralight family, 20 for Plus / DESFire (these need further SELECT and ISO 7816 application-info exchanges to distinguish). The screen briefly shows “MIFARE Classic 1K (or whatever)” so the operator knows what’s being attacked.

Phase 2 — Key recovery. Dictionary attack first. If the dictionary covers all 16 sectors (rare but possible — some hotel chains use the same factory defaults across an entire property), the firmware skips to Phase 3. Otherwise it does nested with any recovered keys, then darkside for any remaining sectors, then hardnested if necessary. Progress is shown per-sector; the operator can see “Sector 5/16 cracked, 11 remaining” updating.

Phase 3 — Read. Once all keys are known, the firmware reads every block of every sector, decrypting on the fly with the Crypto1 keystream. The card’s contents are now in the iCopy-X’s RAM. The screen shows “Card read complete.”

Phase 4 — Card removal and blank insertion. The screen prompts “Remove source card.” The operator removes the source card. The screen then prompts “Place blank card.” The operator places a magic blank (Gen1a, Gen2, Gen3, or Gen4 — see Vol 9) against the antenna.

Phase 5 — Identification of the blank. The firmware identifies which magic variant the blank is. Gen1a responds to a specific backdoor command (40 43 followed by an unlock sequence). Gen2 is invisible-magic — it looks like a normal Classic but responds to direct block-0 write commands. Gen3 has its own APDU dialect. Gen4 is more recent and more configurable. The iCopy-X firmware does the identification by trying each backdoor in sequence and observing which one the blank responds to.

Phase 6 — Write. Using the appropriate write strategy for the detected magic variant, the firmware writes Block 0 (the UID and manufacturer data, copying from the source), then writes every other block with the source’s content (using the source’s keys, which the firmware now knows and uses to authenticate to the blank’s sectors after writing the trailer with the source’s keys). The screen updates per-sector.

Phase 7 — Verification. The firmware reads back the cloned card, sector by sector, with the source’s keys, and compares to the in-RAM image. Any block that doesn’t match triggers a retry; persistent mismatches result in a “Clone failed — try a different blank” error.

Phase 8 — Done. The screen shows “Clone complete.” The operator removes the cloned card, which is now functionally identical (within the limits of the magic-card chemistry’s ability to spoof Block 0) to the source.

Typical end-to-end Auto Clone time for a MIFARE Classic 1K with all-default keys: under a minute. With dictionary-only keys: ~1–2 minutes. With nested needed: ~5–7 minutes. With darkside needed: ~10–15 minutes. With hardnested needed: hours.

The operator’s planning during a live engagement: budget a minute per simple card, five minutes per complicated card, and bring the unit back to a desk for any card the device flags as “this is going to take a while.” Standing in a hallway for thirty minutes with a card pressed against an antenna and an LED blinking is the kind of operational signature that loses engagements.

12. Manual workflow — Sniff mode, when Auto Clone cannot complete

There are situations where Auto Clone alone cannot finish the job and the operator needs to drop to Sniff mode (Vol 7 §6) to capture an over-the-air exchange between a legitimate reader and the source card. The relevant scenarios:

• The card is on a reader that the operator does not have physical possession of (the operator can hold the iCopy-X near the reader and capture the exchange but cannot remove the card to the iCopy-X for direct attack).
• The card is a DESFire or Plus SL3 where the keys cannot be recovered from the card alone — but the reader has the keys and uses them in a legitimate exchange that can be captured.
• The card uses key-diversification (each card has a different key derived from a master key + UID; the master key lives in the reader) and the operator needs the reader’s exchange to extract a usable per-card key.

Sniff mode puts the iCopy-X into a passive listening state at 13.56 MHz, monitoring the reader-to-card and card-to-reader sides of the air channel simultaneously. The captured exchange is stored on the microSD as a structured trace; the firmware then runs key-recovery analytics against the trace, which for Crypto1 includes the same nested / darkside variants but operating against captured nonces instead of generated ones, and for non-Crypto1 protocols (DESFire, Plus, FeliCa) does whatever the protocol-specific recovery technique calls for.

Vol 7 covers Sniff mode in operational detail — how to position the device for a good capture, how long to wait, what the trace contents look like, how to invoke the post-capture analytics. The key point for this volume is that Sniff mode exists, and the cases where Auto Clone alone fails are usually covered by Sniff mode plus the right post-capture analytics.

13. The “MIFARE Classic 1K clone” problem in 2026

A specific operational issue worth covering in its own section: in 2026, the supply of MIFARE Classic 1K silicon is dominated not by NXP but by Chinese clone manufacturers — Fudan, Shanghai Belling, Huahong, and others. These clones are sold as drop-in replacements for genuine NXP MIFARE Classic at substantially lower per-unit cost, and the cloned cards work in essentially every deployed reader because the readers are checking for the MIFARE Classic protocol behaviour, not for genuine-NXP-silicon attestation.

The clone manufacturers vary in their handling of the Crypto1 vulnerabilities. The categories:

• FM11RF08 (Fudan original) — protocol-compatible with NXP MIFARE Classic 1K, same Crypto1, same defaults. Acts identically to genuine NXP. Common in low-cost transit-card deployments through the early 2010s.
• FM11RF08S (Fudan “secure” — meaning more resistant to attacks, not actually secure) — adds hardened nonce filtering to break the darkside and standard nested attacks. Hardnested attack is required.
• FM11RF08S with static encrypted nonces — additional variant where the nonces, after hardening, are encrypted but static across authentications. The staticnested attack handles this.
• Other Chinese clones with various ad-hoc countermeasures — Shanghai Belling, Huahong, and smaller manufacturers have variously implemented their own anti-nested measures. The iCopy-X firmware’s category-detection heuristics try to identify which countermeasure is in play and select the right attack.

The operational consequence is that an operator in 2026 who encounters a “MIFARE Classic 1K” card has somewhere around a 60–80 % chance of looking at a Chinese clone, and a non-trivial subset of those clones require the slower hardnested / staticnested attacks. This is not visible to the user from the card’s surface markings — clones are often indistinguishable from genuine NXP unless the operator decapsulates the chip — and the iCopy-X’s silicon-detection happens during the attack itself when the dictionary and darkside attempts fail.

For pentest planning: assume that any MIFARE Classic deployment that doesn’t go all-defaults-keys is at least possibly a hardened-clone deployment, and budget time accordingly. The cards that are “tough” in the field are usually tough because of the silicon rather than because of operational discipline on the customer’s side.

14. Cross-references and what comes next

Vol 3 is the HF physics that everything in this volume sits on top of. The reader who finds the cipher-state discussions too dense should go back and confirm they have the ISO 14443A REQA / ATQA / SAK / anticollision sequence comfortably grasped before re-reading §§ 3 and 8 here.

Vol 6 is the rest of the HF universe — iCLASS Legacy / Elite / SE / SEOS, ISO 15693 family, FeliCa, Legic. The iCLASS volume is where the iCS Decoder Tool add-on becomes relevant, and where the next class of crypto break (the iCLASS Legacy single-DES authentication, the iCLASS Elite key-diversification model, the SE / SEOS contactless-Smart-Card protocols) plays out.

Vol 7 is the operating-modes detail for Sniff mode, the operational frame around §12 above, and the Auto Clone UI specifics that underlie §11.

Vol 8 is the Expert / Proxmark Mode escape hatch — when the operator needs to drop out of the appliance UI and access the Proxmark3 client commands directly. For MIFARE work this is sometimes useful when an unusual card defies the standard recovery sequence and a hand-crafted attack is needed.

Vol 9 is the blank-card ecosystem — Magic Gen1a vs Gen2 vs Gen3 vs Gen4, which blank works for which clone target, which suppliers are reliable. For MIFARE Classic cloning, the blank choice is load-bearing: a clone is only as good as the blank’s ability to faithfully spoof Block 0 and the access bits.

15. Resources

• “Mifare — Little Security, Despite Obscurity,” Karsten Nohl and Henryk Plötz, 24C3 (December 2007). The original public reverse-engineering presentation; the recording is available in CCC archives.
• “Dismantling MIFARE Classic,” Gerhard de Koning Gans, Jaap-Henk Hoepman, Flavio Garcia, ESORICS 2008. The academic paper that introduced the nested attack and consolidated the cipher’s vulnerabilities.
• “Wirelessly Pickpocketing a MIFARE Classic Card,” Flavio Garcia, Peter van Rossum, Roel Verdult, Ronny Wichers Schreur, IEEE Symposium on Security and Privacy 2009. Real-world demonstration against operational transit systems.
• “The Dark Side of Security by Obscurity: And Cloning MIFARE Classic Rail and Building Passes Anywhere, Anytime,” Nicolas Courtois, SECRYPT 2009. The darkside attack paper.
• “Ciphertext-only Cryptanalysis on Hardened Mifare Classic Cards,” Carlo Meijer and Roel Verdult, CCS 2015. The hardnested attack.
• NXP MIFARE Classic product documentation: https://www.nxp.com/products/rfid-nfc/mifare-hf/mifare-classic
• Iceman Proxmark3 fork documentation: https://github.com/RfidResearchGroup/proxmark3/wiki — operational walkthroughs for every attack covered in this volume, with the original Proxmark3 client commands the iCopy-X firmware wraps.
• proxmark.org community wiki: https://proxmark.org/ — attack walkthroughs, key dictionaries, magic-card identification guides.
• libnfc project: https://github.com/nfc-tools/libnfc — the open-source NFC library underlying many independent MIFARE tools, including the original implementations of nested and darkside.
• This subproject’s local resources: ../05-resources/ — Lab401 user manual PDF for the iCopy-X Auto Clone UI walkthrough, firmware update guide PDF.