Easy AntiCheat Overall Analysis
after spending a few months locked in on bypassing easy anticheat (specifically the fortnite config), i can say it took way longer than i expected. this post goes over the journey, what i built, what broke, what worked, and what i learned. iâm keeping this safe, so no exploit code or full techniques are shown. iâve reported the key issues to the relevant vendors. this is just a breakdown of my experience as someone building from the ground up.
starting from zero â ioctl phase
my first proper driver came right after learning windows internals. just a basic ioctl driver with hidden handles. at that time, every tiny thing i learned could change the whole picture.
one thing became clear fast: eac is heavily dependent on very specific indicators. even public bypasses, if tweaked just slightly , can avoid detection easily. "undetected" is a word people throw around like candy, but in reality, nothing is undetected unless youâve got it through heavy testing across multiple systems, accounts, and configs. still, yeah, itâs possible.
in my early work, i used gdrv to load the driver, then wiped it from disk. added my own mutation engine and randomized names per machine. in limited local testing, this stayed stable and avoided flagging under standard conditions. eventually, i reported the method to eac and they patched it. my guess? they now check the recent name entries in PsLoadedModuleList, compare them to files on disk, and block you if it doesn't match. that leads to the "please restart or unload your unsigned driver" message.
its not the best patch since you could just rename it (its patched now), but a lot of what eac does feels like surface-level patches. they optimize hard, but often cut corners. itâs not like theyâre lazy across the board, but itâs very clear their team prioritizes scale and speed over depth in some places.
their detection logic â shortcuts all day
for example, their interception prevention was initially just based on .sys file name checks, deadass until i reported it, you could bypass the detection by renaming the file. this was after they released the patch.
what iâve learned from all this: eac often releases quick-fix patches, assumes "no oneâs gonna bother to try," and moves on. itâs almost like they expect their presence to scare off 90% of the scene, and for the remaining 10% theyâll catch with memory scans and stack traces. this genuinely does work for most pasters.
next stage â deep hiding, bad ideas
after the gdrv del file bypass got patched, i started digging into blending drivers to look signed. dumb move looking back but uhh i tried overwriting the entire .text section with mine. idk why i thought it would work but it didnt
after that, i switched focus to hiding my driver and device objects instead. i used NtOpenFile to grab a handle directly to the device, skipping symbolic link. then Iâd hide the device on IRP_MJ_CREATE and bring it back on close.
looked clean, but itâs fake asf and easy to tell since youâre holding a handle to something that "doesnât exist" in the namespace. bait for any decent check.
latest driver â (mostly) undisclosed
canât say too much about this one yet, i disclosed the method, and iâm waiting for epicâs team to finish their review. but here's the gist:
still ioctl-based
used a windows vulnerable driver with no backing module or
.textsizehijacked the object since itâs probably whitelisted
the driver itself is near useless so hijacking it wonât mess the system
surprisingly, the hook method (not the driver i hijacked) i used was already public since 2022 and marked as âdetectedâ, but again, eac's checks are hardcoded asf. i flipped a few flags in the driver object, messed with PTEs (page table entries), and their detection logic failed completely.
this held up with ~30 users who hit high levels and achieved high kill games with no bans observed during testing. i didnât test scaling further. didnt rlly wanna ruin peoples experience
the final boss â nmi callbacks
nmis stand for non-maskable interrupts and are one of the worst things for a cheat dev. from a cheat perspective, eac uses them smart as hell, registering a callback before the interrupt fires, pausing all cores, and checking memory execution flow.
if youâre calling your read millions of times per second, nmi will catch the RIP and unwind the stack back to your code. then simply like that they find your drivers memory
can you spoof RIP or fake the frame? yeah, but most options require hooks or bring in new detection vectors. so you can, but not safely.
my workaround? made every core think an nmi was already in progress. that prevents eacâs from running. yeah, its suspicious and it does flag you, but eac uses tiered flags. this one probably puts you in medium, which is better than immediate kill-switch and them finding your memory. worth noting: memory scanning is where eac absolutely shines. they outclass vanguard there by miles.
conclusion â not all hype is earned
eacâs reputation makes people think itâs impossible to bypass. thatâs not true. itâs strong, but inconsistent. some areas are tight like memory integrity, nmi logic. they use things other anticheats dont. but detection-wise? itâs like a scarecrow wearing body armor. looks solid from a distance, but kick it once and the whole thing falls apart. change one thing, and you're through.
if youâre serious about understanding kernel defense, studying eac gives real insight into tradeoffs between performance, detection, and realism. but donât assume everything they do is clean or deep. shortcuts are everywhere unfortunately and thats how it always will be. cheating and anti-cheats is just a cat and mouse game. a new method is discovered, its patched and it'll always be in a loop until these anticheats stop taking shortcuts and think ahead. i hope eac decides to change their ways with lazy checks.
disclaimer
this post is a retrospective look at my personal kernel security research. all vulnerable behaviors discussed were responsibly disclosed through proper channels. no exploit code, bypass steps, or private information is shared. this is not an encouragement or guide to develop cheats â itâs an analysis of real-world anticheat behavior from a technical perspective.
Last updated