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?