Hi,

I am creating a program that would extract resources from PE files. The resource format is definitely different in compressed PE and I need a way to detect them. If they are not error handled, the program would sure to crash when reading the resources (pointer error). Thanks in advance.

Ewayne had pointed out to me that UPX files can be detected by the sections named '0XPU' and '1XPU'. I am just curious about other compressed PE files.
Posted on 2002-12-11 07:58:56 by roticv
a way is to check for packer signature (same as antivirus programs) or to have a short analysis from OEP.
you can try also StudPE - PE Viewer/Editor/Resource dump/... that has a nice feature to see each PE item where it is in the file (for learning PE structure).

you cannot dump resources that are compressed unless that you unpack the program and the dump the resource (a generic unpacker is needed - wich is hard to write and also doesnt work 1oo%).

hope it helps somehow ;)
Posted on 2002-12-11 08:18:46 by TBD
roticv

Try to check couple of section and compare the Raw Size and Virtual Size of each. If there is significatn difference, this may (not always) be compressed exe.
Though resource section may stay in uncompressed state, if not - better skip it.
Posted on 2002-12-12 02:44:40 by masquer
I was thinking of skip reading the resources of the compressed PE files.
Posted on 2002-12-12 03:05:53 by roticv
There is a lot of variation between PE packers and using things like signatures is very unreliable as many don't use them.

I agree with masquer that you need to look at the section sizes as this often indicates a compressed file. If you are really serious, you will track what happens for the first section which is where the stub to unpack the file is stored.

The basics are that the OS loader can load it so there is a way to work out what it does, its just that you may have to do a lot of work to get it going properly.

Regards,

hutch@movsd.com
Posted on 2002-12-12 04:34:35 by hutch--
Often the entrypoint of the compressed/protected PE file is replaced. Alot of packers adds a section at the end of file and changes the entrypoint in the header to this section.

Assuming that most real untouched files are having a entrypoint in it's first section which is almost allways code section you can check in which
section the entrypoint points to and thereby see if there is anything unusual about it.

If I remember correct Aspack looks like this:


.text
.data
.rdata
... <- rest of the real sections
.adata <- appended section

I think by doing such a check you could detect alot of files. If the file is virus infected some viruses places a loader into the first section by replacing real code and then jump later to the last section where the real virus loader is stored. In such cases a detection won't work but I'd say it's also a special case.

I hope this helps.

// CyberHeg
Posted on 2002-12-12 04:56:30 by CyberHeg
CyberHeg

Often the entrypoint of the compressed/protected PE file is replaced. Alot of packers adds a section at the end of file and changes the entrypoint in the header to this section.


Interesting, how you can find OEP with only knowlege that it's replaced. About last section, some of "smart" AV thinks if entry point is within last section - it is maybe a virus.
Some of packer/protectors erase most of sections, change section name and do another tricks to hide original data. So, it is better do not wasting time with those files.
Posted on 2002-12-12 05:15:39 by masquer
Sorry to bring up this old thread.

Can someone explain to mean by significant difference between virtualsize and rawsize. How much do you mean by significant? 100h?
Posted on 2003-04-02 23:01:28 by roticv
Roticv,

The virtual size is the real size (in bytes) of a section;the size of raw data
is the size of sect. aligned to 200h (section alignment)

Iczelion's msgbox examined with PE tut. example #5
Posted on 2003-04-03 03:09:43 by Vortex
Apparently not I suppose.

The file is a uncompressed and unpacked exe. It seemed that its .idata and .data does not apply to the rule on the aligning to 200h
Posted on 2003-04-03 03:39:37 by roticv
Roticv,

Read carefully the raw size (=size of raw data) values:

2B600h/200h=15Bh
7C00h/200h=3Eh
2000h/200h=10h
A000h/200h=50h

All the results are integer.So,the size of raw data is aligned to 200h
Posted on 2003-04-03 04:01:34 by Vortex
I mean...
Try to check couple of section and compare the Raw Size and Virtual Size of each. If there is significatn difference, this may (not always) be compressed exe.


For the .idata there is a significant difference between the rawsize and virutal size, and yet the exe is not compressed.
Posted on 2003-04-03 04:40:14 by roticv
you should generally disregard vsize, and look at roundup(rsize, header.filealign) instead (header.memalign when image is loaded, of course). Especially borland linkers are very ill behaving. In the case of BSS (.data?), last section valign is usually correct though (but look at header.sizeofimage).
Posted on 2003-04-03 07:57:21 by f0dder
Maybe you must check various "suspect" situations to determine if an exe is compressed/encrypted.
An additional (and well working) test is:
Check that the EP is in the first CODE section of the exe, if isn't the probability of a modified exe increases by 50% i guess.

Greets.
Posted on 2003-04-17 02:29:57 by r00t