Anti-Dumping - Part 2

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 

Anti-Dumping

I decided to write this post after i read a wonderful paper for Peter Ferrie. His paper includes several nice anti-dumping tricks. And i am now about to discuss one of them.

For those who are not familiar with the concept of "Anti-dumping", it is preventing debuggers from taking memory snapshots of debuggees after they have already been unpacked. In this post, i will show how to prevent OllyDump from dumping a debugee.

I quickly checked the source code of OllyDump and found out that:
1) The plugin extracts the PE information from the raw file by calling the "CreateFileA" and "ReadFile" functions. This can be defeated by calling the "CreateFile" function in our code with the "dwShareMode" parameter set to Zero, thus preventing OllyDump from opening the file and extracting PE info. See example 1.

2) When the user chooses to dump the process by clicking the "Dump" button, the plugin reads the PE info again, but this time from memory by calling the "ReadProcessMemory" function analogue and then checks for integrity. This can be defeated by destroying the PE header at runtime. See example 2.

 These two pitfalls could have been bypassed by calling the "CreateFileA" and "ReadFile" functions in the "_ODBG_Pluginmainloop" function and then caching the PE header.

To make things even harder, we can call the "UnmapViewOfFile" function to unmap the process main executable's image after we have copied it to a new memory block allocated by the "VirtualAlloc" function or the likes.


This can't be accomplished successfully until you :

1) Fix all absolute addresses e.g. push 0x00401122 because the whole image has been mapped at a new image base, that is, the address of the new memory block.

2) Change PEB.ImageBaseAddress to hold the new image base, otherwise application may access violate when executing code from the new memory block.

Our code will end up with something like the following:
1) Get the size of the main executable image and allocate memory with this size.
2) Copy the whole image to the newly allocated memory (new image).
3) Call the "UnmapViewOfFile" function to unmap the original image.
4) Jump to the newly allocated image and execute code.
5) Fix all absolute addresses in the new image and update PEB.ImageBaseAddress and LDR_MODULE.BaseAddress.
6) Continue execution normally.

Here you can find the source code of example 1, example 2, and example 3.

You can follow me on Twitter @waleedassar