Reverse engineering Android apps is already time-intensive, but when you add obfuscation into the mix, the challenge multiplies. For malware analysts, vulnerability researchers, and bug bounty hunters, reading obfuscated code can feel like decoding a foreign language—one that changes with every app.
Recently, I came across a tool—Androidmeda. It attempts to deobfuscate decompiled Android code using a large language model (LLMs). I decided to give it a try, and to my surprise, the results were far better than expected. Androidmeda doesn’t just rename variables—it makes the code readable, explains what it does, and even generates vulnerability insights.
Until now, analysts either had to power through unreadable code or build their own custom deobfuscators, which are time-consuming and narrowly focused – new obfucator == create new deobfuscator. Androidmeda offers a smarter, if you want AI-powered alternative—and in this post, I’ll walk through how it works and why it matters.
What Is Obfuscation and Why Does It Matter?
Obfuscation is the act of making source code difficult to read while keeping its functionality. Developers use it to protect intellectual property, prevent reverse engineering, and reduce the risk of tampering. Common techniques include renaming variables to meaningless strings, flattening control flow, and encrypting strings.
Unfortunately, obfuscation isn’t just for defense. Malware authors also obfuscate their code—sometimes aggressively—to hide malicious logic from analysts. Tools like ProGuard, DexGuard, Allatori, DashO, and Stringer are frequently used in both legitimate and malicious apps. That creates a major problem for analysts trying to understand how an app works or where its vulnerabilities lie.
Why To Deobfuscate?
This brings us to de-obfuscation. For code reviewers, the goal isn’t just to read code—it’s to understand it. Deobfuscation bridges the gap between unreadable junk and meaningful logic. It lets analysts focus on behavior, not brute-force interpretation. Instead of wasting hours renaming variables or tracing distorted control flow, deobfuscation tools let you spend more time spotting vulnerabilities, understanding app workflow, or suspicious behavior patterns.
Meet Androidmeda: LLM Powered Deobfuscation for Android Apps
Androidmeda is a tool that deobfuscates Android app code using large language models. It doesn’t just rename variables—it explains what the code likely does. The tool uses LLMs to reason through logic and generates annotated, human-readable code with comments. It can even produce vulnerability reports from decompiled code.
Androidmeda supports both local and remote LLM backends:
- Local models like LLaMA or Mistral for air-gapped environments.
- API-based models like OpenAI’s GPT-4, Gemini or Anthropic’s Claude for more accurate and in-depth reasoning.
Installation and usage are straightforward:
• First, clone the repository using
git clone https://github.com/In3tinct/Deobfuscate-android-app.git• Next, install the necessary dependencies with
pip3 install -r requirements.txt• Then, you need to decompile the APK of the target app. The sources suggest using jadx, which will create “resources” and “sources” directories, with the .java files residing in the “sources” directory
• Finally, run the script, specifying your chosen LLM provider and model. For public API models (Google, Anthropic, OpenAI), you’ll need to export your API key. For example, running with Gemini would look like:
python3 androidmeda.py --llm_provider google --llm_model gemini-1.5-flash -output_dir out/ -source_dir input_dir/ -save_code trueIf using Ollama locally, you’d first follow its setup steps and then run
python3 androidmeda.py --llm_provider ollama --llm_model llama3.2 -output_dir out/ -source_dir input_dir/ -save_code true
For some apps I experienced errors that resulted in skipping the deobfuscation of the class or vulnerability analysis, so as always, nothing is 100%, however few fixed could help to resolve the errors.
After fixing the deobfuscation error, vulnerability issue appeared.
The tool takes a decompiled code directory as input, and its output includes a JSON file named vuln_report listing security risks and their impact, and if -save_code true flag is included, deobfuscated code is saved in a package directory structure. It’s crucial to only send specific directories containing app-specific code as input, rather than the entire package, to avoid extensive scan times. Below you can see the vulnerability output, that you should always manually double check :).
vuln_report for dvba vulnerable appDeobfucation use cases include:
- Malware analysis
- Vulnerability research with possible false positives
- Bug bounty recon with possible false positives
- Code readability improvement for legacy or third-party apps
Deobfuscating Crocodilus Malware
Let’s take a recent example from the Crocodilus Android malware family disclosed in March 2025. The original code was heavily obfuscated—variable names were randomized, control structures were warped, and string values were encoded. A quick manual glance gave little away.
Running the same code through Androidmeda changed the game to speed up the analysis. The tool:
- Reconstructed meaningful variable names
- Annotated complex control structures with human-readable explanations
- Highlighted suspicious function calls (e.g., to accessibility APIs and remote URLs)
- Produced a summarized vulnerability report pinpointing weak points
Below is an example of a decompiled code for the same original and deobfuscated class.
The difference was clear: instead of wasting hours parsing logic, the analyst could immediately zero in on malicious analysis.
Other Tools for Android Deobfuscation
While Androidmeda is an impressive improvement, there are other tools – or let’s say plugins – worth knowing:
- JEB Decompiler – commercial tool with deobfuscation features.
- Jadx-gui – widely used open-source decompiler with limited deobfuscation.
Conclusion
Obfuscation serves a purpose—whether for protecting apps or hiding malicious functionality. But for reverse engineers and cybersecurity community, it’s a barrier. Without a deobfuscation tool, analysts are stuck reading raw, scrambled code or writing their own parsers, which only work against specific obfuscation techniques.
Alternatively, reverse engineers might create their own deobfuscator, but such a tool would likely be time-consuming to develop and effective only against a specific obfuscation method. This is where the power of Large Language Models (LLMs) shines, as they offer more universal method to deal with different types of code obfuscation. Tools like Androidmeda, by leveraging LLMs, represent a useful step forward, promising a future where analysts can better read obfuscated code, allowing them to spend less time deciphering complex code and more time on the actual analysis and vulnerability discovery.