Fight Fire with Fire: Using AI to Fight AI

App attacks surged to 83% in January 2025, up from 65% just a year earlier. That number alone should give any security team pause — but the more important question is why the curve is bending so sharply upward. The answer isn’t that there are suddenly more attackers. It’s that each attacker is more capable than they were before, and the gap between a novice and an expert has narrowed in ways that should concern anyone responsible for shipping applications to customers. 

Large language models did that. Not gradually, and not at the margins. They compressed the skill and time requirements for attacking an application in the same way they compressed the skill and time requirements for building one. The tools (jadx, IDAPro, Ghidra, Frida) were already there, and others have been in circulation for years. What changed is the expertise required to use them effectively, and the speed at which a motivated attacker can move from target identification to active exploitation. 

A colleague, Cole Herzog, published a technical walkthrough of exactly this dynamic (AI-Powered Hacking, or: How To Learn to Stop Worrying and Love the LLM) and it’s worth reading in full if you haven’t already. Cole demonstrates, step by step, how an attacker uses an LLM to reverse engineer a mobile app binary, set up a dynamic instrumentation environment, and enumerate functions inside a running application. None of the individual steps are new. What’s new is how little expertise each step now requires. 

The business translation is straightforward: the person who lacked the skills to execute this attack twelve months ago probably has them now, or has access to a tool that fills the gap. Cole’s demonstration used a simple hex dump fed into a publicly available LLM to extract API endpoints from an unprotected binary in under two minutes. That’s not a sophisticated attack. That’s an afternoon project and it’s the first step in a chain that ends at your back-end systems. 

The reason client-side applications occupy a unique position in this threat landscape comes down to a fundamental asymmetry that no amount of network security resolves. Your servers sit behind firewalls, authentication layers, and access controls that you own and operate. Your mobile app sits on a device you don’t own, in an environment you can’t control, running code that anyone in the world can download, unpack, and inspect. Client-side code is completely accessible and readable by threat actors. We’re not talking about a configuration problem or a patching gap. It’s the nature of the medium. 

This asymmetry has always existed. Consider a bank with two million monthly active users. Statistically, some fraction of those users has always included people curious about what’s inside the app — and a smaller fraction of those has always included someone willing to act on what they found. That threat existed in 2022, and in 2021, and well before that. What LLMs introduced is a force multiplier on both ends of the attacker spectrum. The attacker who spent weeks reverse engineering a binary in 2023 can now accomplish the same in hours. And the curious user who would have hit a wall of technical complexity and moved on now has a tool that walks them through each step, writes the scripts, and explains the output — right up until the point where a side project stops being curiosity and starts being something more deliberate. The pool of people capable of mounting a meaningful client-side attack just got significantly larger. 

Here is what makes client-side attacks particularly difficult to reckon with: they don’t look like attacks. An attacker who reverses your app, extracts a valid API key, and begins querying your back-end server generates traffic that is indistinguishable from legitimate traffic. The key is real. The authentication succeeds. The requests conform to expected patterns. There is no alarm, no anomaly, no obvious signal that something has gone wrong because from your infrastructure’s perspective, nothing has. The session looks exactly like one of your two million legitimate users. 

This is why the volume of publicly documented client-side breaches understates the actual frequency of client-side attacks. The breach that gets reported is the one that causes an outage, triggers a fraud alert, or surfaces in a regulatory filing. The attacker who moves carefully, harvests data incrementally, and uses legitimate credentials may never appear in an incident report at all. Absence of evidence is not evidence of absence — it’s evidence of a monitoring gap. 

Runtime threat monitoring closes that gap. Knowing that an app is running in a compromised environment, that its code has been tampered with, or that its protection guards are being probed — that information exists at the moment it happens, not after the damage is done. But detection alone isn’t the end of the story. The more powerful capability is reaction: responses coded directly into the app binary that fire automatically when specific threat conditions are met. A banking app that detects tampering can force step-up authentication before the attacker gets further. An app running in a compromised environment can shut itself down entirely. A mobile game that detects a cheating tool can respond with something more creative — disabling gravity for that player’s units, say, so their soldiers quietly float off the battlefield while legitimate players never notice a thing. The attacker gets a consequence. The experience for everyone else remains intact. 

The logical response to a threat that is accelerating is to accelerate the defense at the same pace. That’s easier said than done when building a Protection Blueprint (the configuration that determines exactly how an app gets hardened) requires weeks of back-and-forth between security engineers, sales engineers, and in some cases the app developers themselves. During that time, the app either ships without full protection or the release schedule slips. Neither outcome is acceptable when the threat environment is moving as fast as it is now and delayed release schedules mean delayed profits. 

This is where AI on the defense side enters the conversation — not as a marketing concept but as a practical response to a real operational problem. Quick Protect Agent v2 analyzes the app’s code, determines which components most need protecting, and produces a tailored first-draft Protection Blueprint automatically. What previously took approximately two weeks of collaborative engineering work now takes roughly two hours. That compression matters not just for efficiency but for security posture: the faster protection can be configured and deployed, the shorter the window during which an app is exposed. 

Cole’s post makes a point worth underscoring here. LLMs can only work with the information available to them — which means they can assist attackers in reversing tools whose implementations are publicly known, but struggle against protections they haven’t been trained on. IP-protected hardening creates a gap that open-source tools don’t. The defense that moves quickly, applies protection that isn’t publicly legible to an LLM, and can detect and react to attacks in real time is a meaningfully harder target than one that doesn’t. 

Another point worth considering is that no security tool can be “one and done”. The threat landscape will continue to evolve. All security vendors are dependent on Threat Research teams to stay current. Digital.ai is not different and our Threat Research team is distributed across two continents and ensures our Application Hardening continues to evolve as threats evolve. 

The 2025 Application Security Threat Report documents an attack rate that has been climbing steeply and shows no signs of leveling off. The underlying dynamic driving that curve isn’t going to reverse — the tools are out there, they’re improving, and they’re accessible to anyone motivated enough to use them. That’s the environment your apps are operating in today, and it will be even more pronounced a year from now. 

None of this argues for panic. It argues for honesty about what the threat actually is, where it lives, and what it takes to address it seriously. The client-side attack surface isn’t going to disappear because you patched your servers or tightened your network perimeter. The attacker who downloaded your app, fed its binary to an LLM, and started mapping your back-end pathways didn’t touch your infrastructure. They didn’t need to. 

The good news is that the same technology accelerating the attack is available on the defense side, and the fundamentals of what makes an app hard to attack haven’t changed: Obfuscation that an LLM hasn’t been trained on. Runtime protections that detect and react before damage is done. Hardening configured precisely for the specific app rather than applied generically. Speed of deployment that matches the speed of the threat. These aren’t new ideas. What’s new is the urgency of applying them well.