damaged document repaired by Adobe

[mauriciov51614002]

I have a signed document, but Adobe indicates that the byterange is invalid. This is because the document has a structural error, which Adobe fixes in memory, causing the byterange to not match. I had the same problem in a previous document, and it was due to missing spaces in the Xref lines, but in this case, I haven't been able to find the problem.

Any recommendations on what it could be, or what tool I could use to analyze it that would be more specific about the error, since I've tried Acrobat and QPDF without success

[Tariq Ahmad Dar]

Hi @mauriciov51614002

Thank you for reaching out and for your detailed explanation.

The error “ByteRange is invalid” typically points to one or more of the following:

Common Causes:

1. Post-signing modification – Any change, even whitespace or metadata updates, after signing can break the ByteRange.

2. Structural corruption – As you mentioned, malformed XRef tables or missing line breaks can cause Acrobat to “repair” the file in memory, invalidating the signature.

3. Incorrectly generated PDFs – Some third-party tools generate PDFs that don’t fully adhere to the ISO 32000 standard, causing validation issues.

You may try:

• If you have the original unsigned PDF, re-sign it using Acrobat or a known-good signing tool.

Unfortunately, once a signed document’s ByteRange is corrupted, the signature is no longer cryptographically valid, even if the content seems visually unchanged.

~Tariq

[mauriciov51614002]

I understand. The signature itself is not a problem and is valid, because the same algorithm signs other documents correctly. What there is, however, is a problem in the structure of the objects added during the signing process, and that's what I haven't been able to find.
As I mentioned earlier, I had a problem with the spaces and sizes of the reference table, and once I resolved this, the signature was validated correctly. In this example, I analyzed each object but couldn't find the error.

[MikelKlink · Accepted solution]

The problem leaping to my eye is that the incremental update with the signature uses cross reference tables while the initial document revision uses a pure cross reference streams.

While the PDF specification does not explicitly require the cross reference type in incremental updates to be the same as in the initial version, Leonard Rosenthol of Adobe has again and again made quite clear that Adobe Acrobat does not support such a switch, see the PDF association PDF issue 523. Also one may argue that such a requirement is implied in the PDF spec.

According to that issue a clarification is discussed that forbids going from stream to table and that recommends against going from table to stream.

---

Another problem in your PDF: The initial revision has cross reference entries for object numbers 0..7 and your incremental update has cross reference entries for object numbers 0, 1, 3, and 12..16. Thus, there are no entries for object numbers 8..11. This violates the PDF spec which explicitly requires there to be a cross reference entry for every object number from 0 to Size-1.

[mauriciov51614002]

Thanks for that observation. I modified the algorithm so it doesn't mix up XREF types, and now the signatures are valid!

[MikelKlink]

Great!

Please be aware, though, that there is an issue in your cross reference stream: According to the PDF spec, a PDF object containing a cross reference stream must also have a cross reference entry. But your cross reference stream has object number 17 while it (and the previous cross reference stream of the initial revision) contain no entries for object numbers larger than 16. There are contexts in which this causes issues.