Verified export

What a verified export is

A verified export (also called a certified export) packages one conversation, or a whole archive, into a single .zip for when a record has to be trusted by someone other than you. The point, versus a screenshot, is that it is tamper-evident and independently verifiable. Anyone who receives it can confirm with standard tools that the package was not altered and existed, unchanged, at a specific time. You do not have to trust Text2Store for any of it.

It is included in a Text2Store subscription. To make one, open a conversation, choose Export, then Verified export.

Exporting from a certified backup strengthens this further: the export's proof reaches back to when the backup was made, not just when you exported it. See the certified backups page for that part of the story.

What's inside the package

The .zip unzips to a small, self-explaining set of files:

• transcript.pdf is the messages as a readable, printable transcript.
• conversation.json is the same messages as data, including anything the PDF can't draw.
• attachments/ holds every photo, video, and file from the conversation, in its original bytes.
• certificate.pdf is a human-readable cover: the device, the conversation, the date range, counts, and how to verify.
• manifest.json is the heart of it: a SHA-256 fingerprint of every other file.
• VERIFY.txt lists plain-English commands to check everything yourself.
• DECLARATION.txt is a fill-in declaration a person can sign (see below).
• manifest.json.tsr is the trusted timestamp, added when you were online.
• tsa/cacert.pem is the timestamp authority's certificate, so the time verifies from the package alone.
• source/backup-timestamp.tsr appears only when the export was made from a certified backup: the backup's own creation-time timestamp, carried forward so the export's proof reaches back to when the backup was made.

What it proves

• Integrity. Every file is listed with its SHA-256 fingerprint in manifest.json. Re-computing any file's fingerprint confirms it is byte-for-byte the same as when you exported it. Change one pixel of one photo and verification fails.
• Provenance to your backup. Each attachment also records the fingerprint it had in the device backup it came from, tying the exported file to that specific backup rather than to something typed by hand. The export refuses to build if any attachment no longer matches.
• Time. When you are online, the whole package is timestamped by an independent Timestamping Authority using the RFC 3161 standard (the same mechanism behind code-signing timestamps). That proves the package existed, unchanged, at a specific moment, which answers "you edited this last week."

Why a change can't slip through

"Tamper-evident" is a precise claim, so here is why it holds. It does not mean the file cannot be edited. Any file can be. It means any edit is caught. An attacker who wants to slip a change past the verifier runs into three walls in a row:

• A fingerprint can't be faked. Each file's SHA-256 fingerprint is a 64-character value computed from its exact bytes. Change a single byte, anywhere, and the fingerprint changes completely. There is no known way to alter a file and keep its SHA-256, so a changed file can no longer match its recorded fingerprint. That is the first wall.
• The list is fingerprinted too. The obvious next move is to edit the fingerprint inside manifest.json to match the changed file. That fails as well: the manifest carries a content-root fingerprint over its own list, and the trusted timestamp is taken over the entire manifest. Editing the list breaks both. Second wall.
• The timestamp needs a key nobody has. The last move is to rebuild the manifest and obtain a fresh trusted timestamp for the rewritten version. That requires the Timestamping Authority's private signing key, which is held by an independent third party (DigiCert). Neither you, nor Text2Store, nor an attacker can produce a valid timestamp without it. This is exactly why a Text2Store verification reports Verified only when a valid trusted timestamp is present: the timestamp is the anchor that makes everything under it impossible to rewrite and re-seal. A package that has no trusted timestamp is reported as Unverified, not verified, precisely because that anchor is missing. Third wall.
• You don't have to trust us. Every one of these checks uses open standards (SHA-256, RFC 3161) and can be reproduced with standard tools that ship on Mac and Windows. The security does not rest on trusting Text2Store's word, or even Text2Store's app.

The honest boundary is worth stating plainly: this is tamper-evident, not tamper-proof. Anyone can still change or delete the file. What they cannot do is change it and have it still verify. If a package verifies, it is the one that was exported. If it was touched, verification says so.

What it does not prove (please read)

Being honest about the limits is part of what makes the rest trustworthy. A verified export does not prove:

• That the messages are true, or that the phone was not manipulated before the backup was made. It proves the package has not changed since export, not what happened before it.
• How it will be received. Text2Store never claims a verified export will be accepted by any particular recipient or process, and never describes it as "court-admissible" or "authenticated." What weight a record carries is always the recipient's decision; software can only make the record checkable.
• Completeness. A verified export can only contain what the phone still had when it was archived. Messages deleted before you captured them are simply absent. The transcript does mark messages that were deleted on the device, edited, or unsent, when that survived to capture.
• Exactly when each message was sent, in an absolute sense. The trusted timestamp attests when the export existed, not when the messages were sent. Message times come from the device.

Protecting it with a password (optional)

A verified export is a plain .zip: anyone who has the file can read the messages. That is usually what you want, because it opens anywhere with no software. When the file has to travel, though, you can lock it. Tick Protect this .zip with a password when you create the export and the contents are encrypted with AES-256. It is off by default and is a per-export choice.

Encryption and tamper-evidence are separate things. The password keeps people from reading the messages. The fingerprints and timestamp are what prove nothing was changed, and they work exactly the same either way. A password does not make an export more verifiable, and skipping one does not make it less.

Everything inside is encrypted, VERIFY.txt included, so a protected export gives up nothing without the password. One thing it cannot hide: a zip never encrypts its list of file names, so anyone can see that the package contains a transcript, a manifest and some attachments. The names are generic, so they say nothing about who you were talking to or what was said.

To verify a protected export in Text2Store, pick it as usual; the app notices it is locked and asks for the password. To verify by hand, extract it with one of the tools above first, then follow the ordinary steps below.

How to verify it, without trusting us

There are two ways, and they check the same fingerprints and the same timestamp.

In the app: choose File, then Verify a Certified Export, and pick the .zip. Text2Store re-checks every fingerprint and the timestamp and reports Verified, Altered, or Unverified. "Verified" means the files match and the trusted timestamp proves the package is unchanged. "Altered" means something no longer matches. "Unverified" means the files are internally consistent but the package carries no trusted timestamp, so it can't be proven unaltered on its own (compare its manifest fingerprint against a copy you trust). It needs no internet and nothing installed, and it works the same on Mac and Windows. For independence, it uses its own pinned copy of the timestamp authority's certificate, not the one inside the package.

By hand: the included VERIFY.txt lists the exact commands. On macOS and Linux use shasum; on Windows use Get-FileHash in PowerShell. To confirm the trusted time as well, use openssl. One honesty note from VERIFY.txt itself: the LibreSSL that ships with macOS cannot verify this timestamp's certificate chain, so install full OpenSSL (Homebrew) or use the in-app verifier; on Windows, the OpenSSL that ships with Git for Windows works. VERIFY.txt also prints the SHA-256 of the timestamp authority's certificate, so you can confirm it against DigiCert's published root at cacerts.digicert.com before relying on the attested time.

The technical details

For the reader who wants to check the mechanism rather than trust the summary: everything below uses published standards (SHA-256, RFC 3161, CMS) and can be reproduced with standard tools. Nothing here is proprietary or secret. That openness is the point, a claim you can independently confirm is worth more than one you have to take on faith.

The fingerprints and the manifest

Every file in the package is hashed with SHA-256 over its exact bytes. manifest.json lists each file as a path and its SHA-256:

{
  "format": "text2store/verified-export",
  "artifacts": [
    { "path": "transcript.pdf", "sha256": "9f2c..." },
    { "path": "conversation.json", "sha256": "4a1e..." },
    { "path": "attachments/0001.jpg", "sha256": "b7d0...",
      "source_backup_sha256": "b7d0..." }
  ],
  "content_root_sha256": "e3b1..."
}

The content_root_sha256 is a single fingerprint over the whole list, so the list itself is tamper-evident too. It is computed by taking one path:sha256 line per artifact, sorting those lines, joining them with newlines, and hashing the result with SHA-256. Anyone can recompute it from the manifest and confirm it matches.

Tying attachments to the device backup

Each attachment also records source_backup_sha256, the fingerprint that file had in the iPhone or iPad backup it came from. The export is built against that backup's own checksum baseline and refuses to build if any attachment no longer matches, so an exported photo is tied to the specific device backup rather than to something dropped in by hand.

What sits outside the fingerprint list

Only two files are not listed as artifacts, for a structural reason: manifest.json cannot contain its own fingerprint, and manifest.json.tsr (the timestamp) is made from the manifest's fingerprint, so it comes into existence after the manifest is sealed. Everything else, including the human-readable certificate.pdf, VERIFY.txt, DECLARATION.txt, and the authority's tsa/cacert.pem, is hashed into the manifest like any other file. A verifier recomputes the manifest's own SHA-256 and treats that as the package fingerprint.

The trusted timestamp

manifest.json.tsr is an RFC 3161 timestamp token, a CMS SignedData structure whose messageImprint is the SHA-256 of manifest.json. To accept it, a verifier confirms that the token's signature is valid, that the signer certificate chains to DigiCert's root (the token embeds its full signing chain, leaf through intermediate to root), that it was within its validity window at the attested time, that it carries a critical id-kp-timeStamping extended key usage (as RFC 3161 requires), and that the imprint equals this manifest's SHA-256. Text2Store's in-app verifier does all of this in pure code with no network access, and it pins its own copy of the DigiCert root rather than trusting the cacert.pem inside the package, so a swapped certificate can't fool it. VERIFY.txt prints the SHA-256 of that certificate so you can confirm it against DigiCert's published root at cacerts.digicert.com.

Checking it yourself, exactly

Hash any file and compare to its sha256 in the manifest:

# macOS / Linux
shasum -a 256 transcript.pdf

# Windows (PowerShell)
Get-FileHash transcript.pdf -Algorithm SHA256

Verify the trusted timestamp covers this exact manifest and chains to the authority:

openssl ts -verify -data manifest.json -in manifest.json.tsr -CAfile tsa/cacert.pem

The package's VERIFY.txt spells out these commands, including how to recompute the content root, so they are copy-and-paste.

What counts as a pass

A verifier should report Verified only when all of the following hold: every listed file is present and matches its fingerprint, the content root recomputes, no extra or duplicated files are present, and a trusted timestamp verifies over manifest.json. A package with no trusted timestamp is Unverified, internally consistent but not independently anchored, because the manifest cannot prove its own integrity without that outside signature. Any mismatch, extra file, or a timestamp that fails to verify is Altered.

The signed declaration

Some processes want a human attestation alongside a record: a person stating, in writing, how the record was made. Software can't make that statement; only a person can. So the package includes DECLARATION.txt: a plain, fill-in template a person (you, or a records custodian) can adapt and complete with the manifest fingerprint you computed.

It is a template, nothing more. It is not legal advice, and if you are preparing something for a formal proceeding, have a lawyer review it first.

Times and time zones

In the human-readable PDFs, message times are shown in the exporting computer's local time with an explicit UTC offset (for example, 2026-06-30 21:14 -08:00), with the time zone noted at the top, so they match what you saw on the phone and stay unambiguous. The machine-readable data (conversation.json) and the trusted timestamp keep everything in UTC, so an expert can always reconstruct exact times.

The honest limit

A verified export is only as complete as the backup behind it. Text2Store can only include what your phone still had when you archived it. The best habit is simple: back up regularly, so a conversation is safely captured long before you ever need it. iOS keeps a deleted message recoverable for a few weeks, so a recent backup often catches more than you'd expect. See the FAQ for more.

Questions?

Email hello@text2store.com and we'll help.