This will be a series of posts related to XignCode3 (XC3) Driver. I started this at the beginning of 2019 while I was doing my research for Unveiling the underground world of Anti-Cheats. Due to that, you will find that the version of XC3 is not the lastest one available.
Reversing a Driver of this kind is not only fun but also let you learn a lot about Windows Internals. That said, I will be as short and precise as possible, and I will try to write down some highlights of what I think are some interesting code snippets or features of this driver.
What we will go through?
- Learn about the DriverEntry
- Learn to identify this function on the binary
- Identify how the Driver Object is created
- Analyze the Major functions implemented, especially the dispatcher one
- Detect some additional code, which we don’t know what it does. Yet.
You can also find here the final result of reversing the function DriverEntry.
Where do I begin?
Getting the .sys file, of course. If you want to reverse this by your own, these are the hashes of the file I used:
- md5: C82DE0BC9A3A08E351B9BFA960F8757A
- sha1: F3AE1406B4CD7D1394DAC529C62BB01F3EB46D4A
- sha256: E7994B56152955835B5025049ABEE651E9C52A6CCAD7E04F2C458C8568967245
When I want to reverse a Driver, I usually like to start with the DriverEntry. In this function, we can find some interesting details that will help us identify most of the features that a driver has implemented.
IDA Pro and Ghidra are usually able to detect this function automatically. But sometimes you may have to do this manually. As the Microsoft site says:
“DriverEntry is the first driver-supplied routine that is called after a driver is loaded. It is responsible for initializing the driver.”
Basically we need to look for a function that calls to IoCreateDevice, this is usually done inside of the DriverEntry, and it is used to create a new device object. This is just one way to do it, but since IDA did it automatically for us, let’s jump straight to the reversing phase.
To keep this post clean, you can see here how DriverEntry was decompiled by IDA Pro at the very beginning, and here the assembly. I encourage you to take a few minutes to read the code and try to identify the main goal of the function before continuing with your reading. Let’s see how we can clean this up. Sometimes renaming and changing the types of the variables can be 50% of the work and of course, will help us to understand the function better.
We know that DriverEntry receives two parameters: a _DRIVER_OBJECT pointer and a PUNICODE_STRING with the registry path. So, we will change the name and type of those two variables.
Something to take into account is that many of the structure types we need when reversing are not available by default on IDA Pro. Therefore, we can import them by doing: “File->Load File->Parse C Header file…”.
Going back to the code, we have some validations and concatenation of the SymbolicLinkName and the DeviceName, nothing weird. They are just setting up the required strings:
DriverEntry needs to implement some particular “required responsibilities or routines” as explained here. Let’s see how they did it before calling IoCreateDevice:
I renamed a few variables and functions to describe their main purpose. However, let me explain how you can easily identify them:
Here we can see all the IRP Major Function Codes available on Windows. In the previous snippet of code, only the numbers 0, 2 and 4 have been implemented:
- IRP_MJ_CREATE 0x00
- IRP_MJ_CLOSE 0x02
- IRP_MJ_WRITE 0x04
A full list can be found on my github.
IRP_MJ_CREATE and IRP_MJ_CLOSE are just generic functions. The interesting one is IRP_MJ_WRITE, which will handle the requests coming from user-mode and it is implemented on fn_DriverIOCTLDispatcher. I will explain in another post how this function works and how it dispatches every IRP request. For now, we will focus on interesting functions that DriverEntry calls.
After some analysis of the inner behavior of the functions that are being called, we can get to the following code:
Some interesting names have appeared:
- and fn_RegisterCreateProcessNotifyRoutine
As you may have noticed I tend to write very descriptive names haha. Those names might be wrong or not, depending on what we discover during the reversing process later. As I mentioned, most of this work has been done months ago. Sometimes reversing has a lot of guessing, so we need to start to imagine what each function could potentially do and give them names so we can picture the goal of every single one of them.
The name is based on what I could infer about those functions. We are going to see them in depth in the following posts.
We can basically separate them into two groups based on their goals. The functions that register some kind of callback; fn_InitRegistrationNotifyAndCallbackRoutines and fn_RegisterCreateProcessNotifyRoutine. And the function that inits basic information that the Driver requires in order to work; fn_InitDispatchMethodArray and fn_ObtainKernelFunctions.
- Analyzing init functions (fn_InitDispatchMethodArray and fn_ObtainKernelFunctions)
- Analyze Dispatch function (fn_DriverIOCTLDispatcher)
- Analyzing Registering Notify and Callback Routines (fn_InitRegistrationNotifyAndCallbackRoutines and fn_RegisterCreateProcessNotifyRoutine)