Home / Attacks & tests / Information Gathering Testing for Mobile Applications
4 test cases
Information Gathering Testing for Mobile Applications
Information gathering on Android begins with the fact that the application package is in the tester's possession. Unlike a web application, the client is fully available for inspection, so the question is not what can be discovered remotely but what the shipped artefact reveals about the system behind it.
What an attacker is trying to achieve
The attacker downloads the same package every user does and reads it. They want the endpoints, the keys, the hidden features and the libraries with published defects — all of which are in the file, and none of which requires touching the server until the attacker already knows where to aim.
Test cases
4 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
AND-INFO-01 Reverse Engineering the Application Code
Objective — Determine what the shipped package discloses when decompiled: endpoints, credentials, algorithms, unreleased features, and the logic the application relies on remaining unread.
How it is tested — Unpack the package and decompile the bytecode and any bundled native libraries. Review the manifest for components, permissions and configuration. Search the recovered source and resources for endpoints, keys, credentials and feature flags. Establish whether obfuscation is applied, and whether it is applied to the parts that matter rather than only to library code. Identify security decisions taken in the client that the server does not repeat.
Prerequisites — The distributed package; decompilation tooling; where the application ships native code, a disassembler.
Indicators — Credentials, keys or endpoints recoverable from the package; no or cosmetic obfuscation; an authorisation or licensing decision taken purely in the client; unreleased functionality present in the build.
Coverage — MASVS-RESILIENCE-3MASVS-STORAGE-1CWE-798CWE-656
Depth — Hybrid Decompilation and secret scanning are automated; judging which recovered logic is security-relevant is not.
AND-INFO-02 Common Libraries and Fingerprinting
Objective — Establish which third-party components the application ships and at which versions, since their published defects become the application's.
How it is tested — Enumerate bundled libraries from package structure, class names, native objects and any dependency metadata retained in the build. Determine the version of each from embedded strings, resource fingerprints and known structural differences between releases. Compare against published advisories. Establish whether a vulnerable component is merely present or actually reachable from the application's own code paths.
Prerequisites — The decompiled package; access to advisory data; the dependency manifest where the build retains one.
Indicators — A bundled component with a published advisory; a version materially behind current; several versions of one library shipped together; a vulnerable component reachable from application code.
Coverage — MASVS-CODE-3V14.2.1CWE-1395CWE-1104
Depth — Hybrid Inventory and advisory matching automate well; establishing reachability requires reading the call paths.
AND-INFO-03 Enumeration of Application Controllers
Objective — Establish the full set of application components and the server endpoints the client knows about, including those no interface path reaches.
How it is tested — Extract the declared components from the manifest and the endpoint set from decompiled code and resources. Compare against traffic captured during ordinary use to identify endpoints the client knows but never calls in normal operation. Identify components reachable from outside the application and the conditions each expects. Record which endpoints are gated by client-side checks only.
Prerequisites — The decompiled package; a proxy capturing traffic from ordinary use; a device on which every interface path can be exercised.
Indicators — Endpoints referenced in the client but never exercised; components exported without an evident need; administrative or debug endpoints present in the release build.
Coverage — MASVS-PLATFORM-1MASVS-CODE-1CWE-926CWE-200
Depth — Manual The valuable result is the difference between what the client knows and what it uses, which requires both halves.
AND-INFO-04 Information Disclosure Through Logcat
Objective — Determine whether the application writes sensitive material to the system log, where it is readable beyond the application's own boundary.
How it is tested — Exercise every workflow — authentication, payment, personal data entry, error paths — while capturing the system log, and search the capture for credentials, tokens, personal data and internal detail. Establish whether logging differs between debug and release builds, and whether any logging framework the application bundles writes independently of the platform log. Include crash and exception paths, which log most verbosely.
Prerequisites — A device or emulator with log access; the release build rather than a debug build; an account whose data can be used in the workflows.
Indicators — Credentials, tokens or personal data in the log; verbose logging left enabled in a release build; a bundled framework logging independently; stack traces carrying request content.
Coverage — MASVS-STORAGE-2MASVS-PRIVACY-1CWE-532CWE-200
Depth — Hybrid Log capture and pattern searching automate; driving every workflow including the error paths is manual.
What we need from you
The application package as distributed; a device or emulator on which it can be installed and run, ideally with elevated privileges; static analysis and decompilation tooling; and a channel for retrieving device logs.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- MASVS-RESILIENCE-3 — The app implements anti-static analysis mechanisms.
- MASVS-STORAGE-1 — The app securely stores sensitive data.
- CWE-798 — Use of Hard-coded Credentials
- CWE-656 — Reliance on Security Through Obscurity
- MASVS-CODE-3 — The app only uses software components without known vulnerabilities.
- V14.2.1 — Verify that all components are up to date, preferably using a dependency checker during build or compile time.
- CWE-1395 — Dependency on Vulnerable Third-Party Component
- CWE-1104 — Use of Unmaintained Third Party Components
- MASVS-PLATFORM-1 — The app uses IPC mechanisms securely.
- MASVS-CODE-1 — The app requires an up-to-date platform version.
- CWE-926 — Improper Export of Android Application Components
- CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor
- MASVS-STORAGE-2 — The app prevents leakage of sensitive data.
- MASVS-PRIVACY-1 — The app minimizes access to sensitive data and resources.
- CWE-532 — Insertion of Sensitive Information into Log File
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.