- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 481
- Reaction score
- 7
Anyone still digging into the SAGE engine? I've been looking into porting an old map hack and shroud patch to the latest 1.05 patch specifically for the Generals Online (GO) launcher. While the logic holds up on a vanilla 1.05 install, the GO Anti-Cheat is significantly more aggressive than the old GenTool hooks.
The Problem
On a standard 1.05 build, patching the shroud state bytes is trivial. However, GO implements a "crash-on-write" policy. The moment you attempt to patch a byte or write to specific memory ranges internally, the game instance is terminated instantly. This isn't just a simple black screen overlay like GenTool—it's a hard process exit.
Technical Analysis
Patch 1.05 Changes
The code structure has shifted significantly from older versions. Memory scanners are hit-or-miss now, and if you aren't comfortable in Ghidra or IDA yet, you're going to have a hard time finding the correct bytes to patch for things like the Scaffold hack or Map Hack. The offsets for shroud state have definitely moved compared to the old 1.04 builds.
Anyone else currently reversing the GO launcher? I'm curious if anyone has successfully manipulated the protection table or found where they initialize the guard pages. If you've got offsets for the 1.05 map hack, let's see how they compare to the vanilla ones.
Have fun reversing.
The Problem
On a standard 1.05 build, patching the shroud state bytes is trivial. However, GO implements a "crash-on-write" policy. The moment you attempt to patch a byte or write to specific memory ranges internally, the game instance is terminated instantly. This isn't just a simple black screen overlay like GenTool—it's a hard process exit.
Technical Analysis
- Hooks: Checked ntdll.NtWriteVirtualMemory and it remains unhooked in user-mode. They aren't using basic ring3 API hooking to catch the write attempt.
- Memory Protection: The AC appears to be using VirtualProtect to set PAGE_GUARD on sensitive addresses, including the map shroud logic. Any access or modification triggers an exception that the AC handles to kill the process.
- The Protection Table: There is an unprotected table in memory that contains the list of addresses the AC monitors. Interestingly, swapping the map hack address in this table with a dummy address doesn't stop the crash, implying a secondary verification or that the monitored addresses are cached elsewhere during initialization.
The AC is likely flagging the STATUS_GUARD_PAGE_VIOLATION. If you're trying to debug this with basic tools, you'll hit a wall. To bypass this, you'll likely need to:
- Find the exception handler and detour it before your write.
- Spoof the memory page attributes without triggering the guard signal.
- Use a kernel-level driver to write if the AC is only monitoring user-mode exceptions.
Patch 1.05 Changes
The code structure has shifted significantly from older versions. Memory scanners are hit-or-miss now, and if you aren't comfortable in Ghidra or IDA yet, you're going to have a hard time finding the correct bytes to patch for things like the Scaffold hack or Map Hack. The offsets for shroud state have definitely moved compared to the old 1.04 builds.
Code:
VirtualProtect(targetAddress, size, PAGE_READWRITE | PAGE_GUARD, &oldProtect);
Anyone else currently reversing the GO launcher? I'm curious if anyone has successfully manipulated the protection table or found where they initialize the guard pages. If you've got offsets for the 1.05 map hack, let's see how they compare to the vanilla ones.
Have fun reversing.