iCopy-X Vol 6 — HF tag families, Part 2: iCLASS Legacy / Elite / SE / SEOS, ISO 15693, FeliCa, Legic, and the iCS Decoder

1. What this volume is

Vol 5 covered the MIFARE family — Classic, Plus, Ultralight, DESFire, NTAG — and the key-recovery attacks (darkside, nested, hardnested) that made the Classic 1K the canonical worked example of a broken commercial RFID crypto system. This volume covers the rest of the high-frequency landscape: the HID iCLASS family (Legacy, Elite, SE, SEOS) that has become the load-bearing technology in modern US and Western European enterprise access control, the ISO 15693 inventory-tag ecosystem (iCODE SLI / SLIX, Tag-it, library and supply-chain tags), Sony’s FeliCa (the technology that runs Japanese transit and large parts of SE Asian micropayment), Broadcom’s Topaz (the simplest NFC Forum Type 1 stock), and Legic (the European proprietary HF protocol that has a major share of Swiss / German / Austrian access control). It also covers the headline iCopy-X-specific accessory — the iCS Decoder — which is the only field-portable tool that can clone iCLASS SE and SEOS cards as of mid-2026.

The mental model the reader should hold while working through this volume is that HF on the iCopy-X splits into two halves. MIFARE (the subject of Vol 5) is one half — the NXP-driven, ISO 14443A-derived, smartcard-style world. iCLASS plus the 15693 long-tail (the subject of this volume) is the other half — the HID-driven, ISO 15693-derived, access-control-style world. The two halves use the same 13.56 MHz carrier and many of the same physical-layer modulation patterns (Vol 3 §4 covers the physical layer in detail), but they diverge sharply at the protocol layer above the carrier, and they have different reasons for being hard or easy to clone. The iCopy-X handles both halves because the Proxmark3 silicon (Vol 2 §3) — the AT91SAM7S512 RFID MCU plus the Xilinx Spartan-3 XC3S100E FPGA — implements both ISO 14443 and ISO 15693 air-interface state machines. The iCS Decoder closes the SE / SEOS gap at the top of the iCLASS stack.

The HF Part 2 master matrix at a glance:

Family	Standard layer	iCopy-X support	Why it matters
iCLASS Legacy	ISO 15693-derived, HID-proprietary protocol on top, 64-bit key (HID K0)	Native; cloning is a 30-second workflow with the standard iCLASS-compatible blank	Still in service across many older US enterprise installations; the K0 key has been public since 2010
iCLASS Elite (HID Elite)	Same hardware as Legacy; customer-specific 64-bit master key derived through HID’s Elite KDF	Native when the key is known; partial recoverability through known KDF weaknesses	High-value enterprise deployments use Elite — when an engagement target is using HID, Elite is a coin-flip likelihood
iCLASS SE	HID’s modern card platform; AES-128-based crypto regime, completely different from Legacy / Elite	Requires iCS Decoder accessory (€200 / $488 add-on); UID-only without it	The dominant HID enterprise card platform for new installations since ~2014
iCLASS SEOS	HID’s flagship secure platform; application-based (DESFire-like), end-to-end encryption, HID-managed key delivery	Requires iCS Decoder accessory plus reader-side configuration that accepts legacy SIO encoding — ~85% coverage in the field	The most secure mainstream HF access card; cloning depends on operator-side knowledge and reader-side acceptance of fallback encoding
iCODE SLI (NXP)	ISO 15693 standard inventory tag, no security	Native read/write of full memory	Library books, supply-chain tracking, generic inventory; trivial workload
iCODE SLIX	ISO 15693 with NXP “privacy mode” — UID readable only after PIN authentication	Partial native (when privacy disabled or known PIN); Proxmark mode escape for PIN-recovery work	The privacy-enabled variant occasionally turns up in modern library systems
iCODE SLI-S / SLI-L	NXP 15693 variants with extended memory / longer UIDs	Native	Larger memory variants, used in some healthcare / industrial deployments
Tag-it (TI)	ISO 15693 implementation from Texas Instruments	Native	Decreasing market share but still in legacy supply-chain systems
FeliCa	Sony / JIS X 6319-4 / ISO 18092, Manchester-encoded, 212 or 424 kbit/s	Native UID read; full content depends on deployment	Japanese transit (Suica, Pasmo), large parts of SE Asian micropayment; rarely the right tool here
Topaz	NFC Forum Type 1; Innovision / Broadcom; 96 bytes	Native	Trivially clonable; early-generation NDEF and some smart-poster deployments
Legic Prime	Legic Identsystems proprietary, broken cipher	Native for older deployments with default keys	European (DE/CH/AT) access control; many sites still on Prime
Legic Advant	Legic 3DES-based, much stronger	UID only at the air interface; full cloning requires operator-side key	The modern Legic platform; treat similarly to iCLASS SE in posture

The detailed treatment that follows takes the families in the order of practical importance to a North American physical-pentester working in 2026: iCLASS is first because it is the load-bearing modern enterprise technology, the iCS Decoder section is where the operational depth lives, and the 15693 / FeliCa / Topaz / Legic sections follow as the encyclopedia coverage that the operator needs once and refers back to as new technologies appear in the field.

2. The HID iCLASS family — the load-bearing modern enterprise technology

HID Global is the dominant vendor of enterprise access-control credentials in North America, with substantial market share across Western Europe and growing presence in APAC. HID’s flagship HF card platform is the iCLASS family, which has been in production since 2002 and has gone through four major generations: iCLASS Legacy (2002–present), iCLASS Elite (2002–present, deployed in parallel with Legacy as a higher-security tier), iCLASS SE (introduced 2014), and iCLASS SEOS (introduced 2014 alongside SE, positioned as the secure-element tier). All four generations coexist in the installed base as of 2026 — Legacy and Elite continue in older deployments and new low-cost installations, SE is the volume modern enterprise card, and SEOS is the high-security tier used by government, banking, and other regulated environments.

The four generations share a physical-layer foundation — they are all 13.56 MHz HF cards, all coupled inductively, all using ISO 15693-derived modulation at the bit level — but they diverge sharply at the protocol layer above the carrier, and at the cryptographic layer above the protocol. Understanding which layer each generation lives at is the key to understanding why some are clonable with the bare iCopy-X and some require the iCS Decoder accessory.

2.1 iCLASS Legacy — the published-key generation

iCLASS Legacy was HID’s first HF card platform, introduced in 2002 as the upgrade path from the older 125 kHz HID Prox (Vol 4 §3). At the physical layer, iCLASS Legacy uses ISO 15693-derived inductive coupling at 13.56 MHz, with the standard 26.48 kbit/s 1-of-256 modulation downlink and 26.48 kbit/s ASK / 53 kbit/s SubCarrier uplink that ISO 15693 specifies. The card’s anti-collision and addressing also follow ISO 15693 in form. Above the air interface, however, iCLASS Legacy replaces the standard ISO 15693 application-layer commands with HID-proprietary commands that the standard 15693 reader does not understand, and adds a 64-bit DES-based encryption layer to authenticate the reader-card exchange.

The 64-bit key in iCLASS Legacy is what is commonly called the HID K0 key — the “standard key” — and it is the same key on every Legacy card HID ever shipped. This is the structural weakness that makes Legacy effectively trivial to clone: every Legacy card uses the same key, the key has been public since 2010, and a reader that knows K0 can read every Legacy card it encounters.

The public disclosure of K0 happened in two stages. In 2010, the team of Flavio D. Garcia, Gerhard de Koning Gans, Ruben Muijrers, Peter van Rossum, Roel Verdult, Ronny Wichers Schreur, and Bart Jacobs at Radboud University Nijmegen published “Dismantling iCLASS and iCLASS Elite” at ESORICS 2010. The paper reverse-engineered the iCLASS authentication protocol from a captured reader-card exchange, identified the key (which HID had previously treated as a trade secret), and published it as part of the cryptographic analysis. HID issued a vigorous legal pushback at the time, but the paper had been distributed and the cryptographic community had verified the result independently. By the time HID’s threats were resolved, the K0 key was permanently public, and the secondary effect of HID’s legal response was to draw additional academic and security-research attention to the Legacy platform.

The iCopy-X handles iCLASS Legacy natively. The base firmware includes the published K0 key, the HID-proprietary protocol commands above the 15693 air interface, and the application-layer card-format decoder that extracts the Card Serial Number (the unique-per-card identifier), the Facility Code (the customer-deployment-specific identifier shared by all cards in one installation), and the Card Number (the per-employee identifier within the facility). The Auto Clone workflow (Vol 7 §3) detects a Legacy card, reads CSN + FC + CN, and writes the full card image to an iCLASS-compatible blank (the “iCLASS Legacy compatible tag” stock sold by Lab401 at ~$28 a pack — see Vol 9 §4). The workflow is approximately thirty seconds end-to-end, including the time for the operator to swap the source card for the blank on the antenna. There is no key recovery step — K0 is built into the firmware.

The remaining installed base of iCLASS Legacy is substantial but shrinking. As of mid-2026, Legacy is most commonly encountered in:

• Older US corporate installations that haven’t refreshed their card stock since ~2010.
• Lower-budget deployments where the SE / SEOS premium isn’t justified.
• Some government-contractor sites that retained Legacy for compatibility with legacy door controllers.
• The HID Identity Suite’s lower tier, which still ships Legacy cards for customers who explicitly request the older stock.

A pentester encountering Legacy in 2026 is encountering a deployment that hasn’t refreshed since well before HID’s own marketing posture shifted toward SEOS. Such deployments are increasingly rare in fresh enterprise builds but remain common in long-tail facility maintenance.

2.2 iCLASS Elite — the per-customer-key generation

iCLASS Elite uses the same physical hardware, the same air-interface protocol, and the same authentication-frame structure as iCLASS Legacy. The single thing that differs is the key. Instead of using the universal HID K0 key, each Elite customer deployment uses a unique 64-bit key, derived from a customer-specific master through what HID called the “Elite KDF” — the Elite Key Derivation Function.

The intent was straightforward: if HID could give each enterprise customer its own key, a compromise of one customer would not compromise all of HID’s installed base. A pentester at one corporate site could not use what they learned to clone cards at the site across the street. The plan was a sensible step up from Legacy’s single-key approach.

The execution was less clean. The 2010 Garcia / Verdult paper that dismantled Legacy also analyzed the Elite KDF and showed that it had several cryptographic weaknesses — most importantly, that the customer-specific key was derivable from a small number of recovered card-reader authentication exchanges. The follow-up work by Carlo Meijer and Roel Verdult in 2015 (“Ciphertext-Only Cryptanalysis on Hardened MIFARE Classic Cards” and related companion work on Elite) sharpened the Elite key-recovery techniques further, reducing the number of card-reader exchanges needed to recover the customer key to a practical field-feasible count.

The state of play in 2026 is that iCLASS Elite is not effectively broken in the way Legacy is, but it is substantially weakened. A pentester encountering an Elite deployment has three reasonable paths:

1. The key is already known to the operator. This happens when the pentester has worked with the client before, when the client has provided the key as part of the engagement scope, or when the key was recovered during an earlier phase of the same engagement. The iCopy-X accepts the Elite key as configuration and then handles the card identically to Legacy. Auto Clone works in this case.

2. The key is recoverable through air-interface attack. This requires sniffing legitimate card-reader exchanges at a live reader on the target site, then performing offline cryptanalysis against the captured exchanges. The iCopy-X has a Sniff mode (Vol 7 §6) that captures the necessary frames; the key-recovery cryptanalysis is typically done on a host computer with more compute than the iCopy-X’s onboard NanoPi NEO H3, though the iCopy-X can perform some recovery on-device for smaller capture sets. The full recovery workflow can take from a few minutes (against deployments with weak key entropy) to hours (against carefully-configured deployments). The Proxmark3 RDV4 (Vol 11 §4) is the better tool for the offline cryptanalysis phase if the operator has the option; the iCopy-X is sufficient for field work but slower.

3. The key is not recoverable in the available time. Some Elite deployments have keys that resist the published attacks within the engagement window. In this case, the pentester reports the failure-mode finding (the deployment used Elite, recovery was attempted, the attack did not succeed within X hours of sniffing) and the engagement scope reflects what was actually possible.

The iCopy-X’s handling of Elite is the same as Legacy once the key is in hand. The 30-second clone workflow applies. The difference is entirely in the front-end: getting the key.

2.3 iCLASS SE — the modern AES-based platform

iCLASS SE (“Standard Encrypted”) is HID’s response to the academic dismantling of Legacy and Elite. SE was introduced in 2014, alongside SEOS, as HID’s transition to modern cryptography. At the physical layer, SE is still 13.56 MHz, still ISO 15693-derived, still uses HID-proprietary commands above the air interface. At the cryptographic layer, however, SE replaces the 64-bit DES-based key with AES-128 keys in a session-establishment protocol that is substantially closer to modern smartcard practice. The card and reader perform a mutual authentication that derives session keys from the long-term card and reader keys, and the actual identity exchange (CSN + facility code + card number) happens inside the authenticated session.

The cryptographic improvement is real. The published attacks against Legacy K0 and Elite KDF do not apply to SE; the underlying primitives (AES-128) have no known field-feasible attacks within the iCLASS SE deployment context. A pentester with the bare iCopy-X firmware looking at an iCLASS SE card sees: a card that reads as ISO 15693 at the inventory level, returns an anti-collision-cycle UID (the CSN in HID nomenclature), and then returns AES-encrypted noise when asked for any application data. The CSN is sometimes useful as a partial identifier — some access control systems are misconfigured to authenticate on CSN alone — but the standard SE deployment requires the full session-authentication exchange before granting access, and that exchange cannot be replayed.

The iCopy-X without the iCS Decoder accessory reads the SE CSN and stops there. The Auto Clone workflow displays the CSN and reports “iCLASS SE — iCS Decoder required for full clone.” The operator without the iCS Decoder cannot do anything else through the iCopy-X UI. Dropping to Proxmark Expert mode (Vol 8 §5) does not change the picture — the AES-128 keys are not in the base firmware, and brute-force is not feasible at any practical engagement timescale.

The path to actually cloning an iCLASS SE card is the iCS Decoder, covered in §3 below.

2.4 iCLASS SEOS — the secure-element generation

iCLASS SEOS (“Secure Element OS” or “Secure Object Service” — HID uses both expansions interchangeably) is the top of the iCLASS family and HID’s flagship secure platform. SEOS is application-based (architecturally similar to MIFARE DESFire in its file-system organisation, but with HID’s own application-layer protocol on top of AES-128 session crypto). Each SEOS card hosts one or more SIO (Secure Identity Object) files — encrypted credential containers — and each SIO is protected by its own keys managed through HID’s Origo cloud-issuance platform.

The cryptographic posture is the strongest of the iCLASS family: AES-128 mutual authentication, end-to-end encryption from card to reader to controller, per-credential keys, optional revocation, optional time-bound issuance, and optional issuance through the operator’s smartphone (mobile credential via HID Mobile Access). For high-security deployments — government facilities, financial institutions, data centers, regulated healthcare environments — SEOS is the contemporary default.

The pentester encountering SEOS faces the same posture as SE, only sharper. The CSN reads at the 15693 inventory level. Everything above the CSN is AES-encrypted opaque blocks. The base iCopy-X cannot do more than read the CSN. The Proxmark Expert mode does not help — SEOS does not have a published key compromise, and the SIO encryption is correctly implemented (in contrast to the iCLASS Legacy / Elite cryptographic mistakes).

The iCopy-X path to cloning SEOS is the iCS Decoder accessory plus a specific environmental condition: the target reader must accept “legacy SIO encoding” as a fallback authentication mode. Most SE / SEOS reader deployments in 2026 still have legacy card acceptance enabled in their configuration — this is HID’s default, intended to ease migration from older card stock during multi-year refresh cycles. When legacy SIO acceptance is enabled, the iCS Decoder can decode the SE or SEOS card’s identity components (CSN, Facility Code, Card Number) and write them to a legacy-format blank that the reader will accept. The Lab401 product page documents this coverage as approximately 85% of deployed SE / SEOS readers — the remaining 15% have disabled legacy acceptance and require either a non-cloning-based approach (RFID relay, social engineering, physical bypass) or simply represent out-of-scope hardening for the engagement.

This is the headline iCopy-X capability and the reason the iCS Decoder is a separate-purchase accessory.

3. The iCS Decoder — the only field-portable SE / SEOS cloner

The iCS Decoder is the iCopy-X accessory that closes the iCLASS SE and SEOS gap. Understanding it requires unpacking what it actually is, what it actually costs, what it actually requires of the target system, and where it sits in the engagement workflow.

3.1 What the iCS Decoder actually is

The iCS Decoder is a separate physical device — a USB-C-connected accessory roughly the size of an SD-card reader, 90 × 55 × 24 mm, 60 g. It is sold by Lab401 (the exclusive Europe / Oceania distributor for iCopy-X products from Nikola Lab) at $488 USD as of mid-2026. The Lab401 product page lists in-stock availability from the EU warehouse with next-day dispatch.

The kit ships with:

• 1× iCS Decoder device
• 3× iCLASS SE® / SEOS® Compatible Blank Cards (one-time-write — the cards can be programmed once with the decoded identity but cannot be reprogrammed afterward)
• 1× USB Type-C to Type-C cable

What the iCS Decoder is not:

• It is not a firmware-only unlock applied to the iCopy-X main unit. The Lab401 product page and the device specifications explicitly identify it as a physical accessory with its own dimensions, weight, USB-C connectivity, and antenna assembly.
• It is not a software license bound to the iCopy-X serial number. The iCS Decoder works with any iCopy-X that has a sufficiently recent firmware revision to recognize the accessory. The cryptographic capability lives in the accessory itself, not in a firmware unlock on the host iCopy-X.
• It is not a card-stock package. The three included blank cards are starter stock; the operator will need to source additional iCLASS SE / SEOS compatible blanks separately (Lab401 sells the iCLASS® SE/SEOS Compatible Blank Tag pack at ~$34 starting price — see Vol 9 §4).

The factual position is therefore: the iCS Decoder is a $488 USB-C device that physically plugs into the iCopy-X and adds SE / SEOS decoder capability to it. The host iCopy-X is required (the iCS Decoder cannot operate standalone — it has no LCD, no keypad, no battery, no UI), and the combination is the field-portable SE / SEOS cloning workflow.

3.2 How it works at the architecture level

The vendor does not publish detailed internals, but the visible design constraints tell most of the story.

The iCS Decoder houses its own HF coil antenna, tuned for the iCLASS SE / SEOS air-interface protocol. The iCopy-X’s main-unit HF coil is tuned for general-purpose HF (covering MIFARE, generic ISO 15693, iCLASS Legacy and Elite); the SE / SEOS protocol coupling characteristics differ enough — both in the carrier modulation profile and in the precise frequency response needed for the AES session-authentication exchanges — that a dedicated antenna assembly produces materially better read reliability than the general-purpose coil would.

The cryptographic processing for SE / SEOS happens in the iCS Decoder itself, not in the iCopy-X main unit. The Decoder must contain either the SE / SEOS key material (preloaded by Nikola Lab during manufacturing) or the algorithmic capability to derive it from observed card-reader exchanges plus public reference points. The Lab401 description of “the world’s first and only device capable of cloning and decoding iCLASS SE and SEOS tags” implies the former — preloaded keys or algorithmic capabilities that exploit a vulnerability in the HID Origo issuance pipeline. The vendor has not published the technical details, and the academic literature has not (as of mid-2026) published a definitive analysis of the underlying mechanism.

The iCopy-X main unit’s role during a SE / SEOS clone is to drive the iCS Decoder over USB-C, receive the decoded identity components (CSN, Facility Code, Card Number) from the Decoder, display them on the LCD, and then drive its main-unit HF coil to write those components to a blank legacy-format card. The Decoder is not used during the write step — only during the read-and-decode step. After the Decoder produces the identity components, the operator disconnects the Decoder, places a legacy-format blank on the iCopy-X main unit’s antenna, and the main unit writes the legacy-encoded credentials.

This split — the Decoder for read-and-decode, the iCopy-X main unit for write — is reflected in the device-instructions sequence on the Lab401 product page (which is reproduced essentially verbatim below in §3.4).

3.3 The “85% coverage” caveat and the legacy-acceptance environmental dependency

The iCS Decoder works by decoding the SE / SEOS card’s protected identity and re-encoding it as a legacy iCLASS Legacy or Elite format card. The resulting cloned card is not a legitimate SE / SEOS card — it does not satisfy the AES-128 mutual-authentication exchange that a fully-locked-down SE / SEOS reader would require. Instead, the cloned card relies on the target reader being configured to accept legacy card formats as a fallback when the SE / SEOS handshake doesn’t complete.

This fallback mode is HID’s default. It exists to ease migration: a customer rolling out SE / SEOS-capable readers across a campus over multiple years can keep their existing Legacy / Elite cards working at every reader, allowing the card-stock refresh to happen on its own timeline rather than synchronously with the reader replacement. The unintended consequence is that the legacy-acceptance configuration is also what makes the iCS Decoder’s cloning approach work.

The Lab401 product page reports approximately 85% coverage — about 85% of deployed iCLASS SE / SEOS reader installations have legacy acceptance enabled and will accept a cloned legacy-format card. The remaining 15% have disabled the legacy fallback through reader configuration, and those readers will refuse a cloned card regardless of how cleanly the iCS Decoder decoded the source.

For the pentester, the operational implication is that the iCS Decoder is not a guaranteed capability against any specific target. The 85% probability is favorable but not certain. Pre-engagement reconnaissance — observation of reader behavior at the target site, ideally with a known-Legacy test card to confirm whether legacy acceptance is enabled — gives the operator usable advance signal. If legacy acceptance is enabled, the iCS Decoder workflow will work for that site; if it is disabled, the engagement must plan a different attack path.

A useful diagnostic in the field: if the target site has a mix of older Legacy / Elite cards and newer SE / SEOS cards being used in parallel (for example, longer-tenured employees still have Legacy cards while recent hires have SE / SEOS cards), then legacy acceptance is necessarily enabled at the reader, and the iCS Decoder workflow is viable. If every card at the site has been refreshed to SE / SEOS — no Legacy / Elite cards in active use — then the reader configuration may have been hardened along with the card refresh, and the iCS Decoder workflow becomes uncertain.

3.4 The end-to-end workflow

The Lab401 product instructions for the iCS Decoder describe a six-step workflow. In annotated form, with the operational context Vol 8 of this series develops in detail:

1. Plug the iCS Decoder into the iCopy-X using the provided USB-C cable. The iCopy-X firmware auto-detects the Decoder within roughly 5 seconds. If auto-detect fails, unplug and replug — the firmware uses a USB enumeration sequence that occasionally needs a retry on first connection. Once detected, the iCopy-X LCD displays an “iCS Decoder ready” indicator.

2. Place the target iCLASS SE or SEOS card on the iCS Decoder antenna. The card sits flat on the top face of the Decoder, with the chip side facing the antenna. The Decoder reads the card through its dedicated HF coil — read range is short (typically under 2 cm) and the card must be aligned to the antenna.

3. The iCopy-X displays the decoded identity: CSN, Facility Code, Card Number. This is the cryptographic work — the Decoder performs the SE / SEOS session-authentication exchange (or its functional equivalent through whatever mechanism the Decoder uses internally), extracts the identity components from the authenticated channel, and ships them over USB-C to the iCopy-X for display.

4. Disconnect the iCS Decoder from the iCopy-X. The Decoder is no longer needed for the write step. Removing it lets the iCopy-X return to its main-unit HF coil as the active antenna.

5. The iCopy-X prompts for an iCLASS SE-compatible tag — the “iCS” prompt. This is the legacy-format blank that will receive the decoded identity. The “iCS-compatible” stock is iCLASS Legacy-format blanks that the iCopy-X firmware programs with the SE / SEOS-decoded identity components in a way that matches the legacy-format authentication that the target reader will accept (when legacy acceptance is enabled, per §3.3).

6. Place the blank card on the iCopy-X main-unit antenna and proceed with the write. The iCopy-X writes CSN + Facility Code + Card Number to the blank, encoded in legacy iCLASS format. The write step takes a few seconds. On completion, the iCopy-X displays the result and the cloned card is ready.

End-to-end timing for the complete workflow is approximately 60–90 seconds, including the time for the operator to swap cables and cards. The dominant component is the cryptographic exchange in step 3, which is materially slower than a Legacy / Elite clone because the SE / SEOS session establishment is computationally heavier than the older DES-based exchanges.

3.5 The 3D-printed iCopy-X + iCS Decoder holder

Lab401 publishes a free 3D-printable holder design that physically integrates the iCopy-X main unit and the iCS Decoder into a single bench-stable assembly. The holder is the 05-resources/iCopy-X iClass reader holder - 5189555/ directory of this subproject — the design files are STL format, printable on any consumer FDM printer (PLA at 0.2 mm layer height is sufficient). The holder includes a lock-bar variant for keeping the assembly closed during transport and an iCLASS-reader-mount variant for bench use.

For field work, the holder is optional — the iCopy-X and the iCS Decoder are robust enough to handle without it — but for bench testing, training, and engagement preparation, the holder makes the workflow substantially less fiddly. Particularly useful for the read step, where keeping the SE / SEOS card stably aligned to the Decoder antenna improves first-attempt read success rate.

3.6 Posture and legitimate use

The iCS Decoder is the most posture-sensitive single item in the iCopy-X ecosystem. iCLASS SE and SEOS are the technologies that high-security deployments — government facilities, financial institutions, data centers, healthcare — use specifically because the credentials cannot be casually duplicated. The iCS Decoder defeats that protection in approximately 85% of deployments. The operator carrying an iCS Decoder is carrying a capability that, used against the wrong target, sits squarely inside the most serious physical-security-related criminal statutes in every jurisdiction the operator could be in.

The legitimate use cases — and this volume of this series operates exclusively inside the legitimate envelope per Vol 1 §6 and Vol 12 — are:

• Authorized physical pentest of a target deployment that uses iCLASS SE or SEOS. The engagement scope explicitly includes RFID cloning; the client is the facility owner; the engagement letter documents the authorization and the scope.
• Facility-owner self-audit. The facility owner uses the iCopy-X + iCS Decoder against their own deployment to test what an attacker could do. The “authorization” is implicit in ownership, but documented internally for the avoidance of doubt.
• Red-team engagement with a formal red-team charter authorizing physical-access work and RFID cloning as part of the in-scope methodology.
• Law enforcement under appropriate warrant or other legal authority. Lab401’s product page explicitly cites LEA (law enforcement) as a legitimate use case for the iCS Decoder — making rapid clones of seized credentials during an active investigation. Operators in this category have their own legal framework.

Anything outside these categories is not what the iCS Decoder is for. The operator’s restraint is the only effective guardrail; the device itself cannot distinguish authorized from unauthorized use, and the iCopy-X firmware has no concept of engagement-scope enforcement. Vol 12 §3 develops the full posture treatment with the international variations on the relevant statutes (CFAA in the US, the Computer Misuse Act in the UK, the various national implementations of the EU NIS / NIS2 directives, and the rest of the international patchwork).

4. The ISO 15693 long-tail — iCODE SLI, SLIX, Tag-it, and the rest

Above the HID-specific iCLASS family, ISO 15693 is also the foundation for a substantial long-tail of generic vendor-neutral inventory and identification tags. These are the cards that show up in libraries, supply-chain operations, healthcare specimen tracking, asset management, and the occasional unusual access-control deployment. The iCopy-X handles them as a class because the Proxmark3 silicon supports ISO 15693 at the air-interface layer.

4.1 NXP iCODE SLI — the generic 15693 baseline

iCODE SLI is NXP’s flagship ISO 15693 inventory tag. Specifications: 13.56 MHz, full ISO 15693 compliance, 64-bit UID (the standard 15693 UID structure: 8-byte UID with a manufacturer code and a serial number), 1024 bits (128 bytes) of user memory organized into 32 blocks of 4 bytes each, no built-in encryption. The card reads at ranges up to ~10 cm in good conditions — substantially better than iCLASS or MIFARE because the larger physical antenna of a typical SLI tag (a label-style form factor) couples more strongly to the reader field.

The iCopy-X reads SLI cards natively. The Auto Clone workflow detects an SLI card by its standard 15693 inventory response, identifies the manufacturer code (NXP), reads the full 128 bytes of user memory, and writes them to a 15693-compatible blank. The cloning is trivially successful — SLI has no authentication step at all, the air-interface protocol is fully published, and the iCopy-X firmware has been handling these cards since the original iCopy product line.

Practical encounters with SLI in the field include:

• Library books. The supermajority of RFID-tagged libraries since ~2005 use SLI or its variants. The tag is bonded to the book’s spine or rear cover, encodes the library catalog ID, and is read by the self-checkout and security gates.
• Supply chain. Pallets, cartons, and high-value items in industrial supply chains often carry SLI labels for inventory tracking.
• Healthcare specimen tracking. Specimen tubes, sample containers, and patient wristbands in some healthcare deployments use SLI for tracking — though the trend in recent deployments has been to NTAG (Vol 5 §6) instead.
• Asset management. IT asset tagging, furniture inventory, conference badge tracking.

The pentester encountering SLI is usually doing so as adjacent context to other RFID work — the deployment that uses SE / SEOS for access control may also use SLI for asset tracking, and the operator may need to understand both technologies during a single engagement. Cloning SLI itself is rarely the engagement objective; reading and analyzing the encoded data more often is.

4.2 NXP iCODE SLIX — the privacy-protected variant

iCODE SLIX is the privacy-protected variant of SLI. The card hardware is identical at the chip level, but the firmware adds an optional privacy mode: when enabled, the card refuses to respond to the standard 15693 inventory request unless the reader first authenticates with a 32-bit PIN. The privacy mode is intended to prevent silent inventory of personal effects — the original use case was library books, where the privacy mode was meant to prevent a passerby from inventorying every book in a person’s bag, but the feature has propagated to other privacy-sensitive deployments.

The iCopy-X handles SLIX in three cases:

1. Privacy mode not enabled. The card behaves identically to standard SLI. Auto Clone works.
2. Privacy mode enabled, PIN known. The operator configures the iCopy-X with the PIN, the firmware authenticates to the card, and Auto Clone then proceeds. This is the case when the engagement scope provides the PIN as part of the authorization.
3. Privacy mode enabled, PIN unknown. The iCopy-X cannot complete Auto Clone. The operator can drop to Proxmark Expert mode (Vol 8 §5) and use the Proxmark3 SLIX PIN-recovery commands. The PIN space is 2^32, which is brute-forceable in principle but slow at air-interface speeds; for engagement timescales the PIN recovery is typically not viable unless prior intelligence narrows the search space substantially.

The encounter rate of privacy-mode SLIX in the field is much lower than the encounter rate of standard SLI. Most SLIX deployments leave privacy disabled, treating the card as if it were SLI.

4.3 NXP iCODE SLI-S and SLI-L — the extended-memory and extended-UID variants

iCODE SLI-S and SLI-L are NXP variants with extended memory (SLI-S has 160 bytes; SLI-L has more). The air-interface protocol is identical to SLI. The iCopy-X handles them natively as extended-memory variants of the base SLI.

These variants turn up in:

• Healthcare specimen tracking that needs more on-card metadata than 128 bytes allows.
• Industrial deployments with rich per-item data (process state, lot numbers, batch tracking).
• High-value asset management that wants to keep the asset history on the tag rather than relying on a network lookup.

4.4 Texas Instruments Tag-it and other 15693 vendors

Before NXP’s iCODE family dominated the 15693 market, TI’s Tag-it family was a significant alternative. The Tag-it physical chip is no longer in active production, but the installed base remains in some legacy supply-chain deployments and in older library systems that have not been refreshed.

The iCopy-X handles Tag-it through the same ISO 15693 air-interface implementation. The manufacturer code in the UID identifies TI rather than NXP, but the protocol exchange is identical and the iCopy-X firmware does not require any special configuration. Cloning is trivially successful.

Other 15693 vendors that the operator may encounter include Infineon (smaller market share, sometimes in industrial applications), STMicroelectronics (the LRI series of tags), and various Chinese-domestic chip vendors (variable quality and sometimes non-standard implementations of the 15693 protocol). The iCopy-X’s ISO 15693 implementation is conformant enough to handle the standard-compliant vendors and most of the Chinese-domestic variants. Genuinely non-standard implementations occasionally produce edge cases — a Chinese-domestic 15693 tag with a slightly off-spec 1-of-256 modulation timing, for example, may read intermittently or fail Auto Clone — and the operator’s recourse is Proxmark Expert mode for direct air-interface investigation.

4.5 ISO 18000-3 mode 1 and the relationship to 15693

A nomenclature note that occasionally confuses operators: ISO 18000-3 mode 1 is the air-interface standard that is functionally identical to ISO 15693. They are the same protocol; ISO 18000-3 mode 1 is the broader air-interface specification (which also covers other modes), and ISO 15693 is the narrower vicinity-coupling card specification. A datasheet may describe a tag as “ISO 18000-3 mode 1 compliant” or “ISO 15693 compliant” — both terms refer to the same air interface. The iCopy-X handles both descriptions identically. ISO 18000-3 mode 2 and mode 3 are different protocols (faster data rates, different modulation), and the iCopy-X does not support those modes.

5. FeliCa — Sony’s parallel HF universe

FeliCa (“Felicity Card” — the marketing name) is Sony’s HF technology, standardized as JIS X 6319-4 in Japan and as ISO 18092 internationally (where it sits alongside ISO 14443 as one of the NFC Forum’s foundational air-interface protocols). FeliCa is the technology that runs:

• Suica, Pasmo, ICOCA, and the other major Japanese transit cards. Every metro, JR rail, and bus system in Japan accepts FeliCa-based fare media. The combined installed base across Japanese transit is in the hundreds of millions of cards.
• EDY, nanaco, WAON, and the major Japanese stored-value micropayment systems.
• MIFARE FeliCa — NXP’s FeliCa-compatible chip lineage, used in some non-Japanese FeliCa deployments.
• EZ-Link (Singapore transit), MTR Octopus (Hong Kong transit — though Octopus has been migrating away from FeliCa to a hybrid platform), and various SE Asian transit systems.
• Apple Pay Suica and similar mobile-wallet emulations of FeliCa-based transit fare.

At the physical layer, FeliCa is 13.56 MHz like every other HF technology covered in this volume, but the modulation differs: FeliCa uses Manchester encoding at the bit level and supports two data rates — 212 kbit/s (the original speed) and 424 kbit/s (the higher-speed mode used in transit-gate applications where read time matters). The Manchester encoding and the data rate are immediate diagnostics: a card that returns valid responses at 212 or 424 kbit/s with Manchester-coded bits is FeliCa; the standard ISO 14443A and 14443B and 15693 modulations look different at the air interface.

The iCopy-X reads FeliCa natively at the air-interface layer. The Auto Clone workflow detects the FeliCa response pattern, identifies the card by its IDm (the FeliCa equivalent of UID — an 8-byte manufacturer-and-serial identifier), and reads the available system codes (FeliCa uses “system codes” — 16-bit values — to identify the applications running on the card). For most field encounters, this is the entire workflow: the operator reads the IDm and the deployment-specific system codes, displays the result, and the engagement either uses the IDm as part of an attack chain or moves on.

What the iCopy-X cannot do is the full FeliCa cryptographic exchange. FeliCa uses application-layer encryption (typically 3DES-based) for the payment / fare / stored-value data, and the keys are deployment-specific and not publicly known. The Suica card’s transaction history, the EDY card’s balance, the iC pay token — none of these are extractable through air-interface attack with the iCopy-X. The operator who reads a Suica card with the iCopy-X gets the IDm and the system code, not the fare history or the balance.

The pentester encountering FeliCa is most commonly doing so:

• In Japan, as part of an engagement against a target with a FeliCa-based access-control deployment. Some Japanese corporate access-control systems use FeliCa cards (often the same physical media as the employee’s transit card, for the convenience of merging credentials). In this case, the IDm read is sufficient if the access control authenticates on IDm alone — a misconfiguration that the iCopy-X exposes cleanly.

• In Asian deployments more broadly. A Singapore engagement may encounter EZ-Link; a Hong Kong engagement may encounter Octopus; a Taiwanese engagement may encounter EasyCard. Each of these has slight protocol variations but all are within FeliCa or close enough that the iCopy-X reads them.

• In NFC interoperability work outside of Asia. Apple Pay and Google Pay have FeliCa modes for use in Japan; some Western enterprise card deployments occasionally use NTAG-FeliCa hybrid cards (the chip supports both NFC Forum Type 2 and FeliCa modes); the iCopy-X handles the FeliCa half of these interactions correctly.

The iCopy-X is rarely the right tool for FeliCa-specific work in Japanese markets where FeliCa-specific tools (the open-source felicat project, the proprietary PaSoRi reader from Sony, and various Japanese-domestic engineering tools) dominate the technical depth. For the iCopy-X user, FeliCa is mostly a “the card reads as FeliCa, here’s the IDm, decide if that’s useful” capability, not a full FeliCa research platform.

6. Topaz — the simplest NFC Forum Type 1

Topaz is the trade name for the simplest NFC Forum Type 1 tag chip, originally produced by Innovision Research & Technology, which was acquired by Broadcom in 2010. The chip lineage is the TopazIIIB and the Topaz 512, the latter having 512 bytes of memory versus the original’s 96 bytes.

The Topaz air interface is ISO 14443A-derived but with several simplifications: anti-collision is a simpler exchange than the standard 14443A cascade, the data rate is fixed at 106 kbit/s, and the command set is small enough that the protocol can be described on a single page. The 96 bytes of user memory (in the original Topaz) are organized into 12 blocks of 8 bytes, with the first block reserved for the 4-byte UID, lock bytes, and the OTP (one-time-programmable) section. The 512-byte variant has substantially more memory but the same protocol structure.

The iCopy-X handles Topaz natively. The Auto Clone workflow reads the 4-byte UID, the lock-byte status, and the user memory contents, then writes the full image to a Topaz-compatible blank or to a Magic UID card configured to emulate Topaz.

Practical encounters with Topaz in 2026 are uncommon. The chip was widely used in early-generation NDEF (NFC Data Exchange Format) smart posters around 2010–2013 — the “tap your phone to get this URL” tags embedded in advertising posters — but the volume migrated to NTAG (Vol 5 §6) for the cost-and-features advantages NTAG offered. The remaining Topaz installed base is mostly:

• Older NDEF smart posters that have not been refreshed.
• Some legacy product authentication labels.
• Hobbyist NFC writers who bought Topaz blanks from early-2010s stock.

The pentester encountering Topaz is usually doing so in an “encyclopedia coverage” sense — the technology exists, the iCopy-X reads it, the data is trivial to extract because there is no authentication layer at all. Topaz is the simplest HF technology in scope; it deserves a paragraph rather than a chapter.

7. Legic — the European proprietary HF protocol

Legic Identsystems, headquartered in Switzerland, manufactures a family of proprietary HF protocols that are widely deployed in European access control, particularly in Germany, Switzerland, and Austria. Legic does not use ISO 14443 or ISO 15693 — the protocol is proprietary and runs at 13.56 MHz with its own modulation and command structure. The two major generations are Legic Prime (the older platform) and Legic Advant (the modern AES-based platform).

7.1 Legic Prime — the broken-cipher generation

Legic Prime was the original platform, introduced in the 1990s. The cryptographic design used a 4-bit nonce in the authentication exchange and a proprietary stream cipher whose internal state was small enough to be exhaustively recoverable. The Prime cipher was reverse-engineered and broken in academic and security-research work in the late 2000s, and tools for cracking Prime keys have been publicly available since.

The iCopy-X handles Legic Prime natively. The Auto Clone workflow detects the Prime air-interface response, recovers the per-card key (or uses operator-provided keys for deployments with non-default key configurations), reads the card data, and writes it to a Prime-compatible blank. The cloning is approximately as fast as iCLASS Legacy — 30 seconds end-to-end.

The remaining installed base of Prime in 2026 is mostly older German / Swiss / Austrian access control that has not been refreshed to Advant. The encounter rate has been declining since ~2010 but Prime is still common in long-tail facility installations.

7.2 Legic Advant — the modern AES generation

Legic Advant is the modern Legic platform, using 3DES-based (and in later revisions, AES-based) cryptography with proper key management. The cryptographic posture is substantially stronger than Prime — there is no published key-recovery attack at the air-interface level that works against properly-configured Advant deployments.

The iCopy-X reads the Advant UID (the air-interface inventory step returns a UID-like identifier) but cannot decode the application data without operator-provided keys. The case is analogous to iCLASS SE: the basic identity is readable, the actual application content is encrypted, and the cloning is not viable through air-interface attack alone.

For Advant, the operator’s path to a clone is the same as for iCLASS SE without the iCS Decoder: either the operator has the key (typically because the engagement provided it), or the operator does not have the key and reports a failure-mode finding. Unlike iCLASS SE / SEOS, there is no Legic-specific decoder accessory equivalent to the iCS Decoder as of mid-2026. Legic Advant is, in operator-practical terms, an out-of-scope card for the iCopy-X when the key is unavailable.

The pentester encountering Legic in 2026 should treat Prime as a routine cloning task (the iCopy-X handles it) and Advant as a key-dependent task (operator-side knowledge required). The encounter probability skews European; a North American engagement is unlikely to see Legic except at multinational employer sites that use the same card stock globally.

8. Per-family cloning workflow summary

The closing reference for this volume is the per-family cloning workflow table — what the operator does for each technology in this Part 2 scope, at a glance:

Family	iCopy-X workflow	Blank stock	Typical time	Caveat
iCLASS Legacy	Auto Clone → reads CSN/FC/CN with built-in K0 key → writes to iCLASS-compatible blank	iCLASS Legacy compatible blank (Vol 9 §4)	~30 sec	None — K0 is built into firmware
iCLASS Elite (key known)	Operator configures Elite key → Auto Clone proceeds identically to Legacy	iCLASS Legacy compatible blank	~30 sec	Requires Elite key in firmware configuration
iCLASS Elite (key unknown)	Sniff mode at live reader → capture exchanges → host-side or on-device key recovery → Auto Clone	iCLASS Legacy compatible blank	Minutes to hours	Recovery success depends on captured exchanges; Proxmark3 better for offline cryptanalysis
iCLASS SE	iCS Decoder accessory: plug Decoder, read card on Decoder, decode CSN/FC/CN, unplug, write to legacy-format blank on iCopy-X main unit	iCLASS SE/SEOS compatible blank (one-time-write)	~60–90 sec	Requires iCS Decoder ($488); requires target reader to accept legacy SIO (~85% of deployments)
iCLASS SEOS	Same as SE — iCS Decoder workflow	iCLASS SE/SEOS compatible blank (one-time-write)	~60–90 sec	Requires iCS Decoder; requires target reader to accept legacy SIO; ~85% of deployments are vulnerable
iCODE SLI	Auto Clone → reads 128 bytes user memory → writes to 15693 blank	Generic 15693 magic blank	~10 sec	None — trivially clonable
iCODE SLIX (no privacy)	Same as SLI	Generic 15693 magic blank	~10 sec	None
iCODE SLIX (privacy enabled, PIN known)	Operator configures PIN → Auto Clone proceeds	Generic 15693 magic blank	~15 sec	Requires PIN
iCODE SLIX (privacy enabled, PIN unknown)	Proxmark Expert mode → SLIX PIN-recovery commands → if successful, Auto Clone	Generic 15693 magic blank	Hours; often not feasible	2^32 PIN space rarely brute-forceable in engagement window
Tag-it (TI)	Same as SLI — air-interface identical	Generic 15693 magic blank	~10 sec	None
FeliCa	Auto Clone reads IDm + system codes; full content read requires deployment keys	FeliCa-compatible blank (rare; iCopy-X support limited)	~10 sec for IDm-only	Most FeliCa applications are encrypted; iCopy-X is rarely the right tool for full FeliCa cloning
Topaz	Auto Clone → reads 4-byte UID + 96 bytes (or 512 bytes for Topaz 512) → writes to compatible blank	Topaz-compatible blank or Magic UID emulator	~10 sec	Trivially clonable; no authentication
Legic Prime	Auto Clone with key recovery → reads card data → writes to Prime blank	Legic Prime compatible blank	~30 sec	Cipher broken; Prime is routinely clonable
Legic Advant (key known)	Operator configures key → Auto Clone proceeds	Legic Advant compatible blank	~30 sec	Requires operator-supplied key
Legic Advant (key unknown)	Not viable through iCopy-X	—	—	No Legic Advant equivalent of iCS Decoder; key-dependent

Vol 7 walks the Auto Clone, Scan, Read LF / Read HF, and Sniff operating modes in operational depth; Vol 8 covers Emulation modes and the Proxmark Expert escape hatch where the workflow above hits Proxmark-mode steps; Vol 9 walks the blank-card ecosystem with the per-vendor sourcing detail (Lab401 “Genuine” packs versus the AliExpress alternatives, OTP behavior on the one-time-write iCLASS blanks, lock-bit gotchas on Magic UID cards).

9. Where this volume hands off

This volume completes the HF-family encyclopedia. Combined with Vol 5 (the MIFARE family) and Vol 4 (the LF families), the operator now has the full per-technology reference for what the iCopy-X reads and writes at the air-interface layer. The next volumes turn from “what the cards are” to “what the iCopy-X does to them”:

• Vol 7 (Operating modes Part 1) — the Auto Clone, Scan, Read LF, Read HF, and Sniff modes. The load-bearing operational reference for day-to-day field work.
• Vol 8 (Operating modes Part 2) — Emulation LF and HF, and the Proxmark Expert escape hatch for when the standard modes can’t complete the workflow.
• Vol 9 (Card-stock ecosystem) — which blank card to use for which technology, why Lab401 “Genuine” packs are worth the premium for professional work, where the AliExpress alternatives fail predictably, and the per-vendor OTP and lock-bit behavior the operator needs to anticipate.

For posture, the iCLASS SE / SEOS section (§2.3, §2.4) and the iCS Decoder section (§3) are the load-bearing posture chapters of this volume — they describe the capability that is most consequential outside the legitimate use envelope, and they are the chapter to re-read before any engagement that includes SE / SEOS targets. Vol 12 is the long-form posture and legal treatment with the cheatsheet.

10. Cross-references and resources

• Vol 1 (Overview) — series structure, decision graph, where the iCopy-X sits in the Hack Tools lineup.
• Vol 3 (RFID / NFC primer) — LF and HF physics, ISO 14443A/B and 15693 air-interface basics, why some cards crack and others do not.
• Vol 5 (HF Part 1: MIFARE family) — the NXP-driven half of HF that this volume’s HID-driven half complements.
• Vol 7 (Operating modes Part 1) — Auto Clone, Scan, Read LF / Read HF, Sniff.
• Vol 8 (Operating modes Part 2) — Emulation and Proxmark Expert mode.
• Vol 9 (Card-stock ecosystem) — blank-card sourcing and per-family blank selection.
• Vol 11 (Comparisons) — iCopy-X vs Proxmark3 RDV4 vs Flipper Zero on iCLASS / 15693 / FeliCa coverage.
• Vol 12 (Legal, ethics, posture, cheatsheet) — the legal envelope with international variation.

Cross-tool references:

• ../Proxmark3 RDV4/ — the lab sibling with the open client SDK; the better tool for offline Elite key cryptanalysis and for SLIX PIN recovery work.
• ../Flipper Zero/ — the multi-tool sibling; weaker iCLASS support, no SEOS support in mainline (Momentum / Xtreme add partial), but useful when the engagement scope extends beyond RFID.
• ../Hacker Tradecraft/02-inputs/volume_sources/vol15.md — the cross-cutting RFID / NFC / access-control tradecraft volume in the Hacker Tradecraft series.

Vendor and academic references:

• HID Global, “iCLASS Credential and Reader Technology” — product documentation across the Legacy / Elite / SE / SEOS family; https://www.hidglobal.com/products/cards-and-credentials/iclass.
• Garcia, F. D., de Koning Gans, G., Muijrers, R., van Rossum, P., Verdult, R., Wichers Schreur, R., Jacobs, B. — “Dismantling iCLASS and iCLASS Elite”, ESORICS 2010 — the canonical academic paper that broke iCLASS Legacy and weakened Elite.
• Meijer, C., Verdult, R. — “Ciphertext-Only Cryptanalysis on Hardened MIFARE Classic Cards” and the related Elite analysis work, 2015 — the follow-up cryptanalysis that sharpened the Elite key-recovery toolchain.
• NXP Semiconductors, “iCODE SLI / SLIX / SLI-S / SLI-L Datasheet Series” — the canonical reference for the NXP 15693 product line.
• Sony Corporation, “FeliCa Technical Documentation” — the FeliCa air-interface and command reference.
• Legic Identsystems, “Legic Advant Family Product Documentation” — the Legic vendor reference.

Local resources in ../../05-resources/:

• iCS Decoder for iCLASS® SE _ SEOS Decoder — Lab401.pdf — the Lab401 product page for the iCS Decoder; the primary vendor reference for the workflow and the 85%-coverage caveat documented in §3 above.
• iCopy-X-User-Manual.pdf — the iCopy-X user manual including the iCLASS-family handling sections.
• iCopy-X iClass reader holder - 5189555/ — the 3D-printable iCopy-X + iCS Decoder holder design files, referenced in §3.5 above.