• File Name: EMAC-Driver-x64.sys
• TimeDateStamp: 0x67CAFFCE (Friday, 7 March 2025 14:16:46 GMT)
• Protector: VMProtect 3.8+

Globals

There are a few interesting “globals” which can lead to some assumptions, for example:

Some are pretty straightforward, like finding syscall indexes dynamically, getting module information from PEB, addresses for tables/dispatchers often used for integrity check, offsets for dynamic system structs and the list goes.

At initialization, the driver resolves a large set of kernel symbols, tables, and offsets stored as global variables using three resolution methods:

1. Export lookup — EmacFindExportByName walks PsLoadedModuleList and parses PE export tables
2. Pattern scanning — EmacFindFunctionByPattern / EmacResolveKernelTableByPattern scans for byte patterns in kernel modules
3. Disassembly-based resolution — Uses bddisasm (NdDecodeEx) to analyze function prologues and extract dynamic offsets from instructions

Here’s a summary of the key resolved globals:

Let’s take FindNtPsLoadedModuleResource as an example:

tries to obtain address by export

fallback to famous ‘FindPattern’ search

Why i don’t like dynamic search

The main thing that leads me to confusion is why the fuck there’s dynamic search for these symbols; like i said it’s a symbol so i wonder why not simply obtain symbol’s and parse its information!? There’s nothing wrong with using FindPattern i guess, but me personally would rather parse symbols, specially because this is a demand driver so obtaining addresses in the driver logic itself is not necessary.

They even take it as far as using a disassembly engine, creating a smart logic to obtain offsets dynamically.

They’re using bitdefender/bddisasm

Extra

For some reason they have checks for ancient Windows versions like 7, 8 and 8.1. This leave me wondering why this code is still left here, Windows 7 for example is not actively supported on Steam for quite a while, and i am pretty sure Windows 10 is the minimum OS required for Counter-Strike: 2. This is honestly dead code, since it will never be actually used/ran.

Version-Dependent Offsets

The driver dynamically resolves KTHREAD structure offsets at runtime based on Windows version, which are used extensively in the thread stack trace verification and other integrity checks:

ExPreviousMode Manipulation

One interesting technique i found is that the driver modifies the calling thread’s PreviousMode to KernelMode before calling certain Nt* functions, then restores it after. This allows kernel code to call Nt* APIs that normally expect user-mode callers, bypassing ProbeForRead/ProbeForWrite checks:

KPROCESSOR_MODE oldMode = KeGetCurrentThread()->PreviousMode;
KeGetCurrentThread()->PreviousMode = KernelMode;
NtQuerySystemInformation(...);
KeGetCurrentThread()->PreviousMode = oldMode;

The offset of PreviousMode in KTHREAD is also resolved dynamically via EmacGetVersionDependentOffset.

Assumptions

Some of those globals are self-explanatory, for example FindNtWmipSMBiosTableLength surely will be used to extract information about SMBIOS, FindWin32kbase_gDxgkInterface this will get the gDxgkInterface table and will perform integrity check later, FindNtKdpDebugRoutineSelect and FindNtKdpTrap[2,3] will be used to verify global exception hooks, FindNtPiDDBCacheTable and FindNtMmUnloadedDrivers are both very known tables that contain information about unloaded drivers ultimately leading to traces if not cleaned correctly, and the list goes…

Important Global Variables

After deeper analysis, here’s a reference of the most important global variables used throughout the driver:

Conclusion

I decided not go so deep into that subject initially, but with further analysis i was able to document most of the globals and their purposes. If you’re curious then take a look at the .IDB