Mobile Application Penetration Testing

Passed review. Shipped the keys.

Your app cleared review and went out to every phone with a production key compiled into it. A senior U.S. engineer takes the package apart by hand and reads the key back to you.

On the store

No malwareSigned buildApproved
  1. 01 · Unpack

    $ apktool d AcmeBanking.apk
    I: Baksmaling classes.dex
    I: Copying assets and libs
  2. 02 · Search

    $ cd AcmeBanking
    $ grep -rl AWS_ .
    ./assets/config.properties

    One match, in a file that ships inside every install.

  3. 03 · The key

    config.properties

    AWS_ACCESS_KEY_ID=AKIA…7QF2
    AWS_SECRET_ACCESS_KEY=6pZ9kR2t…

    A live production key, in every install.

    Hardcoded key. Critical.

  • Approved What the store review checks
  • AWS_SECRET… What shipped in the binary

Nothing replaces skill. Illustrative bundle, synthetic key. Signed, approved, and carrying a secret.

What We Test

An app you ship is an app you no longer control. We run it on the hardware an attacker would use, rooted and jailbroken, and read back everything it brought along.

On-Device Storage

What the app leaves behind: tokens in SharedPreferences or NSUserDefaults, unencrypted files, misused Keychain and Keystore.

Hardcoded Secrets

API keys, credentials, and endpoints compiled into the binary, pulled from the decompiled bundle.

Backend APIs

The REST and GraphQL services behind the app, tested for broken auth, IDOR, and injection, the way an API test would.

Transport Security

TLS, certificate pinning, and whether the traffic can be read or altered in the middle.

Platform Trust

Root and jailbreak detection, exported components, deep links, and what the app still does on a compromised device.

Business Logic

The rules the app enforces on the client, and what happens when the client stops enforcing them.

How We Test

Aligned with the OWASP Mobile Application Security Verification Standard and the Mobile Top 10. Automation maps the app; a senior engineer breaks it.

01

Map & Decompile

We chart the app’s screens, flows, and services, then decompile the APK or IPA to read what shipped inside it.

02

Static & Dynamic

We read the code for secrets and weak crypto, then run the app and watch what it stores, sends, and trusts at runtime.

03

Device & Backend

We test on-device storage and platform controls on rooted and jailbroken hardware, then follow the app to the APIs behind it.

04

Report & Retest

Findings land in Raxis One with proof and a fix as we confirm them. You fix, we verify.

Findings We See in the Wild

Six things we pull out of shipped apps most weeks.

Hardcoded Secrets

Production keys and credentials compiled into the binary, readable by anyone who downloads it.

Insecure Local Storage

Tokens and personal data written to the device in the clear.

No Certificate Pinning

Traffic an attacker on the same network can read and rewrite.

Weak Backend Authorization

The app hides a screen, but the API behind it still answers anyone. IDOR and broken auth.

Trusting a Rooted Device

Client-side checks the app relies on, gone the moment the device is compromised.

Exported Components

Activities, services, and deep links reachable by any other app on the phone.

Two Ways to Test Your App

Same senior engineers, same manual tradecraft, same live findings. The difference is when you want us on it: once, before a release, or every build.

What You Get

Written by the engineer who took the app apart, for the team that has to fix it.

Technical Report

Every finding with proof, reproduction steps, impact, and a fix.

Executive Summary

A board-readable read on the risk and what to do about it.

Live Debrief

Walk the findings with the engineer who did the work.

Included Retest

We verify the fix and issue a clean report, at no extra cost.

A Dangerous Device

Our stories are based on real events encountered by Raxis engineers. Some details have been altered or omitted to protect customer identities.

Our team has tested everything from App Store classics to one-off devices built to a single purpose with proprietary code and specialized hardware. This one was an internal point-of-sale application running on a custom Android-based device.

The device allowed USB debugging. That let our testers attach the Android Debug Bridge and run commands at the operating system level, outside the application’s controls. With a missing critical patch alongside it, the team escalated to root and extracted the application files, then ran whatever they wanted on the device, straight past the app’s locked-down view.

Custody looks like security. Only employees had credentials, and the app handled credit cards and customer personal information. But a malicious employee could point the device at a proxy and intercept every transaction. On site, we also found the devices stored unprotected and out in the open between shifts, free for anyone to alter and quietly return.

FAQ: Mobile Application Penetration Testing

What is mobile application penetration testing?

It is a manual security assessment of an iOS or Android app: the code that ships in the binary, the data it stores on the device, the way it talks to its backend, and what it still does on a rooted or jailbroken phone. It goes well beyond an automated scan to find hardcoded secrets, insecure storage, weak transport security, and backend authorization flaws.

Do you test iOS and Android?

Both. We test on real jailbroken and rooted hardware as well as emulators, because some flaws only appear on a compromised device. If your app ships on both platforms, we test both, since the storage, transport, and platform controls differ between them.

Do you need our source code?

No. We can decompile the APK or IPA and test the app the way an attacker would, from the binary. If you provide source, a white-box test goes deeper and faster. Either works; source is a choice, not a requirement.

Does this include the backend APIs?

A mobile engagement covers the APIs your app directly depends on. For dedicated, in-depth API testing across REST, GraphQL, SOAP, and gRPC, including endpoints not reached through the app, see our API penetration testing service.

Will testing affect the app in the store or our users?

No. We test builds you provide against test or staging backends where possible, and coordinate anything that touches production. We never publish changes to your app or touch real user accounts without your say-so.

How long does a mobile penetration test take?

Most engagements run one to two weeks of active testing, depending on the size of the app, the number of platforms, and the backend surface. Critical findings reach you in real time through Raxis One, and the full report follows within days.

What do you deliver?

A detailed technical report with proof-of-concept evidence and remediation, an executive summary, real-time findings in Raxis One during the engagement, and a retest at no extra charge once you have fixed the issues.

Who performs the testing?

Senior US-based Raxis engineers holding certifications such as OSCP and OSWE. No outsourcing, and no junior testers learning on your app.

Request a quote

Tell Us What You Need Tested

We usually respond in one business day.

Please let us know what's on your mind. Include any details about your target environment, timeline, or compliance drivers.