[AntiCheat] Game Security: The Hidden Truths in Patents and Reports

@codewiz · October 30, 2012 · 4 min read

These days, when meeting with new companies, patents and reports always come up as a frequent topic. It seems like people in the industry have great illusions about these, so let’s talk about that today.


Let's start with patents. Personally, I find the concept of software patents somewhat comedic. Despite this, because respected individuals have crafted relevant legislation, the patent system exists, and people apply for patents to protect their rights. Game security companies are no exception, filing numerous patents. Large companies, with their patent support systems — offering rewards for filing patents — encourage employees to constantly think of new patents to file.

However, there's a serious level of misunderstanding regarding patents. The biggest misconception is this: “Wow, company A has registered this amazing patent to block such hacking tools,” as reported in the newspapers, leading to the naive belief that their solution will block all such hacking tools. Would it really block them? I bet it wouldn’t. Reality is that even a child’s hacking tool cannot be blocked by a few pages of clever wordplay, let alone a wide range of hacking tools they claim to block. It's simply unrealistic.

The second misconception is this: if a patent is registered, people assume the solution must incorporate that feature. But this is not necessarily true. Software patents are about recognizing someone's idea, not verifying whether they have actually implemented it. A patent can be registered without an existing implementation. So, let’s end the misconception that a registered patent guarantees the technology's incorporation into a solution. A patent is just that, a patent, nothing more.

Interestingly, most game security patents resemble a system of simultaneous equations. They set hypotheses to catch hacking tools and link these hypotheses in such a way that, if certain conditions are met, the subject can be considered a hacking tool. It's like solving simultaneous equations by eliminating variables to find the solution. But as we know from middle school math, the number of equations should match the number of variables. Yet, many game security patents lack sufficient equations to solve the system, making it impossible to resolve.

Why the shortfall in equations? It could be intentional concealment, or perhaps they filed the patent for show without knowing the remaining equations. Some patents I've reviewed had missing equations with complex implementations. I wondered if they truly implemented such complex components, and often, they hadn’t. My experience in game security tells me that usually, the hard-to-implement parts are missing. In theory, no hacking tool is uncatchable. The difficulty lies in implementation. Creating functioning code, especially code robust enough to combat hackers, is incredibly challenging. Patents are just patents; let’s boldly abandon the naive belief that they can block hacking tools.


Now, let's look at reports. It’s funny that some companies seem to pride themselves on writing good reports. When I heard this, it felt like idol-like advertising to me. A singer's main job is to sing, so it’s natural to talk about their singing skills first. But idols often focus on other aspects, like dancing or looks. Praising report-writing skills in this industry feels similar.

Having worked in this field for six years, I think I've tried every method imaginable to block hacking tools. I’ve even prayed at temples for it! Naturally, there was a time when we produced reports, formatting them beautifully in Word documents, neatly organized in the repository. But despite accumulating reports, our ability to block hacking tools only seemed to worsen. The realization was simple: we spent so much time formatting reports, capturing screenshots, and pasting code that we lacked time to create actual blocking codes. Hacking tools are blocked by patterns and blocking codes, not by reports. So, we decided to stop writing reports, and like magic, we started successfully blocking hacking tools one after another. The notion that detailed analysis leads to more effective blocking codes is a myth. The truth is far from it. But that’s a story for another time.

Think about it: why do game security companies need to write reports? When do they write analysis reports? Obviously, when they desperately can’t block a hacking tool. It’s like saying, “We couldn’t block this tool, but look at how hard we’ve analyzed it,” to the companies that bought the product. If the tool is blocked, there’s no need for a report. So, advertising good and frequent report-writing is essentially the same as saying, “We’re really bad at blocking hacking tools.”

We had a weekly meeting where, for the first time in a while, we discussed writing a report. Why? Because we were dealing with a persistently updating hacking tool that just wouldn’t be blocked. We decided to write about one of the two we discussed, as the other had already been resolved. Typically, we collect between 4,000 to 10,000 new hacking tools weekly. It’s unrealistic to think we can execute or test all of them, let alone write reports. We’re simply too busy adding patterns, creating blocking codes, and fixing vulnerabilities.

Remember this well.

An analysis report is used when hacking tools don't get blocked.

And the report doesn't actually prevent hacking tools.

Patents and reports also do not prevent hacking tools.

Patents and reports also do not prevent hacking tools.

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