[AntiCheat] Game Security: Overcoming Hurdles.

@codewiz · April 27, 2012 · 15 min read

When do users actually feel the presence of game security products? Is it when hacking tools are effectively caught, and in-game hacking decreases? No. In fact, most ordinary gamers are unaware that game security products are catching hacking tools. The typical moment they become aware of game security products is when a game that used to work well starts malfunctioning. It's at this point that the game security product becomes a hurdle interfering with the game's operation. It's then that all gamers become aware of the name of the anti-cheat solution. Additionally, if the game is truly popular, it might even dominate the top ten real-time search rankings on Naver. Along with all these events, a flood of criticism and defamation towards the anti-cheat solution ensues. In short, it's a dizzying moment.

💡 Naver: The most famous search engine in Korea.

When I first created a product called XIGNCODE, I honestly didn't give it much thought. As I later shaped the product, I made two big resolutions. One, ironically, was to create a real solution that catches actual hacking tools. The other was to never make a product that becomes a hurdle in games. However, as time passed, our product began to be incorporated into games, and in the process of waging war against hacking tools, there were instances where it inevitably became a hurdle. Despite our intentions not to be an obstacle, there were moments when it became a burden. As a gamer myself, I feel endlessly sorry during these times. Then I make another resolution: to buckle down and make it right.

So, why do all game security products invariably become hurdles? Why do these hurdles occur? Are they unavoidable? Conversely, from a gamer's perspective, what should be considered to avoid these hurdles as much as possible? Paradoxically, the reason game security products become hurdles is that they fail to properly overcome the hurdles they face. Here, let's examine the hurdles encountered in the development of game security products and take some time to seek answers to these initial questions, even if they are modest.

#0 Operating System Hurdle

Firstly, for game security products, the operating system itself is like a massive mountain range. Why is that? Games run on various operating systems, and so do game security programs. So why is the operating system a hurdle specifically for game security products? The reason is that game security products, by their nature, use various functions that are not disclosed by the operating system. Why? Why do they do this? There are many reasons, but let's consider the main ones. One reason is the necessity to detect hacking tools that utilize these undisclosed functions, and another is to protect themselves from hacking tools. Utilizing these undisclosed aspects is a primary factor that reduces compatibility. One could say that all the compatibility issues you can think of stem from this one fact. So, how can this be resolved? Can it be solved just by diligent testing? Of course, the problem is not that simple.

Far more than we might think, the operating systems on which games run vary significantly depending on the type of game and the country.

Far more than we might think, the operating systems on which games run vary significantly depending on the type of game and the country.

XIGNCODE undergoes game operation testing on a wide array of operating systems: Windows 2000 SP4, Windows XP SP2, Windows XP SP3, Windows Vista SP1, Windows Vista SP2, Windows 7 RTM, Windows 7 SP1, and Windows 8 CP. It's no small feat. But don't be surprised just yet. These tests are conducted in Korean, Chinese, Japanese, and English versions of each operating system. As you can see, tests are separately conducted for each service pack that is widely used, due to the significant differences between them. Despite these extensive and complex tests that go on for hours, days, and weeks before a product release, problems still arise. Why is that?

The reason is that the hill we are relying on is, in essence, unstable. It's because of the subtle yet significant fact that we are dealing with undisclosed aspects of these systems. In other words, the product is based on clues that could work perfectly well in the morning but fail in the afternoon, which is not surprising at all. If we complain about this fact, Microsoft, the creator of the operating systems, might respond, “Hey, we didn’t disclose that for a reason. It's not meant for your use.” Therefore, testing alone is not enough to overcome this hurdle. What we observe working during 100 hours of testing might just be a fluke within that specific timeframe.

To overcome this hurdle, we need a method more accurate than testing, a way to definitively determine how the operating system actually functions, rather than relying on limited observations. That's why directly reverse engineering the operating system can be more helpful. Yes, but even reverse engineering has its limits. Hence, the ultimate tool to overcome this hurdle is the Microsoft Source Code Licensing Program. That’s the answer, and that’s the ace up our sleeve.

I am the truth, the answer, and the best.

I am the truth, the answer, and the best.

Another inconvenience users face in relation to this hurdle is the inability to enjoy games in various environments. One common complaint about our product is that it does not run on Wine. This always leads us to a dilemma. In reality, making it run on Wine is not particularly difficult (though it can be). However, the problem becomes complex if hacking is done through Wine. Of course, I don't believe that a benign Linux user would install Linux and Wine solely for hacking purposes. But there's always a chance that it could be exploited for such purposes. We are seriously considering this option and contemplating offering Wine compatibility as an option, depending on vendor policies.

#1 System Hurdle

The next hurdle we must overcome is the gaming system itself. There are a variety of systems out there. Nowadays, it's not uncommon for users to play games on systems that are hard for us to even acquire. This is especially true for older games. Testing in this area is actually difficult. Even though we have dozens of test systems for various environments, they are nothing compared to the systems used by actual users. The range of environments is that vast. Moreover, gamers modify and use these diverse systems in ways we can't even imagine.

The main issue with these varied systems is that users do not apply patches for system bugs. A typical example is the Cool’n Quiet feature bug in AMD CPUs. Using this feature can cause the time measurement function to behave abnormally in certain operating systems. This requires a patch, but users are often unaware of such patches, and since most regular programs run fine without it, many do not apply the patch.

However, for us, these issues are extremely critical. We have to distinguish whether the time irregularities are due to the user installing hacking tools or simply not applying a necessary patch. Consequently, all sorts of tricks are employed. Naturally, these tricks reduce the program's compatibility, make testing more challenging, and lead to a more fragile product.

#2 False Positive Hurdle

From here, we start encountering hurdles that are somewhat self-imposed. The methods to block hacking tools can broadly be divided into pattern-based and logic-based approaches. Pattern-based methods work like identifying someone by their fingerprint, blocking a hacking tool based on its specific signature. Like how a fingerprint won’t be recognized if it’s not in the database, this method can’t block hacking tools that haven’t been collected. Thus, the concept of logic-based methods was introduced. This approach diagnoses hacking tools based on the principle of deducing that a person who behaves in a certain way must be person A. In other words, if a program performs actions a, b, and c, it’s considered a hacking tool. Naturally, like our perception of the world, there are blind spots. A person, or in this case, a program, might perform actions a, b, and c without being a hacking tool. This is where we get tripped up. Of course, if a program openly declares itself as legitimate, the problem is somewhat alleviated. However, when a legitimate program uses various tricks to make itself appear like a hacking tool, it becomes almost impossible to whitelist it.

So, which programs are commonly misidentified? Ironically, it's often game utilities, such as video recording tools for games or messaging programs with in-game chat functionality. These programs are characterized by their operation alongside games, but their internal implementation is quite similar to that of hacking tools. As these programs evolve and use various techniques to avoid detection, it has become increasingly difficult to whitelist them.

Other typical utilities that get caught up in this include virtualization utilities like SandBox, VMware, Virtual PC, and network proxy tools. These may not operate like hacking tools, but they are sometimes blocked upon vendor requests. Despite being blocked, users perceive this as a false positive against a legitimate program.

Another typical program that often gets wrongly accused, due to vendor policies, is JoyToKey. As the name suggests, this program allows users to map joystick controls to a computer and also offers macro functionalities. The problem arises because some game vendors allow this program, while others block it. User reactions are sharply divided. If a game widely uses JoyToKey for hacking and the vendor allows it, the reaction is, "Wow, XIGNCODE is trash. It doesn't even block JoyToKey." Even though it's not that we can't block it. Conversely, in games where JoyToKey is rarely used for hacking, if the vendor's policy leads to its blockage, reactions are, "Why block such a normal program? Are they crazy?" Again, it’s not that we want to block it. So, sometimes, when we get caught in the middle and receive criticism, it can feel a bit unfair.

#3 Collision Hurdle

Collisions present a truly serious problem. Game security products often clash with various elements, particularly with antivirus software. Let's look at a recent collision issue we faced, which was a conflict with the code emulation feature of antivirus software. The first reported case was with AVAST. 99.8971234% of such problems are usually due to hooking the same point or attempting to hook it, so we checked for that first. Surprisingly, there was no issue there. But the game was still crashing. After adjusting various options in AVAST, we observed that the crash occurred when AVAST’s code emulation feature was enabled. Why? Perhaps our code was too complex for the code emulator to handle. We instructed our QA team to report this collision to AVAST since it seemed to be an issue on their end. But was that the end of it? Of course not. We couldn't just tell gamers, “This is an AVAST bug, turn off code emulation to play the game.” So, we modified our code to operate at a level that AVAST's emulator could handle when AVAST was active.

This issue feels unjust because, in reality, it isn’t a bug on our side, but rather an issue with AVAST’s code emulator. Eventually, AVAST reported fixing the feature, but many game developers and users often misinterpret these as our faults, which is frustrating. While AVAST is mentioned here, we faced similar issues with three other antivirus types: MS SE, ESET Smart Security, and McAfee. We didn't even bother reporting the errors to some other vendors due to the hassle.

Why did we use code that even AVAST’s code emulator couldn’t understand? One might wonder if using more straightforward code would have avoided the problem. But this is the dilemma: our product needs to protect our code from hackers and prevent them from understanding it. So, the code naturally has to be complex, which is a crucial part of our competitive edge. We must continue using this complex code, even if it leads to collisions.

These collision issues lead to more complex problems. Special code written to handle collisions can backfire on us. If a hacker realizes we've written special code due to antivirus software, they might exploit it. You might think users wouldn't install antivirus software just because of this, but believe me, if there's a way, anyone wanting to use game hacks will find and install that antivirus. The temptation of game hacks is that strong. There was actually an instance in China where KAV was exploited for hacking attempts. So, we need to report these issues and ensure the antivirus software is fixed, no matter how tedious it is.

At this point, you might be considered somewhat experienced in game security, having about 1-2 years of experience. But you’ll soon realize that even if an antivirus company fixes the issue, we can't revert to the original code. The world isn't that simple. Some users update their antivirus software, but countless others don’t. If we naively revert to the original code once we hear the antivirus company has made a fix, we’ll face the same problems again. It's safer to assume that not all users update their software. So, when those exploiting the special code appear, we need to create special code for that special code. This leads to our source code becoming a convoluted mess, and our logic ends up in some 38.7-dimensional space.

#4 Bug Hurdle

This is a hurdle we definitely need to avoid. Yet, it’s the most common and the hardest to evade. As someone aptly put it, it’s clearly a programmer's mistake. However, the term 'bug' might seem like a way to evade responsibility. But yes, it’s true. It’s our clear mistake, our fault. And we acknowledge that.

But to offer some context as an excuse, it goes like this: Game security products have more builds than one might think. This is because hacking tools are frequently updated, so we need to fix vulnerabilities and adapt to new methods. During intense periods, we might have a full build two to three times a week. In such cases, you can consider our QA team utterly overwhelmed. Moreover, these full builds often happen unplanned. Why? Because we need to block hacking tools. There are countless minor builds. We’ve had instances where we updated a module 24 times in one night. Naturally, the hacker who created the tool ended up going back to school the next week. So, these ridiculous mistakes happen quite often in such circumstances.

In an array that appears to have no problems at all, …

In an array that appears to have no problems at all, …

A situation where a ridiculous bug, like a missing NULL, is hidden. Sometimes, thorough alignment is necessary.

A situation where a ridiculous bug, like a missing NULL, is hidden. Sometimes, thorough alignment is necessary.

Of course, it's only natural. If we're smart and truly skilled, we should be able to create things quickly and correctly, without any issues. This is why we always feel humbled and solemn in the face of these bugs. So, what should we do? Practice, practice, practice... We chant "practice makes perfect" and keep practicing to quickly fix things, make urgent changes, and make modifications without making mistakes. The live environment is literally a battlefield.

#5 A Necessary Evil???

The issues are numerous. There was an instance when a game security program, deployed in a major domestic MMORPG, was removed in North America due to user complaints, which was a humiliating experience. People always say this: Why is it necessary when it doesn’t block 100%, and it’s not without its problems?

However, when you actually look at the details, it's hard to maintain that argument. Just blocking a couple of paid hacking tools that are distributed using game security solutions can be worth more than the annual subscription fee. This is especially true for MMORPGs, where content is key. Below is a scenario where a paid auto-hack tool was introduced in a game. At certain times, 60% of all gamers were using this hack tool. The prevalence of hacks in online games is incredibly high, and game security products are much more useful than you might think. What if these auto-tools were consuming the content? It's not just about the imbalance felt by players. The expensive content developed could be absurdly consumed in no time by machines, not by actual players.

The horizontal axis represents time, and the vertical axis indicates the percentage of users using hacking tools. The destructive power of paid hacks is much more severe than one might think.

The horizontal axis represents time, and the vertical axis indicates the percentage of users using hacking tools. The destructive power of paid hacks is much more severe than one might think.

Game companies that have witnessed their games being compromised by hacking tools deeply realize the necessity of game security solutions. Even games with investments of hundreds of billions can be ruined by hacking, rendering the service non-operational. The need for an effective and reliable security solution is far greater than many might assume, as it’s crucial for minimizing problems and maximizing detection rates.

#6 Overcoming the Hurdles

The challenges and difficulties are numerous. What about the programmers? Facing these many hurdles, game security programmers can become discouraged. They might resort to less aggressive detection methods due to a lack of confidence. They may choose simpler hiding techniques over more complex ones. But the moment they shrink back, it's the end for them as game security programmers, and for the product itself. The absence of confidence quickly erodes the competitiveness of the product and code. A true professional needs the resilience to gracefully leap over all these hurdles while boldly choosing risky methods.

We aspire to create a game security solution that brings a pleasant feeling to gamers. Of course, it's not easy.

At the very least, we don't want XIGNCODE to be a burden for the games that use it. We also want gamers who play XIGNCODE-equipped games to feel that the environment is fair. The XIGNCODE team constantly wrestles with these extremes on the seesaw of decision-making. We've always boldly tackled the most dangerous methods and implemented them in the safest way possible. We practice every day to minimize mistakes because that's the only way to maintain trust with everyone using our product and how we've managed to overcome so many hurdles.

New features are ready, and the QA team is tense. These cool features, as always, will overcome hurdles one by one. Once they do, they will be implemented in games, enhancing the response against new hacks. This way, we make progress every day – our products, our team, and our company.

Choose the most aggressive approach but implement it in the safest way possible. Why? Because we are professionals.

Choose the most aggressive approach but implement it in the safest way possible. Why? Because we are professionals.

Looking back, there were good days and bad days. I record all of my little everyday experiences and learnings here. Everything written here is from my personal perspective and opinion, and it has absolutely nothing to do with the organization I am a part of.
(C) 2001 YoungJin Shin, 0일째 운영 중