AI-led reverse engineering: What should still protect you after a bypass?

Suppose an attacker understands your mobile app, suppresses a security check and recovers part of its configuration. What can they do next?

The answer reveals how your security architecture limits the consequences of a local compromise. A strong design keeps meaningful barriers in place after an individual control fails, using protections with different dependencies and enforcement points.

AI-assisted analysis makes this discipline more pressing. Agents can automate parts of investigation and produce scripts for repeated testing.

Cryptomathic's own assessments of AI assisted attacks reinforced the importance of evaluating what an attacker can achieve after an individual protection is challenged. This article turns that principle into questions for reviewing your architecture and suppliers.

When the attacker understands the code

Code hardening should increase the effort required to inspect and modify an application. Sensitive operations also need protection that remains effective when its logic is understood.

Review the secrets and authority distributed with the app.

• Avoid packaging a long-lived shared credential with everything needed to recover it.

• Where practical, provide narrowly scoped, temporary credentials after suitable authentication and verification.

• Protect sensitive stored values deliberately, including appropriate PIN or biometric requirements.

• Use platform-protected keys where suitable.

• Verify the protection available on supported devices.

Fetching a secret from a server reduces exposure in the package, but cannot make plaintext invisible to a compromised process that must consume it.

The desired outcome is clear: understanding the application’s logic should not grant access to protected data or authority to perform sensitive operations.

When a local security check is bypassed

A local warning or shutdown can interrupt an attack. The service still needs to enforce access decisions if the attacker suppresses that response or calls an API directly.

Sensitive backend routes should verify user authentication, authorisation and relevant application or device evidence. Evidence needs appropriate freshness and binding to the request or session, with a defined response when it is missing, invalid or stale.

Check the coverage. Protecting the main user flow leaves a gap if recovery or an alternative API permits the same operation with weaker checks. Enrolment also needs scrutiny because it establishes the trust used later.

Bypassing a local check should leave the attacker facing the backend’s authentication, authorisation and verification requirements. Test this by attempting the sensitive operation directly.

When a credential is exposed

The consequences of credential exposure depend on what the credential authorises and how easily it can be reused. A shared credential embedded across an application population can create far wider exposure than a short-lived credential restricted to a single purpose.

Limit each credential’s scope and lifetime, provide a means of revocation and apply suitable binding where appropriate. The backend must enforce these restrictions.

Test what an attacker could do with an exposed credential. Can it be used from another device, against another account or after the original session has ended? Can the operation be repeated at scale?

The objective is to contain the consequences of exposure: restrict what a recovered credential can authorise and define how access will be revoked.

When the attacker operates through a genuine device

Device binding makes it harder to copy an identity to another device, but it does not address every attack conducted through the genuine device.

A cryptographic key may remain protected against extraction even as a compromised application requests operations using it. Controls over how the key is used therefore matter as much as controls over its storage. Appropriate user authentication can restrict sensitive operations, but the entire transaction flow also requires scrutiny.

For a payment, for example, authorisation should cover the intended beneficiary, the amount and fresh transaction context. The backend must verify that the details approved match those it executes. A valid signature alone does not establish informed user intent if malicious software can alter what the user sees or submits.

Test what prevents an unauthorised operation when device identity and cryptographic checks are valid. Key-use restrictions, transaction approval and fraud assessment should address this scenario together.

Choose complementary protections across vendors

For high-value applications, assess how specialist protections can work together across code hardening, runtime security, backend verification and fraud assessment. Solutions from multiple vendors can add value when they introduce distinct barriers or provide complementary evidence.

Examine their shared dependencies and enforcement points. Two SDKs running in the same compromised process may share failure modes, while independently enforced services can present additional barriers. Multiple checks may also rely on the same signal or feed into a local decision that an attacker can suppress. Test how the combined controls behave when one is bypassed.

For each supplier, establish:

• Which attack paths does its protection address?
• Where is the decision enforced?
• Which dependencies does it share with other controls?
• What remains effective if its protection is bypassed?
• How does its evidence reach the systems responsible for access and transactions?

For each sensitive operation, document the controls in place, the evidence they require, where decisions are enforced and which protections remain effective after a bypass. Assign an owner to test the full path.

Assess how the remaining controls perform when an individual protection is defeated. Validate compatibility, performance and response behaviour across the combined implementation, paying particular attention to gaps between suppliers.

Connect detection to enforceable responses

Runtime observations become more useful when they inform decisions about access and transactions.

Evidence of instrumentation could trigger additional verification or restrict a sensitive function, according to the service’s policy. Combined with an unusual beneficiary and abnormal transaction activity, it could also support a payment hold or fraud review.

The backend must validate the evidence and enforce the response. Missing signals and conflicting evidence need defined treatment. The absence of a mobile security alert should not in itself establish that a transaction is safe.

MASC’s runtime sentinels and assurance verification can contribute evidence to this process. The Reaction Engine evaluates device health signals against configured policies, while the customer’s backend enforces access decisions and integrates the outcome with transaction and fraud controls.

Test the combined design and keep it effective

Tests should follow the attack path through to a potential business outcome. After recovering sensitive material or bypassing a check, attempt the next step: accessing data, reusing a credential, impersonating a device or completing an unauthorised operation.

Record the prerequisites and configuration behind each result. Independently validate AI-generated findings, including whether the agent relied on unintended resources or overstated what it achieved.

As attack techniques evolve, assess whether protections continue to impose meaningful effort and whether a successful bypass can be repeated across releases. AI-assisted analysis makes this testing particularly important.

Include operational failures in the assessment. Define which operations remain available when verification fails or is unavailable, and which additional checks apply. Monitor false positives and the effects of response policies.

Repeat relevant assessments after significant releases and changes to protections. For each layer, establish what remains effective if it fails, who enforces the remaining controls and how their effectiveness has been verified.