iCopy-X / iCopy-XS — RFID / NFC Primer: LF and HF Physics, the ISO Standards, Why Some Cards Crack and Others Do Not

1. Why this volume exists

Every operating mode in the iCopy-X firmware — Auto Clone, Scan, Read LF, Read HF, Sniff, Emulate, Expert / Proxmark Mode — is a structured operation on top of one of a handful of air-interface standards and one of a handful of tag-family conventions on top of those standards. The volumes that follow this one work through specific tag families (Vol 4 for the LF families, Vol 5 for the MIFARE family, Vol 6 for iCLASS / SEOS / FeliCa / Legic) and the operating modes (Vol 7, Vol 8) that drive them. This volume is the layer underneath all of that — the engineering physics, the standards landscape, and the crypto-strength taxonomy that decides, before any button is pressed, what the iCopy-X is going to be able to do with the card on its antenna.

The reader is assumed to have a working engineer’s grasp of the basics — what a tuned circuit is, what ASK / FSK / PSK modulation look like, what a UID is, that AES-128 is strong and broken proprietary crypto is not. The job of this volume is to put those pieces into the specific shape they take in the contactless card world, and to translate the iCopy-X’s behaviour back into the underlying engineering when the device does something surprising. A surprising number of “the card won’t read” troubleshooting moments come down to coupling-factor physics or to a misidentified standard layer; the rest come down to crypto. This volume is what the operator needs to think clearly about both.

A note on standards-quoting. ISO/IEC 14443 parts 1 through 4 and ISO/IEC 15693 parts 1 through 3 are paywalled documents. The descriptions below are paraphrased from the public literature, manufacturer datasheets, the proxmark.org community knowledge base, and the open-source Proxmark3 RRG client source — none of which is the standard text itself. Where a specific numeric value matters (a subcarrier frequency, a bit-encoding timing, an anticollision parameter) and is sourced from the standard rather than from a datasheet, the convention here is to give the value with a “verify in standard” note. The intent is that an engineer reading this volume can act on the numbers, then go to the paywalled standard if and only if a courtroom-grade or specification-conformance question is on the table.

2. LF physics — 125 kHz, near-field magnetic coupling, big coils

The low-frequency band that the iCopy-X services is built around a single carrier: 125 kHz, with some tag families using a slight offset (134 kHz for HITAG2, in some configurations) but the iCopy-X’s antenna handles the practical spread of 125-134 kHz without retuning. Everything that happens at LF happens in the near-field magnetic regime — the wavelength at 125 kHz is roughly 2400 m, so the operator is working at distances of milliimetres-to-centimetres from a wavelength-scale source. The far-field radiation patterns that an antenna engineer associates with most RF work are simply not in play at LF; what matters is the inductive coupling between the iCopy-X’s LF coil and the card’s coil.

2.1 The antenna as a loop inductor

The LF coil on the iCopy-X is, electrically, a multi-turn loop inductor with a parallel-tuning capacitor that brings the LC tank to resonance at 125 kHz. The card, on the other end of the air gap, is also a multi-turn loop inductor with its own resonance capacitor — typically integrated onto the card’s silicon die, sometimes external on older designs. The two loops form a loosely-coupled transformer with a coupling coefficient k that is highly dependent on the geometry of how the card is held against the iCopy-X’s antenna. At close, coaxial alignment k might approach 0.1 to 0.2; at the edge of usable range (5-10 cm away or significantly misaligned) k can drop below 0.01.

The iCopy-X drives its LF coil with a square-wave carrier at 125 kHz from the Spartan-3 FPGA, low-pass filtered into something close to a sinusoid before reaching the coil. The card’s coil sees this carrier as an induced EMF, rectifies and regulates it, and uses the resulting DC to power its own logic. There is no battery on the card — every LF card the iCopy-X works with is a passive tag, harvesting power continuously from the reader’s field. This is why the operator needs to hold the card stably against the antenna during a read: lose coupling and the card resets.

The cross-reference for the loop-inductor analysis is Antennas Vol 14 (transmitting loops), which works through Q, bandwidth, matching networks, and radiation efficiency for transmit loops in general. The iCopy-X’s LF coil is a small-signal, low-power version of the larger transmit loops in that volume — same physics, much smaller scale.

2.2 ASK, FSK, PSK at LF — modulation schemes the iCopy-X handles

The card communicates back to the reader by modulating its load on the magnetic field. The reader sees this load modulation as a small fluctuation in the current through its own coil, which is detected by the analog front end and demodulated by the FPGA. There are three commonly-used modulation schemes at LF:

• ASK (Amplitude Shift Keying) — the card shorts its coil periodically through a load resistor, producing a measurable dip in the reader-side carrier amplitude. This is the simplest scheme and is used by EM4XX, HID Prox (Wiegand-format LF variant), Indala, and most low-end LF tags. Bit rates are typically 1-4 kbit/s.
• FSK (Frequency Shift Keying) — the card modulates its load at one of two distinct sub-carrier frequencies (commonly 8th or 10th sub-multiples of the carrier — e.g., 12.5 kHz and 15.625 kHz). The reader demodulates which of the two frequencies is currently in play to recover the bit stream. HID Prox (the de-facto standard) uses FSK at fc/8 / fc/10, where fc is the 125 kHz carrier; verify exact ratios in HID’s protocol docs.
• PSK (Phase Shift Keying) — the card modulates the phase of its sub-carrier. Less common at LF; used by some Indala and AWID variants, and by HITAG in certain modes.

All three schemes share a fundamental constraint: the reader’s field must remain continuous (or near-continuous) while the card transmits, because the card is using the field as its power source. The iCopy-X solves this by running its LF coil’s carrier continuously during a transaction and reading the load modulation as small variations on top of the carrier. The communication is therefore half-duplex in protocol terms (reader queries, card answers, never simultaneously) but full-duplex in field terms (the carrier is always on while a card-side transmission is in progress). This is in contrast to some HF protocols where the reader briefly stops modulating its own data to listen — see Section 3 below.

2.3 Bit encoding — Manchester, biphase, NRZ

Underneath the modulation scheme is the bit encoding — how a one and a zero are represented in the modulated bit stream. The common ones at LF:

• Manchester — each bit is a transition: low-to-high for a one, high-to-low for a zero (or vice versa, depending on polarity). Self-clocking. Used by EM4XX in its standard mode.
• Biphase (FM0 / FM1) — variations on Manchester with different transition timing. Used by HID Prox in its bit-stream layer.
• NRZ (Non-Return-to-Zero) — a one is a high level for the bit duration, a zero is a low level. Not self-clocking; needs a separate clock signal or a known bit-rate-locked oscillator. Used by some older tag families.

The iCopy-X auto-detects the modulation and encoding for any LF tag it knows about. In Auto Clone mode this is invisible to the operator; the device simply identifies the tag family and proceeds. In Read LF mode the device reports the detected modulation as part of the technology fingerprint. The relevance for the operator is that an unknown-modulation LF tag will fail to identify in Auto Clone; the recovery is to drop to Vol 8 (Expert / Proxmark Mode) and try a more exhaustive scan.

2.4 Range — why LF is hand-held

The 1/r³ near-field falloff that dominates magnetic coupling at LF means that read range at 125 kHz is fundamentally short: typically 1-10 cm for a hand-held device like the iCopy-X with its compact coil. Industrial LF readers built into door access panels manage 15-30 cm because they use much larger coils (often the size of a dinner plate) and much higher transmit power; the iCopy-X’s coil is the size of a credit card, and the device is battery-powered. The trade for that short range is portability — and for the iCopy-X’s intended use case, where the operator deliberately presents a card against the antenna, short range is not a liability.

The operator-side implication is straightforward: hold the card flat against the iCopy-X’s bottom face, centred on the antenna PCB, until the device beeps. If a read fails on the first try, the most common cause is misalignment (card held at an angle, off-centre, or not pressed close enough). Section 7 below covers the antenna-positioning subtleties.

2.5 Why LF tags are physically large

LF tag coils are bigger than their HF counterparts because the resonance constraint at 125 kHz requires a larger inductance for the same capacitance, and a larger inductance means more turns or a larger loop area or both. A typical LF card coil has 100-200 turns of fine wire around the perimeter of the card; a typical HF (13.56 MHz) card coil has 3-5 turns. This is why HID Prox cards and similar LF technologies have a visible spiral pattern when held up to a light, while MIFARE Classic and other HF cards look almost blank inside — the coil is smaller and packed more tightly.

The trade is that LF tags have a much larger physical antenna budget available to them, which is partly why LF tags work well in form factors that HF tags struggle with (keyfobs, wristbands, the cylindrical LF “garage door opener” form factor) — the larger coil tolerates more form-factor variation.

3. HF physics — 13.56 MHz, ISO 14443 framing, faster everything

The high-frequency band that the iCopy-X services is built around 13.56 MHz. This is still near-field magnetic coupling in practical terms — the wavelength at 13.56 MHz is roughly 22 m, and the operator is still working at distances much smaller than a wavelength — but the higher carrier frequency enables much faster modulation rates and more sophisticated protocol stacks on top.

3.1 The 13.56 MHz coupling regime

The HF coil on the iCopy-X is again a loop inductor, but with far fewer turns (3-5 typically) and a much smaller tuning capacitor to resonate at 13.56 MHz. The card-side coil is similarly small and tightly-tuned. Coupling coefficients can be higher than at LF because the smaller coils are physically closer to each other at typical card-against-reader distances, and the higher frequency makes the energy transfer more efficient per unit of coupling.

The card is still passively powered — there is no battery on a MIFARE Classic, an iCLASS card, or a contactless EMV payment card. The reader’s 13.56 MHz field powers the card’s silicon, with the same constraint as at LF: the field must remain on while the card is transmitting. In practice the HF protocols have explicit pause-and-listen sequences (the reader briefly stops modulating its own data to let the card respond), but the unmodulated carrier itself is continuous.

Range at HF for a hand-held reader like the iCopy-X is typically 1-5 cm for ISO 14443 cards and up to 10 cm for ISO 15693 vicinity cards (which use a slightly different protocol family — see Section 5 below). The 1/r³ falloff still dominates, but the higher carrier frequency means the available signal-to-noise at a given coupling factor is better than at LF, so the same coupling factor that fails to read an LF tag may successfully read an HF tag.

3.2 ISO 14443 framing — the dominant HF standard

ISO/IEC 14443 is the dominant air-interface standard for proximity contactless cards at 13.56 MHz. Published by ISO/IEC in 2001 with multiple amendments since, the standard is split into four parts:

• Part 1 (Physical Characteristics) — physical card dimensions, environment, durability.
• Part 2 (RF Power and Signal Interface) — the 13.56 MHz carrier, the modulation, the air interface itself. The split between Type A and Type B happens at this layer.
• Part 3 (Initialization and Anticollision) — how a reader discovers cards in its field, how multiple cards are arbitrated.
• Part 4 (Transmission Protocol) — the higher-level T=CL (transmission protocol contactless) framing, equivalent to ISO 7816 for contact smartcards.

The iCopy-X firmware implements all four parts; the operator does not need to think about the split. What matters at the engineering level is the Type A versus Type B distinction at Part 2, because the two types have different modulations, different anticollision algorithms, and different tag families on top.

3.3 ISO 14443 Type A — the MIFARE family lineage

Type A is the variant defined by NXP (then Philips Semiconductors) for the MIFARE family — the dominant proprietary HF tag family in the world. Type A’s reader-to-card modulation is 100% ASK with modified Miller encoding at 106 kbit/s baseline. “100% ASK” means the reader briefly turns its carrier off entirely during certain bit positions — the modulation depth is 100%. Modified Miller encoding represents bits as the timing of these pauses: a 0 is encoded as a pause early in the bit period, a 1 as a pause late in the bit period (or vice versa depending on context).

Card-to-reader modulation is load modulation with a subcarrier at fc/16 (where fc is the 13.56 MHz carrier; this gives a subcarrier at approximately 847.5 kHz). The card switches its load impedance at the subcarrier frequency, producing a sideband on the reader’s 13.56 MHz carrier that the reader can demodulate to recover the bit stream. The bit encoding on the subcarrier is Manchester at the baseline 106 kbit/s rate.

Higher rates are defined in the standard: 212 kbit/s, 424 kbit/s, and 848 kbit/s, each achieved by reducing the bit duration on top of the same physical-layer modulation. Most tag families in active deployment use the 106 kbit/s baseline; higher rates are used by some newer products and by EMV contactless payment cards. The iCopy-X handles 106 kbit/s natively for all the tag families it supports; higher rates are handled where the tag family requires them (DESFire EV2 can negotiate up to 848 kbit/s, for instance).

Anticollision on Type A is binary search tree (BSST) based: the reader broadcasts a “request” (REQA) command, all cards in the field respond, the reader narrows down the UIDs of responding cards bit by bit through a structured query-response sequence (SELECT, ANTICOLLISION) until it has identified one card and put the others into a HALT state. The detail is in the standard; the iCopy-X handles it transparently.

Tag families on top of Type A — what an iCopy-X user actually encounters in the field:

• MIFARE Classic (1K, 4K, Mini) — the dominant proprietary access-control tag worldwide, with the broken Crypto1 cipher. Vol 5 is the long-form treatment.
• MIFARE Ultralight / Ultralight C / Ultralight EV1 — the simplified, cheaper sibling. No Crypto1 on Ultralight (the C variant has 3DES; the EV1 has improved security but is still weaker than DESFire).
• MIFARE DESFire / DESFire EV1 / EV2 / EV3 — the modern, properly-secured family using AES-128 keys. Vol 5 §7 covers the DESFire-specific details.
• MIFARE Plus — the upgrade path from Classic that adds AES-grade security in its higher security levels. Vol 5 §6.
• NTAG family (NTAG203, 213, 215, 216, etc.) — NFC Forum Type 2 tags, used heavily in tap-to-link consumer applications. Simple memory layout, no crypto in most variants.
• JCOP and other Java Card-based contactless platforms — used as a substrate for custom secure-element applications, often in payment and government identity contexts.

3.4 ISO 14443 Type B — Calypso, French eID, some passports

Type B is the variant developed by other contactless-card manufacturers (Innovatron / Calypso being prominent) as an alternative to Type A. Type B’s reader-to-card modulation is 10% ASK with NRZ-L encoding at 106 kbit/s baseline — a much smaller modulation depth than Type A’s 100% ASK. The 10% modulation is chosen to keep the card powered through the modulation: the reader never fully turns its carrier off, so the card’s power supply stays stable.

Card-to-reader modulation is load modulation with a subcarrier at fc/16 (same subcarrier frequency as Type A, 847.5 kHz) but with BPSK encoding on the subcarrier rather than Manchester. The data rates and the higher-rate options match Type A.

Anticollision on Type B is slotted ALOHA based: the reader broadcasts a request that includes a slot count; cards in the field each pick a random slot and respond in that slot; collisions trigger a retransmission round with more slots. This is conceptually closer to early Ethernet’s CSMA/CD than to Type A’s structured binary search.

Tag families on top of Type B that an iCopy-X user might encounter:

• Calypso — transit cards (Paris RATP, Brussels MOBIB, Lisbon Lisboa Viva, and dozens of other metropolitan systems). The Calypso protocol on top of ISO 14443B is itself proprietary; some details are public, others under NDA. The iCopy-X can read Calypso UIDs and some metadata, but full Calypso file-level operations require the Calypso application protocol layer that the firmware does not necessarily implement.
• French eID (Carte d’identité électronique) — uses ISO 14443 Type B at the physical layer with ICAO 9303 / BAC / PACE authentication on top. Out of scope for the iCopy-X regardless of whether the physical layer works; see Vol 12 on legal posture.
• Some ICAO 9303 passports — passports were originally specified to use either Type A or Type B (each issuing country chooses); newer biometric passports are mostly Type B. Same legal posture caveats as above.

The iCopy-X firmware implements the Type B physical layer and the basic ISO 14443-3 Part 3 anticollision; what it does not implement is the higher-level application protocols (Calypso file operations, BAC / PACE authentication for passports, EMV transaction protocol for payment cards). The base UID and some metadata are readable; the rest is intentionally and structurally out of reach.

3.5 The 106 / 212 / 424 / 848 kbit/s rate negotiation

A Type A or Type B card can advertise during the initial selection sequence (the ATQA / ATQB response) what higher bit rates it supports. The reader then issues a Rate-and-Datasize change command (the RATS / PPS sequence) to move to a faster rate for the remainder of the session. For most legacy tag families (MIFARE Classic, NTAG, basic Ultralight) the negotiation is moot — they only support 106 kbit/s. For DESFire EV2 / EV3 and for modern payment cards the higher rates matter; the iCopy-X handles the negotiation automatically.

The relevance for the operator: a card that takes a noticeably longer time to read than expected is usually a card stuck at 106 kbit/s due to noisy coupling or a partially-failed negotiation, not a slow card per se. Repositioning the card against the antenna often improves the rate.

4. ISO 15693 — the vicinity card family

ISO/IEC 15693 is the air-interface standard for vicinity cards at 13.56 MHz — cards designed to read at a longer distance (up to 1 m in industrial readers, typically 5-15 cm with the iCopy-X’s smaller coil) and with simpler, slower communication than ISO 14443. The standard is split into three parts:

• Part 1 (Physical Characteristics)
• Part 2 (Air Interface and Initialization)
• Part 3 (Anticollision and Transmission Protocol)

Part 2 defines two reader-to-card data rates — 1.65 kbit/s (low) and 26.48 kbit/s (high) — and two coding schemes — “1 out of 4” and “1 out of 256”. The combinations matter mostly in the field: most actively-deployed ISO 15693 systems use the 26.48 kbit/s rate with the 1-out-of-4 coding, but legacy systems sometimes use the slower combinations. The iCopy-X handles all four combinations automatically.

Card-to-reader modulation on ISO 15693 uses load modulation with a single or dual subcarrier. Single-subcarrier mode places the subcarrier at fc/32 (approximately 423.75 kHz); dual-subcarrier mode uses fc/28 and fc/32, modulated alternately to encode bits via FSK on the load. Data rates are correspondingly 6.62 kbit/s (single subcarrier, low rate) or 26.48 kbit/s (high rate); verify exact rates in the standard.

Anticollision on ISO 15693 is slotted ALOHA with a 16-slot frame: the reader broadcasts an inventory request, each card in the field picks one of 16 slots based on its UID, the reader receives responses in slot order and re-runs the inventory with refined UID-mask filters until each card has been individually identified. The protocol can handle dozens of cards in the field simultaneously, which is part of why ISO 15693 is the preferred standard for inventory tracking applications (warehouse stock-counting, library books, asset tracking).

Tag families on top of ISO 15693 that an iCopy-X user might encounter:

• NXP iCODE SLI / SLIX / SLIX2 — the dominant ISO 15693 family for library books, retail inventory, and asset tracking. SLIX adds an optional privacy-protection feature that obscures the UID unless the reader presents a per-card password; SLIX2 extends this with additional commands and longer memory. The iCopy-X reads basic iCODE SLI / SLIX UIDs; the privacy-protected SLIX variant may require dropping to Proxmark mode (Vol 8) to handle the password sequence.
• HID iCLASS Legacy / Elite — HID’s iCLASS family, despite being marketed as a higher-security HF technology, sits on ISO 15693 for its physical layer. The proprietary iCLASS layer on top is what the iCopy-X handles in Vol 6; the underlying transport is ISO 15693.
• TI Tag-it HF-I — older Texas Instruments family, simple memory tags, still occasionally encountered in legacy access-control deployments.
• Various asset-tracking and inventory tags — generic ISO 15693 tags with no proprietary application layer on top. The iCopy-X reads UID and any unlocked memory pages.

The iCopy-X handles ISO 15693 well at the basic Inventory / Read / Write level. The proprietary iCLASS layer on top of ISO 15693 is a separate question — Vol 6 is the full treatment.

5. ISO 18000 — the wider RFID standards picture, and where iCopy-X fits

ISO/IEC 18000 is the umbrella standard for RFID air interfaces across all the major frequency bands, from 135 kHz (Part 2) up through 860-960 MHz UHF (Part 6) and 2.45 GHz microwave (Part 4). The mode that matters for the iCopy-X is 18000-3 — the 13.56 MHz mode — which has two sub-modes:

• Mode 1 is essentially identical to ISO 15693 at the physical layer. iCopy-X handles this as part of its ISO 15693 support.
• Mode 3 is a different, dedicated air interface for 13.56 MHz UHF-style RFID — used in supply-chain applications that need faster anticollision than ISO 15693 provides. iCopy-X does not handle Mode 3.

The relevance for the operator is mostly a vocabulary check: a datasheet that says “ISO 18000-3 Mode 1 compliant” is an ISO 15693 tag, and the iCopy-X will handle it. A datasheet that says “ISO 18000-3 Mode 3” is something else, and the iCopy-X will not handle it — though the operator is unlikely to encounter Mode 3 in access-control or identity-card contexts anyway, since Mode 3 is a supply-chain technology.

The UHF bands (ISO 18000-6, the EPC Gen2 family at 860-960 MHz used by retail anti-theft tags and inventory) are entirely out of scope for the iCopy-X. UHF RFID needs a completely different antenna design and a different signal-processing stack; the iCopy-X has neither. An operator who needs UHF RFID capability is looking at a different class of tool entirely (a Chameleon UHF, a Proxmark3 RDV4 with the UHF add-on, or a dedicated UHF reader/writer).

6. NFC vs RFID — terminology, the NFC Forum types, and what changes

The terminology around “NFC” versus “RFID” is more political than technical. NFC (Near Field Communication) is a marketing umbrella defined by the NFC Forum (a trade association of NXP, Sony, Nokia originally, now broader) for a subset of the existing 13.56 MHz contactless-card standards plus a peer-to-peer mode and a card-emulation mode for active devices like smartphones. RFID (Radio Frequency Identification) is the older, broader engineering term covering the entire spectrum of radio-frequency identification technologies from LF through UHF.

In practice:

• All NFC is RFID, in the sense that NFC sits on top of ISO 14443 and ISO 15693 — the same standards covered above.
• Not all RFID is NFC. LF (125 kHz) tags, UHF (860-960 MHz) tags, and 2.45 GHz tags are not NFC.
• The NFC Forum defines five NFC Forum Tag Types to standardise the cross-vendor experience for “tap your phone on a sticker” applications. The mapping to the underlying standards is:

NFC Forum Type	Underlying standard	Common tag families	Notes
Type 1 (Topaz)	ISO 14443A	Innovision Topaz (largely obsolete)	Simple, slow, mostly historical
Type 2	ISO 14443A	NXP Ultralight, NTAG203/213/215/216	The dominant “NFC sticker” type today
Type 3	JIS X 6319-4 (FeliCa)	Sony FeliCa Lite, FeliCa Standard	Used heavily in Japan (Suica, PASMO transit)
Type 4	ISO 14443A or B	MIFARE DESFire, JCOP, smartphone HCE (Host Card Emulation)	The “smart” NFC type — full file-system and application layer
Type 5	ISO 15693	NXP iCODE SLI / SLIX, TI Tag-it	Added later (2015) to bring vicinity cards into the NFC fold

The iCopy-X handles Types 1, 2, 4 (in their ISO 14443A flavour), and 5 well. Type 3 (FeliCa) is handled at the basic level — UID reads work, FeliCa-specific application commands work for the simpler variants — but the iCopy-X is not the primary tool for FeliCa work, which is a much more common use case in Japanese contexts than in Western ones. Vol 6 §6 covers the FeliCa specifics.

The Type 4 split between ISO 14443A and B matters in one specific context: smartphone Host Card Emulation (HCE). When an Android phone emulates a card (Google Pay, for instance), it presents itself as a Type 4 card on the ISO 14443A side. The iCopy-X can read the public NDEF (NFC Data Exchange Format) records that an HCE-emulated card chooses to present, but it cannot impersonate the device’s tokenized payment credentials — those are protected by hardware-backed AES-grade crypto in the phone’s secure element.

7. Antenna positioning — coupling factor, alignment, and the operator’s intuition

A surprising amount of “the card won’t read” troubleshooting comes down to coupling-factor physics rather than to a malfunction in the iCopy-X. The fundamentals:

• Coupling falls as 1/r³ in the near field, where r is the distance between the two coils. Doubling the gap quarters the coupling factor (and therefore quarters the received signal strength on either side).
• Coupling depends on coaxial alignment. Two parallel coils with their axes aligned have maximum coupling; two coils with their axes perpendicular have approximately zero coupling. A card held at a 45-degree angle to the iCopy-X’s antenna has roughly half the coupling of one held flat.
• The card’s own coil geometry matters. A standard credit-card-shaped HF card has a coil that runs around the perimeter of the card; the magnetic flux from the iCopy-X’s coil couples best when the card is held flat against the antenna with the card’s edges aligned to the antenna’s edges. A keyfob or wristband form factor has a smaller coil that’s more sensitive to alignment.

In practice, the operator-side lessons are:

• Hold the card flat against the iCopy-X’s bottom face. The antenna PCB is on the bottom; the card should be pressed against it.
• Centre the card on the antenna. The iCopy-X’s coil is roughly the size of the antenna PCB, which is roughly the area of a credit card; positioning matters more for smaller-coil tags (keyfobs, wristbands) than for credit-card-sized tags.
• The “slight angle” trick. For cards that read intermittently or fail to read at all, holding the card at a 5-15 degree angle to the iCopy-X’s antenna sometimes improves the read. The underlying physics is that some card designs have a coil that’s slightly off-axis from the card’s outer rectangle (because the silicon die is in a particular corner, and the coil is routed around it); tilting the card brings the coil into better alignment with the iCopy-X’s coil. This is an empirical trick that experienced pentest operators learn; the engineering explanation is that the card’s effective coil-axis is not always exactly perpendicular to the card’s face.
• The “lift and re-present” trick. If a card fails to read on the first attempt, lifting it away from the antenna, waiting one second, and re-presenting it often works. The underlying physics is that the card has reset and re-powered from the field; if the first attempt failed due to a partial power-up or a noisy coupling moment, the reset gives the card a clean start.
• Avoid metallic surfaces. Holding the iCopy-X against a metal desk while presenting a card to it will detune both antennas through eddy-current coupling to the metal. Working on a non-conductive surface (a clipboard, a magazine, a wooden tabletop) improves read reliability.

These are not iCopy-X-specific quirks — they apply to any near-field RFID reader. The Proxmark3 RDV4 has the same physics; the Flipper Zero, with its smaller and weaker antennas, has the same physics in a more pronounced form. The iCopy-X’s relatively large, well-tuned antenna is forgiving of moderate misalignment; the operator’s intuition for positioning develops with experience, and the only real cure for read-reliability problems is to develop that intuition through practice.

8. Crypto-strength taxonomy — why some cards crack and others do not

This is the most operationally-load-bearing section of the volume. Whether a given card can be cloned to a functional duplicate depends on the cryptographic envelope around the card’s identity data, and the cryptographic envelope falls into one of four broad categories. The category determines what the iCopy-X can do: full clone, key-recovery clone, UID-only clone, or unreadable contents.

8.1 Category 1 — no crypto, UID-only or unlocked memory

These are the cards that the iCopy-X handles trivially. The card has a unique identifier (UID), possibly some unlocked memory pages, and no cryptographic authentication is required to read any of it. The reader queries, the card answers, the iCopy-X writes the same bits to a compatible blank, and the clone is functionally identical to the original.

Cards in this category:

• EM4100 / EM4102 / EM4200 (LF) — pure UID-only tags. 64 bits or 128 bits of identifier, no crypto. The default LF tag family for low-end access control.
• HID Prox (LF, Wiegand format) — UID-only with a manufacturer-specific encoding. Some sites layer their own access-control logic on top of the UID, but the card itself is no-crypto.
• Indala, AWID, ioProx, Viking (LF) — variations on the same theme, different manufacturers, all UID-only.
• MIFARE Ultralight (HF) — UID plus 64 bytes of unprotected memory. No crypto.
• NTAG 203 / 213 / 215 / 216 (HF) — UID plus unprotected memory. NTAG can optionally lock individual pages, but the lock is a one-bit write-protect, not a crypto-authentication.
• iCODE SLI (HF, ISO 15693) — UID plus unprotected memory. SLIX adds optional privacy protection (see Category 2).
• Most generic ISO 15693 inventory tags — UID plus unprotected memory.

The iCopy-X’s Auto Clone mode handles all of these in a single button-press operation: scan the original, identify the family, present a compatible blank, write the same bits. Vol 4 (for LF) and Vol 5 §3 (for Ultralight / NTAG) cover the family-specific details.

8.2 Category 2 — proprietary broken crypto

These are the cards that have a proprietary cryptographic authentication scheme protecting some or all of their memory, but the proprietary crypto has been publicly broken — the algorithm is known, the keys can be recovered through one of a small number of well-documented attacks, and the iCopy-X (or the Proxmark3 it shares silicon with) implements those attacks. The operator runs the appropriate key-recovery mode, the iCopy-X recovers the keys, and the rest of the card becomes readable. The clone is then functionally identical to the original — including the cryptographic authentication, because the same recovered keys can be loaded onto a compatible blank.

The dominant card in this category is MIFARE Classic (1K, 4K, Mini), which uses the proprietary Crypto1 cipher. Crypto1 was reverse-engineered in 2008 by Karsten Nohl, Henryk Plötz, and the Dutch research group around Roel Verdult and Flavio Garcia (the “Dismantling MIFARE Classic” paper, ESORICS 2008). Their analysis showed that Crypto1 is a 48-bit linear-feedback-shift-register based stream cipher with significant weaknesses in its key-stream generation, and several practical attacks were developed:

• Darkside attack (Nicolas Courtois, 2009) — recovers a key by exploiting the card’s response to deliberately malformed authentication attempts. Requires only the card itself and a reader (no original key needed). Time: seconds to minutes for one sector key.
• Nested attack (Garcia / van Rossum et al., 2009) — once one sector key is known (often from a known default like FFFFFFFFFFFF), the rest of the card’s sector keys can be recovered through a “nested” authentication sequence that exploits the cipher’s state-reuse properties. Time: seconds per sector.
• Hardnested attack (improved nested, 2014-ish) — handles MIFARE Classic variants that resist the original nested attack through random nonces (the “hardened” variants). Time: minutes to tens of minutes per sector.

The iCopy-X implements all three attacks. In Sniff mode (Vol 7 §6) the device captures a legitimate reader-to-card authentication, extracts the key, and proceeds to nested-attack the rest of the card. In Auto Clone mode, the device attempts the attacks in order of speed: try known default keys first, then darkside, then nested if any key is recovered, then hardnested if nested fails. Most field-encountered MIFARE Classic cards yield to this sequence in under a minute.

Other cards in this category:

• HID iCLASS Legacy (HF, ISO 15693 substrate) — uses a proprietary key derivation scheme that was publicly broken in 2010-2013 through a sequence of research papers culminating in Garcia et al.’s “Exposing iClass Key Diversification” (USENIX WOOT 2012). The iCLASS “HID Master Key” (the global key that derives per-card keys) leaked publicly in 2014; once the master is known, the per-card key is computed from the UID via the disclosed algorithm. The iCopy-X has the master key built into its firmware and handles iCLASS Legacy as a Category 1-equivalent operation in practice. Vol 6 §2 is the long-form treatment.
• HID iCLASS Elite — the same iCLASS family with an additional layer of site-specific keys on top. The site-specific key sometimes leaks (insider, dumped reader firmware, configuration card recovery); when it does, the iCLASS Elite card becomes Category 1-equivalent. When it doesn’t, the iCLASS Elite card is Category 3 — see below.
• MIFARE Plus in SL1 (Security Level 1) mode — the backward-compatibility mode where MIFARE Plus emulates MIFARE Classic with Crypto1, for sites that haven’t yet upgraded their readers. Same attacks apply.
• MIFARE Classic EV1 — NXP’s “hardened” successor to the original MIFARE Classic. Resists the original nested attack but is vulnerable to hardnested. iCopy-X handles it.
• HITAG2 / HITAG2-S (LF, 134 kHz) — proprietary stream cipher, broken in 2012. The iCopy-X implements the attack.
• MIFARE Ultralight C — uses 3DES authentication for write protection (read is still free). The 3DES is not broken per se, but it’s commonly deployed with weak (default or short) keys; iCopy-X attempts dictionary attacks for the common cases.
• SLIX (privacy-protected iCODE) — uses a 32-bit password to unprotect the privacy mode. The password is brute-forceable in tens of minutes on modern compute; the iCopy-X may need to drop to Proxmark mode for full SLIX privacy work.

The defining feature of Category 2 is that the attacks are off-device, scriptable, and well-documented. The iCopy-X’s value here is operational — having the attacks pre-implemented and on-button in a portable device — not cryptographic. Anyone with a Proxmark3 RDV4 and the patience can do the same work; the iCopy-X just makes it field-ready.

8.3 Category 3 — AES-grade modern crypto, no public attack

These are the cards whose cryptographic protection has been designed with modern primitives (AES-128 typically, sometimes elliptic-curve key exchange) and whose implementations have not been publicly broken. The iCopy-X can read the UID and any unauthenticated metadata; the protected memory is unreadable without the correct key, and the key is not recoverable through any attack the iCopy-X can run.

Cards in this category:

• MIFARE DESFire EV1 / EV2 / EV3 — AES-128 (and 3DES on EV1 if configured that way) for both authentication and encrypted communication. The full DESFire protocol uses mutual authentication, per-session keys, and encrypted file operations. No public attack on properly-configured DESFire EV2 / EV3 as of mid-2026. The iCopy-X reads the UID and any cardholder-visible application metadata; the encrypted file contents are intentionally unreadable.
• MIFARE Plus in SL3 (Security Level 3) mode — AES-128 throughout, no Crypto1 emulation. Same situation as DESFire EV2 / EV3.
• HID iCLASS SE (Secure Element) — uses AES-128 with proper key management, structured on top of a JavaCard secure element. As of mid-2026 there is no public attack on iCLASS SE that the iCopy-X can leverage. Vol 6 §4 covers iCLASS SE in detail.
• HID iCLASS SEOS — HID’s flagship product with full ISO 7816 / SCP02 / SCP03 channel security on top of iCLASS SE’s substrate. AES-128 plus authenticated session encryption. Reading SEOS contents requires the iCS Decoder Tool (Vol 6 §5) — a separate Lab401 product that handles the SEOS protocol layer. Even with the iCS Decoder, what you get is the credential-bearing data the operator’s authorized to extract; the cryptographic envelope is intact.
• EMV contactless payment cards (Visa payWave, Mastercard PayPass, Amex ExpressPay, etc.) — AES and 3DES throughout, with full EMV transaction protocol on top. The iCopy-X reads the UID and the publicly-readable PAN (Primary Account Number, sometimes — depends on the issuer’s tokenization), but the actual transaction-completing cryptography is in the card’s secure element and is not exposed to the air interface. Cloning is structurally impossible. Vol 12 is also categorical that payment cards are out of scope as a posture matter regardless.
• ICAO 9303 passports (modern) — BAC / PACE for the basic channel, then EAC (Extended Access Control) for sensitive biometrics, all on AES-grade primitives. The UID is readable; the rest requires the issuing authority’s cryptographic credentials. Vol 12 treats passports as out of scope regardless.
• JCOP-based corporate ID cards (when properly configured) — Java Card secure elements running custom applets with AES-grade authentication. The iCopy-X reads the UID; the applet contents are protected.
• Apple Pay / Google Pay tokens in their HCE (Host Card Emulation) presentation — same situation as EMV contactless. Tokenized, hardware-backed, not cloneable.
• DESFire-emulating smartphones in HCE mode — when an Android phone is emulating a DESFire card via HCE, the application keys live in the phone’s secure element. iCopy-X reads the UID and any chosen-public metadata; the encrypted application contents are protected.

The defining feature of Category 3 is that the cryptographic design is sound and the implementation is known not to have a public bypass. The iCopy-X’s behaviour is consistent and predictable: UID is read, encrypted contents are not. The clone that emerges is therefore a UID-only clone, which is functional only against systems that don’t check the encrypted contents — and most modern systems that deploy Category 3 cards do check the encrypted contents, by design.

8.4 Category 4 — the asymmetric crypto and OS-secure layer

A small but growing fraction of corporate and government identity cards use asymmetric cryptography — the card holds a private key that never leaves the secure element, and the reader holds the corresponding public key (or a CA-signed certificate). Authentication is by digital signature: the reader sends a challenge, the card signs it with its private key, the reader verifies the signature. The card’s private key is structurally unrecoverable through any air-interface attack.

Cards in this category overlap with Category 3 in many cases — modern EMV cards, iCLASS SEOS in some deployments, government identity cards, PIV / CAC cards (US federal personal identity verification cards) — but the asymmetric layer is what makes Category 4 cryptographically distinct. Even if the card’s symmetric session keys could somehow be extracted (they cannot, in current designs), the private key for asymmetric authentication is in a hardware-backed enclave that the air interface cannot reach.

The iCopy-X’s behaviour against Category 4 cards is identical to Category 3: UID readable, everything else not. The reason to call this category out separately is that some asymmetric-keyed cards are starting to remove the UID as well (or to randomise it per session), which makes even the UID-clone strategy useless. MIFARE DESFire EV2 / EV3 with random ID enabled is the most common example — the card presents a different “UID” to every reader interaction, derived cryptographically from the actual card identity plus a session nonce. The iCopy-X reads a UID, but it’s not the same UID twice in a row, and writing it to a blank produces a clone that won’t authenticate.

8.5 The operational takeaway

The iCopy-X’s productive workflow runs across Categories 1 and 2. Category 3 cards yield UIDs and metadata, which is sometimes enough for an authorized engagement (a system that only checks UID), but is increasingly not enough as modern systems require full content cryptographic authentication. Category 4 cards are unreachable beyond UID, and even the UID may be randomized.

The strategic implication for a physical-pentest engagement is to know in advance which category the target cards belong to. A site running HID Prox LF on its main doors and MIFARE Classic on its elevator access is a Category 1 / Category 2 target — the iCopy-X clones will work. A site running iCLASS SEOS on every door is a Category 3 target — the iCopy-X with the iCS Decoder can read what it’s authorized to read, but cloning to a different blank is much harder. A site running DESFire EV3 with random IDs and AES-128 keys distributed through a key-management server is a Category 3 / Category 4 target — the iCopy-X gets a UID that changes every read, and the cryptographic contents are intact. The engagement scope and the expected deliverables need to be set accordingly; the operator should not promise a client that any card can be cloned, because the modern cards explicitly cannot be.

9. UID-only cloning vs full-content cloning — what each gets you

The distinction between cloning the UID and cloning the full content is operationally critical. The iCopy-X can do either, depending on the card and the operator’s intent; the implications differ.

UID-only cloning copies the card’s unique identifier (UID, also called PUPI on Type B cards, also called CSN on iCLASS) to a compatible blank. The blank then presents the same UID to a reader as the original would. This is sufficient when:

• The target access-control system checks only the UID, not any encrypted contents. Surprisingly many legacy installations work this way, especially older HID Prox readers that were originally designed before MIFARE Classic existed and were retrofitted into systems running MIFARE Classic cards.
• The target reader cannot perform full cryptographic authentication — e.g., a cheap reader that just hashes the UID into an access decision.
• The cardholder data layer (e.g., a hotel reservation system, a meal-card system) keys off the UID and the card’s encrypted contents are decorative.

Full-content cloning copies the entire memory of the card — including the cryptographic authentication keys, where those have been recovered — to a compatible blank. This requires:

• A blank card with magic write capabilities (the ability to write to “factory” blocks that on a normal card are read-only after manufacture). Vol 9 covers the magic-card families (Gen1a, Gen2, Gen3 for MIFARE Classic; T5577 universal blanks for LF; iCLASS-specific blanks).
• The recovered keys for the source card (from a Category 2 attack, or known defaults for a Category 1 card).
• The matching tag family for the blank (MIFARE Classic 1K source needs a 1K blank, not a 4K; iCLASS Legacy needs an iCLASS-compatible blank, not a generic ISO 15693 tag).

The functional difference is that a full-content clone passes every authentication check the original passes, including cryptographic ones. A UID-only clone passes only the UID-based checks. The legal-posture difference is significant in practice — a full-content clone is structurally identical to the original card, which can be a more concerning artifact in a corporate-security context than a UID-only clone that only works on legacy readers.

The iCopy-X’s Auto Clone mode attempts full-content cloning by default for Category 1 and 2 cards, falling back to UID-only when the keys cannot be recovered or when a magic blank of the right family is not presented to the antenna. The operator can force UID-only by presenting a non-magic blank (which will accept the UID write where the blank’s family permits it but cannot accept the protected-block writes). Vol 7 §3 covers the Auto Clone decision tree in operational detail.

10. What the iCopy-X cannot crack — and why

A working list of cards that the iCopy-X will not successfully clone to a functional duplicate, even with the best blanks and the most patient operator:

• MIFARE DESFire EV2 / EV3 with AES-128 application keys, where the keys are not known to the operator and are not recoverable from the air interface. The iCopy-X reads the UID; the application data is encrypted with a key that’s in the card’s secure element and the corresponding key on the reader / backend. No air-interface attack on AES-128 exists, and the implementation does not leak.
• MIFARE Plus in SL3 mode for the same reason — AES-128 throughout, no Crypto1 emulation.
• iCLASS SE / SEOS with properly-managed keys, where the site has not had a key compromise and the cards’ AES keys are not in the iCopy-X’s known-key store. The iCS Decoder Tool helps with the protocol layer but does not magic the keys into existence.
• Modern EMV contactless payment cards (post-2015 issuers in most markets). The PAN may or may not be readable in clear; the transaction cryptography is sealed in the secure element. Cloning is structurally impossible.
• Modern ICAO 9303 e-passports with BAC / PACE / EAC. The MRZ-derived key is needed to even read the basic data group; biometric data requires CSCA-derived authentication. iCopy-X is not the right tool, and the legal exposure is severe (Vol 12).
• DESFire EV2 / EV3 with random ID enabled — the “UID” the reader sees is a session-specific value, not the card’s actual UID, and changes every interaction. A clone with the captured session-UID will not authenticate on the next interaction because that session-UID is no longer valid.
• JCOP-based corporate identity cards with secure-channel ISD-keys, where the issuer has done their job — the iCopy-X reads the UID and ATR; the applet contents require GlobalPlatform secure-channel keys that are not known to the operator.
• Apple Pay / Google Pay / Samsung Pay tokens in HCE, where the device’s secure element is doing the crypto. iCopy-X sees a NDEF record or a Type 4 application response; the underlying tokenized credential is hardware-backed.
• Modern transit cards with full Calypso application protocol, in cities where the iCopy-X’s basic Calypso support does not extend to the file-level operations. UID may be readable; full file operations are not.

The operational consequence is straightforward: when scoping an engagement, the iCopy-X covers the legacy and mid-range access-control card population well. It does not cover the modern high-security card population, and pretending otherwise — to a client, to oneself — is a recipe for missing deadlines and overcommitting deliverables.

11. Cross-references and what to read next

This volume sets up the technology layer underneath the rest of the series:

• Vol 4 (LF tag families in scope) — the family-specific treatment of EM4XX, T5577, HID Prox, Indala, AWID, ioProx, Viking, HITAG, and the rest of the LF landscape. The Section 2 physics here is the engineering background; Vol 4 is the per-family detail.
• Vol 5 (HF tag families in scope, Part 1 — MIFARE) — the full treatment of the MIFARE family from Ultralight through Classic, Plus, DESFire EV1/2/3, and NTAG. The Crypto1 attacks (darkside, nested, hardnested) are covered in operational detail here.
• Vol 6 (HF tag families in scope, Part 2 — iCLASS / SEOS / FeliCa / Legic) — iCLASS Legacy, Elite, SE, SEOS, with the iCS Decoder Tool integration. FeliCa for completeness. Legic for European-deployment coverage.
• Vol 7 (Operating modes Part 1 — Auto Clone, Scan, Read LF, Read HF, Sniff) — the operating modes that use the standards from this volume.
• Vol 8 (Operating modes Part 2 — Emulation, Expert / Proxmark Mode) — the emulation modes and the escape hatch to the underlying Proxmark3 capabilities.

Cross-links into the wider Hack Tools hub:

• Antennas Vol 14 (transmitting loops) — the larger-scale antenna engineering background for the loop-inductor physics covered in Section 2.1. The iCopy-X’s coils are small-signal, low-power versions of the transmit loops in that volume.
• Antennas Vol 4 (antenna theory) and Vol 16 (BALUNs and matching) — the resonance-and-matching background for understanding why the iCopy-X has separate LF and HF coils with separate tuning networks rather than a single broadband antenna.
• Proxmark3 RDV4 — the lab sibling. Same FPGA bitstream lineage and same STM32 protocol layer; everything in this volume applies to the Proxmark3 as well as to the iCopy-X. The difference is operational (laptop-tethered research-grade workflow versus portable appliance), not technological.
• Hacker Tradecraft Vol 15 (RFID / NFC / Access Control) — the tradecraft-layer treatment of how RFID work fits into a broader engagement, including the legal envelope and the operational posture.
• ../_shared/legal_ethics.md — the baseline lab-discipline rules.

12. Resources and further reading

Public-domain references that are good for deepening any specific section:

• NXP MIFARE family datasheets — public on nxp.com. The MF1S50YYX and MF1S70YYX (Classic 1K, 4K) datasheets are the canonical reference for the Classic family; the MF3D81/82HX (DESFire EV3) datasheet for the modern family.
• ISO/IEC 14443 parts 1-4 and ISO/IEC 15693 parts 1-3 — paywalled at iso.org. Worth the cost for a serious practitioner; the public literature is largely accurate but does not have the authoritative bit-level detail.
• “Dismantling MIFARE Classic” — Garcia, de Koning Gans, Muijrers, van Rossum, Verdult, Schreur, Jacobs. ESORICS 2008. The paper that broke Crypto1. Available on the Radboud University website and via various academic archives.
• “Exposing iClass Key Diversification” — Garcia, de Koning Gans, Verdult. USENIX WOOT 2012. The paper that broke iCLASS Legacy. Also on the Radboud University website.
• “The Darkside of MIFARE” — Courtois, 2009. The original darkside attack paper. Available via Nicolas Courtois’s academic page at UCL.
• Proxmark3 RRG community knowledge base — proxmark.org and the proxmark3 wiki. The community-built reference for the FPGA bitstream behaviour and the STM32 protocol implementations; almost everything in Sections 2-5 of this volume can be cross-checked against the Proxmark3 source.
• The NFC Forum specifications — nfc-forum.org. The Tag Type 1-5 specifications, the NDEF specification, the Connection Handover specification. Most are free to download.
• HID’s iCLASS technical white papers — historical, somewhat sparse, mostly written for system integrators rather than reverse engineers. Useful for the official framing of iCLASS Legacy / Elite / SE / SEOS; cross-check against the academic literature for the technical truth.

For the iCopy-X-specific operational use of these standards, the local resources in ../05-resources/ — the Lab401 user manual, the iCS Decoder PDF, the firmware update guide — are the canonical references. The community repositories at iCopy-X-Community/icopyx-teardown and Nikola-Lab provide the silicon-layer cross-check that this volume’s physics descriptions are consistent with what the device actually does.