Previous: LF RFID and iButton · Series index · Next: Sub-GHz
Sources checked 18 September 2026 · Exercises have not been run on THL hardware.
Use case: Separate a lab tag’s public identity, content, and authentication. Legitimate use: Check labels and assess an authorized prototype. Harmful use: Copy weak credentials, expose private data, or substitute misleading content. Exercises use disposable data with no access or payment privileges.
1. What NFC adds
Flipper’s NFC hardware operates at 13.56 MHz, separately from the LF and contact interfaces in Part 03. NFC devices can exchange structured data and, depending on their design, authenticate and encrypt communication. Frequency alone establishes neither security nor emulation support. Flipper NFC overview
Three different questions often get compressed into “Can it copy my card?”
- Identity: What identifier or protocol metadata does the card disclose?
- Content: Which memory pages, files, or application data can the reader obtain?
- Authentication: Can a device prove knowledge of the required secret for a fresh transaction?
A photograph of Flipper displaying an identifier answers only the first question. Even a useful-looking dump may omit protected content or transaction state.
2. How tag families change the answer
| Example family | Relevant documented limit |
|---|---|
| MIFARE Classic | Sector contents depend on obtaining the appropriate keys; recognizing the card is not a complete read. |
| Ultralight / NTAG | Open pages may be readable while protected pages are unavailable. |
| MIFARE DESFire | Flipper documents reads of unprotected applications and files, not unrestricted extraction of secrets. |
| Unknown Type A card | The saved result may contain only UID, SAK, and ATQA metadata. |
Flipper’s current documentation makes emulation dependent on card type and saved data: an operation may reproduce supported card data or only its UID. Do not promote partial capture to “full clone.” Supported reads and emulation
NXP’s NTAG213/215/216 family provides user memory for labels and business cards, a UID, locks, and configurable password protection. Intentionally readable label content is public information, not a recovered secret. NXP NTAG21x
Password-protected memory should not be confused with a modern cryptographic access credential. NXP explicitly describes NTAG21x password protection as a convenient memory-access control and points to application-layer cryptography for greater protection. Password and acknowledgement values are not disclosed by normal memory reads. NTAG21x data sheet, section 8.8
3. Safe exercise: inspect a plain-text lab label
Reuse a supported training tag containing only a text record such as THL NFC LAB, plus your NFC phone or reader. Prepare the record using your application’s documented write function if needed. Use a disposable, unenrolled tag; leave irreversible lock bits and passwords unchanged.
- Read the physical tag using your existing NFC application. Record its reported type and text. Keep URLs, contact details, credentials, and automation triggers out of this lab.
- On Flipper, select NFC → Read, present the tag at the rear, then choose More → Save. Give it an unmistakable lab name. Record whether the result is complete, partial, or identifier-only. NFC read procedure
- Remove the physical tag. If that type offers suitable emulation, select NFC → Saved → [lab tag] → Emulate and present Flipper to your own reader. Compare the displayed text and metadata. NFC emulation procedure
- Record the actual outcome, then stop emulation. If the phone sees nothing, record that limitation rather than changing to a real access card. Delete unneeded saved lab files after review.
The expected result, on a compatible combination, is readable lab content from the original and emulated tag. Phone software, card family, capture completeness, and emulation support can change the result. Matching text proves reproduction of that text for that reader; it does not demonstrate successful authentication, payment, or a building-access bypass.
4. How misuse works, and why stronger systems differ
A system authorizing someone using only a public identifier may accept a compatible emulator presenting that identifier. Separately, a substituted label can direct a trusting user to a deceptive page. These are explanatory scenarios, not claims of a THL incident.
Cryptographic systems ask for more than copied public bytes. DESFire EV3, for example, supports mutual authentication, AES, and secure messaging when configured appropriately. Its optional random identifier also shows why a UID need not be a permanent tracking label. Deploying the chip without using its security features would not confer those benefits automatically. NXP DESFire EV3
Payment claims require particular care. EMVCo explains that contactless transactions generate a one-time security code for each transaction. Displaying card metadata or replaying a static NFC identifier does not supply that cryptographic transaction capability. This chapter provides no payment-card cloning procedure. EMV Contactless Chip
5. Defenses and completion exercise
Authenticate credentials using the system’s supported cryptographic mechanism, protect keys, and keep enrollment and revocation under administrative control. For public information tags, inspect the destination before opening it and use physical checks against substitution. Protecting a genuine tag against writes does not stop someone replacing the entire label; content integrity and physical placement are different problems.
Completion exercise: Label every observed field as identity, public content, or authenticated evidence. Explain why a successful text-tag demonstration cannot establish that a protected DESFire application or payment card was cloned. Keep the source-backed capability claim separate from your own measured result.