Home / Attacks & tests / Information Gathering
3 test cases
Information Gathering
Information gathering on iOS starts from a harder position than on Android: the distributed binary is encrypted, so the first task is obtaining a decrypted copy from a device. Once that is done, the binary, its bundle and the system log describe the application and the service behind it.
What an attacker is trying to achieve
The attacker wants what the shipped application knows: the endpoints it calls, the components it embeds, the identifiers it uses and anything the developers left in the bundle. The store encryption is a delay rather than a control, since it is removed by the device at launch.
Test cases
3 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.
IOS-INFO-01 Common Libraries and Fingerprinting
Objective — Establish which third-party frameworks the application embeds and at which versions, since their published defects are inherited by the application.
How it is tested — Recover a decrypted binary from a device and enumerate the linked and embedded frameworks, including those statically linked into the main image. Determine versions from embedded strings, bundle property lists and known symbol differences between releases. Compare against published advisories, and establish whether a vulnerable framework is reachable from the application's own code rather than merely present.
Prerequisites — A decrypted binary; the application bundle; disassembly tooling; advisory data.
Indicators — An embedded framework with a published advisory; a version materially behind current; a statically linked component with no version metadata; a vulnerable framework reachable from application code.
Coverage — MASVS-CODE-3V14.2.1CWE-1395CWE-1104
Depth — Hybrid Inventory automates once the binary is decrypted; obtaining that decrypted copy, and judging reachability, does not.
IOS-INFO-02 Enumeration of Application Controllers
Objective — Establish the application's internal structure and the server endpoints it knows about, including those no interface path reaches.
How it is tested — Dump the class and method structure from the decrypted binary and identify the controllers, their relationships and the entry points registered in the bundle property list — URL schemes, universal link domains, background modes and extensions. Extract endpoint strings from the binary and compare against traffic captured during ordinary use to find endpoints the client knows but never calls.
Prerequisites — A decrypted binary and class-dump tooling; the bundle property list; a proxy capturing traffic from a full pass through the interface.
Indicators — Endpoints referenced but never exercised; URL schemes or link domains registered beyond those documented; debug or internal controllers present in the release build.
Coverage — MASVS-PLATFORM-1MASVS-CODE-1CWE-200CWE-489
Depth — Manual The useful result is the gap between what the binary knows and what the interface uses, which requires both.
IOS-INFO-03 Information Disclosure Through the System Log
Objective — Determine whether the application writes sensitive material to the device log, where it is readable outside the application's own container.
How it is tested — Capture the unified log while driving each workflow that handles credentials, tokens, payment or personal data, including error and retry paths, and search the capture for that material. Establish whether the application uses privacy-preserving log formatting or interpolates values directly, since the default redaction is easily defeated by explicit formatting. Include crash reports and any bundled logging framework.
Prerequisites — A device with unified log access; the release build rather than a development build; an account with recognisable data.
Indicators — Credentials, tokens or personal data in the log; explicit formatting defeating default redaction; a bundled framework logging independently; request bodies in crash reports.
Coverage — MASVS-STORAGE-2MASVS-PRIVACY-1CWE-532CWE-200
Depth — Hybrid Capture and search automate; driving the error paths that log most fully is manual.
What we need from you
A device on which the application can run with elevated privileges, since a decrypted binary must be recovered from memory; disassembly and class-dump tooling; the application bundle including its property lists and assets; and access to the unified log.
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-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-200 — Exposure of Sensitive Information to an Unauthorized Actor
- CWE-489 — Active Debug Code
- 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.