[AntiCheat] Game Security: A to Z of Dealing with VIP Hack Tools...

@codewiz · February 29, 2012 · 7 min read

My blog was practically in a shutdown state. I'm not fond of saying I'm busy, but I've been really swamped. My mind was flooded with endless bugs, overlapping CBT schedules, various demands, issues, and even a VIP hack tool... I've been so buried in these that I barely had time to breathe, but now I'm catching my breath. Heh, it's time to talk a bit about XIGNCODE (pronounced as 'Signcode') and the VIP hack tool, something I haven't done in a while.

The recent GG gesture from a particular hack tool group.<br><br>It's unfortunate that only the hack tool creators know this fact.

The recent GG gesture from a particular hack tool group.

It's unfortunate that only the hack tool creators know this fact.

A VIP hack tool is essentially a premium hack tool, not just a regular paid one. It's characterized by quality assurance from the hack tool production groups. Think of it as a hack tool for which you pay a premium price in exchange for quality assurance. Like how security companies guarantee a response within a certain number of hours in their contracts, VIP hack tools offer similar provisions to their users. For example, if the hack tool goes down for 72 hours, they might provide a bonus period. In simple terms, a VIP hack tool is what you get from people who are seriously dedicated to creating hack tools.

Naturally, dealing with VIP hack tools can be quite challenging. In fact, it's often hard to even call it a 'response'. Most VIP hack tools are updated simultaneously with game patches, maintaining an almost constantly available status. In this post, I’ll share some insights and tips(?) based on my experiences in dealing with these VIP hack tools.


Technique and skill. These are in fact the most crucial elements. Without these, everything that follows is simply impossible. Therefore, when creating a game security product, it's essential to hire developers and analysts who are smarter than hackers. Without this, the battle is lost before it even begins.

Here's what this means: Suppose a kernel mode hack tool emerges, and we only have user mode technology. There are situations where you can't find a solution unless you fight at the same level. For example, if you only know DirectX hooking, but the hack tool creator is using WDDM hooking; or you only check for hooks at the function entry point, but the technique involves hooking in the middle of the function; or you only think of hooking through code overwrite, but the hacker uses an exception handler for hooking. In certain areas, if you don’t know the technique, you'll never be able to respond. So, possessing a certain level of technical skill is mandatory.


Tools. This is the second most important aspect. Security products must have codes with a theoretical basis that can definitively end certain fights. When non-client bots or bypass tools emerge, there should be a theoretical foundation for post-response, even if pre-emptive blocking is not possible. Without this, you can't continue the fight. Without such tools, it's simply a case of a bypass emerging and then it's over.

Moreover, for known generic hack tool methods, you need tools so complete that they can entirely block such approaches. When we check a specific API being hooked, there should be no way to bypass our code while hooking that API. The same applies when illegally calling a specific game function – if we protect that game function, there should be no way to bypass our code while making the illegal call. Creating such high-quality code is not easy. But without these codes, the fight can never be ended. You must have tools that can corner hackers into a dead end at some point to end the fight.


After establishing these fundamentals, the truly important thing is updates. Hack tools are distributed immediately upon completion. It doesn't even matter if they cause crashes in some operating systems. They operate on a 'deploy first, test later' model. Even if only some of the hack tools work, users cheer and pay without hesitation.

However, the situation is different for security products. They must function on all PCs, undergo conflict tests with other products, and pass through internal QA, the QA of the game company, or sometimes the QA of the game company's own security team. Even with these complex stages, security products must be updated quickly enough to keep pace with hack tools. If a single security product update can take down a hack tool for a day, then updates should ideally happen daily. Anyone who has responded knows that it's nearly impossible to keep a hack tool down for a day without additional updates.

To maintain such an update cycle, those developing security products need to pay attention to many aspects. Primarily, a structure should be created where hack tools can be blocked by replacing data rather than code. This is because data replacement causes fewer issues than building new versions. Also, it reduces the verification needed, thus shortening QA time. Moreover, you must not waste time analyzing every new hack tool that appears. Block it first, then analyze. This means responses need to be as quick as possible, considering QA time.

It's a race against time. Hack tool users and creators must be made to realize that new updates to their tools will immediately cause problems. Without this awareness, similar to the broken windows theory, a multitude of similar hack tools will emerge uncontrollably.


System variability. Looking closely at this battle, you’ll notice that hack tool groups are few, but their users are many. Thus, one clever strategy to win this fight is to introduce system variability. That is, if our security product behaves differently on the hack tool creator's PC compared to others, it becomes a significant headache for the creator. If the hacker thinks it works on their PC and distributes it, only for users to find it doesn’t work on theirs, it creates an uproar. If such situations occur frequently, the hack tool creator, overwhelmed by complaints, might just give up.


Delayed detection. This is a simple but surprisingly effective method. If you want to delay the distribution of a hack tool, you can achieve this by simply delaying its detection. Of course, the delay should be only as long as it renders the hack tool useless from the user's perspective. For instance, in an FPS game, detect the tool only when the player starts a game after entering a room. Usually, immediate detection is preferred, and known hack tools are detected as soon as the game starts. This is a problem.

This method is effective because it increases the testing time for hack tool creators and exhausts them. They have to enter a game room to see any results. In other words, it takes longer to verify whether their modification has been bypassed. Variable detection times are even more effective. For hack tool creators, it becomes difficult to determine how long they need to test.


Complex internal IPC structure. The key thing you must conceal is how the hack tool is detected. Therefore, there should be a distance between the detection part and the part that reports the detection to the user. Never make the mistake of immediately reporting a detection. Hackers will naturally trace back from the detection point. Create an incredibly complex series of IPC channels. Once the IPC mechanism becomes complex enough, hackers will start to think that it's faster to modify their code than to analyze and patch ours.


With VIP hack tools, the diagnostic routine must never be at a level where it can be bypassed through a generator. Hack tool developers should be forced to think and recompile their code upon seeing our updates. If this is not the case, even truckloads of updates will be ineffective. Every time we update, we must include a diagnostic routine that forces the hack tool developer to at least recompile. It’s even better if the routine requires significant contemplation from the hacker.


Despite all this detailed explanation, honestly, these are really complex, headache-inducing, and tiresome issues. In such cases, just use Wellbia.com's XIGNCODE. They offer excellent game security services at reasonable prices. After all, when you think of game security, XIGNCODE comes to mind, and vice versa.

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