On a previous post I’ve talked about how to perform API hooking at kernel level on 32bit Windows systems to prevent a process from being terminated.
Today I’m gonna talk about OBR and callbacks.aspx), mainly to show how to achieve the same result on 64bit systems starting from Vista SP1 and later.
While studying Windows internals for my job, I had to deepen my knowledge of executable loading process, including their memory layout, address relocations and so on.
I came accross the PEB ( process environment block ), a data structure ( mostly undocumented ) that NT systems use internally to handle many aspects of a process, including a list of loaded libraries, environment variables, command line arguments, heap informations, TLS slots and so on.
The interesting fact about the PEB is that can be inspected to obtain those informations without the use of any standard API, thus resulting in an interesting technique to detect bad written virtual machines, emulators and any sort of sandboxing that could be used by a malware analyst or an anti virus product.
Moreover you could check the PEB to detect if a DLL has been injected into your process to perform api hooking.
API hooking softwares usually hooks API such as EnumProcessModules and patch them to hide the presence of the injected module. Inspecting the PEB you will be able to perform the same task only analyzing your address space, thus avoiding API patching.
This post is about SSDT patching to perform API hooking within the kernel instead of the classic user mode hooking using remote threads and things like that.
SSDT hooking is as far as I know the lowest level technique to replace/hook/intercept/whatever API and for this reason has been used for years both by malwares writers and AV vendors.
I’m using the past tence due to the fact that on 2005 Microsoft introduced a Kernel Patching Protection ( also known as “PatchGuard” ) for 64 bit systems, making this technique uneffective in the worst case or quite harder to perform in the average case.