[AntiCheat] Game Security: The Timing War

@codewiz · July 08, 2012 · 9 min read

Looking at a book titled 'A Book On C,' it starts by explaining the meaning of 0 in the C language. It serves as the starting index number in arrays, signifies the end of a string, represents falsehood, among other things. Similarly, in game security, timing is used in a variety of ways and is an important concept. Today, I will write a bit about this aspect of timing.

#0

There is a timing when game security products inevitably have to start a step behind, and that's the execution timing. This is because the first axiom of game security products is that 'a game security product can never run before a hacking tool'. To overturn this premise, product P from overseas even resides in memory regardless of game execution. However, it still only runs after the operating system has started. If a hacking tool runs before the operating system starts, there's nothing to be done. Of course, this isn't to assume such an extreme — though it's not really that extreme — case. Even without considering this, there's a major reason why Product P's strategy doesn't work. It's the specificity of game security. General security products are used by users to protect their PCs from hackers. However, in game security, the users themselves become hackers. So, even if it resides in the system, if users terminate the process with the intention to use a hacking tool, it's over. You might think about operating very covertly. Sure, it's possible. But if it's too covert, it ends up fighting with the antivirus neighbors. Angry antivirus friends classify us as a white rootkit and ruthlessly delete us. Anyway, we shouldn't fight with antivirus friends. We need to stay on good terms, haha~

For this reason, the pre-game execution realm remains an eternally uncharted territory for game security products, much like how the moment of the Big Bang seems like an unsolvable mystery to us. XIGNCODE, to respond more effectively to these constraints, develops most of its technology from the perspective of detection rather than blocking. This is because blocking is always ultimately a method bound to fail, as it cannot start first. If we look at the history of game security, there's a bit of a trend. In the very early stages, it borrowed the detection perspective from antivirus, then as hooking developed, it shifted to a blocking perspective, and as hooking technology in the hacking tool camp also advanced, it's shifting back to detection. The form of blocking spoken of in all game security products today can be considered just a shell to stop the fools. That doesn’t mean blocking technology is completely meaningless. Most of those who try to create hacking tools are such fools.

#1

Next in game security, a crucial topic is INFINITE. In this field, INFINITE is considered a big taboo. What is INFINITE? It means indefinitely waiting for a specific event or message. Developers learn to use INFINITE in programming to avoid creating synchronization issues. However, in game security, using INFINITE is a fast track to creating a poor product.

I'll show you how easily your assumption that everything will eventually respond shatters!!!<br><br>Taste the world that never responds forever.

I'll show you how easily your assumption that everything will eventually respond shatters!!!

Taste the world that never responds forever.

For example, consider a scenario where a game security product covertly sends a SendMessage to a specific window in a critical part of the game. We might not know which window it is. Typically, a message would return. But what if a hacker becomes aware of this? They might create a window that does not respond to the SendMessage, effectively rendering the security product useless. This isn't just about SendMessage; in any event, one should never wait indefinitely. These are points that can be easily attacked. Therefore, in most cases, game security products set a timeout. If there is no response past this timeout, they can proceed to the next procedure.

Smart rookie game security developers often make this point: "That's because the game security product operates independently of the game. If it were integrated with the game, such actions might not be feasible, as it would also cause the game to freeze, right?!" Indeed, they are sharp developers. They'd be hired on the spot if they applied to our company. They've correctly identified a key consideration in game security, but there's a caveat. It's ideal to covertly add security code to the rendering thread. However, this can lead to a myriad of other issues, the most prominent being lag. While this approach might prevent hackers from delaying responses, it also risks causing screen freezing in normal situations due to rendering thread delays. Therefore, it's best to add only very carefully and cautiously written code to the rendering thread.

#2

Next, there's the matter of activation timing. This refers to the point at which hacking tools are actually activated within the game, not just when they are executed. Most hacking tools released nowadays do not activate at the same time they are executed. Why? To bypass security products. Traditional game security products only performed hacking tool checks at the game's launch. Thus, hackers would wait for these checks to complete before activating their hacking tool codes. Since the scan had already passed, they could easily bypass the security products, even with older methods.

Game security developers didn't just stand by, of course. They made changes to perform checks periodically. What did hackers do then? They restored their code periodically. This means if they knew the initial avoidance time and cycle, they could reset their modified code to the original during these cycles, and then re-modify it after the security scan was over. What next? Naturally, the security product developers made the cycles random and unpredictable. However, activation timing remains a critical aspect, as depending on the method of inspection, the cost can be too high to allow for frequent checks.

Gamers also adjust the injection timing using the manual method.

Gamers also adjust the injection timing using the manual method.

Of course, it's not just hackers who use such methods. Users also utilize activation timing, commonly referred to as 'injection delay' strategies. Hacking tools that operate through DLL injection can be detected or go unnoticed depending on the timing of the injection. This is a tactic used in the presence of such vulnerabilities. In the past, manual injection methods were used, allowing gamers to decide when to inject. Once a hacking tool user found a moment when detection was avoided, they would share the method in their community. "Wait for the game to launch, see something appear, and inject after about 3 seconds – that worked." Based on this vague advice, others would try to replicate the process, though it's not easy. Taking pity on these people, a hacking tool developer eventually upgraded the injector. This new version allowed users to specify the injection delay in milliseconds. After this development, the community shifted from sharing vague stories to simply exchanging the precise milliseconds for injection, a somewhat sad evolution of the scenario. Haak~

#3

I'm the famous Alta. But XIGNCODE only scans once, even if a thousand instances are launched.

I'm the famous Alta. But XIGNCODE only scans once, even if a thousand instances are launched.

Another term commonly used by gamers is 'Alta', short for 'Alzip timing'. This refers to running multiple instances of Alzip simultaneously. There are variations like Alta50 or Alta100, indicating the simultaneous execution of 50 or 100 instances of Alzip at the game's launch. This tactic is designed to delay the game security product's detection of hacking tools by occupying it with checking Alzip instances. Impressive, isn't it? The desire of users to hack games is indeed intense. While different in principle, a related method is 'Fraps timing'.

💡 Alzip: The most famous compression utility in Korea.

XIGNCODE employs various techniques to counteract such methods. It fundamentally uses caching for almost all its inspection items. There's no need to scan the same object twice. For well-known programs like Alzip, it uses whitelisting to expedite their inspection. Additionally, it prioritizes the inspection of objects that resemble hacking tools. Ultimately, methods like Alta are rendered ineffective against XIGNCODE.

#4

There's also a strategic timing element in the ongoing battle between hackers and game security developers, known as release timing. This refers to the timing of distributing newly created hacking tools and the application of security updates to block them. You might wonder if this is really a battleground? Absolutely, it's intense. But, as mentioned in a previous article, game security developers are at a significant disadvantage because updating security products requires an enormous amount of time and effort from numerous personnel.

Let's consider who engages in this kind of strategic battle. When would be the most annoying time for a game security developer for a new hacking tool to emerge? Yes, you guessed it – Friday nights. Imagine the frustration when these updates happen on a fiery Friday night. Even more irritating, some hacking tool sites announce things like this, usually referring to overseas hacking tools: "We have already created the hacking tool and will update it on Friday night, Korean time. Ha~ My blood pressure~ 😢~ This is the nature of the industry.

But the developers of XIGNCODE aren't just sitting ducks. They don't just create one diagnostic routine; they create several at once. And, as previously explained, these are designed to activate differently based on the system and time. So, it's Friday night, and the hacker excitedly releases their tool. What happens next? Right, there's an uproar among users. The hacker faces a meltdown situation, as the tool seems to work on their own PC. The more inconsistencies there are, the more likely the hacker is to give up.

The avatar of that guy stuck on the whiteboard of the XIGNCODE development team~

The avatar of that guy stuck on the whiteboard of the XIGNCODE development team~

Speaking of this strategic battle, it reminds me of a notable figure in the history of XIGNCODE. There was a hacker so infamous that their avatar and a 'WANTED' sign were once posted on the development team's whiteboard. This person, unique in having such a distinction, had created an early bypass for XIGNCODE 1.0, which, theoretically, was the most perfect model ever made. It gave us quite a headache. To counter this individual, we had to update the XIGNCODE code on the game servers. Although XIGNCODE is designed to be updated even while the game server is running, game companies are not particularly fond of doing so. Often, the only updates we could make were during the weekly scheduled maintenance. To maximize our single shot each week, we created different codes for Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, and Sunday. This tiresome battle lasted about 9-10 months. However, with the launch of the third version, XIGNCODE3, this individual eventually vanished from the community. It's a somewhat tragic end. They were adept at SEH hijacking and hooking. Despite being an adversary, their skills were admirable. Here's to hoping they lead a good life forever, haha~

#5

In war, the most important element is information, and the next is timing. The same applies in game security: information and timing are crucial. If the costs are the same, I believe it's better to use solutions developed by those who truly understand these aspects. Haha~

Just changed one security product, and the rumors in the hacking tool community spread so fast. I wonder why?

Just changed one security product, and the rumors in the hacking tool community spread so fast. I wonder why?

It's because XIGNCODE is the only solution that sends hackers back home.

It's because XIGNCODE is the only solution that sends hackers back home.

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