Reverse-engineered engine integration
Mina native mod menu
The menu draws nothing. It clones live engine vtables and builds pages out of the game's own controls, so it looks and behaves like a vanilla menu because it is one.
Problem
The game ships a code-loading mod API but no way for players to configure mods in game. An overlay drawn on top would feel foreign and fight the engine's input, font, and sound behavior.
Engineering approach
- Locate every engine function by byte signature and every data global by parsing rip-relative displacements, no hardcoded addresses, so Windows and Linux build from one source.
- Walk the world's menu-root entity to find the options menu, inject a Mods entry, and push cloned menu objects with overridden page-builder and cursor-movement vtable slots.
- Render every widget, sliders, toggles, enums, keybinds, labels, buttons, with the engine's own slider control class; edits write through mod-owned pointers, then fire callbacks so mods persist their own settings.
- Publish a single vendored header so any mod gets an in-game settings page in about fifteen lines, with an ABI handshake that safely skips mismatched mods.
Outcome
- Working and in active use on native Windows and Linux builds, including Proton handhelds, with signatures and vtable slots verified against each target binary.
- Designed to degrade rather than crash: when a game update breaks signatures, the mod logs what it could not resolve and simply stays out of the menu.
The hardest problem
A settings menu players cannot tell apart from the game's own, in an engine with no UI API.
Anything drawn as an overlay fights the engine's font, cursor, sounds, and input timing. The only way to look native is to be native, which means depending on undocumented internals that any game update can break.
Locate everything by byte signature, clone the live menu vtables, build pages from the game's own slider control, and when signatures stop matching after an update, log it and stay out of the menu instead of crashing.
How I worked through it
Data globals were the harder half. Functions can be found by instruction patterns, but a global has no bytes to match, it is reached by parsing the rip-relative displacement out of an instruction that a signature did locate. Every signature and vtable slot is verified against each target binary, including a symbol-level check on Linux, so a wrong hit disables the mod instead of corrupting memory.
The cloned menus keep the original class's -8 RTTI slot intact so the engine's own RTTI queries still resolve, and mod-facing safety comes from a vendored header with an ABI handshake: the menu reads the ABI version and struct size before trusting anything else, and skips mismatched mods silently.
Technologies
- C++
- Reverse engineering
- Signature scanning
- Vtable cloning
- ABI design
- CMake
- Windows
- Linux