Hi guys,

I've come across something interesting. Whilst playing around, I started encrypting and packing some PE sections through my code (rather than a 3rd party protector). All the encrypting etc was working fine. I then decided to encrypt the .rsrc section. I applied the same (working) code that I had de/encrypted other sections with, then updated the section characteristics to be read & writeable instead of just readable.

I tested my exe with the encrypted .rsrc on my Win2k box, it works fine. I then copied it over to an XP box and tried it. As soon as I launch the .exe, I get a "Only part of a ReadProcessMemory or WriteProcessMemory request was completed" dialog. My code doesn't use either of these functions and that wasn't a msgbox I made, so I looked at it a bit closer. The code to decrypt the .rsrc section is the first piece of code in the exe, and there is no dependancy on any encrypted code (otherwise it wouldn't work in Win2k )

It seems as though there is a difference between Win2k and WinXP in how the .rsrc section is used when an exe loads. I tried it on 2 different XP machines, it fails. Try it on win2k, it works.

I've searched around for information about this but I just can't find anything relevant. Searching on the error brings up a small number of (irrelevant) code related hits, and thousands of game/app support requests. None of them are applicable to this issue. I've reviewed the MSDN PE section bible pages and there's no indication there either. I've played with the section characteristics, no luck. Other packers can (as far as Windows is concerned until the decompressor stub is loaded) corrupt the PE section with no side effects, but I'm missing something.

Anyone able to shed any light on this and point me in the right direction? Happens on XP SP1 and XP no SP, but works on all vers of Win2k so far. Been staring at it a few hours now with no luck...

Thanks!

I think, I may be incorrect, but if your rsrc section is flagged as being initialized data then windows will try and load it. however, because it's encrypted it may not be loading correctly. Have you tried setting the flags for your rsrc section to D0000080 (uninitalized) or E0000020 (code). It may or may not work. :/

EDIT: oops just saw that you already played with the section charactersitics. N/M

This is totally random but sometimes random thoughts lead to solutions...

Get rid of the separate resource section, and move the encrypted resource data into the code section. In the PE header, set the resource directory pointer to Null. Create a new section that has an RVA of where the original resource section would be after decryption and a VirtualSize of the decrypted resource section, but leave the RealSize and RealOffset Null. It should have readable,writable,uninitialised attributes. Then get the decryption code to decrypt the resources into this section.

My guess is that the PE loader in XP attempts to decipher the contents of the resource directory if the resource directory pointer is not Null, encounters the invalid encrypted data, and cannot process it, thus the error. In 2K, the PE loader does less checking when loading the sections. Also, is this XP SP1, SP2, or Original? I know that in SP2 they added more PE loader checking.

Just null out the resource directory pointer and it might work.

afaik, the whole resource tree (headers) has to be unencrypted.
the data pointed out by IMAGE_RESOURCE_DATA_ENTRY.OffsetToData can be encrypted.

Cheers guys, I'll try that... drizz's suggestion first, because that's less work

Anyone aware of a reference that shows just what parts of the PE can be messed with at runtime? Eg: "You cannot modify the RVA specified in IMAGE_DATA_DIRECTORY entry" etc... Would be handy.

every part has to be taken care of, with little less or little more work (and depends if its dll/exe).
for now just handle the rsrc section correctly...(and TLS if have this in your PEs)

find this, if you haven't already, :
"Writing Your Own Packer - by BigBoote"

Yeah, that was the point of my post. A page with the info listing where the little more and little less work is needed would be very helpful

i'll give some (dword) pointers...

*some of the pointers can change values (ie you can merge tls,rsrc,etc. in one section)

export table:
- has to be intact
import table:
- do what you wan't but you have to resolve application calls to apis
i'm sure you saw the big protections at work here (arma,aspr,am,...)
resource:
- headers must be valid, but the actual data can be packed/encrypted
(not all - for particular reasons, like 1st icon, ver info, manifest,...)
(headers and data can be in different sections (thats why
reshacker gives errors on some unpacked PEs))
debug:
- strip it
relocation:
- strip it if its exe
tls table:
- has to be intact *
iat:
- depends if your loader import table is Borland style or normal. if its borland - zero it.

i think this is about it for start.

err..Did you read the article i mentioned in my previous post?

Yes, I did read the article again (and have read it in the past). One specific thing I noted this time was this quote:



So if this is correct, LLXX's suggestion won't solve the problem. For future reference for everyone else:



According to the article, anyway. I'll test this out shortly. But again it comes back to the fact that compressing .rsrc in its entirety works on Win2k but not on XP, therefore the change to the execution process is within Windows, not within the PE format.

quote1: i'm not sure but i think its only true for COM/OCX dlls
quote2: you can add RT_MANIFEST to the list

i'll attempt to answer again...

Raw picture:

before packing .rsrc:

after packing .rsrc:

your loader or whatever section:

That is very strange. I randomly renamed the resource section of several PEs on my disk (including the standard test application, Notepad) and notice no change in operation. This would be on WinXP (no SP).