Slicing Through Bytecode with an AI Agent

Agentic AI has quietly become one of the more useful tools in mobile pentesting. In this post I walk through how I set it up in my home lab, point it at a real Android app, and use it as a second pair of hands while I test manually. The target for this run was the Nextcloud Android app, an open source project with known issues in older releases, which makes it a great practice subject.

Why I Reach for Local Models First

When you run a frontier model from a cloud provider, your data travels to a third party company. For personal projects and learning that tradeoff is fine, and frontier models are also reasonable when the target is open source code that is already public. The story changes on a real client engagement. Pushing client code or findings through a hosted frontier model counts as exfiltrating client data, which lands you in breach of most engagement contracts. That alone makes local models the necessary for professional work, and the whole industry is moving that way, so it is worth getting comfortable with a self-hosted setup early.

A few models I have found worth trying:

• Dolphin3-Cyber-8B, finetuned for cybersecurity tasks and shipped without guardrails.
• Dolphin3.0-Llama3.1–8B-abliterated, another open option for offensive work.
• Qwen2.5-Coder-14B-Instruct, a coding focused model. It uses more resources and keeps light guardrails that clear easily once you frame yourself as a pentester.

If your GPU runs out of VRAM, most local setups will offload to system RAM to keep going. You can also rent cloud GPUs to host these models when your local machine cannot handle them, and over time you can finetune your own models to fit the way you work.

One tip that squeezes more out of your hardware: split the work across two models. Run one model tuned for prose and a second tuned for coding. That division keeps each model in its strength zone and pulls more useful output from a single GPU.

The momentum for local models is real. During incident response on the OpenAI breach, Hugging Face ran into guardrails that blocked legitimate defensive work, and they moved to GLM 5.2 to get the job done.

This is just something worth considering before we move on.

Static Agentic Mobile Pentesting

Setting Up the Target

An APK is essentially an Android zip file, so the first step is simple: download it and unzip it. I grabbed an older Nextcloud version 3.17.0 from APKMirror and extracted it in my lab.

https://www.apkmirror.com/apk/nextcloud/nextcloud/nextcloud-3-17-0-release/

Inside the extracted files, the pieces that matter most are the dex files, which hold the compiled application code. Android apps are usually Java based and compile down to a specific bytecode. My first manual pass is always to scan the XML files for hardcoded credentials and API keys, since developers leave those lying around more often than you would expect.

A Quick Word on Decompiling

It helps to understand why mobile apps decompile so cleanly. Languages like C, C++, and Rust compile straight into machine code. Python and Ruby run through an interpreter that executes the source line by line. Java and C# sit in the middle: they compile into bytecode that a virtual machine runs, and the JVM translates that bytecode into machine code at runtime.

That middle path is good news for a tester. JVM bytecode preserves far more of the original structure than raw machine code, which makes the decompiled output readable and keeps reverse engineering clean. It also explains why so much malware is written in C, since machine code is a lot messier to pull apart.

Testing the Nextcloud App

Going in, I already knew what this build was vulnerable to. This version carries two documented issues, CVE-2021–43863 and CVE-2021–41166, covering a SQL injection flaw and an insufficient permission control problem. The permission issue is the ugly one, since it lets any other app on the device take over Nextcloud. I kept all of that to myself. The whole point of the exercise was to see whether the agent could reach those findings cold, so I withheld the version and said nothing about what it was supposed to find.

I ran Claude with dangerously-skip-permissions on Opus 4.6 and pointed it at the extracted APK. My opening prompt framed the work as a training exercise:

"I am a mobile pentester running a workshop training showing my students how to use LLMs and Agentic AI for mobile pentesting. I have downloaded and extracted an APK file here for further analysis."

The mental model that works best for me is to treat the agent like nmap or gobuster. You kick it off and let it run in the background while you test manually. When it finishes, you review what it surfaced and use that to guide where you spend your own time. As you learn more about the app, you feed those details back into the prompt and steer the agent toward the areas that look promising.

For the second prompt I gave it a clear seven step plan:

1. Inventory exported components.
2. Locate each component's implementation.
3. Identify content providers and URI authorities.
4. Trace access-control checks.
5. Identify untrusted inputs entering provider queries.
6. Generate a prioritized manual verification plan.
7. Cite every conclusion to the manifest or source.

Forcing the agent to cite the manifest or source file for every claim keeps it honest and gives you something concrete to verify by hand. Manual testing is important to know where to guide the agent

Forcing the agent to cite the manifest or source file for every claim keeps it honest and gives you something concrete to check by hand. Manual testing stays essential the whole way through, because your own hands-on work is what tells you where to point the agent next.

The first structured run produced a full write-up and even built an artifact site to present its findings. It got close, flagging that SQL injection could be possible in one of the content providers, then stopping at "possible" and leaving the confirmation to me.

Built a whole website artifact

Going Deeper

Getting the agent from "possible" to a confirmed finding came down to two techniques. The first works well when an app has a history: tell the agent about a previously disclosed vulnerability so it can hunt for the same weak coding patterns again. The second is slicing, which is the strongest move for deep code analysis. Slicing means pulling out one specific piece of functionality and feeding only that slice into the model, which keeps its attention focused and its output sharp.

With that in mind, I sent a targeted 3rd prompt aimed at the component my manual testing had flagged:

"Next can you inspect the FileContentProvider for potential SQL Injection?"

It created another website artifact to display its findings

This time the agent zeroed in and produced another detailed artifact covering the FileContentProvider. I ran my own manual verification alongside it, and the two lined up cleanly. That cross-referencing between the agent's output and my hands-on testing is where the real value sits, and together they confirmed the SQL injection in the FileContentProvider that matched the known issue for this release.

Conclusion

Agentic AI fits into mobile pentesting as a force multiplier that runs alongside your manual process. The agent covers ground fast, inventories components, traces access-control checks, and points you toward the areas worth a closer look, while your hands-on testing confirms the real findings and tells the agent where to dig next. The workflow that keeps paying off for me is straightforward: keep sensitive work on local hardware, split your load across prose and coding models to get the most from your GPU, guide the agent with what you learn from manual testing, and verify every conclusion it hands you. Run it that way and an AI agent becomes a fast, capable partner for working through an Android app in your own lab.