Static app analysis (APK/IPA)

~7 min · APK/IPA · static · Hunter Pro

The short version. Crusader's App Analysis screen takes an app package apart without running it. It reads the Android manifest, lists permissions, flags exported components and browsable deep links, mines the app's compiled code and resources for custom request headers and hardcoded http(s) URLs, and scores it all into triage leads. Those leads are wired straight into the rest of Crusader — discovered URLs become Site Map endpoints, and any endpoint or header opens in Repeater as a ready-to-send request. Static analysis surfaces leads, not confirmed bugs: prove each one with live interception. Today the extractor is Android-only (.apk / .xapk / .apks).

01What static analysis is good for

Before you intercept a single request, the app package already tells you most of its attack surface. The manifest declares every screen, service, and content provider, and which of them other apps can reach. The compiled code carries the API hosts it talks to, the custom headers it sends, and the deep links it answers. Pulling that out first means you walk into live testing with a target list instead of a blank proxy.

Crusader's App Analysis is built to convert that inventory into work:

Endpoints to test — hardcoded URLs become Site Map entries and one-click Repeater requests.
Custom headers to probe — app-defined headers (auth, attestation, tenant routing, signing) get opened as Repeater "proof kits" so you can test whether the server actually enforces them.
Exported components to triage — activities, services, receivers, and providers reachable by other apps, ranked by whether they're protected by a permission.
Build mistakes — debuggable or test-only release builds, cleartext traffic, loose backup flags, and the presence of a network security config.

Run this only against apps you're authorized to test. Decompiling and analyzing a package is part of an engagement scope — make sure the app is in yours.

02Platform support & what it extracts

Android is what's implemented today. The file picker and importer accept .apk, .xapk, and .apks packages. App-bundle archives (.xapk / .apks) are unzipped and the embedded split APKs are analyzed, with the base APK chosen as the primary manifest source. iOS .ipa packages are not parsed by the static analyzer yet — the iOS side of Crusader's mobile workflow is live instrumentation against a jailbroken device (see the cert-pinning and mTLS guides), not package extraction. If your engagement is iOS, treat this page as Android-only.

For a loaded Android package, the analyzer extracts:

What	Detail
Package identity	Package name, version name/code, launch activity, `minSdk` / `targetSdk`, declared features, file size and SHA-256.
Permissions	Every declared permission, with dangerous/privacy-sensitive ones (location, contacts, SMS, camera, accessibility, install-packages, overlay, external storage…) flagged.
Manifest flags	`debuggable`, `allowBackup`, `usesCleartextTraffic`, `testOnly`, and whether a `networkSecurityConfig` is set.
Components	Activities, activity-aliases, services, receivers, and providers — with exported state, guarding permission (incl. provider read/write), intent filters, and provider authorities.
Deep links	Browsable `VIEW` intent filters, decomposed into scheme / host / path so you can see every URL the app will open.
Custom headers	App-defined HTTP header names mined from the DEX strings and resources, with standard headers filtered out and high-value ones (auth, token, api-key, app-check/attestation, tenant, signature…) flagged.
Endpoints / URLs	Hardcoded `http(s)` URLs recovered from dex/resources/assets (capped at 200), de-duplicated and filtered of known-noise hosts.

Each of these is also rolled up into a list of severity-scored static triage leads — for example "Exported components without manifest permission," "Cleartext traffic allowed," "High-value custom request headers," or "Browsable deeplink attack surface."

What it does not do. The analyzer surfaces header names and URL strings — it does not dump secret values (API keys, tokens) as confirmed credentials, and it does not parse the APK signing certificate or report a code-signing chain. Treat flagged headers and endpoints as places to look, then confirm what's really sensitive by capturing traffic.

03What you'll need

Crusader with the mobile feature — App Analysis lives in the Mobile section and is part of Hunter Pro. Opening the screen prompts to unlock if your license doesn't cover it.
Android SDK Build-Tools — the manifest read uses aapt. If it isn't on your PATH or under a detected SDK, install it (for example sdkmanager "build-tools;34.0.0", or via Android Studio's SDK Manager). Without it, Crusader can still show file size but not the manifest. Crusader can install the surrounding mobile toolchain for you from Setup tools.
The app package — a local .apk, .xapk, or .apks file for an app you're authorized to test.

04Step 1 — Load an app package

Open Mobile from the sidebar and select App Analysis. Click Choose app and pick a local .apk, .xapk, or .apks file.

Crusader inspects the package on import: for an app bundle it expands the archive and selects the base APK, runs the manifest read, then scans the compiled code and resources for headers and URLs. When it finishes, the package is recorded into the current project and selected as the active artifact. Imports are retained per project, so you can switch between several packages with the artifact selector at the top of the screen.

If you came in through Easy Mode's "Pick a test app" drop zone, the same package also lands here — Easy Mode installs it on the emulator, while App Analysis is where you read what's inside it.

05Step 2 — Read the extraction

The active artifact panel leads with identity (package name, version, SDK levels, launch activity, SHA-256) and a triage score. Below it, a row of stat cards summarizes the surface: Exported components, Deeplinks, custom Headers (with a high-value count), and Sensitive permissions against the number of endpoint hosts.

Work top to bottom:

Static triage leads — the scored findings, highest severity first. Each row is explicitly marked "Not proof yet": it's a static signal, and it carries the on-device confirmation commands you'd run to prove it.
Build & network flags — a debuggable or testOnly release build is high signal; usesCleartextTraffic=true tells you to watch login/token/API/WebView traffic for HTTP downgrade; allowBackup=true points at local-data extraction; a network security config is worth opening for debug trust anchors, cleartext exceptions, and pinned domains.
Exported components — anything exported without a guarding permission is a priority. Exported content providers without a permission get called out for immediate authority/URI enumeration.
Deep links — each browsable route shows its scheme://host/path. These are your candidates for auth-callback abuse, host-validation bugs, open redirects, and WebView injection.
Custom headers — high-value headers (auth, attestation, tenant, signing) are the ones most likely to gate server behavior. The parser note at the bottom is the raw, copyable summary.

Quick copy actions on the active artifact let you grab the package name, the SHA-256, or a ready-made probe plan for the discovered surface. Rescan headers re-mines the original file if you want a fresh pass.

06Step 3 — Turn leads into tests

This is where static analysis pays off — every lead has a path into live testing.

Endpoints → Site Map → Repeater

Hardcoded URLs are recorded as Site Map endpoints tagged apk-static (they show up as unprobed "ghost" endpoints until you hit them). Click any discovered endpoint to load it as a Repeater tab — Crusader builds the request, pre-fills a baseline, and notes the candidate headers — then press Send to confirm the endpoint is live and see how it responds unauthenticated.

Custom headers → proof kit

A flagged header opens in Repeater as a header proof kit: a control request plus variants with the header blank and mutated. Send all three and compare. If the response changes only when the header is present and correct, the server enforces it; if a blank or junk value works the same, you've found a control that isn't actually a control — a real lead for auth, attestation, or tenant-isolation bypass.

Endpoints → live interception

The strongest signal is the app actually using these endpoints. Route the app through Crusader's proxy and watch the same hosts and headers appear in History under real auth. To get HTTPS out of a hardened app you'll usually need to defeat certificate pinning first.

Static findings are leads, not confirmed vulnerabilities. An exported activity, a cleartext flag, or a suspicious header is a hypothesis until you reproduce the impact live. Pair this screen with cert-pinning bypass so you can intercept the app's real traffic and prove the lead.

07Limits & honesty

Android only, for now

The static extractor handles .apk / .xapk / .apks. There is no iOS .ipa parser — for iOS, the workflow is live Frida instrumentation against a jailbroken device, covered in the pinning and mTLS guides.

aapt is required for the manifest

Permissions, manifest flags, components, and deep links come from aapt. If the Android Build-Tools aren't installed, those sections are skipped and the inspection note says so — install Build-Tools and rescan. Header and URL mining runs regardless, since it reads the package directly.

Recovered, not exhaustive

URL and header extraction is a best-effort scan over compiled code and resources with size caps (URLs are capped at 200). Obfuscated, encrypted, or runtime-assembled strings won't appear, and counts can be lower bounds when output is truncated — Crusader flags truncation in the findings. Absence of a lead is not proof the app is clean.

It finds leads; you confirm them

Nothing here is a confirmed bug. The screen is deliberate about this: leads are labelled as static signals and shipped with the confirmation steps needed before anything is reportable. The proof comes from live traffic, not the package.

Bypass cert pinning → Capture mTLS client certs → Bug-hunting workflow →

Want a guide that isn't here yet? Email hello@crusaderproxy.com.