Anti-Dumping - Part 3

In this post i will share with you a couple of small tricks that can be deployed to harden or defeat memory dumping attempts. As i have just mentioned they are small tricks, so don't flame at me.

The first trick briefly involves appending a special section header to the section table of your executable. The new section header is to be set with a huge virtual size. Don't worry, this is not going to affect the file size (on disk) since we can set the raw size of the new section to zero (completely virtual section).

This results in the the "SizeOfImage" field of the IMAGE_OPTIONAL_HEADER structure being huge as well.

Unlike old anti-dumping tricks, we don't have to forge the "SizeOfImage" field of PEB.LoaderData or that in the PE Header memory page. Here, we give the dumping tools a huge value that they are very likely to fail to allocate using e.g. the "VirtualAlloc" function or its likes. Of course, this trick does not defeat dumping tools that read the memory of processes page by page.

Since the raw size of this huge section is zero, then the new section will be zero-initialized and the OS memory manager will throw it away making the memory usage of such process as smooth as possible.

It is now obvious that the new section should be left as it is. Your code should never read, write, or execute it. As any attempt to e.g. write to it results in the OS memory manager restoring the whole section into memory.

Here you can find a demo.

The second trick was first mentioned by Kris Kaspersky. The trick is very nice and simple. If we set the memory protection of one section as PAGE_GUARD, then the "ReadProcessMemory" function will fail usually with the system error code ERROR_PARTIAL_COPY, 0x12B. To defeat this trick, dumping tools are now using the "VirtualProtectEx" function to remove the PAGE_GUARD attribute, then read the section, and finally restore the PAGE_GUARD attribute.

To enhance this trick, i have created a watching thread that infinitely calls the "VirtualQuery" function and once it detects that PAGE_GUARD is removed from the section's memory protection attributes, it just terminates the process. Here is the code and here is a demo.

N.B. For the second trick to be effective, you should place the sections you want to protect after the PAGE_GUARD section so that the process terminates before them being dumped.

N.B. The second trick theoretically has better chances to work on multi-processor systems than on single-processor ones.

Any comments or ideas are very welcome.

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