3.7 KiB
| allowed-tools | description | user-invocable | argument-hint | argument |
|---|---|---|---|---|
| Bash, Read, Glob, Grep, Write | Detect and analyze tracker/analytics SDKs in decompiled Android sources | true | <path to decompiled sources directory> | path to decompiled sources directory (optional) |
/find-trackers
Detect and analyze analytics/tracker SDKs in a decompiled Android app.
Instructions
You are starting the tracker analysis workflow. Follow these steps:
Step 1: Get the source directory
If the user provided a path as an argument, use that. Otherwise, ask the user for the path to the decompiled sources directory.
If no decompiled sources exist yet, tell the user to run /decompile first on their APK/XAPK file.
Verify the directory exists and contains .java or .kt files:
find "$SOURCE_DIR" -name "*.java" -o -name "*.kt" | head -5
Step 2: Run broad detection
Execute the tracker detection script to sweep for all known tracker SDKs:
bash ${CLAUDE_PLUGIN_ROOT}/skills/tracker-analysis/scripts/find-trackers.sh "$SOURCE_DIR" --all
Parse the output — non-empty sections indicate a detected SDK.
Step 3: Analyze each detected SDK
For each SDK found in the sweep, perform deep analysis:
- Read the initialization code — find where the SDK is set up, extract API keys/app IDs
- Catalog tracked events — list all event names and their parameters
- Check user identification — find setUserId/identify calls, what user data is collected
- Verify consent handling — check if the app gates analytics on user consent
- Identify data endpoints — known domains and any custom relay/proxy
Use the reference documents in ${CLAUDE_PLUGIN_ROOT}/skills/tracker-analysis/references/ for SDK-specific patterns.
Step 3b: Filter false positives
When analyzing the results, distinguish real SDK presence from false positives:
- HIGH confidence — SDK-specific classes/imports are present (e.g.,
FirebaseAnalytics.getInstance(),import com.adjust.sdk.Adjust). The SDK is definitely integrated. - MEDIUM confidence — Only generic method names matched (e.g.,
.track(,.logEvent(,.identify(). These are common method names used by many libraries, not just tracker SDKs. Verify by checking if the actual SDK package exists in the source tree. - LOW confidence — Only string matches (e.g., the word "amplitude" in a comment or unrelated context). Check the surrounding code — if it's not an SDK import/call, it's a false positive.
Quick verification: For any SDK flagged as detected, check if its package directory actually exists:
# Example: verify Firebase is really present, not just a string match
find "$SOURCE_DIR" -path "*/com/google/firebase/analytics" -type d
Use --summary for a quick confidence-scored overview before diving into raw output:
bash ${CLAUDE_PLUGIN_ROOT}/skills/tracker-analysis/scripts/find-trackers.sh "$SOURCE_DIR" --summary
Step 4: Produce report
Generate a structured report with:
- Summary table: SDK name, init location, event count, user ID method, consent status
- Per-SDK detail: initialization, events, user data, consent, endpoints
- Privacy summary: total SDKs, consent coverage, user data shared, endpoint domains
Refer to ${CLAUDE_PLUGIN_ROOT}/skills/tracker-analysis/SKILL.md for the full report format.
Step 5: Offer next steps
Tell the user what they can do next:
- Deep-dive a specific SDK: "I can trace the full data flow for Firebase Analytics"
- Check data exfiltration: "I can search for proxy/relay patterns and custom endpoints"
- Analyze ad SDKs: "Run
/find-adsto analyze advertising SDKs too" - Export report: "I can save this report as a markdown file"