I have started to work on the pdf crack +ORC asked us. I downloaded
http://www.adobe.com/supportservice/devrelations/PDFS/TN/PDFSPEC.PDF
file which is a detailed description of the pdf format, so not much
cracking on that. (Some of us might start to write the txt -> pdf 
converter based on the specs.)
After reading the security specs I got the next preliminary
conclusions:

Whether the menubar, toolbar of the reader is present when you open
a document is not connected to the security, its controlled by  
boolean variables HideMenuBar, HideToolBar in the Viewer Preferences 
section of the file. You can change the true settings to false and
they appear when you open the file. Be careful though not to change
the lenght of the file when you change the text (you have enough space
there fortunatelly), because the file lenght is linked to the security 
heavily.

The restrictions what can be done with a file is contained in the P 
variable of the Filter section. Its an unsigned word value certain
bits representing the writing, copying printing permissions of the
user. You can not change this value to eliminate the restrictions
because all text and picture data of the file (but not the file
itself) is encoded by the RSA algorithm using a key provided by
a hash function from a random file ID, the userkey, the permission
value etc. This means that if we change permission value the text
and data cannot be decoded correctly. (The reader complains of
corrupted file, tries to fix it etc.) Therefore, we must let the
program to decode the text with the original permission value
and patch the program to set itself up with a "let him do everything"
value later on.

I got all this info only by reading the specs and setting values in
the pdf files. Now I try to find the part of the program where he sets
itself up according to the permission value. BTW the acrobat reader 
(being only a reader) does not allow modifying a document 
independently of the permission value which means this restriction
is logically hard coded in it.

I wrote this to inform you in which direction I am going with this 
project and to facilitate quick exchange of information to spare
some work for all of us.

bye
Zer0+ 
      

Here I send, as promised, a polished version of the Acrobat reader
patch which enables to select and copy parts of a document
independently of Adobe security settings.
I do not want to repeat here how the whole encryption is working
in  a PDF document (you can find that in the PDF specs from
Adobe or understand it reading the many essays inside +HCU's 
pdf-project), so I just point out the most important things.

- If a PDF document is encrypted by using the Standard security
handler the P key containes the permissions which are granted
when the document is opened with the user password. Its a word
value, FFFC meaning you are allowed to do everything, FFC0 means
you can=B4t touch the document.

- You can't just rewrite this value in the document because it
is used for generating the key which is used to encrypt the
document (check the specs for details.)

- However, here is a note from the PDF specs:

"Despite the specification of document permissions in a PDF file,
PDF cannot enforce the restrictions specified. It is up to the
implementors of PDF viewers to respect the intent of the document
creator by limiting access to an encrypted PDF file according to
the permissions and passwords contained in the file."

This means that a reader can ignore the permission settings.
Unfortunately, this nice feature is missing from Acrobat Reader
so we have to work a bit.

Target: Adobe Acrobat Reader 3.00   2 263 552 bytes

Our main aim is to find the place of the program where the
permission value can be modified to let us do everything without
affecting the decryption of the document.

What I did was: set a break point on kernel _lread to monitor
the file access, if the P value was read into memory breakpoint
set break point on its memory position and see where the program
touches it. This way I got to code at 47D50D where the program
starts to parse it, at 4CDF3D it converts the string to word
value and later puts it at the 26C position of a structure
at 442844 MOV [ECX+0000026C], EAX. This was an effective, but
long and boring way to find this position. Now looking back
I could have found it by searching the dead listing for the
value FFFC (remember this is the let everything to do value
which is used when there is no protection) the program sure
moves it into [ECX+0000026C] a few times. Well, this means
I am still quite a way from being a ZEN cracker :( and once
again proves the words of the great Dave Mustaine "Hindsight
is always 20-20" :)

Now that we have this position we can see what the program
is doing with it. It takes the value at 442CB8 for generating
the decryption key and at 4430E5 it copies it to position
20C and used for setting the permissions. I wanted to fiddle
with the permission settings as far as possible from the
decryption part so I followed it till 480A62 where it moved
to [esi+78] position. Actually the value has been transformed
a bit high order byte to 7F and low order byte incremented
by 1 so the desired value at this position is 7FFD instead
of FFFC. It seems the program is not moving it any further
so we have to patch here to move 7FFD into [esi+78].

This enables selecting text and pictures from any document
and printing it. If you check the security settings menu
point you will see the original settings because the
program reads the 26C position which we have not changed
to present the settings. If you want to change that you
can fiddle with one of the few instructions which reads
[reg+0000026C], but I actually forgot which one. I myself
prefer not to change it, this way I can check what kind of
permissions the author originally set for us :)

One last thing: the author of the pdf document can set
whether the menubar toolbar and windowUI is displayed
when a document is opened. This is controlled by the
HideToolBar, HideMenuBar and HideWindowUI flags in the
ViewerPreferences dictionary. We of course want to have
these goodies always on (which is the default value) so
can destroy the reference to these flags so the program
cannot recognise them. Therefore search these strings in
the reader exe file and change one letter in them. Now the
program cannot parse these settings in the PDF file 'correctly' 
anymore so we always have the goodies on.

PS: I think now I'll move on to a deeper analyse of the 
pdf standard encryption handler and I will write a small 
utility to get the user and owner password of a document 
(if I can). 
I am just curious what could be the owner password of the 
Ghiribizzo files :)

Zer0+

Back to the PDF-Project

---

homepage links anonymity +ORC students' essays Academy database
tools cocktails antismut CGI-scripts search_forms mail_Fravia
Is reverse engineering illegal?