IOCTL Driver - 900 Users
Good morning! seb here, back again breaking down another Fortnite cheat driver.
this one was mid. nothing crazy. but i still wanted to walk through the analysis and drop some notes on how i broke it down.
dumping the driver
since the driver was mapped with kdmapper, it wasn’t as simple as grabbing a file. no PE on disk, no obvious handles. so instead, i hooked the MajorFunction table in Intel’s vulnerable driver and dumped the raw memory during write calls, basically catching every payload it passed through.
to rebuild the image, i used PE-Dump-Fixer to restore the PE headers. after that, i tossed it into IDA and got to work.
reversing the comms
first thing i checked: I/O control logic. the MajorFunctions were being set manually, so finding the dispatch table and tracking the IOCTLs was quick.
turns out the driver used a basic security verification check through a hardcoded string. and yeah, it was literally sitting in the binary 💀. converted it to hex and boom, i could now use this rubbish.
reused code and lazy detection
digging deeper, i started seeing code from public cheat sources. literally pasted straight off GitHub. i saw:
the same CR3 caching method from a 2022 paste
reused memory reading logic
and a usermode comms setup that’s been public since 2020
they used gdrvloader to load the driver and i guess somehow eac just ignored an unsigned driver on 900 peoples computers that were probably getting reported for cheating
still… it was somehow in use by 900+ users. deadass wild.


detection and final thoughts
wrote a clean 20-line detection routine. no signature scanning, zero false positives. just logic-based detection from how the IOCTLs and memory ops were structured.
nothing new here, just a super average IOCTL driver, half-pasted and half-held together by duct tape. no clue how EAC missed this, but they did.
Last updated