Okay so i have a file i'm trying to crack, its a pdf to jpg program and it was packed with UPX 2.00, so i used upx.exe from sourceforge to unpack it, it unpacked fine and ran fine afterwards. Its a basic nag for serial sort of thing but when i open it in Olly i get the message "Module 'PDF' has entry point outside the code (as specified in the PE header). Maybe this file is self-extracting or self-modifying. Please keep it in mind when setting breakpoints!" which i remember seems to be the message i get when i have a packed file so i checked it in PEiD just to be sure and it sait that its written in Microsoft visual C++ 6.0 so it is unpacked right? so i open it in Olly again, and debug past the nag and find a way to patch the registration but when i try to "Copy to executable" it says "Unable to locate data in executable file" and then crashes... does anyone know what the problem is?

i also tried finding the section of code i needed to patch in a hex editor and the code is different (the code i'm patching is a basic conditional jump in the registration scheme[i couldn't find the serial but i didnt look very hard so i may try that])... but the code in the hex editor at the same offset doesnt have any likeness to the code i was trying to patch...

cheers to anyone who can help me,
Jamey

p.s. i did search but only found stuff on unpacking upx not problems after...

=]

For starters, the file may be packed or crypted twice: You unpacked the trivial UPX, but the resulting file, which I assume is the one you traced in Olly, still has all the symptoms of a packed executable, which you described already.

PEID is not perfect, the fact that it says VC 6.0 is not the final word. Try other packer detection tools, search the board and the tool repositories for them.

It may well also happen that the packer is home made and no tool identifies it.
No problem. find tutorials on manual unpacking and/or the use of a loader that can patch your app in memory after it unpacks itself (Lena's tuts are great for these topics).

oh, cheers, i didnt actualli think that it'd be packed twice but yes it makes sence thanks loads, i'll search and if that doesnt work i'll scour lena's tutes (i have already found them very useful, i'm currently working through the reversing with lena series of tutorials)... cheers much for the help,

Jamey

It might as well be a custom "internal" (i.e. not an externally applied packer/crypter on the pre-compiled executable) protection too (although the initial Olly message speaks against this, but I guess that could just be a remnant of the file once being packed too).

If the code you want to patch is inside the range of the PE file's static sections, just dump the exe from memory and compare it to the original, to see exactly which parts of it is crypted.

Use "entropy check" feature of PEiD for a more positive identification -- in my experience, anything above 7 is packed, and below is not. Or you could load the file in a text editor with binary wrap mode and look at the "texture" of the code; packed files look more like compressed data, while unpacked executables will show nearly regular patterns. Compare e.g. a normal notepad.exe and a UPX-packed notepad.exe to see the difference.

I've seen the "entry outside of code" warning before, and in many cases it's false. OllyDbg is reading some unused fields in the PE header (size of code/size of data) which is completely ignored by the loader.
That feature is a kludge at best; it is recommended to not use it and instead use a hex editor (*after* noting down the area in need of change and closing, as the file is locked when loaded in the memory). There is a plethora of problems involved with trying to copy "live" code into a file that I won't elaborate on.

You could be confusing virtual addresses with file offsets. A better way would be, as alluded to above, record the sequence of bytes (5-10 should be enough) at the critical location, and search for those in the hex editor. One more thing, if you haven't done so make sure the file has no relocs and strip them if necessary.

I am fairly surprised of such a failure from PeID. It happens often that it does not recognize something, and in that case the generic enthropy check are usually good enough, but a false identification never happened to me.
To identify the possible second layer of protection, you may want to check the section names... That is usually a good source of information Also, a quick look at the code around the the EP will help you. VC-compiled executables features the standard prologue.