Adobe Producer Spoofing: A PDF Metadata Forgery Case Study

Originally published at reads it — along with every other field — straight out of any PDF.

Why the Producer field is the obvious thing to forge

Every PDF carries internal records about how it was made. Two fields matter most to a reviewer:

• 
  producer — the software that wrote the final bytes of the file.


• 
  creator — the application the content originated in.

Fraud-detection lore, repeated in countless “how to spot a fake bank statement” guides, says the same thing: a real institutional document is generated by an automated back-end system, so if the producer says Microsoft Word, Canva, or some online PDF tool, you are probably looking at a forgery. (For the full breakdown of what these fields contain and what they reveal, see the .) That advice is correct as far as it goes.

The problem is that it is public advice. Forgers read the same guides. So the natural next move is not to leave an incriminating producer string in place — it is to overwrite it. And if you are going to overwrite it, you do not write LibreOffice. You write the most trusted name you can: Adobe.

Overwriting a metadata string is trivial. A producer value is just text inside the file; dozens of free tools and one-line scripts will set it to anything you like. So the field that fraud guides tell reviewers to trust is also the field that is cheapest for a forger to fake. A metadata-only check that stops at “the producer says Adobe, looks fine” is checking the one thing the attacker fully controls.

What a metadata-only review actually verifies (almost nothing)

Reading the producer and creator strings tells you what the file claims about itself. It does not tell you whether those claims are true. A self-reported field is a self-reported field, whether it says Canva or Adobe PDF Library.

This is the gap. The reviewer who rejects a statement because its producer says Canva is doing the right thing — but a forger who has done their homework will never present that file. They present the version that says Adobe. Now the same reviewer, applying the same rule, accepts the worse forgery. The rule rewards the more careful attacker.

To catch producer identity forgery you cannot ask “what does the file say?” You have to ask “does the rest of the file behave the way a file from that producer actually behaves?” That is a structural question, not a metadata-string question.

The contradiction a forged Adobe claim leaves behind

Genuine Adobe software does not just stamp a producer string and stop. When real Adobe products write a PDF, they leave a coherent set of structural fingerprints throughout the file — the byproduct of how that software actually assembles, describes, and saves a document. These fingerprints are consistent across genuine Adobe output because they fall out of the software’s real internals, not from any single field a user types.

A forger who only overwrites the producer text gets none of that for free. They have changed the label on the box without changing what is inside it. The result is a file whose metadata announces “Adobe produced me” while its underlying structure tells a different, internally inconsistent story — the structure of an online editor or a consumer re-save tool wearing an Adobe name tag.

That contradiction — an Adobe origin claim that the file’s own structure does not support — is the signal. When HTPBE sees a document asserting Adobe origin while the structural fingerprints that genuine Adobe output reliably carries are absent or mutually inconsistent, it treats the Adobe claim as forged and returns the public marker HTPBE_PRODUCER_IDENTITY_FORGED. The verdict for such a file is modified: the metadata has been edited to misrepresent the file’s origin, which is precisely a post-creation modification.

We deliberately do not publish the exact byte-level checklist of which fingerprints are checked or how they relate. That list would be a bypass recipe — a map of exactly which fields a forger would need to forge in lockstep to defeat the check. The principle is the part that’s safe to state plainly: real Adobe output leaves structural fingerprints that a string-overwrite, a consumer re-save tool, or a metadata editor does not reliably reproduce. The forger faked the easy part and skipped the hard part, because the hard part is invisible to them.

A worked example, in business terms

Picture two files crossing a lending team’s desk in the same week.

File A is a real PDF statement from a bank’s document system. Its producer reflects the institutional pipeline that generated it. Its internal timestamps, structure, and origin signals all line up. HTPBE returns intact. Accept.

File B looks nicer. Its producer proudly says Adobe PDF Library, which the reviewer reads as a green flag. But File B started life as a PDF that someone opened in a browser editor, changed the closing balance on, and then ran through a step that rewrote the producer to Adobe. The Adobe claim is bolted onto a body that was never anywhere near Adobe software. HTPBE returns modified with HTPBE_PRODUCER_IDENTITY_FORGED. Reject.

To the human eye, File B is the more trustworthy of the two — it name-drops Adobe; File A just has some institutional toolchain string nobody recognizes. Structural forensics inverts that intuition, which is the whole point. The forger optimized for the human reviewer’s heuristic and walked straight into the structural one.

Where inconclusive fits — and why it isn’t a failure

Not every non-Adobe file is a forged-Adobe file. Plenty of legitimate documents are simply produced by consumer software: someone exports a perfectly honest letter from a word processor or a print-to-PDF driver. Those files don’t claim a false institutional origin; they just aren’t the kind of file whose integrity can be cryptographically vouched for after the fact.

For those, HTPBE returns inconclusive. That verdict is not a tool failure and it is not an accusation — it means the file was made with consumer software, so there is no institutional structural baseline to verify the file against. inconclusive is itself a useful signal: if your process expected a document from an institution and the result is inconclusive, the file wasn’t generated by an institutional system, and that mismatch is something your workflow should act on. Producer identity forgery is the opposite case: a file actively claiming the institutional/Adobe origin it doesn’t have. The first is a quiet gap; the second is a loud lie.

The honest limit

This detector raises the cost of the attack; it does not make it impossible. A forger who fully understands what genuine Adobe output looks like, and who reproduces the entire coherent fingerprint — not just the producer string, but every structural detail that has to agree with it — can in principle still present a file that asserts Adobe origin without contradicting itself. No structural check that relies on fingerprints can claim absolute immunity against an attacker who perfectly reproduces those fingerprints.

What the detector does is move the bar from “edit one text field, which any free tool does in a second” to “reconstruct a complete, internally consistent Adobe production fingerprint by hand.” The overwhelming majority of producer-spoofing forgeries are the first kind, because the second kind requires deep, document-internals knowledge that the casual forger — the one buying a “fake bank statement” off a Telegram channel — simply does not have. Catching the cheap, common attack while being honest that a determined expert can still get through is the realistic standard for forensics, and it is the standard we hold this check to.

One more boundary worth stating: HTPBE is structural PDF tamper detection. It reasons about the file’s bytes and structure — whether the document was modified after creation and whether its origin claims hold up. It is not a KYC or identity-verification platform, and it does not read the document’s content to decide whether the named account holder is a real person or whether the balance is plausible. It complements an identity and risk stack; it does not replace one. Producer identity forgery is firmly in its lane: a structural contradiction between what the file says made it and what actually did.

Detecting it in your own pipeline

Producer identity forgery is one of 61 forensic checks (as of this writing) that run on every document submitted to the ; for the conceptual model behind the verdicts, see returns deterministic synthetic results for documented scenarios, so you can build and verify your gate logic before pointing it at production documents.

Who should care about this check

If you run fraud or risk operations at an alternative lender, a fintech, an insurer, or any business that accepts customer-supplied PDFs claiming to come from a bank, an employer, or a government body, producer identity forgery is being used against you right now — specifically because your team has been trained to read the producer field as a trust signal. The forgers know that, which is why they forge it.

The fix is not to stop reading metadata; it’s to stop trusting self-reported metadata on its own. (If you want a broader catalog of what tampering leaves behind, see , or start with pay-per-check on the web tool if you want to run a batch of suspicious documents before committing to an integration. Either way, the next forged-Adobe statement that lands in your queue should come back modified — not waved through on the strength of a string anyone can type.

Vollständiger Original-Bericht

Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

↗ Original-Artikel auf dev.to lesen