Challenge

One week before my demo at the Black Hat Arsenal I released a peepdf challenge. The idea was solving the challenge using just peepdf, of course ;) This post will tell you how to solve the challenge so if you want to try by yourself (you should!) STOP READING HERE! The PDF file can be downloaded from here and it is not harmful. No shellcodes, no exploits, no kitten killed. In summary, you can open it with no fear, but do it with a version of Adobe Reader prior to XI ;)

Let's start! :) This is what you see with the last version of peepdf:

In a quick look you can spot some Javascript code located in object 13 and also an embedded file in the same object. Checking the references to this object and some info about it we see that it is an embedded PDF file:

In one week I will be traveling to Las Vegas to show how peepdf works in the Black Hat USA Arsenal. My time slot will be on Wednesday the 5th from 15:30 to 18:00, so you are more than welcome to come by and say hi, ask questions or just talk to me. I will also be presenting some of the work Rohit Dua is doing during the Google Summer of Code (GSoC), adding a scoring system for peepdf.

After the "useless" analysis of the fake objects now we can focus on the objects which will be parsed by the PDF reader:

/Catalog (27)
    dictionary (28)
        dictionary (22)
            dictionary (23)
                dictionary (22)
                /Annot (24)
                    dictionary (23)
                    /Page (25)
                        /Pages (26)
                            /Page (25)
        stream (21)
    /Pages (26)

If we take a look at the Catalog object...

PPDF> object 27

<< /AcroForm 28 0 R
/MarkInfo << /Marked true >>
/Pages 26 0 R
/Type /Catalog
/Lang en-us
/PageMode /UseAttachments >>

There is no presence of any triggers here (/OpenAction) or in the rest of the objects (/AA) so it seems that the /AcroForm element has something to say. Also, the suspicious object 21 (/EmbeddedFile) is related with this interactive form:

PPDF> references to 21

[28]

PPDF> object 28

<< /DA /Helv 0 Tf 0 g
/Fields [ 22 0 R ]
/XFA [ template 21 0 R ] >>

In the dictionary of the form we can see that object 21 is a template and that there is a reference to a field object (object 22). So we continue analysing the field objects:

PPDF> object 22

<< /V

If we launch peepdf we obtain this error:

$ ./peepdf.py -i fcexploit.pdf

Error: parsing indirect object!!

$ ./peepdf.py -fi fcexploit.pdf

File: fcexploit.pdf
MD5: 659cf4c6baa87b082227540047538c2a
Size: 25169 bytes
Version: 1.3
Binary: True
Linearized: False
Encrypted: False
Updates: 0
Objects: 18
Streams: 5
Comments: 0
Errors: 2

Version 0:
	Catalog: 27
	Info: 11
	Objects (18): [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 22, 23, 24, 25, 26, 27, 28]
		Errors (1): [11]
	Streams (5): [5, 7, 9, 10, 11]
		Encoded (4): [5, 7, 9, 10]
	Objects with JS code (1): [5]
	Suspicious elements:
		/AcroForm: [27]
		/OpenAction: [1]
		/JS: [4]
		/JavaScript: [4]
		getAnnots (CVE-2009-1492): [5]

Now we can see some statistics and information about the document. We can see some errors too, proof that it's not a normal PDF file: