[AntiCheat] Collision Hell…

@codewiz · November 25, 2011 · 3 min read

As a programmer earning my living, I've come to despise a particular word: "Crash". Just hearing it, even while eating, feels like everything is coming back up. It's that unpleasant and annoying, and something I wish to avoid. After specializing in security, another hated word emerged: "Conflict". Making a good security program essentially means avoiding as many conflicts as possible. This is evidenced by many security companies highlighting the lack of conflicts as a key feature of their products. It's ironically humorous that instead of touting the performance of security products, the absence of conflicts is considered a major advantage. More amusingly, customers prioritize this too. In practice, conflicts are a critically important element.

Having worked on game security products for five years, I thought I had seen every possible conflict. Conflicts with similar security products were just the beginning, not to mention those with various other security products, and even game hacking tools. There was this kernel mode game hacking tool, poorly coded, causing a blue screen if you closed the game while it was running. Ironically, we changed our entire hook code just to avoid conflicts with this hacking tool, which in hindsight seems like an overreaction. But at that time, it felt necessary. It was a significant task. Changing all the hook codes led to conflicts with a Chinese firewall product, for which we added special code. It's a lawless world, with no traffic lights or rules, where we must avoid all conflicts. Experience is king in this world, and avoiding conflicts, seemingly trivial, becomes our strongest barrier to entry. Quite a funny fact.

Having experienced all sorts of conflicts and adding code to avoid them, I thought I had faced it all. But today, I witnessed a real bombshell of a conflict. Our product is a game security product, designed to prevent cheating during game play. But what happened? A conflict arose with the game itself, or more precisely, with its inbuilt security code. Hilariously, the game's security code was catching our security product. It was unbelievable. This doesn’t mean the game did anything wrong. Nowadays, with hacking issues being prominent, large game companies have their own security teams developing modules to enhance game security. This is a positive trend and beneficial for external security companies, as external products often face limitations in integration with games. But, the internal security teams don't have these constraints. Anyway, the security code did its job. We just need to find a loophole in that code to perform other necessary functions.

This might make it seem like we’re always on the receiving end of conflicts. However, we often cause more conflicts. Most affected programs are game utilities, like Bandicam, a well-known recording utility I used to use for capturing World of Warcraft videos. It’s much more powerful than Fraps. But Bandicam frequently conflicts with game security products, including ours. We had to whitelist it. While doing this, I often marveled at Bandicam's complex hooking code. If it had clearly indicated to us that it was Bandicam's hooking code, it would have been easier to allow. But surely, Bandicam's developers had the same concerns, needing to avoid detection by security products. So, they might have gone to such lengths for that reason.

At this point, one might think how foolish all this is. Those on the receiving end of conflicts write more complex code to avoid them, and those causing conflicts write even more complex code to allow these. It’s a feedback loop increasing entropy. In this context, the code I'll write tonight will someday become a nuisance for the person who wrote the game’s security code. My complex code to avoid conflicts will turn back into a conflict for them. Watching this cycle, one can only laugh.

I remember reading a book about TCP/IP, where I came across the CSMA/CD (Carrier Sense Multiple Access with Collision Detection) concept. It struck me as a simple yet ingenious method. Tonight, as I write code to avoid yet another conflict, I’m reminded of CSMA/CD's Collision Detect. Don’t we have a way to break this vicious cycle and automatically detect conflicts?

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