[AntiCheat] Game Security: The Race Towards Zero…

@codewiz · April 11, 2013 · 7 min read

We, too, always dream of the Zone of Zero.


Games are among the most hardcore of programs. They're often the primary reason people upgrade their hardware. One of the biggest challenges for game security programs that run alongside these games is that they must not affect the game's performance. Try running a game with an antivirus scan in the background and see how much it slows down - you’ll immediately understand what I'm talking about. Game security programmers have to put in a lot of effort to make their programs operate as if they weren't there at all.

#0

XIGNCODE is one of the very few game security products that employs some of the most aggressive detection routines. Such aggressive methods are the only way to increase the difficulty for hack tools and to stand a fighting chance. Of course, that doesn't mean hack tools will disappear 100% – just keep that in mind. What it does mean is that we can maintain a relatively higher quality of hack tool control haha~

XIGNCODE CPU usage on an AMD 2.7GHz single-core processor

XIGNCODE CPU usage on an AMD 2.7GHz single-core processor

An aggressive approach, in other words, means more computations, which in turn means more CPU resources are needed. However, for game security products running concurrently with a game, there's an inherent need to minimize CPU resource usage. So, we try really hard to keep the CPU usage as close to zero as possible during gameplay. Thinking "0%? So, it doesn't use the CPU at all?" would be a misconception. We are talking about using 0.0001%, 0.00001%, and so on. It’s our constant effort to increase the number of zeros in front of that 1.

Typically, if a game security product uses more than 2% of the CPU for a single core, sensitive users will notice lag instantly. If it goes above 3%, even less sensitive users will notice stutters, and at 5% usage, all users will begin to complain about lag – I'm referring to the minimum system requirements, of course.

So, we must avoid any sudden excessive CPU usage at all costs. It sounds very easy when you put it like that, right? Just use less CPU. But it’s not that simple in practice, because there’s actually no official way to allocate CPU quotas for each thread in a Windows environment, which makes accurately limiting the CPU usage of a game security product more complicated than it seems.

If we could implement our own preemptive scheduler outside of the Windows scheduler, the issue could be somewhat simpler, but it’s not easy to implement such a scheduler in user mode in a Windows environment. You can tell this by the fact that fibers are implemented non-preemptively. Of course, there’s the option of replacing the kernel scheduler, but it's neither documented nor without significant risk to the entire system, making it tough to use in a commercial product.

#1

You might wonder why we're causing such a fuss when we can just run things slowly. You are right. However, there's another pressing factor from the other side demanding our attention, and that's the cursed timing. In order to lower CPU usage, detection code cannot be infinitely slow. Depending on the game, 3 minutes and 5 minutes are significantly meaningful detection times in game security.

If detection occurs within 3 minutes, in the case of paid hack tools, the creator will announce that the tool has been patched and will update the hack tool. Even for the most malignant users, if detection occurs within this timeframe, they tend to hold off using the hack tool.

If diagnosis happens around 5 minutes or is delayed further, hack tool creators won't make an announcement about a patch. Users perceive this as a penalty. Aggressive users continue to use hack tools. If detections are made within 5 minutes, hack tool users will continue to exist in the game, causing players to encounter them repeatedly and get the impression that hacks are rampant.

In other words, the dreaded timing means that hack tools must be blocked within 3 minutes at most, and in the worst case, players should not be able to continue their gameplay for more than 5 minutes. To achieve this, obviously, CPU resources must be used. Hence, finding the optimal balance between CPU resource usage and hack tool detection speed is vital. Only then can you use the minimum possible CPU resources while keeping the detection speed at an acceptable level.

#2

For this reason, XIGNCODE uses a somewhat unique dispatching strategy. Our strategy's key lies in timing. We categorize this timing into four main criteria. The first one is the S moment when the game starts. This is when users are waiting for various game data to load. Next, there's the P moment when the game has started and users are enjoying the game. There’s also the L moment when users pause their game to do something else. In a Windows environment, this would mean when the game is not the active process. Finally, there's the X moment when a hack tool is detected. If you're clever, you might have already guessed why we categorize moments like this – the same routine may consume different amounts of CPU resources depending on when it is executed.

At the S moment, since users are already waiting for the game data to load, routines scheduled at this time utilize all available CPU resources. At the P moment, since users are actually playing the game, they are scheduled to use the least possible CPU. As we'll see later, routines are also designed to receive a diminishing return premium.

The L moment is a bit ambiguous. If at the L moment we immediately perform operations that consume all CPU resources, then users will notice lag if they quickly return to the game. If the time away exceeds a certain level, all detection routines operate in a way that consumes a lot of CPU resources, comparable to the starting point. Other processes might not appreciate it, but since it doesn’t incur any penalty from a gameplay perspective, it’s acceptable. Lastly, the X moment is when we can make a real mess. It’s the most glorious moment where even crashes don't scare us; we're in an invincible state haha~

#3

XIGNCODE also employs sociotechnical techniques to reduce lag, specifically in the scheduling policies of the detection routines. All of XIGNCODE's detection routines are scheduled in a retardando fashion. Wondering what retardando means? It means things will gradually slow down. Why? To minimize the impact on legitimate users.

Hack tool users tend to start using hack tools as soon as the game starts, and 80% of all hack tool detections stem from 20% of malignant users. Surprisingly, the 80/20 rule seems to apply everywhere. Anyway, sociotechnically, users who play nicely tend to continue playing nicely. So all of XIGNCODE's detection routines are scheduled to suffer diminishing returns. Starting after a certain period following the game’s launch, almost all detection routines operate as if they were dead. Of course, even in such cases, detection should still be possible within the 3 minutes mentioned earlier.

Windows users may have noticed that Windows seems to speed up the more they use it. Also, a program may perform faster the more frequently it is run compared to its first execution. This is thanks to operating systems' caching systems that offer such functionalities. It's a simple concept–often requested resources are cached in advance, ready to provide them instantly the moment a user makes a request. It’s interesting how efficient this system can be because most users repeatedly use the same programs. The XIGNCODE development team has been considering adopting a scheduling policy that incorporates this caching system. In essence, the more you play the game honestly, the less performance penalty you will experience from the security product; conversely, the more you mess around with hack tools, the more it will grate on your system.

Sadly, there is no Silver Bullet here.<br><br>Though, you don't need to be too disappointed.<br><br>After all, you have top-notch handcrafted epic ammo in XIGNCODE.<br><br>When you're in doubt about your damage output, check your ammo first. We'll rip up the damage meter for you.<br><br>Always remember, New Yorker hunters even use epic ammo when they grind ㅋ~

Sadly, there is no Silver Bullet here.

Though, you don't need to be too disappointed.

After all, you have top-notch handcrafted epic ammo in XIGNCODE.

When you're in doubt about your damage output, check your ammo first. We'll rip up the damage meter for you.

Always remember, New Yorker hunters even use epic ammo when they grind ㅋ~

@codewiz
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일째 운영 중