applink-declaration-analysis

Extract app identifiers and claimed URL paths from assetlinks.json and apple-app-site-association files.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill applink-declaration-analysis-dbx0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: applink-declaration-analysis
Source: https://github.com/dbx0/skills/tree/main/skills/mobile/reverse-engineering/applink-declaration-analysis
Command: npx skills add https://github.com/dbx0/skills --skill applink-declaration-analysis-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Mobile recon often stalls when you cannot obtain an IPA or APK, yet two public, unauthenticated JSON files on the target's domain already declare which apps handle its URLs and which paths they claim. This Skill turns those declarations into concrete attack surface while preventing the common false positive of reporting staging-app link hijacking that certificate binding actually prevents. ## Core Features & Use Cases - Declaration harvesting: Fetch apple-app-site-association and assetlinks.json (including the legacy non-.well-known path) across candidate hosts to enumerate production, staging, and internal bundle identifiers. - Path mining: Extract the exact claimed URL paths (e.g., /payment/, /account-linking/) as a curated list of sensitive token-bearing flows for web testing. - Exploitability verification: Compare Android sha256 cert fingerprints and iOS team IDs to decide whether a staging declaration is genuinely reportable or a hygiene note. - Use Case: During a fintech engagement with no IPA access, pull the AASA file from the production domain, recover staging bundle IDs and claimed payment paths, then verify fingerprint separation before writing anything into the report. ## Quick Start Fetch the .well-known/apple-app-site-association and assetlinks.json files from the target domain and analyze them for staging app identifiers and claimed URL paths.

Frequently Asked Questions about applink-declaration-analysis

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

FAQPage Schema
How do I find an app's universal links and Android App Links without the binary?

Fetch https://<domain>/.well-known/apple-app-site-association and /.well-known/assetlinks.json from the target's hosts. These unauthenticated JSON files list the app identifiers and exact URL paths each app claims, with no binary required.

How to check if a staging app in assetlinks.json is exploitable?

Compare the sha256_cert_fingerprints across package entries in assetlinks.json. Distinct fingerprints with zero overlap mean Android verifies the signing cert and the declaration is not exploitable; empty or missing fingerprint arrays warrant further investigation.

Can I assess iOS attack surface without an IPA file?

Yes, the apple-app-site-association file reveals bundle IDs, claimed paths, and webcredentials entries. For Flutter or React Native apps, cross-reference custom URL schemes from Android assets to infer the shared API surface and scope the untested native remainder.

Why is 'staging app can hijack production links' usually a false positive?

Both platforms bind declarations to a signing identity: Android verifies sha256 cert fingerprints and Apple validates the team ID at install. An outsider cannot publish an app that inherits those links, so only unregistered bundle IDs, empty fingerprints, or attacker-controlled hosts are reportable.

What are the limitations of app link declaration analysis?

It only exposes what the target declares publicly and cannot reveal runtime behavior, native-layer logic, or endpoints not tied to claimed paths. Findings still require validation against the live web surface and, where possible, the actual binaries.