IAT hooking

So far I only talked about kernel hooks, but you can do some hooking in userland also. Today I’m going to show you the simpler of the two userland hooking processes is called Import Address Table hooking (IAT).

When an application wants to use a function that is located in a DLL (kernel32,user32…) For example MessageBoxA, the application must get the address of the function. We do this through an IAT.

So what we’re going to do is, create a DLL with our fake function, load it into the target and when the target application calls the original function, our function is going to get executed instead of the original.

In my example, we are going to hook MessageBoxA. MessageBoxA is located in user32.dll, so fire up your dissembler (In my case IDA) And find the full prototype. In our case it’s going to be:

int __stdcall MessageBoxA(HWND hWnd,LPCSTR lpText,LPCSTR lpCaption,UINT uType)

It’s very important that you have the exact same prototype as the original one!

Now go create an application that calls MessageBox, and dissemble it. I’m going to use OllyDbg. The call to MessageBoxA is going to look this way: “CALL DWORD PTR DS:[<&USER32.MessageBoxA>] ” Now look in the window before the Hex View, you are going to see something like: “DS:[0042428C]=7E45058A (USER32.MessageBoxA)” 0042428C is what we need. It’s the pointer to the function.

Now it’s time to create our DLL. First lets make our fake function.

int __stdcall NewMessageBoxA(HWND hWnd,LPCSTR lpText,LPCSTR lpCaption,UINT uType)
{
char real[200];
sprintf(real,”Inside hooked MessageBoxA.\n\nText=%s\nTitle=%s”, lpText, lpCaption);
MessageBox(NULL,real,”Real values”,MB_OK);

return MessageBoxA(hWnd,”Fake much”,”Fake”,uType);

}

It’s going to show us the real values, and then we are going to return what we want! Also, you may want to make the function fail. To do so, get the value when the function doesn’t succeed, use MSDN for that.

Now we want to get MessageBoxA address, to do so, we are going to use GetModuleHandle/GetProcAddress. Like this:

OrigAddress = (int)GetProcAddress(GetModuleHandle(“user32.dll”), “MessageBoxA”);

Now we must point the original function to our fake one, so when the real one is called, our fake one is getting executed. We do this this way:

OurAddress = (int)NewMessageBoxA ;

This is pretty much it. It wasn’t that hard was it? Of course this is not the full code, if you want the source code, you can download it at the end of this post.

This method is not perfect. I’m going to quote a passage from the book “Rootkits:Subverting the windows kenel” (The picture came from there to.)

Here we go: “Some applications do late-demand binding. With late-demand binding, function addresses are not resolved until the function is called. This reduces the amount of memory the application will use. These functions may not have addresses in the IAT when your rootkit attempts to hook them. Also, if the application uses LoadLibrary and GetProcAddress to find the addresses of functions, your IAT hook will not work.”

If you find any errors or bugs, please leave a comment. Thanks for visiting and reading.

DOWNLOAD

Getting the system calls by yourself

Of course you can get them from a website such as this one.

You can find them by disassembling the module where the function is located.

Notice 30 is the call number of NtCreateProcessEx. It’s moved into EAX

But you can code a program that will do that for you!

Let’s do that. In my example, only the functions that are exported by “ntdll.dll” are going to work. But that can be changed really easily…

mov eax, 30h ; NtCreateProcessEx
mov edx, 7FFE0300h
call dword ptr [edx]
retn 24h

Since we know that the call number is loaded into EAX, we have to check for a “mov eax”. “mov eax” = 0xB8

if ( *Function != 0xB8 )
{
return FALSE;
}

Then we want to check for “mov edx”, its 0xBA.

if ( *(Function + 5) != 0xBA )
{
return FALSE;
}

Now you can do additional checks, but this is enough. If you’re wondering why we did function + 5, thats because ZwCreateProcessEx is located at 7C90D769 and the mov edx instruction is on 7C90D76E. So we did function address + 5.

Well the rest is simple, and doesn’t require any explanation. You can download the source code here. If you find any errors or bugs, please leave a comment. Thanks for visiting and reading.

Later.

CRC32: File checksum

I recently needed to check the integrity of some files, but I didn’t know what hash to use nor how to generate one! I choose CRC32 for no particular reasons, and it wasn’t as hard as I imagined to generate the hash!

Anyways, the source code is easy to understand and I tried to comment it as much as I could, so no explanation here. You can download the source code from here.

Executable size

Ever downloaded a crackme or a program and realized how huge it was and it was only doing something really simple? I did and unfortunately I even released my own programs and they were full of bloat. In this article I’m going to show you 3 steps that I always do now when I build a final version of my programs.

I’m using MVC++ 6 as my complier, but the tricks that I am going to do can be done in other compliers as well. Okay let’s start of with a simple “Hello World” program.

#include “stdio.h”
int main(void)
{
printf(“hello, world\n”);
return 0;
}

Without touching my complier settings, the executable size is: 152kb Thats a lot for a simple Hello World program. And if you open it in an disassembler, you will see that there’s so much bloat.

1st step
You need to do a “Release build” instead of a “Debug build” This will reduce the size dramatically. You can do that by going to Build -> Set Active Configuration and click Win32 Release.

Okay now let’s build it again! And a new folder named “Release” has appeared and the executable is now 28kb, we reduced the size 5 and half times!

Step 2
Now we are going to modify settings. Goto Project -> Settings -> Click the “Link” tab. Now look at the edit box where it says “Object/library modules”

Okay now remove everything from there and type “MSVCRT.LIB kernel32.lib user32.lib” and build. The executable size is now: 16kb. This is very important! only using those 3 libraries will cause some of your API not to work. For example, RegOpenKeyEx Why? Because it needs “Advapi32.lib” How do you know? Go to the API MSDN page, scroll all the way down till you see the “Requirements” So now all you need to do is add the required library.

Step 3
This is really not hard, goto Project -> Settings -> click the link tab and now see that big edit box? Add this line “/ALIGN:4096″ there. Build, and the executable size is now 2.50kb! and we started at 152kb.

You can learn about this linker option at MSDN: /ALIGN

Now you executable is small and not full with bloat. You can open it in an assembler and you will see its more cleaner and sleek. I gave you my 3 steps that I always do, however a simple google search will show you more in depth tricks to reduce the size to 1kb and less! Thanks for reading. And I’m almost done writing a article about hooking Nt* functions, will publish later today.

Later.

Process Token Privileges

In the past week I’ve been reading posts in forums, and I realized that many people are surprise that some of their API don’t work. For example InitiateSystemShutDown, SetSystemTime or for that matter terminating a critical process. They don’t work because the calling process requires to have some sort of a privilege on it’s tokens, which are disabled by default. There’s many more API’s then those mentioned above. It may be a good thing for an average user because it increases security, but for us it’s not. In this post I’m going to teach you how to adjust your process tokens privileges and enable debug privileges.

Our goal today is to enable SE_DEBUG_NAME privilege to be able to kill a critical processes (Will cause a crash/BSOD) As you may know to kill a process, we use OpenProcess() and TerminateProcess() The code will look like this:

printf(“Enter PID you want to terminate: “);
scanf (“%d”,&processID);

hProcess=OpenProcess(PROCESS_ALL_ACCESS, false, processID);
hTerminate=TerminateProcess(hProcess,0);

This will terminate your average process, but now try to kill “winlogon.exe” for example. Won’t work, why? Open Process Explore And do the fallowing.

As you see SeDebugPrivilege is disable, we are going to enable it. To do so we are going to use 3 API’s : LookupPrivilegeValue(), OpenProcessToken() and AdjustTokenPrivileges()

The first thing we have to do is use LookupPrivilegeValue() to get the LUID (Locally Unique Identifier) of the privilege we want, in our case SE_DEBUG_NAME.

TOKEN_PRIVILEGES Debug_Privileges;
LUID luid;

if (!LookupPrivilegeValue (NULL,
SE_DEBUG_NAME,
&luid))
{
printf (“LookupPrivilege() error %u\n”, GetLastError());
CloseHandle (hToken);
return false;
}

If everything went well, we should now received the LUID value of our privilege. Now we are going to use OpenProcessToken(). Since we want to enable or disable the privileges we are going to use this flag: TOKEN_ADJUST_PRIVILEGES. To see a full list of all the available flags visit this page .

HANDLE hToken;
if (!OpenProcessToken (GetCurrentProcess(),
TOKEN_ADJUST_PRIVILEGES,
&hToken))
{
printf (“OpenProcessToken() error %u\n”, GetLastError());
return false;
}

We are almost done, 1 step to go. This time we are going to use AdjustTokenPrivileges(). We use this adjust the privileges. You can either enable or disable a privilege with this API.

if (!AdjustTokenPrivileges (hToken,
FALSE,
&Debug_Privileges,
0,
NULL,
NULL))
{
printf (“AdjustTokenPrivileges() failed with code %d\n”, GetLastError());
CloseHandle (hToken);
return false;
}

Now if everything went well, open Process Explorer and check is the SE_DEBUG_NAME is still disable, it shouldn’t be.

If it’s blank, it means everything went well (I don’t know why it doesn’t say Enable) If you may think that an API is failing because it requires a privilege, go to your API MSDN page and read the “Remarks” section. It will inform you with everything you need to know. The full sources are below, and if you find any error or any bug, please make me know about them. Thank you for reading.

Download