Video games are truly intriguing pieces of software. They are built with cutting edge technology and employ some of the most wild and innovative logic, all while being artistically expressive and generally entertaining.

I have always been a fan of video games and can truthfully (albeit cornily) say that they have brought me where I am today. Video games served as an accelerant for my interest in computer systems, software, and security. In fact I may never have made the leap from mere scripting and web language to proper object-oriented programming had I not been dead set on coding my own video game cheats. And when one of my creations gained popularity, a strongly worded email from a small game studio scared me straight and helped encourage me to pursue a more ethical hacking career.

However, when most video game players hear “hacking” in the context of their favorite game, they only think of cheaters. Cheaters in multiplayer games may not be directly attacking their fellow players in a technical way, but they are attacking the game’s infrastructure and logic. However, it is becoming increasingly clear that hopping into a video game lobby with strangers can be a security risk. Inspired by this recent report on a botnet being spread through a 0day in Counter Strike’s multiplayer environment, I thought I’d share my experience and thoughts on the attack surfaces of video games, and video games as an entire attack surface of their own.

Ethics and Motives of Video Game Hacking

Like many other young and impressionable kids, when I first started hacking video games I only did it for the lulz. When the hit sequel to the popular iOS game “Jelly Car” was released in 2009, people scrambled to shave seconds off of their run times and make it to the top 10 worldwide leaderboard for each level. I thought it would be hilarious to boost past them with a time so ridiculous that they’d scratch their heads and wonder how it happened. So I poked around, managed to edit the level data files, and scored a record breaking 0.00001 seconds on all the levels.

Jelly Car was a fun little racing game with soft-body physics

I know from many of the peers that I met in game hacking communities and forums that this “for the lulz” sentiment was not only common, but almost exclusive. After all, we were attracted to video games for fun. A similar ideology that I encountered, was that “it’s just another way to play the game”. Anyone could have opened up those level files from Jelly Car, edited the coordinates of the finish line, and claimed that top spot. Armed with this logic, many video game hackers feel as though they’ve outsmarted the other players and for a while I failed to see how truly grotesque that mentality was.

Obviously, as I grew up I started to define a proper moral compass and saw the flaws in my misguided logic. Today, I absolutely love playing competitive video games like Counter Strike in an entirely legitimate manner and feel the same anguish I once caused whenever I encounter a cheater.

CS:GO (the only game I play these days) with in-game hacks enabled

Not everyone, however, moves on. From my experience, one thing became clear: hacking video games is a gateway drug. You find yourself learning the same techniques used by blackhats in other fields, and who better to teach you? You wander into communities with moral code akin to the wild west. You may be tempted at the sight of financial gains or your curiosity might get the better of you. So it was no surprise to me when I read that the authors of the massive Mirai botnet had been motivated by hacking Minecraft. Originally, they just DDoS’d Minecraft servers but eventually expanded their market when they saw how much cash there was to be made.

I was once acquainted with a small hacker group known as BassCode that was also a part of the Minecraft scene. At first, they had relatively good intentions, as far as hacking intentions can go. They exposed people that were charging money for Minecraft cheats that they hadn’t coded themselves. They were “skid” busters. But eventually, they just started cracking all of the premium cheats and leaking private video game exploits. And now, looking at their website’s archive.org data over the past 8 years shows a deterioration into doxing, racism, defacing, and database dumps.

The Scope of an Attack on a Video Game

A majority of hackers in video games are using in-game exploits. Much like my editing of the Jelly Car data, they are manipulating the software or the communication between their game and a central server in order to change the gameplay. Their actions are usually confined entirely to the game in progress.

This isn’t a necessary limitation, however. Let’s take a look at the “Belonard” trojan that was recently propagated through Counter Strike servers. It’s end goal and ultimate functionality was to edit a config file of the game in order to promote certain servers by placing them at the top of the list. It’s slightly more complicated than that, but there really wasn’t any motivation beyond driving traffic to their game servers. This hacker had a 0day exploit that gave them user-level disk read/write capabilities and they chose to use it only for in-game effect. No ransomware, no backdoors, no keylogger, just a meager financial and popularity boost that really never left the scope of the game.

Promoted servers being hacked into a game's list (Credit Dr.Web)

In similar fashion, the slimy BassCode crew that I mentioned earlier started adding what was known as a “lastlogin stealer” to the Minecraft hacks that they were cracking and releasing. While I cannot say with certainty that nothing else was injected, they were initially caught using the full user-level read/write privileges inherited by Minecraft to collect a single file that contained the decryptable credentials of the currently logged in Minecraft account. Another case of in-game hackers venturing out of the game and into the private data of another player just for game-related gain.

Video Games as an Attack Surface

We used to tweak our game client's code to avoid rendering dropped items and then drop thousands of individual items in front of someone else to crash their game

Video game data gets weird. Very rarely are we exposed to so many different types of data that originate from an untrusted peer. Whether its updating the coordinates of an in-game box that you’ve decided to move, the creation and direction of a bullet projectile, or announcing to an entire Minecraft server that you just instantly dropped 2560 diamond swords on the ground, your actions have an incredibly varied impact on other people’s software.

And yes, I know what you’re thinking. Video game servers do have security. Client data gets sanitized, verified by the server, and it’s all transported in predictable, custom designed packets. Sometimes, video games have peer to peer data transfer but usually your game is getting all of its data from a trusted server. However, just because the server is trusted, doesn’t mean the content should be. In similar fashion, XSS attacks are most effective when placed on a trusted website.

I believe that a more significant blackhat attack distributed through video games will happen in the near future. It won’t take long for a video game hacker to realize that they can do so much more damage than promoting their custom servers or for a traditional blackhat to see the potential exploits in old video games.

Gamers hold onto their favorite games dearly, and many old multiplayer games have thriving online servers without receiving any updates in years. Major game design companies have recently been proving to the community that they will do absolutely anything to squeeze revenue from fans and discontinuing updates for games but keeping them online as revenue streams is not going to be rare. Security-conscious people would never open an untrusted PDF file with a 5 year old version of Adobe Reader, but may not think twice about booting up their favorite old game and playing with strangers.

In this quickstart guide, we will be learning about the role of object deserialization in security. Deserialization is featured in most major languages and when implemented improperly, either by the language itself or by the application being written, can be a fruitful attack surface. CVE-2017-5941 is an example of flawed implementation of deserialization in the node.js JavaScript framework.

What is Object Deserialization?

Understanding deserialization requires a basic understanding of object-oriented programming. Most modern programming languages allow for improved efficiency by using the concept of an object. The basic structure of an object is programmed, including its functionality and any details that can vary, just once (into what is called a class). This code can then be re-used when multiple versions of this object are needed, ultimately improving efficiency. There are many more benefits to using objects that don't need to be covered for exploring deserialization. If object-oriented programming is a new concept to you, it can help for this guide to think of an object as a filled out form. The software application can print off as many forms as it wants, and fill them out differently.

Deserialization is the act of reversing serialization. Serialization is a complex type of encoding. Much like we base64 encode URL parameters and cookie data, programming languages serialize objects so that they can be transported under constraint. When receiving a serialized object, a programming language or application will process it and convert it back into an object in memory. This is where things can go awry.


CVE-2017-5941 is a deserialization exploit in the node.js JavaScript framework. Node.js is used very widely across the web in modern web applications, and any version that has not been patched and utilizes deserialization is susceptible to attack.

CVE-2017-5941 takes advantage of the conversion moment in deserialization, where the serialized object has been processed and is being put into memory. It does this by serilaizing an "immediately invoked function" into the object.

Immediately Invoked Functions

JavaScipt syntax includes a way to call a function at the same moment it is defined. The syntax is simply appending two parenthesis, "()", after the definition. Example:

alert("I am an example function!");

Now lets draft a function that we might want to execute on a target:

require('child_process').exec('ls /', function(error, stdout, stderr) { console.log(stdout) });

Exploiting CVE-2017-5941

So we know that code can be executed when a function is defined, but its not ever supposed to be the user's role to define functions. Javascript, however, allows functions to be placed inside regular variables. If a web application is serializing user input as a variable (this could be as simple as a variable called first_name that takes a value from a form field), we can modify the data transmission to send an immediately invoked function with our payload instead of the expected value type for the variable.

However, it is important to realize the role of deserialization at this point. Simply sending an immediately invoked function to a server won't accomplish anything. If the payload isnt deserialized, it never gets treated with the respect of "real code". Much like cross-site scripting, or injection attacks, deserialization exploitation is the result of unintentionally running user input as functional code. However, unlike cross-site scripting or injection attacks, this capacity is a necessity. The entire purpose of deserialization is to transport code and data that is intended to be re-entered into the application as functional code.


This truly unique ability to leave and enter your programming language's interpretation layer is what makes serialization/deserialization in all languages worthy of investigation as an attack surface. Many major languages have had deserialization exploits and there are likely to be new and creative ways to break this system in the future.

In this guide, we will take a look at a few exploits that target remote keyless entry (RKE) systems in modern vehicles. We will learn the theory behind the generic rolljam attack and also implement a specific attack on Subaru vehicles. Read Guide

In this guide we will observe one of Java's most dangerous vulnerabilities, CVE-2012-1723. We will analyze the conditions of the vulnerability and work through an example of practical exploitation through a drive-by attack. Read Guide