Recently I decided to take a look at a vulnerability in ProShow Gold reported by BKIS and detailed in OSVDB 57226.  Much of the hard work was done, as BKIS had released a PoC pointing out the trigger location.  I quickly found that the way to make this bug work easily was to exploit it using the SEH technique.

I used Metasploit’s ./pattern_create.rb to get the offset to the first handler in the chain.  Typing ./pattern_create.rb 6500, felt a little weird, but sometimes you just have to overwrite a lot of stuff.  I then used ./pattern_create.rb again to get the max payload size, past the handler.  In the module this is listed as 1000 bytes, but you could actually squeeze a few more (if you’re into writing exceptionally large custom shellcode). Read more…

Code, Exploitation 0day, exploit, metasploit

Welcome to the second installment of Anti-Debugging Techniques.  This week we will be playing with the idea of using the Windows API to do process listing and comparison in an effort to frustrate debuggers.  We will of course be including a binary and source for your testing pleasure.

Before we get too far along, I’d also like to mention that in Part I, there was a mistake that would have allowed exploitation with or without a debugger attached.  This has been fixed and new code and a fresh binary have been uploaded.

The Windows API allows us to enumerate processes currently running by using a combination of the CreateToolhelp32Snapshot, Process32FirstW and Process32NextW functions.  The first step is to create a handle to the process snapshot and a variable to store PROCESSENTRY32 structure information.  A call is made to Process32FirstW to get the first entry in the list and populate the structure.  The PROCESSENTRY32 structure contains several pieces of information including the registered process name.  We continue to walk the snapshot by calling Process32NextW. Read more…

Code anti-debug, c, Code, reversing

In this series of posts we will begin exploring common and not-so-common anti-debugging techniques.  The idea is that this will allow us to better understand the tricks and methods of those individuals and organizations that would work to stump our RE and exploit development efforts.  I know it’s hard to believe, but they do exist.

We will make every attempt to give example code so that you may step through the execution and trace the inner workings of the technique discussed.

Every journey begins with a single step, so here I present one of the lowest bars in anti-debug techniques,  IsDebuggerPresent().

So, the way IsDebuggerPresent works is that it first looks at the TEB structure and locates the PPEB pointer to the Process Environment Block (PEB).  After getting us to the PEB, we look two BOOLs into the structure and find the BeingDebugged BOOL.  That’s all there is to it.  That’s all that determines whether or not IsDebuggerPresent() returns true or false.

Pre-compiled binary of below [16.4kb] or Source [1.5kb]

/*================================================================================
 
	Description:
		This is example code for the IsDebuggerPresent anti-debugging technique.
		There is a simple buffer overflow nested in a code path reachable when
		IsDebuggerPresent() is set to false.
 
	Author:
		Saint Patrick 
 
================================================================================*/
 
#include
#include
#include 
 
BOOL isDebuggerPresent();
 
// Here we have a simple buffer overflow to exploit.
int main(int argc, char *argv[])
{
	// Static Buffer @ 250
	char buffer[250];
	if (isDebuggerPresent()){
		exit(0);}
	else
        {
		// Print something and then do the devil's dance
		printf("L1pht appreciates your donation of: %s",argv[1]);
		strcpy(buffer,argv[1]);
        }
	return 0;
}
 
// This is the method that takes care of the WinAPI calls.
// This code was ripped from a forum post discussing IsDebuggerPresent by mudlord
BOOL isDebuggerPresent()
{
 BOOL result = FALSE;
 //Get a handle to the kernel32.dll library
 HINSTANCE kern_lib = LoadLibraryEx( "kernel32.dll", NULL, 0 );
        if( kern_lib ) {
				// Get the function address
                FARPROC lIsDebuggerPresent = GetProcAddress( kern_lib, "IsDebuggerPresent" );
                if( lIsDebuggerPresent && lIsDebuggerPresent() ) {
                        result = TRUE;
                }
                FreeLibrary( kern_lib );
        }
		// Return the result of IsDebuggerPresent
        return result;
}

We can see that this technique can easily be defeated with a little fixup code, a plugin for OllyDBG or the !hidedebug command in ImmunityDBG.

Hopefully this quick intro gave you something to play/demo with. Now play!

References:

IsDebuggerPresent Function [MSDN]

Code anti-debug, c, Code, reversing