Windows Device Driver Analysis -- 2
Budget: $3,000 – $5,000 AUD
This project focuses on the reverse engineering and security analysis of a Windows kernel-mode driver used in an anti-cheat system. The objective is to understand how the driver performs system integrity checks at the kernel level specifically how it detects unauthorized or suspicious kernel modules and to derive practical recommendations for safely loading a driver in such an environment.
Importantly, this is not a full reverse engineering of the entire driver. The scope is limited to identifying the specific detection mechanisms the anti-cheat driver uses to scan the kernel, focusing on the Windows API calls and kernel structures it interrogates. The goal is to determine what traces a manually loaded driver leaves behind and how to avoid detection by cleaning or spoofing those traces appropriately.
The analysis will examine how the anti-cheat driver enumerates loaded kernel modules and inspects key system structures, including:
PiDDBCacheTable – how it verifies loaded driver records
MmUnloadedDrivers – how it tracks recently unloaded drivers
g_KernelHashBucketList (ci.dll) – hash validation data
Wdfilter RuntimeDriverList – Windows Defender's driver tracking
PoolBigPageTable – large executable memory allocations
System thread stack traces – validation of call stacks
PsLoadedModuleList – the primary loaded module list
Compiler artifacts – recognizable byte patterns from static linking
Based on these findings, the project will document exactly which structures and functions the anti-cheat monitors and provide clear guidance to a kernel developer on how to implement a loader that avoids detection. This includes:
Which kernel structures must be cleaned or spoofed (and how to do so without triggering alarms)
Which Windows API calls and functions to avoid because they leave detectable traces
How to safely perform memory read operations from a hidden driver without raising flags
A practical checklist of traces to eliminate, with specific implementation notes
The final deliverable is a concise technical report written for a kernel developer. It will not attempt to reverse the entire driver that would be outside scope and unnecessary. Instead, it will focus on the anti-cheat's kernel visibility and detection patterns, translating those observations directly into actionable development requirements for building a driver that can coexist with the anti-cheat undetected.
The goal is simple: give the developer a clear understanding of what the anti-cheat looks for and exactly what needs to be done to avoid those flags nothing more, nothing less.
-DISCLAIMER-
This is not a full driver reversal. The scope is strictly limited to kernel-space elements: identifying the specific detection mechanisms the anti-cheat driver uses to scan the kernel, focusing on the Windows API calls and kernel structures it interrogates. Any analysis beyond what is necessary to answer these questions is out of scope.
If the applicant is professional and delivers quality work within this defined scope, this initial engagement is estimated at approximately five months. Should the driver receive updates during or after this period, and provided the applicant's work meets expectations, there is a clear path to continued collaboration on an ongoing basis. If you belive the job requires more money feel free to communicatie with me. can send resources from whats already known and you just have to confirm.
You will need to sign a NDA
Importantly, this is not a full reverse engineering of the entire driver. The scope is limited to identifying the specific detection mechanisms the anti-cheat driver uses to scan the kernel, focusing on the Windows API calls and kernel structures it interrogates. The goal is to determine what traces a manually loaded driver leaves behind and how to avoid detection by cleaning or spoofing those traces appropriately.
The analysis will examine how the anti-cheat driver enumerates loaded kernel modules and inspects key system structures, including:
PiDDBCacheTable – how it verifies loaded driver records
MmUnloadedDrivers – how it tracks recently unloaded drivers
g_KernelHashBucketList (ci.dll) – hash validation data
Wdfilter RuntimeDriverList – Windows Defender's driver tracking
PoolBigPageTable – large executable memory allocations
System thread stack traces – validation of call stacks
PsLoadedModuleList – the primary loaded module list
Compiler artifacts – recognizable byte patterns from static linking
Based on these findings, the project will document exactly which structures and functions the anti-cheat monitors and provide clear guidance to a kernel developer on how to implement a loader that avoids detection. This includes:
Which kernel structures must be cleaned or spoofed (and how to do so without triggering alarms)
Which Windows API calls and functions to avoid because they leave detectable traces
How to safely perform memory read operations from a hidden driver without raising flags
A practical checklist of traces to eliminate, with specific implementation notes
The final deliverable is a concise technical report written for a kernel developer. It will not attempt to reverse the entire driver that would be outside scope and unnecessary. Instead, it will focus on the anti-cheat's kernel visibility and detection patterns, translating those observations directly into actionable development requirements for building a driver that can coexist with the anti-cheat undetected.
The goal is simple: give the developer a clear understanding of what the anti-cheat looks for and exactly what needs to be done to avoid those flags nothing more, nothing less.
-DISCLAIMER-
This is not a full driver reversal. The scope is strictly limited to kernel-space elements: identifying the specific detection mechanisms the anti-cheat driver uses to scan the kernel, focusing on the Windows API calls and kernel structures it interrogates. Any analysis beyond what is necessary to answer these questions is out of scope.
If the applicant is professional and delivers quality work within this defined scope, this initial engagement is estimated at approximately five months. Should the driver receive updates during or after this period, and provided the applicant's work meets expectations, there is a clear path to continued collaboration on an ongoing basis. If you belive the job requires more money feel free to communicatie with me. can send resources from whats already known and you just have to confirm.
You will need to sign a NDA