Question Genshin Impact — Bypassing mhyprot2 to Attach x64dbg/CE

[byte_corvus]

Dealing with the mhyprot2 kernel driver in certain anime-centric RPGs is always a tedious game of cat and mouse. While the driver is basically a textbook implementation of kernel-level protection, it still effectively bricks most standard debugging attempts. I’ve been reversing the OS version (6.x) and I'm currently looking to bridge the gap between static analysis and live dynamic debugging without getting clapped by the AC.

What's currently working:

At the moment, basic memory access is stable using a handle duplication trick. Instead of fighting

NtOpenProcess

directly, I'm injecting a bridge DLL via

WH_GETMESSAGE

hook.

1. Inject bridge DLL using

   SetWindowsHookEx

2. Inside the game process, call

   DuplicateHandle(GetCurrentProcess(), ..., extProcess, ...)

   to pass a full-access handle to the external tool.
3. This bypasses the need for the external process to ever call

   OpenProcess

   on the target.
4. Inline hooking via MinHook is also functional for internal logic redirection.

The Wall: Debugger Attachment

mhyprot2 is aggressive when it comes to debug objects. It actively blocks

NtDebugActiveProcess

and almost certainly utilizes

ObRegisterCallbacks

to strip debug access rights from any handle that somehow gets through. If you try to attach x64dbg or use the Cheat Engine debugger, it either fails to find the process or the handle is immediately nuked.

Spoiler: Technical Blockers Found

1. NtOpenProcess is hooked/monitored with debug access flags.
2. Debug object creation is heavily restricted.
3. Kernel callbacks strip handle permissions back to basic access.

Potential Vectors for Dynamic Analysis:

I'm weighing a few options here to get a live view of the registers and memory state without triggering a flag:

1. Kernel Callback Nuking — Writing a driver to unregister mhyprot's

ObRegisterCallbacks

It’s the most direct route, but manually unlinking callbacks in kernel space is a quick way to a BSOD or a manual ban if their heartbeat check catches the modification.

2. Hypervisor-based Debugging — Tools like HyperHide or TitanHide are the "clean" way to do this at the hardware level. However, modern AC drivers are getting better at detecting VM signatures or timing discrepancies caused by VM exits.

3. In-Process VEH Debugger — This seems like the lowest-risk approach. Instead of attaching an external debugger, map a lightweight Vectored Exception Handler (VEH) engine inside the game process itself via the existing DLL injection path. It keeps everything "internal," but you lose the luxury of a full x64dbg UI unless you pipe the data out to a custom GUI.

While others are struggling to even get a read handle using public junk injectors, we're looking at proper dynamic analysis. If you're serious about reversing these titles, you need to understand that mhyprot2 isn't just watching your process—it’s watching the kernel's relationship with that process.

Has anyone had any luck with stable hypervisor setups recently, or are we all moving toward internal VEH engines for live analysis?