I’ve been thinking about writing a game proxy, specificaly for the game Tibia. Now, as with all proxies: one bug equals catastrophic failure. And this, specially in an MMO, can’t be good for you.
Let me clarify, even if you attempt to hook the process and detour the original routines (ie. send and receive functions) or use a full-blown TCP/UDP router; if your code is buggy, you may as well close the process yourself before it crashes and your character joins limbo as deadly monsters chew its legs off and the game’s gods laugh off their asses in front of you, of course, you won’t be able to see it but you can imagine it wont be pretty.
Perhaps, redundancy is the key here.
If you manage to design a stable and proper layer that sits in between your code and theirs, then -theoretically speaking- even if your code crashes, you can still reopen your process and tell the layer to route the data back to you once again.
The idea behind this concept is simple, try not to use the other process for everything. Just detour or inject as little code as possible, make sure you can always route back to another process of yours and you’ll be safe. That is, unless your detouring layer isn’t strong enough and you don’t sanitize input data… In such case, we are back to square one.
One nifty and clean way of storing your information would be by setting up user data on the process window, namely a pointer to a structure of yours. If this user data is not equal to 0, we know for a fact that we already tampered with this process.
Now, if we have access to this pointer, we could read whatever it is we wrote. Of course, it should point to a memory area on the proxy-layer running process. So to speak, if no layer is running (or no layer is hooked) and we encounter a non 0 on the user data, we should “xor it” -zero it- for it cannot point to a valid (for us) memory area. This, however, would only happen if your layer crashes – because, its de-attach routine should make sure it sets the user data back to 0 once the deal is closing. In such case, again, we would be back to square one.
Thus, it is imperative to write a stable API that sits in between the other process and your process. If you’re thinking about writing a game proxy, make sure you try this out first. With a proper API and proper data and pointer sanitation, crashes would be something of the past and you will be able to focus on the real important aspect of writing the manipulation code for the game, instead of working around bugs and random crashes on the host process.
I would of loved to draw up some graphs and charts for this but, time is lacking.
So good luck with your game hacking! – I will most likely hit the topic once again in the future.