- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 519
- Reaction score
- 7
Ran into a wall while trying to poke at One Piece Bounty Rush on Steam. The game is protected by XIGNCODE3, and as most of you know, it's a pain if you don't handle the kernel-level heartbeats and handle stripping correctly.
The Current Setup
I'm using a modified Undetected Cheat Engine (UDCE) build along with a custom kernel driver to keep the process hidden from the AC's scan routines. The hiding part seems to work—no immediate kick or ban—but the memory access is completely cooked.
Technical Roadblock
When attaching to the game process, the memory regions are showing up as execute/read-only. Attempting to scan or scroll through the memory results in a sea of question marks (????). This usually points to a few specific X3 behaviors:
If anyone has managed to get a stable R/W handle on the Steam build of Bounty Rush without triggering the heartbeat, I'd appreciate some insight. Are you guys manually stripping the AC's callbacks or using a different IOCTL approach to bypass the page protection?
Drop your thoughts on the latest X3 behavior below.
The Current Setup
I'm using a modified Undetected Cheat Engine (UDCE) build along with a custom kernel driver to keep the process hidden from the AC's scan routines. The hiding part seems to work—no immediate kick or ban—but the memory access is completely cooked.
Technical Roadblock
When attaching to the game process, the memory regions are showing up as execute/read-only. Attempting to scan or scroll through the memory results in a sea of question marks (????). This usually points to a few specific X3 behaviors:
- Handle Stripping: Even if the driver hides the CE process, XIGNCODE3 might be stripping access rights from the handle via ObRegisterCallbacks.
- Memory Protection: The AC might be using its own driver to hook memory access APIs or using page protection that your current kernel implementation isn't bypassing.
- Heartbeat Sync: Some versions of X3 on Steam check for debugger attachments and will zero out the view for any unauthorized handle.
Attempted to use DBVM to hide the debugger further, but the results remain the same. The kernel driver is supposed to grant full access, but it seems X3 is winning the race on the handle elevation or is re-patching the permissions dynamically.
If anyone has managed to get a stable R/W handle on the Steam build of Bounty Rush without triggering the heartbeat, I'd appreciate some insight. Are you guys manually stripping the AC's callbacks or using a different IOCTL approach to bypass the page protection?
Drop your thoughts on the latest X3 behavior below.
