A mobile app is a bundle of clues about who built it and what it talks to. Even without deep reverse engineering, examining an app reveals the servers it contacts, the trackers and SDKs it embeds, and the developer identifiers linking it to other apps — a rich, often overlooked OSINT surface.
What you'll need
- The app package (an APK) and its store listing
- A safe, isolated device or research environment to handle it
- Domain Names & Usernames and Threat Intelligence tools to resolve what you find
Steps
- Start with the store listing. Record the developer name, contact email, website, and privacy policy — these often tie an app to a company or individual before you open a single file.
- Inspect the permissions and manifest. List what the app requests access to; excessive or mismatched permissions are both a privacy red flag and a clue to its real function.
- Extract embedded endpoints. Pull the domains, API URLs, and hosts baked into the package; each is a lead you can resolve with WHOIS and infrastructure lookups.
- Identify trackers and SDKs. Note the analytics and advertising libraries present; their IDs are frequently reused across an author's other apps, enabling a pivot.
- Correlate and attribute. Combine developer details, shared endpoints, and reused tracker IDs to connect the app to a wider portfolio and, where possible, to a real operator via attribution.
Common pitfalls
- Running unknown apps on a real device. Malware and honeytokens make an isolated environment essential.
- Treating third-party SDK domains as the developer's. Shared advertising and analytics hosts can create false links if not distinguished.
- Overreaching from static clues. Endpoints and permissions show capability, not proof of behaviour — corroborate before concluding.
Verify your result
You have analysed the app when you can list its permissions, the endpoints and trackers it embeds, and the developer identifiers — and can show which of those genuinely link it to other apps or a real-world operator.