A mobile app has to tell the server what it wants to do. Its code, requests and responses expose enough information for someone to build a different client. AI assistants can help interpret that information and write the replacement. The security question is what the server lets that client do.
Recent decompilation projects show substantial progress, with important limits. For companies shipping apps, the practical consequence is to test API permissions and business rules assuming someone already understands the client.
From a mobile app to an automated client
Consider an illustrative example. A commuter wants a simpler way to book a bus. An assistant helps inspect the app’s network requests and build a bot that checks schedules and reserves a seat using the commuter’s account. This is a hypothetical scenario, not a verified incident.
For the operator, using a different interface is not by itself a security failure. The questions are whether the bot can book only for its owner, whether the server checks the voucher balance and whether repeated reservations can exhaust the available seats.
A valid session answers who is signed in. Each operation still needs its own authorization decision. An endpoint omitted from the public documentation remains reachable if a caller discovers its address.
A different client. The same API.
Understanding the app lets someone rebuild the interface. The server still has to decide what each request may do.
The app reveals the route
Request formats, endpoint addresses and client-side checks can be studied.
AI helps connect the pieces
An assistant explains the calls and helps write an alternative client.
The official app is optional
The bot calls the backend directly using the permissions of its token.
A valid session is not permission.
The request: account A tries to cancel account B’s booking.
“The user is logged in.”
The server accepts a valid session without verifying who owns the booking.
“This booking is not yours.”
The server checks the caller against the booking owner before changing it.
What the decompilation projects actually show
In November 2025, developer Chris Lewis described a workflow for Snowboard Kids 2 that gave Claude individual functions to reconstruct and checked the compiled result against the original. He reported more progress in three weeks than in the preceding three months. Some runs lasted more than eight hours without supervision. He also described wasted quota, difficult functions and the tools and community work that made the process possible. This was a measured improvement within an existing project, not a whole game recovered from scratch in an afternoon. [1]
In October 2026, Maurice Heumann published an account of reconstructing Call of Duty: Modern Warfare 2. Early agent output looked readable but contained incorrect types and invented logic. Progress became more reliable after the team introduced automated comparisons with the original binary. He reported that 99% of functions were present and 83% matched exactly, after roughly three months. His token estimate was 600 to 700 billion, with some logs lost. That is evidence of substantial automation and substantial cost. [2]
The useful lesson is the feedback loop. A model proposes code, a tool checks it and the next attempt uses the result. The quality of that check matters as much as the volume of generated code. These accounts do not establish a universal speedup for reverse engineering or show that every protected application can be reconstructed cheaply.
An API offers a different kind of feedback through responses and observable state changes. A successful request may confirm how an operation works. It does not establish that the caller was entitled to perform it. Testing must check the resulting records and access boundaries, including when a response looks successful.
What someone can learn from the client
Android tools such as JADX can recover Java-like code and resources from app packages. Its maintainers explicitly warn that decompilation is not always complete or correct. The JADX AI MCP integration gives an assistant access to analysis tools, reducing the manual work of moving between code and questions. Neither tool guarantees a correct understanding of an application. [3] [4]
Web applications already deliver JavaScript to the browser. Mobile applications contain request formats, service addresses and client logic. A person inspecting their own device can also study what the app sends and receives, subject to the protections in place.
For a product team, the first review should identify what the distributed build reveals: active and retired endpoints, embedded credentials, administrative functions and fields that influence prices, roles or ownership. Treat the output from a model as leads to verify. An API address, schema or public project identifier is not automatically a vulnerability.
Keep client defenses in their proper role
OWASP includes resistance to reverse engineering in its mobile security standard. Obfuscation and tamper resistance can raise the effort required to analyze an app. Their effectiveness depends on the implementation and the attacker’s capabilities. They should support server controls, not carry decisions about access to other people’s data. [5]
- Obfuscation and certificate pinning
- They can complicate analysis and interception. Do not assume they make a client unmodifiable or prove that a request came from your approved interface.
- A shared signing secret inside the app
- If extracted, it can be reused outside the app. Distinguish it from a device-bound private key protected by hardware and verified through a properly designed protocol.
- Device integrity checks
- Use attestation and tamper signals in a defined risk policy. Check them on the server and test missing, expired and replayed evidence.
- Random record identifiers
- They make guessing harder. The server must still check whether the caller may access the referenced record. A leaked identifier must not grant access.
A practical review asks what happens after one of these protections is bypassed. The answer should point to an independent control over the affected action, with a test showing that it holds.
The Subaru case: the app was not the weakest route
Sam Curry and Shubham Shah’s January 2025 writeup describes vulnerabilities in a Subaru STARLINK administrative portal that exposed customer information, vehicle location history and remote vehicle commands. They reported the issue in November 2024 and said Subaru patched it within 24 hours. [6]
One detail matters for this discussion. Curry first tested the mobile app’s vehicle commands and found that authorization held. The researchers then examined employee-facing infrastructure, where the more consequential weaknesses were located.
This was not presented as an AI-driven intrusion. It demonstrates why a mobile assessment should follow the service beyond the app. An administrative portal, support tool or legacy API can reach the same sensitive records through a different permission model.
What building Brelo taught me about client trust
During seven years building a business in Brazil, I cofounded Brelo and led the development of technology that allowed mobile phones to serve as collateral for credit. Device locking put part of the product’s enforcement on hardware in someone else’s hands. Attempts to bypass that enforcement were a recurring engineering problem.
That experience shaped how I review applications today. I start by separating what the device can report from what the service must decide. A client can report its state or ask for an operation. The server needs enough independent information to decide whether the operation is valid.
For an API, a useful design target is that extracting the complete client should not increase a caller’s server-side privileges. The implementation may be visible. Ownership checks, balances and approval requirements still have to hold. This is a lesson from my work at Brelo, rather than a result measured in the decompilation projects above.
For startups: five checks to run this week
Choose one valuable workflow, such as a booking, payment or account change. Work in an authorized test environment with fictitious data. Give each check an owner and record the expected result, observed result and any follow-up.
Inspect what you shipped
Review the current app package or browser bundle. List endpoints and embedded keys, then establish what each key can actually access. Revoke or rotate exposed secrets and remove the dependency on them. Restrict intentionally public keys to their intended APIs and uses.
Evidence: a reviewed inventory, verified key restrictions and an owner for every reachable service.
Test with two accounts
Create records under account A and account B. Verify that A cannot read or modify B’s records through the API, including export and delete operations. Repeat across tenants if your product serves organizations. OWASP identifies this failure as broken object level authorization. [7]
Evidence: denied cross-account requests and confirmation that the target records stayed unchanged.
Make the server enforce the limit
Use a test voucher or balance. Attempt a duplicate submission, a changed amount and concurrent requests within the agreed scope. Verify that retries do not create extra transactions and that insufficient balances are rejected even without the official app.
Evidence: the final ledger or inventory state, together with the decisions for each request.
Limit the business action
Define acceptable booking, redemption or lookup activity. Test limits per relevant account, tenant or resource, not just per IP address. Decide what should happen when an otherwise authenticated caller holds scarce inventory without completing a purchase. OWASP treats abuse of sensitive business flows as a distinct API risk. [8]
Evidence: the agreed threshold, the resulting block or review action and a check that normal use still works.
Retire the routes nobody owns
Compare the routes in distributed builds with the deployed API inventory. Include older versions, debug services and administration tools. Remove unused access after checking dependencies. Review private storage separately for ownership and retention rules. Published documentation does not replace those checks. [9]
Evidence: an owner and access policy for each retained route, plus an external check that retired routes are unavailable.
If time is limited, start with sensitive data exposed without authorization, reusable secrets and operations that move money or change account access. A new obfuscation layer will not correct those server-side failures.
For enterprises: follow the same record across systems
A customer record may be reachable from the mobile app, a support console, a partner integration and a batch export service. Assign one exercise owner to follow that record across all four routes. Ask each system owner to show the effective permissions, including service accounts and emergency access.
- Test the complete transaction. Verify who can create, approve, change and submit it. Recheck approval if the amount or recipient changes.
- Include alternative routes. Test the customer API alongside support and administrative interfaces. Use accounts with different roles and confirm that tenant boundaries hold on each route.
- Measure response. Generate agreed test activity, locate the audit events and have the responsible team revoke access. Verify that existing sessions and delegated credentials stop working as intended.
- Keep the checks in delivery. Add meaningful authorization and transaction tests to the release process. Repeat them when permissions, identity providers or API versions change.
The output should be a short list of access paths, verified failures and decisions. Attach evidence to each finding and identify the team that can fix it. A list of discoverable endpoints alone does not establish business impact.
When an AI agent holds a real user token
Return to the booking example. The agent may need to read schedules and create one reservation. A copied user session might also allow cancellation, profile changes or access to payment information. Those extra permissions remain available even when the task does not require them.
Where automation is supported, provide scoped credentials, bounded lifetimes and a clear revocation mechanism. Require approval for consequential operations and bind that approval to the actual transaction. A malicious instruction in a page or document should not be able to expand the agent’s authority.
The same applies to internal company assistants. Document which systems they can reach, who owns the integration and what evidence each action produces. Oktsec’s AI governance work addresses these decisions. Its Control enforcement applies to configured traffic routed through it; API authorization must also hold when a caller reaches the backend through another permitted route.
For mobile, web and API reviews, Oktsec pentesting can assess the client, server permissions and business logic together. Bring one application and the operations that matter most. The assessment should establish what an alternative client can actually do and which controls prevent it.
Sources and scope
- Chris Lewis, The Unexpected Effectiveness of One-Shot Decompilation with Claude, November 27, 2025.
- Maurice Heumann, Game decompilation project report, October 9, 2026.
- JADX maintainers, project documentation and decompilation limitations.
- JADX AI MCP, user guide.
- OWASP MASVS, resilience against reverse engineering.
- Sam Curry and Shubham Shah, Hacking Subaru: Tracking and Controlling Cars via the STARLINK Admin Panel, January 23, 2025.
- OWASP API Security Top 10, API1:2023 Broken Object Level Authorization.
- OWASP API Security Top 10, API6:2023 Unrestricted Access to Sensitive Business Flows.
- OWASP API Security Top 10, API9:2023 Improper Inventory Management.
Published October 14, 2026. Project results are attributed to their authors and were not independently reproduced by Oktsec. The booking scenario is illustrative. The Brelo account is the author’s experience; the review exercises are Oktsec’s recommendations based on the access risks discussed here.