iCopy-X / iCopy-XS — Legal, Ethics, Posture, Cheatsheet, Glossary

1. The baseline legal envelope

This volume is not legal advice. It is engineer-grade orientation written by an engineer for an engineer. The statutes cited below are real and the citations are correct as of 2026-05; the interpretations are conservative, mainstream, and rely on widely-published secondary literature. Before doing any work that depends on a specific legal posture, talk to an attorney licensed in the relevant jurisdiction. The cost of a one-hour consultation is far less than the cost of getting this wrong.

Every tool in the Hack Tools hub operates under a single baseline rule that the project-level ../_shared/legal_ethics.md document states canonically and that this volume restates in iCopy-X-specific terms:

Own the hardware you are working on, or have explicit written authorization from the owner.

For the iCopy-X this rule is structural, not aspirational. The device cannot tell whether the card held against the antenna belongs to the operator or to someone else. It cannot tell whether the operator has authorization to clone the card or whether the operator is in the wrong jacket pocket of the wrong person at the wrong time. The same Auto Clone button press described in Vol 7 §3 is, depending entirely on documentation that lives in the operator’s bag and not in the device’s firmware, either a professional security activity billed at the operator’s hourly rate or a federal felony under 18 USC § 1030. The hardware is identical in both cases. The legal envelope is entirely on the operator’s side, and the documentation in the engagement folder is what makes the envelope real.

The distinction is worth restating because it is unusual in the broader hardware-hacking space. Most tools covered in the ../ hub have a clearer operational envelope — a Flipper Zero scanning 433 MHz sub-GHz traffic is doing something that has obvious lab-vs-field signal regardless of context; a HackRF One transmitting custom waveforms requires deliberate setup that signals intent; even the WiFi Pineapple’s PineAP rogue-AP behaviour announces itself loudly on the air. The iCopy-X’s Auto Clone is silent, fast, and physically indistinguishable from a maintenance worker briefly tapping their badge twice. The documentation is the only thing that distinguishes the two.

In practice every legitimate operator carries the documentation explicitly. A pentest team member carries a signed Statement of Work and a client Authorization Letter on their person; a corporate red-team operator carries a current red-team charter signed by a corporate officer; a facility-owner self-audit operator carries (in effect) the deed to the building. The documentation is not paranoia or excessive caution — it is the affirmative defense that turns an action that would otherwise be a felony into authorized professional work. It is also the artifact that, if the operator is challenged on-site, ends the challenge quickly and professionally instead of escalating it.

The remainder of this section gives the engineer-grade orientation on what statutes apply in the major jurisdictions an operator working with an iCopy-X is likely to encounter. The treatment is conservative — when statute interpretation is contested, this volume adopts the more cautious reading and points at where the contest lies rather than picking a side. Operators doing serious work should retain counsel who can give the jurisdiction-specific reading.

2. Jurisdictional treatments

2.1 United States — federal

The United States has multiple overlapping federal statutes that potentially apply to RFID and NFC work, and the overlap is part of the difficulty. The same act of cloning a card can trigger different statutes depending on what kind of card it was, what the operator did with the clone afterward, and what state the operator was physically standing in.

18 USC § 1030 — Computer Fraud and Abuse Act (CFAA). The CFAA is the broadest and most-litigated federal computer-crime statute. Section 1030(a) prohibits “intentionally access[ing] a computer without authorization or exceed[ing] authorized access” with various aggravating factors raising the penalty. Courts have read “protected computer” extremely broadly — in Van Buren v. United States, 593 U.S. 374 (2021), the Supreme Court narrowed the “exceeds authorized access” prong but the “without authorization” prong remains expansive. An RFID-based access-control system at a corporate building is, under the prevailing reading, a “protected computer” because it uses interstate commerce (the manufacturer is in a different state, the back-end is cloud-hosted, etc.) and makes access decisions based on computer logic. Cloning a card to obtain access is “access[ing]” that computer.

The affirmative defense is authorization. A signed pentest Statement of Work from the building owner is the canonical form. The CFAA does not require a specific format; what it requires is that the owner of the system actually authorized the access in question, and that the authorization actually covered what the operator did. This is where engagement-folder discipline matters: an SOW that authorizes “physical security assessment” but does not explicitly authorize “RFID badge cloning” may or may not cover an iCopy-X Auto Clone, depending on which Federal Circuit the prosecution lands in. Explicit is better than implicit. The well-written SOW lists the in-scope card formats by name (HID Prox, iCLASS Legacy, MIFARE Classic, iCLASS SE/SEOS) and lists the out-of-scope formats (payment cards, government identity documents) by name too.

Penalties under § 1030 range from a misdemeanor (up to one year) for simple unauthorized access to ten years for unauthorized access with intent to defraud, and twenty years for repeat offenders or for actions causing significant damage.

18 USC § 1028 — Identity Document Fraud. Section 1028 prohibits trafficking in, producing, or using false identification documents. The technical question for iCopy-X work is which RFID-bearing tokens count as “identification documents” under the statutory definition at § 1028(d)(3): “a document made or issued by or under the authority of the United States Government, a State, political subdivision of a State, a sponsoring entity of an event designated as a special event of national significance, a foreign government, political subdivision of a foreign government, an international governmental or quasi-governmental organization which, when completed with information concerning a particular individual, is of a type intended or commonly accepted for the purpose of identification of individuals.”

Corporate access-control badges generally are NOT “identification documents” under this definition — they are issued by private entities and are not commonly accepted for general identification. Driver’s licenses with embedded RFID (some states), passports with embedded RFID (all ICAO-compliant passports), national identity cards (most countries have them; the US does not), and Department of Defense Common Access Cards (CACs) clearly ARE identification documents. Cloning these moves the operator squarely into § 1028 territory regardless of whether they also violate the CFAA.

The penalty structure under § 1028 includes specific aggravators for “transfer or use of a means of identification with intent to commit, aid, or abet any unlawful activity” — penalties up to fifteen years.

18 USC § 1029 — Access Device Fraud. Section 1029 prohibits trafficking in or using “access devices” with intent to defraud — defined at § 1029(e)(1) as “any card, plate, code, account number, electronic serial number, mobile identification number, personal identification number, or other telecommunications service, equipment, or instrumental identifier, or other means of account access that can be used, alone or in conjunction with another access device, to obtain money, goods, services, or any other thing of value, or that can be used to initiate a transfer of funds.”

The supermajority of corporate access-control badges are NOT access devices under this definition (they do not access money, goods, or services in the financial sense). Credit cards, debit cards, EBT cards, calling cards, and contactless payment cards (EMV) ARE access devices and clearly fall under § 1029. Transit cards may or may not be access devices depending on the system — fare media that store stored value typically are; tap-and-go systems that link to a backend account may be. The iCopy-X should not be pointed at any payment card or transit card under any circumstances regardless of authorization claims; the legal exposure is severe and the statute is close to strict-liability in its intent-to-defraud element.

Penalties under § 1029 range up to fifteen years for fraudulent use or trafficking.

47 USC § 605 — Unauthorized Reception of Communications. Section 605 prohibits unauthorized reception, divulgence, or use of “wire or radio communications”. The technical question for iCopy-X work is whether RFID and NFC near-field communications are “radio communications” under the statutory definition.

The mainstream interpretation, supported by the limited case law that exists, is that proximity-coupled near-field communications at the iCopy-X’s operating distances (low-frequency 125 kHz, high-frequency 13.56 MHz, both within a few centimeters of the antenna) are not “radio communications” in the § 605 sense, because they are not “communications by wire or radio” intended for any broader audience — they are point-to-point cryptographic transactions between a card and a reader. This interpretation is not unanimously settled, however; courts in some circuits could read § 605 to apply, especially for active sniffing of legitimate transactions between a card and a third-party reader (which is more clearly an “interception” than is reading a card the operator is physically holding).

The conservative reading: the iCopy-X’s Auto Clone mode, which transacts with a card the operator is holding, is not within § 605. The Sniff mode (Vol 7 §4), which captures a transaction between a card and a reader for offline key recovery, is closer to the § 605 line. Authorized engagements should explicitly cover sniffing in the SOW.

The Stored Communications Act, 18 USC §§ 2701-2712. The SCA’s relevance to RFID work is limited but real for engagements that include reading data off NFC-bearing devices (Apple Pay / Google Pay tokens, NFC-equipped smartphones). The SCA covers stored electronic communications and stored data on remote computing services; an NFC token stored on a phone is technically “stored data on an electronic communication service” in some readings. This is mostly an issue only when the engagement extends to mobile-device NFC payloads. The iCopy-X is not the right tool for that work anyway (its strength is access-control cards, not phone-mediated payments).

2.2 United States — state law

State computer-crime statutes vary widely in scope, and the variance matters because the conservative operator should expect to be prosecuted under whichever statute is harsher — federal or state — in any actual incident. A handful of representative examples:

California Penal Code § 502 — Unauthorized Access to Computer Systems. Section 502(c) prohibits a long list of computer-related actions, including “knowingly accesses and without permission alters, damages, deletes, destroys, or otherwise uses any data, computer, computer system, or computer network” (§ 502(c)(1)) and “knowingly and without permission disrupts or causes the disruption of computer services” (§ 502(c)(5)). California courts have read this broadly. The penalties are significant — a felony with up to three years and substantial fines for most subsections.

The relevance for iCopy-X work in California: a corporate access-control system is unambiguously a “computer system” under California’s broad reading, and unauthorized cloning is unambiguously “alteration” or “use” of that system. The authorization defense applies but California’s version requires demonstrably express permission — informal verbal authorization that would survive a CFAA prosecution may not survive a § 502 prosecution.

Texas Penal Code Title 7 Chapter 33 — Computer Crimes. Texas’s statute is narrower than California’s. Section 33.02 (Breach of Computer Security) requires the actor to “knowingly access[] a computer, computer network, or computer system without the effective consent of the owner”. The “effective consent” standard is well-developed in Texas case law and tends to be satisfied by ordinary written authorization. Penalties range from a Class A misdemeanor for simple breaches to first-degree felonies for breaches involving harm to critical infrastructure.

The relevance for iCopy-X work in Texas: the authorization standard is more workable than California’s. Standard SOW + Authorization Letter forms generally satisfy § 33.02’s “effective consent” requirement.

New York Penal Law Article 156 — Offenses Involving Computers. Article 156 has multiple grades of unauthorized computer access, from Computer Trespass (a misdemeanor) up to Computer Tampering in the First Degree (a Class C felony for tampering causing more than $50,000 in damages). The statute’s “unauthorized” standard is interpreted similarly to the CFAA’s.

Other states. The remaining 47 states have analogous statutes, most modeled on either the CFAA or one of the early state precedents (California’s, New York’s, or Illinois’s). The variance among them is substantial enough that an engagement spanning multiple states should have counsel review the SOW for state-by-state applicability.

2.3 European Union

General Data Protection Regulation (GDPR), Regulation (EU) 2016/679. GDPR applies to the processing of personal data of EU residents, including data on RFID tokens used for identification or access control. Article 32 (Security of processing) makes “demonstrably unauthorized access” to identity data a regulable event for the controller (the entity that determines purposes of processing) and the processor (the entity that processes data on the controller’s behalf). For an iCopy-X engagement, the building owner is typically the controller; the pentest firm and its operators are processors.

This has two practical implications. First, an authorized engagement should explicitly designate the pentest firm as a processor under a written Data Processing Agreement (DPA) compliant with Article 28. Second, the SOW should explicitly authorize the handling of identifier data — UIDs, sector keys, AIDs, encrypted blobs that resolve to a person — and should specify the retention period and destruction protocol for that data (§4.5 below).

Penalties under GDPR are administrative rather than criminal, but they are large: up to €20 million or 4% of global annual turnover, whichever is greater, for the most serious infringements. The penalties fall on the controller and the processor, not on the individual operator, but a deficient DPA structure can result in the pentest firm being personally exposed.

Directive 2013/40/EU — Attacks Against Information Systems. This is the EU’s harmonized computer-crime directive, the regional analog of the CFAA. It requires member states to criminalize “illegal access to information systems” (Article 3), “illegal system interference” (Article 4), “illegal data interference” (Article 5), and “illegal interception” (Article 6). Each member state implements the directive in its own criminal code with national variations, but the floor is harmonized across the EU.

The directive’s authorization standard is similar to the CFAA’s: the action must be “without right” (Article 3), which is read to mean without the consent of the rights-holder. Standard SOW + Authorization Letter satisfies this.

Penalties under the directive are floors that member states must exceed: minimum maximum penalties of two years for basic offenses, three years for aggravated offenses, and five years for offenses committed against critical infrastructure or as part of a criminal organization.

National implementations. A few representative examples of how member states implement the directive in their own criminal codes:

• Germany — StGB § 202a (Ausspähen von Daten / Data Espionage). Criminalizes unauthorized acquisition of data secured against access. Penalty up to three years. § 202c (Vorbereiten des Ausspähens und Abfangens von Daten / Preparation) is the controversial “hacker tools” prohibition that criminalizes producing or supplying tools designed for the purpose — interpreted reasonably narrowly in practice but technically broad.
• France — Code pénal § 323-1 (Accès frauduleux / Fraudulent Access). Penalty up to two years (or three if data is altered or destroyed). § 323-2 (entrave / system disruption) and § 323-3 (data manipulation) add aggravators.
• Italy — Codice Penale art. 615-ter (Accesso abusivo a un sistema informatico / Unauthorized Access). Penalty up to three years, with aggravators for committing the offense by a public official or with violence.
• Spain — Código Penal art. 197 bis (Acceso ilícito). Penalty up to two years for unauthorized access; up to three years if obtained through breaching security measures.

The variance across implementations is substantial enough that an operator doing engagements across multiple EU member states needs the engagement-folder documentation to cover the worst case among them.

2.4 United Kingdom

The UK left the EU in 2020 but kept the substance of the EU-aligned computer-crime regime in its existing national statute.

Computer Misuse Act 1990 (CMA), as amended. The CMA is the UK’s foundational computer-crime statute. Its substantive offenses are:

• § 1 — Unauthorised access to computer material. Summary offense, penalty up to twelve months on summary conviction, two years on indictment. The basic offense.
• § 2 — Unauthorised access with intent to commit or facilitate commission of further offences. Penalty up to five years on indictment. Aggravated form of § 1.
• § 3 — Unauthorised acts with intent to impair, or with recklessness as to impairing, operation of computer. Penalty up to ten years on indictment. The disruption / damage offense.
• § 3A — Making, supplying or obtaining articles for use in offence under sections 1 or 3. The UK “hacker tools” offense, interpreted reasonably narrowly in practice but technically broad. Penalty up to two years on indictment.
• § 3ZA — Unauthorised acts causing, or creating risk of, serious damage. Penalty up to fourteen years (or life for endangering human welfare or national security). Added by the Serious Crime Act 2015. Relevant only for the most serious incidents.

For iCopy-X work in the UK, an interesting wrinkle is the § 3 territory: if the cloning of a card is authorized but the subsequent use of the clone is not separately authorized, the use itself can be a § 3 offense even if the cloning was a § 1 non-offense (because it was authorized). This is an unusual structural feature of the CMA that does not have an obvious CFAA analog, and it means SOWs for UK engagements should explicitly authorize both the cloning AND any planned subsequent use of the cloned card.

Data Protection Act 2018 and UK GDPR. Post-Brexit, the UK retained a near-identical version of GDPR as domestic law. The substantive obligations are essentially identical to EU GDPR for iCopy-X work. The supervisory authority is the Information Commissioner’s Office (ICO); maximum administrative penalties match the EU GDPR’s €20m / 4% scheme converted to GBP.

2.5 Canada

Criminal Code § 342.1 — Unauthorized Use of Computer. The Canadian federal statute. Subsection (1) criminalizes obtaining “any computer service” or “intercept[ing] or caus[ing] to be intercepted, directly or indirectly, any function of a computer system” fraudulently and without colour of right. Penalty up to ten years on indictment.

The “colour of right” standard is the authorization defense — operator has colour of right if they reasonably believe (and the belief is supported by documentation) that they have authority to perform the access. Standard SOW + Authorization Letter satisfies this.

Criminal Code § 403 — Identity Fraud. Section 403 criminalizes fraudulently personating “another person, living or dead” with intent to gain advantage, obtain property, or cause disadvantage to any person. Cloning a corporate access badge and using it to enter a building under the badge-holder’s identity is potentially within § 403’s reach even when the cloning itself is authorized (because the use is impersonation). Penalty up to ten years.

For Canadian engagements, the SOW should explicitly cover the impersonation element, similar to the UK CMA § 3 wrinkle.

2.6 Australia

Criminal Code Act 1995 (Cth), Part 10.7 — Computer Offences. Part 10.7 covers the Commonwealth-level computer crimes:

• § 477.1 — Unauthorised access, modification or impairment with intent to commit a serious offence. Penalty: same as the underlying serious offense (up to life imprisonment for the most serious cases).
• § 477.2 — Unauthorised modification of data to cause impairment. Penalty up to ten years.
• § 477.3 — Unauthorised impairment of electronic communication. Penalty up to ten years.
• § 478.1 — Unauthorised access to, or modification of, restricted data. Penalty up to two years.
• § 478.2 — Unauthorised impairment of data held on a computer disk etc. Penalty up to two years.

State-level statutes in each Australian state add their own variations. The Commonwealth statutes apply when the offense affects “Commonwealth data” or “telecommunications” in the federal sense; state statutes cover the residual.

The authorization standard is similar to the CFAA’s. Standard SOW + Authorization Letter satisfies the typical case.

2.7 The general principle

Across all the jurisdictions surveyed, the common structural pattern is:

1. Unauthorized access to a computer system is criminalized, with penalties scaling by the type of data and the harm caused.
2. Authorization is an affirmative defense — the operator must be able to produce documentation showing they had permission.
3. Specific categories of data are subject to heightened protection: payment cards, government identity documents, medical records.
4. Subsequent use of cloned material may be a separate offense from the cloning itself, requiring separate authorization in the SOW.
5. The pentest firm and the operator have separate exposures — the firm under data-protection statutes (GDPR, UK DPA, state privacy laws); the operator under computer-crime statutes (CFAA, CMA, equivalents).

An engagement-folder discipline that produces documentation satisfying the strictest of these jurisdictional requirements is robust against all of them. The next two sections describe what that documentation looks like.

3. The bright lines this series tells the operator NOT to cross

Some categories of card and some operational behaviours sit on top of statutes that are harsh enough, narrow enough, or close enough to strict liability that no authorization an operator is likely to obtain in routine practice will protect them. This series treats these as bright lines — do not cross them, period. The iCopy-X firmware will technically attempt to read most of them; the operator’s restraint is the only guardrail.

3.1 Payment cards

EMV contactless payment cards (Visa payWave, Mastercard PayPass, American Express ExpressPay), Apple Pay / Google Pay / Samsung Pay tokens, contactless debit cards, prepaid contactless cards, EBT contactless cards, and any other payment-credential-bearing RFID-NFC artifact is OUT OF SCOPE for iCopy-X work regardless of authorization claims.

The reasons:

• 18 USC § 1029 (US) is close to strict liability on the intent-to-defraud element when payment cards are involved. Federal prosecutors have wide discretion and the case law gives them a comfortable runway.
• The Payment Card Industry Data Security Standard (PCI DSS) governs the handling of payment card data. PCI DSS compliance is contractual, not statutory, but breaches generate civil liability separate from the criminal exposure.
• Bank fraud statutes (18 USC § 1344 and equivalents) add another layer of federal exposure with twenty-year maximums.
• State and provincial fraud statutes add another layer below the federal.
• The card networks themselves (Visa, Mastercard, American Express, Discover) actively investigate compromise events and refer to law enforcement aggressively.

Even an authorized engagement that includes a financial institution as the client should NOT use iCopy-X for payment-card work — the right tool for that is a Proxmark3 RDV4 in a lab setting under a specific PCI-DSS-compliant engagement structure with a counsel-reviewed scope. The iCopy-X’s portable use case does not survive that structure.

3.2 Government identity documents

ICAO 9303 e-passports, driver’s licenses with embedded RFID (Real ID-compliant cards in many US states, equivalents globally), national identity cards (most countries other than the US have them; some carry RFID), Department of Defense Common Access Cards (CAC), Personal Identity Verification (PIV) cards used by US federal civilian agencies, and equivalents in other governments are OUT OF SCOPE.

The reasons:

• 18 USC § 1028 (US) applies directly, with penalty enhancements for trafficking in or producing identity documents (up to fifteen years).
• 18 USC § 1028A — Aggravated Identity Theft adds a mandatory two-year consecutive sentence to any predicate offense that involves “knowingly transfers, possesses, or uses, without lawful authority, a means of identification of another person”.
• Passport-specific statutes (18 USC §§ 1541-1546) apply additional federal offenses to passport fraud.
• State-level identity-theft statutes add another layer.
• The cryptographic protections on modern e-passports (BAC / PACE / EAC, as covered in Vol 3 §7) are designed to make casual reading hard and are designed to leave forensic traces when bypassed. The iCopy-X may technically read the basic UID layer of an e-passport, but going beyond that requires breaking cryptographic protections that the issuing government has tested specifically to detect breaches.

The right tool for authorized government-identity-document work — for example, vulnerability research on a specific protocol generation under contract to the issuing government — is a Proxmark3 RDV4 in a research lab with specific written authorization referencing the relevant statutes. This is not iCopy-X work.

3.3 Transit cards

Metropolitan transit cards (Oyster in London, Octopus in Hong Kong, OMNY in New York, Clipper in San Francisco Bay Area, Compass in Vancouver, Navigo in Paris, Opal in Sydney, Pasmo / Suica in Tokyo, and dozens of others globally) are technically within the iCopy-X’s reading capability and many are within its modification capability. Most transit cards are MIFARE Classic, MIFARE Plus, FeliCa, or CIPURSE — all card families the iCopy-X handles natively.

This is OUT OF SCOPE despite being technically straightforward.

The reasons:

• State-level theft-of-service statutes apply directly. Fares are services; obtaining them through card manipulation is theft of services with intent. Penalty schedules vary by state but are generally in the year-to-five-year range for non-trivial amounts.
• Specific transit-fraud statutes exist in many jurisdictions. New York Penal Law § 165.16 (Unauthorized Use of a Transit Pass) is one example.
• The federal Travel Act (18 USC § 1952) can apply when transit-fraud schemes cross state lines.
• The transit authorities themselves maintain forensic capabilities and active monitoring for card-balance anomalies. Most modern transit systems detect “impossible” travel patterns (e.g., a card tapping in at two stations in close succession that are physically distant) and flag them for investigation. This is not a context in which “I only modified one card” is invisible.

Authorized transit-system pentest work exists (the transit authorities themselves contract for it), but it is contractual work performed at the authority’s facilities with their specific scope and their specific tooling. Field-portable card cloning of a transit card “to see if it works” is not authorized work in any meaningful sense.

3.4 Medical devices and RFID-equipped medical records

Implanted RFID devices (VeriChip and successors, RFID-enabled prosthetics, RFID tags on implantable medical devices), hospital wristbands with patient identifiers, prescription bottle RFID tags, and medical-device tracking tags are OUT OF SCOPE.

The reasons:

• HIPAA (US) — 42 USC § 1320d et seq. applies to “protected health information” (PHI), defined broadly enough to cover patient identifiers carried on RFID tokens. Penalties include criminal exposure for “obtaining” PHI without authorization, up to ten years for the most serious cases.
• Medical-privacy statutes in most other developed jurisdictions (GDPR special-category data, UK DPA, Canada PIPEDA, Australia Privacy Act) add additional layers of administrative penalty.
• Tampering with implanted medical devices triggers separate federal statutes — 18 USC § 1365 (Tampering with Consumer Products) applies in extreme cases, with penalties up to life for harm to a person.

Authorized medical-device security research exists but is highly specialized work performed under very specific institutional and regulatory frameworks (institutional review board approval, FDA coordination, etc.). The iCopy-X’s casual physical-pentest use case does not extend into this territory.

3.5 Audited access-control systems

Some access-control systems maintain audit logs that record which card accessed which reader at what time. When the system in scope has audit logging — which is increasingly common in modern enterprise installations — the operator should EXPECT that the audit log will be reviewed during incident response, that the review will identify the cloned-card activity, and that the review will be able to correlate the activity with whatever the cloned card was used for.

For authorized engagements, the audit-log exposure is fine — it actually demonstrates the engagement’s value (the customer can see the cloned-card activity in their logs, confirming the assessment was performed and identifying which readers and times the operator tested). The SOW should explicitly address audit logs: who will know about the engagement, who will see the logs in real time, what the operator should do if security operations responds to the engagement activity as if it were a real incident.

For unauthorized work, the audit log is the operator’s eventual undoing. Audit logs are the reason that even sophisticated unauthorized access-control attacks tend to get traced after the fact even when they succeed in the moment.

3.6 Public spaces and third-party cards

Demonstration or experimentation in public spaces — coffee shops, conferences, transit stations, airports — where third-party cards may be in range of the iCopy-X antenna is OUT OF SCOPE under almost all authorization structures.

The iCopy-X’s antenna read range is short (centimeters for LF, similar or slightly more for HF), but in a crowded space “the same wallet I’m authorized to test” is hard to keep separated from “anyone else’s wallet within a meter of me”. The conservative posture is to perform iCopy-X work in controlled spaces with explicit physical separation from third-party cards — a meeting room with the door closed, an empty office, a lab bench.

3.7 The cardinal-sin summary

In one sentence: the iCopy-X is for cloning identity-token RFID/NFC cards that the operator owns or is explicitly authorized to clone, used in physical spaces under the operator’s or the customer’s control. Everything else is out of scope.

4. The pentest engagement folder

For any iCopy-X engagement other than a self-audit (the operator working on cards in their own facility), the operator should maintain a physical or encrypted-digital engagement folder containing the documentation that establishes the authorization envelope. The folder should be on the operator’s person during fieldwork. If the operator is challenged on-site, the folder is what ends the challenge.

The components of a complete engagement folder are below. Not all engagements need all of these; the structure scales by the complexity of the engagement and the sensitivity of the target. The minimum for any non-trivial engagement is the first three.

4.1 The signed Statement of Work

The SOW is the master document. It describes:

• The contracting parties. Who the pentest firm is, who the customer is, signatories on both sides with their authority to sign.
• The scope of work. What activities are authorized — specifically including “RFID badge cloning” or “physical access-control assessment” or equivalent precise language. Generic “physical security assessment” language is not enough.
• The dates. The engagement window. Cloning a card on Tuesday under an SOW that ran Monday-to-Monday last week is unauthorized cloning.
• The in-scope locations. Physical addresses, building names, floors. “All ACME Corp facilities” is acceptable for some engagements but more specific is better.
• The in-scope card formats. “All HID Prox, iCLASS Legacy, MIFARE Classic, and iCLASS SE/SEOS cards issued by the customer for facility access” is a useful baseline. Avoid open-ended “any RFID/NFC card present at the facility” language.
• The explicitly out-of-scope items. “Payment cards (including any contactless EMV payment cards present at the facility), government identity documents, personal identity cards belonging to customer employees that are not used for facility access, and transit cards are explicitly out of scope” is a useful baseline. Be explicit.
• The pricing and payment terms. Relevant for the contractual relationship but not directly for the legal envelope.
• The deliverables. What the customer gets at the end — typically a written report, sometimes a debrief presentation, sometimes the cloned cards for retention.
• The signatures. Both parties’ authorized signatories, dated, with a clear effective date.

4.2 The Authorization Letter

The Authorization Letter is the document the operator presents if challenged. It is typically shorter than the SOW (one page is normal) and contains:

• A clear identification of the customer signatory. Name, title, organization, contact information.
• A clear statement that the named pentest firm and its operators are authorized to perform the named activities. “ACME Corporation hereby authorizes <firm name> and its designated employees to perform physical security assessment, including RFID badge cloning, at <facility addresses>, during the period <date range>.”
• A contact number for the signatory. A 24/7 number that someone challenging the operator can call to verify the authorization in real time. The number should be answered by someone with authority to confirm the engagement, not a general front desk.
• The signatory’s actual signature and the date.
• Optionally, a duplicate in the local language if the engagement is in a country where English is not the dominant language. A bilingual letter is safer than a single-language one in non-English jurisdictions.

The Authorization Letter is what the operator hands to a challenger. The challenger may be a security guard, a curious employee, a police officer responding to a call. The letter establishes the operator’s bona fides quickly and professionally without exposing the broader SOW (which often contains client-confidential information the operator should not show third parties).

4.3 The Signatory Authority Documentation

The deeper question that occasionally arises during a challenge is whether the customer signatory had authority to authorize what they authorized. A CISO can typically authorize a security assessment of corporate systems; a facility VP can typically authorize physical access testing of the facilities they oversee; an IT director may or may not be able to authorize testing of physical access controls (which often fall under facilities management or physical security, not IT).

For sensitive engagements, the engagement folder should include a brief description of why the customer signatory has authority. This may be an organizational chart excerpt, a copy of the signatory’s job description, or a brief memo from corporate counsel confirming the signatory’s authority. The point is not to bury the challenger in paperwork — it is to have the answer ready if the question is asked.

4.4 The In-Scope and Out-of-Scope Inventories

For complex engagements, a separate document listing the in-scope items and the out-of-scope items by enumeration is useful. Example:

In scope:

• HID Prox cards issued by ACME Corp Facilities (format identified by 30-bit Wiegand at site code 5678)
• iCLASS Legacy cards issued by ACME Corp Facilities for executive floors
• MIFARE Classic cards used for elevator access
• iCLASS SE/SEOS cards used for data-center access (requires iCS Decoder)

Out of scope:

• Any payment cards belonging to ACME Corp employees or visitors
• Government identity cards (driver’s licenses, passports, CACs) regardless of carrier
• Personal cards belonging to employees that are not used for facility access (transit cards, gym cards, etc.)
• Cards belonging to building tenants other than ACME Corp
• Cards used at the data center if no iCS Decoder is present (no fallback “let’s try reading them anyway”)

The explicit out-of-scope list is what protects the operator from edge-case judgment calls during the engagement.

4.5 Data Handling and Retention

The captured data — UIDs, sector keys, full card dumps, derived keys — is sensitive material. The SOW or a separate Data Handling Agreement should specify:

• Where the data is stored during the engagement. The iCopy-X’s microSD (Vol 2 §7) is the primary storage; the operator should know whether secondary copies (to a laptop, to cloud storage, to a backup drive) are authorized.
• Who has access to the data. Operator only, operator’s manager, the customer, or some defined combination.
• What encryption protections apply. The microSD is not encrypted by default; the engagement should specify whether the operator must use an encrypted alternative (e.g., a LUKS-formatted USB stick connected to the iCopy-X in Expert / Proxmark mode for sensitive captures, per Vol 8 §5).
• The retention period. How long captured data is retained after the engagement closes. Typical durations are 30 days for engagement-purposes retention plus an additional period for any litigation hold.
• The destruction protocol. How and when captured data is destroyed — typically a secure wipe of the iCopy-X microSD plus deletion of any secondary copies plus a written destruction attestation to the customer.

For engagements under GDPR or equivalent data-protection regimes, this section should be formalized as a Data Processing Agreement under Article 28.

4.6 The Escape-Procedure Phone Number

If the operator is challenged on-site and the Authorization Letter does not immediately resolve the challenge — for example, if a security guard wants to detain the operator while they verify the engagement, or if a police officer is called — the operator needs to know who to call.

The escape-procedure phone number is typically:

1. Primary: The customer signatory who signed the Authorization Letter, available 24/7 during the engagement window.
2. Secondary: A senior person at the pentest firm with authority to escalate to the customer’s executive team if the primary is unreachable.
3. Tertiary: Engagement counsel — an attorney who has been briefed on the engagement and can intervene if the situation escalates.

All three numbers should be in the engagement folder, with names. The operator should NOT call the police themselves; the right move when challenged is to present the Authorization Letter, ask the challenger to call the primary number on the letter, and wait quietly for the resolution.

4.7 The Operator’s Personal Identification

Separate from the engagement folder, the operator should carry standard personal identification — driver’s license or equivalent. The Authorization Letter often does not include the operator’s full legal name (it typically authorizes “designated employees” or “the bearer of this document”); the personal ID confirms the operator’s identity to the challenger.

Note that the personal ID should be unrelated to the engagement. A passport, a driver’s license, an employee badge from the pentest firm — these are appropriate. The Authorization Letter itself is NOT identification for the operator’s person, only for their authority.

4.8 What NOT to keep in the engagement folder

A few items are commonly mistaken for engagement-folder material but should be kept separate:

• Captured card data. This goes on the iCopy-X microSD (or the encrypted secondary, per §4.5), not in the engagement folder. The folder is paperwork, not payload.
• The pentest firm’s internal procedures, playbooks, or proprietary methodology documents. These are not authorization documentation and have no value to a challenger; they only expose firm IP.
• The pentest firm’s customer list, prior engagement details, or any reference to other customers. Confidentiality between engagements requires that this material stay separated.
• Personal items unrelated to the engagement. The folder is a professional artifact; it should be intelligible to a challenger without ambiguity about what it is.

5. Authorization patterns

Different engagement structures imply different authorization documentation. The patterns below cover the main structures an iCopy-X operator is likely to encounter.

5.1 Corporate red team

The largest enterprises run their own red teams — internal security functions that test the enterprise’s defenses on a scheduled basis. Authorization flows from a corporate signatory (Chief Information Security Officer, Chief Security Officer, sometimes the Chief Financial Officer for high-stakes engagements) to the red-team manager, who then authorizes specific engagements and engagement operators.

Documentation:

• A current Red Team Charter signed by the corporate signatory, authorizing the red team’s broad mandate.
• An Engagement Plan for the specific engagement, signed by the red-team manager, identifying scope and dates.
• Per-engagement Authorization Letters issued to operators, deriving from the charter.
• All documentation is internal to the corporation; no external party is involved.

Legal exposure: minimal for the operators (they are employees acting under explicit authorization); on the corporate signatory and the red team manager for ensuring the activities stay within proper bounds.

5.2 External pentest engagement

A contracted security firm performs physical pentest for an outside client. This is the most common structure for serious iCopy-X work outside the largest enterprises.

Documentation:

• A Master Services Agreement (MSA) between the firm and the client, establishing the broad relationship.
• A Statement of Work for the specific engagement, signed by both parties, referencing the MSA.
• An Authorization Letter from the client, addressed to the firm and its designated operators, explicitly authorizing the activities.
• An internal Engagement Plan from the firm assigning specific operators to the engagement.
• A Data Processing Agreement (under GDPR-equivalent regimes) covering the handling of captured data.

Legal exposure: shared between the firm and the operator. The firm carries exposure under data-protection statutes and for any breaches of the MSA / SOW; the operator carries exposure under computer-crime statutes for any actions outside the authorized scope.

5.3 Facility-owner self-audit

The owner of a facility tests their own access control. This is the cleanest legal posture available — the operator is the owner; authorization is self-granted.

Documentation:

• Evidence of facility ownership (deed, lease specifying the operator’s authority, equivalent).
• An internal self-audit plan documenting the scope and methodology (useful for insurance and compliance purposes even when not legally required).
• A retention policy for any captured data (the owner can do anything with their own data, but professionalism suggests treating it formally).

Legal exposure: essentially zero on the access-control statutes (the operator IS the authorizing party); minor exposure on data-protection statutes if employees’ card data is collected (the employee identifiers are still personal data under GDPR-equivalent regimes).

5.4 Bug bounty / responsible disclosure

Bug bounty programs typically authorize testing of named software systems and explicitly do NOT authorize physical access testing. Check the specific program scope before any physical engagement.

Some specialized “physical security bug bounty” programs exist (typically run by large tech companies for their own facilities) and may authorize iCopy-X-class activity within a narrow scope. These are unusual.

Documentation:

• The published program scope, downloaded and dated.
• Any specific authorization obtained from the program operators for activities not clearly within the published scope (typically required).
• The standard engagement-folder structure for the activities performed.

Legal exposure: high if the operator misjudges scope. Bug bounty programs are NOT a substitute for explicit per-engagement authorization for unusual activities.

5.5 Research and academic

Academic security research — a graduate student or research scientist studying RFID security at a university — has its own authorization framework, typically involving:

• Institutional Review Board (IRB) approval for any research that touches human subjects (which most security research touches).
• Faculty advisor sign-off on the research methodology.
• Coordination with the university’s general counsel for research touching on sensitive jurisdictions.
• For research on third-party systems: prior coordination with the system owner OR fully synthetic test environments.

Legal exposure: variable. Academic research enjoys some protections under federal and state law (the “academic research” affirmative defense exists in CFAA case law) but the protections are narrow and depend on adherence to the standards above.

5.6 Personal / hobbyist

The operator working on cards they personally own — their own apartment-building fob, their own gym card, their own employer-issued badge with the employer’s permission. This is the “ownership” prong of the baseline rule and is the cleanest legal posture available for individual hobbyists.

Documentation:

• For personally-owned cards (apartment fob, gym card if the operator owns it): typically no documentation needed; ownership establishes authorization.
• For employer-issued badges: explicit written permission from the employer is required. Without it, the badge is the employer’s property and cloning it is unauthorized regardless of the operator’s status as a badge-holder.
• For roommate’s / family member’s cards: written permission is required from the person whose name is on the card.

Legal exposure: minimal for genuinely owned cards; ordinary computer-crime exposure for cards belonging to others without explicit permission.

6. Things this series will not help with

This volume is explicit about what is in scope and what is not. A few additional categories are worth calling out because they recur in operator questions:

• Anything not covered by the authorization. If the SOW does not explicitly authorize cloning a particular card type or a particular activity, the operator should not perform it. “It’s similar to what’s authorized” is not authorization. “The customer would obviously agree” is not authorization. “The customer’s IT person verbally told me on the phone” is not authorization. Written, signed, specific is the standard.
• Operating without authorization documentation. Even if the operator believes the authorization is real, lack of documentation means lack of affirmative defense. Get the paper.
• Operating in jurisdictions where the operator has not checked the legal envelope. A US-based pentest firm running an engagement in the EU should have specific EU counsel review the engagement structure. The differences are real and material.
• “Public” demonstrations where third-party cards might be in range. Conference demonstrations, podcast recordings, tradeshow booths — keep these in fully controlled environments with verified card stock, not in public spaces where unknown third-party RFID-bearing items are present.
• “Just to see if it works” experiments. The iCopy-X is a professional tool; treat it as one. Experimentation with unknown cards in unknown contexts is the activity profile that creates incidents.
• Helping someone “just for a friend”. If the friend has a legitimate need, the friend can produce documentation. If they cannot, the operator should not.
• Providing the iCopy-X to someone without documentation training. The tool’s button-simple operation is its strength and its risk; an operator who hands their iCopy-X to an inexperienced user has transferred their legal exposure without transferring their understanding of the envelope.

7. The laminate-ready cheatsheet

The following sections are designed to be printed on durable card stock or laminated, folded, and carried in the engagement folder or in the iCopy-X case. Each table is one of the load-bearing field references.

7.1 Mode-to-key quick map

The four buttons on the iCopy-X keypad are typically labeled UP, DOWN, OK (or ENTER), and ESC (or BACK). Exact silkscreen labels vary by firmware revision; see Vol 2 §4 for the photo reference.

Action	Button sequence	Notes
Power on	Hold OK 2 seconds	LCD comes up to the splash screen, then boot menu
Auto Clone (LF or HF)	Main menu → UP/DOWN to “Auto Clone” → OK	Default mode; works for the supermajority of routine clones
Read LF	Main menu → “Read LF” → OK	Scans LF tag families, displays decoded data, does NOT write
Read HF	Main menu → “Read HF” → OK	Scans HF tag families, displays decoded data, does NOT write
Sniff (MIFARE keys)	Main menu → “Sniff” → OK	Wait for reader+card to transact, capture frames, recover keys
Emulate LF	Main menu → “Emulate” → “LF” → OK	Emulates a previously-read LF card; iCopy-X acts as the card
Emulate HF	Main menu → “Emulate” → “HF” → OK	Emulates a previously-read HF card
Expert / PM3 Mode	Main menu → “Expert” → OK → confirm	USB connects iCopy-X to laptop as a Proxmark3 device; raw access
Settings	Main menu → “Settings” → OK	Brightness, language, microSD info, firmware version
Power off	Hold ESC 2 seconds	Saves state, powers down
Soft reset	Hold OK + ESC for 5 seconds	If UI is stuck
Hard reset	Hold all four buttons 10 seconds	If soft reset fails; preserves microSD data

7.2 Tag-family quick map

Card technology	Frequency	Recommended mode	Time budget	Output	Recommended blank
HID Prox (26-bit / 34-bit / 35-bit / 37-bit Wiegand)	125 kHz LF	Auto Clone	5-10 s	T5577 cloned	T5577
HID Prox II (corporate format)	125 kHz LF	Auto Clone	5-10 s	T5577 cloned	T5577
Indala 26-bit	125 kHz LF	Auto Clone	5-10 s	T5577 cloned	T5577
AWID 26-bit	125 kHz LF	Auto Clone	5-10 s	T5577 cloned	T5577
ioProx	125 kHz LF	Auto Clone	5-10 s	T5577 cloned	T5577
EM4100 / EM4102	125 kHz LF	Auto Clone	5-10 s	T5577 or EM4305 cloned	T5577
Viking	125 kHz LF	Auto Clone	5-10 s	T5577 cloned	T5577
HITAG2 (most variants)	125 kHz LF	Auto Clone	10-30 s	T5577 cloned (partial support)	T5577 or HITAG2 if available
MIFARE Classic 1K (default keys)	13.56 MHz HF	Auto Clone	5-15 s	Magic Gen2 cloned	Magic Gen2
MIFARE Classic 1K (unknown keys)	13.56 MHz HF	Sniff → wait for transaction → recover → Auto Clone	1-15 min	Magic Gen2 cloned	Magic Gen2
MIFARE Classic 4K	13.56 MHz HF	Auto Clone or Sniff first	5-30 min	Magic Gen2 4K cloned	Magic Gen2 4K
MIFARE Ultralight	13.56 MHz HF	Auto Clone	5-10 s	Magic Ultralight cloned	Magic Ultralight
MIFARE Plus	13.56 MHz HF	Auto Clone (SL1 mode); else Sniff	10 s - 30 min	Magic Plus cloned	Magic Plus
MIFARE DESFire	13.56 MHz HF	Read only (no clone available without keys)	N/A	Diagnostic only	N/A
NTAG21x	13.56 MHz HF	Auto Clone	5-10 s	NTAG21x writable cloned	NTAG21x or Ultralight clone
iCLASS Legacy	13.56 MHz HF	Auto Clone	10-20 s	iCLASS Legacy clone	iCLASS Legacy blank
iCLASS Elite	13.56 MHz HF	Auto Clone (Elite KDF in firmware)	10-30 s	iCLASS Elite clone	iCLASS-compatible blank
iCLASS SE	13.56 MHz HF	Auto Clone + iCS Decoder required	30 s - 2 min	iCLASS SE clone	iCLASS SE blank
iCLASS SEOS	13.56 MHz HF	Auto Clone + iCS Decoder required	30 s - 2 min	iCLASS SEOS clone	iCLASS SEOS blank
ISO 15693 iCODE SLIX	13.56 MHz HF	Read; Auto Clone partial	5-15 s	Magic 15693 cloned (where available)	Magic 15693
Legic Prime	13.56 MHz HF	Read partial; clone partial	30 s	Diagnostic / partial clone	Legic blank if supported
Legic Advant	13.56 MHz HF	Read only	N/A	Diagnostic only	N/A
FeliCa	13.56 MHz HF	Read partial	N/A	Diagnostic only	N/A
EMV contactless	13.56 MHz HF	OUT OF SCOPE — do not attempt	N/A	N/A	N/A
ICAO 9303 passport	13.56 MHz HF	OUT OF SCOPE — do not attempt	N/A	N/A	N/A

7.3 Blank-card decision tree

If the source card is…	Use this blank	Why
HID Prox / Indala / AWID / EM4XXX / Viking	T5577	Universal LF blank; emulates the relevant LF formats
HID Prox specifically and you want format-correct emulation	EM4305 or T5577	T5577 works for HID; EM4305 is the strict-EM4XXX alternative
HITAG2	HITAG2 native blank if available, else T5577 (partial)	HITAG2 emulation on T5577 has edge cases
MIFARE Classic 1K	Magic Gen2 1K	Gen2 allows direct sector-0 write including UID; safer than Gen1a
MIFARE Classic 4K	Magic Gen2 4K	Same logic at 4K capacity
MIFARE Classic with unusual sector locking	Magic Gen3	Gen3 has more flexible block-0 control; uncommon need
MIFARE Ultralight / NTAG	Magic Ultralight writable	Standard writable Ultralight; commodity stock
iCLASS Legacy	iCLASS Legacy blank from Lab401 “Genuine” or compatible	Format-specific; avoid generic alternatives
iCLASS Elite	iCLASS Legacy blank with Elite KDF support	Verify the blank stock supports Elite KDF writes
iCLASS SE	iCLASS SE blank (requires iCS Decoder for write)	Format-specific; bind to iCS Decoder workflow
iCLASS SEOS	iCLASS SEOS blank (requires iCS Decoder for write)	Format-specific; bind to iCS Decoder workflow
Anything else	Confirm in Vol 9	The blank-card volume is the authority

7.4 Key-recovery time budget

Attack	Used against	Typical time	Notes
Darkside	MIFARE Classic (vulnerable variants)	10-60 s	Card-only attack; no reader needed
Nested	MIFARE Classic (most variants)	30 s - 5 min	Requires ONE known key (often a default key) to derive others
HardNested	MIFARE Classic hardened (some EV1)	5-30 min	Modern variant of nested; slower; works on hardened
Dictionary attack	MIFARE Classic with default keys	5-30 s	Tests common keys against the card; first thing to try
Sniff (key recovery from reader)	MIFARE Classic any	Minutes-hours (depends on transactions)	Captures actual reader-card auth; offline analysis recovers keys
iCLASS Legacy default-key crack	iCLASS Legacy	5-10 s	Fixed-key attack; iCLASS Legacy uses well-known defaults
iCLASS Elite KDF	iCLASS Elite	30 s - 2 min	Custom keys derived from Elite KDF; firmware handles automatically
iCLASS SE / SEOS	iCLASS SE / SEOS	Requires iCS Decoder	Closed; not user-configurable

7.5 Troubleshooting flow — Auto Clone failed, now what?

Auto Clone failed
    │
    ├─ Did the read succeed but write failed?
    │       │
    │       ├─ Wrong blank card type? → Check §7.3 blank-card decision tree
    │       ├─ Blank card already written / locked? → Try fresh blank
    │       ├─ Blank card from non-trusted source? → Try Lab401 "Genuine" stock
    │       └─ All blanks failing? → Suspect HF coil issue → see Vol 2 §5
    │
    ├─ Did the read fail entirely?
    │       │
    │       ├─ Card sitting on antenna? → Reseat directly over coil center
    │       ├─ Wrong card-family expected? → Try Read LF / Read HF manually
    │       ├─ Card cryptographically locked? → See "keys unknown" branch below
    │       └─ Battery low? → Check battery; LF/HF coil power suffers at low V
    │
    ├─ Did Auto Clone identify the card but say "keys unknown"?
    │       │
    │       ├─ Source card is MIFARE Classic with non-default keys
    │       │       → Switch to Sniff mode, wait for a transaction with the real reader
    │       │       → After transaction captured, recover keys (Vol 7 §4)
    │       │       → Then return to Auto Clone with the recovered keys
    │       │
    │       ├─ Source card is iCLASS SE/SEOS
    │       │       → iCS Decoder accessory required (Vol 6 §5)
    │       │       → Without it, the card reads as encrypted nonsense
    │       │
    │       └─ Source card is MIFARE DESFire / Plus SL3 / FeliCa secure
    │               → Authorized engagement workflow only; not a routine Auto Clone target
    │               → Escalate to Proxmark3 RDV4 + scripted attack (Vol 11)
    │
    └─ Did Auto Clone work but the cloned card doesn't work at the reader?
            │
            ├─ Cloned-card sector data correct but card-format-mismatch?
            │       → Check that the blank chosen matches the source format exactly (§7.3)
            │
            ├─ UID required by the reader, blank's UID not writable?
            │       → MIFARE Gen2 / Gen3 blank required (not Gen1a; not generic)
            │
            ├─ Reader has additional anti-clone (rolling counter, time-based)?
            │       → Reader-side anti-clone defenses; not all clones are emulatable
            │       → Document the failure for the engagement report
            │
            └─ Cloned card works intermittently?
                    → Blank-card power-budget issue at the reader; try fresh blank
                    → Or reader sensitivity issue at this specific reader
                    → Try another reader of the same type to isolate

7.6 Pre-engagement checklist

Before stepping onsite for an engagement, the operator should verify:

Item	Verified?
Engagement folder — SOW signed, Authorization Letter signed, dates current	□
Personal identification — government-issued, separate from engagement materials	□
iCopy-X battery — full charge, last charged within 24 hours	□
microSD card — installed, sufficient free space, no leftover data from prior engagements	□
USB-C cable — included in kit for charging and Expert mode if needed	□
Blank-card inventory — sufficient quantity for engagement scope	□
— T5577 blanks (LF universal)	□
— Magic Gen2 1K blanks (HF MIFARE Classic)	□
— Magic Gen2 4K blanks (HF MIFARE Classic 4K)	□
— Magic Ultralight blanks (HF Ultralight / NTAG)	□
— iCLASS Legacy blanks (if engagement scope includes iCLASS)	□
— iCLASS SE/SEOS blanks (if engagement scope includes SE/SEOS)	□
iCS Decoder (if engagement scope includes iCLASS SE/SEOS)	□
Firmware version — current per Lab401 release notes; updated within 30 days	□
Escape-procedure phone numbers — primary, secondary, tertiary all verified working	□
Customer contact for engagement — primary signatory reachable 24/7 during window	□
Backup operator — if engagement is high-stakes, second operator briefed and on standby	□
Engagement plan — onsite arrival time, scope of physical movement, exit protocol	□

7.7 Post-engagement checklist

After completing fieldwork and returning to controlled space, the operator should verify:

Item	Completed?
Captured card data — secured per engagement Data Handling Agreement	□
microSD card — contents reviewed, sensitive captures encrypted or migrated to secured store	□
iCopy-X — soft-reset to clear current state; no captured data left in scratch buffers	□
Spent blank cards — accounted for; any failed clones disposed of or returned per engagement terms	□
Unused blank inventory — counted, restocked for next engagement	□
Engagement folder — preserved per retention policy (typically 30 days minimum, longer per legal hold)	□
Engagement report draft — started while context is fresh; cards encountered, attacks attempted, outcomes documented	□
Audit-log notification — customer notified that engagement activity will appear in their access-control logs at expected timestamps	□
Data destruction protocol — scheduled per Data Handling Agreement (typically T+30 days)	□
Lessons-learned note — any technique improvements, blank-card stock issues, firmware quirks documented for future engagements	□
Equipment condition — iCopy-X case checked for damage; battery condition noted	□
Customer debrief — scheduled per SOW deliverables	□

8. A-Z glossary

The terms below are the load-bearing technical vocabulary across the iCopy-X series. The glossary is intended as a quick lookup; the cross-references point at the volume sections where each term is treated in depth.

AID (Application IDentifier) — A short identifier (typically 16-32 bits) used by MIFARE DESFire and HID iCLASS SE/SEOS to identify which application’s data is being requested on a multi-application card. Cards may host multiple AIDs; selecting the correct one is a prerequisite for cryptographic authentication. See Vol 6 §3 (SEOS) and Vol 5 §6 (DESFire).

Air interface — The physical-layer radio interface between a card and a reader. The major air interfaces relevant to iCopy-X are ISO 14443A/B (proximity HF), ISO 15693 (vicinity HF), and the various proprietary LF formats. See Vol 3.

Allwinner H3 — The application processor SoC at the heart of the NanoPi NEO module in the iCopy-X. Quad-core ARM Cortex-A7 at 1.2 GHz, well-supported by mainline Linux. See Vol 2 §3.

ATM91SAM7S512 — see AT91SAM7S512.

AT91SAM7S512 — The ARM7TDMI MCU at the Proxmark3 silicon layer of the iCopy-X (and the canonical Proxmark3 RDV4). Handles the RFID protocol state machines on top of the FPGA’s RF modem. The “S512” suffix denotes 512 KB of flash. See Vol 2 §4.

Auto Clone — The headline iCopy-X operating mode. A single button sequence that scans whatever card is held against the antenna, identifies the technology, decodes the relevant identity bits, and writes those bits to an appropriate blank card held against the same antenna. Works for the supermajority of routine cloning tasks. See Vol 7 §3.

AWID — One of the historical 125 kHz LF access-control formats. Similar overall structure to HID Prox 26-bit; uses different bit-encoding. T5577 emulates AWID natively. See Vol 4 §5.

BAC (Basic Access Control) — The first-generation cryptographic protection on ICAO 9303 e-passports. Uses keys derived from the passport’s machine-readable zone (MRZ). Out of scope for iCopy-X work; reading e-passports beyond the basic UID layer is illegal in most jurisdictions and out of scope per §3.2.

Block 0 — In MIFARE Classic, the first block of sector 0. Contains the card’s UID (4 bytes for original cards, 7 bytes for newer variants) plus manufacturer-specific data. Normal MIFARE Classic cards have a read-only block 0; “Magic” clones (Gen1a, Gen2, Gen3) allow block 0 to be rewritten. See Vol 5 §3.

CFAA (Computer Fraud and Abuse Act) — 18 USC § 1030, the United States federal computer-crime statute. The primary federal statute applicable to unauthorized RFID/NFC work. See §2.1.

Coil (LF / HF) — The two air-loop antennas on the iCopy-X’s lower face. The LF coil is a multi-turn flat coil tuned for 125 kHz; the HF coil is a smaller loop tuned for 13.56 MHz. Both connect through their respective matching networks to the analog front end. See Vol 2 §5 and Antennas Vol 14.

Crypto1 — The proprietary stream cipher used to authenticate and encrypt MIFARE Classic transactions. Broken in 2008 (Garcia et al., “Wirelessly Pickpocketing a MIFARE Classic Card”). The breakage is the foundation of darkside, nested, and hardnested key-recovery attacks. See Vol 5 §4.

Darkside attack — A MIFARE Classic key-recovery attack discovered in 2008 by Courtois that exploits the Crypto1 authentication protocol’s nonce-leakage behaviour to extract a single key from a card with no prior key knowledge. Typically 10-60 seconds. The iCopy-X implements darkside in firmware. See Vol 5 §5.

DESFire — NXP’s modern HF card family (technically MIFARE DESFire). AES-secured, supports multiple applications via AIDs. The cryptographic security is genuinely strong; the iCopy-X can read DESFire metadata but cannot clone an active DESFire card without the application keys. See Vol 5 §6.

Dictionary attack — Trying a list of common default keys against a card’s sectors. Often the fastest first step for MIFARE Classic key recovery — many cards in the field still use the factory default keys. See Vol 5 §5.

Elite KDF (Key Derivation Function) — HID’s per-customer key derivation function for iCLASS Elite cards. Derives a unique master key for each customer from a customer-specific input. The iCopy-X has Elite KDF support in firmware and handles Elite cards automatically when the customer’s identifier is known or recoverable. See Vol 6 §2.

EM4100 / EM4102 — The canonical low-end LF card family, originally from EM Microelectronic. 64-bit UID-only cards; read-only; the basis for many cheap access-control systems. Trivially cloneable to T5577. See Vol 4 §3.

EM4305 — A user-writable LF tag from EM Microelectronic. Often used as a strict-EM4XXX alternative blank when T5577 is not appropriate. See Vol 4 §3.

EMV (Europay/Mastercard/Visa) — The contactless payment-card standard. ISO 14443-based; uses dynamic data authentication and per-transaction cryptography to make replay difficult. Explicitly OUT OF SCOPE for iCopy-X work per §3.1.

Expert Mode (Proxmark Mode) — The iCopy-X operating mode that exposes the underlying Proxmark3 silicon to a host laptop via USB-C. Effectively turns the iCopy-X into a portable Proxmark3, enabling the full Proxmark3 client SDK. The escape hatch for situations the standalone modes cannot handle. See Vol 8 §5.

FeliCa — Sony’s proprietary HF card technology, dominant in Japan and parts of Asia. Different air interface from ISO 14443A/B; partial support in the iCopy-X (read diagnostics, limited write). See Vol 6 §6.

FIDO / U2F / WebAuthn — Cryptographic authentication standards using physical security tokens (YubiKeys, etc.) over NFC. Out of scope for iCopy-X cloning work; the security model specifically resists cloning by design (private keys never leave the token).

FPGA (Field-Programmable Gate Array) — A reconfigurable digital chip whose logic is defined by a bitstream loaded at boot. The iCopy-X uses a Xilinx Spartan-3 XC3S100E FPGA as the RFID modem — handling carrier modulation/demodulation, framing, and timing at speeds the MCU could not match in software. See Vol 2 §4.

FUID (Fudan UID-writable) — Magic-card variants manufactured by Fudan Microelectronics (a Chinese semiconductor company). FUID Gen1a, FUID Gen2, etc. are the MIFARE Classic compatible Chinese clones. Note that Fudan also makes legitimate (non-magic) MIFARE Classic compatibles; “FUID” colloquially refers to the magic variants. See Vol 9 §3.

Gen1a (Magic Gen1a) — The earliest generation of UID-writable MIFARE Classic clones. Uses backdoor command sequence (the “Chinese magic backdoor” 0x40-0x43 commands) to access block 0. Vulnerable to detection by readers that probe for backdoor commands. See Vol 9 §3.

Gen2 (Magic Gen2) — The second generation of UID-writable MIFARE Classic clones. Uses the standard authenticate-then-write protocol for block 0 (with the default block-0 key). More compatible than Gen1a; detection by anti-clone-aware readers is harder. The recommended default blank for MIFARE Classic cloning. See Vol 9 §3.

Gen3 (Magic Gen3) — The third generation of UID-writable MIFARE Classic clones. Adds more flexible block-0 access controls and additional backdoor functionality. Niche; the iCopy-X handles Gen3 automatically when needed. See Vol 9 §3.

GDPR (General Data Protection Regulation) — Regulation (EU) 2016/679. The EU’s data-protection regulation. Applies to processing of personal data of EU residents, including identifier data on RFID cards. See §2.3.

HardNested attack — A MIFARE Classic key-recovery attack designed for “hardened” Classic variants (some MIFARE Classic EV1 cards) where the Crypto1 nonce randomness has been improved enough to defeat the original nested attack. Slower than nested (5-30 minutes typical); the iCopy-X implements hardnested in firmware. See Vol 5 §5.

HID Global — One of the dominant access-control vendors. The owner of the HID Prox, iCLASS Legacy, iCLASS Elite, iCLASS SE, and iCLASS SEOS card family. iCopy-X has comprehensive support for all HID formats; SE/SEOS requires the iCS Decoder. See Vol 4 §4 (Prox) and Vol 6 (iCLASS family).

HID Prox — The dominant 125 kHz LF access-control format in the United States, manufactured by HID Global. Variants include 26-bit (H10301), 34-bit, 35-bit (Corporate 1000), 37-bit, and HID Prox II formats. T5577 emulates all of them. See Vol 4 §4.

HITAG2 — A 125 kHz LF card family from NXP, used in automotive immobilizers and some access-control systems. Uses a 48-bit key and a non-trivial authentication protocol. Vulnerable to known cryptographic attacks (Verdult et al. 2012). Partial iCopy-X support. See Vol 4 §6.

iCLASS Legacy — HID Global’s first-generation HF card (also called “Standard Security” iCLASS). Uses fixed master keys that have been publicly published since 2012 (Garcia et al., “Dismantling iClass and iClass Elite”). The iCopy-X clones iCLASS Legacy natively in Auto Clone. See Vol 6 §2.

iCLASS Elite — HID Global’s “Elite” iCLASS variant. Uses customer-derived keys via the Elite KDF. Still cryptographically vulnerable (the KDF design is reverse-engineered). iCopy-X handles Elite via the firmware’s Elite KDF implementation. See Vol 6 §2.

iCLASS SE — HID Global’s third-generation iCLASS, introducing the Secure Identity Object (SIO) cryptographic container around the legacy card data. Requires the iCopy-X plus the iCS Decoder accessory. See Vol 6 §3.

iCLASS SEOS — HID Global’s fourth-generation iCLASS, introducing the Seos cryptographic identity protocol. Requires the iCopy-X plus the iCS Decoder accessory. See Vol 6 §4.

iCS Decoder (iCS Decoder Tool) — The iCopy-X accessory that adds iCLASS SE and iCLASS SEOS decoder capability. Sold separately by Lab401 at approximately $488 USD (€200 at recent EUR rates) as of mid-2026. NOT a firmware unlock — a separate physical USB-C accessory device. License-bound to the iCopy-X serial number. See Vol 6 §5.

Indala — One of the historical 125 kHz LF access-control formats, originally from Indala Corporation (acquired by Motorola). Similar overall structure to HID Prox 26-bit. T5577 emulates Indala. See Vol 4 §5.

ioProx — A 125 kHz LF access-control format from Kantech (acquired by Tyco / now Johnson Controls). Used primarily in Canadian and Eastern US installations. T5577 emulates ioProx. See Vol 4 §5.

ISO 14443A — The dominant HF air-interface standard for proximity-coupled smart cards. Uses 13.56 MHz; defines anticollision, framing, and the higher-layer protocol foundation. The basis for MIFARE Classic, MIFARE Plus, MIFARE Ultralight, NTAG, iCLASS, NFC Forum Type 1/2/4 tags, and many others. See Vol 3 §4.

ISO 14443B — A variant of the ISO 14443 air interface using a different anticollision scheme. Used by some government identity systems and a handful of access-control vendors. iCopy-X supports ISO 14443B. See Vol 3 §4.

ISO 15693 — The vicinity-card HF air-interface standard, also at 13.56 MHz but with longer effective read range (decimeters rather than centimeters) and a different protocol. Used by iCLASS and various inventory / library / asset-tracking systems. iCopy-X supports ISO 15693. See Vol 3 §5.

KDF (Key Derivation Function) — A cryptographic function that derives a specific key from a master key plus an input. Used by HID iCLASS Elite, iCLASS SE/SEOS, and many other modern card systems. See Vol 6.

Legic — A Swiss-developed HF card technology, with Prime and Advant variants. Used primarily in European installations. iCopy-X has partial Legic Prime support, no Legic Advant support. See Vol 6 §6.

LF (Low Frequency) — The 125 kHz frequency band used by HID Prox, EM4100, Indala, AWID, ioProx, HITAG2, and many other legacy access-control card formats. iCopy-X has a dedicated LF coil and front end. See Vol 3 §2 and Vol 4.

Magic card — Collective term for UID-writable MIFARE Classic clones. Gen1a, Gen2, Gen3 are the canonical variants. Sometimes called “Chinese magic cards” or “FUID cards” (after Fudan, one of the manufacturers). See Vol 9 §3.

Matching network — The L-C network between an antenna coil and the driving electronics that brings the coil’s impedance to match the driver’s expected source impedance (typically 50 Ω). Critical to power transfer efficiency in RFID. See Antennas Vol 16.

MIFARE Classic — NXP’s first-generation HF card family. 1K, 4K, and Mini variants. Uses Crypto1 (broken). The most common access-control HF card by installed base. iCopy-X clones natively in Auto Clone. See Vol 5 §3.

MIFARE Plus — NXP’s third-generation MIFARE family. Multiple security levels (SL1, SL2, SL3); SL1 is Classic-compatible (still uses Crypto1), SL3 uses AES. iCopy-X handles SL1 natively. See Vol 5 §7.

MIFARE Ultralight — NXP’s simpler HF card family. UID + small EEPROM, no Crypto1, intended for low-value applications. Several variants (Ultralight C, Ultralight EV1, NTAG). iCopy-X clones natively. See Vol 5 §8.

MRZ (Machine-Readable Zone) — The two- or three-line OCR-formatted text at the bottom of an ICAO 9303 passport’s identity page. The MRZ contains the keys used to derive BAC keys. Out of scope for iCopy-X work.

NanoPi NEO — The FriendlyARM-manufactured small single-board computer that serves as the iCopy-X’s application processor. Allwinner H3 quad-core ARM Cortex-A7 at 1.2 GHz, 256 MB RAM, runs OpenWrt. See Vol 2 §3.

Nested attack — A MIFARE Classic key-recovery attack that uses a single known key (typically a default key recovered via dictionary attack) to derive the keys of other sectors on the same card. Typically 30 seconds to 5 minutes. iCopy-X implements nested in firmware. See Vol 5 §5.

NFC (Near Field Communication) — The branding and standards consortium that wraps ISO 14443A and ISO 18092 for consumer applications. NFC Forum Type 1-5 tags are subsets of the underlying ISO standards. See Vol 3 §6.

NTAG — NXP’s NFC Forum Type 2 tag family, sometimes called “NTAG21x” after the common models (NTAG213, NTAG215, NTAG216). User-writable EEPROM, anti-clone counter, optional password protection. Common consumer NFC tag. See Vol 5 §8.

OpenWrt — The open-source Linux distribution focused on embedded devices, originally for residential routers. The iCopy-X uses OpenWrt as its base Linux distribution on the NanoPi NEO. See Vol 10 §2.

PACE (Password Authenticated Connection Establishment) — The second-generation cryptographic protection on ICAO 9303 e-passports, replacing BAC. Out of scope for iCopy-X work per §3.2.

PM3 / Proxmark3 — The open-source RFID research platform. Hardware: AT91SAM7S512 ARM7TDMI + Xilinx Spartan-3 XC3S100E FPGA. Same silicon as the iCopy-X’s RFID brain. Multiple hardware revisions (Easy, RDV2, RDV3, RDV4); RDV4 is the canonical current revision. See Proxmark3 RDV4 and Vol 11.

Proxmark3 RDV4 — The current canonical revision of the Proxmark3 hardware (RDV4 = Research and Development Version 4). The lab sibling to the iCopy-X — same silicon, end-to-end open-source, full client SDK on a laptop. See Vol 11 for the comparison.

RFID (Radio-Frequency IDentification) — The umbrella term for the various wireless identification technologies covered in the iCopy-X series. Subdivides into LF (125 kHz), HF (13.56 MHz), and UHF (860-960 MHz); iCopy-X covers LF and HF, not UHF. See Vol 3.

SAM (Secure Application Module) — A cryptographic accessory used by some HID readers to securely hold the master keys needed to authenticate iCLASS Elite, SE, and SEOS cards. Reader-side, not card-side; relevant to the iCopy-X discussion in that SAM-equipped readers can use card-specific keys the cardholder does not have. See Vol 6 §3.

Sector trailer — In MIFARE Classic, the last block of each sector. Contains Key A (6 bytes) + access bits (4 bytes) + Key B (6 bytes). The keys protect the sector’s data; the access bits control which operations are allowed with which key. See Vol 5 §3.

SEOS — see iCLASS SEOS.

Sniff mode — The iCopy-X operating mode that captures the wireless transaction between a real reader and a real card for offline analysis. Used primarily to recover MIFARE Classic keys when the card’s keys are not known and an authentic reader-card transaction can be observed. See Vol 7 §4.

Spartan-3 (Xilinx) — The Xilinx FPGA family used in the Proxmark3 lineage. The iCopy-X uses the XC3S100E variant — 100K equivalent system gates, suitable for the Proxmark3 RFID modem workload. See Vol 2 §4.

SOW (Statement of Work) — The master contractual document describing the scope, parties, dates, and deliverables of a pentest engagement. The foundation of the engagement folder. See §4.1.

STM32 (STM32F103) — A separate ARM Cortex-M3 MCU on the iCopy-X main PCB, handling housekeeping tasks (LCD interface, keypad scanning, power management, USB-C interface) and protocol-layer logic that sits on top of the FPGA-managed RF. Note: the Proxmark3 silicon in the iCopy-X is an AT91SAM7S512, NOT the STM32 — the STM32 is a separate co-processor for non-RFID housekeeping. See Vol 2 §4.

T5577 — Atmel / Microchip’s universal LF programmable blank card. User-writable, configurable to emulate EM4100, HID Prox, Indala, AWID, ioProx, Viking, and many other LF formats. The default LF blank for iCopy-X work. See Vol 4 §3 and Vol 9 §2.

UID (Unique IDentifier) — The card-level identifier present on essentially every RFID/NFC card. 4 bytes for original MIFARE Classic; 7 bytes for newer Classic and most modern cards; 8 bytes for HID iCLASS. The first piece of data read off any card. See Vol 3 §3.

VICC (Vicinity Integrated Circuit Card) — The ISO 15693 term for a card following the vicinity-card air-interface standard. See Vol 3 §5.

Viking — A historical 125 kHz LF access-control format, less common than HID Prox or EM4100 but still present in some legacy installations. T5577 emulates Viking. See Vol 4 §5.

Wiegand — A binary card-data encoding format originally used by Wiegand-effect access-control cards (a magnetic technology, not RFID) and now used as a card-data-on-the-wire format for many RFID systems including HID Prox. “26-bit Wiegand” describes the standard 26-bit format: 8-bit site code + 16-bit card number + 2 parity bits. See Vol 4 §4.

Xilinx — The FPGA manufacturer (now part of AMD) whose Spartan-3 XC3S100E is the iCopy-X’s RFID modem. See Vol 2 §4.

9. Resources and further reading

9.1 Project-internal cross-references

• Vol 1 — Overview, decision graph, how to read this series
• Vol 2 — Hardware tour
• Vol 3 — RFID / NFC primer
• Vol 4 — LF tag families
• Vol 5 — HF tag families Part 1 (MIFARE family)
• Vol 6 — HF tag families Part 2 (iCLASS family, FeliCa, Legic, iCS Decoder)
• Vol 7 — Operating modes Part 1 (Auto Clone, Scan, Read, Sniff)
• Vol 8 — Operating modes Part 2 (Emulation, Expert / Proxmark Mode)
• Vol 9 — Card-stock ecosystem (T5577, Magic, iCLASS / SEOS blanks)
• Vol 10 — Firmware update workflow and open-source upstream
• Vol 11 — Side-by-side comparisons (vs Proxmark3 RDV4, Flipper Zero, cheap duplicators, ChameleonMini)

9.2 Hack Tools hub cross-references

• ../_shared/legal_ethics.md — the canonical project-level baseline. The §1 statement of this volume restates the same rule in iCopy-X-specific terms.
• ../_shared/comparison.md — cross-tool decision matrix in prose form across the full Hack Tools lineup.
• ../_shared/capability_matrix.html — interactive sortable capability matrix across all tools.
• ../Proxmark3 RDV4/CLAUDE.md — the lab sibling. Same silicon, different posture.
• ../Flipper Zero/CLAUDE.md — the multi-tool sibling.
• ../Hacker Tradecraft/ — the cross-cutting tradecraft deep dive. See especially:
  • Vol 15 — RFID / NFC / Access Control tradecraft
  • Vol 19 — Legal & Ethics — the broader treatment of the legal envelope that this volume’s §1-§6 restates in iCopy-X-specific form.
• ../Antennas/ — the antenna deep dive. Relevant volumes for iCopy-X work:
  • Vol 14 — Transmit loops — the LF/HF coil physics underlying the iCopy-X antenna PCB.
  • Vol 16 — BALUNs and matching networks — the matching-network theory underlying the iCopy-X front end.

9.3 Statutory text (primary sources)

• 18 USC § 1030 (CFAA): https://www.law.cornell.edu/uscode/text/18/1030
• 18 USC § 1028 (Identity Document Fraud): https://www.law.cornell.edu/uscode/text/18/1028
• 18 USC § 1028A (Aggravated Identity Theft): https://www.law.cornell.edu/uscode/text/18/1028A
• 18 USC § 1029 (Access Device Fraud): https://www.law.cornell.edu/uscode/text/18/1029
• 47 USC § 605 (Unauthorized Reception of Communications): https://www.law.cornell.edu/uscode/text/47/605
• HIPAA (42 USC § 1320d et seq.): https://www.law.cornell.edu/uscode/text/42/1320d
• EU GDPR (Regulation (EU) 2016/679): https://eur-lex.europa.eu/eli/reg/2016/679/oj
• EU Directive 2013/40/EU (Attacks Against Information Systems): https://eur-lex.europa.eu/eli/dir/2013/40/oj
• UK Computer Misuse Act 1990 (as amended): https://www.legislation.gov.uk/ukpga/1990/18
• UK Data Protection Act 2018: https://www.legislation.gov.uk/ukpga/2018/12
• Canadian Criminal Code § 342.1 / § 403: https://laws-lois.justice.gc.ca/eng/acts/c-46/
• Australian Criminal Code Act 1995, Part 10.7: https://www.legislation.gov.au/Details/C2024C00037

9.4 Secondary sources and case law references

• Van Buren v. United States, 593 U.S. 374 (2021) — Supreme Court narrowing of “exceeds authorized access” under the CFAA. Full text at the Supreme Court’s published opinions.
• Garcia, F. D., et al. “Dismantling MIFARE Classic.” ESORICS 2008. — The foundational academic paper documenting the Crypto1 break.
• Garcia, F. D., et al. “Wirelessly Pickpocketing a MIFARE Classic Card.” IEEE S&P 2009. — The card-only (darkside) attack documentation.
• Garcia, F. D., et al. “Dismantling iClass and iClass Elite.” ESORICS 2012. — The HID iCLASS family cryptographic analysis.
• Verdult, R., et al. “Gone in 360 Seconds: Hijacking with Hitag2.” USENIX Security 2012. — The HITAG2 attack documentation.

9.5 Industry references

• HID Global product documentation: https://www.hidglobal.com/ — for current iCLASS / SEOS specifications.
• NXP MIFARE technical documentation: https://www.nxp.com/products/rfid-nfc/mifare-hf/mifare-classic — for current MIFARE Classic / Plus / DESFire / Ultralight specifications.
• Proxmark3 RRG mainline: https://github.com/RfidResearchGroup/proxmark3 — the active open-source Proxmark3 firmware and client.
• Lab401 (iCopy-X distributor): https://lab401.com/
• Nikola Lab / icopyx.com (iCopy-X manufacturer): https://icopyx.com/
• iCopy-X-Community teardown: https://github.com/iCopy-X-Community/icopyx-teardown
• iCopy-X-Community upstream: https://github.com/iCopy-X-Community/icopyx-upstream
• Nikola-Lab GitHub org (official upstream of open-sourced hardware): https://github.com/Nikola-Lab

9.6 Engagement-folder templates and references

The pentest industry has well-developed templates for the documentation discussed in §4. Useful sources:

• SANS Penetration Testing curriculum — published SOW templates and authorization-letter language.
• Offensive Security PEN-200 / OSCP curriculum — standard engagement-structure references.
• Council of Registered Ethical Security Testers (CREST) — UK / EU professional body, publishes engagement frameworks.
• Open Source Security Testing Methodology Manual (OSSTMM) — methodology framework with engagement-structure references.

For the legal-specific documentation (DPA templates under GDPR, etc.), consult counsel licensed in the relevant jurisdiction. Generic templates can be a starting point but should be reviewed by an attorney before use in an actual engagement.

10. Document version and currency

This volume is current as of the iCopy-X 2.0 firmware family and the legal landscape as of 2026-05. The statutory citations in §2 are correct as of that date; subsequent amendments and case law developments may change specific points. The card-technology references in §7 and §8 are current as of the firmware revision documented in Vol 10.

Document revision dates:

• 2026-05-25 — initial publication as the closeout volume of the iCopy-X deep-dive series.

Series structure summary — see Vol 1 §1 for the full reading-order recommendation. For day-to-day engagement work, the load-bearing volumes are:

• Before an engagement: this volume (§1-§6), Vol 11 (tool comparison), Vol 9 (blank-card stock).
• During an engagement: this volume’s cheatsheet (§7), Vol 7 + Vol 8 (operating modes).
• After an engagement: this volume’s post-engagement checklist (§7.7), Vol 10 (firmware-update workflow if a new revision is available).

Series status: Vol 12 is the closeout. The series is complete as of this volume’s publication. Future updates to the series will track:

• iCopy-X firmware revisions (require updates to Vol 7, Vol 8, Vol 10).
• New card technologies appearing in the field (require updates to Vols 3-6).
• Material changes in the statutes cited in §2 (require updates to §2 specifically; major recasts are unlikely but case-law refinements are routine).
• Changes in the iCS Decoder accessory or pricing (require updates to Vol 6 §5).

One more time, because it bears repeating: this volume is not legal advice. Engineering-grade orientation, written for an engineer audience who already understands the technical material and now needs to understand how the legal framework wraps around it. Real legal advice for a real engagement comes from a licensed attorney with jurisdiction-specific expertise. The cost of that consultation is small. The cost of getting this wrong is large. Get the consultation.