PDF Signature: "Expected a dict object" - pdf

I'm creating a library for digitally signing a PDF document. During my quest I stumbled upon an other problem.
In Acrobat I'm getting the error:
Error during signature verification.
Adobe Acrobat error.
Expected a dict object.
I know it expects a dictionary object somewhere. But I have no idea where.
This problem shows up when I add the image to the AP of the signature.
For this I'm basing my implementation on the spec, and " Insert multiple digital approval signatures without invalidating the previous one "
Most of this seems to work correctly, but when the image is present it results in the error. The image is correctly visible.
Current working:
(This is a very short overview of the part where the error is, it might be slightly different, but hope this helps)
I update the signature annotation. Add link to object that contains normal appearance.
16 0 obj
<<
/Type/Annot
/Subtype/Widget
...snip...
/AP<<
/N 21 0 R
>>
>>
Add image as XObject
20 0 obj
<<
/Type/XObject
/Subtype/Image
...snip...
/Length 29569
>>
stream
...snip...
endstream
endobj
Add XObject (Normal appearance)
21 0 obj
<<
/Type/XObject
/Subtype/Form
/Resources<<
/XObject<<
/UserSignature272 20 0 R
>>
>>
/BBox[0 0 135 37.5]
/Length 44
>>stream
q
135 0 0 37.5 0 0 cm
/UserSignature272 Do
Q
endstream
endobj
I think the problem happens somewhere in obj (21 0), but I'm not sure.
Here is a minimal file that can be used for testing.
https://drive.google.com/file/d/17sdz2xJy3VhN6i9YiuPrJ6x2s5kU2sra/view?usp=sharing
Any help, or hints would be welcome.
(This post is a continuation of PDF Digital Signature has "Bad parameter" in Acrobat, but is about a different problem, same subject area.)

You're running into a bug of Adobe Acrobat here: If you display a XObject from inside your signature appearance stream, it expects that XObject to have a Resources entry. This may make sense in case of form XObjects but it doesn't for image XObjects like in your case.
A work around is to add an empty Resources dictionary to your image XObject.
I checked this by replacing the /BBox[1 0 0 1 0 0] in your image XObject (which is not needed there anyways) by /Resources<< >>.
When Adobe Acrobat creates its own signature appearances, it creates a hierarchy of form XObjects here with Resource dictionaries all over including those for the "layers". I assume Adobe Reader, seeing the Do operator attempts to collect information on such "layers", not expecting to immediately be confronted with an image XObject.

Related

PAC2021 reports "Error while parsing the PDF document (Operator 'cm' is not allowed in this current state)" - but why?

I am using the PAC2021 application to analyze some PDFs for compliance towards the PDF/UA standards.
For some files (all generated by the software of my company) the following error is reported:
Error while parsing the PDF document (Operator 'cm' is not allowed in this current state)
There are no further explanations, just this phrase. An example of PDF page content that raises the above error is:
/P << /MCID 0 >> BDC
BT
0 g
1 0 0 1 81 639.75 cm
/F0 10 Tf
1 0 0 1 0 4.45 Tm
(Hello, world!) Tj
ET
EMC
Apparently PAC2021does not like the "cm" in the fourth line, but why?
I went through the documents of specifics for PDF and could not find an explanation on why this should be considered a syntax error. All PDF readers I have tried do not complain about such content, also I tried running the same document through Adobe Preflight for PDF/UA, it reported the document as fully compliant.
So I'm wondering: is this content violating a special restriction of the PDF/UA format? If so, where can I find its definition? Or is it an error in the PAC2021 report?

How to test ClamAV service for potential threats

As part of an enterprise software project, our application connects to an antivirus service backed by ClamAV, using ICAP as communication protocol. I would like to test the antivirus service response to malicious documents but, of course, I cannot use a document which is actually infected with something malicious. I found EICAR Anti Malware Testfile, but it only seems to come as either a .txt or a .zip and the system only allows upload of Word or PDF. The antivirus service only recognizes EICAR if it is send to it "as-is" but not when embedded inside a Word or PDF.
My question is: how can I create a Word and/or PDF document that is recognized by ClamAV as a threat despite it is actually not harmful at all?
I initially suggested
Since docx is a zip you could try rename eicar.zip as eicar.docx it proves only that a docx is reviewed/scanned similar to a zip, not that the AV can detect malicious VBA macros which would be a different payload.
However, the uploading step, involving Apache Tika file verification, blocked that simplistic approach, as the file type was not as expected.
My second suggestion was
Take a valid docx rename to zip drop the eicar text into it with explorer (or use zip add) and rename to docx as that's likely to bypass Tika checking.
Apparently that worked.
Likewise it should be possible to embed eicar.txt inside a PDF however detection again would not mean the av is scanning for JavaScript exploitation, just that the plain text signature is seen in a PDF file, thus only hints that a PDF is scanned.
This is more difficult due to PDF encryption, but with a hand crafted text file attachment in an editor, it may not be encoded, simply stored as plain text, sufficient basic for the eicar trigger to be seen.
It could look something like this but cut and pasting this binary shown as text will likely fail storage as eicar.pdf due to ansi line endings encoding. so grab a binary copy from link below
%PDF-1.4
%µ¶
1 0 obj
<</Pages 2 0 R/Type/Catalog>>
endobj
2 0 obj
<</Count 1/Kids[3 0 R]/Type/Pages>>
endobj
3 0 obj
<</Contents 4 0 R/MediaBox[0 0 500 800]/Parent 2 0 R/Resources<</Font<</F1 5 0 R>>>>/Type/Page>>
endobj
4 0 obj
<</Length 57>>
stream
q BT /F1 24 Tf 1 0 0 1 50 720 Tm (Hello World!) Tj ET Q
endstream
endobj
5 0 obj
<</BaseFont/Courier/Subtype/Type1/Type/Font>>
endobj
xref
0 6
0000000000 65536 f
0000000016 00000 n
0000000062 00000 n
0000000114 00000 n
0000000227 00000 n
0000000333 00000 n
trailer
<</Size 6/Root 1 0 R/ID[<89311A609A751F1666063E6962E79BD5><FDDAE606D8247DFCBA7D13E1833DEDE3>]>>
startxref
395
%%EOF
%X5O!P%#AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
%%EOF
temporarily available from https://gofile.io/d/53fylg should look like this
assuming your antivirus allows download :-) try save download as text otherwise I will need to upload as RAR
However those two "Positives" would be just as good a detection as telltales that any AV is searching those file types for current known exploits.
I recommend download the live script running version bottom of this article for deeper testing.
https://blog.didierstevens.com/2015/08/28/test-file-pdf-with-embedded-doc-dropping-eicar/

iText PDF fails with message "Dictionary key endstream is not a name"

The issue is the same as reported here.
I have taken this image and converted to this PDF using GraphicsMagick v1.3.26 (build on 2017-07-04):
gm convert itext_banner_InvalidPdfException.jpg itext_banner_InvalidPdfException.pdf
When I try to read it with iText v5.5.12 I get the following exception:
java -cp itextpdf-5.5.12.jar com.itextpdf.text.pdf.parser.PdfContentReaderTool itext_banner_InvalidPdfException.pdf
com.itextpdf.text.exceptions.InvalidPdfException: Rebuild failed: Dictionary key endstream is not a name. at file pointer 1197; Original message: Dictionary key endstream is not a name. at file pointer 1197
at com.itextpdf.text.pdf.PdfReader.readPdf(PdfReader.java:764)
at com.itextpdf.text.pdf.PdfReader.<init>(PdfReader.java:197)
at com.itextpdf.text.pdf.PdfReader.<init>(PdfReader.java:235)
at com.itextpdf.text.pdf.PdfReader.<init>(PdfReader.java:223)
at com.itextpdf.text.pdf.PdfReader.<init>(PdfReader.java:213)
at com.itextpdf.text.pdf.parser.PdfContentReaderTool.listContentStream(PdfContentReaderTool.java:200)
at com.itextpdf.text.pdf.parser.PdfContentReaderTool.main(PdfContentReaderTool.java:249)
Questions:
What exactly is wrong with given PDF? It seems like there is an issue in GhostScript which is used indirectly by GraphicsMagick.
When I open it with iText RUPS v5.8.8, it does not print any warnings to Console tab. Does it mean it is valid from iText RUPS point of view?
Your PDF contains this broken object:
11 0 obj
<<
endstream
endobj
The opening << is closed by a endstream. This does not match.
If that object was meant to be a mere dictionary, it should have looked like this:
11 0 obj
<<
[a reasonable number of dictionary entries]
>>
endobj
If that object was meant to be a stream, it should have looked like this:
11 0 obj
<<
[a reasonable number of dictionary entries]
>>
stream
[stream data]
endstream
endobj
BTW, the object in question is not referenced from any other object in the PDF. If you open the PDF in a PdfReader in partial mode, therefore, the issue will be ignored.

pdf, appearance streams, checkbox not shown correctly after focus lost

I'm working on a program generating interactive forms into PDF files.
The generated file is here (source is readable). The checkbox is on the bottom of the page. After it gets focus it is rendered correctly (white square with red/blue border), after it lose the focus the square disappears and the default appereance is shown (thats incorrect for me).
in Acrobat 9, X, XI
in build-in chrome pdf viewer it works fine
Adobe XI Pro - preflight - shows warning "Form field has multiple appearances"
I can not find the mistake.
Thanks for your help.
the same (similar) problem described there:
http://forums.adobe.com/message/5144579#5144579
---- here is a part of a pdf file I expect the mistake
2 0 obj
<<
/Type /Catalog
/Pages 1 0 R
/OutputIntents [7 0 R]
/Metadata 8 0 R
/PageLabels 10 0 R
/AcroForm 14 0 R
>>
endobj
14 0 obj
<<
/Fields [13 0 R]
>>
endobj
13 0 obj
<<
/Type /Annot
/Subtype /Widget
/Rect [20.0 20.0 120.0 120.0]
/FT /Btn
/F 4
/T (name)
/AS /Yes
/V /Yes
/AP <<
/N <<
/Yes 11 0 R
/Off 12 0 R >>
>>
>>
endobj
11 0 obj
<<
/Type /XObject
/SubType /Form
/BBox [20.0 20.0 120.0 120.0]
/Length 19 0 R
>>
stream
....
endstream
endobj
12 0 obj
<<
/Type /XObject
/SubType /Form
/BBox [20.0 20.0 120.0 120.0]
/Length 20 0 R
>>
stream
....
endstream
endobj
My observations with your PDF are somewhat different but interesting nonetheless:
Adobe Acrobat 9 Pro v9.5.4 (with PDF/A r/o view disabled) here does exactly what you originally seem to have expected: It only uses the red or blue framed box. If one toggled the check box, though, even if toggling back on again, it wants to save a new revision with some changes to your field.
Adobe Reader X! v11.0.2 starts in PDF/A read-only mode and displays the red frame. After leaving that r/o mode, though, it shows the default cross appearance. When it gets the focus it again uses the red and blued frames. When it loses focus, it goes back to the default appearances.
The behavior I observed in Adobe Reader X! seems to be what you observed in more cases.
Thus in essence the issue is that under certain circumstances (for me: not in PDF/A r/o mode, focus not on form field) some PDF vewers (for me: Adobe Reader XI) don't use your custom check box appearances but some standard ones, and you think that this is incorrect.
Unfortunately there is a hint in the PDF specification ISO 32000-1:2008 according to which viewers may (perhaps even shall) act just so. Table 189 in section 12.5.6.19 Widget Annotations explains the entries in an appearance characteristics dictionary (value of /MK in the widget dictionary; you do not provide one, thus defaults apply), among them /CA:
text string (Optional; button fields only) The widget annotation’s normal caption,
which shall be displayed when it is not interacting with the user.
Unlike the remaining entries listed in this Table, which apply only to
widget annotations associated with pushbutton fields (see Pushbuttons in
12.7.4.2, “Button Fields”), the CA entry may be used with any type of
button field, including check boxes (see Check Boxes in 12.7.4.2, “Button
Fields”) and radio buttons (Radio Buttons in 12.7.4.2, “Button Fields”).
In particular check boxes, therefore, whenever not interacting with the user, shall be displayed using their normal captions, not their appearances.
When there is no focus on a form field, Adobe Reader seems to think that the form is not interacting with the user, and therefore switches to display of caption instead of appearance.
Unfortunately the normal caption you can define for a button is but a text string which by default seems to be interpreted in the context of the Zapf Dingbats font (try /MK<</CA(1)>> for example). This is, though, where you should continue looking, maybe you can make it use some Type 3 font of your design containing a blue and a red square frame.

confirmation dialog (alert) after form submit

I was wondering if there is any way to notify a user in adobe reader
that a pdf form has been submitted to the server? I am submitting a
normal http/html form to a php script no big deal, straight forward,
but there seems to be a big "black hole" in documentation, forums etc.
as to what happens when the form is submitted.
Isn't there a way to trigger a javascript alert after I have submitted
a form?? I dont't want to return another pdf that says "thank you",
that is a bit tacky. I am very new to pdf forms so I am guessing there
must be a way to return FDF to the original document that has some
javascript in it that is executed eg alert('thank you for your
feedback!')..
This should really be straight forward, I assumed Adobes much hyped
PDF technology was much more developer freindly and accessible..
Any ideas?? (Oh and please don't ask why I am using pdf forms and not the web, this is coming from "The Top", so as a developer I just have to do it..)
The server script which you are posting to must reply with this content type in the HTTP header:
'Content-Type: application/vnd.fdf'
eg. If you are using PHP:
header('Content-Type: application/vnd.fdf')
followed by the relevant bastardized-pdf-javascript-mutant-half-bread that will trigger the alert() dialog.
%FDF-1.2
1 0 obj
<<
/FDF
<<
/JavaScript
<<
/Doc 2 0 R
/After (confirmSend();)
>>
>>
>>
endobj
2 0 obj
[
(confirmSend) 3 0 R
]
endobj
3 0 obj
<<
>>
stream
function confirmSend()
{
app.alert({
cTitle : 'title of the window',
cMsg : 'message',
nIcon : 3
});
}
endstream
endobj
trailer
<<
/Root 1 0 R
>>
%%EOF
I hope you receive this message, as I wasted nearly 2 weeks of my life finding a solution...
Thanks for this! I too have been searching for a solution to this for hours! It was extremely frustrating. It seems like overkill to install the FDF Toolkit just to get a simple confirmation dialog box after the PDF has been submitted.
I eventually came up with the following through trial and error (it seems there is absolutely no documentation about this on the net):
%FDF-1.2
%âãÏÓ
1 0 obj
<<
/FDF
<<
/Status(Thank you. Your details have been submitted and someone will get in touch with regarding your application.)
>>
>>
endobj
trailer
<</Root 1 0 R>>
%%EOF
The above will present (or should present) a dialog box in Adobe Reader without showing the "Warning: JavaScript Window" warning.
Hope this ends up being useful to someone.
I wrangled with this for days, trying to figure out why when I sent the FDF using response.write, it just wouldn't display in Reader. I tried sending both hand-crafted FDF and installing the FDF toolkit to create the FDF response. I was able to create valid FDF, as I was able to open locally in Reader and have the pop-up display correctly but I couldn't get it to work for the life of me sending FDF from my ASP.NET page.
Then inspiration struck. In one of my attempts to send the FDF, I stored the FDF in a file and tried to use a streamreader to pump it into the response. After many unsuccessful attempts to use response.write, on a whim I tried response.redirect to the saved fdf file and it worked. I had previously added fdf as a registered MIME extension for my web site, with application/vnd.fdf as the MIME type. Now the user receives the pop-up after successful submission. The simple solution, in C#, looks like this:
Page.Response.Redirect("success.fdf");
I managed to happen upon the answer after 3 days of searching, adding a header for fdf file in the php script, adding '#FDF' to the end of the url in acrobat seems to have been the solution;
%FDF-1.2
1 0 obj
<<
/FDF
<<
/JavaScript
<<
/Doc 2 0 R
/After (confirmSend();)
>
>
>
endobj
2 0 obj
[
(confirmSend) 3 0 R
]
endobj
3 0 obj
<<
>
stream
function confirmSend()
{
app.alert("The form has been successfully submitted\nThank you for your feedback!", 3);
}
endstream
endobj
trailer
<<
/Root 1 0 R
>
%%EOF