Minimizing the CyberSecurity Headaches of Video Game Modding
As the year draws to a close, it's time to reflect on a lot of things. Some of them are obvious, others are not.
For example, video game modding isn't really an attack vector most people would think of. But if you dig below the surface, there's a lot to unpack.
First of all, there's several different types of game modding, which can overlap:
- Exposed file changes - alterations to easily accessible files, typically configuration files.
- Altering variables at runtime - using external tools to change hex values that control in-game statistics and functions.
- Altering compressed archives - unpacking the contents of compressed archives, editing the contents, then repacking the contents to alter game behavior.
- Creating and inserting new content - requires various formats, tools, and possible code alterations to accomplish.
So, what are the cybersecurity implications? Let's break them down by who is doing what.
Players
- Least amount of control.
- Desires some change to game experience from mods.
- Depend on 3rd parties (mod developers) to make mods/software and provide support.
- Rely on hosting websites and antivirus/firewalls on personal computers/devices for security.
- Unlikely to have tools capable of detecting potential vulnerabilities caused by improper programming.
Basically, players are end users who are placing a lot of faith in the mod makers to A) not intentionally place malware in their systems, B) accidentally make malware infected mods, or C) accidentally compromise/damage their systems due to unexpected software interactions. The amount of risk is dependent on the type of mod, with exposed file changes like alterations to configuration files being the lowest risk.
Also exacerbating risk are proprietary file/archive formats that don't allow the user or antivirus software to properly asses the mod's contents. This is a more frequent problem with popular engines such as Unreal and Unity.
Mod Developers
- Variable amount of control.
- Variable amount of personnel.
- Variable amount of programming experience.
- Variable amount of troubleshooting experience.
- Desires to change some aspect of game experience.
- Dependent on 3rd party tools or self-developed tool solutions.
- Rely on hosting websites and antivirus/firewalls on personal computers/devices for security.
- Variable likelihood to have tools capable of detecting potential vulnerabilities caused by improper programming.
Theoretically, mod developers should be the people responsible for handling all the cybersecurity implications of modding games.
The problem is that until AI driven programming/modding tools that incorporate code assessment and hardening measures become standard, there's no way for modders to realistically do so.
Why? Well, the answer is very simple. The vast majority of modders are hobbyists. They tend to only learn enough to accomplish the task(s) they want to do, and generally cannot make their own tools. They are therefore dependent on officially provided tools and documentation, which games rarely provide these days, old third party tools, or community sourced tools... which they don't have the technical knowledge or skill to vet the coding of.
For anything short of a developer made Visual Studio/VS Studio extension or tool, there's a huge leap of faith required by the potential modder - namely, that the tools aren't rife with malware.
And then there are issues of coding compatibility with the game itself and other mods. Modders with the knowledge and skills are likely to work on the low hanging fruit of potential exploits, like memory leaks. But no one is going to be doing comprehensive testing for potential vulnerabilities. Between lack of time, knowledge, experience, and automation to run modded games until a crash happens, there's simply too many hurdles for any single individual modder to overcome.
Game Developers
- Most amount of control.
- Variable amount of personnel.
- Generally high amount of programming experience.
- Generally high amount of troubleshooting experience.
- Near total control of game experience and coding.
- Dependent on 3rd party tools or self-developed tool solutions.
- Typically have business grade security.
- Variable likelihood to have tools capable of detecting potential vulnerabilities caused by improper programming.
In reality, the people most responsible for cybersecurity in video games are the developers and, if applicable, network game service providers.
This is pretty much due to probabilities. The game developer and whoever they partner with to provide online capabilities (multiplayer, content updates, etc...) are the most likely to have the proper tools to test for and fix potential vulnerabilities.
Even if a developer supplied the source code for the game as part of a mod Software Development Kit (SDK), that likely won't include the ability to update the engine, which is third party software that runs all the game code. If there's a vulnerability in the engine, the patch fixing that vulnerability might actually be in a file that the mod SDK does not allow modders to compile, and can only be distributed by the developers.
That being said, when it comes to security, game developers are generally focused on multiplayer modes and other network connected features. And for good reason. Manipulation of data in those modes not only affects the general player experience (cheaters being able to see through walls, for example), it can also be weaponized. Games like Dark Souls 3 have had malicious actors dump modified items into other player's games using the network features, causing their victims to be banned from playing with non-cheaters.
It is only in the circumstance where the game is intended to be modified that developers think of the implications of the game being modified.
Mitigation
There are two main ways to mitigate potential cybersecurity vulnerabilities created by modifying games:
- Provide official modding support through tools and documentation.
- Provide a non-modding solution to game customization.
The first is a rather time and resource consuming effort, but depending on the game genre and perceived value of building a sustained player base, can be worth it. For example, XCOM 2, a 2016 strategy game title, has a robust player base 7 years later, because it has a massive amount of mod content. This content was created through the use of developer provided tools and seed knowledge, which provided the basis for a modding community that is still active to this day.
This allows for known methods of data input to be sanitized and hardened, and depending on how the source code licensing is handled, permits auditing via open source public hosting.
Non-modding solutions to game customization actually has two major subsets:
- User modifiable configuration files.
- In-game customization menus.
The first option might be confusing to non-gamers, especially non-PC gamers. Aren't user editable files a form of mod support?
Technically, yes, but in general, they exist mostly a standard fail-safe for boot-time troubleshooting and configuration of a game. If you can't get a game to boot at a desired resolution and language, editing the configuration files gives you a chance to force the game to do what you want.
The other option, which is growing to be more popular, is having an in-game menu to customize settings. This is basically a user friendly method of what the configuration file does - let players change numbers and other operations that affect gameplay.
As it so happens, this is precisely what the majority of gamers (75+%) would like. For a variety of reasons, what tends to make an experience less enjoyable to a gamer is the developer's choice for the settings. Typically, things will be too hard, too easy, or take too long, and/or some other kind of inconvenient for an individual player.
The advantage of these approaches is that they reduce the number of possible inputs to sanitize, while also fulfilling the demands of the largest number of users. It won't satisfy the people who want to change how things work or add new content, of course. But helping cut down the threat surface for bad actors to exploit more than makes up for.
Will developers implement these methods as standards in the future? If tool sets make it fast and easy, perhaps they will.
