The MIFARE attacker playbook: what three papers and one Proxmark3 teach you

Hi folks,

A new paper dropped in January of this year, I forgot to post there, and then missed the time to do so -> “BREAKMEIFYOUCAN!: Exploiting Keyspace Reduction and Relay Attacks in 3DES and AES-protected NFC Technologies” by Nathan Nye, Philippe Teuwen, Tiernan Messmer and others (eprint 2026/100, breakmeifyoucan.com). It dismantles MIFARE Ultralight C, Ultralight AES, NTAG 223/224 DNA, and the counterfeit Ultralight C clones that have quietly infiltrated hospitality and ticketing supply chains (Giantec GT23SC4489 a.k.a. ULCG, Feiju FJ8010, USCUID-UL).

What makes it worth writing about is not that it’s a standalone breakthrough. It’s that when you read it alongside Philippe Teuwen’s August 2024 paper “MIFARE Classic: exposing the static encrypted nonce variant” (eprint 2024/1275) and back further to Teuwen and Herrmann’s 2021 SSTIC paper “EEPROM: It Will All End in Tears”, you realize you’re looking at a three-part research arc: the same methodology deepening and branching across five years of work on adjacent parts of the MIFARE family tree. Same author orbit, same toolchain, same adversary model, same philosophy. The 2021 paper established the physical primitive: EEPROM writes are not atomic, interrupting the erase phase leaves exploitable intermediate states, and this applies to contactless silicon in ways the industry had largely ignored. The 2024 paper applied that lens to MIFARE Classic FM11RF08S while also stumbling into something completely unexpected, a hardware backdoor key baked into the entire Fudan production run and, it turned out, into old NXP and Infineon silicon too. The 2026 paper weaponizes both threads simultaneously: relay attacks to reach authenticated state, partial key overwrite via non-atomic page writes, tearing to collapse the remaining keyspace, and the counterfeit PRNG weaknesses to skip the hard parts entirely on a third of the cards in the wild. What emerges from reading the three together is a reusable attacker playbook that probably applies to more than just MIFARE.

Same adversary model, same primitives

Both papers target a specific shape of adversary: no lab, no FIB, no power analysis rig. Just a Proxmark3, a Flipper Zero, maybe a ChameleonUltra, a decapped sample for IC identification when it helps, and patience. Both papers explicitly call out that the attacks work on resource-constrained hardware. The BREAKMEIFYOUCAN authors estimate total equipment cost under $500. Teuwen’s Fudan work runs entirely on a Proxmark3. The whole point is accessibility, which matters because it means these aren’t theoretical threats for red teams with grant funding, they’re operational threats for anyone who acquires a second-hand hotel keycard.

Inside that model, both papers lean on the same three primitives:

Weak PRNGs as the pivot. The 2024 paper’s core break hinges on a 16-bit LFSR whose state is effectively time-of-query-dependent since card power-up, producing initial nonces concentrated in a narrow window of the 2¹⁶ possible values. When you decap ULCG and reverse its PRNG, you find a 16-bit LFSR that is essentially the MIFARE Classic LFSR rotated by one bit. USCUID-UL and FJ8010 use the MIFARE Classic LFSR verbatim. Same shape, same exploitation: collect a few thousand nonces, plot their LFSR index distribution (the 2026 paper includes the histograms, they’re striking), observe collisions within tens of queries (>50% collision probability within 12 queries for ULCG and FJ8010, within 31 for USCUID-UL), and you’ve collapsed the nonce search space to something brute-forceable offline. The 2024 paper uses weak PRNG analysis differently: it confirms that FM11RF08S nonces cluster around a narrow initial window, enabling the timing-based nonce recovery without a backdoor (Section IX of the 2024 paper), and it partially reverse-engineers the nested nonce generation mechanism as two alternating 4-bit S-boxes applied per key nibble (Section X), which is used to jointly filter keyA and keyB candidates and speed up the backdoored nested attack by a factor of ~6.

EEPROM tearing. Teuwen’s 2021 SSTIC work “EEPROM: It Will All End in Tears” (co-authored with Herrmann) feeds directly into the 2026 paper. The 2026 paper exploits the total absence of anti-tearing protection on lock bytes of ULCG/GT23SC4489 to overwrite protected memory pages even when lock bytes should prevent it, then builds an entire key-recovery methodology around tearing key pages: partial key overwrite, weak-bit characterization, revival via thermal stress and field-distance manipulation, late-erasing bit inference, and calibration on RFU pages. On Ultralight C, tearing a single 28-bit key segment down to HW <= 3 reduces the brute-force to ~37 seconds at 100 keys/s, but note this requires repeated tearing across multiple tags, with the paper reporting ~7 tearing operations and ~55 seconds per tag to recover an average of 1.5 bits. On Ultralight AES, tearing revealed an unexpected per-tag 128-bit mask XOR’d onto the stored key, an architectural countermeasure the authors only discovered because they were tearing, and which is itself recoverable in about 7 minutes. The 2024 FM11RF08S paper doesn’t rely on tearing, but the 2026 paper explicitly credits the earlier SSTIC work as its physical exploitation baseline.

Behavioral fingerprinting. Both papers include extensive annexes cataloguing how genuine silicon responds to malformed commands, short frames, mistimed auth attempts, and unspecified state transitions, versus how the clones respond. Frame Delay Time (FDT) on authentication failure is particularly discriminating: 78 µs for GT23SC4489, 842 µs for genuine NXP MF0ICU2, 3646 µs for USCUID-UL variant 1, three orders of magnitude apart. The 2024 paper extends this to a full metrics table across 50+ MIFARE Classic variants (FDT, SAK, NACK behavior, short-frame responses, backdoor support, ACL behavior under different auth commands), which is one of the most comprehensive public fingerprinting references for MIFARE silicon that exists. This is not bonus material, it’s how you tell a genuine FM11RF08S from an Infineon SLE66R35 that happens to share the same backdoor key A31667A8CEC1, or a real NXP MF0ICU2 from a USCUID-UL pretending to be one.

The shared methodology: a reusable checklist

Distilling both papers, the methodology looks like this:

1. Question the PRNG first. Never trust vendor claims about randomness. Collect a few thousand nonces, plot their distribution across LFSR index space, run Berlekamp-Massey if you suspect an LFSR. Cheap silicon fakes randomness badly, and even expensive silicon sometimes ties nonce generation to internal state in ways that become exploitable. The GT23SC4489 distribution peaks so sharply that more than 50% of observed nonces in 10,000 samples concentrate in a window of roughly 27 consecutive LFSR values.
2. Inventory the state machine by fuzzing. Both papers performed systematic command fuzzing across all single- and double-byte sequences in every card state. The 2024 paper found the FM11RF08S backdoor authentication commands (64xx–67xx, 6Cxx–6Fxx) by doing exactly this, testing what the card does in response to 6*00 and seeing unexpected nonce replies where NAKs were expected. The 2026 paper produced the behavioral fingerprinting tables the same way. This is the single highest-yield technique in the whole playbook: undocumented commands, unspecified state transitions, and off-by-one ACL quirks are everywhere in contactless silicon.
3. Identify what is non-atomic. The partial key overwrite attack works because writing a 112-bit 2TDEA key (or 128-bit AES key) is actually four separate 4-byte page writes, and nothing enforces atomicity. The attacker authenticates once via relay, overwrites three quarters of the key with zeros, and the card happily accepts each page write independently. Every time you encounter a cryptographic secret stored across multiple addressable memory units, ask whether it can be partially replaced.
4. Test for anti-tearing on everything that matters. Keys, lock bytes, authentication failure counters, access control bytes. The 2026 paper’s clone attacks depend on the GT23SC4489 lacking anti-tearing on lock bytes. The Ultralight AES mask recovery depends on tearing key pages. The FJ8010 does implement anti-tearing on key pages (erasing toward 0xFFFFFFFF rather than 0x00000000), which actually reveals itself as a distinguishing fingerprint. If a critical byte isn’t protected against interrupted writes, assume an adversary will interrupt writes.
5. Treat CMAC-less protocols as broken post-authentication. Ultralight C has no session integrity at all. Once relayed into AUTHENTICATED state, which the 2026 paper demonstrates is feasible because the tag side of the handshake has no timeout, only the reader, an attacker can inject arbitrary plaintext commands for as long as the RF field remains on. Ultralight AES has optional CMAC (SEC_MSG_ACT) that is disabled by default. Every system surveyed in the 2026 paper except one (a VingCard deployment) left it off. The relay trick generalizes to any protocol where one side waits indefinitely for the other’s response.
6. Enumerate key reuse across the deployment before you attack. Static key across all tags? Check with UID swap during relay. Static key across sites? Check by presenting a recovered credential elsewhere. Key diversified from UID only, without a site salt? The 2026 paper’s credential forgery case study (Section 18) demonstrates exactly this failure mode against a deployed hospitality system: UID-only KDF shared across multiple sites meant a key sniffed at hotel B worked to authenticate at hotel A, which combined with publicly documented encoding formats allowed them to forge an expired keycard into a valid one. Both papers’ Section V / Section 5 are effectively the same insight: measure key reuse before attempting full recovery, because it determines whether you need 1 card, 4 cards, or 40.
7. Sniff once, reuse offline. Both papers minimize online brute-force by capturing reader contributions early. In the 2026 paper, collecting the reader’s ek(RndA || RndB') lets you validate 2TDEA key candidates entirely offline for one 28-bit segment, around 60 seconds on a modern laptop. For the two-tag variant, recovering the final 56 bits offline on rented GPUs costs roughly $122 for ~6 hours of compute (70× RTX 4090 at Vast.ai 2025 pricing, with the 4/9× DES reduction from Section 10.2 applied), but note this is the offline phase only; the two online segments still take roughly 21 days with two simultaneous readers. The 2024 paper’s supply-chain attack is the extreme version of this: precompute nested nonce LFSR ancestors from virgin FM11RF08S tags before they’re personalized, store 36 bytes per card UID, and the field attack collapses from 21 minutes to 19 seconds.

This playbook is generic. It is not specific to MIFARE. Apply it to any contactless card, any embedded secure element, any low-cost crypto IC, and you will find at least two or three of these primitives exploitable.

The data-first attack and what it means for red teams

One of the more underappreciated contributions of the 2024 paper is Section XXIII, the “data-first attack.” The traditional card-only attack sequence is: break keys -> dump data → clone. The data-first attack inverts this: collect data and encrypted nonces in 2 seconds via the backdoor key, then walk to the reader and recover keys on the fly from failed authentication traces, presenting stolen {nT} values and computing valid responses because you already know the plaintext nonces. Key recovery in that scenario takes under 0.2 seconds.

The practical scenario the paper outlines, briefly touching a target card at a social event, then emulating it at a reader elsewhere, is precisely the threat model for high-value access control: defense contractors, government buildings, hotel operator cards, data center badge systems. If the infrastructure is running FM11RF08S cards (and many operators don’t know they are, they ordered “MIFARE Classic 1K” and got Fudan), and an attacker knows the backdoor key A396EFA4E24F, the card doesn’t need to be held for more than two seconds. The Proxmark3 script hf mf isen --collect_fm11rf08s_with_data handles both data and nonce collection in a single pass (~1.7 seconds measured).

For red teamers doing physical security assessments: this is now a realistic card-only attack chain that fits entirely within a casual social interaction, requires no knowledge of the system keys, and leaves no detectable trace on the card.

Why this matters beyond MIFARE, including for defense contexts

The counterfeit IC problem documented in the 2026 paper is structural, not incidental. Cards visually identical to genuine NXP Ultralight C, same form factor, same command set, sometimes sold with the NXP logo, have been found in hospitality, ticketing, and vehicle monitoring deployments. 34% of 73 sampled cards from US hospitality were non-genuine. NXP has active litigation against at least one distributor (Global Card Systems) over this. The lesson, verify silicon provenance, fingerprint behaviorally, don’t trust UID ranges, applies directly to any sector that uses contactless credentials at scale, including defense facilities, government ID programs, and critical infrastructure under NIS2 scope.

For defense specifically: MIFARE Classic (including Fudan variants) and Ultralight C remain in operational use for physical access control at facilities that aren’t under the most stringent access card mandates. The 2024 paper’s finding that old NXP MF1ICS5003/MF1ICS5004 (manufactured 1998–2001) and Infineon SLE66R35 cards share the backdoor key A31667A8CEC1 with Fudan clones is a supply-chain archaeology finding, it suggests the backdoor predates the Fudan chips and may have spread through shared IP or design reuse across multiple manufacturers. Cards from this period are not uncommon in legacy physical access systems that were never refreshed. If you’re auditing a facility and you’re seeing SAK 08 or SAK 88 cards, run hf mf info before assuming anything about their provenance.

Accessible tooling

Both papers come with tooling merged into the Iceman Proxmark3 fork. The BREAKMEIFYOUCAN release contributed: mfulc_des_brute for offline 2TDEA brute-force from captured nonce pairs, mfulc_counterfeit_recovery.py for one-shot single-card recovery against ULCG/FJ8010/USCUID-UL, mfulaes_mask_recovery.py, ntag22x_suncmac_recovery.py, new hf mfu cchk/hf mfu aeschk dictionary commands, full Ultralight AES support across hf mfu info/rdbl/wrbl/dump, counterfeit fingerprinting in hf mfu info, and relay support in hf mfu sim. The 2024 FM11RF08S tooling: staticnested_*, fm11rf08s_recovery.py, mfkey32nested, backdoor auth command support across hf mf *, has been merging into the same fork since August 2024, against commit 71621470bd1ac5caae64f24d4413bc1bcc3e65ef as the stable reference point in the paper.

If you want to reproduce either paper without wrestling with a build environment, the RF Swift RFID image has all of this packaged:

bash

rfswift images pull -i rfid
rfswift run        # choose the rfid image

The Proxmark3 client and the full set of accompanying binaries and scripts live under /rftools/rfid/proxmark3. libnfc, MFOC, mfcuk, ChameleonUltra tooling and the usual suspects are there too, so you can chain a Fudan backdoor dump into an Ultralight C relay attack on the same infrastructure, hotel, transit, parking, whatever, without leaving the container. The LFSR position control added to hf 14a raw -w <µs> for ULCG timing is particularly useful for reliably landing on the high-probability nonce window before initiating the relay-based auth.

Only on gear you own or are explicitly authorized to test, of course. Nathan Nye’s contribution to the 2024 paper’s follow-up (the FM11RF32N backdoor keys 518B3354E760 and 73B9836CF168) started exactly that way, via a camping bracelet with an unknown key flagged by the Flipper Zero detection that Nathan had implemented.

References

• BREAKMEIFYOUCAN paper & resources: https://breakmeifyoucan.com – https://eprint.iacr.org/2026/100
• FM11RF08S backdoor paper: https://eprint.iacr.org/2024/1275
• Proxmark3 Iceman fork: https://github.com/RfidResearchGroup/proxmark3

Originally posted on the Penthertz Community.