Intercepting all System Calls by Hooking KiFastSystemCall

Usually I don’t post things like this, but because KiFastSystemCall hooking only works on x86 systems and doesn’t work on Windows 8 or above, it no longer has much use in malware. There are also multiple public implementations for this method, just not very elegant, which I hope to correct.

If you haven’t read my previous article about this topic, or need a refresher, you can find it here.

Performing a System Call

KiFastSystemCall has a very strange calling convention (if you can call it that). Each native function (Ex: NtCreateFile) corresponds to a function with the same name in the SSDT. In order to make the transition from user mode to kernel mode, the instruction “sysenter” is used.
I don’t want to go into great detail on how the sysenter instruction actually enters kernel mode, as that would take up the entire page, but I’ll explain the basics:
  • The SSDT is an array of addresses for each native function.
  • The number you see being moved into the eax register is known as its ordinal, and is the position within the SSDT where that functions address is located. 
  • When the sysenter instruction is executed the kernel reads the ordinal from eax and uses it to call the corresponding function in the SSDT, before returning execution to usemode.
Something important to note is that the native function simply calls KiFastSystemCall and doesn’t even set up a stack frame, meaning the address of the first parameter can only be accessed using [esp+8], so we can’t just hook KiFastSystemCall with a C function, as this matches no standard calling convention (which is what makes the method so tricky to implement).

Dispatching Calls

Since the last article I’ve improved on the dispatching method, which now has two purposes: 
  1. Determining which native function made the call to KiFastSystemCall, so we can properly handle it.
  2. Setting up the stack in such a way that we can access the parameters using plain C.
Normally we’d hook each individual function we want to intercept with a single handler (proxy), but all native functions call KiFastSystemCall, so we need to think differently. 
As I explained earlier, the SSDT is an array of addresses and the ordinal (which is in eax when KiFastSystemCall is invoked), corresponds to the position of that function’s address within the SSDT. Using this knowledge we can do the same: We create an array of addresses for the the proxy functions and use the ordinal to locate the correct handler using the ordinal in eax. For our SSDT each entry will be 8 bytes, so the handler needs to be placed at our_ssdt[2*ordinal] (in order to get the ordinal for a native function we just read 4 bytes starting at the 2nd byte of the function). 
You’re probably wondering why each entry for our SSDT is 8 bytes, instead of 4; this is because in order to set up the stack before calling the proxy, we need to know how many parameters were passed to KiFastSystemCall (we store the proxy address as the first 4 bytes and the number of parameter as the rest).
Preparing the Stack
When KiFastSystemCall is invoked, there are two return addresses between the stack pointer and the function parameters (the return from KiFastSystemCall to the native function and the return from the native function). In order to call the proxy function we will get the number of parameter for the function from our_ssdt[2*ordinal+4] and push them to the stack again, in stdcall format (the proxy function is responsible for removing them from the stack). The last thing that is pushed to the stack before we call the proxy is the eax register (the ordinal), we will need this later if we wish to call the original, non hooked, version of KiFastSystemCall.

The Code

FstHook – This is my own C library which allows a program to easily hook any number of native function using a single hook on KiFastSystemCall.
Everything is pretty well commented and self explanatory, but if you have any questions feel free to email me on [email protected]
Best Languages to Learn for Malware Analysis

One of the most common questions I’m asked is “what programming language(s) should I learn to get into malware analysis/reverse engineering”, to answer this question I’m going to write about the top 3 languages which I’ve personally found most useful. I’ll focus on native malware (malware which does not require …

Investigating Command and Control Infrastructure (Emotet)

Although the majority of botnets still use a basic client-server model, with most relying on HTTP servers to receive commands, many prominent threats now use more advanced infrastructure to evade endpoint blacklisting and be resilient to take-down. In this article I will go through and explain my process of identifying …

Creating a Simple Free Malware Analysis Environment

Computer Requirements: A CPU with AMD-V or Intel VT-x support (pretty much any modern CPU). 4 GB RAM (more is better). Make sure Virtualization (AMD-V or Intel VT-x) is enabled in the BIOS. To do this, you’ll need to google “enable virtualization” along with your bios or motherboard version, then …