// the find
wwweeeqqu/honor-of-kings-RE-research
Full-stack mobile game-security research (Honor of Kings / sgame): kernel-mode cross-process memory reading (KernelPatch KPM), Tencent ACE anti-cheat & IL2CPP/native engine reverse engineering, and a real-time ESP overlay. Educational / research only; no proprietary binaries.
A full-stack reverse engineering research project targeting Honor of Kings (王者荣耀): kernel-mode cross-process memory reading via KernelPatch KPM, complete anti-cheat (Tencent ACE) teardown, and a working real-time ESP overlay. The distinguishing feature is 109 timestamped research journal entries that document every wrong turn, not just the final result. Aimed at Android/ARM64 security researchers and anti-cheat engineers.
The research journal is the real product here — documenting false starts like 'IL2CPP is the wrong layer' and 'hardware breakpoints wedge the entire machine on BOLT kernels' is something almost no RE project does, and that institutional knowledge is worth more than the code. The anti-detection reasoning is sound: reading memory via KPM supercall never touches sgame's syscall path, so ACE's /proc/maps scan sees nothing — the 500-read-zero-crash result isn't luck, it follows from the architecture. The FakeFow finding has lasting value for any game security engineer: a deterministic lockstep game cannot hide data from clients because every client must simulate everything, which is why fog-of-war cheats in this genre survive year after year. Zig for the static arm64 reader is a good call — it sidesteps Android's dynamic linker entirely and produces a clean cross-compiled binary you can push and run without fighting libc dependencies.
This works on exactly one device: OnePlus PJF110, Android 14, kernel 6.1.75. BOLT/PGO/LTO kernels (which is what most OEMs ship) kill hardware breakpoints and likely break several other assumptions — the repo documents this failure but offers no path forward. The offset table for the 4-follow coordinate chain will rot the moment Tencent pushes a game update, and there is no offset-scanning fallback; someone adopting this inherits a manual RE job every patch cycle. The apk-tools directory is 250+ scripts with version suffixes (apply_patches_v18 through v26, build_patch_v34 through v51) and no indication of which ones are current — it reads as raw AI-agent output that was never consolidated, which makes reproducing any specific step harder than it should be.