Hacking
Hacking
As some of you are probably aware, a lot of game companies have recently been cracking
down on "hackers". They've implemented the entire spectrum of userland detection
mechanisms, ranging from the ridiculously simplistic to the incredibly complex. Over the
course of the past few weeks, I have devoted a lot of time to trying to find a general
solution to the problem of detection evasion. In some sense, it juxtaposes our position as
hackers, with that of the game companies. To exploit a game you have to find only one
flaw in their system whereas they have to design a system without any flaws. Similarly,
when we hide ourselves from their detection code, all they have to do is spot a single
mistake of ours, and it is us who are charged with devising and implementing the perfect
system. The below article is my attempt at accomplishing this. It is by no means complete
or perfect, but I'd like to think that it is a first step in that direction.
For this purpose i'm going to assume we need to load a module into the target(as we do in
the case of most game hacks or bots). We must recognize two distinct instances in which
a rogue module could be detected. Upon injection and then the rest of the time.
Nearly every dll injection method involves calling LoadLibrary at some point or another.
So a simple way to catch any modules you wish to detect is to hook LoadLibrary(or
LdrLoadDll, or whichever other lower level native
API's).
This problem can be solved in one of two ways. The first and simplest being
randomization of the modules name. Since a great many legitimate pieces of software
inject dll's into every process on the system(Trillian, AIM, hotkey software, etc..) no
reasonable detection system can use a "white list" design(detection that involves making
sure only verified modules are loaded, and considering anything that isn't explicitly good,
to be bad). So a blacklist must be used, which makes it so that randomized module
nomenclature is a perfectly acceptable solution to this detection technique.
The other method, which I implemented is to use one other method of dll injection, which
i've called "manual mapping". It seemed at first like a very daunting task to emulate the
windows PE loader and make everything
work correctly, but it turns out that it's not really all that difficult. My
ManualMap(appendix) code does just that. It could use a great many improvements, I
know, and in fact I have my own private vastly improved
version, but it's only a proof of concept.
After a module is injected into a running process, it can be detected in two ways. The first
is to scan the module list or call GetModuleHandle on modules that you consider
"hacks". This is mitigated by unlinking your
module from the list using a tool like CloakDll(appendix). Or using something like
ManualMap so the module is never linked in the first place. I think the second solution is
a bit better, but they are more or less the same.
The second way of detecting modules after they've been injected is much more clever. It
is to iterate through every page on the system(pages are aligned on 0x1000 bytes, so this
is actually feasible), and check it for
offending code signatures. This problem can be countered by using a modified dll loader
that randomizes the offset from the page boundaries where the real data actually starts.
However, a better solution I think is
to create two new blank pages enclosing your module. And then use VirtualProtect to set
the PAGE_GUARD flag on these two pages. The PAGE_GUARD flag will generate a
one-shot exception whenever the memory is accessed. Using an unhandled exception
filter, vectored exception handling, or a KiUserExceptionDispatcher hook(I recommend
the latter), you can catch these exceptions. This will let you know when you are being
scanned and allow you to do whatever you like to prevent the detection code from
spotting your module.
To create any worthwhile hacks it is almost always necessary to modify the games code
in some way. However, code modifications are all too easy to detect, and until now
nobody has come up with a viable generalized solution to this problem. I'm afraid I can't
claim to have completely solved it, but I have found a way to tame it a bit.
I've come up with a way to hook functions without modifying any code in the target
process at all. The only drawback is that you can only simultaneously hook 4 functions.
My method is to use the debug registers (i.e. hardware breakpoints). You can see my
implementation of it in the CHook class in the appendix.
Now, debug registers can be detected quite easily. Anyone calling GetThreadContext with
CONTEXT_DEBUG_REGISTERS will see them, any exception handlers will get a
context structure that contains them, etc.. The solution to this is to hook
NtGetContextThread, NtSetContextThread, and KiUserExceptionDispatcher. Of course,
you'd have to use a patch hook for those. Since quite a few antivirus/anti-spam/firewall
programs hook functions like these to help "improve overall system security", it would be
unreasonable for a detection system to label you as a hacker based soley on
the presence of modified bytes in your system dll's. This means that you can hook up to 4
functions without fear of them being detected.
Even though they may not detect you based solely on the presence of those hooks in the
system modules, they still do leave you open to one potential avenue of detection. Which
is to locate your hooks in the system modules,
parse the jump patches and determine where they lead. A subsequent CRC of the hook
procedure would be more than enough for a positive identification.
There are again, two solutions to this problem. One is to hook by using an int03
breakpoint instruction, and then catching exceptions(this is also implemented in my
CHook class if you look hard enough, you'll spot it) and
redirecting them to the proper hook procedure. This would require you to either use a
standard jmp patch hook on KiUserExceptionDispatcher(which would sort of defeat the
purpose) or use one of the two standard forms of SEH.
The other solution which I consider much better, though slightly more difficult to
implement is to write a polymorph engine for your hook procedures. It doesn't have to be
anything too fancy, even randomized NOP-equivalent padding in-between actually
relevant instructions(NOP equivalents are instructions such as mov eax, eax). This would
make any
attempt at CRC checking your functions fail. I haven't yet implemented this method.
However, I might end up writing some PoC code for it at some point.
The easiest method of doing this comes from the area of shellcoding. As i'm sure you all
know, shellcode is often encrypted with a short runtime decrypting loader in order to
evade IDS signatures. That runtime decryption stub is very easy to write a simple asm
polymorph engine for. By simply placing NOP's in-between various instructions and
using randomized encryption keys that change every time it is encrypted or decrypted,
you could make it very difficult if not impossible to create any type of working signature
for your code, without sacrificing too much in the way of performance.
The debug registers are also quite useful for many other interesting purposes. You can
hook memory reads/writes as well as instruction fetches. This means you can create a
callback for memory modification(great for values in memory you want to monitor, this
means you don't have to poll them anymore). A complete description of them can be
found in the appendix.
Another point to consider is that instead of attempting to detect your API hooks, they
could simply disable them by patching over your hooks with the original bytes. This is
easy to do and portable enough for a game company to consider implementing, since the
first few bytes of most API's don't often change between versions of Windows. The
solution to this problem requires us to realize that before being able to write to any
memory in the code section of a process image, you'd have to call VirtualProtect to
change it's page protection temporarily. So, a hook on NtProtectVirtualMemory should
prevent them from simply overwriting all of your hard work.
IV - Conclusion
V - Appendix
ManualMap:
http://www.darawk.com/Code/ManualMap.cpp
Debug registers:
http://pdos.csail.mit.edu/6.828/2005/readings/i386/s12_02.htm
CloakDll:
http://www.darawk.com/Code/CloakDll.cpp
CHook:
http://www.darawk.com/Code/CHook.h
http://www.darawk.com/Code/CHook.cpp
// ManualMap - by Darawk
// Featured @ www.RealmGX.com & www.Darawk.com
//
// The purpose of ManualMap is to "manually map" a dll
// module into a remote process's address space. This
// means that instead of just manipulating the remote
// process into calling the LoadLibrary function, we
// have our own emulation of what LoadLibrary does
// without all those annoying detectability issues ^^.
// The advantage of this method over using something
// like my CloakDll function, is that this method never
// has to call a function like LoadLibrary inside the
// remote process. Since LoadLibrary can be hooked,
// the dll could still be caught at the injection stage.
// Or possibly also through the weakness I discussed in
// the comment header of that file, which is not present
// when using this technique.
#include <windows.h>
#include <tlhelp32.h>
#include <shlwapi.h>
#define IMAGE_DIRECTORY_ENTRY_IMPORT 1
#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5
// Pietrek's macro
//
// MakePtr is a macro that allows you to easily add to values (including
// pointers) together without dealing with C's pointer arithmetic. It
// essentially treats the last two parameters as DWORDs. The first
// parameter is used to typecast the result to the appropriate pointer type.
#define MakePtr( cast, ptr, addValue ) (cast)( (DWORD_PTR)(ptr) +
(DWORD_PTR)(addValue))
PIMAGE_SECTION_HEADER GetEnclosingSectionHeader(DWORD,
PIMAGE_NT_HEADERS);
LPVOID GetPtrFromRVA(DWORD, PIMAGE_NT_HEADERS, PBYTE);
// Stub that calls the Dll from within the remote process.
// This is necessary because a DllMain function takes 3
// arguments, and CreateRemoteThread can pass only 1.
__declspec(naked) void DllCall_stub(HMODULE hMod)
{
_asm
{
push 0
push 1
push [esp+0Ch] // Pointer to the hMod argument
mov eax, 0xDEADBEEF // Patch this in with the real value at run-time
ret // Don't have to clean up the stack because the calling function
// is just going to call ExitThread() immediately after this
// function returns.
}
}
if(hFile == INVALID_HANDLE_VALUE)
return false;
if(ntHd-
>OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].Size)
FixImports(pId,
(unsigned char *)dllBin,
ntHd,
impDesc);
// Fix "base relocations" of the new module. Base relocations are places
// in the module that use absolute addresses to reference data. Since
// the base address of the module can be different at different times,
// the base relocation data is necessary to make the module loadable
// at any address.
IMAGE_BASE_RELOCATION *reloc = (IMAGE_BASE_RELOCATION
*)GetPtrFromRVA(
(DWORD)(ntHd-
>OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].Virtua
lAddress),
ntHd,
(PBYTE)dllBin);
if(ntHd-
>OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].Size)
FixRelocs(dllBin,
moduleBase,
ntHd,
reloc,
ntHd-
>OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].Size);
delete dllBin;
return true;
}
WriteProcessMemory(hProcess,
MakePtr(LPVOID, moduleBase, header->VirtualAddress),
MakePtr(LPCVOID, dllBin, header->PointerToRawData),
header->SizeOfRawData,
(LPDWORD)&n);
virtualSize = header->VirtualAddress;
header++;
virtualSize = header->VirtualAddress - virtualSize;
nBytes += virtualSize;
// Set the proper page protections for this section.
// This really could be skipped, but it's not that
// hard to implement and it makes it more like a
// real loader.
VirtualProtectEx(hProcess,
MakePtr(LPVOID, moduleBase, header->VirtualAddress),
virtualSize,
header->Characteristics & 0x00FFFFFF,
NULL);
}
return true;
}
// If the module isn't loaded in the remote process, we recursively call the
// module mapping code. This has the added benefit of ensuring that any of
// the current modules dependencies will be just as invisble as this one.
if(!GetRemoteModuleHandle(pId, module))
MapRemoteModule(pId, module);
while(itd->u1.AddressOfData)
{
IMAGE_IMPORT_BY_NAME *iibn;
iibn = (IMAGE_IMPORT_BY_NAME *)GetPtrFromRVA((DWORD)(itd-
>u1.AddressOfData), ntHd, (PBYTE)base);
itd++;
}
impDesc++;
}
return true;
}
while(1)
{
unsigned long *locBase =
(unsigned long *)GetPtrFromRVA((DWORD)(reloc->VirtualAddress), ntHd,
(PBYTE)base);
unsigned int numRelocs = (reloc->SizeOfBlock -
sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD);
locData++;
}
nBytes += reloc->SizeOfBlock;
reloc = (IMAGE_BASE_RELOCATION *)locData;
}
return true;
}
if(thSnapshot == INVALID_HANDLE_VALUE)
{
MessageBox(NULL, "Error: unable to create toolhelp snapshot", "Loader", NULL);
return false;
}
pe.dwSize = sizeof(PROCESSENTRY32);
while(retval)
{
if(StrStrI(pe.szExeFile, process) )
{
ProcFound = true;
break;
}
retval = Process32Next(thSnapshot,&pe);
pe.dwSize = sizeof(PROCESSENTRY32);
}
return pe.th32ProcessID;
}
modEntry.dwSize = sizeof(MODULEENTRY32);
Module32First(tlh, &modEntry);
do
{
if(!stricmp(modEntry.szModule, module))
return modEntry.hModule;
modEntry.dwSize = sizeof(MODULEENTRY32);
}
while(Module32Next(tlh, &modEntry));
return NULL;
}
return 0;
}
delta = (INT)(pSectionHdr->VirtualAddress-pSectionHdr->PointerToRawData);
return (PVOID) ( imageBase + rva - delta );
}
// GetProcAddress2 - by Darawk
// Featured @ www.RealmGX.com & www.Darawk.com
//
// GetProcAddress2 is essentially identical to the
// windows API function GetProcAddress, with one
// key difference. GetProcAddress2 does not check
// to make sure the module handle that's passed to
// it is in the loaded modules list. GetProcAddress2
// is designed to be used in conjunction with ManualMap
// or CloakDll. It allows you to access functions that
// have been exported from a dll loaded by ManualMap or
// cloaked by CloakDll. This functionality is necessary
// for plugin-based applications and late-binding functions.
#include <windows.h>
#define IMAGE_DIRECTORY_ENTRY_EXPORT 0
// Pietrek's macro
//
// MakePtr is a macro that allows you to easily add to values (including
// pointers) together without dealing with C's pointer arithmetic. It
// essentially treats the last two parameters as DWORDs. The first
// parameter is used to typecast the result to the appropriate pointer type.
#define MakePtr( cast, ptr, addValue ) (cast)( (DWORD_PTR)(ptr) +
(DWORD_PTR)(addValue))
unsigned int i;
for(i = 0; i < ied->NumberOfNames; i++)
if(!stricmp((char *)GetPtrFromRVA((DWORD)names[i], ntHd, (PBYTE)hMod,
true), func))
break;
return 0;
}
return offset;
}
if(mapped)
offset = GetMappedSectionOffset(pNTHeader, pSectionHdr, imageBase);
if ( !pSectionHdr )
return 0;
delta = (INT)(pSectionHdr->VirtualAddress-pSectionHdr->PointerToRawData);
return (PVOID) ( imageBase + rva - delta + offset);
}
// CloakDll - by Darawk
// Featured @ www.RealmGX.com & www.Darawk.com
//
// The purpose of CloakDll is to allow the user to hide any loaded
// module from the windows API. It works by accessing the modules
// list stored in the PEB, and subsequently unlinking the module
// in question from all 4 of the doubly-linked lists that it's a
// node of. It then zeroes out the structure and the path/file
// name of the module in memory. So that even if the memory where
// the data about this module used to reside is scanned there will
// still be no conclusive evidence of it's existence. At present
// there is only one weakness that I have found in this method.
// I'll describe how it may still be possible to discover at least
// that a module has been hidden, after a brief introduction to how
// the GetModuleHandle function works.
//
// *The following information is not documented by Microsoft. This
// information consists of my findings while reverse-engineering
// these functions and some of them may be incorrect and/or
// subject to change at any time(and is almost definitely different
// in different versions of windows, and maybe even in different
// service packs). I've tried to make my code as version independant
// as possible but certain parts of it may not work on older versions
// of windows. I've tested it on XP SP2 and there i'll guarantee
// that it works, but on any other versions of windows, it's anyone's
// guess.*
//
// GetModuleHandle eventually calls GetModuleHandleExW, which in
// turn accesses the native API function GetDllHandle, which calls
// GetDllHandleEx. And it's not until here, that we actually see
// anything even begin to look up information about loaded modules.
// Whenever GetModuleHandle is called, it saves the address of the
// last ModuleInfoNode structure that it found in a global variable
// inside of ntdll. This global variable is the first thing
// checked on all subsequent calls to GetModuleHandle. If the
// handle being requested is not the one that was requested the last
// time GetDllHandleEx calls the LdrpCheckForLoadedDll function.
// LdrpCheckForLoadedDll begins by converting the first letter of the
// module name being requested to uppercase, decrementing it by 1 and
// AND'ing it with 0x1F. This effectively creates a 0-based index
// beginning with the letter 'A'. The purpose of this is so that
// the module can first be looked up in a hash table. The hash table
// consists entirely of LIST_ENTRY structures. One for each letter
// 'A' through 'Z'. The LIST_ENTRY structure points to the first
// and last modules loaded that begin with the letter assigned to
// that entry in the hash table. The Flink member being the first
// loaded beginning with that letter, and the Blink member being the
// last. The code scans through this list until it finds the module
// that it's looking for. On the off-chance that it doesn't find it
// there, or if the boolean argument UseLdrpHashTable is set to false
// it will begin going through one of the other three lists. If, at
// this point it still doesn't find it, it will admit defeat and return
// 0 for the module handle.
//
// Weakness: The global variable inside ntdll that caches the pointer
// to the last module looked up could be used to at least detect the
// fact that a module has been hidden. The LdrUnloadDll() function
// will set this value to 0 when it unloads a module, so if the cache
// variable points to an empty structure, the only logical conclusion
// would be a hidden module somewhere in the process. This could be
// resolved by using the static address of this variable and simply
// zeroing it out. However, this would make the code specific to only
// one version of windows. You could also scan the address space of
// ntdll for any occurences of the base address(aka module handle)
// of the module you're hiding. However, this would be slow and it
// would clutter up the CloakDll_stub function, because it'd have to
// all be done manually. And i'd have to either use a static base
// address for ntdll...which would probably work on most versions
// of windows, however I really don't like using static addresses.
// Or i'd have to manually locate it by writing my own unicode
// string comparison code, to lookup ntdll in the list by it's name.
// Realistically though anyone trying to detect this way would run
// into the same problem. That their code would not be version
// independant. So, it's unlikely to see any largescale deployment
// of such a technique. However, anyone who would like to solve
// this problem themselves is perfectly free, and encouraged to do
// so.
#include <windows.h>
#include <winnt.h>
#include <tlhelp32.h>
#include <shlwapi.h>
#define UPPERCASE(x) if((x) >= 'a' && (x) <= 'z') (x) -= 'a' - 'A'
#define UNLINK(x) (x).Blink->Flink = (x).Flink; \
(x).Flink->Blink = (x).Blink;
#pragma pack(push, 1)
typedef struct _UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} UNICODE_STRING, *PUNICODE_STRING;
#pragma pack(pop)
bool CloakDll_stub(HMODULE);
void CD_stubend();
_asm
{
mov eax, fs:[18h] // TEB
mov eax, [eax + 30h] // PEB
mov eax, [eax + 0Ch] // PROCESS_MODULE_INFO
mov pmInfo, eax
}
if(!module->baseAddress)
return false;
// This code will pretty much always be optimized into a rep stosb/stosd pair
// so it shouldn't cause problems for relocation.
// Zero out the module name
memset(module->fullPath.Buffer, 0, module->fullPath.Length);
// Zero out the memory of this module's node
memset(module, 0, sizeof(ModuleInfoNode));
return true;
}
if(thSnapshot == INVALID_HANDLE_VALUE)
{
MessageBox(NULL, "Error: unable to create toolhelp snapshot", "Loader", NULL);
return false;
}
pe.dwSize = sizeof(PROCESSENTRY32);
while(retval)
{
if(StrStrI(pe.szExeFile, procName) )
{
ProcFound = true;
break;
}
retval = Process32Next(thSnapshot,&pe);
pe.dwSize = sizeof(PROCESSENTRY32);
}
return pe.th32ProcessID;
}
modEntry.dwSize = sizeof(MODULEENTRY32);
Module32First(tlh, &modEntry);
do
{
if(!stricmp(modEntry.szModule, module))
return modEntry.hModule;
modEntry.dwSize = sizeof(MODULEENTRY32);
}
while(Module32Next(tlh, &modEntry));
return NULL;
}