KO | EN

GitLite

Minimalist Open Source Repository Search Engine

gitlite — search

#developer-tools #codex #typescript #ai-agents #ai-agent #cli #claude-code #open-source #deepseek-harness #dsh-plugin #python #mcp

sot-eac-kernel-bypass

★ 5 Open GitHub ↗

Kernel-mode driver for Sea of Thieves that manually maps DLLs into the game process while fully bypassing Easy Anti-Cheat. Uses PTE NX-bit manipulation for stealth memory, Steam Overlay Present hook hijacking for threadless execution, and shared memory IPC — no driver object, no remote threads, no detectable traces. Currently working as of Feb 2026

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# sot-eac-kernel-bypass

kernel driver that injects DLLs into Sea of Thieves bypassing EAC. manual maps the dll, hides executable memory from the anticheat using page table manipulation, and triggers execution through the steam overlay — no threads, no driver object, nothing for EAC to find. still undetected as of feb 2026.

---

## background / how i got here

so i wanted to inject a cheat dll into sea of thieves. sounds simple right? except EAC (easy anti cheat) is running in kernel mode and it checks basically everything. i tried all the normal stuff first — CreateRemoteThread, APC injection, SetThreadContext — all got flagged instantly. like literally within seconds the game would close.

spent about 2 weeks figuring out what EAC actually checks and how to get around each thing individually. this readme is basically me explaining what i did and why, its not super organized but whatever

## no driver object

first problem: EAC enumerates all loaded drivers. if you register a DriverObject with a device etc its game over immediately.

so my driver just... doesnt have one. the DriverEntry has a weird signature (`PVOID, DWORD64` instead of the normal `PDRIVER_OBJECT, PUNICODE_STRING`) because its not meant to be loaded normally. you map it with kdmapper or something similar. DriverEntry spawns one system thread with `PsCreateSystemThread` and thats it. no device, no symbolic link, no nothing. EAC cant find what doesnt exist i guess

## communication

obviously cant use IOCTLs because EAC monitors that. i use a shared memory section instead (`\BaseNamedObjects\Global\SOTInjectConfig`). the usermode loader creates it, writes the target PID and dll path, driver opens it and reads everything from there. no IOCTLs needed.

the section name is built char by char at runtime btw. no static strings in the binary that scanners could find. maybe overkill but idk better safe

## process readiness

before injecting i need to make sure the game process is actually ready. i attach with `KeStackAttachProcess` and walk the PEB loader data looking for kernel32.dll. if its loaded, process is ready. retries every 500ms, up to 60 seconds total. sea of thieves takes forever to start so yeah

## the steam overlay thing

ok so this is probably the most important part. i need to somehow execute code in the game process but i cant create threads because EAC detects that.

what i figured out: steam's overlay hooks the games Present function (IDXGISwapChain::Present). it stores the original function pointer in a global inside `GameOverlayRenderer64.dll`. i found the exact offset by loading the dll in IDA — its at `+0x1621D8`, theres a qword there that holds the real Present address.

so the idea is: from kernel mode, find that dll in the process, read the original Present pointer, then later replace it with my shellcode. the game calls Present every frame so my code runs automatically. no thread creation at all.

honestly i was surprised this worked first try. well not first try but like third try lol

## manual mapping

the driver reads the dll file into kernel pool memory and then does a full manual map into the game process. nothing too crazy here but some parts were annoying:

**sections** — allocate SizeOfImage bytes with `ZwAllocateVirtualMemory`, copy PE sections. standard stuff

**relocations** — process DIR64 and HIGHLOW relocations. the image always gets rebased so this always runs

**imports** — ok this part sucked. cant use GetProcAddress or LdrLoadDll because EAC hooks those (or at least monitors them, not 100% sure). so i walk the PEB module list myself, find the exporting dll, parse its export table manually. works fine for normal dlls but then i ran into the api-set thing. modern dlls import from `api-ms-win-crt-runtime-l1-1-0.dll` and stuff like that which arent real dlls. had to build a resolver that maps those to the actual dlls — crt stuff goes to ucrtbase.dll, core stuff to kernelbase.dll, vcruntime to ntdll. probably not complete but covers everything my dll needs

**the PTE trick** — ok this is the cool part and the main reason EAC cant detect the injected memory.

normally youd call `ZwProtectVirtualMemory` with `PAGE_EXECUTE_READWRITE` to make your code executable. but EAC walks the VAD tree and looks for executable memory that isnt backed by a legitimate module. instant detection.

what i do instead: i leave everything as `PAGE_READWRITE` in the VAD. then i go directly into the page table entries and clear the NX bit (bit 63) for the pages that need to be executable. to find the PTE base i scan ntoskrnl's .text section for the MiGetPteAddress pattern (`48 C1 E9 09 48 B8`). then for each page in executable sections i just clear bit 63 in the PTE and flush TLB with `__writecr3(__readcr3())`.

result: NtQueryVirtualMemory says its RW memory. but the CPU sees the PTE and executes it fine. EAC has no idea. i think i found this idea from some random post about VAD vs PTE inconsistency, then looked at the intel manual (vol 3) to understand how it actually works. took me a while to get right tbh, had a bunch of BSODs before i got the TLB flush correct

**exception handling** — almost forgot about this. the mapped dll uses C++ exceptions so i need to register the .pdata section via RtlAddFunctionTable. without this every try/catch crashes. learned that the hard way

## shellcode execution

i build a small shellcode (~160 bytes or so) that does:
1. calls RtlAddFunctionTable for exception support
2. calls the dlls entry point (DllMainCRTStartup) with a flag page as lpReserved — flag page has the original Present address and the pointer location
3. jumps to original Present so the game keeps rendering

then i just overwrite the overlay's Present pointer with my shellcode address. next frame the game calls Present, hits my shellcode, dll initializes, and the dll itself restores the original Present pointer from the flag page.

so its a one-shot thing. after that first frame everything is back to normal. clean stack traces from then on.

## fallback if no steam overlay

if the overlay isnt loaded (disabled or whatever) theres a fallback. i find a syscall stub in ntdll like NtWaitForSingleObject (pattern match the `4C 8B D1 B8` prologue), save original bytes, and patch in a jump to my shellcode. the shellcode uses `lock bts` for atomic one-shot execution then restores the original stub. works but the overlay method is cleaner

---

## detection stuff

been running this for weeks now, no ban so far. heres what EAC checks and why this avoids it (as far as i understand it):

- **threads** — i dont create any. execution comes from the games own Present call
- **VAD flags** — all memory is PAGE_READWRITE. the executable bit is only in the PTEs which NtQueryVirtualMemory doesnt report
- **driver objects** — there is no driver object. nothing to enumerate
- **IOCTLs** — no device, no irps. shared memory only
- **module list** — dll is manually mapped, not in any loader list
- **imports** — resolved manually. no LdrLoadDll calls
- **pool tags** — randomized with rdtsc. no fixed tag
- **stack traces** — shellcode is one shot. after first frame, Present is restored, stack is clean
- **string sigs** — section name built at runtime char by char

i might be wrong about some of these. EAC changes their stuff all the time. but so far so good

---

## how to build

you need WDK and visual studio 2022 with kernel driver stuff installed. windows sdk 10.0.26100.0 or whatever version you have should work

the vcxproj is already set up:
- entry point is DriverEntry
- subsystem native
- `/kernel /GS-`
- links ntoskrnl.lib, hal.lib, wmilib.lib
- no CRT, no manifests

```
msbuild driver.vcxproj /p:Configuration=Release /p:Platform=x64
```

output goes to `bin\Release\driver.sys`

to load it use kdmapper or any vuln driver mapper. do NOT try to load it through service control manager, it will not work (wrong DriverEntry signature on purpose)

---

## epstein files

```
main.cpp              - all the driver code, single file ~1060 lines
ntoskrnl_apc.def      - def file for some unexported ntoskrnl stuff
driver.vcxproj        - vs build project
README.md             - this
```

---

![Just a proof picture if forgot to add fuck u](https://media.discordapp.net/attachments/1460951389659205655/1474591130564952228/image.png?ex=699a6782&is=69991602&hm=9d37b5a282800317f86d60b9c74b76b4892834eab684c9e758ee65e2bbd6feb9&=&format=webp&quality=lossless&width=1536&height=864)

## disclaimer

educational purposes only etc. dont use this to cheat in online games. or do idc im not your mom

sot-eac-kernel-bypass

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README