Obfuscation vs AI: How much protection does your app really have?

An attacker does not need to understand your entire app. One reusable credential, one exposed customer record or one route to an unauthorised operation may be enough to cause harm.

Obfuscation can make that work harder. AI-assisted analysis increases the pressure to demonstrate how much harder, and what remains protected when an attacker succeeds.

For organisations whose apps handle sensitive data or valuable transactions, this calls for a closer examination of what an attacker can obtain, how much effort it takes and what they can do with the result.

What makes your app worth attacking?

The potential reward extends beyond data stored on the device. An app may contain credentials, proprietary logic or material that helps an attacker interact with backend services. Its legitimate functions may also become a route to account takeover or unauthorised transactions.

These assets have different consequences. Recovering a configuration value may reveal little of immediate use. Recovering a reusable credential could expose services or accounts. Accessing customer information can cause harm even when no payment is possible.

Start by identifying what makes your application valuable to an attacker. Then consider whether a successful technique could be repeated across customers, devices or releases. A weakness that can be exploited repeatedly creates a different level of exposure from one requiring extensive work on each individual device.

AI puts pressure on the cost of analysis

Reverse engineering involves inspecting binaries, choosing tools, observing execution and testing hypotheses. AI agents can (largely) automate parts of this investigation and produce scripts for repeated analysis. That gives attackers more opportunities to search for a useful weakness within the time and resources available during the attack window.

Quarkslab’s exploratory research illustrates agents switching techniques when they encounter obstacles. It also concludes that obfuscation still increases attacker cost. The research does not establish a universal reduction in attack time or show that AI defeats every protection.

Application owners should therefore reassess protections whose effectiveness depends heavily on making investigation slow. Where work can be automated and repeated, previous assumptions about the effort required may no longer hold.

An attacker does not need to understand everything

Consider an application that decrypts sensitive information during execution. An attacker able to observe the relevant process may seek the plaintext at that moment. Reconstructing the entire application could be unnecessary.

An attacker interested in one credential or privileged operation can focus on the narrow path that exposes it. The complexity of the surrounding code offers limited reassurance if that path remains accessible, as AI assisted attacks are exceptionally efficient in targeting specific context.

In Cryptomathic's own assessments of Android and iOS test packages using GPT6 / Astra, agents recovered protected configuration and embedded key material, along with some protected bytecode being reconstructed. Nonetheless, the assessment did not result in false user acceptance, successful token replay or device impersonation. These findings show why extracting material and exploiting a service must be evaluated separately.

Our article, mobile app security in the age of agentic reverse engineering, describes the test conditions, separate secure-storage findings and their limitations.

Increase effort, reduce exposure, constrain misuse

Three priorities should guide the response to an attack.

1. Make analysis, extraction and tampering harder. Retain appropriate obfuscation and anti-tampering, supported by runtime protection that detects relevant interference. Test the combination against realistic attack paths, including attempts to observe execution and bypass local checks. Assess what an attacker achieves after defeating an individual protection.
2. Remove unnecessary sensitive material. Review what the app needs to contain, store and process. Avoid packaging long-lived shared secrets with everything needed to recover them. Delivering material after authentication can reduce exposure in the package, but plaintext consumed by a compromised process may still be observable. Appropriate storage protection and controls over use remain necessary.
3. Limit what exposed credentials can enable. Restrict where credentials work, how long they remain valid and which operations they permit. Use suitable device binding and revocation mechanisms where appropriate. Keep sensitive authorisation decisions under backend control. Recovering configuration should not, by itself, enable customer impersonation or payment approval.

Together, these measures increase the work required and reduce the usefulness of what an attacker obtains. They can make opportunistic abuse less attractive, while providing further barriers when a determined attacker persists.

MASC contributes to this approach by combining runtime protection and protected storage with backend verification, alongside the customer’s identity, transaction authorisation and fraud controls.

What could an attacker actually walk away with?

Use four questions to assess your application:

• What sensitive information or credentials can an attacker obtain?
• What access and effort would that require?
• Can the result be reused across devices, accounts or application releases?
• What still prevents data access or an unauthorised transaction?

Obfuscation has value, but its presence alone tells you too little about the protection of your data and services.

Assess your protection against a concrete outcome: how much effort does an attacker need to obtain something valuable, and what can they do with it? Use that answer to decide where protection needs strengthening.

Read Mobile app security in the age of agentic  reverse engineering for the assessment findings and recommendations for a layered protection strategy.