I Hacked a Free Camera Mode Into a Dead MMO
Reverse engineering Free Realms and building a fully controllable camera
Index
Why do this?
Free Realms was my favourite MMO growing up. The official game shut down in 2014, but over the years the community has distributed offline clients and local servers that make the world explorable again.
That made it a good environment for me to learn game hacking and software reverse engineering: whatever I did would stay inside a local, offline instance of the game and would not affect other players.
At the time, I wanted to create some nostalgic social media content around Free Realms, cinematic aerial shots of its world.
This would be quite difficult since the game’s camera is third person, bound to the player character, and my guy does not fly.
The solution? I must make my own free-flying camera system!
However, there is no source code, modding SDK or anything to work with 🥲
It was time to learn a new skill.
Finding the Camera Coordinates
I installed Cheat Engine, a source-available memory analysis and debugging tool used to inspect and modify running programs, set code breakpoints, and disassemble machine code.
Using Cheat Engine, I started looking through the game’s memory while moving the camera.
It didn’t take long to find values that appeared to correspond to the camera’s world X Y Z coordinates.
Changing them confirmed I was in roughly the right place, as the game’s camera would snap to the new values for a single frame, but simply overwriting those values didn’t work. The game was constantly recalculating the camera position and writing new values back over mine.
That meant the coordinates themselves weren’t particularly useful, what I really needed to find was the code responsible for updating them.
Using Cheat Engine‘s debugger, I started breaking on the instructions that wrote to those memory addresses and tracing through the surrounding assembly code to understand where the values were coming from.
Working Backwards From Assembly
From there, most of the process happened directly inside Cheat Engine.
There were no function names or symbols to rely on, so I had to work backwards from what I could observe at runtime.
The process was roughly:
- Change something in-game
- See what memory changed
- Break on the relevant instruction
- Inspect CPU registers and nearby memory
- Follow the surrounding assembly
- Make a guess about what the code was doing
- Patch or bypass part of it
- See what happened (9/10 times -> game crashed)
The vast majority of my guesses were wrong.
I found dozens of values that looked like camera transforms but were actually temporary values used somewhere during the camera update.
Very early on in this assembly debugging journey I realised this is something AI would actually excel at, so I started prompting away, making this whole process a billion times faster (I no longer had to individually interpret thousands of lines in assembly 🙏)
Over time I started identifying different parts of the third-person camera logic: camera distance, orbiting, collision adjustments, direction vectors and the final position eventually used by the game.
Once I understood where the final camera state was coming from, I could stop fighting individual values and intercept the system at a more useful point.
Reverse Engineering the Input System
Manipulating the camera was half of the problem.
I also needed to understand and read the game’s existing input so I could reroute it to control my camera with WASD, as opposed to creating a whole separate system for detecting any input and routing that to my scripts.
Again, the process was Press Buttons -> Look for any memory changes, trying to find some crumb of data that could somehow be interpreted as input.
This part was less straightforward than I expected.
The game didn’t have an array containing whether each key was pressed, as I was hoping it would.
Working my way back from assembly breakpoints, I eventually found myself looking at a 256-entry input state buffer. Each entry held the state of the keyboard + mouse in a given frame.
It was extremely tricky to find because all this information was encoded and bitmasked. Once I knew this is what the input system was reading from, I was able to reverse-engineer all the state compression, and I now knew what keys were being pressed at any given frame, as well as the cursor position.
Taking Control of the Camera
The final solution involved a few injections of x86 assembly to hijack the parts of the code I needed, some bits of the original code would reroute to my own scripts while others were straight up ignored or bypassed.
The game still handled rendering exactly as before, I was just replacing the position and rotation it would normally use for the camera.
I wrote my new camera system in Lua, since that is the scripting language Cheat Engine supported.
I made some helper functions in Lua to decode the game’s encrypted input as well, in order to feed that into my system in a more sane manner.
Building the Camera Controller
Finally, time for me to do something I actually know how to.
I wrote the free-camera movement system in Lua with:
- frame-rate-independent forward, backward, sideways and vertical movement
- acceleration and deceleration
- movement speed changes with keybinds
- ease-in and ease-out camera rotation controlled by the mouse
- adjustable sine-wave-based head bobbing
- toggling between normal gameplay and free-camera mode
The end result was similar to flying the Unreal Engine camera around an editor viewport.
Who’s flying this thing?
A completely detached camera worked well for some situations, but it also exposed a couple of limitations.
Some systems still used the player’s position, not the camera position.
This meant you could fly anywhere you wanted, but the audio was still captured based on the player’s location and rotation.
Eventually you would fly so far that you would unload the chunk of terrain the player was standing on, causing them to fall into infinity, abruptly ending your flying session as the player and camera were reset to the game’s main spawn point.
To fix all issues, I decided the easiest, dumbest and therefore best solution was to move the player with the camera, and keep them at a permanent relative offset.
This meant I could record anything while keeping the player character outside the frame, as he was always standing behind the camera.
Conclusion
What started as a way to get better footage from an old game ended up being a very practical introduction to reverse engineering.
I went from knowing nothing about the executable to being able to identify and intercept parts of its camera and input systems, then build my own controller on top of them.
The final tool gave me a fully independent camera that could fly through the entirety of Free Realms, pass through geometry and explore areas that were never meant to be seen from such angles. In doing so, I also implemented the player no-clip.
In sum, this project involved:
- x86 assembly
- Cheat Engine
- runtime memory inspection
- debugging compiled code
- code injection and hooks
- reconstructing game data structures
- reverse engineering input and camera systems
- Lua
- camera movement programming
It was the perfect project to learn game hacking: reverse-engineering how a game works internally, modifying it for a specific use case without using that knowledge to cheat or interfere with anyone else’s experience.