RedForge / Mobile

What anybody who downloads your app can pull out of it.

Android APK and AAB, iOS IPA, and the backend API those apps actually talk to. Mapped to the OWASP Mobile Top 10 and MASVS, and bound to the exact build by SHA-256 so the report cannot drift from what you shipped.

What is covered

The build, and the API behind it.

A mobile app is a client you hand to strangers. Everything compiled into it is readable, and the API it talks to is reachable without it.

Android — APK and AAB

What your release build actually ships, read the way anybody who downloads it can read it.

How it works

We decompile your release build and examine what it contains: hardcoded API keys and credentials, screens and services other apps on the same phone can launch, unprotected content providers, backup and local storage settings, weak encryption, and whether certificate pinning is present.

How it helps

A key compiled into an APK is a published key. This tells you which ones are already public, and which components a malicious app installed alongside yours could call.

iOS — IPA, static analysis

Entitlements, App Transport Security, background modes, pinning, and the API surface recovered from the binary itself.

How it works

We read Info.plist, entitlements and Mach-O strings, review data protection classes and WebView ATS exceptions, and check Universal Links and jailbreak-detection handling.

How it helps

Static only. Runtime and traffic analysis on iOS needs a physical device, which is not in this package — and the report says so rather than implying the runtime surface was cleared.

The backend API

The hosts extracted from the build, then tested as the running API they are.

How it works

Backend hosts and endpoints recovered from the binary are fed into the same API assessment the web engagement uses: authentication, per-object permissions, rate limiting, token handling and input validation.

How it helps

The app is a client, not the boundary. Anyone can call your API without it, which is why testing the build alone answers half the question.

The report is bound to one build. Every mobile finding carries the SHA-256 of the exact APK, AAB or IPA it was found in. A report that does not name the build it tested cannot be checked against the build you shipped, and a month later nobody can tell whether it still applies.

Ready to scope a mobile assessment?

Send us the build and the backend it talks to. Written authorization from the legal owner of the asset comes first, always.

Send us your scope