Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
How can I read the original PE sesctions?
For example, before UPX:
I use the JclPeImage.pas unit (Delphi) for reading the sections from memory (base address = $400000). Can I reach the unpacked sections by using some kind of offset?
Yes, the original PE header + section data is stored in the compressed file. You can possibly find the section data by searching for the string ".text" in the memory.
But can't it be set by UPX in the header after decompressing? Searching in memory is not that straightforward.
Or even better: is it possible to make it fully "transparant"? So after decompressing the memory content is the same (or almost) as normal (rebuilding the section headers etc).
What I want is getting the JCLDEBUG section. But now it is hidden, because the header only shows the UPX0 and UPX1 sections. So, from the application point of view, the state of the UPX exe is different than without UPX. Like in my case: my exe works different because it can't find some manual defined sections. So the UPX compressing is not "transparant"…
Hmmm, I hoped I could access the original header using the "Size of Uninitialized Data" offset, or "0x1000" in front of "Base of Code", so address " 0xaf000" (see below).
But I think the original header is not unpacked at all, right? Is it possible though to add this functionality in a new version? Please?! It would help me very much!
Base of Code, 0xb0000
Entry Point RVA, 0x10c880
Magic, PE32 (0x10b)
Preferred Image Base, 0x400000
Size of Code, 0x5d000
Size of Headers, 0x1000
Size of Image, 0x110000
Size of Initialized Data, 0x3000
Size of Uninitialized Data, 0xaf000
I think it's not safe to copy the original header back because of DEP (data execution prevention). I also think that searching the memory for some string should be easy enough. Also please note, that UPX never promised 100% transparent (de)compression - there are programs which want to mess with their own image in ways which just can't be supported.
But is it possible to copy the header in front of the new "Base of Code"?
In my previous post it is changed from originally 0x1000 to 0xb0000. If it can be added before that, it would be great!
So, original header at offset 0xb0000, base of code at 0xb0000+0x1000 = 0xb1000.
It gives a bit more overhead and bit bigger compressed exe, so if it is conditional via a new compress parameter, it is OK for me (and my customer).
I don't know if overwriting the header and 100% transparancy is possible at all, but it would just be great :-).
By the way: searching memory is the last option I want to use:
- not very elegant, brute force method
- not very save: for example JCLDEBUG also exists as string constant
So what kind of data do you need from the section header JCLDEBUG? An offset and a size? Why don't you simply store those data in the name of the new section headers? I mean, just change the string of "UPX0\x00" to "0\x00" then you will have 6 bytes of free data to store some information. Similarly for "UPX1".
By the way, copying data before the "base of code" will trigger DEP. So it's not safe.
Yes, at least the offset.
But do you mean with "change the string of UPX0" that I have to change the UPX source?
Not very elegant of course, but is that easy to do?
Wait, what about making an UPX2 section, which contains the original header? I would prefer that above hacking some custom stuff in section names. Is that easy to do?
Changing the source of UPX is the last thing you and me want to do ;-) It's tricky to do correctly and you never know when the next version of UPX will be released (Markus is the one who decides).
Anyway, it's not needed to change the source of UPX for this. You would only have to create 2 small utilities. The first one would read the offset of your section from the uncompressed exe. Then you compress the file. Then the second utility would write the saved data into the compressed exe.
I'm not familiar with compiler/linker magics in windows, but isn't it possible to define a normal pointer which points to the beginning of your section? Using some kind of pragma for example?
JCLDEBUG section is added after compilation using a JCL tool, which is open source, so I have a working demo how to add a section to a exe file :-). Should not be very difficult to do, and I can use that extra tool in our FinalBuilder server on our exe file when it gets build. Sound OK. thanks!
But can Markus put this functionality to UPX as default functionality, so other people can use their original header too?
Be careful with adding a new section to the UPX compressed file. Some tool may corrupt the target file.
Markus is the one who releases the new versions of UPX, but I'm the one responsible for the win32/pe format. And I still think that restoring the original PE header is not safe.
The JCL tool does not corrupt a normal exe, so I think it also won't on a compressed exe. But of course I will test that first! :-)
I will not restore the PE, just add it in a new section (UPXH).
Btw, is the complete exe compressed, or are also some sections stripped (like .reloc?). What I mean: can I use the offset in the original header (in my new section) to get the address of the sections after decompression?
The PE header is completely rebuilt. You may, or may not have enough space for a new section header in the compressed executable.
Well, You need to unpack, so you can revert the compressed data to original stream before use of UPX.
One option is to visite the site http://upx.sourceforge.net/ and download the source code of UPX and study the code, but I think hard to use the code with your program because the time to learn how the UPX works. Other option: when you identifies UPX0 section on .exe, you so call UPX to revert the pack (see comand line options to upx) and get the original file exe. So you can read the unpacked original file with the sections .text .itext… rsrc.
But, there is one important information: in this case, the UPX is an APP that only compact with LZMA compression, so is possible unpack; some apps pack the exe with passwords and cript ways, in this other case is impossible to you get access to protected resources inside exe.