Adding LTV in signature makes pdf invalid using C#

隐身守侯 提交于 2019-12-02 07:23:49

There is an error in the cross reference table of the original PDF. Adobe signature validation is known to be sensitive to such errors (see this answer and this answer), under certain circumstances it shows signatures of such files as invalid.

You should ask the source of that document to provide a version without that error

The details

The cross reference table of the first, unsigned revision of the document looks like this:

xref
0 55
0000000000 65535 f
0000000018 00000 n
0000000164 00000 n
0000000216 00000 n
0000000554 00000 n
0000003363 00000 n
0000003529 00000 n
0000003764 00000 n
0000003815 00000 n
0000003866 00000 n
0000004038 00000 n
0000004279 00000 n
0000004439 00000 n
0000004662 00000 n
0000004792 00000 n
0000004818 00000 n
0000004991 00000 n
0000005061 00000 n
0000005297 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000005466 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000006188 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000006236 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
0000000000 00000 n
54 18
0000006284 00000 n
0000006350 00000 n
0000006648 00000 n
0000171077 00000 n
0000171435 00000 n
0000171726 00000 n
0000171973 00000 n
0000323100 00000 n
0000323123 00000 n
0000324290 00000 n
0000324333 00000 n
0000324715 00000 n
0000326153 00000 n
0000328056 00000 n
0000328093 00000 n
0000328132 00000 n
0000328214 00000 n
0000328377 00000 n

As you see it consists of two subsections, the first one for 55 objects starting at 0, the second one of 18 objects starting at 54.

This is invalid for two reasons:

  • First of all (as already has been explained in the two answers referenced above) the cross reference table of the initial PDF revision must consist of a single section only!

    For a file that has never been incrementally updated, the cross-reference section shall contain only one subsection, whose object numbering begins at 0.

    (ISO 32000-1 and ISO 32000-2, in both cases section 7.5.4 "Cross-Reference Table")

  • Furthermore, that cross reference table has two entries for the same object, both the last entry of the first subsection and the first entry of the second subsection relate to object 54. This also is forbidden:

    A given object number shall not have an entry in more than one subsection within a single section.

    (ibidem)

Depending on details of the respective code this may or may not result in arbitrary problems when processing the PDF with some PDF processor, e.g. Adobe Acrobat Reader.

Your edit

In your edit you shared a number of files. In particular you shared

According to your code you apply all changes in append mode. Thus, the three latter files each have to consist of the first file VeriFinger_SDK_Brochure_2017-12-27.pdf plus some appended data. But that is not the case, the three latter files actually all are shorter than the first one. Thus, I have to assume that that first file is first processed somehow and then signed.

Now looking at the cross reference table of the "original file" VeriFinger_SDK_Brochure_2017-12-27.pdf (simply open it in a text viewer and scroll to its end) we see it is in one piece, just a single subsection. It contains a number of entries marked as free but no gaps.

Looking at the cross reference tables of the first revisions of the latter three files, though, we see that each of them is split into multiple subsections. Apparently runs of entries marked free have been cut out of the table resulting in a table with many subsections. Probably this has been designed as an optimization attempt but the result is a damaged PDF.

Thus, whatever PDF processor it is which you apply to your files before signing, exactly that processor damages the PDF.

The PDF processor that damages the PDF

Comparing the document information of your original file and the initial revisions in the other three files, a PDF processor handling the file before it is signed appears to be Aspose.PDF for .NET 19.1 because the Producer value is changed to that.

And indeed, this appears to be a known Aspose issue, see for example the PDF/A-1 conversion creates invalid XRef table thread on the Aspose free support forum, started in August 2016.

It has been filed as PDFNET-41272 and marked as fixed in Aspose.Pdf for .NET 17.2.0 in February 2017, but as reported on that very forum thread in the same month, it was not really fixed at all.

Apparently Aspose has not yet fixed this bug and still is working on it.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!