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.
If you try to search for some code samples or documentation about this topic, you will find that almost anyone will say that denying a computer administrator to terminate a process is wrong, so process self-protection should be avoided.
This is true 99% of the cases, the remaining 1% are those cases when a process is vital for the system infrastructure security such as anti malwares, IPS and IDS. Those kind of softwares have to protect themself from malicious software trying to terminate their services and processes or inject arbitrary code into their executable address space, so that’s when an appropriate protection is vital.
No matter how hard you try, there’s really no 100% safe way to do this in user mode … you could try API hooking, passive monitoring, process sandboxing, whatever, there’s always a way to bypass a user mode protection. API hooks can be overwritten, monitoring can be eluded with straight calls to ntdll and obfuscation, sandboxing can be detected.
That’s why kernel patching was the most used technique on pre Vista systems, once you are in the kernel you have full power and the lowest level possible vision of what is happening on a computer, moreover you don’t need to handle all the abstractions a user mode environment implies.
When you talk about working in the Windows kernel, you talk about developing a driver, that’s why Microsoft implemented a set of brand new API to intercept and eventually filter events and actions on object handles before they are actually executed by the kernel.
Enough talking, let’s see how the ObRegisterCallbacks is defined:
This function accepts an input structure pointer that defines what object handles you want to monitor and which actions on them and gives you back a RegistrationHandle i.e. a global object we will use from now on to work with those callbacks.
The OB_CALLBACK_REGISTRATION structure content:
The Altitude field is basically the load order.aspx) you want your driver to be loaded at, RegistrationContext is an arbitrary object you want to be passed down to your callbacks and finally the OperationRegistration field is a pointer to an array of OB_OPERATION_REGISTRATION structures which defines every detail of our callback. So let’s say we want to intercept every access to object handles of processes ( OpenProcess, etc ), we would declare:
YourPreCallback and YourPostCallback are obviously two routines that will be called before the process handle is actually opened ( the pre callback ) and after the operation is completed ( post callback ).
For our purposes, the post callback can be declared just as:
While the pre callback will do all the dirty work for us ( we want to block an unauthorized access to our processes before they’re actually performed, right? )
What this callback is doing, is preventing process with PID 1234 from being accessed with PROCESS_TERMINATE, PROCESS_VM_OPERATION, PROCESS_VM_READ or PROCESS_VM_WRITE privileges, so any malicious software that will try to terminate it or to call API such as (Write|Read)ProcessMemory will inevitably fail with the good old 0x00000005 error ( ACCESS_DENIED ).
When your driver unloads, don’t forget to call ObUnRegisterCallbacks on the RegistrationHandle you’ve previously saved on a global object to correctly inform the kernel that you are not going to intercept those operations anymore.
Well, easy peasy, this is how AV and security softwares are being protected nowdays on 64bit systems from malicious termination, code injection, credential theft from memory (well you are just an idiot if you keep sensible data as clear text in memory -.-) and any kind of manipulation which could lead to the system damages.
Please Donate To Bitcoin Address: [[address]]
Let's stay in touch!