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