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 meant for legal or records use: custody matters, harassment, contractor or realtor disputes, or anything you may need to produce later. The point, versus a screenshot, is that it is tamper-evident and independently verifiable. A lawyer, an opposing expert, or a court's IT staff 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.

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.

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 (freeTSA). 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.
• That a court will accept it. Text2Store never claims a verified export is "court-admissible" or "authenticated." Admissibility is the court's decision, and it turns on things we cannot control: how the device was handled, relevance, hearsay rules, and the judge. We give you a package a court can independently verify. Whether it is admitted is up to the court.
• 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.

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 (built in on macOS and Linux; on Windows, the one that ships with Git for Windows). VERIFY.txt also prints the SHA-256 of the timestamp authority's certificate, so you can confirm it against freeTSA's published root 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 freeTSA's 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 freeTSA 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 freeTSA's published root.

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

For a record to come in without a live witness, the rules of evidence that allow it, in US federal court the Federal Rules of Evidence 902(13) and 902(14), still call for a written certification by a qualified person. Software can't swear to how a record was made; only a person can. So the package includes DECLARATION.txt: a plain, fill-in template a person (you, or a records custodian) can adapt, complete with the manifest fingerprint you computed, and sign under penalty of perjury.

It is a template to make that step easier. It is not legal advice, and it is not a promise that any particular court will accept it. If you are preparing something for a proceeding, have a lawyer review it.

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.