Almost three years ago, we published an article about AI and social engineering.
At the time, we discussed how AI could help attackers create convincing messages, impersonate trusted people, automate OSINT and build synthetic identities. We were already well on the way toward a world in which it would become increasingly difficult to distinguish a genuine person, company or communication from a bogus one.
Still, what looked sophisticated in 2023 has now become routine.
Modern AI tools can write convincing messages in any language, reproduce a person’s communication style, generate voices and images, analyze large volumes of information, and operate software tools with increasingly limited human supervision. The attacker no longer needs a separate specialist for every stage of an operation. An AI agent can help with reconnaissance, code analysis, scripting, infrastructure configuration and the interpretation of results.
Put another way, the implications for mobile security go beyond AI being able to produce more convincing phishing emails.
AI can help an attacker to analyze your mobile application, understand how it communicates with your backend, and identify where trust can be manipulated across the entire mobile channel.
Your application code is not the only thing under attack; it’s just one wall under strain within a growing room where the target is trust itself, and the relationship between the user, device, application and backend.
In the following paragraphs we’ll explain how we believe security can best be implemented for the whole mobile channel in what’s already being referred to as the post-AI era.
Mobile threats in the post-AI era
Post-AI doesn’t necessarily mean the world that comes after artificial intelligence, but rather the period after AI has stopped being a novelty.
And it seems we’re already there, because AI has become a standard engineering tool already. Developers use it to generate code, write tests, review pull requests, explain unfamiliar frameworks and configure infrastructure. Security teams use it to analyze logs, investigate incidents, identify vulnerabilities and process threat intelligence.
What’s sometimes overlooked, however, is that attackers can use exactly the same capabilities to increase their own efficiency.
So, returning to the title of this piece, is AI an angel or a demon? The truth is the underlying technology is neither good nor evil. Its impact depends on who operates it, what information it receives, which tools it can access and what objectives it is given.
For a security engineer, AI can identify a dangerous API, explain a memory-safety problem or help to produce a more complete protection configuration.
For an attacker, the same model can examine decompiled application code, identify security-critical functions, generate instrumentation scripts and explain how the application constructs authenticated backend requests.
Government cybersecurity guidance now recognizes that frontier AI models can help discover software vulnerabilities and allow malicious actors to operate at greater speed and scale. At the same time, defenders can use the same capabilities to strengthen code and improve vulnerability management.
Can modern AI really reverse engineer a mobile application?
Partially, and the nuance matters. Modern AI can meaningfully accelerate reverse engineering by explaining decompiled code, identifying cryptographic, networking, and authentication logic, and generating scripts for tools like Ghidra and IDA. What it cannot do is take a well-protected APK, AAB, IPA, or XCArchive and automatically return the source code, cryptographic keys, and a working backend exploit. AI doesn't replace a skilled reverse engineer; rather it multiplies one, chiefly by generating and testing hypotheses far faster than a person working alone ever could.
An AI model is not a magic button that accepts any heavily protected APK, AAB, IPA or XCArchive and immediately returns the complete source code, cryptographic keys and a working backend exploit.
Reverse engineering remains a difficult undertaking. Mobile applications combine multiple languages, optimization stages and runtime environments. A single application may contain Kotlin, Java, Swift, Objective-C, C++, Rust, JavaScript, Dart, native libraries and third-party frameworks. Important behavior may only become visible at runtime. Code may depend on remote configuration, device state, backend responses and hardware-backed operations.
Obfuscation, code encryption, control-flow transformation, anti-debugging, integrity verification and runtime protections make this work significantly harder.
But an attacker doesn’t need AI to understand every instruction perfectly. They simply need it to reduce the cost of reaching the next useful result.
Recent research has moved beyond asking whether an LLM can explain a short piece of decompiled code. New benchmarks now evaluate whether tool-enabled agents can analyze binaries, recover validation logic and solve purpose-built reverse-engineering tasks. The results show that modern agents can already complete a meaningful proportion of these tasks when they are connected to standard analysis tools.
AI can therefore accelerate the repetitive and time-consuming parts of reverse engineering in the following ways:
- classifying functions and code regions;
- explaining decompiled or disassembled code;
- identifying cryptographic, networking and authentication logic;
- tracing relationships between classes, methods and native functions;
- generating scripts for tools such as Ghidra, IDA or dynamic instrumentation frameworks;
- comparing different application releases;
- identifying API endpoints and request formats;
- locating integrity checks and anti-analysis mechanisms;
- creating hypotheses and automatically testing them;
- summarizing thousands of lines of analysis into a practical attack plan.
Does AI always produce a correct answer? No, it doesn’t.
What it does do is generate and test hypotheses much faster than a human working alone ever could. And so a skilled reverse engineer is not replaced by AI. Rather their potential is multiplied by it.
Why you can’t rely on model safeguards
The major hosted AI providers are well aware of the potential for misuse. They apply usage policies, model-level safeguards, access controls and monitoring intended to prevent their systems from assisting with clearly malicious activity.
These controls are important, but they cannot be treated as part of your application’s security model.
Firstly, model behavior is not perfectly predictable. The distinction between legitimate security research and malicious reverse engineering can be difficult to determine from a prompt alone.
Secondly, attackers can divide an operation into many apparently innocent tasks. Asking a model to explain an assembly function, describe a cryptographic construction or produce a debugging script may each have legitimate purposes. The malicious objective only becomes visible when the outputs are combined.
Thirdly, not every capable model is accessible exclusively through a controlled cloud service.
Open-weight models can be downloaded and operated locally. For example, the official GLM-5.2 model release describes an MIT-licensed model that can be deployed locally using common inference frameworks. Once model weights are running in infrastructure controlled by the operator, there is no hosted provider sitting between the user and the model to perform real-time policy enforcement.
That’s not to say that this type of AI model is bad. Indeed, these models are extremely important for research, independence, privacy and technological progress.
It simply means that one cannot rely on the AI provider to spot and rebuff an attack. It isn’t a reliable security control.
It’s a better bet to assume in your risk model that a capable attacker will be able to access an AI model that will analyze the material they provide.
A modern AI-assisted attack begins with your application code
Most sophisticated mobile attacks still begin in a familiar place: the application package.
The attacker downloads an Android APK or extracts it from an installed device. On iOS, they may obtain a decrypted IPA from a compromised environment. They can also target an SDK, framework or library distributed to your customers.
The first objective is usually not to exploit the backend immediately. It is to understand how the application expects a legitimate user and device to behave.
An AI-assisted analysis may look for:
- authentication and enrollment flows;
- API endpoints and undocumented operations;
- request-signing algorithms;
- embedded certificates, public keys and secrets;
- device and installation identifiers;
- anti-fraud signals;
- root, jailbreak, emulator and hooking checks;
- integrity-verification logic;
- native security components and JNI boundaries;
- feature flags and remote configuration;
- transaction limits and business rules;
- third-party SDKs that handle identity, payments or cryptography.
- From there, static analysis becomes dynamic analysis.
The attacker can run the application in a controlled environment, attach instrumentation, intercept functions, modify return values and observe sensitive data while it is being processed. AI can help generate scripts, interpret traces, correlate runtime behavior with decompiled code, and adjust the next experiment.
Eventually, the attacker may no longer need to interact with the original user interface at all.
Once the application’s protocol, signing process and trust signals are sufficiently understood, the attacker can attempt to reproduce or manipulate its communication with the backend. Requests may contain valid credentials and use the correct structure. From the server’s perspective, they can look like requests from a genuine application.
This is how an attack that starts with application code analysis can expand into the compromise of the complete mobile channel.
The backend itself may never be directly exploited. Instead, it is likely to be persuaded to trust a client that is no longer trustworthy.
The curious case of context bombs
The security community has already started developing creative ways to defend against autonomous AI attackers. One particularly interesting - and slightly amusing - example is the concept of a context bomb.
The idea is to place carefully designed content inside a decoy resource, such as a canary secret. When an attacking AI agent discovers and reads the resource, the content interferes with the agent’s reasoning or triggers its safety mechanisms. At the same time, the defender receives an alert that the decoy has been accessed.
In simple terms, the attacker’s AI opens what appears to be a valuable secret and suddenly decides that it should stop what it is doing.
There is something wonderfully ironic about protecting infrastructure by making the attacker’s AI experience an ethical crisis.
Tracebit tested this technique against several agentic models in a controlled cloud environment. According to its published results, adding a single context bomb to a canary secret substantially reduced the agents’ ability to complete attack paths.
The researchers also found that different models reacted to different sensitive subjects. Content that stopped some Western models was less effective against other models, while different material affected models operated by Chinese providers.
The project has published examples through its context-bombs GitHub repository.
It’s an intelligent experiment and a good example of turning an AI system’s own behavior against it. But we shouldn’t confuse an inventive defensive technique with a durable security boundary.
A context bomb only works when the agent encounters it. It may depend on the model, system prompt, safety policy and provider. An attacker can pre-process or filter retrieved content. A locally modified model may react differently. And a human attacker may simply ignore it.
Most importantly, a context bomb doesn’t prevent your application from being decompiled, modified, instrumented or impersonated.
It’s a tripwire, a distraction, and a potential agent-disruption mechanism. It isn’t application integrity.
So what is the answer?
Classical mobile app protection matters more, not less
While it might be tempting to assume that traditional application protection becomes irrelevant when attackers have AI, the opposite is actually true.
AI works best when it has clean, structured and meaningful context. Readable class names, recognizable control flow, obvious API clients and unprotected string constants give the model high-quality material to analyze.
A weakly protected application effectively prepares its own documentation for the attacker.
This is why Android and iOS obfuscation remains a foundational security control.
However, renaming classes and methods alone is not sufficient. Modern application protection needs to combine multiple mechanisms:
- code and symbol obfuscation;
- string and resource encryption;
- code encryption and runtime restoration;
- control-flow transformations;
- native-code protection;
- application and component integrity verification;
- anti-tampering and anti-repackaging controls;
- protection of embedded databases, AI models and sensitive assets;
- runtime checks and enforcement;
- hardened network communication.
The objective is not to make reverse engineering mathematically impossible. No client-side protection can make that guarantee on a device controlled by an attacker.
Rather the objective is to remove useful context, increase uncertainty, prevent automated analysis from producing reliable results and make every stage of the attack more expensive for a bad actor - even with the help of AI.
The stronger the protection, the more likely an AI model is to produce a confident but incorrect interpretation.
For once, an AI hallucination can work in the defender’s favor.
Why static protection alone is not enough
An application does not remain encrypted and obfuscated while it performs every operation. At some point, instructions must execute and data must be processed.
This is why application protection must extend into the runtime environment. A serious Runtime Application Self-Protection (RASP) layer should detect and respond to:
- debuggers;
- hooking and instrumentation frameworks;
- code injection;
- rooted or jailbroken devices;
- emulators and virtualized environments;
- modified operating-system components;
- malicious applications;
- overlays and remote-access tools;
- integrity violations;
- unexpected changes to executable memory;
- other conditions indicating that execution can no longer be trusted.
Detection without enforcement is not enough.
Depending on the risk and business process, the application should be able to terminate, restrict sensitive functionality, invalidate a session, require additional verification, or report a tamper-protected security signal to the backend.
That’s why our own mobile application protection solution, DexProtector, combines static code and resource hardening, application integrity, runtime protection and communication hardening for Android and iOS applications and SDKs.
But even strong protection inside the application is only one part of the answer.
You need to protect the whole mobile channel
An AI-assisted attacker will not respect the boundaries between your mobile development team, fraud team, API team and security operations center. And so your protection architecture shouldn’t respect those boundaries either.
Mobile Channel Protection secures the complete interaction between the user, device, application and backend. It requires several layers working together.
1. Protect the application package
Apply protection to the final APK, AAB, IPA or XCArchive that will actually be distributed.
Source-level transformations alone do not see everything that enters the final application. Build tools, generated code, third-party libraries, frameworks, extensions and post-processing stages can all change the final attack surface.
The security boundary must cover the artifact the attacker receives; what we call the final container.
2. Protect the runtime environment
The application should continuously verify that it is running in an environment where its execution, memory and decisions can still be trusted.
A check performed only during startup is not enough for a long-running or transaction-heavy application. Threat conditions can change while the process is active.
3. Bind the application to the backend
The backend should not trust a request simply because it contains a valid access token, device identifier or cryptographic signature.
An attacker may extract a secret, trace the signing operation or invoke the legitimate function from inside a compromised process.
Mobile API Protection allows the backend to verify that a request originates from a legitimate and untampered application instance before processing a sensitive operation.
This creates a connection between client-side integrity and server-side enforcement.
4. Generate trusted security intelligence
A binary allow-or-block decision is not appropriate for every risk signal.
A rooted device, emulator, injected library, accessibility-based malware or anomalous installation history may each require a different response. The correct decision may also depend on the user, transaction value and previous behavior.
That’s why our threat intelligence and telemetry solution, Alice Threat Intelligence, converts authenticated and tamper-proof signals from the application into intelligence that security and fraud teams can use in real time.
This allows an organization to move from trusting isolated client claims toward cross-validating application integrity, runtime state, device identity and behavioral history.
5. Isolate the most sensitive operations
Some operations are too sensitive to leave within the ordinary application execution environment.
That's why our virtual Trusted Execution Environment, the Licel vTEE, isolates key handling, request signing and other security-critical logic from the surrounding application; providing hardware-level trust even where a device's hardware TEE is fragmented, restricted or unavailable.
A complete mobile channel strategy identifies which operations need this stronger boundary rather than treating every function as equally sensitive.
Don’t forget the SDK
The same security principles apply to mobile SDKs, but the trust model is even more difficult.
An SDK is distributed into an application controlled by another organization. It may execute inside a hostile or poorly protected host application. Its public interfaces, internal logic and resources can be analyzed independently. Attackers can build a dedicated harness application around it, invoke exported functionality directly and manipulate the environment in ways that may not be possible in the intended application.
An SDK therefore cannot depend entirely on the host application to protect it.
It needs its own protection for:
- code and resources;
- embedded databases and AI models;
- native libraries;
- integrity;
- runtime checks;
- secrets and cryptographic operations;
- communication with backend services
We explore this threat model in more detail in our Knowledge Hub guide about protecting Android and iOS SDKs.
AI can help the defender too (with the right context)
None of this means AI belongs solely in the attacker's hands. A model can also examine an application's architecture, suggest protection mechanisms, and explain configuration options to developers who are meeting them for the first time.
But the quality of its output depends entirely on the context it receives. We see a lot of configuration files that look technically complete but are wrong for the application they’re meant to protect. That’s because the model didn't know which classes are loaded dynamically, which native library resolves a method by its original name, or which operation has a strict latency requirement. Without that context, it fills the gaps confidently rather than correctly.
We'll look at some common configuration failures – and how to reverse them – in more detail in an upcoming article.
Finding the right security balance in the post-AI era
It’s clear that we can and should use AI to improve mobile security.
We should use it to review code, draft and sanity-check protection configurations, generate negative test cases, investigate incidents, and process security intelligence at a scale that would be impossible for a human team alone.
But we must also build our applications on the assumption that attackers have access to the same capabilities.
They will use AI to understand code more quickly. They will automate experiments. They will connect static analysis with runtime instrumentation. They will search for the shortest path from an application binary to a trusted backend operation.
The answer is not to prohibit AI or hope that every model provider will stop every malicious request. The answer is to reduce the quality of the attacker’s context, protect application execution, verify integrity at the backend and continuously validate signals across the complete mobile channel.
The angel and the demon are both using the same technology. Security effectiveness will increasingly depend on which side has the better architecture.
Find out more about why it’s so important to protect the whole mobile channel:
Frequently asked questions
Can AI reverse engineer an Android or iOS application?
AI can assist with reverse engineering by explaining decompiled code, identifying security-critical logic, generating analysis scripts and operating external tools. It does not automatically recover every protected application, but it can significantly reduce the time and specialist effort required for many analysis tasks.
Is mobile app obfuscation enough to defend against AI-assisted attacks?
No. Obfuscation is an essential foundation, but it should be combined with code and resource encryption, application integrity, runtime protection, communication hardening, backend app verification, and threat intelligence based on trusted signals.
Can AI break code obfuscation?
Not on its own. AI can help an attacker interpret obfuscated code by classifying functions, explaining decompiled logic, and generating analysis scripts, which lowers the effort required, but it doesn’t automatically undo strong protection. Obfuscation combined with code encryption, control-flow transformation, integrity verification, and runtime protection removes the clean context AI relies on, making automated analysis slower, more expensive, and more likely to produce confident but incorrect results.
Can AI generate a mobile app protection configuration?
It can help, but only when it receives version-specific context about the application and the protection tool; dynamic class loading, native method resolution, latency constraints, and framework architecture are all invisible to a model working from generic knowledge. A configuration that looks complete can still be wrong for the application it protects. That’s why a configuration should still be reviewed and tested by engineers who understand the application architecture, compatibility requirements and threat model.
Why does AI make mobile channel protection more important?
AI allows attackers to move more quickly between application analysis, runtime manipulation and backend abuse. Protecting only the application code leaves gaps around device trust, execution integrity, API requests and backend decision-making. Mobile channel protection addresses these layers as one connected security system.
What is a context bomb?
A context bomb is a defensive technique that places specially crafted content inside a decoy resource, such as a canary secret, to disrupt an AI agent that discovers and reads it. It interferes with the agent's reasoning or triggers its safety mechanisms while alerting the defender that the decoy was accessed. It’s a useful tripwire and agent-disruption mechanism, but is not a durable security boundary: it only works when the agent encounters it, its effect varies by model and provider, and it does nothing to stop an application from being decompiled, modified, or impersonated.
