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
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.
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
Please Show An example how we can implement this in .Net Framework
ReplyDelete