Introduction
Welcome to the first blog in the series of articles where we will be explaining not just what we're building at PROTEKKT, but also why we're doing it. This post is an introduction to the problem, part one in a series of articles explaining our goals and the technology we're building. In the following articles we will be diving more into technical explanations. We will go through examples of code protection approaches and their weaknesses, we will look at the problem from the point of view of someone reverse engineering software protection and last, but not least, we will be talking about what we're building and which new features we aim to provide to our customers.
Illustration of potential misuse of AI agents
In order to understand what we're building, it's important to understand why we're doing it - which problems are we solving and what new are we bringing to the table?
We understand that most software companies utilizing various software protection solutions do not have dedicated reverse engineers among their employees and that sometimes it's hard to choose the right solution. Our goal here is not to present our products behind fancy words, but to:
- Make you understand the problem.
- Show you that we have deep understanding of the problem.
In other words, if we get the question "Why us (as the solution provider)?", our answer isn't a list of protection/obfuscation related words and features. We want you to choose us because you believe that:
- We are capable of delivering quality solutions today, but also:
- We are capable of doing that in the future as well.
Technology advancements
Technology is advancing everywhere and reverse engineering is no exception. Things that took weeks or months to reverse engineer a decade or two ago take significantly less time today.
Introduction of SMT solvers for the purpose of binary analysis and deobfuscation were a significant improvement. The tools people built became capable of removing or simplifying large amounts of obfuscated code. The code that was generated in order to confuse humans looking at it and waste their time became somewhat trivial for computers.
As time went on, people realized that a significant part of what they were implementing was reinventing the wheel. Compilers already perform extensive code analysis and optimizations. Decades of prior work that implements code transformation into simpler form, removal of redundant or unreachable code, constant propagation, control flow simplification and so on. Ready to use libraries perfect for integration with binary analysis and deobfuscation tools.
Although these libraries and toolchains significantly simplify certain problems, the entire process still requires the reverse engineer to perform lots of tasks and human reasoning specific to the software or code they are analyzing.
The age of AI
The cybersecurity industry has extensively started utilizing AI for finding vulnerabilities in all types of software, from smaller end-user applications to extremely large code repositories such as operating system kernels and web browsers. The results are thousands of discovered vulnerabilities that were previously unknown. The fascinating part is not just that many of them are indeed exploitable, but that AI agents haven't just found vulnerabilities, but have also completely autonomously developed working exploits for them.
No domain specific knowledge required from the user. No vulnerability-research expertise required. No exploit development skills required. Just a simple prompt: "Analyze software XYZ for security vulnerabilities".
The AI agents don't just attempt to solve these tasks in their "virtual heads". They implement helper scripts/tools for complex tasks and run them, then reason about their output, run tests, trace suspicious behaviour and repeat the cycle until they succeed.
While there's nothing wrong with using AI for discovering and fixing security vulnerabilities, it's completely natural to always keep in mind "What if a malicious actor uses it before the legitimate ones do?".
Reverse engineering tools and services are no exception when it comes to implementation of AI agents. The industry already offers a wide range of reverse engineering tools with AI capabilities. Some work on smaller portions of code and some already work across entire binaries. Although this is designed for completely legitimate use (e.g. malware analysis), we're coming back to what we kept in mind when talking about AI assisted vulnerability discoveries: "What if a malicious actor used it?". The illustration from above may have sounded too far-fetched for today, but is it really?
Modern software protection requirements
In order to provide reasonable intellectual property security, software protection solutions have to keep up with the advancements in the reverse engineering approaches and tooling. The systems and platforms in use are reverse engineereable by their nature. There is no exact "software protection needs to do this" in order to be effective.
Software protection and anti-piracy versus reverse engineering has always been about complexity. It was never about preventing it completely, but about how much time is needed for a group of highly motivated reverse engineers to understand what (and how) the software does.
While it depends on the software in question, adding more reverse engineers in many cases did not equal faster analysis and reconstruction of code or breaking of the software protection. Very often the process requires solving puzzles one by one, the next one being "unlocked" by solving the previous one. And this is what was the limit for decades. However, in the age of AI agents, you can always speed up the process by scaling hardware.
In order to battle this, software protections need to be significantly more complex than before. What took a person a month to reverse engineer may be a matter of minutes for an AI agent.
It's not about making malicious humans struggle anymore, it's about making computers struggle.
Read the next part: Hardening Against AI Reverse Engineering: Making Computers Struggle