Direct answer
Use NFC memory dumps responsibly: understand pages, blocks and files, compare hexadecimal data, preserve evidence, avoid unsafe restores and protect sensitive data.
What an NFC memory dump represents
A dump is a captured view of bytes returned through a supported technology at a particular time. It is not automatically a complete chip image, because unreadable areas, volatile state, protected files and manufacturer data may be absent or represented by placeholders.
- Snapshot
- Record tag technology, tool version, read command scope and failures alongside the bytes so another analyst knows what was actually captured.
- Authorization
- Acquire and inspect dumps only from tags and systems the operator owns or is explicitly authorized to diagnose.
Pages, blocks, sectors and files
Type 2 tags commonly expose four-byte pages, MIFARE Classic organizes blocks within sectors, and Type 4 or DESFire products use applications and files over ISO-DEP. A universal row of hexadecimal bytes cannot erase these protocol differences.
- Address meaning
- An offset is meaningful only with the chip family and command used to read it.
- Access conditions
- Unread bytes may indicate authentication or policy, not damaged memory; preserve that state instead of filling it with guessed zeros.
Read hexadecimal without losing structure
A useful view groups bytes by the technology's natural address unit, labels offsets and pairs hexadecimal with safe text decoding. Known capability, lock and configuration areas should be annotated without pretending that every vendor uses the same map.
- Endianness
- Multi-byte counters and identifiers may use different byte orders; interpretation must follow the relevant data sheet or protocol.
- Encoding
- Printable text in one region does not prove the entire dump is UTF-8; NDEF parsing should begin from its container and record headers.
Compare dumps with a controlled diff
A byte diff is valuable when one variable changes at a time: before and after a write, known-good versus failing sample, or two configuration revisions. Highlight changed addresses and preserve both originals as immutable evidence.
- Expected changes
- Separate intended NDEF payload bytes or counters from unexplained changes in lock and configuration areas.
- Noise
- Dynamic counters, random identifiers and unreadable responses can create differences that need protocol context rather than immediate fault labels.
Recognize lock and configuration hazards
Some memory addresses control irreversible locks, password access, mirror behavior or read ranges. Editing a hex cell without a chip-specific model can permanently disable future writes or expose data.
- Guardrail
- Mark sensitive regions read-only in the editor until the user selects a supported operation that validates the complete configuration.
- Confirmation
- Describe the exact addresses and consequence before any write that can set permanent lock state.
Understand dump file formats
BIN stores raw bytes but little context; HEX adds textual address records; TXT is human-readable but not standardized; tool-specific formats such as Flipper NFC include metadata and protocol fields. Import must validate structure before presenting a write action.
- Round trip
- Export and re-import the same authorized sample in tests to verify that addresses, gaps and metadata remain stable.
- Version marker
- Include application and format version so future builds can migrate fields instead of guessing an old layout.
Why blind restore is unsafe
A dump from one chip may contain manufacturer data, lock state or addresses that another tag does not implement. Writing every byte to a visually similar target can fail, corrupt public content or alter permanent configuration.
- Compatibility gate
- Require the expected technology, memory geometry and writable ranges to match before enabling a supported restore.
- UID boundary
- Factory-programmed or protected identifiers generally cannot be recreated through ordinary write commands and must not be advertised as restorable.
Preserve diagnostic evidence
Name captures with a case reference, date, tool version and non-sensitive sample label, then hash exported files when integrity matters. Keep the original read-only and create a separate annotated or redacted copy for discussion.
- Chain of handling
- Record who acquired, transformed and shared the file when the investigation supports production or security decisions.
- Reproducibility
- Store the command scope and errors, not just the bytes that happened to succeed.
Redact confidential NFC data
Dump files can contain URLs with tokens, contact records, internal identifiers or proprietary configuration. Preview and remove sensitive ranges before attaching a file to a support ticket or public issue.
- No analytics
- Never send full dumps, UIDs or discovered secrets to routine product analytics.
- Retention
- Delete working files when the authorized diagnostic purpose ends and document any required longer retention.
A responsible laboratory workflow
Begin with read-only identification, collect a baseline, decode standard NDEF, consult the correct manufacturer documentation and change one authorized value at a time on expendable test stock. Re-read after each operation and stop when the technology is uncertain.
- Test stock
- Use clearly labelled laboratory tags rather than live access, payment, identity or transit credentials.
- Report
- State what was observed, what could not be read and which conclusions remain assumptions.
Quick reference
| Format | Strength | Main caution |
|---|---|---|
| BIN | Compact raw bytes | No inherent addresses or technology context |
| HEX | Address-aware text exchange | Multiple variants need validation |
| TXT | Readable notes | Not a reliable interchange standard |
| Tool-specific NFC | Carries protocol metadata | Version and compatibility vary |
Related NFCMagic app screens
These screenshots connect this NFC memory dump diagnostics guide to the related Android workflow in NFCMagic. They document interface states; radio behavior still requires a physical Android device and real tags.
Frequently asked questions
Is an NFC dump always a complete copy of a tag?
No. Protected, volatile, unsupported and manufacturer-controlled areas may be missing or unreadable.
Can a BIN dump be written to any tag of the same size?
No. Technology, memory map, writable ranges and configuration must match; blind restore can damage the target state.
Why do two reads of one tag differ?
Counters, random identifiers, dynamic data, read errors or changing application state can create legitimate differences.
What should be removed before sharing a dump?
Redact tokens, personal data, secret configuration, full identifiers and any content outside the authorized diagnostic need.
Primary technical sources
- Android Developers: Advanced NFC — Official guidance for tag technologies, NDEF operations and foreground dispatch.
- Android Developers: Ndef API — API contract for capacity, writability, NDEF I/O and permanent read-only operations.
- NXP: NTAG 213, 215 and 216 — Official capacities, RF characteristics, lock features and target applications.