Hacker Tradecraft Volume 15 — RF Tradecraft III: RFID, NFC, and Access Control — Hacker Tradecraft · Hacking

The card families from 125 kHz EM4100 through 13.56 MHz MIFARE and iCLASS, the NFC protocol stack at engineer depth, the capability-level catalog of clone-replay-relay-downgrade attacks, and the gear from Proxmark3 and Flipper Zero through HydraNFC, ChameleonUltra, and iCopy-X

Section	Topic
1	About this volume
2	LF vs HF RFID — the physics and the operational differences
3	The card families — reference catalog
4	NFC — the protocol stack and the attack surface
5	Access-control attacks — capability-level catalog
6	The gear — RFID and NFC hardware comparison
7	Legal and regulatory
8	Cross-reference index
9	Resources

1. About this volume

This volume closes the RF reference cluster. Vol 13 treated SDR and sub-GHz — the 300 MHz to 1 GHz consumer-wireless population center, the I/Q + Nyquist + receive-chain fundamentals, and the capture-analyze-replay workflow that defines the practitioner’s working day at the sub-GHz layer. Vol 14 treated the 2.4 / 5 / 6 GHz Wi-Fi and BLE attack surface — the rogue-AP family from KARMA through MANA, the WPA2 4-way handshake and PMKID offline-crack pipeline, the WPA3 SAE / Dragonblood landscape, and the BLE protocol stack from PHY through GATT. This volume closes the cluster at the opposite end of the spectrum — the low and high frequency contactless-card ecosystem at 125 kHz and 13.56 MHz that powers most physical access control, transit fare, payment, and the rapidly-growing NFC-tag population.

The framing matches Vol 13 and Vol 14. The reader — tjscientist, a 45-plus-year EE and software engineer — already understands the physics of inductive coupling, near-field communication, and the basic ISO 14443 / 15693 standards. What this volume does is wrap that physics in the security-research framing that the hat volumes (Vols 6-12) have been deferring here whenever they referenced “see Vol 15 for the card families” or “see Vol 15 for badge-cloning depth.” The content, in operational order: the LF-vs-HF distinction and what it means for security posture (§2); the card-family catalog from EM4100 through MIFARE Classic through iCLASS SE through DESFire EV3 with each family’s security model, attack status, and typical deployment (§3); the NFC protocol stack at the ISO 14443 / 15693 / NFC Forum spec level, the four operating modes, NDEF, HCE, and the attack surface that follows from them (§4); the capability-level catalog of clone / replay / relay / brute-force / downgrade / long-range-capture attacks (§5, deliberately not an operational walkthrough); the RFID/NFC gear comparison from the Proxmark3 RDV4 lab tool through the Flipper Zero handheld through the Chameleon Ultra emulator through the iCopy-X consumer cloner (§6); and the legal frame that applies the CFAA “without authorization” doctrine to physical access control (§7).

Reference-cluster role. Like Vol 13 and Vol 14, every H2 heading in this volume becomes a frozen vol15-<heading-slug> anchor at first commit. The headings are deliberately chosen to be time-stable (5-10 words, slug-friendly, no / or & characters — Vol 11’s RF/HID heading slugified as rfhid and caused cross-reference issues later, a lesson now applied). Other Hack Tools deep dives deep-link into these anchors as HackerTradecraft_Complete.html#vol15-<slug> — the Flipper Zero deep dive reaches in for the NFC and 125 kHz tradecraft context that the Flipper documentation deliberately doesn’t re-derive; the future Proxmark3 RDV4 deep dive (currently a CLAUDE.md placeholder at ../../Proxmark3 RDV4/CLAUDE.md) will be the canonical platform-level link in. Inside the series, the hat volumes have already deferred multiple threads here: Vol 11 §3.6 treated the badge-cloning-during-physical-pentest workflow as part of the red-team operator’s physical-entry RF/HID staging layer, with the Proxmark3 and Flipper as the working set; this volume deepens the card-family and attack-capability side of those references.

What this volume does not duplicate. The hardware-level depth on individual devices lives in the device deep dives. Each sibling deep dive is referenced by relative path from the consolidated HTML at 03-outputs/:

Proxmark3 RDV4 — the lab-grade RFID/NFC research tool at chip-and-firmware depth; the LF + HF antenna configurations; the Iceman vs official firmware fork; the Lua scripting environment; the SIM reader expansion; the Blue Shark Bluetooth + battery accessory — will live in the future deep dive at ../../Proxmark3 RDV4/ (project directory carries the CLAUDE.md placeholder; the deep dive is aspirational as of early 2026).
Flipper Zero — the integrated RFID/NFC handheld at full depth; the dual-band antenna PCB, the ST25R3916 NFC subsystem, the 125 kHz LF subsystem implemented in firmware on the STM32 MCU, the protocol library, the read/save/emulate/write workflow on both bands — lives in ../../Flipper Zero/03-outputs/Flipper_Zero_Complete.html.

This volume treats RFID, NFC, and access control at the tradecraft level — what the card-family landscape looks like, where each attack class sits historically, what the workflow’s capability surface is at command-line depth, what gear covers which corners, and where the legal lines fall. Hardware-and-firmware depth is the device deep dives’ job; the tradecraft framing is this volume’s.

2. LF vs HF RFID — the physics and the operational differences

The contactless-card landscape splits cleanly at the boundary between low-frequency (LF, 125-134 kHz) and high-frequency (HF, 13.56 MHz). The frequency choice drives almost every operational difference that matters: coupling mechanism, read range, antenna geometry, data rate, encryption capability, and the population of cards that uses each band. The third major band — ultra-high frequency (UHF, 860-960 MHz) — covers the supply-chain and inventory population (EPC Gen2 / RAIN RFID) and is largely out of scope for security tradecraft, but appears here for orientation because it shapes the boundary of what “RFID” means in different contexts.

2.1 The physics of inductive coupling

Both LF and HF RFID transponders are passive devices — they carry no battery; they harvest their operating power from the reader’s emitted RF field. The coupling mechanism is magnetic, not radiative: the reader’s antenna coil generates a time-varying magnetic field; the card’s antenna coil, brought into that field, has an EMF induced in it; the card rectifies that EMF, powers up, and modulates its own load to communicate back. The reader senses the load-modulated reflection as a tiny change in the impedance of its own antenna. This is near-field communication in the strict sense — the operating distance is small compared to a wavelength, and the field that couples between reader and card is the magnetic component, not the propagating wave.

The consequence for security tradecraft is that read range is short by physics, not by policy. A 125 kHz field has a wavelength of ~2400 m; the working zone of a card-coupling magnetic field falls off as 1/r³ in the near zone. Doubling the antenna-to-card distance reduces coupling by ~8×. A typical 125 kHz EM4100 access card couples reliably at ~10 cm and is unusable beyond ~20-30 cm with a consumer antenna. A typical 13.56 MHz MIFARE card couples reliably at ~5-10 cm with a consumer antenna and is unusable beyond ~15 cm. Long-range RFID capture therefore means building a larger antenna or driving more transmit power — both of which raise the noise floor and run into regulatory and physics limits well before they extend range by an order of magnitude. The famous Eric Smith / Bishop Fox “Tastic RFID Thief” (2013-2014) extended HID Prox read range to ~3 ft using a long-range commercial reader (typically an HID MaxiProx 5375) wired into a custom controller — that was the state of the art for LF and remains a useful reference point.

2.2 LF — 125 kHz

LF RFID operates at 125 or 134 kHz with extremely short range, simple modulation, and minimal cryptography. The LF population is dominated by access-control credentials (HID Prox, EM4100/EM4102, Indala, AWID), pet implants (ISO 11784/11785 at 134.2 kHz), livestock tags, automotive immobilizers (Hitag2 at 125 kHz, Megamos at 125 kHz, Texas Instruments DST/DST40 at 134.2 kHz), and a long tail of older industrial tags. The data rate is low — typically 1-8 kbps — and a full card read takes a few hundred milliseconds. The coupling is sub-cm with a small antenna; mid-range with a larger reader.

Cryptographically, the LF landscape is almost entirely unprotected. EM4100, the most common LF card globally, has no cryptography at all — the card emits a fixed 40-bit serial number repeatedly whenever it is in field, and any LF reader can read it. HID Prox carries a fixed Wiegand-format code, also unencrypted. Indala is similar — proprietary format, no cryptography. The Hitag2 family (used in mid-1990s through 2010s automotive immobilizers) carries a proprietary 48-bit stream cipher that was broken by Verdult, Garcia, and Balasch at USENIX Security 2012; recovery of the secret key from a target car takes less than six minutes with ordinary hardware.¹ The Megamos Crypto (used in many VW Group vehicles 2009-2015) was broken by Verdult, Garcia, and Ege at USENIX Security 2013 (publication was court-delayed for two years).² DST40 (used in older Texas Instruments-based automotive and ExxonMobil Speedpass tokens) was broken by Bono, Green, Stubblefield, Juels, Rubin, and Szydlo at USENIX Security 2005.³

The pattern across the LF family is consistent: when there is cryptography, it is proprietary 1990s-era design with key sizes around 40-48 bits, and the public-research community has broken essentially all of it. The defense at the LF layer is to migrate off LF entirely — most access-control deployments built since ~2010 use HF (iCLASS SE, MIFARE DESFire EV2/EV3) precisely because the LF cryptographic substrate has no viable upgrade path.

2.3 HF — 13.56 MHz

HF RFID at 13.56 MHz is where the cryptography lives. The coupling is still magnetic and the range is still short (~10 cm consumer-antenna), but the data rate is higher (106 kbps base, 212 / 424 / 848 kbps available, up to 6.78 Mbps in newer NFC profiles), and the standards explicitly architect cryptographic protections into the protocol. The major HF card-family standards are:

ISO/IEC 14443 Type A — the most-deployed HF physical layer. Modulation is 100% ASK from reader to card; subcarrier-modulated load modulation card-to-reader at 847.5 kHz. MIFARE Classic, MIFARE Plus, MIFARE Ultralight, MIFARE DESFire, and many proprietary cards live on Type A.
ISO/IEC 14443 Type B — alternative physical layer with 10% ASK reader-to-card and BPSK card-to-reader. Used in some banking applications, some national ID systems (French CNIE, some passport variants), and a smaller share of access-control deployments.
ISO/IEC 15693 — “vicinity” cards designed for slightly longer range (~50 cm in laboratory conditions, ~15-30 cm in practice). Lower data rate (~26 kbps). Used in some access-control deployments, ski-lift passes, library tags, and HID iCLASS Legacy (which sits on a proprietary modulation that derives from ISO 15693).
FeliCa — Sony’s proprietary HF protocol used in Japanese transit (Suica, Pasmo, Icoca) and Octopus cards in Hong Kong, also in some payment systems. Different physical layer from ISO 14443; higher data rate (212 / 424 kbps); proprietary cipher with mixed disclosure record.
NFC Forum specifications — layered on top of ISO 14443A, ISO 14443B, ISO 15693, and FeliCa as the four NFC tag-type physical layers (NFC-A through NFC-F). NFC is treated in detail in §4.

The HF cryptographic landscape ranges from broken to strong. MIFARE Classic’s Crypto-1 cipher was broken by Karsten Nohl and Henryk Plötz at the 24th Chaos Computer Congress in December 2007, then formalized cryptanalytically by Courtois, Nohl, and O’Neil in IACR ePrint 2008/166 (April 2008), with the full key recovery in ~200 seconds on a PC given a single known IV.⁴ ⁵ The Radboud University team (Garcia, de Koning Gans, Verdult, et al.) extended the work in “Wirelessly Pickpocketing a MIFARE Classic Card” (S&P 2009), demonstrating practical attacks against deployed transit systems.⁶ iCLASS Legacy fell to Garcia, de Koning Gans, Verdult, and Meriac at USENIX WOOT 2011 (“Exposing iClass Key Diversification”) and ESORICS 2012 (“Dismantling iClass and iClass Elite”); the master keys were derived and the cards were demonstrated to be no more secure than single-DES against a chosen-plaintext attack.⁷ ⁸ DESFire EV1’s hardware implementation suffered a side-channel disclosure (Oswald and Paar, CHES 2011); the protocol-level AES authentication is sound, but specific EV1 silicon batches were vulnerable to differential-power-analysis key extraction with physical access. DESFire EV2 (2016) and EV3 (2021) carry AES-128 authentication, hardware-attack hardening, and remain unbroken at the cryptographic-protocol level as of early 2026.

2.4 UHF — 860-960 MHz (orientation only)

UHF RFID covers ~860 MHz (EU) through ~960 MHz (US) and operates by far-field radiative coupling — the field propagates as a wave, not as a near-zone coupling, and the range is correspondingly larger (typically 3-12 m for passive tags, much further for battery-assisted tags). The dominant standard is EPC Gen2 (ISO/IEC 18000-63), the supply-chain inventory protocol used by retailers, logistics operators, and asset-tracking deployments. The security model is minimal — the original EPC Gen2 spec includes a 32-bit “kill” PIN and a 32-bit “access” PIN, both transmitted in the clear; Gen2v2 added the option for cryptographic tag authentication via ECC, but adoption is limited and most deployed Gen2 tags carry essentially no authenticated security. UHF tag cloning is trivial (the tag’s identifier is broadcast on demand); UHF tag forging against most systems requires only a writable Gen2 tag and a UHF reader/writer.

UHF is out of scope for this volume because the contactless-credential population that matters for physical-access tradecraft (the population that says “I’m Jeff and I’m authorized to enter this building”) is overwhelmingly LF or HF, not UHF. The UHF population is supply-chain and asset-tracking — important commercially, but not the security-research center of gravity. Specialist research on UHF tradecraft does exist (Gen2 selective-write attacks, distance-bounding research, RAIN RFID privacy attacks) but lives outside the working scope of this reference cluster.

2.5 The frequency comparison

Property	LF (125-134 kHz)	HF (13.56 MHz)	UHF (860-960 MHz)
Coupling mechanism	Magnetic (near-field; 1/r³)	Magnetic (near-field; 1/r³)	Radiative (far-field; 1/r²)
Wavelength	~2400 m	~22 m	~33 cm
Read range (consumer antenna)	~10 cm	~5-10 cm	~3-12 m
Read range (extended antenna)	~3 ft (Bishop Fox Tastic / HID MaxiProx 5375)	~30 cm specialized	~30+ m specialized
Data rate (typical)	1-8 kbps	106 kbps base; up to 6.78 Mbps NFC	26-640 kbps
Antenna geometry (card)	Multi-turn coil, ~50 mm diameter	Multi-turn coil, ~35-50 mm	Dipole, ~70 mm
Cryptography	Almost none (Hitag2 / Megamos / DST40 broken)	Crypto-1 (broken), DES iCLASS (broken), AES (strong: DESFire EV2/EV3, iCLASS SE)	Almost none (32-bit PINs; Gen2v2 ECC optional)
Standardization	Proprietary per vendor (EM4100, HID Prox, Indala, Hitag2)	ISO 14443 A/B, ISO 15693, FeliCa, NFC Forum	ISO 18000-63 (EPC Gen2 / Gen2v2)
Population	Legacy access control, immobilizers, livestock, pet implants	Modern access control, transit, payment, passports, NFC consumer	Supply chain, retail inventory, asset tracking
Primary security research lineage	Bono/Juels DST40 2005; Verdult Hitag2 2012; Verdult Megamos 2013	Nohl/Plötz MIFARE 2007; Garcia iCLASS 2011/2012; Oswald/Paar DESFire EV1 2011	Distance-bounding research; selective-write academic
Hack Tools coverage	Proxmark3 RDV4, Flipper Zero (built-in LF subsystem), iCopy-X	Proxmark3 RDV4, Flipper Zero (ST25R3916), Chameleon Ultra, HydraNFC, ACR122U	Out of scope (Proxmark3 has no UHF antenna; specialty Impinj/Zebra hardware required)

Table 15.1 — LF / HF / UHF RFID comparison. The frequency choice drives essentially every other operational property; the security-research community’s attention has concentrated on LF (where the cryptography is broken or absent) and HF (where the cryptography is the active research front and where deployment is still migrating off broken families like MIFARE Classic and iCLASS Legacy). UHF is its own commercial ecosystem with its own research community and its own gear; it appears here for orientation, not as part of the working RFID-tradecraft toolkit.

2.6 Why the LF / HF distinction matters operationally

Three operational consequences fall out of the LF / HF split that the working operator carries into every engagement:

Reader hardware is band-specific. A 125 kHz reader is a different physical device — different antenna geometry, different RF stage, different protocol stack — from a 13.56 MHz reader. The Proxmark3 RDV4 is one of the few platforms that integrates both, and it does so by switching between two physical antennas. The Flipper Zero similarly carries a dual-band antenna PCB but uses different MCU subsystems for each (the 125 kHz LF read/write/emulate is implemented in firmware on the STM32 MCU because no dedicated LF chip is on board, while the 13.56 MHz NFC subsystem uses the dedicated ST25R3916 chip). A reader designed only for 13.56 MHz cannot read a 125 kHz card; a reader designed only for 125 kHz cannot read a 13.56 MHz card. This is why “RFID research” in practice usually means owning a multi-band tool.

Migration off broken families is incremental. Most enterprise access-control deployments installed before ~2010 use LF (HID Prox is the dominant family in North America; EM4100-class in Europe and Asia). Migration to HF DESFire EV2/EV3 or iCLASS SE typically happens at refresh cycles (7-15 years for access-control infrastructure), so the deployed LF population in 2026 remains very large. The defender’s question — “is my system using a cryptographically defeated card family?” — is non-trivial because the migration story is “we’re moving to HF” rather than “we have moved to HF.” Many sites carry mixed LF/HF readers during multi-year transitions, which preserves the LF attack surface for the lifetime of the legacy card.

Cloneability scales with cryptography, not with frequency. The naive expectation — “HF is more secure because the cards are newer” — is wrong in the general case. An EM4100 LF card and a MIFARE Classic 1k HF card are both trivially cloneable; the operator can extract the full credential and write it to a programmable card in a few seconds with the right tool. A DESFire EV3 HF card is not cloneable because the AES-128 protocol does not give the attacker the key material to write a replica. The frequency tells you which band you’re working in; the card family within the band tells you what the security model is. §3 catalogs the families.

3. The card families — reference catalog

This section catalogs the major contactless-card families operationally relevant to physical-access security research. The catalog is reference-shaped — each family has a security model, a known-attack status, and a typical deployment context. The pattern is consistent: the older, simpler, smaller-keyspace families have been broken at the public-research level; the modern AES-based families (DESFire EV2/EV3, iCLASS SE, MIFARE Plus in EV2 mode) are operationally secure when correctly deployed. The attacker’s job at this layer is therefore usually to figure out which family a target system uses, then apply the corresponding capability from the §5 attack catalog.

A MIFARE-format combicard combining a chip-and-PIN contact interface with a 13.56 MHz contactless MIFARE coil — the canonical reference for the HF coil geometry that powers every contactless card. … — A MIFARE-format combicard combining a chip-and-PIN contact interface with a 13.56 MHz contactless MIFARE coil — the canonical reference for the HF coil geometry that powers every contactless card. The visible spiral antenna is the multi-turn loop that couples magnetically with the reader's antenna; the integrated circuit at the antenna's center is the chip that handles the protocol stack (ISO 14443 A) and, in the case of MIFARE Classic 1k/4k, runs the now-broken Crypto-1 cipher. The combicard physical layout is identical across the MIFARE Classic, MIFARE Plus, MIFARE DESFire, and MIFARE Ultralight families — the cryptographic substrate inside the chip is what differs.

Figure 15.1 — MIFARE combicard. Photo: File:Mifare combicard2.jpg by Mcapdevila. License: CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AMifare%20combicard2.jpg).

3.1 LF card families

EM4100 / EM4102 (EM Microelectronic) — the baseline LF access-control card globally. 64-bit fixed-format identifier (40-bit serial + customer code + parity bits), no cryptography, no write capability on EM4100 itself (write-once-by-laser at the factory; the EM4102 and later EM4305/EM4205 add field-writable variants). The card emits its identifier continuously whenever in field; any 125 kHz reader sees the same 40-bit identifier. Cloning is trivial: capture the identifier with a Proxmark3 or Flipper Zero, write it to a T5577 or EM4305 programmable card. Population: enormous — EM4100 is the dominant low-cost LF card globally, used in countless small-business access-control deployments, gym memberships, hotel keys (older), parking-access tags.

HID Prox (HID Global) — the dominant LF access-control family in North America. Wiegand-format codes; the most common formats are 26-bit (H10301), 34-bit (H10306), 35-bit (Corporate 1000), and 37-bit (H10302/H10304). The card emits the Wiegand code on demand. No cryptography. Cloning is trivial with a Proxmark3 (lf hid read then lf hid clone) or with a Flipper Zero. The Wiegand format encodes a facility code (which site/installation the card belongs to) and a card number (which card within the site); some attackers harvest facility codes from a single captured card and then generate sequential card numbers to brute-force valid card IDs. HID has been moving customers off Prox to iCLASS SE / SEOS for over a decade, but the deployed Prox base remains very large.

Indala (HID Global) — a different proprietary LF format from HID; the result of HID’s acquisition of Indala in 2000. Similar architectural pattern to HID Prox: fixed code, no cryptography, trivially cloneable. Less common than Prox in 2026 deployments but still present in legacy installations.

AWID (Applied Wireless ID, now Bosch / RBtec) — another fixed-code LF family; 26-bit format common. Cloneable. Lower deployment population than HID Prox or EM4100.

Hitag2 (NXP, originally Philips Semiconductors) — proprietary stream cipher, 48-bit key. Used in mid-1990s through 2010s automotive immobilizers across at least 34 car makes and 200+ car models. Broken by Verdult, Garcia, and Balasch at USENIX Security 2012 — key recovery in under six minutes with ordinary hardware.¹ Industry response was a slow migration to AES-based immobilizers (Hitag AES, Megamos AES, others), still incomplete in the deployed used-car population as of 2026.

Megamos Crypto (Thales / EM Microelectronic, used by VW Group) — proprietary 96-bit cipher (effective security ~49 bits due to design flaws). Broken by Verdult, Garcia, and Ege at USENIX Security 2013; publication delayed two years by court order at Volkswagen’s request before being released in 2015.² Used in VW Group immobilizers ~2009-2015; replaced with stronger ciphers in subsequent model years.

DST40 / DST80 (Texas Instruments) — 40-bit and 80-bit proprietary block ciphers used in Texas Instruments DST tags. DST40 was broken by Bono, Green, Stubblefield, Juels, Rubin, and Szydlo at USENIX Security 2005 — full key recovery in hours via parallel brute force on FPGAs. DST80 followed (Wouters, Marin, Ashur, Gierlichs, and Preneel, USENIX Security 2020).⁹ Used in many older ExxonMobil Speedpass tokens (now discontinued) and older Texas Instruments-based automotive immobilizers.

iCLASS Legacy (HID Global) — technically HF at 13.56 MHz, not LF, but cataloged here alongside the broken legacy families because of the security-pattern parallel. Uses ISO 15693 physical layer with a proprietary higher-layer protocol. Cryptography is DES-based with key diversification. Broken by Garcia, de Koning Gans, Verdult, and Meriac in 2011 and 2012; the master keys are publicly known and the cards are no more secure than single-DES.⁷ ⁸ HID has been migrating customers off Legacy to iCLASS SE / SEOS for over a decade, but the deployed Legacy base remains material in 2026.

3.2 HF card families

MIFARE Classic 1k / 4k (NXP) — the most-deployed HF card globally. ISO 14443A physical layer; proprietary Crypto-1 stream cipher; 48-bit keys; 1 KB (Classic 1k) or 4 KB (Classic 4k) of memory organized as 16 or 40 sectors with two 48-bit keys per sector (Key A, Key B). Broken by Nohl and Plötz at 24C3 (December 2007), then formalized by Courtois, Nohl, and O’Neil (IACR ePrint 2008/166, April 2008), with full key recovery in ~200 seconds on a PC given a single known IV.⁴ ⁵ Subsequent work (Garcia et al., S&P 2009 “Wirelessly Pickpocketing a MIFARE Classic Card”) demonstrated practical attacks against deployed transit systems.⁶ The standard tooling — mfoc (Mifare Classic Offline Cracker, by Norbert Szetei) and mfcuk (Mifare Classic Universal toolKit) — recovers all sector keys from a target card in minutes. Despite the cryptanalytic break, MIFARE Classic remains widely deployed because the migration cost to MIFARE Plus or DESFire is large; many transit systems and small-scale access-control deployments still use it.

MIFARE Plus (NXP) — the migration card from Classic to AES. Supports four security levels (SL0-SL3) negotiated at personalization; SL3 uses AES-128 authentication and is operationally secure against the public attack landscape. Backward-compatible at SL1 with MIFARE Classic readers — which means MIFARE Plus deployed at SL1 inherits Classic’s weaknesses; defenders need SL3 to get the AES protection.

MIFARE DESFire EV1 / EV2 / EV3 (NXP) — the modern, cryptographically strong NXP card. ISO 14443A. EV1 supports 2K3DES, 3K3DES, and AES-128 authentication; EV2 (2016) is AES-only with additional features (transaction MAC, originality check, virtual cards); EV3 (announced June 2, 2020) adds Secure Unique NFC (SUN) messaging — a tap-unique cryptographic authentication message generated per tap that yields tap-unclonable URLs — plus a Transaction Timer feature for MITM mitigation, greater operating distance, and delegated application management for over-the-air key updates via NFC-enabled smartphones. EV3 IC is Common Criteria EAL 5+ certified. Cryptographically the protocol design is sound and the public attack landscape against modern EV2/EV3 silicon is limited to side-channel attacks requiring physical access to specific hardware (Oswald and Paar showed DPA-based key extraction against specific EV1 silicon batches at CHES 2011, since hardened).¹⁰ DESFire EV2/EV3 is the default secure-HF-card recommendation in 2026; new deployments target this family.

MIFARE Ultralight / Ultralight C / Ultralight EV1 (NXP) — low-cost MIFARE family without Crypto-1. Ultralight has no authentication at all; Ultralight C adds 3DES-based authentication; Ultralight EV1 adds an originality signature. Used in disposable transit tickets, event passes, hotel keys. Ultralight C’s 3DES authentication has known implementation weaknesses in some deployments but the protocol itself is sound.

NTAG 21x (NXP) — NFC Forum Type 2 tag family. NTAG213 (180 bytes user memory), NTAG215 (504 bytes), NTAG216 (888 bytes), and the newer NTAG413/424 DNA with SUN messaging. Used pervasively in NFC consumer applications — tap-to-pay smart tags, marketing tags, Amiibo-style figurines, the NFC tag chip you stick on a lamp. NTAG213/215/216 have no cryptography (a password write-protect option exists but is short and bypassable). NTAG424 DNA adds AES-128-based SUN messaging that produces a tap-unique URL; this is the cryptographically-strong NTAG family.

iCLASS / iCLASS Elite (HID Global) — broken as cataloged in §3.1. Used in many HID access-control deployments through ~2014.

iCLASS SE / iCLASS Seos (HID Global) — the secure-migration path from iCLASS Legacy. iCLASS SE adds 3DES- and AES-based credential framework support; iCLASS Seos is the most modern variant, AES-128-based, and structurally equivalent to DESFire EV2 / EV3 for the access-control use case. Operationally secure against the public attack landscape as of 2026; the migration story for HID customers is iCLASS Legacy → iCLASS SE → iCLASS Seos.

LEGIC Prime / LEGIC Advant (LEGIC Identsystems) — proprietary HF family widely deployed in European access-control (corporate, university, ski resorts). LEGIC Prime is the older, weaker variant; partial cryptanalysis exists in the public literature.¹¹ LEGIC Advant (2007+) uses 3DES and AES authentication and is operationally secure when correctly configured.

FeliCa (Sony) — Japanese-domestic HF protocol used in transit (Suica, Pasmo, Icoca, Manaca), payment (Edy, iD, QUICPay), and Octopus cards in Hong Kong. Uses the proprietary Felica protocol (different physical layer from ISO 14443) and a proprietary cipher. Mixed public-research record; the cryptanalysis has been less prolific than for Crypto-1, but research papers exist demonstrating partial attacks against specific card variants. FeliCa is also one of the four NFC Forum tag-type physical layers (NFC-F) and is supported by every modern smartphone NFC stack.

ICAO MRTD / Biometric passport (ICAO Doc 9303) — ISO 14443-based contactless smart-card protocol embedded in modern passports. Uses Basic Access Control (BAC) or PACE (Password-Authenticated Connection Establishment) for the link-layer authentication, then Active Authentication / Chip Authentication / Terminal Authentication for the document content. The cryptography is sound in the protocol; the deployed implementations have had varied issues over the years (BAC’s effective entropy is bounded by the printed MRZ, which can be obtained by skimming the passport’s photo page). Not typically an access-control target but listed here for completeness because passport readers are part of the broader HF ecosystem.

3.3 The card-family reference table

Card family	Frequency	Vendor	Cryptography	Known attacks	Typical deployment	Cloneable?
EM4100 / EM4102	LF 125 kHz	EM Microelectronic	None	N/A — fixed code	Generic LF access control, gym tags, parking	Trivially
HID Prox	LF 125 kHz	HID Global	None	N/A — fixed Wiegand code	Dominant LF access control in North America	Trivially (Proxmark3 / Flipper)
Indala	LF 125 kHz	HID Global (acq. 2000)	None	N/A — fixed code	Legacy access control	Trivially
AWID	LF 125 kHz	Bosch / RBtec	None	N/A — fixed code	Legacy access control	Trivially
Hitag2	LF 125 kHz	NXP	Proprietary 48-bit stream	Verdult-Garcia-Balasch USENIX 2012 (~6 min key recovery)	Automotive immobilizer ~1995-2015	After key recovery
Megamos Crypto	LF 125 kHz	Thales / EM	Proprietary 96-bit (eff. 49)	Verdult-Garcia-Ege USENIX 2013 (publication delayed by court 2 yrs)	VW Group immobilizer ~2009-2015	After key recovery
DST40 / DST80	LF 134.2 kHz	Texas Instruments	Proprietary 40 / 80-bit	Bono et al. USENIX 2005 (DST40); Wouters et al. USENIX 2020 (DST80)	Legacy ExxonMobil Speedpass, TI-based immobilizers	After key recovery
MIFARE Classic 1k/4k	HF 13.56 MHz (ISO 14443A)	NXP	Crypto-1 (48-bit stream)	Nohl-Plötz 24C3 2007; Courtois-Nohl-O’Neil ePrint 2008; Garcia et al. S&P 2009	Transit, legacy access control	Yes — `mfoc` / `mfcuk` recover all sector keys in minutes
MIFARE Plus	HF 13.56 MHz	NXP	AES-128 at SL3	None known at SL3	Migration path from Classic	Not at SL3
MIFARE DESFire EV1	HF 13.56 MHz	NXP	3DES + AES-128	Oswald-Paar CHES 2011 (DPA, requires physical access)	Modern access control, transit	Not against EV1 silicon without hardware attack
MIFARE DESFire EV2 / EV3	HF 13.56 MHz	NXP	AES-128 + AES-256	None public	Modern access control, transit, NFC payments	No
MIFARE Ultralight	HF 13.56 MHz	NXP	None	N/A	Disposable tickets, hotel keys	Trivially
MIFARE Ultralight C	HF 13.56 MHz	NXP	3DES	Implementation issues; protocol sound	Slightly-better disposable	After key recovery if applicable
NTAG 213/215/216	HF 13.56 MHz (ISO 14443A)	NXP	None (optional 32-bit password)	N/A	NFC consumer tags, Amiibo, marketing	Yes
NTAG 424 DNA	HF 13.56 MHz	NXP	AES-128 + SUN messaging	None known	Tap-unique URL applications	No
iCLASS Legacy	HF 13.56 MHz (ISO 15693-derived)	HID Global	Proprietary DES + hash0	Garcia et al. WOOT 2011 + ESORICS 2012 (master keys known)	Legacy HID access control	Yes — master keys public
iCLASS SE / iCLASS Seos	HF 13.56 MHz	HID Global	3DES / AES-128	None known at Seos AES	Modern HID access control	No
LEGIC Prime	HF 13.56 MHz	LEGIC Identsystems	Proprietary	Plötz / Nohl partial disclosures	Legacy European access control	Variable
LEGIC Advant	HF 13.56 MHz	LEGIC Identsystems	3DES / AES	None public	Modern European access control	No
FeliCa	HF 13.56 MHz	Sony	Proprietary	Partial public research; mixed record	Japanese transit and payment; Octopus	Variable
ICAO MRTD (passport)	HF 13.56 MHz (ISO 14443A/B)	Per-country	BAC / PACE + AA / CA / TA	Effective BAC entropy bounded by MRZ; protocol sound	Biometric passports	No (cloning the chip data is possible but useless without the signing keys)
EPC Gen2 / RAIN RFID	UHF 860-960 MHz	Multiple	32-bit PINs (Gen2); ECC optional (Gen2v2)	Trivial cloning; Gen2v2 adoption limited	Supply chain, retail inventory	Trivially

Table 15.2 — Contactless card-family reference catalog. The pattern that emerges across the table is consistent across both LF and HF: pre-2000-era proprietary cryptography has been broken at the public-research level (Crypto-1, iCLASS Legacy DES, Hitag2, Megamos, DST40); modern AES-based families (DESFire EV2/EV3, iCLASS Seos, MIFARE Plus SL3, NTAG 424 DNA) are operationally secure. The migration path for every major vendor — NXP, HID Global, LEGIC — is from a broken or aging cipher to AES, and the timeline of that migration is the practical determinant of what attack surface a given site presents in 2026.

3.4 The card-family lineage — how the migrations connect

                              ACCESS-CONTROL CARD LINEAGE
                              ───────────────────────────

   ┌─────────────────────────┐     ┌─────────────────────────┐
   │  HID PROX (LF, ~1990s)  │     │  EM4100 (LF, ~1990s)    │
   │  Wiegand fixed code     │     │  Fixed 40-bit serial    │
   │  No crypto              │     │  No crypto              │
   └────────────┬────────────┘     └─────────────────────────┘
                │                                  │
                │ (HID migration since ~2005)      │ (no migration; EM cards
                │                                  │  installed once, stay)
                ▼                                  │
   ┌─────────────────────────┐                     │
   │  iCLASS LEGACY (HF)     │                     │
   │  DES + hash0            │                     │
   │  Broken Garcia 2011/12  │                     │
   │  Master keys public     │                     │
   └────────────┬────────────┘                     │
                │                                  │
                │ (HID migration since ~2014)      │
                ▼                                  │
   ┌─────────────────────────┐                     │
   │  iCLASS SE / Seos (HF)  │                     │
   │  3DES / AES-128         │                     │
   │  Operationally secure   │                     │
   └─────────────────────────┘                     │
                                                   │
   ┌─────────────────────────┐                     │
   │  MIFARE Classic (HF,    │ ◄───────────────────┘
   │  introduced 1994)       │  (when migrating LF-EM to HF,
   │  Crypto-1 broken 2007   │   small-scale buyers often
   │  Still widely deployed  │   chose Classic for cost; many
   └────────────┬────────────┘   are still on Classic in 2026)
                │
                │ (NXP migration path since ~2010)
                ▼
   ┌─────────────────────────┐
   │  MIFARE Plus (SL1-SL3)  │
   │  AES at SL3             │
   └────────────┬────────────┘
                │
                ▼
   ┌─────────────────────────┐
   │  MIFARE DESFire EV2/EV3 │
   │  AES-128 + transaction  │
   │  MAC + SUN messaging    │
   │  Default secure pick    │
   └─────────────────────────┘

                              AUTOMOTIVE IMMOBILIZER LINEAGE
                              ──────────────────────────────

   ┌─────────────────────────┐
   │  DST40 (TI, ~1990s)     │
   │  40-bit cipher           │
   │  Broken Bono 2005        │
   └────────────┬────────────┘
                │
                ▼
   ┌─────────────────────────┐
   │  Hitag2 (NXP, ~1995-    │
   │  2015)                  │
   │  48-bit stream cipher   │
   │  Broken Verdult 2012    │
   └────────────┬────────────┘
                │
                ▼
   ┌─────────────────────────┐
   │  Megamos / DST80 / Hitag│
   │  AES (~2015+)           │
   │  AES-128                │
   │  Operationally secure   │
   └─────────────────────────┘

Figure 15.2 — The access-control and automotive-immobilizer card-family migration trees. The pattern across both is identical: a 1990s proprietary cipher with 40-48 bit keyspace ships, runs for 10-15 years, is broken by the public-research community, and gets migrated to AES on a 5-10 year refresh cycle. The lineage that matters operationally is not “what is the strongest available card?” but “what does the deployed base look like at the target site?” — and the answer is almost always a mix of broken and modern families running concurrently during a multi-year migration.

4. NFC — the protocol stack and the attack surface

Near Field Communication (NFC) is the HF 13.56 MHz subset specifically architected for short-range two-way communication between consumer devices — smartphones, tags, payment terminals, peripherals. NFC sits on top of the ISO 14443 and ISO 15693 physical layers cataloged in §2.3, adding the NFC Forum’s higher-level protocol layers (the four tag types, the operating modes, NDEF, the application layer). The NFC ecosystem is the dominant consumer-facing application of HF RFID — every modern smartphone has NFC, NFC tags are sold by the bagful at hardware stores, NFC payment terminals are everywhere, and the security-research surface has matured correspondingly.

An NFC tag chip in its glass-encapsulated package — the physical form factor that ships in NFC stickers, embedded in lamps and posters, and in the long tail of NFC-enabled consumer products. The ch… — An NFC tag chip in its glass-encapsulated package — the physical form factor that ships in NFC stickers, embedded in lamps and posters, and in the long tail of NFC-enabled consumer products. The chip is connected to a multi-turn coil antenna (not visible in this view) that handles the inductive coupling with the reader; the chip itself implements the NFC Forum protocol stack appropriate to its tag type (Type 1 / 2 / 4 / 5 NFC-A / B / F / V). NTAG 213, NTAG 215, NTAG 216, and the newer NTAG 424 DNA are the most-common consumer NFC tag chips as of 2026.

Figure 15.3 — NFC tag chip. Photo: File:NFC Tag Chip.jpg by HenryWortel. License: CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3ANFC%20Tag%20Chip.jpg).

4.1 NFC standards and the protocol stack

The NFC standards are layered atop ISO 14443 and ISO 15693, with the NFC Forum specifications adding the consumer-facing protocol layers. The canonical reference is NFC Forum’s NFC Digital Protocol Technical Specification and the four tag-type specifications.¹²

   ┌──────────────────────────────────────────────────────────────────┐
   │                          APPLICATION                             │
   │      (smartphone app, embedded firmware, payment app, etc.)      │
   └─────────────────────────────────┬────────────────────────────────┘
                                     │
   ┌─────────────────────────────────▼────────────────────────────────┐
   │  NDEF  (NFC Data Exchange Format)                                │
   │                                                                  │
   │  Standardized record format for storing structured data on tags  │
   │  and exchanging it between devices: URI, Text, MIME, Smart       │
   │  Poster, External Type records, etc. The format every NFC tag-   │
   │  writing app produces.                                           │
   └─────────────────────────────────┬────────────────────────────────┘
                                     │
   ┌─────────────────────────────────▼────────────────────────────────┐
   │  NFC TAG TYPE PROTOCOL  (Type 1 / 2 / 4 / 5)                     │
   │                                                                  │
   │  Type 1 (Topaz; ISO 14443A) — small, simple, rare in 2026        │
   │  Type 2 (NTAG / Ultralight; ISO 14443A) — most-common consumer   │
   │  Type 4 (DESFire-class; ISO 14443A/B) — large memory, optional   │
   │          AES; supports both card emulation and tag modes         │
   │  Type 5 (ISO 15693 / NFC-V) — vicinity range; used for inventory │
   │          and some access-control                                 │
   │  NFC-F (FeliCa) — Japanese transit; separate tag-type but covered│
   │          by NFC Forum stack                                      │
   └─────────────────────────────────┬────────────────────────────────┘
                                     │
   ┌─────────────────────────────────▼────────────────────────────────┐
   │  NFC DIGITAL PROTOCOL                                            │
   │                                                                  │
   │  Activation, collision resolution, frame format, anti-collision  │
   │  for ISO 14443A (Type 1, 2, 4A), ISO 14443B (Type 4B), ISO 15693 │
   │  (Type 5), and FeliCa (NFC-F). The unifying upper-physical-layer │
   │  framework that lets one NFC controller speak to any tag type.   │
   └─────────────────────────────────┬────────────────────────────────┘
                                     │
   ┌─────────────────────────────────▼────────────────────────────────┐
   │  NFC ANALOG SPECIFICATION                                        │
   │                                                                  │
   │  RF analog requirements — antenna geometry, field strength,      │
   │  modulation depth, subcarrier characteristics. The bottom-layer  │
   │  specification that determines NFC compliance.                   │
   └─────────────────────────────────┬────────────────────────────────┘
                                     │
   ┌─────────────────────────────────▼────────────────────────────────┐
   │  ISO 14443 A/B  +  ISO 15693  +  FeliCa  (PHY layers)            │
   │                                                                  │
   │  The underlying physical-layer standards on which NFC sits.      │
   │  13.56 MHz inductively-coupled near-field communication.         │
   └──────────────────────────────────────────────────────────────────┘

Figure 15.4 — The NFC protocol stack as the NFC Forum layers it onto the underlying ISO 14443 / 15693 / FeliCa physical-layer standards. The two parts of the stack that the working operator actually interacts with are NDEF (the format the operator writes to a tag) and the NFC tag type protocol (the framework that determines whether nfc-list or the smartphone NFC reader sees the tag at all). The lower layers are transparent — the operator picks a tag chip family in §3, and the analog and digital protocol layers come along for the ride.

4.2 NFC operating modes

NFC defines three operating modes, two of which are connection-oriented and one of which has been increasingly deprecated:

Reader / Writer mode (R/W mode). The device acts as an NFC reader — it powers up a passive NFC tag in its field and reads or writes the tag’s contents. This is the mode the operator uses when reading an NFC tag with a smartphone, writing a URL to a sticker tag with NFC Tools, dumping a MIFARE Classic with mfoc. The reader provides the RF field; the tag is passive.
Card Emulation mode (CE mode). The device acts as if it were a passive NFC card — it modulates the field that an external reader provides, emulating an ISO 14443A or 14443B card. This is the mode Apple Pay, Google Pay, Samsung Pay, and HCE-based apps use when the smartphone is held to a payment terminal. The Chameleon Ultra, ProxGrind ChameleonTiny, and Flipper Zero all support card emulation across multiple HF families.
Peer-to-Peer mode (P2P mode). Two NFC-equipped devices exchange data without either being a tag — historically used for “Android Beam” file sharing and similar pairing handoffs. The NFC Forum deprecated P2P mode in 2019 (NFC Forum Spec 18) and Android removed Android Beam from Android 10 (2019); modern OSes use BLE pairing handoffs instead of NFC P2P for the same use cases. iOS never officially supported NFC P2P. P2P remains in the standard for backward compatibility but is essentially unused in 2026 consumer deployments.

4.3 NDEF — the NFC Data Exchange Format

NDEF (NFC Data Exchange Format) is the standardized record format for storing structured data on NFC tags and exchanging it between NFC devices. The format is simple — a sequence of one or more NDEF records, each with a Type Name Format (TNF) field, a Type field, an optional ID field, and a Payload field. The standard record types defined by the NFC Forum:

URI Record — a URL or URI. The most-common NDEF record on consumer tags; an NFC sticker with a URL on it is a tag with a URI Record encoding https://example.com/. Tapping the tag with a smartphone opens the URL in the default browser (after a user confirmation dialog on most modern phones).
Text Record — a plain text string with a language code.
Smart Poster — a URI Record bundled with a Text Record describing it and optional action codes (open browser, save for later, etc.). Designed for marketing posters; common in pre-2015 NFC tag deployments, less common since.
MIME Record — arbitrary content with a MIME type. Used for images, vCards, calendar invites, anything not a URL or text.
External Type Record — vendor-defined types, namespaced by domain. The mechanism for application-specific tag formats (Google’s Android Application Records, Sony’s PlayStation NFC types, the Amiibo NFC format, etc.).
Empty Record — a placeholder record with no content. Rare.
Unknown / Unchanged Records — for chunked or unknown-type records.

A typical consumer NFC tag (an NTAG213 sticker bought in bulk) ships pre-formatted with an empty NDEF message; an app like NFC Tools writes a URI Record to it; the tag is then ready to be tapped to open the URL. The whole payload — TLV wrappers, NDEF header, URI Record — typically fits in ~120 bytes of an NTAG213’s 180-byte capacity. The NTAG215/216 (504 / 888 bytes) supports correspondingly longer payloads.

4.4 Host Card Emulation (HCE)

Host Card Emulation (HCE) is the Android API (and iOS Core NFC equivalent since iOS 13) that lets a smartphone app — running in user space, not in a secure-element chip — act as the NFC card on the device’s NFC controller. Before HCE (Android 4.4 / KitKat, 2013), card emulation required a hardware Secure Element (SE) on the phone, controlled by the carrier or the OEM, and apps had to negotiate access to the SE through a labyrinth of trusted-services-manager intermediaries. HCE put the card-emulation surface in the hands of any Android app developer. On the Apple side, the trajectory was slower: iOS 11 (2017) first opened NFC tag reading to third-party apps via Core NFC; iOS 13 (2019) extended that to writing and (partial) HCE; iOS 14+ progressively widened the API surface.

The security model of HCE shifts the trust boundary from the SE to the app’s host environment. The app receives APDU commands from the NFC reader through the NFC controller; the app processes them in user-space code; the app sends APDU responses back. For payment applications, HCE typically pairs with cloud-tokenization services (the actual payment credential is a short-lived token, not the underlying PAN, and is provisioned to the device on demand). For loyalty / transit / access-control applications, the app holds the credential directly.

The HCE attack surface is mostly implementation attacks — a malicious Android app that requests NFC permission can selectively respond to APDU commands; if a payment terminal sends a transaction APDU to a non-payment app, the response would simply be wrong and the transaction would fail, but the AID-routing layer in the Android NFC stack does the dispatch correctly when implementations are conformant. The interesting HCE research surface has been in (a) AID-conflict attacks where two apps claim the same AID, and (b) implementation flaws in specific apps that don’t validate the APDU stream they receive. iOS 13’s Core NFC HCE equivalent has a tighter security model; only one app at a time can claim the foreground NFC reader role, and the AID claims are managed by Apple.

4.5 NFC operating-mode and attack-surface summary

NFC mode	Typical application	Attack surface	Defensive posture
Reader / Writer	Tap to open URL; mfoc/mfcuk dumping; NFC Tools writing	Malicious NDEF (URL phishing, intent injection, app handler abuse); skim attacks against bypassed card readers	OS-level URL confirmation prompts; intent-handler hardening; phishing-aware user training
Card Emulation (smartphone)	Apple Pay, Google Pay, transit fare, HCE apps	AID-conflict attacks; APDU parser flaws in apps; cloud-tokenization compromise	Tokenization (not card-data) for payments; per-AID app validation; secure-element fallback for highest-value apps
Card Emulation (dedicated emulator)	ChameleonUltra cloning attacks; Flipper NFC emulate	Used for cloning/replay against weak HF families	Migrate target system off broken families (Classic, iCLASS Legacy)
Peer-to-Peer (deprecated)	Historical Android Beam	Largely retired in deployed clients	Disable in NFC settings; deprecated in NFC Forum spec 18; not present in iOS
Passive tag (Type 1-5)	NFC stickers, lamps, posters, badges, payment cards	Cloning (Type 2 trivially); NDEF malicious payloads; URL phishing	Use SUN-messaging tags (NTAG 424 DNA) for tap-unique URLs; avoid blanket-tap-any-tag user habits

Table 15.3 — NFC operating modes and the corresponding attack surfaces. The pattern: the reader-side attacks (a phone is tricked by a malicious tag into opening a URL, launching an intent, or processing a malformed NDEF record) live at the NDEF and app-handler layers. The card-side attacks (a card-emulator is used to clone or replay a credential against a deployed reader) live at the HF physical and cryptographic layers — these are the attacks of §5. The two halves are different threat models with different defenses.

4.6 The NFC consumer-application surface

The NFC consumer ecosystem has expanded dramatically since the 2014-2017 period when payment-NFC went mainstream. Smartphone NFC apps that the working operator should know exist:

NFC Tools (wakdev) — the most-used cross-platform consumer NFC app. Read and write NDEF records to NFC tags; read NFC card identifiers and capability data; format tags; password-protect NTAG21x tags. Pro version adds tasks and scripting. Available on Android and iOS.
NXP TagWriter — NXP’s official tag-writing app; supports MIFARE Plus, DESFire, NTAG, and Ultralight with full NDEF and proprietary-write capabilities. Android-only.
MIFARE Classic Tool (MCT) — Android app for reading, writing, cloning, and analyzing MIFARE Classic 1k/4k cards. Includes default key lists; integrates with the cracker libraries. Requires a phone with NXP NFC controller (most Android phones have this). The closest mobile equivalent to mfoc / mfcuk.
NFC Smart Tools — generic NFC-tag scanner with NDEF parsing; useful for “what is this tag?” reconnaissance.
Tagify — vCard / WiFi / payment-URL tag-creation focused.
iCopy-X (companion app) — companion mobile app for the iCopy-X cloning hardware, treated in §6.

The consumer-NFC app population is large, well-supported, and free or freemium. For most “read this NFC tag and tell me what it is” tasks the smartphone app stack is sufficient; the dedicated hardware (Proxmark3, Flipper, Chameleon) is needed when the work goes beyond NDEF into MIFARE Classic key recovery, iCLASS deep-dive, or LF cards that smartphones don’t speak.

4.7 The NFC attack surface in operational terms

Five attack patterns dominate the NFC attack-research literature; each maps cleanly onto a §5 capability or a §6 tool:

Tag cloning — copying a target NFC tag (typically NTAG213 / 215 / 216 or MIFARE Classic) to a programmable tag of the same family. Trivial for tags with no cryptography (NTAG 21x, MIFARE Ultralight) or broken cryptography (MIFARE Classic). The Flipper Zero’s NFC menu does this in three taps.
NDEF spoofing — writing a malicious NDEF record (typically a URI Record with a phishing URL) to a tag that the user then taps. The classic attack pattern against the “scan QR code on the table for the menu” — replace the legitimate NFC tag underneath with one that opens a credential-harvesting site.
Relay (NFC card-to-reader-across-distance) — using two NFC-capable devices (typically smartphones with the NFC-Relay app, or dedicated hardware like the NFCGate framework) to relay the NFC traffic between a victim’s card (in their wallet, far away) and a reader (in the attacker’s location). The attack defeats the proximity-based “you must be near the reader” implicit assumption. Most actively studied against payment cards and access-control cards; effective against systems without distance-bounding protections. Implementations of distance-bounding at the protocol level remain limited in deployed systems as of 2026.
Skimming via bypass readers — placing a malicious NFC reader behind a legitimate payment terminal or access-control reader; the malicious reader pre-skims the card before the legitimate reader sees it. Common against payment-terminal skimmer-overlay attacks; the credit-card industry’s response is point-to-point encryption at the terminal.
Cryptographic attacks against weak families — the MIFARE Classic key-recovery work; iCLASS Legacy master-key extraction; Hitag2 key recovery for automotive. These attacks target the protocol, not the deployment, and yield the credential material that subsequent cloning attacks use.

The NFC attack surface against modern AES-protected cards (DESFire EV2/EV3, iCLASS Seos, NTAG 424 DNA) is structurally limited — the cryptographic protocols are sound and the deployed implementations have mostly closed the historical side-channel issues. The attack surface against the legacy population (MIFARE Classic, iCLASS Legacy, EM4100, HID Prox, Ultralight, NTAG 213/215/216) is essentially open — the working operator extracts the credential in minutes with consumer hardware and clones it to a programmable tag.

5. Access-control attacks — capability-level catalog

This section catalogs the major attack capabilities against contactless access-control credentials at the capability level — what each attack does, what target population it applies against, what tool implements it, and what the operational countermeasure is. The catalog is reference-shaped, not an operational walkthrough. The operational steps for any of these attacks against a target system are explicitly out of scope; the discriminator between research and crime at this layer is authorization, not capability, and the same tool that runs the attack against the operator’s own hardware in their own lab runs it against a third-party’s system — the legality is in the paperwork, not the gear.

Posture — load-bearing callout. Badge cloning of physical access systems is criminal without written authorization. The Vol 8 (Grey Hat) authorization framing and the Vol 11 §3.6 engagement-paperwork stack — SOW, scope document, Rules of Engagement, get-out-of-jail letter — apply fully to RFID and NFC work against any system the operator does not own. Cloning your own gym card or your own building’s badge for backup is one threat model; cloning your neighbor’s badge or a delivered visitor pass is a federal CFAA event regardless of the technical ease. The §7 legal section frames this in statutory detail. The catalog below describes capabilities; the operator carries the responsibility for the authorization envelope every time the antenna goes near a card.

5.1 Clone — capture and write

The modal attack against the LF and weak-HF population: capture the credential’s identifying payload from a target card, write that payload to a blank programmable card of the same family, present the cloned card to the reader. Successful against every card family in §3 that lacks cryptography (EM4100, HID Prox, Indala, AWID, MIFARE Ultralight, NTAG 213/215/216) and every family whose cryptography has been broken at the public-research level (MIFARE Classic, iCLASS Legacy, Hitag2 with key recovery, Megamos with key recovery, DST40/DST80).

The standard programmable LF write target is the T5577 chip (also marketed as T5577-class blanks; the Atmel/Microchip T55x7 family). T5577 can emulate EM4100, HID Prox, Indala, AWID, Hitag (read-only), and several other LF formats by writing the appropriate identifier and selecting the modulation type. The standard programmable HF write target is the Magic UID (or “Chinese Magic”) MIFARE Classic — a writable MIFARE Classic 1k/4k card where the manufacturer block (block 0, which on a normal MIFARE card is read-only and carries the UID) is writable. Magic UID cards come in two main variants: Gen1 (proprietary backdoor commands to write block 0) and Gen2 (block 0 writable through standard MIFARE writes when the correct keys are known). Both let the operator clone a MIFARE Classic to a writable target including the UID.

Capability example (one Proxmark3 command sequence shown for orientation; not an operational walkthrough):

# Proxmark3 RDV4 — HID Prox capture and clone (LF, 125 kHz)

[usb] pm3 --> lf hid read              # capture HID Prox identifier from target
[lf hid] HID Prox TAG ID: 2006e22f0a (45 bits)
                  facility code: 113
                  card number: 12345

[usb] pm3 --> lf hid clone -r 2006e22f0a   # write the captured identifier to
                                            # a blank T5577 card in field

[lf hid] Cloned HID Prox to T5577.

Figure 15.5 — Proxmark3 RDV4 capability example showing LF HID Prox capture-and-clone. The lf hid read command captures the HID Prox identifier from a target card in field; the lf hid clone -r <identifier> command writes that identifier to a blank T5577 card. Total elapsed time including the field re-positioning between captures: under thirty seconds for a competent operator. The same workflow applies to EM4100 (lf em 410x read / lf em 410x clone), Indala (lf indala read / lf indala clone), and AWID (lf awid read / lf awid clone).

The HF Clone analog for MIFARE Classic — after the sector keys have been recovered (§5.4) — is a hf mf cload or hf mf restore operation that writes the dumped target card’s contents to a Magic UID writable target. The Flipper Zero equivalent for both bands is read-via-firmware-menu, save-to-SD, write-to-blank-of-same-family.

5.2 Replay

Replay is the degenerate case of clone — same as clone for any system that authenticates by checking only the static credential payload, which is most LF systems and most weak-HF systems. In the strict definition, replay means “transmit a previously-captured signal at the time of attack without writing it to a card first” — a one-shot impersonation. For LF/HF RFID this distinction is largely academic: the Proxmark3 can replay an LF captured signal directly (lf sim / lf simbidir), and the Flipper Zero can emulate a saved LF or HF card directly without writing it to a physical blank. Both modes accomplish the same operational outcome as clone (the reader sees the credential and accepts it) without producing a physical clone card.

The distinction that matters is whether the target system uses only a static credential check, or whether it uses challenge-response authentication. Static-credential systems (LF Prox, EM4100, MIFARE Classic with broken Crypto-1) are vulnerable to replay; challenge-response systems (DESFire EV2/EV3, iCLASS Seos, MIFARE Plus SL3) are not — the reader sends a fresh nonce, the card cryptographically processes it with its key, and a replayed historical response is detected because the nonce differs.

5.3 Relay

Relay attacks against NFC are the academic-research class of access-control attack — well-studied in the literature, occasionally demonstrated in proof-of-concept, but operationally rare against most deployments because of the latency, hardware, and physical-positioning requirements. The mechanism: two NFC-capable devices act as a relay pair. One device (the “ghost” or “leech”) sits near the target card or the victim with the legitimate credential; the other (“the proxy”) sits at the reader. The leech reads the card’s responses; the proxy emulates the card to the reader and forwards the reader’s challenges via an IP or Bluetooth back-channel to the leech, which forwards them to the actual card, which responds, with the response shuttled back through the back-channel to the proxy and presented to the reader. From the reader’s point of view, the relayed card is indistinguishable from the genuine card — the protocol exchange is correct, the cryptographic responses are valid, the timing is within the protocol’s allowed envelope (NFC has generous timing tolerances by design).

The standard relay reference implementations are NFCGate (Vincenz Mechler et al., academic) and the more-recent NFC Relay Android apps. Hardware-based relay platforms include the ChameleonMini, the Proxmark3 with a custom Lua script, and dedicated experimental relays built around Raspberry Pi + PN532 boards.¹³

Relay is most operationally relevant against automotive keyless-entry systems (Tesla, BMW, Mercedes have all had documented relay-attack windows over various model years; NCC Group’s March 2022 Tesla relay demonstration is one of many), where the proximity assumption is the entire security model. For building access control, relay is technically possible against any non-distance-bounded HF or LF system, but the operational complication of positioning the leech near the victim’s card while the proxy is at the reader is usually solved by the attacker getting the card itself rather than building a relay.

Defenses at the protocol level — distance-bounding protocols that cryptographically measure the round-trip time and reject responses that exceed a tight threshold — have been published in the academic literature for over a decade (Brands and Chaum 1993; Hancke and Kuhn 2005; numerous subsequent variants) but remain rarely deployed in production access-control systems as of 2026. The HID Seos protocol family and recent ICAO MRTD work include distance-bounding-adjacent measures; broader deployment is on a years-out timeline.

5.4 Brute force / nested attack against MIFARE Classic Crypto-1

The standard cryptanalytic attack pipeline against MIFARE Classic, implemented in the mfoc (Mifare Classic Offline Cracker by Norbert Szetei) and mfcuk (Mifare Classic Universal toolKit) tools. The pipeline:

Default-key check. MIFARE Classic ships with a small set of default keys (FFFFFFFFFFFF, A0A1A2A3A4A5, D3F7D3F7D3F7, several others) that are correct for many low-effort deployments. mfoc tries these against every sector first; in many cases it recovers all sector keys without needing the deeper attacks.
Nested attack. Once at least one sector’s key is known (from default-key check or from a previously-recovered key), the nested attack recovers all other sector keys by exploiting the structure of the Crypto-1 stream cipher in the authenticated state. Each subsequent sector key falls in seconds.
Darkside attack. When no default key works (no sector is initially known), the Darkside attack — developed in the post-Nohl/Plötz research — recovers an initial key by exploiting Crypto-1’s PRNG weaknesses during authentication failures. Slower than nested (minutes vs seconds) but still tractable on consumer hardware. The Darkside attack is what mfcuk primarily implements.

The combined mfoc + mfcuk workflow recovers all 32 keys (two per sector × 16 sectors for Classic 1k, or 80 keys for Classic 4k) from a target card in 1-15 minutes depending on default-key luck and which sectors have weak keys. After key recovery, dumping the full card contents is a few seconds; cloning to a Magic UID is another few seconds. The entire pipeline from “have a MIFARE Classic in field” to “have a working clone” is under twenty minutes for a competent operator with a Proxmark3 or a PC-attached NFC reader running libnfc.

The Proxmark3 RDV4 implements the full pipeline natively in firmware via the hf mf chk, hf mf nested, hf mf hardnested, hf mf darkside, and hf mf autopwn commands. The Flipper Zero implements default-key checks and a subset of the more sophisticated recovery work — sufficient for many practical low-effort deployments but not as complete as the Proxmark3 toolkit. The smartphone equivalent (MIFARE Classic Tool on Android) handles default-key recovery and Magic-UID cloning.

5.5 Downgrade attacks

Downgrade attacks force a reader that supports multiple card families or multiple security levels into accepting the weakest variant. The pattern appears in two main forms:

Reader-multi-format downgrade. Most enterprise access-control readers (HID multiClass SE, ASSA OPTIMA, HID Signo) support multiple card families simultaneously to ease migration — they will accept iCLASS Legacy, iCLASS SE, iCLASS Seos, MIFARE Classic, DESFire EV2 / EV3, and others, presenting the credential to the backend through a unified protocol. An attacker who has compromised an iCLASS Legacy credential for the site (via the public master keys) can present that credential to the multi-format reader even if the site has been migrating to iCLASS Seos — as long as the Legacy support hasn’t been disabled. The defense is to disable the broken card families in reader configuration at the head end; the practical reality is that many multi-format readers are deployed with all formats enabled to maximize compatibility, leaving the legacy attack surface open during the entire migration window.
MIFARE Plus security-level downgrade. MIFARE Plus negotiates a Security Level (SL0-SL3) at personalization. SL1 is backward-compatible with MIFARE Classic readers and inherits Classic’s Crypto-1 weakness; SL3 uses AES-128 and is operationally secure. A deployment that personalized cards at SL3 but configured readers to accept SL1 inherits the Classic attack surface. The defense is to enforce SL3-only at the reader.

5.6 Long-range capture

The fundamental physics of inductive coupling (§2.1) bounds standard read ranges to ~10-30 cm for both LF and HF. Long-range capture techniques extend that by building larger antennas or driving more transmit power. The notable references:

Bishop Fox “Tastic RFID Thief” (Eric Smith and Fran Brown, ~2013-2014) — long-range LF reader built around an HID MaxiProx 5375 commercial long-range reader, captured HID Prox cards at ~3 ft range; documented at DEF CON and Black Hat. Has been the reference design for long-range LF capture for over a decade.¹⁴
iCopy-XS hardware (variant of iCopy with extended antenna) — consumer-grade extended-range LF hardware. Range increase is modest (~1.5x consumer baseline).
Custom-built loop antennas for HF (13.56 MHz) — multi-turn-coil antennas tuned to 13.56 MHz can extend HF read range to ~30 cm; the trade-off is bulk and visible-equipment posture during physical operation.
HID MaxiProx 5375 and equivalent commercial long-range readers — purpose-built for long-range LF reading at vehicle gate kiosks and the like; the Bishop Fox work weaponized this commercial reader category.

Long-range capture is operationally relevant to physical-pentest engagements where an authorized red-team operator wants to capture badge credentials from foot traffic in a lobby, parking garage, or stairwell without close approach to individual targets. The defense is administrative (don’t deploy long-range readers in public-facing locations where they would be predictable capture targets) and physical (shielding wallets for high-security badges; per-card RFID-blocking sleeves). The cryptographic defense — distance-bounding protocols — would also apply but is rarely deployed (§5.3).

5.7 The attack-capability summary table

Attack	Target card population	Capture distance	Tool that implements it	Defensive countermeasure
Clone (capture and write to programmable)	EM4100 / HID Prox / Indala / AWID / Ultralight / NTAG21x / MIFARE Classic (after key recovery) / iCLASS Legacy / Hitag2 (after key recovery)	~10 cm consumer	Proxmark3 RDV4 (full); Flipper Zero (subset); ChameleonUltra (HF)	Migrate to AES-based card families (DESFire EV2/EV3, iCLASS Seos, MIFARE Plus SL3, NTAG 424 DNA)
Replay (one-shot transmission of captured signal)	Same as Clone — any static-credential card	~10 cm consumer	Proxmark3 RDV4 (`lf sim`, `hf 14a sim`); Flipper Zero (emulate from saved)	Challenge-response authentication; AES-based families
Relay (extend read range via two-device relay)	Any non-distance-bounded HF or LF system	Arbitrary (limited by relay-back-channel reliability)	NFCGate; ChameleonMini; PN532-based research platforms	Distance-bounding protocols (rare in deployment); proximity detection
Brute force / nested (Crypto-1)	MIFARE Classic 1k / 4k	~10 cm consumer	`mfoc` + `mfcuk`; Proxmark3 RDV4 (`hf mf autopwn`); MIFARE Classic Tool (Android subset)	Migrate to MIFARE Plus SL3 or DESFire EV2/EV3
Master-key extraction (iCLASS Legacy)	iCLASS Legacy	~10 cm consumer	Proxmark3 RDV4 (`hf iclass loclass`); the Garcia 2012 toolkit	Migrate to iCLASS SE / Seos
Hitag2 key recovery	Hitag2 (automotive immobilizer ~1995-2015)	~10 cm consumer	Proxmark3 RDV4 (`lf hitag`); custom hardware	Migrate to AES-based immobilizer (Hitag AES, modern Megamos AES)
Downgrade (multi-format reader)	Reader accepting both Legacy and Modern families	~10 cm consumer	Any tool that can present Legacy credential	Disable broken card families in reader configuration
Downgrade (MIFARE Plus SL1)	MIFARE Plus cards deployed at SL1	~10 cm consumer	Any MIFARE Classic tool	Enforce SL3-only at the reader
Long-range LF capture	HID Prox / EM4100 / Indala (LF)	Up to ~3 ft (Tastic RFID Thief)	Bishop Fox Tastic; HID MaxiProx 5375 + custom controller	Administrative (don’t deploy long-range readers in public-facing); RFID-blocking sleeves for high-value badges
NDEF spoofing	NFC tags consumers tap with smartphones	N/A (tag is in-place)	NFC Tools, NXP TagWriter	OS-level URL confirmation; user training; SUN-messaging tags (NTAG 424 DNA) for tap-unique URLs
Skim-via-bypass-reader	Payment cards, access-control cards in field of a malicious overlay reader	N/A (overlay reader is in-place)	Custom skimmer hardware; commercial gray-market skimmers	Tamper-evident terminals; point-to-point encryption at the terminal

Table 15.4 — The access-control attack-capability catalog. The pattern across the table: the cryptographically defeated card families (every LF family without crypto, plus the broken-crypto families: Crypto-1, iCLASS Legacy DES, Hitag2, Megamos, DST40) are vulnerable to capture-and-clone-or-replay; the modern AES-based families (DESFire EV2/EV3, iCLASS Seos, MIFARE Plus SL3, NTAG 424 DNA, Hitag AES, modern Megamos AES) are not. The dominant defensive recommendation across the entire catalog is the same: migrate the deployed card base off broken families to AES-based families, and enforce that migration at the reader configuration so multi-format readers don’t accept downgraded credentials. The complementary administrative defenses (long-range reader placement; shielding sleeves; SUN-messaging tags; user training) are layered on top of the cryptographic migration.

5.8 The attack-decision-tree for “what works against this card?”

                              "I HAVE A TARGET CARD"
                              ──────────────────────
                                         │
                                         ▼
                              ┌──────────────────────┐
                              │  Identify frequency  │
                              │  Proxmark3 → hw       │
                              │  Flipper → wand both  │
                              └──────────┬───────────┘
                                         │
                  ┌──────────────────────┼───────────────────────┐
                  │                      │                       │
                  ▼                      ▼                       ▼
        ┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐
        │    LF 125 kHz    │   │    HF 13.56 MHz  │   │    UHF 860+      │
        └────────┬─────────┘   └────────┬─────────┘   └────────┬─────────┘
                 │                      │                      │
                 ▼                      ▼                      ▼
        ┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐
        │  Identify family │   │  Identify family │   │  EPC Gen2/v2     │
        │  read ID, format │   │  read ATQA/SAK,  │   │  (out of scope)  │
        │  card_id, sigs   │   │  protocol bytes  │   │                  │
        └────────┬─────────┘   └────────┬─────────┘   └──────────────────┘
                 │                      │
       ┌─────────┴────────┐   ┌─────────┴──────────┐
       │                  │   │                    │
       ▼                  ▼   ▼                    ▼
┌────────────┐   ┌─────────────┐   ┌─────────────┐   ┌──────────────┐
│ EM4100 /   │   │ Hitag2 /    │   │ MIFARE      │   │ DESFire EV2/ │
│ HID Prox / │   │ Megamos /   │   │ Classic /   │   │ EV3 / iCLASS │
│ Indala /   │   │ DST40 /     │   │ iCLASS      │   │ Seos /       │
│ AWID       │   │ DST80       │   │ Legacy /    │   │ MIFARE Plus  │
│            │   │             │   │ Ultralight /│   │ SL3 / NTAG   │
│            │   │             │   │ NTAG 21x    │   │ 424 DNA      │
└─────┬──────┘   └──────┬──────┘   └──────┬──────┘   └──────┬───────┘
      │                 │                 │                 │
      ▼                 ▼                 ▼                 ▼
┌────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ Clone to   │  │ Key recovery │  │ For MIFARE   │  │ Cryptography │
│ T5577      │  │ via published│  │ Classic:     │  │ holds.       │
│ blank.     │  │ attack tools.│  │ mfoc + mfcuk │  │              │
│ Trivial.   │  │ Then clone.  │  │ then clone   │  │ Attack       │
│            │  │              │  │ to Magic UID.│  │ requires     │
│            │  │              │  │              │  │ side-channel │
│            │  │              │  │ For others:  │  │ DPA hardware │
│            │  │              │  │ clone as-is  │  │ + physical   │
│            │  │              │  │ where        │  │ access; not  │
│            │  │              │  │ supported.   │  │ operational. │
└────────────┘  └──────────────┘  └──────────────┘  └──────────────┘

Figure 15.6 — The attack-decision tree for “what works against this card?” The flow chart captures the working operator’s first 60 seconds with an unknown target: identify frequency, identify family, route to the corresponding attack capability. For the modern AES-based families, the answer is honest — the cryptography holds, and the practical attack target is the deployment (migration windows, multi-format reader downgrade, administrative compromise) rather than the card itself. For everything else, the catalog of §5.7 applies.

6. The gear — RFID and NFC hardware comparison

The Hack Tools lineup’s RFID and NFC coverage centers on two devices — the Proxmark3 RDV4 (the lab-grade research tool, aspirational in tjscientist’s inventory as of early 2026) and the Flipper Zero (the field-portable subset, multiple units owned). The broader practitioner-tool landscape adds the Chameleon Ultra emulator family, the HydraNFC v2 open-source platform, the ACR122U commodity USB reader, the iCopy-X consumer cloner, and the smartphone-NFC-app stack. This section is the comparison table and the decision graph for “which platform do I reach for?”

A Proxmark3 RDV4 with the Bluetooth + battery accessory module attached — the canonical field-research configuration for the Proxmark3. The RDV4's design accommodates a daughterboard expansion bus … — A Proxmark3 RDV4 with the Bluetooth + battery accessory module attached — the canonical field-research configuration for the Proxmark3. The RDV4's design accommodates a daughterboard expansion bus that the Blue Shark Bluetooth+battery accessory and the SIM-reader expansion both plug into, turning the bench-tethered USB device into a wireless handheld controlled from a phone or laptop over BLE. Visible: the dual-band LF + HF antenna geometry (the larger ferrite-cored loop on the right is the HF antenna; the smaller loop and the LF antenna leads are at the top), the Atmel SAM7S microcontroller, and the FPGA that handles the low-level RFID signal processing. The Iceman firmware fork is the working community standard, supporting both LF and HF protocols and a deep Lua scripting environment for automation.

Figure 15.7 — Proxmark3 RDV4 with the Bluetooth + battery accessory module. Photo: File:Proxmark3 RDV4 with Bluetooth and battery module.jpg by Ari T. Benchaim. License: CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0). Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3AProxmark3%20RDV4%20with%20Bluetooth%20and%20battery%20module.jpg).

6.1 The platform comparison table

Tool	Cost (early 2026)	LF (125 kHz)	HF (13.56 MHz)	NFC modes	Programmable card writing	Crypto attacks	Form factor	Cross-ref
Proxmark3 RDV4 / RDV4.01	$300-400 (kit varies; ~$700+ for full kit with all antennas + Blue Shark + SIM reader)	Yes — read / write / clone / emulate (all LF families)	Yes — read / write / clone / emulate (all HF families)	R/W + CE	Yes (T5577, Magic UID, more)	Full — Crypto-1, iCLASS Legacy, Hitag2, Megamos; Iceman firmware extensive	Bench-grade or handheld w/ Blue Shark; ABS chassis	`../../Proxmark3 RDV4/CLAUDE.md` (deep dive aspirational)
Flipper Zero (built-in)	$170 (full device)	Yes — read / write / clone / emulate (firmware on STM32; EM4100, HID Prox, Indala, AWID common formats)	Yes — read / write / clone / emulate via ST25R3916; MIFARE Classic read with default keys, NTAG / Ultralight, NFC NDEF	R/W + CE (subset of full HF families)	Yes (T5577, Magic UID; via firmware)	Subset (default-key check for MIFARE Classic; not full nested/darkside in stock firmware; community apps add more)	Pocketable handheld	`../../Flipper Zero/03-outputs/Flipper_Zero_Complete.html`
ChameleonUltra (RRG / ProxGrind)	$180-220	Yes (added in Ultra; ChameleonMini was HF-only)	Yes — read / write / clone / emulate; MIFARE Classic 1K/2K/4K, NTAG 210-218, Ultralight, DESFire EV1/EV2, MIFARE Plus	Primarily CE (emulation-focused); R/W supported	Yes (emulates as if writable)	Crypto-1 brute force; Iceman-derived	Keyring-sized; nRF52840-based; ~6 months battery	(No Hack Tools deep dive)
ChameleonTiny (ProxGrind)	$80-100	No (HF-only)	Yes — read / write / clone / emulate; MIFARE Classic family	CE-focused	Limited	Emulation only	Keyring-sized; predecessor to Ultra	(No Hack Tools deep dive)
HydraNFC v2 (Benjamin Vernoux)	$150-200	No (HF-only)	Yes — read / write / emulate / sniff; ISO 14443A/B / ISO 15693 / FeliCa	R/W + CE + sniff (the sniff mode is the distinguishing feature)	Yes	TRF7970A-based; supports most HF attacks via community firmware	Shield for HydraBus; bench tool	(No Hack Tools deep dive)
ACR122U (Advanced Card Systems)	$30-50	No (HF-only)	Yes — read / write (limited); libnfc-compatible	R/W	Yes (writing limited by libnfc)	Default-key check; basic MIFARE Classic via libnfc + mfoc/mfcuk on host	USB device, requires PC	(No Hack Tools deep dive; commodity USB reader)
PN532-based modules ($5-15 each)	~$5-15	No (HF-only; some boards add separate LF chip)	Yes — basic read / write	R/W (limited CE)	Yes for basic writes	Default keys; host-side mfoc/mfcuk	Bare board for embedded use	(No Hack Tools deep dive)
Smartphone with NFC + apps	(already owned)	No (smartphones don’t carry 125 kHz radios)	Yes — read / write NDEF; MIFARE Classic via MIFARE Classic Tool (Android); NTAG, Ultralight, DESFire (without auth keys)	R/W + CE (HCE) + (deprecated P2P)	Yes for many HF families via Android apps	MIFARE Classic Tool does default-key check + basic write; not full mfoc/mfcuk	Pocketable; everyone has one	(NFC Tools, MCT, NXP TagWriter — consumer apps)
iCopy-X / iCopy-XS	$300-500	Yes (extended range on XS variant)	Yes — MIFARE Classic, HID iCLASS Legacy, NFC	R/W; clone-focused workflow	Yes (T5577, Magic UID, others)	Built-in default-key check; clone-focused workflow more than research	Handheld; user-friendly	(No Hack Tools deep dive; consumer cloner)
Ubertooth Zero (historical)	N/A	No	No	N/A	N/A	N/A	(Ubertooth One is BT/BLE, not RFID — listed here only to clarify scope)	Vol 14 §6

Table 15.5 — RFID and NFC hardware comparison across the Hack Tools lineup plus the canonical research and consumer tools that practitioners use alongside. The platform groupings: Proxmark3 RDV4 — the lab-grade research tool with full LF + HF coverage, full attack toolkit, and the deepest scripting environment (Iceman firmware + Lua); Flipper Zero — the integrated handheld with built-in LF + HF subsystems and a polished UI, the practical pocket tool for most field RFID/NFC work; ChameleonUltra family — emulation-focused HF (and Ultra adds LF) platforms in keyring-size form factor with multi-day battery; HydraNFC v2 — open-source HF research with the rare sniff mode (passively observing a reader-card exchange without participating); ACR122U and PN532 modules — commodity USB and embedded HF readers that pair with a PC running libnfc / mfoc / mfcuk; smartphone-with-NFC — the always-on consumer-tier baseline for NFC NDEF work and basic MIFARE Classic; iCopy-X — consumer-friendly cloner with the workflow polished for non-researcher operators.

6.2 The decision graph — which platform to reach for

The working pattern for “which platform for which job”:

“I need to characterize an unknown contactless card I just acquired.” → Proxmark3 RDV4 if available (the hw status, lf search, hf search command sequence identifies frequency, family, format, and known-attack status in under a minute). Flipper Zero if no Proxmark (handles the common cases, less coverage of obscure formats).
“I need to clone my own gym membership card / hotel key / building badge for backup.” → Flipper Zero. The integrated handheld + the read-save-emulate-or-write-to-blank workflow is purpose-built for this. The Proxmark3 RDV4 also handles it; the Flipper is just less work.
“I need to recover keys from a MIFARE Classic card.” → Proxmark3 RDV4 (hf mf autopwn is the canonical full pipeline). MIFARE Classic Tool on Android handles the default-key subset. The Flipper Zero stock firmware handles default keys; community apps extend coverage.
“I need to research a novel HF card protocol — capture the reader-card exchange to understand what’s happening.” → HydraNFC v2 — the sniff mode is its distinguishing feature. The Proxmark3 RDV4 also supports HF sniffing via hf 14a snoop; HydraNFC’s sniff workflow is cleaner.
“I need to do a long-range LF capture during an authorized red-team engagement.” → Bishop Fox Tastic RFID Thief (or equivalent custom long-range LF reader). Out of the Hack Tools lineup; requires bespoke build.
“I need to emulate a card for sustained periods (days to months) in a covert deployment.” → ChameleonUltra. The ~6-month battery life and keyring form factor are purpose-built for this.
“I’m writing NDEF records to consumer NFC tags.” → NFC Tools or NXP TagWriter on a smartphone. The Proxmark3 and Flipper can do this; the smartphone-app workflow is faster.
“I want a single integrated tool that handles 80% of practical field work without being a research lab.” → Flipper Zero. The price/capability/form-factor balance is the best in the lineup for the field-portable use case.
“I want the deepest possible research platform.” → Proxmark3 RDV4 with Iceman firmware. The Lua scripting environment, the Blue Shark Bluetooth+battery, the SIM reader expansion, and the depth of the Iceman command catalog put it above every other RFID/NFC platform for serious research work.

6.3 Proxmark3 firmware — Iceman vs official

A practical note that matters operationally: the Proxmark3 has two main firmware lineages — the official Proxmark3 firmware maintained at github.com/Proxmark/proxmark3, and the Iceman fork maintained at github.com/RfidResearchGroup/proxmark3 by Iceman (a community researcher) and contributors. The two trees have diverged considerably; the Iceman fork is the de-facto community standard for serious research work. The Iceman tree carries broader LF and HF protocol support, faster and more reliable reads, an expanded command set in the Proxmark CLI (hf mf autopwn, hf iclass loclass, dozens of additional family-specific commands), regular updates and bug fixes, and support for newer accessories and hardware revisions. The official tree is more conservative and is still maintained, but most published Proxmark3 research and most tutorials assume Iceman.

The practical recommendation for a tjscientist-owned RDV4: flash Iceman from the start. The official firmware is the right pick only if a specific corporate-policy reason requires it.

6.4 The Flipper Zero RFID/NFC subsystem in context

The Flipper Zero’s RFID/NFC capabilities, covered at depth in the Flipper Zero deep dive, are a deliberately-scoped subset of what the Proxmark3 RDV4 does. The 125 kHz LF subsystem is implemented in firmware on the STM32 MCU (no dedicated LF chip is on board), reading and emulating EM4100, HID Prox, Indala, AWID, and several other LF families with the same read-save-emulate-or-write-to-T5577 workflow. The 13.56 MHz NFC subsystem uses the dedicated ST25R3916 NFC chip, reading and emulating MIFARE Classic (with default-key check), NTAG, MIFARE Ultralight, NFC NDEF data, and several other families. The dual-band antenna PCB carries two passive coil antennas — one for 13.56 MHz NFC and one for 125 kHz LF — coupled to the appropriate MCU subsystem.

The Flipper’s value proposition for RFID/NFC tradecraft is the same as for sub-GHz tradecraft (§13.4): the friction between encountering an unknown card in the wild and having a working capture-and-clone or capture-and-emulate workflow is reduced to a few taps on a handheld. The Flipper doesn’t replace the Proxmark3 for serious research; it replaces the Proxmark3 for quick field enumeration, handheld emulation of cloned credentials, and NFC NDEF authoring where the polished UI and pocket form factor matter more than the cryptanalytic depth.

6.5 Sourcing notes

A few practical sourcing notes from the early-2026 market:

Proxmark3 RDV4 is available from a handful of authorized vendors — Lab401 (EU), MTools Tec (international), Hacker Warehouse (US), KSEC Worldwide (UK/EU). The RDV4.01 (current as of late 2025) supersedes the original RDV4 with minor hardware refinements; both run the same Iceman firmware. The Blue Shark Bluetooth+battery accessory and the SIM reader expansion ship separately. Counterfeit / clone “Proxmark3 Easy” units exist on AliExpress at $30-60 — these are functional but lack the RDV4’s onboard FPGA and antenna geometry; suitable for learning but not for serious research.
Flipper Zero is sold directly by Flipper Devices (flipper.net) and a handful of authorized resellers. Lead times in 2024-2025 normalized after the 2022-2023 supply crunch. Multiple units owned in tjscientist’s MY_GEAR inventory.
ChameleonUltra is sold by Lab401, KSEC, MTools Tec, and others. The original ChameleonMini and ChameleonTiny remain in the catalog at lower price points; the Ultra is the current flagship.
HydraNFC v2 is sold by Hydrabus (the parent shield-stack project) and Lab401. Lower volume / less consumer-friendly support than the other entries.
ACR122U is widely available at $30-50; clones exist at $15-25 with variable quality. The genuine ACR122U is the working baseline.
iCopy-X / iCopy-XS are sold by RfidWorld and a handful of consumer-cloner vendors. The user-experience polish is higher than Proxmark3 / Flipper; the cryptanalytic depth is lower.

7. Legal and regulatory

The legal framing for RFID and NFC security research is similar in structure to Vol 13 §7 (sub-GHz) and Vol 14 §7 (Wi-Fi/BLE) but with two important differences: the physical-security overlap is sharper (badge cloning is the technical means; unauthorized building entry is the legal harm), and the receive-side legality is broader because the RFID/NFC bands carry less of the protected-communication content that ECPA covers (no cellular voice, no LE Audio, no broadcast traffic in the LF/HF bands). The countervailing factor is that the active-use posture is harder to defend: there is no Part 15 “I was just listening” framing for badge cloning — the operator presented a credential to a reader; that’s an act with intent.

The line — load-bearing callout. Badge cloning of physical-access systems is criminal without written authorization. Cloning your own gym card or your own building’s badge for personal backup convenience is probably fine in most US jurisdictions; cloning your neighbor’s badge, a coworker’s badge, a delivery driver’s badge, or any badge for any building you do not have authorization to enter is a CFAA “without authorization” event coupled with a state-law trespass or burglary charge. The same antenna pressed against the same card has wildly different legal consequences depending on whose card it is and whose building it opens. The technical capability does not grant the legal permission; the engagement paperwork does. See Vol 19 (when authored) for the statutory walkthrough; see Vol 11 §3.6 for the engagement-paperwork stack that an authorized red-team operator carries when their scope of work includes physical-entry badge cloning as a sanctioned engagement step. The lab-discipline baseline at ../../_shared/legal_ethics.md covers the framework that applies to every Hack Tools project including this one.

7.1 Receive — what’s generally legal

Passive observation of RFID and NFC fields in the United States is essentially unrestricted. The bands (125 kHz LF, 13.56 MHz HF, 860-960 MHz UHF) are ISM bands that carry no broadcast content, no licensed services, no protected common-carrier traffic, and no ECPA-covered communications. The receive-side legal posture is therefore much cleaner than the Wi-Fi or sub-GHz cases — there is no analog of the ECPA cellular-voice restriction in the RFID/NFC bands, and the FCC’s Part 15 rules treat the receive side as unregulated.

What this means in practice for the operator:

Owning an RFID/NFC reader (Proxmark3, Flipper, ACR122U, smartphone) is unrestricted.
Holding a reader near an unknown card and capturing the card’s response is the card’s response — the operator did emit a field, but the field is below Part 15 limits and the card chose to respond. The capture itself is not a prohibited act under federal RF law.
Capturing the identifier of a card that someone walks past with — the “skim” pattern — is at the boundary. The act of capture is physically passive; the legality turns on whether the operator subsequently uses the captured data. Capturing for research and discarding without use is a different posture from capturing and writing to a clone.

The state-law layer matters here: a few US states (notably California Penal Code § 502.5) explicitly criminalize unauthorized acquisition of RFID card data, regardless of subsequent use. The federal landscape doesn’t criminalize the capture itself; some state landscapes do. Operator awareness of the jurisdiction is part of the working posture.

7.2 The CFAA layer — access-control attacks as computer crime

The Computer Fraud and Abuse Act (18 U.S.C. § 1030) applies to access-control systems the same way it applies to network systems. An access-control reader is a “computer” within the CFAA’s broad definition (any electronic data-processing device performing computational tasks); the access-control backend it talks to is unambiguously a computer. Presenting a cloned credential to gain entry to a facility is unauthorized access to that computer system; the unauthorized physical entry that follows is a separate state-law trespass (typically burglary or criminal trespass).

The CFAA exposure for unauthorized access-control attacks is real and has produced federal prosecutions. The cases tend not to be famous because the typical defendant pleads to the state-law burglary or trespass charge (where the immediate harm — unauthorized presence in a building — is most directly framed) and the federal CFAA charge is dropped or never filed. But the CFAA framework applies; in higher-value cases (corporate espionage, attack on critical infrastructure, attack on government facilities), the federal charges are the leading edge.

A relevant Auernheimer-style note: the legal community’s framing of “what counts as authorization for accessing a card-data system” is more settled than the Wi-Fi-network analog because the access-control vendor-and-customer contract relationship is bilateral and explicit (the customer agrees to terms of use; the cards are provisioned credentials within that agreement; cloning is outside the agreement’s scope). The “could have been authorized but wasn’t” gray zones that bedevil the network-access CFAA cases largely don’t exist in the access-control space.

7.3 State-law and burglary-tools layer

Beyond the federal CFAA, state-law layers apply with substantial variation:

State computer-crime statutes. Every US state has an analog of the CFAA, often broader (Texas Penal Code §§ 33.02, California Penal Code § 502, etc.). State exposure adds to federal exposure, not in place of it.
Burglary and burglary-tools statutes. Many states criminalize the possession of tools designed for committing burglary, with the burglary-tools statutes typically requiring intent (mere possession of lockpicks or RFID cloners is not the offense; possession with intent to use them in a burglary is). The intent element is what protects locksmiths, security researchers, and authorized red-team operators from the burglary-tools sweep. The defensive posture is to carry the engagement paperwork — SOW, Rules of Engagement, get-out-of-jail letter — when the gear is being carried in a context that might attract police attention.
Trespass statutes. Unauthorized entry to a building or controlled-access area is a state-law trespass everywhere in the US, with the gradient running from simple trespass (typically a misdemeanor) to burglary (typically a felony, requiring intent to commit a further crime once inside).
California Penal Code § 502.5 — California specifically criminalizes the reading or skimming of RFID card data without authorization. A small number of other states have analogous statutes; most do not.

The international landscape parallels the federal/state US framework with jurisdiction-specific variations: the UK Computer Misuse Act 1990 covers unauthorized access; the German § 202a-c StGB covers unauthorized data acquisition; the French Article 323-1 et seq. covers unauthorized computer access. GDPR adds a data-protection layer for any captured personal data (card identifiers can be personally identifying when correlated with their bearer).

7.4 The authorized-engagement frame

For authorized engagements, the same paperwork stack covered at depth in Vol 6 §1 and Vol 11 §3.6 applies fully to physical-access work:

Statement of Work (SOW) — the contract that authorizes the engagement. The SOW must explicitly enumerate physical-access techniques: “badge cloning of in-scope credentials,” “tailgating,” “lock-picking,” “long-range RFID capture of foot traffic in lobbies,” etc. A SOW that says “test the physical security” without enumerating techniques is inadequate paperwork.
Scope document — the specific list of in-scope buildings, in-scope card families, in-scope timeframes, and (critically) the out-of-scope boundaries. The operator should not be cloning the CEO’s badge without specific authorization; the scope document is where that line is drawn.
Rules of Engagement (ROE) — what the operator does when something goes wrong, who they call, what they do if confronted by site security, what the deconfliction protocol is when local law enforcement gets involved (which they will, regularly, in physical engagements).
Get-out-of-jail letter — the signed letter on company letterhead authorizing the operator’s presence, with contact information for the engagement sponsor. Carried physically during the engagement. When the operator is detained by site security or local police, the letter is the immediate de-escalation document.

The physical-pentest community has worked out this paperwork stack over twenty years; the patterns are well-known and the templates are widely available (TrustedSec, SANS, and several other firms publish templates). The operator’s responsibility is to carry the paperwork, follow the scope, and recognize that the same gear that does authorized research does unauthorized crime — the discriminator is the paperwork.

7.5 The lab-discipline rule at RFID/NFC

The project-wide legal_ethics.md baseline — own the hardware you’re testing or have written authorization to test it; operate inside an RF environment you control or have authorization to occupy; record what you’re doing so the engagement is auditable — covers the RFID/NFC attack surface cleanly. The high-risk cases the operator should think about in advance:

“It’s just my own card.” Cloning your own card for backup is fine in most US jurisdictions. The risk emerges when the cloned card is used to access a facility — even if the original card legitimately authorized that access, the cloned-card use creates a duplicate-credential situation that some access-control systems treat as an anti-passback violation, and the facility owner’s terms of use likely prohibit it. Practical posture: clone your own card for backup; don’t use the clone unless the original is lost.
“It’s a card I found / it’s a friend’s card / it’s a card I’m testing for a client without paperwork.” Don’t. The CFAA + state-law exposure is real, the gray-zone defenses are weak, and the technical capability does not grant the legal permission.
“I’m in a state with a § 502.5-class statute.” Skimming captures (capturing cards from passersby) are categorically illegal in those jurisdictions regardless of subsequent use. Some engagements expressly carve out skimming as out-of-scope for this reason; verify the jurisdictional posture before any work that involves capturing cards the operator does not own.
“I’m carrying a Proxmark3 / Flipper / cloner in checked or carry-on luggage.” US TSA generally treats consumer electronics as unrestricted; international travel raises additional questions. Some jurisdictions (UAE notably) treat RFID research hardware as customs-controlled imports. The operator carrying gear internationally should research the destination jurisdiction in advance.

See Vol 19 (when authored) for the full statutory walkthrough; the practical baseline is to operate inside the authorization envelope at all times.

8. Cross-reference index

The Vol 15 contribution to the canonical anchor index that Vol 21 consolidates. The nine H2 headings below are frozen append-only as of this volume’s first commit — renaming any of them changes the auto-generated vol15-<slug> anchor and silently breaks inbound links.

From	Anchor target in Vol 15	Context
Vol 6 §3	`#vol15-the-gear-rfid-and-nfc-hardware-comparison`	White-hat physical-pentest toolkit — Proxmark3 and Flipper in the engagement working set.
Vol 7 §3	`#vol15-access-control-attacks-capability-level-catalog`	Criminal-economy credential-cloning operations — the capability catalog and the broken card-family landscape.
Vol 8 §3	`#vol15-the-card-families-reference-catalog`	Grey-hat disclosure work against contactless card families — Nohl/Plötz MIFARE, Garcia iCLASS, the disclosure trajectories.
Vol 9 §3	`#vol15-the-gear-rfid-and-nfc-hardware-comparison`	Green-hat RF starter kit — Flipper Zero RFID/NFC subsystem as the on-ramp; Proxmark3 as the next step.
Vol 10 §3	`#vol15-access-control-attacks-capability-level-catalog`	Defender’s view of access-control attack surface; the migration narrative away from broken card families.
Vol 11 §3.6	`#vol15-the-gear-rfid-and-nfc-hardware-comparison`	Red-hat physical-entry RF/HID staging layer — Proxmark3 and Flipper in the authorized red-team operator’s kit.
Vol 11 §3.6	`#vol15-access-control-attacks-capability-level-catalog`	The clone-and-replay attack capability used during authorized physical-pentest engagements.
Vol 13 §3	`#vol15-lf-vs-hf-rfid-the-physics-and-the-operational-differences`	Vol 13’s spectrum map hands off the 125 kHz LF and 13.56 MHz HF rows to Vol 15.
Vol 13 §7	`#vol15-legal-and-regulatory`	Vol 13’s TX-vs-RX legal frame; Vol 15 extends with the CFAA / physical-trespass overlay specific to access-control work.
Vol 14 §2	`#vol15-lf-vs-hf-rfid-the-physics-and-the-operational-differences`	Vol 14’s 2.4/5/6 GHz coverage vs Vol 15’s LF/HF coverage — the band-and-distance distinction across RF tradecraft.
Vol 14 §5	`#vol15-nfc-the-protocol-stack-and-the-attack-surface`	BLE vs NFC comparison — both are short-range, paired-device protocols on different physical layers with different security models.
Flipper Zero deep dive	`#vol15-the-card-families-reference-catalog`	The card-family context behind the Flipper’s RFID/NFC menu offerings.
Flipper Zero deep dive	`#vol15-nfc-the-protocol-stack-and-the-attack-surface`	The NFC protocol context behind the Flipper’s ST25R3916-based NFC subsystem.
Proxmark3 RDV4 deep dive (when authored)	All §3-§6 anchors	The Proxmark3 deep dive will lean heavily on Vol 15 for the card-family and attack-capability framing.
Vol 16 (Computer-hacking tradecraft)	`#vol15-nfc-the-protocol-stack-and-the-attack-surface`	NFC-tag attacks against smartphones — the BadUSB-equivalent surface in NFC.
Vol 17 (Social engineering tradecraft)	`#vol15-access-control-attacks-capability-level-catalog`	Badge-cloning during physical social-engineering engagements — the technical capability behind the operator’s badge story.
Vol 19 (Legal line & ethics)	`#vol15-legal-and-regulatory`	The CFAA / state-law / international framework that this volume’s §7 summarizes.
Vol 20 (Cheatsheet)	All §3 + §5 + §6 anchors	RFID/NFC field-card material — card-family identification, attack capability, tool-decision graph.
Vol 21 (Glossary + canonical anchor index)	Every Vol 15 H2 anchor	Vol 21 consolidates the series anchor catalog.

Table 15.6 — The Vol 15 cross-reference index. The pattern matches Vol 13 and Vol 14: hat volumes link out for technical depth (the attack-capability catalog, the card-family reference, the gear comparison); tool deep dives link in to ground their hardware in the broader tradecraft (the Flipper Zero deep dive’s RFID/NFC menus, the future Proxmark3 RDV4 deep dive); the reference cluster siblings (Vol 13, Vol 14) build on adjacent foundations (the spectrum map hand-off, the band-and-distance comparison); the synthesis volumes (Vols 16-21) consume Vol 15 anchors for their own cross-references. The append-only discipline on the H2 headings is what keeps this index stable across the deep-dive cluster.

The frozen H2 anchors as committed in this volume:

#vol15-about-this-volume
#vol15-lf-vs-hf-rfid-the-physics-and-the-operational-differences
#vol15-the-card-families-reference-catalog
#vol15-nfc-the-protocol-stack-and-the-attack-surface
#vol15-access-control-attacks-capability-level-catalog
#vol15-the-gear-rfid-and-nfc-hardware-comparison
#vol15-legal-and-regulatory
#vol15-cross-reference-index
#vol15-resources

9. Resources

Primary references for Vol 15, organized by topic, with footnoted citations to the specific papers, tools, statutes, and books.

LF and HF RFID standards and physics. ISO/IEC 14443 (parts 1-4) is the canonical reference for HF Type A/B contactless card protocols.¹⁵ ISO/IEC 15693 covers the “vicinity card” physical layer used by NFC Type 5 and iCLASS Legacy.¹⁶ The NFC Forum’s specifications portal hosts the Digital Protocol, Analog Specification, and the four NFC Tag Type specifications.¹² Klaus Finkenzeller’s RFID Handbook (Wiley, 3rd ed. 2010) is the canonical engineer reference for the physics of inductive coupling, antenna design, and the standards landscape.¹⁷

MIFARE Classic cryptanalysis. Karsten Nohl and Henryk Plötz’s 24C3 (December 2007) presentation “Mifare, little security, despite obscurity” is the original cryptanalytic disclosure.⁴ Nicolas T. Courtois, Karsten Nohl, and Sean D. O’Neil’s “Algebraic Attacks on the Crypto-1 Stream Cipher in MiFare Classic and Oyster Cards” (IACR ePrint 2008/166, April 2008) is the formal cryptanalytic paper.⁵ Flavio D. Garcia, Peter van Rossum, Roel Verdult, and Ronny Wichers Schreur’s “Wirelessly Pickpocketing a MIFARE Classic Card” (IEEE S&P 2009) demonstrated practical attacks against deployed transit systems.⁶

iCLASS Legacy cryptanalysis. Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult, and Milosch Meriac’s “Exposing iClass Key Diversification” (USENIX WOOT 2011) and the follow-on “Dismantling iClass and iClass Elite” (ESORICS 2012) are the canonical iCLASS Legacy breaks.⁷ ⁸

Hitag2 and Megamos cryptanalysis. Roel Verdult, Flavio D. Garcia, and Josep Balasch’s “Gone in 360 Seconds: Hijacking with Hitag2” (USENIX Security 2012) is the canonical Hitag2 cryptanalysis paper.¹ Roel Verdult, Flavio D. Garcia, and Barış Ege’s “Dismantling Megamos Crypto: Wirelessly Lockpicking a Vehicle Immobilizer” (USENIX Security 2013/2015, court-delayed two years) is the Megamos break.² Lennert Wouters, Eduard Marin, Tomer Ashur, Benedikt Gierlichs, and Bart Preneel’s “Fast, Furious and Insecure: Passive Keyless Entry and Start Systems in Modern Supercars” (CHES 2019) and follow-on DST80 work (USENIX Security 2020) extend the lineage.⁹ Stephen C. Bono, Matthew Green, Adam Stubblefield, Ari Juels, Aviel D. Rubin, and Michael Szydlo’s “Security Analysis of a Cryptographically-Enabled RFID Device” (USENIX Security 2005) is the original DST40 break.³

DESFire EV1 side-channel research. David Oswald and Christof Paar’s “Breaking Mifare DESFire MF3ICD40: Power Analysis and Templates in the Real World” (CHES 2011) documented the EV1 silicon DPA vulnerability that drove subsequent hardware hardening.¹⁰

LEGIC cryptanalysis. Henryk Plötz and Karsten Nohl’s partial LEGIC Prime disclosures (2009-2012) appear in various conference talks; the academic literature is thinner than for MIFARE / iCLASS.¹¹

Tools. The Proxmark3 project’s Iceman fork¹⁸ is the canonical community-standard firmware and toolkit. The official Proxmark3 fork¹⁹ is more conservative and the historical reference. libnfc²⁰ is the canonical Linux NFC library that ACR122U and PN532 modules use. mfoc (Norbert Szetei)²¹ and mfcuk (Andrei Costin)²² are the standard MIFARE Classic key-recovery tools. The HydraNFC v2 project²³ is the open-source HF research platform. The ChameleonUltra project²⁴ from RfidResearchGroup / ProxGrind is the modern emulation-focused platform.

Long-range capture research. Eric Smith and Fran Brown’s “Tastic RFID Thief” presentation at DEF CON 21 / Black Hat USA 2013 documented the long-range LF capture pattern with the HID MaxiProx 5375.¹⁴ The full schematics and bill-of-materials are available on Bishop Fox’s research GitHub.

Sibling Hack Tools deep dives — the device-level depth that this volume deliberately doesn’t duplicate:

Proxmark3 RDV4 (CLAUDE.md placeholder, deep dive aspirational): ../../Proxmark3 RDV4/CLAUDE.md
Flipper Zero deep dive: ../../Flipper Zero/03-outputs/Flipper_Zero_Complete.html

Series cross-references in this volume. Vol 6 §3, Vol 7 §3, Vol 8 §3, Vol 9 §3, Vol 10 §3 for the hat-volume tooling treatments that link in for the card-family / attack-capability framing. Vol 11 §3.6 for the red-hat physical-entry RF/HID staging context. Vol 13 for SDR fundamentals and sub-GHz; Vol 13 §3 for the spectrum-map rows that hand off to this volume; Vol 13 §7 for the TX-vs-RX legal baseline this volume extends. Vol 14 for Wi-Fi and BLE; Vol 14 §5 for the BLE-vs-NFC comparison. Vol 16, Vol 17 for the rest of the reference cluster. Vol 19 (when authored) for the full statutory walkthrough of the CFAA / state-computer-crime / international framework.

Roel Verdult, Flavio D. Garcia, and Josep Balasch, “Gone in 360 Seconds: Hijacking with Hitag2”, 21st USENIX Security Symposium, August 2012, Bellevue WA. The canonical Hitag2 cryptanalysis paper; key recovery in under six minutes with ordinary hardware against any Hitag2-based automotive immobilizer. https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/verdult. ↩ ↩² ↩³
Roel Verdult, Flavio D. Garcia, and Barış Ege, “Dismantling Megamos Crypto: Wirelessly Lockpicking a Vehicle Immobilizer”, 22nd USENIX Security Symposium, 2013 (publication delayed two years by court order at Volkswagen’s request; finally released in 2015). The Megamos Crypto break affecting many VW Group vehicles 2009-2015. https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/verdult. ↩ ↩² ↩³
Stephen C. Bono, Matthew Green, Adam Stubblefield, Ari Juels, Aviel D. Rubin, and Michael Szydlo, “Security Analysis of a Cryptographically-Enabled RFID Device”, 14th USENIX Security Symposium, August 2005. The original Texas Instruments DST40 break, including the ExxonMobil Speedpass attacks. https://www.usenix.org/legacy/event/sec05/tech/full_papers/bono/bono.pdf. ↩ ↩²
Karsten Nohl and Henryk Plötz, “Mifare, little security, despite obscurity”, 24th Chaos Communication Congress (24C3), December 2007. The original cryptanalytic disclosure of the MIFARE Classic Crypto-1 cipher, including the reverse-engineering of the chip by electron microscopy and the demonstration of a working attack. Slides and recording available via CCC archives. https://events.ccc.de/congress/2007/Fahrplan/events/2378.en.html. ↩ ↩² ↩³
Nicolas T. Courtois, Karsten Nohl, and Sean D. O’Neil, “Algebraic Attacks on the Crypto-1 Stream Cipher in MiFare Classic and Oyster Cards”, IACR Cryptology ePrint Archive, Report 2008/166, April 2008. The formal cryptanalytic paper demonstrating full 48-bit key recovery in ~200 seconds on a PC from a single known IV. https://eprint.iacr.org/2008/166. ↩ ↩² ↩³
Flavio D. Garcia, Peter van Rossum, Roel Verdult, and Ronny Wichers Schreur, “Wirelessly Pickpocketing a MIFARE Classic Card”, IEEE Symposium on Security and Privacy (S&P) 2009. Demonstrated practical attacks against deployed transit systems using the Crypto-1 weaknesses, including over-the-air key recovery and clone-card production. https://www.cs.ru.nl/~rverdult/Pickpocketing_Mifare-IEEE_SP_2009.pdf. ↩ ↩² ↩³
Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult, and Milosch Meriac, “Exposing iClass Key Diversification”, 5th USENIX Workshop on Offensive Technologies (USENIX WOOT 2011). The initial iCLASS Legacy disclosure documenting the DES-based key diversification and the chosen-plaintext attack. https://www.usenix.org/legacy/event/woot11/tech/final_files/Garcia.pdf. ↩ ↩² ↩³
Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult, and Milosch Meriac, “Dismantling iClass and iClass Elite”, ESORICS 2012. The follow-on comprehensive paper documenting the full iCLASS Legacy and iClass Elite breaks, including master-key derivation and the attack pipelines. https://flaviodgarcia.com/publications/dismantling.iClass.pdf. ↩ ↩² ↩³
Lennert Wouters, Eduard Marin, Tomer Ashur, Benedikt Gierlichs, and Bart Preneel, “Dismantling DST80-based Immobiliser Systems”, IACR Transactions on Cryptographic Hardware and Embedded Systems (TCHES) 2020, Issue 2, with companion USENIX work. The Texas Instruments DST80 break affecting Toyota, Hyundai, Kia, and other manufacturers’ immobilizer systems. https://tches.iacr.org/index.php/TCHES/article/view/8546. ↩ ↩²
David Oswald and Christof Paar, “Breaking Mifare DESFire MF3ICD40: Power Analysis and Templates in the Real World”, CHES 2011 (Cryptographic Hardware and Embedded Systems). DPA-based key extraction against specific MIFARE DESFire EV1 silicon batches; subsequent EV1 / EV2 silicon revisions hardened the implementation. https://link.springer.com/chapter/10.1007/978-3-642-23951-9_14. ↩ ↩²
Henryk Plötz and Karsten Nohl, “Peeling Away Layers of an RFID Security System”, Financial Cryptography 2011. Partial LEGIC Prime cryptanalysis covering reader/card protocol weaknesses; less complete than the MIFARE Classic or iCLASS work but documents the broad pattern. Additional LEGIC research has appeared at later CCC events. ↩ ↩²
NFC Forum, Specifications and Application Documents. https://nfc-forum.org/our-work/specification-releases/. Hosts the NFC Digital Protocol Technical Specification, NFC Analog Specification, the four NFC Tag Type specifications (Type 1, 2, 4, 5), NDEF, and the various application-layer documents (Connection Handover, Personal Health Device Communication, etc.). ↩ ↩²
Aurélien Francillon, Boris Danev, and Srdjan Capkun, “Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars”, NDSS 2011. The canonical relay-attack paper for automotive systems; demonstrated practical relay attacks against ten different vehicle models. https://eprint.iacr.org/2010/332. Subsequent work by NCC Group (Tesla, BMW relays, 2022) extended the pattern. ↩
Eric Smith and Fran Brown (Bishop Fox), “Tastic RFID Thief: Silent, But Deadly”, presentation at DEF CON 21 / Black Hat USA 2013. Documented the long-range LF capture pattern with the HID MaxiProx 5375 commercial long-range reader. Full schematics and bill-of-materials on Bishop Fox’s research repository. ↩ ↩²
ISO/IEC 14443 — Identification cards — Contactless integrated circuit cards — Proximity cards. Multi-part standard (Parts 1-4) defining the HF 13.56 MHz contactless card physical and link layers (Type A and Type B variants). The canonical reference for MIFARE, DESFire, NTAG, and the broader HF card population. https://www.iso.org/standard/70170.html. ↩
ISO/IEC 15693 — Identification cards — Contactless integrated circuit cards — Vicinity cards. Multi-part standard defining the HF 13.56 MHz “vicinity card” physical and link layers (slightly longer range than ISO 14443; lower data rate). The physical-layer basis for NFC Tag Type 5 and iCLASS Legacy. https://www.iso.org/standard/39694.html. ↩
Klaus Finkenzeller, RFID Handbook: Fundamentals and Applications in Contactless Smart Cards, Radio Frequency Identification and Near-Field Communication, Wiley, 3rd ed. 2010 (or 4th ed. when available). The canonical engineer-grade reference for the physics of inductive coupling, antenna design, modulation and coding for RFID, and the standards landscape across LF, HF, and UHF. ↩
Iceman fork of the Proxmark3 project, RfidResearchGroup. https://github.com/RfidResearchGroup/proxmark3. The de-facto community-standard Proxmark3 firmware and host-side toolkit; supports the full LF + HF protocol family, the deep Lua scripting environment, and the modern Iceman command catalog (hf mf autopwn, hf iclass loclass, etc.). ↩
Official Proxmark3 project. https://github.com/Proxmark/proxmark3. The historical reference; more conservative than the Iceman fork. Most published research and most tutorials assume the Iceman fork. ↩
libnfc — Low-level NFC SDK and programmer’s API. http://nfc-tools.org/index.php?title=Libnfc. The canonical Linux library that ACR122U, PN532, and similar HF readers use. Foundation for many higher-level NFC tools including the early mfoc and mfcuk. ↩
Norbert Szetei et al., mfoc (Mifare Classic Offline Cracker). https://github.com/nfc-tools/mfoc. The canonical MIFARE Classic key-recovery tool implementing the default-key check + nested attack pipeline; requires at least one known key (often found by default-key check) to bootstrap. Open source; GPLv2. ↩
Andrei Costin et al., mfcuk (Mifare Classic Universal toolKit). https://github.com/nfc-tools/mfcuk. Implements the Darkside attack against MIFARE Classic — recovers an initial key without any prior known key. Slower than mfoc’s nested attack but tractable when no default keys work. Open source; GPLv2. ↩
Benjamin Vernoux, HydraNFC v2 shield for HydraBus. https://hydrabus.com/hydranfc-v2-specifications. Open-source HF research platform (TRF7970A-based) with read / write / emulate / sniff capabilities across ISO 14443A/B / 15693 / FeliCa. The sniff mode (passively observing a reader-card exchange without participating) is the distinguishing feature. ↩
RfidResearchGroup / ProxGrind, ChameleonUltra. https://github.com/RfidResearchGroup/ChameleonUltra. The current-generation Chameleon (NRF52840-based) supports MIFARE Classic 1K/2K/4K, NTAG 210-218, Ultralight (Standard / C / EV1), DESFire EV1/EV2, MIFARE Plus emulation, with ~6 month battery life in keyring form factor. The Ultra adds LF support; ChameleonTiny is the HF-only predecessor. ↩

Hacker Tradecraft Volume 15 — RF Tradecraft III: RFID, NFC, and Access Control

Contents