OllyDbg v1.10 And Wow64

If you have ever used OllyDbg v1.10 on Window 7 64-bit version (Wow64), then you must have seen the annoying single-step breaks that frequently interrupt your debug session. I spent a couple of hours to find the reason behind this and finally came out with this small plugin, "OllyWow64", to fix this bug.

You can find OllyWow64 here.
Version 0.2 can be found here.

The fix is as easy as what you see in the image below.

 Here you can find the source code.
Here you can find the source code of version 0.2.

Update:
Version 0.2 of OllyWow64 has been released.

You can follow me on Twitter @waleedassar 

OllyDbg Resource Table Parsing Integer Overflow

In this post i will quickly show you an integer overflow found in OllyDbg v1.10. This leads to a buffer overflow, which can be exploited to execute code arbitrarily.

In brief, all you have to do is set the size of Resource table to 0xFFFFFFF7.

Olly adds 0x9 to 0xFFFFFFF7, which sums up to Zero due to an integer overflow. Zero byte is then allocated by calling the "GlobalAlloc" function. Finally the "_Readmemory" function is called to copy 0xFFFFFFF7 bytes to the newly allocated memory causing a buffer overflow. See the image below.

But wait, there is a minor issue that i need to shed some light on. The "_Readmemory" function, as its name implies, is a wrapper of the kernel32.dll "ReadProcessMemory" function. So why did this call succeed if the number of bytes to copy is that huge? the reason behind this is that the "_Readmemory" function checks to see if data at the target address is cached. If it is cached, the "memcpy" function is directly called and this is where the buffer overflow occurs.

Here you can find the demo.

You can follow me on Twitter @waleedassar

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 

OllyDbg Section Name Crash

This is an old yet interesting bug in OllyDbg. This bug affects OllyDbg v1.10 even with the "OllyAdvanced v1.27" option set.

Here is a screenshot of the vulnerable code.

In brief, set the name of the code section to "%*s%*s%s" and the "SizeOfCode" field to zero.

A demo can be found here.

You can follow me on Twitter @waleedassar 

Visual Basic Malware - Part 1

I can't deny i was interested in Visual Basic Malware the last few days. So, i am going to share some of my experiences with this type of malware.

Since i don't feel comfortable with VB Decompiler and the likes (perhaps you do), i decided to take two VB Malware samples and see what special procedures could be taken to make the analysis process easier without use of these tools.

Before going into the details of VB malware, i will quickly give some basic information about VB executables.

1) VB executables come into two flavors, P-Code and Native. P-Code executables are compiled into bytecode which is interpreted by the Visual Basic virtual machine at runtime, while Native ones are compiled into native machine language. So, Native VB executables are easier to debug. On the other side, P-Code VB executables are easier to decompile.

2) At the entry point, there is always a non-returning call to the "ThunRTMain" function. This function has only one parameter, which is a pointer to a bulky structure holding everything the executable needs.

3) The code section contains a lot of interesting and non-interesting stuff. So, a quick and dirty way to spot functions (Native only) is to search for 0xE9E9E9E9 in disassembly. This dword denotes the real start of code. In P-Code executables, 0xE9E9E9E9 is followed by 0x9E9E9E9E as they have no x86 instructions.

4) Each function starts with a call to the "Zombie_AddRef" function and ends with a call to the "Zombie_Release" function. So, a simple executable might have hundreds of calls to these two functions.

5) Calling an API function is conducted either by calling the MSVBVM60.dll function that wraps up that API or by calling the "DllFunctionCall" stub.  See the images below.

6) Any "Private/Public Declare Function ..." statement in a module is reflected in the executable as a "DllFunctionCall" stub.

The "DllFunctionCall" function receives one parameter. This parameter points a small structure whose first and second members point to the DLL and function names successively. The "DllFunctionCall" function is internally as simple as a call to the "LoadLibraryA" function followed by a call to the "GetProcAddress" function, see the image below. Actually, the function's name is not very accurate as the function only retrieves addresses.

Conclusion: Enumerating all calls to the "DllFunctionCall" stubs in a VB executable is very useful in analyzing VB malware.


Enumerating this kind of calls in disassembly is as easy as searching the PE sections for a specific byte pattern. The pattern is usually, if not always, like this:

I have created an OllyDbg plugin, OllyVB, to let you easily find all "DllFunctionCall" stubs by matching the byte pattern shown above.

Usage: 
ALT+E to enumerate modules in OllyDbg and then Right-Click and choose "View names".

Back to our main topic.

Sample 1)

Loading sample1.exe into OllyDbg v1.10 (with the "OllyVB" plugin), we will find that it imports many APIs. See the images below.

As you can see, all the "DllFunctionCall" stubs are encrypted except the "CallWindowProcW" one. Why "CallWindowProcW"? we will find this later, just keep reading.

The next step is to place breakpoints on all the "DllFunctionCall" stubs we have and then run (F9).

Once execution stops at the "CallWindowProc" stub, take a quick look at the stack to inspect parameters. You will see that the first and second parameters passed to the "CallWindowProcW" function are so fishy as the first parameter which is supposed to be a pointer to a window procedure points to a heap location and the second parameter which is supposed to be a window handle points to a string. To find the reason behind this weird function call, let's quickly dig into the "CallWindowProcW" function internals.

As you can see in the image above, the call to the "CallWindowProcW" function ends up with call dword ptr[ebp+0x8], which causes code at this heap location to be executed. we can now conclude that the "CallWindowProcW" function is only used to invoke its first parameter.

As many know, Visual Basic does not intrinsically support function pointers, this is why VB programmers (I bet not so many are still alive) are using this function (other functions can also be used) to implement something similar to the C function pointers, a quick and dirty way to execute shellcode or hide the "DllFunctionCall" stubs from disassembly. See the images below.

The sample in question does not call the "VirtualProtect" function to allow execution from heap (Perhaps, cuz it was written too long ago) and this is why Hardware Data Execution Prevention (DEP) kills this piece of malware.

Now, let's see the shellcode that the "CallWindowProcW" function executes using the call dword ptr[ebp+0x8] trick.

As you can see in the image above, the shellcode resolves a function address given its DLL name and hash. The address resolved will later be used to form another shellocde. We will see this later.

Repeating the same trick, we will see a call to the "CreateProcess" function by which the executable spawns itself in suspended state.

It will then unmap the image of the spawned executable from address space by calling the "ZwUnmapViewOfSection" function and re-allocate 0x4f000 bytes at 0x400000 by calling the "ZwAllocateVirtualMemory" function.

The "ZwWriteVirtualMemory" function will then be called several times to create the new executable. Finally, the "ZwResumeThread" function will be called to resume the suspended process.

After taking a memory dump of the new process and fixing its section table (by merging all sections into one big section), i got another Visual Basic piece of malware that is not encrypted at all. This piece of malware will be discussed in another post but here is a quick view of its "DllFunctionCall" stubs.

Notes:
1) The markers 0xE9E9E9E9 and 0x9E9E9E9E are not mandatory. They don't affect the executable if removed.
2) Everything that applies to the "CallWindowProcW" function also applies to its ANSI version.
3) Many other APIs can be used in the same way as the "CallWindowProcW" function.
4) I hate Visual Basic.

Here you can find sample 1. password : infectedtakecare

Any comments or ideas are more than welcome.

You can follow me on Twitter @waleedassar 

GetModuleFileNameEx And Infinite Loops

In this post i am going discuss an infinite loop bug in some functions of the psapi.dll. I will take the "GetModuleFileNameExW" function as an example.

I have chosen the "GetModuleFileNameExW" function of psapi.dll v5.1.2600.5512, the one shipped with Windows XP SP3.

The function's prototype is:

Let's have a look at the function in OllyDbg.

As you can see in the image above, almost everything is done in the non-exported "_FindModule@12" function. The "_FindModule@12" function's source code looks something like this.

As you can see from the source code above, if the function is called with the "hMod" parameter set to Zero, the "ImageBaseAddress" value in the PEB (Process Environment Block) is retrieved and then the "InMemoryOrderModuleList" doubly linked list is traversed and each "LDR_MODULE" structure is queried for its "BaseAddress" field . If the "BaseAddress" field is equal to the "ImageBaseAddress" value, the function successfully returns.

And if the "hMod" parameter is set to nonzero, the doubly linked list is directly traversed and each "LDR_MODULE" structure is queried for its "BaseAddress" field. If the "BaseAddress" field is equal to the "hMod" value, the function successfully returns.

So, if we manipulate any LDR_MODULE structure to point at itself instead of pointing at the next structure, then we can cause any application that uses the function against our process to go into an infinite loop.

Here is a demo that causes OllyDbg v1.10 to go into an infinite loop when you open the "Select process to attach" dialog box. You can also use the second demo for OllyDbg v2.0.

Trying to test these demos on Windows 7, you will notice that everything is okay and no infinite loops occur. So, let's check the "_FindModule@12" function in psapi.dll shipped with windows 7 (WOW64).

If we compare the source code of both versions, we will easily see that Microsoft fixed that bug by defining a value for the maximum number of modules that can be loaded in a process. The value is 0x2710.

Any ideas or comments are very welcome.

You can follow me on Twitter @waleedassar 

OllyDbg v2.01 And TLS Callbacks

One of the new interesting features introduced in version 2.0 of OllyDbg is the ability to pause on TLS callbacks. Actually, i discussed some flaws of this feature in a previous post, but in this post i will show you a minor bug (not so minor) that i found while playing with OllyDbg, like i sometimes do.

OllyDbg v2.0 assumes that the "Size" field in the TLS data directory is mandatory, but it is actually not. To make things clearer, i will dump the ntdll.dll code responsible for parsing the TLS info.

As you can see in the image above, the "RtlImageDirectoryEntryToData" function is called to get the absolute address of the "IMAGE_TLS_DIRECTORY32" structure. Its fourth parameter is a pointer to a variable that receives the size of  "IMAGE_TLS_DIRECTORY32" structure, which is typically 0x18 bytes. It is easy to notice that no checks are done to verify the size.

To be even more sure, let's check the code that extracts TLS info in the "RtlImageDirectoryEntryToData" function .

As the two images above imply, the OS loader simply discards the "Size" field and continues invoking TLS callbacks.

On the other side, OllyDbg stops processing the TLS info. if the "Size" field is zero. See the image below.

The source code for the image above should be something like this.

We can easily figure out from the source code that setting the "Size" field to Zero is enough to fool OllyDbg to ignore TLS info. We can also fool OllyDbg by setting the "Size" field to 0xC or abit longer depending on the executable's ImageBase.

Things get more interesting if the "AddressOfCallbacks" member is e.g. 0x01F12200 and the "Size" field is 0xF. In this case, OllyDbg will place the int3 breakpoint at 0xF12200 and since 0xF12200 will never be hit, the breakpoint will be left untouched.  Just play with this demo.

N.B. Many file inspectors are also affected by this bug e.g. Stud_PE and exeinfo.
Update: This has been fixed in Stud_PE as of version 2.6.0.8.

You can follow me on Twitter @waleedassar 

Collection Of OllyDbg Bugs And Exploits

I have created a new project on code.google.com to track the publicly disclosed bugs and exploits in OllyDbg v1.10 and later.

It can be reached at:
http://code.google.com/p/ollybugs
http://code.google.com/p/ollybugs/downloads/list

I will keep updating it as long as bugs and exploits are being disclosed.

Any comments or ideas are very welcome.

You can follow me on Twitter @waleedassar 

RtlSetProcessIsCritical

The "RtlSetProcessIsCritical" function is one of the ntdll.dll undocumented functions, which can be very useful for software protections and malware.

The function has the following prototype:
int __cdecl RtlSetProcessIsCritical(bool IsCritical, bool* pOld,void* u);

It is easy to see from the function prototype that if the function is called with the first parameter set to true, the process becomes critical and vice versa. For those who don't know, if a process is critical and it crashes or gracefully exits, the whole system is taken down after a blue screen of death is displayed.

The interesting thing about the code in the image above is that if it is run in OllyDbg, the system crashes upon any attempt to terminate the process or OllyDbg, while this does not happen if the code runs without a debugger. The reason behind this behavior is that the "RtlSetProcessIsCritical" function requires the debug privilege, SeDebugPrivilege, to come into effect and OllyDbg passes this privilege down to its debuggees. This can be very useful for anti-debugging, since any failed debugging attempt e.g. failure to handle an exception due to the author-defined unhandled exception filter not being called, would result into taking down the whole system.


I have seen some anti-anti-debug plugins, which patch OllyDbg process memory to prevent it from acquiring the debug privilege and subsequently depriving debuggees from inheriting that privilege and becoming critical. To circumvent those plugins, we can explicitly acquire that privilege by calling the "AdjustTokenPrivileges" function with the appropriate parameters. The only drawback here is that any crash to our process or any graceful termination attempt would result in a blue screen of death. We can take care of this by patching the "ZwTerminateProcess" function or any similar technique.

Some demos to play with can be found here.

Side note:
The "RtlSetProcessIsCritical" function is just a wrapper of the "ZwSetInformationProcess" function with the "ProcessInformationClass" parameter set to 0x1D.

In response to some malware, i have created an OllyDbg plugin to handle such situations. The plugin simply calls the "ZwSetInformationProcess" to detox (remove criticality of) the process being debugged and thus safely debugging it without caring about the more likely debugging crashes.

Version 0.1 of the plugin can be found here.

Version 0.2 of the plugin can be found here.

The source code can be found here.

Any comments or ideas are very welcome.

You can follow me on Twitter @waleedassar