decompile-threat-review

Decompile Android APKs and run multi-agent static review to produce threat models and candidate vulnerability reports.

48|27|Updated Jul 30, 2026
One-click install
npx skills add https://github.com/abisheikM1/Tribunal --skill decompile-threat-review-abisheikm1
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: decompile-threat-review
Source: https://github.com/abisheikM1/Tribunal/tree/main/skills/decompile-threat-review
Command: npx skills add https://github.com/abisheikM1/Tribunal --skill decompile-threat-review-abisheikm1

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Manually reviewing a decompiled Android app for vulnerabilities is slow and error-prone: large codebases get skimmed, cross-file attack chains get missed, and findings lack the concrete verification steps needed for dynamic testing. This Skill automates the first stage of an authorized Android pentest by decompiling an APK and coordinating a multi-agent adversarial review that outputs a structured threat model and a prioritized candidate-findings report. ## Core Features & Use Cases - Automated decompilation and inventory: Runs apktool and jadx (PATH or vendored jars), hashes the APK into a targets/<sha256>/ workspace, fingerprints frameworks, and flags jadx decompile failures and heavily R8/ProGuard-obfuscated classes that require a smali pivot. - Multi-agent adversarial review: A threat-model-builder subagent plus four parallel rubric-lens subagents review the tree against a 13-category vulnerability catalog, with skeptic subagents attempting to refute each candidate finding before it ships. - Coverage and chain synthesis: coverage.py surfaces large unreviewed source files, and chain_graph.py cross-references entry points with findings to catch multi-hop chains (e.g., exported component forwarding an Intent to a path-traversal sink). - Use Case: Drop an authorized APK into apk/, run the inventory script, and receive threat_model.json plus report.json/report.md where every finding carries an exact dynamic verification plan (adb/Frida/Burp commands) ready for the dynamic-verify stage. ## Quick Start Place an APK you are authorized to test into the apk/ directory and ask the agent to decompile it and build a threat model with candidate vulnerabilities.

Frequently Asked Questions about decompile-threat-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I statically analyze an Android APK for vulnerabilities?

Place the APK in the apk/ directory and run the inventory script, which decompiles it with apktool and jadx into targets/<sha256>/. A multi-agent review then reads the decompiled tree against a 13-category rubric and writes threat_model.json plus report.json with candidate findings.

What tools are needed to decompile an APK with this workflow?

You need Python 3.10+ and Java, plus apktool and jadx. The scripts prefer versions on your PATH but fall back to vendored jars under tools/, so no separate install is required. Scripts degrade gracefully if a tool is missing.

How does the review handle obfuscated or failed jadx decompilation?

inventory.json flags jadx decompile failures and heavily R8/ProGuard-renamed classes with an obfuscation score. For those files you read the smali counterpart under apktool/smali*/ directly, and record them in threat_model.json's low_confidence_areas.

Can I use this on any APK I download?

No. A scope gate requires the APK to physically reside in the apk/ directory, which asserts you own it or are authorized to test it. The scripts fail closed with exit code 3 when the path resolves outside that boundary.

Why does the review use multiple subagents instead of one pass?

A single linear pass tends to skim files on large trees and never gets a second perspective before findings ship. The workflow fans out a threat-model builder, four rubric-lens reviewers, and skeptic subagents that try to refute each candidate finding before it is written up.

What happens to the findings after static review?

Each finding in report.json carries a verification_plan with exact adb, Frida, or Burp commands. The dynamic-verify skill executes those plans on an emulator and updates each finding's status to confirmed, not-reproduced, or needs-manual.