npx claudepluginhub jygzyc/decx --plugin decxThis skill uses the workspace's default tool permissions.
Turn one `decxcli-app-vulnhunt` or `decxcli-framework-vulnhunt` finding into one buildable `poc-<target>` project.
assets/poc-template-app/app/build.gradleassets/poc-template-app/app/src/main/AndroidManifest.xmlassets/poc-template-app/app/src/main/java/com/poc/targetapp/ExploitEntry.javaassets/poc-template-app/app/src/main/java/com/poc/targetapp/ExploitRegistry.javaassets/poc-template-app/app/src/main/java/com/poc/targetapp/PoCActivity.javaassets/poc-template-app/app/src/main/res/layout/activity_poc.xmlassets/poc-template-app/app/src/main/res/values/strings.xmlassets/poc-template-app/app/src/main/res/values/styles.xmlassets/poc-template-app/gradle.propertiesassets/poc-template-app/gradle/libs.versions.tomlassets/poc-template-app/gradle/wrapper/gradle-wrapper.jarassets/poc-template-app/gradle/wrapper/gradle-wrapper.propertiesassets/poc-template-app/gradlewassets/poc-template-app/gradlew.batassets/poc-template-app/settings.gradleassets/poc-template-server/package.jsonassets/poc-template-server/public/index.htmlassets/poc-template-server/public/payload.htmlassets/poc-template-server/public/scenario.jsassets/poc-template-server/server.mjsHunts 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.
Generates proof-of-concept code demonstrating security vulnerabilities for responsible disclosure, including Foundry and Forge tests for smart contract bugs.
Guides PoC exploit development for confirmed vulnerabilities in whitebox pentesting, with language recommendations, Python templates, and HTTP request patterns.
Share bugs, ideas, or general feedback.
Turn one decxcli-app-vulnhunt or decxcli-framework-vulnhunt finding into one buildable poc-<target> project.
Current project shape:
ExploitEntry, ExploitRegistry, and PoCActivityserver/ with index.html, scenario.js, and server.mjsDefault ceiling:
build-ready unless the user explicitly asks for compiledeployed or runtime-validated unless deployment or runtime proof actually happeneddecx code and decx ard command must include -P <port>.--help command before retrying.decx process close <session-name> or decx process close --port <port>.decx process open "<apk-path>" -P <port>
poc-<target> project per target; add one exploit id per finding.applicationId under com.poc.* and keep allowBackup="false".Normalize the active finding into this packet before coding:
{
"targetApp": "short target name",
"packageName": "victim package",
"componentType": "Activity|Service|Provider|Receiver|Intent|WebView|Framework",
"componentClass": "victim entry class or interface",
"vulnType": "specific finding type",
"entryPoint": "externally reachable method or callback",
"traceSummary": {
"sourceComponent": "tracked victim entry component or service interface",
"possibleIssueTypes": ["current issue-type hypotheses or narrowed class"],
"analyzedAttackChains": ["already traced victim-side chain summaries"],
"nextCandidateTargets": ["follow-up targets that are not part of this active PoC"]
},
"source": "attacker-controlled input",
"sink": "security-relevant action",
"callChain": ["minimal verified method path"],
"bypassConditions": ["exact conditions that make exploitation possible"],
"impactEvidence": "visible effect the PoC should prove",
"port": 8080
}
Select construction details up front:
{
"exploitMode": "direct-trigger|interception|returned-handle|hosted-web-content|binder-caller|ui-assisted",
"validationStory": "button-only|deeplink|intent-url|scenario-page|background-helper|manual-network",
"supportComponents": ["optional helper activity/service/receiver"],
"serverNeeds": ["optional trigger links, hosted HTML, bridge logic, result capture"],
"manifestNeeds": ["only what the exploit needs"],
"successSignal": "what the PoC should visibly prove"
}
Input gate:
statically-supportedcandidate findings require explicit exploratory intent from the userrejected findings should not become PoCsTrack progress with:
PoC Progress
- [ ] Normalize one finding
- [ ] Re-verify target path in DECX
- [ ] Select exploit mode and validation story
- [ ] Create or reuse PoC project
- [ ] Load one matching reference
- [ ] Implement exploit
- [ ] Register exploit and wire support
- [ ] Optional compile
- [ ] Optional deploy and runtime check
- [ ] Close DECX session
Keep only:
traceSummary so the active source component and already analyzed chain do not get lost during handoffMinimum checks:
Suggested commands:
decx ard exported-components -P <port>
decx ard app-manifest -P <port>
decx code method-source "<full-method-signature>" -P <port>
decx code class-source "<package.Class>" -P <port>
Write the result as:
- [PASS/FAIL] Surface exists: ...
- [PASS/FAIL] Entry point matches: ...
- [PASS/FAIL] Source is attacker-controlled: ...
- [PASS/FAIL] Sink is reachable: ...
- [PASS/FAIL] No missed non-bypassable guard: ...
Exploit modes:
direct-trigger: exported Activity, Service, Receiver, Provider pathsinterception: implicit Intent hijack, ordered broadcast, result or grant capturereturned-handle: mutable PendingIntent, granted content://, Binder or handle reusehosted-web-content: WebView, browser handoff, attacker page, JS bridgebinder-caller: AIDL, Messenger, framework Binder method callsui-assisted: task hijack, clickjacking, lifecycle or visible choreographyValidation stories:
button-only: local app button is enoughdeeplink: browsable URI is the natural triggerintent-url: browser-clickable intent:// or custom-scheme triggerscenario-page: browser page drives the whole chainbackground-helper: helper component must stay active outside the foreground activitymanual-network: SSL/MITM or remote-origin setup is requiredSelection rules:
capture -> triggerserver/ payload over remote infrastructure when both prove the same thingBootstrap:
node skill/decxcli-poc/scripts/setup-poc.mjs <target-app>
The script:
assets/poc-template-app/ to poc-<target>/app/assets/poc-template-server/ to poc-<target>/server/targetapp to the real target nameReuse rule:
poc-<target> project for later findings against the same targetLoad only one primary reference:
| Surface | Reference |
|---|---|
| Activity | references/poc-app-activity.md |
| Broadcast / Receiver | references/poc-app-broadcast.md |
| Provider | references/poc-app-provider.md |
| Service | references/poc-app-service.md |
| Intent / grant / handle | references/poc-app-intent.md |
| WebView | references/poc-app-webview.md |
| Framework Binder / service | references/poc-framework-service.md |
| Shared contract | references/poc-base.md |
Place exploit code under:
app/src/main/java/com/poc/<target-app>/exploit/
Implementation rules:
deeplink, intent-url, or scenario-page, keep PoCActivity route handling and server/public/ artifacts alignedscenario-page, fill only the sections the chain needs:
Always:
ExploitRegistryCommon support pieces:
server/public/ updates for browser-driven flowsOnly if the user explicitly asks.
Environment check:
node skill/decxcli-poc/scripts/check-env.mjs
Build:
cd poc-<target-app>/app && timeout 300 ./gradlew assembleDebug --no-daemon
If the build fails:
Only if the user explicitly asks and a device or emulator is available.
Typical commands:
adb devices
adb install app/build/outputs/apk/debug/app-debug.apk
adb logcat -s PoC:I AndroidRuntime:E
adb uninstall com.poc.<target-app>
Runtime proof must name the exact observed effect, for example:
Always close the DECX session used for re-verification before the final response:
decx process close --port <port>
If the session was opened by name, close it by name instead.
Close with:
stateprojectPathactiveFindingexploitModevalidationStoryexploitClassfilesChangedmanifestChangesdeliveryArtifactsbuildStatusruntimeStatusremainingManualStepsIf the PoC stopped before compile or runtime validation, state that explicitly.