In this post i am shedding some light on something i have recently found which turns out to be an effective anti-dumping trick. It should work against most memory dumpers out there but it is tested only on OllyDump, LordPE, and VSD. So, let's go.
If we have an executable with the "SectionAlignment" field set to a value greater than 0x1000 e.g. 0x10000 and the "FileAlignment" field set to a value less than the "SectionAlignment", the OS commits only 0x1000 bytes for the PE header (of course, if compatible with the "SizeOfHeaders" field) and the rest, 0xF000, will be reserved (MEM_RESERVE). The same applies to the next sections. Given this fact, any attempt to call the "ReadProcessMemory" function with the "nSize" parameter set to the size of image will definitely fail, something that most dumpers do.
We construct the executable like this.
And this is how it looks like in memory.
In the image above, you can see a reserved memory block after each section. Any attempt to read from this block will fail.
Now let's see how memory dumpers handle this executable.
In this post i am assuming that the granularity of page protection and commitment on your system is 0x1000. You can find this value on your system by calling the "GetSystemInfo" function.
Here you can find a demo to play with.
Material in this post has been tested on Windows 7, Wow64 and XP SP3.
Update:
LordPe has the IntelliDump mode to handle such case. Thanks deroko for pointing this out.
You can follow me on Twitter @waleedassar
If we have an executable with the "SectionAlignment" field set to a value greater than 0x1000 e.g. 0x10000 and the "FileAlignment" field set to a value less than the "SectionAlignment", the OS commits only 0x1000 bytes for the PE header (of course, if compatible with the "SizeOfHeaders" field) and the rest, 0xF000, will be reserved (MEM_RESERVE). The same applies to the next sections. Given this fact, any attempt to call the "ReadProcessMemory" function with the "nSize" parameter set to the size of image will definitely fail, something that most dumpers do.
We construct the executable like this.
And this is how it looks like in memory.
Now let's see how memory dumpers handle this executable.
In this post i am assuming that the granularity of page protection and commitment on your system is 0x1000. You can find this value on your system by calling the "GetSystemInfo" function.
Here you can find a demo to play with.
Material in this post has been tested on Windows 7, Wow64 and XP SP3.
Update:
LordPe has the IntelliDump mode to handle such case. Thanks deroko for pointing this out.
You can follow me on Twitter @waleedassar
"the OS commits only 0x1000 bytes for the PE header". That's not true. SizeOfHeaders field determines how much is mapped. Change that value to 0x10000 and you'll see the entire block is mapped in (assuming that you have that much file content).
ReplyDeleteThanks Peter for leaving Me this comment. You are right. I am gonna mention the SizeOfHeaders thingy even though it is a minor issue that does not greatly affect the main idea.
ReplyDeleteIf dumpers are really using ReadProcessMemory(SizeOfImage), then that's just stupid. You don't need to change the alignment in that case, just create a section with no characteristics set, and then it won't be mapped.
ReplyDeleteGood comments guys! Like the article waliedassar!
ReplyDeleteYes most dumpers are that stoopid. Ollydump, the most widely used dumping plugin does so. Thanks for adding the characteristics issues, actually I did not try it but it is always good to know new stuff.
ReplyDeleteBut if like this, the pe file can not run
ReplyDelete