I am trying to understand how PDF objects are encoded.
Example - PDF doc with 1 page of text in english has following objects (this PDF was created using PDFLaTex tool):
obj 3 0
obj 8 0
obj 11 0
obj 5 0
obj 12 0
Could someone explain me the concept behind the object ID generation, it doesn't have an order and I am not able to figure out the concept behind it.
Related
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.
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/
%PDF-1.7
4 0 obj
<</Type/ObjStm/N 3/First 14/Length 139>>
stream
1 0 2 41 3 76 <</Type/Catalog/Version/1.7/Pages 2 0 R>><</Type/Pages/Kids[3 0 R]/Count 1>><</Type/Page/MediaBox[0 0 200 200]/Parent 2 0 R>>
endstream
endobj
5 0 obj
<<
/Root 1 0 R
/ID[<7F1FE2C507E6DB4CB0787E660F2B0C65><2450E4E8FF5FC84380428886C0DD4C2F>]
/Size 6
/Index[1 5]
/W[1 4 1]
/Type/XRef
/Length 68
/Filter[/ASCIIHexDecode]
>>
stream
020000000400
020000000401
020000000402
010000000A00
01000000E500
endstream
endobj
startxref
229
%%EOF
The PDF above opens in Chrome (or Edge), but in Adobe Acrobat (Reader) it crashes. Ghostscript regards it as fine too. Note that it assumes CRLF for line breaks.
I read the parts of the PDF spec that are relevant for a basic PDF, and it seems that the above syntax follows it. Why doesn't Adobe like it?
Here is a link to the PDF. Notice how it opens in Chrome, but crashes in Adobe Acrobat. (This PDF uses LF for line breaks, and has a Resources dictionary on the page, based on the comments.)
Acrobat has the following 2 quirks, both of which do not follow the specs:
If the XRef Stream has a single filter, an array must not be used. So /Filter[/FlateDecode] won't work, and /Filter/FlateDecode will. This may apply to any Stream Object, not sure.
An XRef Stream must use the FlateDecode filter. ASCIIHexDecode won't work. A predictor is not required.
Here is a link to the above PDF, fixed up for Acrobat.
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.
I try to (programmatically) write the page numbers to all pages in a PDF file.
The object I use to write looks like this:
493 0 obj
<</Length 96>>
stream
Q
/2 12 Tf
/DeviceRGB cs
0 0 0 scn
q
1 0 -0 1 298 32 cm
BT
1 0 0 1 -3.6 1.884 Tm
(2) Tj
ET
Q
endstream
endobj
It worked fine, until I tried to do it on a page which uses the flag "/rotate" :
23 0 obj
<</Parent 2 0 R /Rotate 180 /Contents [492 0 R 24 0 R 493 0 R ] ... >>
...
When tried to do so, the number I wrote came upside down (and in the top of the page instead of bottom).
I read about this in the PDF manual, and found I can use the annotation flags, indicating I want the written number to be fixed, and not effected by page rotation.
For that, I tried to add to the 493 obj dictionary the corresponding flag (NoRotate):
493 0 obj
<</Length 96 /F 16>>
stream
...
The only thing that actually happens is that the number I try to write doesn't show at all.
I tried to load different numbers into the "/F", but they all lead to an invisible number.
I tried to look for examples in the manual and over the net, but didn't find.
What am I doing wrong?
Maybe I place the "/F" in the wrong location??
According to Adobe's PDF Reference v1.7 (link to PDF), 8.4.2 Annotation Flags, the flag /F only applies to annotations -- objects with a /Type of /Annot, and appearing in a PDF as sticky notes, text edits, and clickable rectangles.
It seems you have to provide the rotation yourself, using the Tm operator.