PDF Digital Signature Chain: Detect PDFs Signed Then Modified

The PDF digital signature chain is a cryptographic lock: it computes a hash over a specific byte range of the file and stores that hash inside the document. If any byte within that range changes, the signature becomes invalid. This is what makes digitally signed PDFs trustworthy — in theory.

In practice, the PDF specification allows content to be appended after a signature without invalidating it. This is intentional: it supports legitimate workflows such as adding a second signature, appending a certification, or adding long-term validation (LTV) data. But it also creates a bypass: an attacker can append modified content after the signature, and the signature itself remains cryptographically valid. The signed portion did not change. The document did.

This is how a PDF gets signed then modified without triggering a certificate-level alert — and it is one of two high-stakes tampering patterns that HTPBE? detects at certain confidence.

What a PDF digital signature actually covers

When a signing platform — DocuSign, Adobe Sign, HelloSign, or any PDF-signing library — signs a document, it records a /ByteRange entry in the signature dictionary. This entry specifies exactly which bytes of the file the cryptographic hash covers:

/ByteRange [0 840 1256 4390]

This means bytes 0–840 and bytes 1256–5646 are signed. The gap (bytes 841–1255) is reserved for the signature value itself — it cannot be signed because it contains the signature.

After signing, the file ends at byte 5646. If content is appended, the file grows beyond that boundary. The signature covers bytes 0–5646. Everything appended after byte 5646 is unsigned.

An e-signature platform showing “signature valid” on such a document is not lying: the signed byte range is intact. But the document you are reading is larger than what the signer approved.

How to detect a PDF signed then modified: two patterns at certain confidence

HTPBE? raises two markers at certain confidence for signature-related tampering. Certain is the highest confidence level in the system. Unlike high-confidence markers — which indicate strong but circumstantial evidence — certain markers are binary. Either the bytes changed or they did not. Either the signature object exists or evidence of its removal is in the file.

Pattern 1: Modifications after digital signature

The detection reads the signature dictionary’s /ByteRange, calculates the covered range, and compares it against the actual file size. If there are xref entries pointing to objects outside the signed byte range, the document was modified after signing.

Structural evidence that confirms this:

• The file has an incremental update (a new xref section appended after the last signature event)
• The new xref section contains object references that fall outside the /ByteRange of the existing signature
• The signature itself remains internally valid — only the unsigned append is flagged

This pattern appears when someone takes a signed contract, appends a modified page (or replaces a referenced object through an incremental update), and re-distributes the file. The signing platform’s signature UI may still show “valid” because the platform validates the byte range it knows about, not the full document.

The API response for this pattern:

{
  "status": "modified",
  "modification_confidence": "certain",
  "modification_markers": ["Modifications after digital signature"],
  "has_digital_signature": true,
  "modifications_after_signature": true,
  "signature_removed": false,
  "xref_count": 3
}

Pattern 2: Signature removed

The second pattern is removal. A signed PDF has its signature object stripped and the file is saved as a new document. The goal is to produce a file that does not show a signature at all — removing the constraint of an immutable signed payload.

This is harder to clean up completely. The PDF specification’s incremental-update model means prior xref entries leave traces in the file structure. When a signature object is removed, the object slot persists in the xref table as a free entry. Additionally, HTPBE?’s ghost-info scan inspects object streams (ObjStm) for residual metadata — Info dictionaries, annotation references, and signature field stubs that were present before removal but not cleanly erased.

The structural evidence for removal:

• A /SigFlags entry in the AcroForm dictionary (or a residual reference to one) indicates the document had a signature form field
• The corresponding signature object is absent or marked free in the xref
• Object streams preserve the original Info dictionary with signing-tool metadata that contradicts the document’s current state

API response for signature removal:

{
  "status": "modified",
  "modification_confidence": "certain",
  "modification_markers": ["Signature removed from document"],
  "has_digital_signature": false,
  "modifications_after_signature": false,
  "signature_removed": true,
  "xref_count": 2
}

Why these are certain, not high

Most forensic markers in this system produce high confidence because they rely on inferential evidence: a timestamp inconsistency, a producer mismatch, an unexpected xref count. These signals are reliable but not deterministic. A single high marker is suspicious. Multiple high markers together constitute a strong case.

certain confidence works differently. The underlying evidence is structural and self-consistent:

For modifications after signing: the signature’s byte range is embedded in the document. The file size is a fact. Whether xref entries exist outside the signed range is an arithmetic check. There is no ambiguity.

For signature removal: the PDF xref model records object lifecycle events. A free-entry slot where a signature object previously lived, combined with residual metadata that references it, is evidence that does not require interpretation. The object existed and was removed.

Neither pattern requires comparing the document against an external original. The file carries its own forensic record.

Integrating PDF digital signature chain fraud detection into a contract workflow

The check is a single API call. Upload the PDF to accessible storage (S3, Cloudflare R2, Google Cloud Storage — presigned URLs work), then submit the URL:

curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-storage.example.com/contracts/executed-agreement-2024.pdf"}'

The response comes back immediately with a check ID. Retrieve the full result:

curl https://api.htpbe.tech/v1/result/{check_id} \
  -H "Authorization: Bearer YOUR_API_KEY"

For a contract workflow, the fields to branch on are modifications_after_signature and signature_removed. Both being false on a signed document (where has_digital_signature: true) means the signed byte range covers the full document and no removal evidence was found:

interface SignatureCheckResult {
  status: 'intact' | 'modified' | 'inconclusive';
  modification_confidence: 'certain' | 'high' | 'none' | null;
  modification_markers: string[];
  has_digital_signature: boolean;
  modifications_after_signature: boolean;
  signature_removed: boolean;
  xref_count: number;
}

function assessSignedContract(result: SignatureCheckResult): 'valid' | 'tampered' | 'unsigned' | 'review' {
  // Certain-confidence tampering: reject immediately
  if (result.modifications_after_signature || result.signature_removed) {
    return 'tampered';
  }

  // Signed and structurally intact
  if (result.has_digital_signature && result.status === 'intact') {
    return 'valid';
  }

  // No signature present — escalate for manual review in a workflow
  // that expects signed documents
  if (!result.has_digital_signature) {
    return 'unsigned';
  }

  // Modified (high confidence) but no signature-specific markers
  // Producer mismatch, incremental updates without signature bypass, etc.
  return 'review';
}

Testing without real contracts

Test keys accept mock URLs that return deterministic responses. For signature-chain testing:

# Returns modifications_after_signature: true
https://api.htpbe.tech/v1/test/modified-medium.pdf

# Returns signature_removed: true
https://api.htpbe.tech/v1/test/signature-removed.pdf

Use these in your CI test suite to cover both certain-confidence branches without consuming production quota.

How this complements DocuSign and Adobe Sign validation

Platforms like DocuSign and Adobe Sign validate the signing certificate chain and timestamp integrity at the time of signing. That is a different layer from what HTPBE? checks.

DocuSign’s validation answers: “Was this document signed with a valid certificate at the claimed time?”

HTPBE?’s analysis answers: “Has this document been modified since it was signed, or has the signature been removed?”

These are complementary checks. A document can pass DocuSign certificate validation while still containing unsigned content appended after the fact — because DocuSign validates the byte range it signed, not the file as you receive it now.

The practical scenario where both layers matter: an executed agreement is downloaded from a signing platform, modified by one party (additional clause appended, a payment term changed via an incremental update), and re-submitted as the “final executed version.” DocuSign’s certificate is intact. HTPBE? surfaces the post-sign modification.

Limitations

Certificate trust validation is out of scope. HTPBE? does not validate that the signing certificate comes from a trusted CA, is within its validity period, or chains to a known root. That is the e-signature platform’s job. HTPBE? operates on structural evidence, not PKI.

LTV annotations are not flagged. Long-Term Validation (LTV) data — certificate revocation records, timestamp tokens — is legitimately appended to signed PDFs after the signing event. HTPBE? accounts for this and does not flag LTV appends as modifications after signature.

Counter-signatures on the same byte range. A workflow where a second party adds their signature to an already-signed document creates a valid multi-signature PDF with an incremental update. HTPBE? distinguishes this from content modification because the appended xref section contains a new signature object, not arbitrary content changes. This is treated as intact.

Clean removal with full file rewrite. If an attacker takes a signed PDF and rewrites the entire file from scratch — rebuilding the xref table from scratch, regenerating all object streams, and removing all structural traces of the signature — the ghost-info scan may not surface residual evidence. This requires deliberate, expert-level counter-forensic work and is not the profile of typical contract fraud.

Who should use this check

This check is most relevant for teams that receive executed contracts, certified documents, or signed legal agreements from counterparties and need to check post-receipt integrity.

Specific workflows where it applies:

Legal operations and contract management platforms — checking that executed agreements received from opposing counsel or vendors match what was sent for signing. See how HTPBE? integrates into legal contract workflows.

Financial services compliance — loan agreements, insurance policy documents, and disclosure forms often carry digital signatures. A compliance audit that includes structural fraud detection of signed documents catches tampering that certificate validation alone misses.

M&A and due diligence workflows — document rooms accumulate hundreds of executed agreements. Running batch checks through the PDF signature fraud detection API surfaces any that were modified after signing before they influence deal terms.

E-signature platform integrations — if you build on top of DocuSign or Adobe Sign and store executed documents in your own system, adding a structural check at the point of storage creates an immutable forensic record for each document from the moment it enters your custody.

The check is fast enough to run synchronously at document intake: average analysis time is under three seconds for contracts up to 10 MB.