Mobile App Security In The Age Of Agentic Reverse Engineering

What happens when you combine frontier AI Models with human reverse engineering expert?

Mobile application security must remain effective even when an expert human and Agentic AI joins forces. This change in the threat landscape requires multiple lines of defence, each protecting a different boundary and limiting the consequences of adjacent failures.

The central question is therefore not whether AI can reverse-engineer a mobile application, but which security decisions remain trustworthy after it does. For engineering and risk leaders, this shifts the objective from making analysis impossible to limiting what a compromised app can reveal, authorise or influence.

Until recently, reverse engineering was a human-centric task where tools were leveraged to understand the code semantics, create hypothesis and test different attacks scenarios. The cost of doing so was quite high – multiple human days and often hundreds of hours of instrumentation attempts and probing. This has changed drastically with modern and quite capable AI Models.

Modern AI models can reduce the cost of operating an instrumentation lab by automating parts of a familiar reverse-engineering workflow: selecting tools, inspecting binaries, emulating routines, testing hypotheses and producing reusable analysis scripts. In this article, “agentic AI” means a system that can plan and execute several of these steps with limited human intervention, while a human expert supplies objectives, context and validation. The security concern is not that the workflow is new, but that it can be repeated faster and more persistently, lowering the expertise and time required to explore a mobile application.

This risk multiplies when you combine the Agentic Reverse Engineering with the expertise of a sophisticated attacker with precise knowledge of mobile security, this results in much higher strategic risk for an application.

A recent article from Quarkslab on this topic has gotten some traction in the mobile security ecosystem. Quarkslab’s exploratory research illustrates agents switching from static analysis to execution and emulation when the obfuscated code becomes difficult to interpret.

This is evidence of an emerging capability, but does it defeat commercial protections available today?

At Cryptomathic, we conducted penetration testing on Android and iOS test applications using GPT6-Astra. Within that test scope, two findings stood out; they should be read as evidence of emerging capability rather than as proof that every implementation or commercial protection will fail.

In this article we share details on what we found, how Cryptomathic MASC helps, and a detailed list of 7 expert recommendations ready to share with your team.

What we found

The AI Agent was able to recover protected configuration and embedded key material, and decrypted bundled files from the apps, which was previously never achieved through extensive state of the art manual and automated penetration tests.

Protected Android bytecode was also reconstructed by analyzing DEX/Smali code.

This research highlighted 6 important aspects for us as a Mobile Application Security provider, like a deck of cards, few protections mechanisms are prone to fall, but a couple mechanisms withstood the challenge:

Levelling up for the Agentic Reverse Engineering Era

Cryptomathic Mobile Application Security Core (MASC) combines protection against static and dynamic instrumentation with frameworks for securing sensitive data, network protocols, cryptographic operations and application and device health signals. Its relevance to agentic reverse engineering lies in how these controls divide responsibility between the app and the backend: app-side measures raise the cost of analysis and detect hostile conditions, while backend policy determines whether observed evidence is sufficient to permit access or authorise an operation.

At Cryptomathic, our experts have continuously been evolving the security design of MASC, and we continue this path. As we have demonstrated in this article, obfuscation and encryption of app resources are now to be treated as a baseline, but they no longer constitute a substantial defence against Agentic Reverse Engineering:

Obfuscation and DEX encryption: These controls should be treated as cost-raising measures rather than durable trust boundaries. Their value is to increase the time, computation and analyst effort required to understand the application, buying time for detection and response; they should not be relied upon to protect sensitive configuration or to authorise high-value operations.

• App Shielding: Protecting the app’s static environment against repackaging attacks remains essential to ensure that the app is official and authentic.

Establishing trust in the app’s runtime environment is key and is one of the hallmarks of MASC. MASC’s runtime sentinels detect conditions such as instrumentation, tampering, rooting and compromised device environments. This addresses the execution and observation techniques an agent may use to work around the app’s defences.

Cryptomathic continues to evolve techniques to raise the cost of Agentic Reverse Engineering, and some of the techniques thar are being explored include:

• Context bombs and honeytokens: Overwhelm automated analysis and use decoys to detect misuse.
• “Plausible” result loops: Distract analysis with convincing but unhelpful results.
• Method poisoning: Introduce misleading method logic to complicate reverse engineering.

What really sets MASC apart is the runtime protection, where Cryptomathic’s 40 years of experience with applied cryptography starts to show:

Challenge-response protocol: MASC Assurance verifies challenge-response evidence and supplies decisions the application backend can enforce. Circumventing checks in the app therefore need not unlock the service: server verification and authorization remain additional barriers.

Post-Quantum Device Binding and Transaction Signing: The Assurance Server’s device binding adds an instance-specific verification requirement, while supported authentication and signing flows use platform-protected asymmetric keys. Together, these controls can make recovered code or configuration insufficient to clone an enrolled identity or authorise an operation. However, hardware-backed key protection does not by itself control how a compromised application uses the key; sensitive operations must also be bound to verified transaction context and enforced by the backend.

Reaction Engine: MASC Assurance Reaction Engine turns device health signals into configurable responses against active threats. Teams can adjust server-side reaction policies as attack patterns change and combine the results with their fraud controls.

Examples of further runtime protection features being explored include:

• Anti-CPU emulation techniques: Detect emulated execution environments to hinder automated analysis
• Authentication: Verify identity before granting access to protected resources.
• Use of PIN/Biometric Secure Storage: This introduces a requirement beyond possession of the app package. Biometric-protected storage resisted the tested attempts on both rooted and non-rooted devices.
• Server-side configuration: Keep sensitive settings on the server, outside app control.
• Zero-knowledge proofs: Prove a claim without revealing the underlying secret.

Get in touch with Cryptomathic’s MASC team to know more about how these measures help protect against the modern AI threats. While Cryptomathic has spent a lot of time in researching and developing a defence strategy on AI threats for its MASC product line, below are some special recommendations that we give to banks, financial institutions, payment providers and any other application provider that is handling sensitive information:.

AI-Threat Defence Recommendations

Whilst no longer sufficient, we would advise retaining appropriate obfuscation and anti-tampering as initial barrier because the goal is to utilize as much tokens as possible for the AI to be successful. On top of this, add runtime application self-protection (RASP) to detect debugging, instrumentation and hostile environments. Our assessment specifically recommends not relying on obfuscating sensitive configuration details, but this does not mean abandoning all hardening.

2) Re-think what defence in depth means for your application

Multiple protections inside the same process may share failure modes. Clients should ask what still prevents fraud or data access after code is understood, a local check is bypassed, or an app-held secret is exposed, but keeping important functionality behind authentication protocols can withstand instrumentation attempts. Our research highlighted this point: if a packaged content is extracted, does it mean defeat of complete security architecture? Not really!

Effective defence in depth connects app protection with secure hardware, user authorisation and server-side enforcement. Secure coding, patching and robust user authentication remain the foundation of secure app coding. The objective is to prevent a local compromise from authorising a sensitive business operation.

3) Make the backend enforce access decisions

An app warning or local shutdown is not sufficient if an attacker can still invoke the service directly or if an AI agent can map a path of execution that purposefully does not create tripwires when faced with runtime detections. Require the backend to verify the relevant application and device evidence before permitting sensitive operations, alongside user authentication and server-side authorisation. Bind evidence to the appropriate request or session and enforce freshness.

4) Keep authority and long-lived secrets off the app

Do not ship a long-lived shared secret with everything needed to recover it. Keep authoritative credentials and sensitive decisions on the server wherever practical. Where the app needs configuration or temporary credentials, release only the minimum after suitable authentication and validation, with limited scope and lifetime and a revocation path. Bootstrap trust must not depend solely on another reusable secret in the package. Server delivery reduces exposure at rest in the package; it cannot make plaintext invisible to a compromised process that must consume it.

5) Protect keys and control what they can authorise

Generate device-specific keys inside platform secure hardware and verify the level of protection available on the device. Hardware isolation can prevent key extraction, but it may not stop a compromised application from requesting a legitimate cryptographic operation. The threat model should therefore include environments that simulate or misrepresent trusted execution capabilities (for example using TEESimulators) and could produce key material that the application mistakes for hardware-generated material; enrolment and backend verification must validate the provenance and permitted use of each key.

For payments and other high-value actions, you shall consider binding the App/server authorisation to the actual business operation, including details on the beneficiary, transaction amount or details and fresh transaction context. DPoP (RFC 9449) can be instrumental to enforce effective proof of possession of a genuine and duly enrolled device. The backend must also verify that the authorised data matches the operation it executes.

6) Operate the controls as a living system: Mobile Security and Fraud as one connected line of defence

For prevention of runtime related fraud led by an expert attacker using Agentic AI, it is vital than ever to correlate signals of compromise from the device, OS, trust environment, application, user and its behavior. Correlating all of these signals with account and transaction behaviour can provide a full picture of an attack chain being performed. The security backend should feed these into the fraud decisioning engine, enriching real-time transaction risk scoring with customer behaviour, payment history, transaction velocity and beneficiary risk. Connecting mobile threat intelligence with fraud analytics therefore strengthens protection across the entire customer journey.

7) Conduct your own penetration tests using the frontier AI models 

Traditional penetration testing mechanisms and methodologies lack the scale and speed that AI can provide. There are two things that still make traditional penetration tests useful: 1. Scope and Context 2. External validation factor.

The future of penetration testing will combine experts who understand system context and scope with the scale and speed of AI. Independent validation may also evolve towards certifying bodies that provide evidence for legal and compliance purposes. For staff engineers, the immediate task is to redesign trust boundaries and test failure paths; for product owners, it is to prioritise server-enforced controls and recovery capabilities; for information security professionals, it is to connect mobile telemetry with detection and response; and for risk managers, it is to assess the business operations that remain exposed after app compromise. Traditional penetration testing is being challenged, and organisations should adapt their mobile security programmes accordingly.

Sources and evidence:

[1] Quarkslab - Defeating AI-Assisted Reverse Engineering, 20 August 2026

[2] Android Developers - Android Keystore system, Security features