Adwiteeya Agrawal Security fanatic. Reverse Engineer and Web App Specialist.

Hey,
So moving on to a relatively advanced API based debugger detection or anti-debugging techniques, i am going to today discuss the implmentation of ZwSetInformationThread routine. Now this is an undocumented win32 API and we need to get a pointer to the function inside a library and then make a call to the function. The very first implementation is as follows (by the way I code on Code:Blocks 12.11):

#include “stdafx.h”
#include “windows.h”

void antidebug();
void antidebug()
{
HMODULE lib;
FARPROC _ZwSetInformationThread;
lib = LoadLibrary(“ntdll.dll“);
_ZwSetInformationThread = GetProcAddress(lib, “ZwSetInformationThread“);
(_ZwSetInformationThread)(GetCurrentThread(),0x11,0,0);
MessageBox(NULL, “Debugger Detached“, “Debugger Detached“, MB_OK);
}

int _tmain(int argc, _TCHAR* argv[])
{
antidebug();
MessageBox(NULL, “Double Check…“, “Double Check“, MB_OK);
return 0;
}

Before I get into the BUGs lemme just try and explain what is happening here, so we are basically loading a handle to ntdll.dll by calling the LoadLibrary process and then we load the callback to _ZwSetInformationThread which is of datatype FARPROC[more on FARPROC] then we call ZwSetInformationThread routine which has four parameters as per http://msdn.microsoft.com/en-us/library/windows/hardware/ff567101%28v=vs.85%29.aspx .

The firstparameter is the handle to the current thread and since we want to run this function within our program we use the GetCurrentThread() function call which returns a handle to the current thread. Next is a value 11. This is basically the value because of which the debugger would get detached from the process. Now how did i get this value. As per documentation on msdn the second parameter is of the enumeration type _THREADINFOCLASS which is as follows [source] :

typedef enum _THREADINFOCLASS {
ThreadBasicInformation,
ThreadTimes,
ThreadPriority,
ThreadBasePriority,
ThreadAffinityMask,
ThreadImpersonationToken,
ThreadDescriptorTableEntry,
ThreadEnableAlignmentFaultFixup,
ThreadEventPair_Reusable,
ThreadQuerySetWin32StartAddress,
ThreadZeroTlsCell,
ThreadPerformanceCount,
ThreadAmILastThread,
ThreadIdealProcessor,
ThreadPriorityBoost,
ThreadSetTlsArrayAddress,
ThreadIsIoPending,
ThreadHideFromDebugger,
ThreadBreakOnTermination,
MaxThreadInfoClass
} THREADINFOCLASS;

So ThreadHideFromDebugger is 17 which is basically 11 in hex. And the remaining two parameters are obviously not of importance to us. :D

Now coming to the bugs. “|17|error: too many arguments to function|” But MSDN said that it needed four :O and now i started removing one parameter at a time and the function ran when i did not pass any arguments. After having searched a lot! The only solution that i could think of was to use the asm function and pass these arguments manually.

So i made the following changes.

(_ZwSetInformationThread)();
GetCurrentProcess();
asm(“pushl 0“);
asm(“pushl 0“);
asm(“pushl 0x11“);
asm(“pushl %eax“);

Oh and by the way the assembly syntax utilized on GCC is the AT&T asm. So yeah! I had to first read that because i have being doing the intel format. I read [this]

So this was some success because atleast the exe compiled, i had already though that now i would easily debug everything on OllyDbg and get it through. But this is what GCC(or i) had done to the code. :

So this wasnt the best solution.But it was some success since i was atleast able to compile the exe now and look it up in Olly (Somehow i am more comfortable with that.)

I decided that since the value passed as the handle to the process is the only thing that i do not know lemme pass other values by modifying the assembly code manually in Olly and changed the code to the following :

HANDLE hndle = GetCurrentThread();
(_NtSetInformationThread)();

The exe did compile and i was getting the pop up messages too.

Next thing was to immediately load this exe into my dearest OllyDbg and get started. Here is the very first look.

You can see that a call gets made to GetCurrentThread at 00401365 and the value is returned into EAX which is them moved to our variable “handle” (EBP-14). So after a couple of runs i realized that this value was always the same and always returning FFFFFFFE i am not sure if this is a fixed constant for a each system or is it just the local handle to every thread. But this is what it was in the case that I had in front of me. Then later you can see that a different value is moved into EAX and at 00401370 we make a call to that address (call eax) hence this is the handle to the ZwSetInformationThread.

So far so good. Next i had to modify the code so that i could push values to the stack before the call eax is executed. If you at the address 00401362 you would see that MOV EBP-10,EAX instruction is executed just after GetProcAddress so basically this is the place where the handle to ZwGetInformationThread is placed on the stack hence we can only modify the code after this. That is from 401365 to 40136D where the value is pushed back into EAX. (Or we could NOP both of these so that the value remains unchanged)

So here are the modifications that i did, wait and after this modification i clicked analyse code. So you’d see that now Olly recognizes this as a function ^_^

so we have obviously overwritten the call to GetCurrentThread but the code seems to fit just fine! :)

Now do you see a push -2 at 0040136B i had assembled PUSH 0xFFFFFFFE. :) And also since this is windows you would have to push the last argument first… just in case you did not know this.
Now before you run the code remember to save all modifications to exe because if the code is successful you would be detached from the debugger.
And finally we run the program. We Get the pop ups. And next we are detached from the debugger. :) (The code screen goes blank. Try reloading with << button.
The Blank Screen :

The Error :

H3LL Y34H! B)

by Adwiteeya Agrawal