Speak of the Devil: I did my second talk
2026 Apr 09 (E: 2026 Apr 09)
The slides (n=17) can be downloaded at /downloads/talk2.pdf.
You can also check out my previous talk for the same audience.
Q&A
Will add more, but I’m working off what I remember.
(Regarding pointer paths and manipulating the same variables across restarts, different computers, and environments.)
As long as there is a valid pointer path to the entry point
(0x400000 = “GameName.exe” = any executable), the same
variable can be targeted. This holds until the developer patches the
game or releases a new version, in that case the base offset changes,
but generally every other higher level offset can be reused.
For example, a game has a variable at…
[[[0x400000 + 1133cc]+24]+1c1]+1b00
The devs patched the game, so the variable can not be targeted with
the same path anymore, but the gamehacker can still reuse offsets
[24, 1c1, 1b00].
What’s with the assembly code you wrote?
“I don’t recognize the directives at the top.”
It is still x86 assembly, but it is a “Cheat Engine dialect” specifically for code injection. The main difference is the top portion of the code allocates memory, defines labels, and makes them accessible accessible to Cheat Engine’s Lua interpreter. The opcodes, registers, and everything else remain the same.
Would the code injections you wrote in x86 assembly still work on ARM?
The game would need to be running on ARM computers to begin with. While I don’t know about running x86 binaries and games on ARM, at SCaLE 23x, Lutris managed to run Crysis on an ARM machine.
(If entire game binaries got “translated”, there’s a good shot the code injection will as well since I used the same set as opcoodes as the game’s compiler.)
(What’s) the difference between attaching a debugger from Linux (gdb) and attaching a debugger within Wine (Cheat Engine)?
You might (depending on game) be better able to evade anti-cheat detection better by attaching gdb to Wine with the game loaded. See WINE for Video Game Hackers from LayerOne 2025.
Within in the context of presentation itself, gdb output included 64-bit registers (r**) while Cheat Engine mainly stuck to 32-bit registers (e**).
What’s the deal with VRAM / GPU memory?
It’s a “computer architecture and hardware design” deal.
Memory scanning as featured operates only on system memory and not GPU memory. VRAM is also arranged and accessed differently from RAM because of parallel access for graphics processing. VRAM is also not directly accessed by the CPU.
Typically, messing with the game’s graphics involves graphics API interception rather than what’s featured in the talk.
What games do you recommend for getting started with gamehacking?
Legally, a free and open source game or a game without a anti-reverse engineering clause in its EULA.
To avoid getting account bans or being a d*ck to multiplayer communities, singleplayer or offline games.
For straightforwardness, games written entirely in a compiled language (C, C++) and do not operate a scripting engine.
Additionally, games with notorious reverse engineering and hacking communities e.g Pokemon, Diablo II, Resident Evil / Devil May Cry, Silent Hill are good too.
Are you that person?
I use a separate alias on Steam.