tut How to hook tut 6

[llvengancell]

Tutorial] Hooking
[TUTORIAL] Everything you need to know about Hooking
Author:OsGB'
Tutorial:

In essence there are only 2 types of hooks;

1) User Level Hooking
2) Kernel Level Hooking


of course there are so many things that fall into place between those 2 things that the remaining types of 'sub' hooks are just gravy.


Win32 API Hooking falls under User Level hooking (user level, application level, os level -- et al)
API Hijacking is the easiest to do although very complex for a newcomer

here are a few things you can do at User Level Hooking:

Window subclassing.

One of the most simplistic hooking methods is sublcassing a window, after this is done a user can do a lot of things such as modify keyboard and mouse input/output, do events when certain input is given, etc...

A HWND Proc Hook is an example of a way to subclass a windows application and grab all of the input that a user sends it (keyevents, mouse, et al)

The only thing bad about Subclassing is that you are constricted to that single application and it is therefore not a system wide at all


Proxying

You find this to be common in wrappers, basically its when a user replaces a dll with their own that has the same amount of names and exports all of the functions/symbols that the original would

Function fowarding and hooking the exports of a dll is a simple process and is something that you saw me explain earlier in my first post, a simple example of proxying code used in a GL Wrapper:

Code:

// Global Defines:
typedef void ( *glBegin_typedef) (GLenum mode); // glBegin Typedef
glBegin_typedef original_glBegin; // original_glBegin define

// opengl32.cpp
void Hooked_glBegin (GLenum mode)
{
//dotheshit();
(*original_glBegin) (mode);
}



Code:

// opengl32.def
// defines of DLL Exports and their Indexes are as follows:
LIBRARY opengl32
EXPORTS
...
glBegin = Hooked_glBegin @11
...



Since the opengl32.dll is loaded automatically (as a proxied dll - a wrapper) that in essence 'wraps' the render device of opengl, it will do everything you tell it to do.
as you can see in the Hooked_glBegin function it does everything you tell it to do and THEN calls back to the original function so as to not **** things up :]

proxying is one of the easier ways to hook functions and can even be system wide if done in certain modules.


Code Overwritting / Detouring

Oh this is fun! this requires asm > Code overwritting can be a very complicated and messy concept but if it works, it works good. (although its buggy and prone to error out A LOT so... its not a fun process, and its not garunteed to work since its not static like function forwarding through a lib or subclassing can be)
There are a lot of ways you can overwrite code or detour, all are very powerful, all are very 'hacky' but efficient. A simple example of code overwritting is what we used to do long ago with Bytehacking of uscript packages.

Code:

if(you == hax0r)
PP.Destroy();



overwritting is as simple as bytehacking in that case where you can change Destroy to - Firealt, or == to !=, or you to him, or hax0r to l3git...

Just as there are a lot of possibilities in a simple bytehack there are also a lot of possiblities in API hooking using overwritting.

1 way of overwritting is to replace the address of the function when it is "CALL"ed

Code:

; example of a call in ASM - taken straight from Engine.dll
PUSH EBX
PUSH ESI
PUSH DWORD PTR SS:[EBP+8]
CALL Engine._DllMain@12



lets take a crash course in Reverse Engineering 101:

as we can plainly see thats a call to DllMain which every dll prog needs, and since im a super leet hax0r i know what DllMain is composed of;
Code:

BOOL APIENTRY DllMain(HMODULE hDll, DWORD Reason, PVOID lpReserved)

now let me get back to what i was saying each one of the above asm instructions has an 'address' in memory
the first instruction of:
PUSH EBX is located at 0x105E189F in Engine.dll
PUSH ESI is 0x105E18A0
PUSH DWORD PTR SS:[EBP+8] is 0x105E18A1
and the call to DllMain is 0x105E18A4


now your probably wondering why is it that it was incremental from 0x105E189F + 1 =
to 0x105E18A0 + 1 =
to 0x105E18A1 + 3????? =
that makes sense right? thats just going up by 1 each time.... but whats this?
the call to DllMain is at 0x105E18A4???
why did it jump 3 entire bytes, did it **** up some how?

no it didnt heres why:

In order to call a function one must first push all of its params (registers) to the stack, params are pushed backwards (DONT EVER FORGET THIS):

so in the case of DllMain, you have 3 params:
DllMain(HMODULE hDll, DWORD Reason, PVOID lpReserved)
1) lpReserved = DWORD PTR SS:[EBP+8]
2) Reason = ESI
3) hDll = EBX

now look:

Code:

// remember backwards ->
PUSH lpReserved;
PUSH Reason;
(PUSH hDll); - [and prepare to call DllMain]
Call DllMain;


each of the above look like this in Hex:
Code:

0x53
0x56
0xFF75 0x08
0xE8 0xF796DBFF

translate that back to english:
Code:

0x(5)PUSH (3)EBX
0x(5)PUSH (6)ESI
0x(5)PUSH (FF7)DWORD PTR SS:[EBP (08)+8]
0x(E8)CALL (F796DBFF)Engine._DllMain@12

now to explain why it jumps 3 bytes from 0x105E18A1 to ( +3 = ) 0x105E18A4

0x105E18A1 = FF75 08

0xFF = 1 byte
0x75 = 1 byte
0x08 = 1 byte

1 + 1 + 1 = 3

0x105E18A1 + 3 = 0x105E18A4

makes sense now? I hope so.



Onward again to how one actually HOOKS that "CALL" of DllMain (this isnt a smart idea, but just a proof of concept, dont go trying to hook the programs entry point......)


remember how:
0xE8 0xF796DBFF
=
(F796DBFF)Engine._DllMain@12

well what if we wanted to call "MyHax0rDllMain" instead

well thats easy, we would do this:
0xE8 0xOFFSETOFOURFUNCTION



You can do this one of 2 ways, if your just hacking the dll itself with its own code (ie bytehacking) - fyi; you CAN bytehack a dll/exe, its very possible, you need to know asm.

1) Bytehacking the File: you could tell it to JMP to another area in the dll instead of Calling DllMain, of course it would crash but if you knew what you were doing it wouldnt crash you could make it do what you want.

2) Editing Memory: Remember the old md5 hacks for 2k4 that Clockwize released? Welcome back to the hell of trying to read over that source, but maybe this time you'll understand what it was doing.

its doing exactly what i showed above^- just its doing it on the fly so it has to protect the memory and protect the registers otherwise the computer will freak out and scream "WTF ARE YOU TRYING TO DO, YOU CAN NOT VIOLATE ME WHEN I AM TRYING TO RUN A PROGRAM! OMG RAPE"

code snippets;

Code:

HMODULE hEng = GetModuleHandle("Engine.dll"); // Open Engine.dll for reading
DWORD TheSuperDuperHax0rOffset = (DWORD)GetProcAddress(hEng, "_DllMain@12"); // Our Hax0r Offset = where DllMain is in Engine.dll (0x105E18A4 - you could hard code this of course)

Now that you have the Location loaded into a Pointer you can use in your source you can VirtualProtect the next 5 bytes in memory

why 5?

0xE8 0xF796DBFF
0xE8 = 1
0xF7 = 1
0x96 = 1
0xDB = 1
0xFF = 1

1 + 1 + 1 + 1 + 1 = 5

fill all 5 bytes with NOPS:
Code:

__asm nop;
__asm nop;
__asm nop;
__asm nop;
__asm nop;



Protect your registers so you dont **** up the stack!!!
__asm pushad ; push all registers
// do what you want here:
// in our case we shall:
__asm call MyHax0rDllMain


reset the registers again!

__asm popad

TADA YOUR DONE

thats several methods of Code Overwritting and 1 example of Detouring!
/me whipes sweat off forehead


Breakpoints via Debugger

breakpoints own! ok well sorta... they are great in so many ways but not (in my opinion) for hooking
debuggers give you an easy way to make use of them

A breakpoint stops (pauses) a program for an extended amount of time to give you the user time to do whatever you wish with the memory that you broke at without ****ing up the program

There are a few drawbacks to using this approach though as debugging a prog will suspend all application threads (will ... physically pause the program)
uh not the best hax0r method...

can also be done through code, too much of a waste to explain


Altering the IAT (Import Address Table)

This is a very clean and efficient way to hook almost anything, if you saw my Unreal Engine Hook tutorial you will see an example of Import Address Table hooking.

In order to make good use of IAT hooking you need to know a good deal about the Portable Executable (PE) Windows File Format and Common Object File Format (COFF)

The most important of the 2 however is the PE File Format, the PE file format is composed of 7 sections, just like our unreal file format is composed of certain things (Header, Name Table, Imports, Exports)

the most important part of the PE File Format is ".idata" .idata is in essence the Import Table and all of the data within it. When a program/module is made it has a lot of 'dependancies' just as our hacks have dependancies in say; 'engine' and 'core' -

Each dependancy in a Win32 application is called an Import (same as uscript)

The best way to determine all of the Imports of a application is to grab information (in an infinite loop) out of .idata - one would think that scanning through all of the imports of an application would bog down the hooking process and take considerable system resources, but thats what is so lovely about IAT, every import of said win32 application is located neatly and cleanly within the Import Address Table! Because it's just that, a Table, with offsets Imports and data, each one composed of nothing more than an indirect call to an import that is 'written' into the IAT with a simple JMP

Scan through .idata, find the function (offset, thunk, et al) that you want ->
and VirtualProtect it again - initalize your typedef and fill it with all the information from what the IAT points to and TADA you just hooked a win32 API Function in the most clean and efficient manner to date (imo)

heres a code snippet for ya'll who havent looked at my source:

Code:

// Globals:
typedef void (WINAPI *ProcessEvent_typedef)(class UFunction*,void*,void*);
ProcessEvent_typedef orgProcessEvent;


// IAT MAJIC
void ReDirectFunction (char* strDllName, char* strFunctionName, DWORD newFuncAddy)
{
DWORD dwBackup;
DWORD dwIndex;
DWORD dwOffset;
HMODULE hEng;
PIMAGE_DATA_DIRECTORY pDataDirectory;
PIMAGE_DOS_HEADER pDosHeader;
PDWORD pdwIAT;
PDWORD pdwINT;
PIMAGE_IMPORT_DESCRIPTOR pImportDescriptor;
PIMAGE_IMPORT_BY_NAME pImportName;
PIMAGE_OPTIONAL_HEADER pOptionalHeader;
PIMAGE_NT_HEADERS pPeHeader;
PSTR strCurrent;

hEng = GetModuleHandleA("Engine.dll");

if(!hEng) return;

pDosHeader = PIMAGE_DOS_HEADER(hEng);
dwOffset = pDosHeader->e_lfanew;
pPeHeader = PIMAGE_NT_HEADERS(long(hEng) + dwOffset);
pOptionalHeader = &pPeHeader->OptionalHeader;
pDataDirectory = pOptionalHeader->DataDirectory;
dwOffset = pDataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress;
pImportDescriptor = PIMAGE_IMPORT_DESCRIPTOR(long(hEng) + dwOffset);

for(dwIndex = 0; true; dwIndex++)
{
dwOffset = pImportDescriptor[dwIndex].Name;
strCurrent = PSTR(long(hEng) + dwOffset);
if(stricmp(strCurrent, strDllName) == 0) break;
}

dwOffset = pImportDescriptor[dwIndex].FirstThunk;
pdwIAT = PDWORD(long(hEng) + dwOffset);
dwOffset = pImportDescriptor[dwIndex].OriginalFirstThunk;
pdwINT = PDWORD(long(hEng) + dwOffset);

for(dwIndex = 0; true; dwIndex++)
{
dwOffset = pdwINT[dwIndex];
pImportName = PIMAGE_IMPORT_BY_NAME(long(hEng) + dwOffset);
strCurrent = PSTR(pImportName->Name);
if(stricmp(strCurrent, strFunctionName) == 0) break;
}

VirtualProtect(&pdwIAT[dwIndex], sizeof(DWORD), PAGE_READWRITE, &dwBackup);

orgProcessEvent = (PrEv)pdwIAT[dwIndex];

pdwIAT[dwIndex] = PtrToUlong(newFuncAddy);
VirtualProtect(&pdwIAT[dwIndex], sizeof(DWORD), dwBackup, &dwOffset);

}



called with:
Code:

ReDirectFunction("Core.dll", "?ProcessEvent@UObject@@UAEXPAVUFunction@@PAX1 @Z", (DWORD)&xProcessEvent);


:]


Now that I got that all aside I will just tell you briefly what Kernel Level hooking is and why you should NOT attempt to do it unless you REALLY know what your doing:

The great thing about playing at the Kernel level is that you have free roam to do whatever the **** you please, every winapi function that is called at a User Level or even higher (OS etc) will pass through Kernel, you have access to it ALL - the only thing you might piss off is an AntiVirus or 2, anticheats cant do SHIT about kernel level romping, shit a stick- anticheats cant do much about USER LEVEL hooking, so you can only IMAGINE how impossible it would be for an anticheat to do much of anything when you play with the kernel

The easiest way (hah easy) to achieve kernel level romping is to do one of the following:

1) get the Win DDK for your respective OS, start reading --- and make simple hooks of shit that you find in ntdll (the resultes of this are monumental as I have seen in almost every game I have hacked using Kernel level hooks with this
method) and its not overly hard to do!

2) Write your own Device Driver
hang on let me sit back for a minute and say
R O F L

yeah... ok thats done. p1p0 is doing that right now and is coming out VERY succesfull, mad ****ing props to him for making the impossible possible! (and at such a young age! insanity >_<!)

3) RING0

lol...

if you know what ring0 is you know why i just laughed
I played there but let me tell you this, **** up once and you will surely see the entire system DUMP and DIE with a BLUE SCREEN OF DEATH

so uh, dont make mistakes :]

ever seen several BSOD's on a NT System in 1 day? I have, its a very disturbing sight

When i was toying with ring0 there was barely ANY documentation out there, and still to this day documentation is severely lacking... if you want to know more about ring0 you can talk to me personally or i HIGHLY suggest you read what this site has to offer:
--- and read ALL of the links he provides, your lucky you can find ANY information on the insides of NT but its there, read!
__________________

[soad56]

h god make an zip file with all files!