How Nimbus coexists with EAC and NEP (NEProtect)

Marvel Rivals is protected by three anti-cheat layers, not one. Understanding what each layer does — and what Nimbus does around it — explains both why our patch turnaround is minutes-not-hours and why running a second cheat alongside Nimbus is the single fastest way to get banned.

Layer 1: Easy Anti-Cheat (EAC). A user-mode anti-cheat from Epic. EAC seals the Marvel Rivals process's loaded-module list within ~3 seconds of the game starting — after that point, any new DLL appearing in the process is logged as a foreign load. EAC also enforces a no-debug, no-handle-injection contract on the game process.

*How Nimbus handles EAC:* we inject before the seal closes. The loader watches for Marvel-Win64-Shipping.exe to spawn, attaches at the title-screen render moment, maps the payload using a manual-map vector (not LoadLibrary — that's what EAC instruments). The payload is in-process before EAC's first integrity sweep runs.

Layer 2: NEProtect (NEP). NetEase's in-house kernel driver. NEP loads as a Windows service under a per-session random name (e.g. NEPrsbtt9s, NEPqx3kld7) about 180ms after Marvel-Win64-Shipping.exe spawns. From kernel space it scans the game process's module list for foreign DLLs, watches behavioral patterns (mass ReadProcessMemory from external processes, hook patterns on Present() / EndScene()), and reports findings to the NetEase backend.

*How Nimbus handles NEP:* the manual-map vector keeps our payload out of the PE module list NEP enumerates — there's no entry to find. We also unlink from the PEB (Process Environment Block) loader lists before NEP starts its first sweep. Our render hook uses a vtable-overwrite vector that doesn't leave the canonical hook signature NEP's behavioral scanner watches for.

Layer 3: NetEase backend. The signature DB and ban-issue infrastructure. EAC and NEP report findings; the backend correlates across the player base and issues the actual bans, usually in waves (rather than per-incident).

*How Nimbus handles the backend:* we publish every detection event publicly within 1 hour of confirmation and rebuild the loader against the new signature in minutes (median 14 minutes) using the Resolver pipeline. The backend's signature DB updates faster than most public cheats can recompile; the Resolver is the moat.

Why running a second cheat is fatal. NEP's behavioral scanner doesn't know which DLL did the hooking — it sees a hook is present and reports it. If you run Nimbus alongside a public cheat (Jarvis, sigmarivs, oreorivals, whatever), the public cheat's hook signature trips the scanner, and the backend bans the account, not the specific cheat. Nimbus could be perfectly clean and you'd still be banned because the other cheat's signature was on the same machine. Do not run two cheats at the same time. This is the #1 cause of bans we see in support tickets.

Don't disable EAC. The DisableEAC.exe tool circulating in Discord servers patches the EAC service to fail-open. NEP's kernel driver notices EAC isn't reporting and reports that to the backend as a tamper signal — first-launch ban, no recovery. Nimbus assumes EAC is running normally; the manual-map vector is designed for that environment, not an EAC-bypass environment.

The honest summary. Nimbus's safety record (zero wave-detection events traceable to a Nimbus signature in the last six months) depends on three things you control: don't run a second cheat, don't disable EAC, and don't use Nimbus during a known active incident (check /status before launching after a patch).