AI Makes Reverse Engineering Mainstream Software & Malware Far Easier

Researchers unpacked, mapped, and recreated complex software and the Turla malware, raising fresh concerns for defenders.

Mainstream software and malware can be reverse-engineered more easily than ever, thanks to artificial intelligence (AI) tools — something that security researchers are warning has implications for cyber defense, intellectual property (IP) theft, and beyond.

Household applications typically run on hundreds of thousands, if not millions of lines of code. They incorporate hundreds of third-party libraries, gobs of files, and complex webs of interconnected components. Unpacking and mapping it all is exactly the kind of task that was so difficult before AI, but is now totally in range for even small teams and individuals.

Cybersecurity researchers from Intezer recently tested out how easy it is to reverse-engineer software with AI by picking on some high-profile candidates: Slack, Apple’s Finder app, and, importantly for security researchers, the Turla malware. Ironically, the malware proved the most difficult to wrangle. They found it only moderately challenging to meaningfully recreate Apple’s and Salesforce’s proprietary apps from the ground up.

“It lowers the bar,” Intezer senior security researcher and malware analyst Nicole Fishbein says of AI. “In the past, to reverse-engineer a software, you needed experience. You needed to understand Assembly, and it took a lot of time. Now, I don’t want to say anyone [can do it], but it is much easier.”

How to Reverse Engineer at Home

As one would when applying AI to any other major task in cybersecurity, to properly reverse engineer a large program, one needs a “harness.” A harness is a little mech suit that focuses a model or models on a specific task, provides it whatever tools it needs to perform its task, and defines its various permissions and restrictions.

No matter her target, Fishbein recalls, “Every case required us to build a different harness, just because the [programs] are so different. For example, if in one case you can just ask Claude to reconstruct the source code, in another case Claude will refuse. Or with malware, when I wanted to be very safe and not execute anything, we had a more complex harness with an extra model.”

The malware reconstruction harness ended up consisting of a deterministic Python control plane wrapped around a compiler, with a virtual machine, various static analysis tools, and multiple large language models (LLMs). “We have an Orchestrator agent that controls this whole thing and sends tasks to different sub-agents. It takes the whole binary and breaks it into smaller functions, based on what tools like Binary Ninja provide. From there it goes through a process of reconstruction that is done by one agent, and another agent will test the results,” she explains.

By the end, Fishbein and her colleague built a Turla replicant featuring its full working pipeline: how it receives and executes commands, its file transfer mechanisms, more or less everything. For malware researchers without overly tight deadlines, she says, “If you can recreate the full picture and not miss any key components, that gives you a lot of information.”

Reconstructing Slack & Apple Finder

Fishbein notes, “When we started this research, something that I had in the back of my mind was people that vibe code apps that mimic other very common apps. I was just curious to see how possible it is” to mimic the source material nearly exactly. It didn’t turn out to be exceptionally difficult, though results did vary.

The researchers’ Finder simulacrum could support plenty of everyday uses as the real app — various file actions, local search, etc. — but the original didn’t reveal enough to allow them to mimic its internal structure precisely.

Slack went over more easily. Whereas Finder relied on files managed by cloud services, and actions whose results depended on other macOS services, Slack offered little that the researchers couldn’t easily unpack by reverse-engineering its Javascript source code. They reproduced the full client “very simply,” they wrote, though they had trouble precisely reconstructing its server, information about which wasn’t so readily obtained. It’s possible, too, that a real-life attacker interested in stealing Salesforce’s proprietary code, or picking it apart for vulnerabilities, might not put too much stock in the infrastructure side of things anyway.

Implications for Hackers & Businesses

On Sept. 10, Anthropic released a report describing how threat actors have been abusing its models. Among other cases, it described significant activity from the Russian threat actor Midnight Blizzard, primarily targeting Ukraine’s government, military, and diplomatic staff. As part of its campaign in Ukraine, Midnight Blizzard had stolen a complete, proprietary software development kit (SDK) for a drone vision system. Over a period of “several days,” with help from Claude, the advanced persistent threat (APT) reverse engineered it. The target was of course unsurprising, given that drones have contributed massively to the war between Russia and Ukraine.

Elsewhere in the same report, Anthropic described a Chinese campaign whose goals included malware development, reconnaissance against foreign governments’ networks, vulnerability discovery in major endpoint security products, and more. To manage so many workflows at once, the actors ran Claude in different workstreams, one of which involved reverse-engineering security products in search of bugs.

In addition to nation-states, Fishbein points to evidence of reverse-engineering lower down on the threat actor totem pole. “We see a lot of malware that all of a sudden will become open source. There is a tendency of taking malware that threat actors see works well, and then either leaking the source code, or just recreating it and making it open source to anyone,” she says.

And, of course, AI is helping reverse engineering reach the upstanding masses. Last month, an open source (OSS) tool and Model Context Protocol (MCP) server called “REA” — short for “Reverse Engineer Anything” — became the single most popular program listed on GitHub.

Now that reverse-engineering is so much faster and more attainable for more people than ever, vendors may need to take more caution with their IP. Their first step might be to define what outcomes they wish to prevent, before deciding on defensive measures. For instance, reverse engineers can straightforwardly reproduce the Slack client, but even in that case they’ll not be able to recreate its entire implementation. “Right now, what the research shows is that as long as you haven’t [exposed] your server-side infrastructure to the customer, you’re protected,” Fishbein notes.

To protect their source code, ironically, developers might take some pages out of hackers’ playbooks. Malware developers (and cautious corporations, historically) have long proven the efficacy of effective encryption, obfuscation — perhaps, even, with help from AI — and other anti-analysis measures in frustrating the cybersecurity defenders interested in reverse-engineering their creations.

“Encryptors or different anti-cheating mechanisms that have been around for a while would also help,” Fishbein says, “but it is hard to tell how long they will hold, with every new model [getting better] every month.”