Proving an NFC or RFID capture is unaltered
An NFC dump or an RFID capture is one of the easiest pieces of evidence in security work to edit and one of the hardest to defend. This guide walks through how a capture is shown to be unchanged, from the moment it is read off the card to the moment it appears in a report.
The problem with an NFC or RFID capture
A contactless access credential reads out to a very small file. A Flipper .nfc dump or a Proxmark3 log is often a few hundred bytes of plain, human-readable structure: a UID, some sector data, a key list. That readability is useful in analysis and fatal for trust. Open the file in any editor and you can change the UID, flip a sector, or add a key, and the file remains perfectly valid. Nothing in it records when it was captured, which reader produced it, or whether it has been touched since.
So when the finding "this badge is clonable" reaches the client, the file on its own proves nothing. The reviewer has no way to tell the capture you read at the turnstile from one assembled afterwards. Capture integrity is the discipline of closing that gap: showing, cryptographically, that the bytes in the report are the same bytes that came off the card.
What integrity actually means here
Integrity is a narrow and testable claim. It does not mean the capture is interesting, or that the finding is severe. It means exactly one thing: the file has not changed since it was collected. That claim is testable because of how a cryptographic hash behaves. A SHA-256 digest is a fixed 64-character fingerprint of a file's exact bytes. Two files with the same digest are byte-for-byte identical. Change one bit and the digest changes beyond recognition, and you cannot run the process backwards to forge a file that produces a chosen digest. Record the digest when the capture is collected, recompute it later, and the comparison is a clean yes or no.
The engineering question is where in the file's life you take that first hash, and over which bytes.
Hashing the native file at read time
Vaultprobe hashes the native capture file at the point it is read in, over the file's raw bytes. This sounds obvious and is easy to get wrong. Many tools that touch a capture decode it to text first, repair it, or normalise its line endings, then hash the cleaned-up version. For a binary capture, such as a pcap, a wireless handshake, or a raw card dump, that text round-trip silently rewrites any byte that is not valid text, so the stored hash no longer matches the original file. The integrity claim quietly breaks before it is ever tested.
Hashing the raw bytes avoids that. The digest Vaultprobe records is taken over the exact bytes on disk, so it equals a plain sha256sum of the file and stays byte-accurate for text and binary captures alike. The hash is anchored to the real artefact, not a cleaned-up projection of it, which is the only version of the hash an auditor can independently reproduce.
Re-verifying the capture downstream
A digest captured once is only half of integrity. The other half is being able to re-check it at any later point, by someone who does not have to take your word for anything. Every capture Vaultprobe ingests carries its SHA-256 into the report as a custody record with an evidence identifier. To re-verify, you re-hash the original file and compare:
The command exits zero on a match and a non-zero code on a mismatch, so it works as a manual spot check and as an automated gate. Because the digest in the report is just a standard SHA-256, the client's own auditor does not even need Vaultprobe. They can run sha256sum against the original capture on their own machine and compare it to the report. Integrity that only your tool can confirm is not integrity, so the verification path is deliberately one anybody can walk.
Surfacing tamper status, never hiding it
The strongest version of this chain starts on the capture device itself. For NFC captures, a Vaultprobe capture companion on the handheld computes the SHA-256 at the moment of capture and writes it into a sidecar record next to the file. At ingest, Vaultprobe recomputes the hash independently and compares the two, then reports the outcome explicitly:
- Verified. The on-device hash matches the file, so the capture is intact from the device onward.
- Mismatch. The hashes disagree. This is raised loudly as possible tampering, with a clear instruction not to trust the capture, rather than being swallowed.
- Missing or malformed sidecar. Flagged in its own right, because a capture with no device record, or a damaged one, is exactly the case a reviewer needs to see.
The principle is that a tamper signal is always surfaced. A silent pass on a capture that failed its integrity check would be worse than no check at all, because it would launder a doubtful file into a trusted-looking one. A failed or absent check is treated as a finding about the evidence, not as noise to suppress.
Where this fits
Capture integrity is one link in a longer chain. Hashing at the moment of capture is what makes the integrity claim defensible from the earliest point, covered in the chain-of-custody guide. Mapping the verified finding to a recognised control framework is what makes it useful to an auditor, covered in the defensible-report guide. Integrity is the link that turns "trust us" into "check it yourself".
Put a capture through it
Vaultprobe runs as a single self-hosted Docker container, with no cloud upload and no client data leaving your network. The 30-day pilot lets you ingest your own NFC and RFID captures and see the integrity status in a real report.