npx claudepluginhub jygzyc/decx --plugin decxThis skill uses the workspace's default tool permissions.
Use this skill for static framework and Binder-service vulnerability hunting.
assets/findings-template.jsonassets/poc-handoff-template.jsonassets/recon-template.jsonassets/report-target-vuln-en.mdassets/report-target-vuln-zh.mdassets/report-template-en.mdassets/report-template-zh.mdassets/report-template.mdassets/resume-template.jsonassets/shortlist-template.jsonreferences/framework-service-clear-identity.mdreferences/framework-service-data-leak.mdreferences/framework-service-identity-confusion.mdreferences/framework-service-intent-redirect.mdreferences/framework-service-permission-missing.mdreferences/framework-service-race-condition.mdreferences/framework-service.mdreferences/risk-rating.mdHunts vulnerabilities in Android APKs using DECX CLI and JADX: enumerates attack surfaces, triages exported components and deep links, traces WebView/IPC flows, screens exploitability, generates bilingual reports with PoC handoff.
Performs static analysis of Android APK/AAB files with MobSF to detect hardcoded secrets, insecure permissions, vulnerable components, and crypto flaws. For pentesting, CI/CD gates, and APK reviews.
Performs automated static analysis of Android APK/AAB files using MobSF to detect hardcoded secrets, insecure permissions, vulnerable components, and weak cryptography. For pre-deployment scans, pentesting, or CI/CD security gates.
Share bugs, ideas, or general feedback.
Use this skill for static framework and Binder-service vulnerability hunting.
source/decxcli-app-vulnhunt for APK surfaces and decxcli-poc for PoC or runtime validationstatically-supportedpoc-validated, runtime-validated, verified exploitable, or equivalentdecxcliframework_<oem>_<vendor>.jar or a user-provided equivalent final bundlesource/ as separate DECX targetssource/ or another split jar, stop and ask for the processed final bundlesystem_server, Binder services, AIDL implementations, vendor services, OEM framework code, and privileged manager or service familiesdecxcli-app-vulnhuntdecx code command and every session-backed decx ard command must include -P <port>decx ard commands such as system-services, perm-info, framework collect, and framework process do not use -P <port>; use --serial and --adb-path when neededdecx ard framework run and decx ard framework open use -P <port> only when they open a DECX session"package.Class.method(paramType):returnType"... in signatures--help command before retrying.decx-analysis/<target-name>/recon.json, shortlist.json, findings.json, report.md, resume.json, poc-handoff.jsonassets/recon-template.json, assets/shortlist-template.json, assets/findings-template.json, assets/resume-template.json, and assets/poc-handoff-template.json| State | Meaning | Allowed |
|---|---|---|
candidate | suspicious path found, still missing evidence | Yes |
statically-supported | static evidence supports reachability, control, bypassability, and visible impact | Yes |
rejected | unreachable, uncontrollable, blocked, or not impactful | Yes |
Every reported finding must answer:
reachablecontrollablebypassConditionsimpactEvidenceratingRationaleDecision rules:
candidaterejectedreferences/risk-rating.md: do not report itTrack progress with:
Framework VulnHunt Progress
- [ ] Phase 1: Prepare framework target and confirm session
- [ ] Phase 2: Enumerate Binder / framework attack surface
- [ ] Phase 3: Trace per-service flows
- [ ] Phase 4: Trace required cross-service or manager chains
- [ ] Phase 5: Filter by exploitability
- [ ] Phase 6: Generate final report
- [ ] Handoff: Pass minimal finding set to decxcli-poc
Goal: open the final framework bundle and confirm DECX is healthy.
Fastest path:
decx ard framework run --serial <serial> -P <port>
Artifact-retaining path:
decx ard framework collect --serial <serial>
decx ard framework process <oem> --serial <serial>
decx ard framework open -P <port> --serial <serial>
If the user already has the final bundle:
decx ard framework open "<framework-jar-path>" -P <port>
decx process status -P <port>
Rules:
framework run for fastest device-to-session flowcollect -> process -> open when artifact retention or output-directory control mattersframework_<oem>_<vendor>.jar session name when possibleframework collect and framework process are adb or local-artifact operations, not session-backed reads, so do not add -P <port>decx process close "<name>"Goal: enumerate the framework attack surface and return a minimal structured shortlist.
Execution model:
decx commandsStart from one of these anchors:
decx ard system-services --serial <serial> --grep <keyword>decx ard system-service-impl "<interface>" -P <port>decx code implement "<interface>" -P <port>decx code search-method "<methodName>" -P <port> only if the Binder entrypoint name is still unknownRecon rules:
--grep filter before broadening scopesystem-services and perm-info are support evidence, not substitutes for code tracingsystem-services returns structured JSON with total and services[]; use name and interfaces directly rather than grepping raw textdecx ard perm-info "<permission>" --serial <serial> and reason from the parsed object instead of shell snippetsRecon output:
needsAnalysis: true targets move to Phase 3recon.json before deep tracing when interruption-safe analysis mattersGoal: upgrade each retained framework target to statically-supported or downgrade it to rejected, while keeping the current source component, likely issue type, chain progress, and next follow-up targets explicit.
Core loop:
decx ard system-services --serial <serial> --grep <keyword> to map the runtime surfaceinterfaces[] to choose the most relevant Binder contractdecx ard system-service-impl "<interface>" -P <port> to resolve one selected implementationdecx ard perm-info "<permission>" --serial <serial>system-services.interfaces[]; do not invent or normalize Binder names by handSubagent split:
references/framework-service.md plus target source and selects likely vuln patterns and entry methodsChain command:
decx code method-context "<currentMethod>" -P <port>
Use method-source only when you need the full body; prefer method-context to see callers and callees in one call.
Method labels:
SOURCE: attacker-controlled Binder or manager input enters hereSINK: privileged service action happens hereSAFE: non-bypassable guard exists herePASS_THROUGH: keep tracingDEAD_END: no further valueCommon sources:
Parcel fields decoded from transactionsCommon sinks:
clearCallingIdentityCommon non-bypassable guards:
enforceCallingPermission, checkCallingPermission, enforceCallingOrSelfPermissionPhase output:
shortlist.json if recon took meaningful effortfindings.jsonshortlist.json or findings.json traceSummary current with the source component, narrowed issue types, analyzed chains, and next candidate targetsvulnType, risk, status, serviceName, interface, entryPoint, source, sink, callChain, traceSummary, reachable, controllable, guardsChecked, bypassConditions, impactEvidence, ratingRationaleContinue only when needed:
Rules:
nextMethods from the previous phasechainThis phase is exploitability triage based on the traced chain, not exploitation proof.
Quick rejection checks:
| Condition | Check |
|---|---|
signature or signatureOrSystem permission | perm-info.protectionLevel |
| exact signature enforcement | checkSignatures, platform-signer compare |
| hard package or UID allowlist | immutable trusted allowlist |
| root or system-only path | privileged-only API or environment |
| non-bypassable guard on source-to-sink path | permission, ownership, identity, cryptographic, or strict type guard |
Framework-specific rules:
perm-info confirms signature or signatureOrSystem, treat the path as protected unless access is forwarded or capability is re-grantedcandidate unless bypass conditions are explicitsystem-services shows no matching Binder service on the connected device, downgrade runtime-reachability confidenceThree-factor gate:
Decision:
statically-supportedrejectedGoal: generate the final Markdown report using only statically-supported findings.
Execution model:
Reporting steps:
assets/report-template.mdreferences/risk-rating.mdzh -> assets/report-template-zh.md, en -> assets/report-template-en.md, both -> Chinese first then Englishdecx code method-source "<method>" -P <port>Mandatory report content:
Bypass Conditions / UncertaintiesVisible ImpactRating RationaleReport rules:
At 60% context usage, hand off immediately:
{
"handoff": true,
"phase": "<current phase>",
"component": "<current service or null during recon>",
"traceSummary": {
"sourceComponent": "<current Binder service, manager facade, or Stub>",
"possibleIssueTypes": ["<current likely issue types>"],
"analyzedAttackChains": ["<chains already traced>"],
"nextCandidateTargets": ["<next services or helper chains to analyze>"]
},
"port": 31234,
"done": "<completed work>",
"next": "<entry instruction for the next subagent>",
"context": "<minimum context needed to continue>"
}
If file-backed continuation is enabled, also persist the same state to resume.json.
Resume procedure:
resume.jsontarget, artifactPath, sessionName, port, and serial still matchrecon.json, shortlist.json, and findings.jsondecx process status -P <port>lastCompletedPhase and nextAction instead of repeating completed workdecxcli-pocPass only the minimal finding packet plus the current trace focus.
poc-handoff.json from assets/poc-handoff-template.jsonstatically-supportedreferences/framework-service.mdreferences/risk-rating.md