Internal vs External
When talking about developing tools for game modding a typical question that arises is should my tool be Internal or External? What is the main difference between an Internal and External tool? The terms internal and external refer to the location that the code is being run from.
If the code is running from inside the game’s process it is considered to be an Internal tool. If the code is running from outside the game’s process (as a separate executable) it is generally considered to be an External tool. Most tools will fall into one or the other however in certain situations a hybrid approach is utilised for maximum effectiveness.
An external tool as the name implies runs outside of the targeted executable. It interacts with the target application by calling API like WriteProcessMemory or by modifying game files or resources. A save file editor or a custom launcher is an example of such tools. Typically they will locate the game’s process via the main window of the game or by scanning through a list of running processes or they will simply locate the main executable and launch it.
Once they’ve located the game’s process they’ll call OpenProcess to retrieve a handle to the process in order to modify the game’s memory while it’s running. For trainers this might be something like giving the player unlimited money or lives. They’ll also register some keybindings so the player can use the trainer while the game is running.
External tools can not draw on the game’s display in the same manner as an internal tool. Usually they will achieve this functionality by creating a transparent window over the top of the game and drawing to it instead. This is typically referred to as an “overlay” which the tool can then draw information to.
I have seen such mods for StarCraft which log a player’s Actions Per Minute and check their performance against what is expected; giving a visual notification to ‘slow down’ or ‘speed up’ their actions. Other information can be drawn to the overlay such as build orders, timings for various actions or the number of idle workers in play.
An internal tool is the exact oppose of an external one, it is typically packaged into a Dynamic Link Library and either forcibly injected into the target process or loaded through a DLL Hijacking method such as use of a ProxyDLL. This is not always the case it can also include modifying (patching) the game’s code on disk in order to modify it’s behaviour, this is typically the case with “community patches” whereby the original developer no longer supports the game so it’s fans continue to update the patch the game to fix bugs. A really good example of an internal patch with run time memory patching is the Silent patches for the GTA series of games which you can view here.
Internal tools once running inside the game will typically locate the pointer to the game’s drawing device in order to render to the main screen. For DirectX games this means locating (or hooking) the created device in order to run code inside of the EndScene call. For more information on how this is achieved take a look at my DirectX 9 hooking tutorial.
Internal tools can also modify and redirect program flow by modifying the program’s code through use of hooking or redirection. For example an internal tool may wish to receive a notification when the player’s health is changed. So typically they modify the player’s TakeDamage() function to call their own function instead. An external tool would have to poll the memory address where the health is stored in order know if it changes.
So which type should I use?
In my opinion the choice is already made before you ask yourself that question. Certain functionality is not achievable from an External tool. It comes down to how much control you wish to exert over the target program: if you need to control program execution (install hooks/redirection) than internal is the way to go. If you only need to read/write some values then going to the trouble of injecting yourself into the application is probably not worth the effort.
Your skill level needs to be taken into consideration as well. How comfortable are with a debugger? Do you think you’d be able to locate what part of your code is crashing when your DLL is injected into another process? If your answer is no then you’re probably looking at sticking with an external tool (for now: practice makes perfect).
Case Study: Unreal Engine 3
I was faced with a similar design issue when I begun reverse engineering Unreal Engine 3. Do I write a DLL and inject my code? What if my DLL crashes and all the memory addresses get changed? I could loose hours of work! Due to this I opted for an external tool for the following reasons:
- I could easily debug my code with Visual Studio.
- There was no risk in crashing the game and therefore loosing all my found memory addresses.
- I felt code injection was overkill.
- Someone told me to use internal so out of spite I went with external.
Ultimately you can go with either one: everyone has their preferred method. I generally favour internal code as it gives me the power I need, do I always need that power? No, but I like having the option. There also may be other reasons to choose one over the other: such as anti-cheat systems detecting internal mods. So in that situation it may be better to create an external tool instead.