A security researcher recently trained a Long Short-Term Memory (LSTM) neural network to recover 65% of Advanced Encryption Standard (AES)-encrypted firmware. Not by breaking the encryption algorithm (AES remains mathematically sound), but by exploiting a subtle implementation flaw: The manufacturer had reused the same encryption key and nonce (a unique one-time value) across 34 different firmware versions.
The attack required collecting firmware samples, identifying the key-reuse pattern, and training a machine learning model to predict the original bytes based on how firmware is typically structured—in opcodes, memory addresses, and instruction sequences.
The computational cost? An Nvidia A100 GPU is rented for a few euros per hour. The time to train? About eleven hours. The result? Firmware that was supposed to be cryptographically protected is now readable in Ghidra.
Just a couple of years ago, this attack would have been theoretical—the kind of thing discussed in academic papers but rarely executed in practice. Today, the researcher published their methodology, training scripts, and model architecture on a public blog. Anyone with basic machine learning knowledge and a cloud GPU can replicate it.
This is the new reality. AI has fundamentally changed what’s possible in reverse engineering. And your applications are the next target.
The firmware attack is striking, but it’s just one example of a broader shift. Across the reverse engineering landscape, AI-powered tools are emerging that dramatically lower the skill barrier for analyzing compiled code.
Let’s settle this: Die Hard is a Christmas movie, and compiling code is merely a way to distribute it, not a security feature. Compiled code can be reversed just as easily as any JIT-ready artifact.
Consider LLM4Decompile, an open-source project from researchers at Southern University of Science and Technology and Hong Kong Polytechnic University. Their team trained a series of large language models, ranging from 1.3 billion to 33 billion parameters, specifically to convert binary code back into readable source code. These aren’t general-purpose chatbots repurposed for code analysis; they’re purpose-built decompilation engines trained on 4 billion tokens of C source code and corresponding assembly.
The results are remarkable. In benchmarks measuring whether decompiled code can actually be recompiled and executed, LLM4Decompile outperforms both GPT-4o and the industry-standard Ghidra decompiler by over 100%. The decompiled output doesn’t just look like source code—it runs. Variable names are semantically meaningful. Control flow is reconstructed accurately. Comments are inferred from context.
But you don’t need to train your own models. A growing ecosystem of tools integrates LLMs directly into existing reverse engineering workflows. GhidrAssist, GhidrOllama, and ReVa are plugins that connect Ghidra to local or cloud-based language models, enabling natural language queries against binary files. An analyst can highlight a function and ask “explain what this does” or “identify potential vulnerabilities,” and receive detailed, contextual answers. The plugin handles the complexity of extracting relevant code, formatting it for the model, and presenting results, all within the familiar Ghidra interface.
What once required years of experience reading assembly and understanding compiler patterns can now be approximated by someone who knows how to write a good prompt. As one presenter at RSAC 2025 put it: “Senior colleagues had to spend thousands of hours learning to deobfuscate code via painstaking trial and error, whereas today’s new malware researchers can rely on LLMs to do a lot of this work for them.”
Attackers are now weaponized more than ever before.
Here’s what makes this particularly concerning for application security: these AI capabilities work best against unprotected code. When the code follows standard compilation patterns, uses recognizable library functions, and preserves debugging symbols, AI models can leverage their training data to make accurate predictions about structure and intent.
The inverse is also true. When researchers tested state-of-the-art LLMs against heavily obfuscated malware from the Emotet campaign, even the best models struggled to fully reconstruct the original functionality. Obfuscation, the deliberate transformation of code to resist analysis, created friction that AI couldn’t fully overcome. The models could extract some indicators of compromise, but the obfuscation layer significantly degraded their effectiveness.
This finding has a clear implication: if your compiled applications lack code hardening, symbol renaming, control flow obfuscation, and string encryption, AI-powered tools will tear through them with minimal effort. The binary becomes, effectively, an open book.
OPSWAT recently demonstrated just how accessible these capabilities have become. In a live demonstration, a user with no malware development experience created functional, near-zero-day malware in under two hours using open-source AI models running locally on a consumer gaming PC. No specialized training. No deep technical expertise. Just the right prompts and publicly available tools.
Now imagine that same capability, AI-assisted code analysis by someone who isn’t an expert, pointed at your unprotected application binaries. Your proprietary algorithms. Your licensing logic. Your API keys and authentication flows.
This is precisely why layered code protection matters more than ever. Obfuscation raises the complexity ceiling, transforming readable patterns into tangled control flows that resist automated analysis. Runtime Application Self-Protection (RASP) adds another dimension—detecting tampering, debugging attempts, and code injection in real time and responding before damage is done. Together, these defenses don’t just slow attackers; they force AI tools to work against actively hostile code that fights back.
Imagine obfuscation as a stealthy camouflage, and RASP as a tactical countermeasure that a fighter jet uses when it is radar-locked.
The threat isn’t hypothetical: Security researchers are already documenting AI-assisted attacks in the wild.
SentinelLabs recently analyzed a case where a threat actor used an AI coding assistant to orchestrate a highly autonomous extortion campaign. The AI didn’t just help write malicious code; it evaluated which stolen data was most valuable, calculated optimal ransom amounts based on the victim’s profile, and generated customized ransom demands designed to maximize psychological pressure. Tasks that previously required a coordinated team with diverse skills were collapsed into a single operator working with a well-prompted AI.
Language barriers, once a natural limitation on attacker reach, are dissolving. SentinelLabs notes that Russian-speaking operators might not recognize that a file named “Fatura” (Turkish for “invoice”) or “Rechnung” (German for “bill”) contains sensitive financial data. But an LLM identifies these instantly, regardless of language. Attackers can now instruct a model to “find all documents related to financial debt or trade secrets,” across files in Arabic, Hindi, Japanese, or any other language, and get actionable results.
Perhaps most concerning: top-tier threat actors are already migrating to self-hosted, open-source models to avoid the guardrails built into commercial AI services. Tools like Ollama make it trivial to run capable language models locally, with no usage logging, no content filtering, and no provider oversight. As these local models improve—and they’re improving rapidly—defenders will lose the limited visibility that cloud-based AI providers currently offer into malicious use patterns.
The security community’s assessment is sobering but precise: What we’re witnessing isn’t a revolution in attacker capabilities, but a significant acceleration. The fundamental techniques— reverse engineering, code analysis, and vulnerability exploitation—remain the same. What’s changed is the speed at which they can be executed, the scale at which they can be deployed, and the skill level required to deploy them.
Competent threat actors are becoming faster. They can operate across more platforms, more languages, and more geographies than ever before. Meanwhile, the skill floor for launching sophisticated attacks continues to drop. Tasks that once required years of specialized training can now be approximated by motivated amateurs with access to the right tools.
If your security strategy assumes that compiled code is inherently difficult to reverse engineer, that obfuscation is optional because “security through obscurity doesn’t work,” or that sophisticated attacks require sophisticated attackers—those assumptions are now dangerously outdated.
The organizations that will weather this shift are those that treat code protection as a core security requirement, not an afterthought. That means obfuscation to raise the cost of static analysis, RASP to detect and respond to runtime attacks, and a defense-in-depth mindset that assumes attackers will eventually get access to your binaries (because they will).
In upcoming posts, we’ll examine exactly how exposed .NET and Java binaries really are, what’s at stake when your code is compromised, and the specific techniques that modern application security demands.
The question isn’t whether AI will be used against your applications. It’s whether your defenses will hold when it is.
1. “Something From Nothing – Breaking AES Encrypted Firmwares.” Something From Nothing Blog. https://something.fromnothing.blog/posts/something-from-nothing/
2. Bernadett-Shapiro, G., Walter, J., & Delamotte, A. “LLMs & Ransomware: An Operational Accelerator, Not a Revolution.” SentinelLabs, December 15, 2025. https://www.sentinelone.com/labs/llms-ransomware-an-operational-accelerator-not-a-revolution/
3. Tan, H., Luo, Q., Li, J., & Zhang, Y. “LLM4Decompile: Decompiling Binary Code with Large Language Models.” arXiv:2403.05286, October 2024. https://arxiv.org/abs/2403.05286
4. Patsakis, C., Casino, F., & Lykousas, N. “Assessing LLMs in Malicious Code Deobfuscation of Real-world Malware Campaigns.” Expert Systems with Applications, July 2024. https://arxiv.org/abs/2404.19715
5. RSAC Conference. “LLMs Save Threat Researchers Time.” RSAC 2025. https://www.rsaconference.com/library/blog/llms-save-threat-researchers-time-but-our-obfuscated-javascript-case-study-shows
6. OPSWAT. “AI Hacking: How Hackers Use Artificial Intelligence in Cyberattacks.” September 2025. https://www.opswat.com/blog/ai-hacking-how-hackers-use-artificial-intelligence-in-cyberattacks
7. Tang, J. “GhidrAssist: An LLM Extension for Ghidra.” GitHub, 2025. https://github.com/jtang613/GhidrAssist