Shared Memory Driver - 3000 Users
good morning. seb here. welcome to the cheat analyst section of my blog. today iâm covering a case where i reversed a kernel-mode cheat driver to figure out how it works under the hood.
the goal wasnât to dump comms or go full-blown RE, just wanted to understand how it reads memory, what kind of stealth techniques it uses, and what makes it tick.
initial context
this all started in a random discord convo. someone dropped their driver in my dms asking me if i can try to reverse it:
"yo can u try reverse my driver?" "is this the shared mem u use for ur p2c" "yes but i disabled r/w incase u do get around to fucking it up"
i got the .sys file (around 16kb), and the first thing that stood out, no imports.
no MmCopyMemory, no ObReferenceObjectByHandle.
just a clean PE file with stripped imports and a small footprint.
first impression: minimalism
this driver was tiny. no fancy driversigning junk, no packed layers. but what really caught my eye was the way it was doing memory access.
so i opened it up in IDA and started walking through. didn't bother trying to reverse the full comms, i assumed they were broken or dummy anyway based on what the dev said:
"i disabled r/w" "i didnât disable but like if u try to use it wonât work."
so instead, i focused on behavior.
the memory access method
one of the first real clues came from this line:
InterlockedCompareExchange((volatile signed __int32 *)g_SharedMemControl, casNewVal, casExpected);after reversing some calls to the pointers, g_SharedMemControl, right away that told me itâs using a shared memory control struct to coordinate comms between usermode and the driver.
but to be honest i was surprised the read logic didnât look like anything normal.
instead of relying on standard APIs, it was walking page tables manually.
page table inspection
while stepping through the code, i noticed the driver was scanning through memory using page tables. this means it wasnât calling any normal memory functions, instead, it was:
resolving virtual addresses manually
walking the PML4 -> PDPT -> PD -> PT
checking if pages were valid or present
then reading them directly
no imports needed.
and most importantly, it avoided the return addresse checks on apis used like mmcopymemory. (since it isnt using it obviously)
why this matters
what made this setup unique wasnât some magical exploit, it was the intentional lack of detection surface. just manual memory access using raw paging structures.
however, eac could easily walk all pages and find this memory that isnt backed by a module in psloadedmodulelist - since entry took 0 arguments, we can assume its manually mapped meaning it has no driver object affiliated with it. not only that, but the memory is most likely rwx since they are writing the pe headers into memory which really doesnt help if hvci is enabled. it does nothing to hide itself so its a bit poor overall, and i do not understand how eac has not banwaved this driver yet.
final thoughts
i didnât need to dump the comms to understand the driver really,
this kind of cheat is a great example of âless is more.â and even though i was just reversing it for fun, it gave me a better understanding of what kind of threats anti-cheat developers should actually be looking for in the wild.
not every cheat is loud or trying to blend in. some just walk PTEs and leave no trace.
Last updated