deardaniel/secdata-raw huggingface dataset:
OWASP Mobile Application Security Testing Guide: MASTG TECH 0025

---
title: Automated Static Analysis
platform: android
---

You should use tools for efficient static analysis. They allow the tester to focus on the more complicated business logic. A plethora of static code analyzers are available, ranging from open source scanners to full-blown enterprise-ready scanners. The best tool for the job depends on budget, client requirements, and the tester's preferences.

Some static analyzers rely on the availability of the source code; others take the compiled APK as input.
Keep in mind that static analyzers may not be able to find all problems by themselves, even though they can help us focus on potential problems. Review each finding carefully and try to understand what the app is doing to improve your chances of finding vulnerabilities.

Configure the static analyzer properly to reduce the likelihood of false positives, and maybe only select several vulnerability categories in the scan. The results generated by static analyzers can otherwise be overwhelming, and your efforts can be counterproductive if you must manually investigate a large report.

There are several open source tools for automated security analysis of an APK.

- [Androbugs](https://github.com/AndroBugs/AndroBugs_Framework "Androbugs")
- [JAADAS](https://github.com/flankerhqd/JAADAS "JAADAS") (archived)
- @MASTG-TOOL-0035
- [QARK](https://github.com/linkedin/qark/ "QARK")
OWASP Mobile Application Security Testing Guide: MASTG TECH 0040

---
title: Waiting for the Debugger
platform: android
---

The @MASTG-APP-0003 is not stupid: it notices that it has been run in debuggable mode and reacts by shutting down. A modal dialog is shown immediately, and the crackme terminates once you tap "OK".

Fortunately, Android's "Developer options" contain the useful "Wait for Debugger" feature, which allows you to automatically suspend an app during startup until a JDWP debugger connects. With this feature, you can connect the debugger before the detection mechanism runs, and trace, debug, and deactivate that mechanism. It's really an unfair advantage, but, on the other hand, reverse engineers never play fair!

<img src="Images/Chapters/0x05c/debugger_detection.png" width="400px" />

In the Developer options, pick `Uncrackable1` as the debugging application and activate the "Wait for Debugger" switch.

<img src="Images/Chapters/0x05c/developer-options.png" width="400px" />

Note: Even with `ro.debuggable` set to "1" in `default.prop`, an app won't show up in the "debug app" list unless the `android:debuggable` flag is set to `"true"` in the Android Manifest.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0016

---
title: Disassembling Code to Smali
platform: android
---

If you want to inspect the app's smali code (instead of Java), you can [open your APK in Android Studio](https://developer.android.com/studio/debug/apk-debugger "Debug pre-built APKs") by clicking **Profile or debug APK** from the "Welcome screen" (even if you don't intend to debug it you can take a look at the smali code).

Alternatively you can use @MASTG-TOOL-0011 to extract and disassemble resources directly from the APK archive and disassemble Java bytecode to smali. apktool allows you to reassemble the package, which is useful for @MASTG-TECH-0038 the app or applying changes to e.g. the Android Manifest.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0030

---
title: Sandbox Inspection
platform: android
---

The application data is stored in a sandboxed directory present at `/data/data/<app_package_name>`. The content of this directory has already been discussed in detail in @MASTG-TECH-0008.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0129

---
title: Verifying Android Dependencies at Runtime
platform: android
---

> The preferred techniques for analyzing dependencies are @MASTG-TECH-0131 and @MASTG-TECH-0130. This technique, which is described here, should only be used in a black-box environment because it is manual and cannot easily be automated.

When analyzing an application, it's important to analyze its dependencies, which are usually in the form of libraries, and ensure that they don't contain any known vulnerabilities. If the source code is unavailable, you can decompile the application and check the JAR files. If @MASTG-TOOL-0022 or other obfuscation tools are used properly, the version information about the library is often obfuscated. Otherwise, this information may still be found in the comments of the Java files of the given libraries. Tools such as @MASTG-TOOL-0130 can help analyze the possible libraries packaged with the application. If you can determine the library's version, either from the comments or from specific methods used in certain versions, you can manually search for CVEs.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0051

---
title: Tampering and Runtime Instrumentation
platform: generic
---

First, we'll look at some simple ways to modify and instrument mobile apps. _Tampering_ means making patches or runtime changes to the app to affect its behavior. For example, you may want to deactivate SSL pinning or binary protections that hinder the testing process. _Runtime Instrumentation_ encompasses adding hooks and runtime patches to observe the app's behavior. In mobile application security however, the term loosely refers to all kinds of runtime manipulation, including overriding methods to change behavior.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0048

---
title: Static Analysis
platform: generic
---

For white-box source code testing, you'll need a setup similar to the developer's setup, including a test environment that includes the Android SDK and an IDE. Access to either a physical device or an emulator (for debugging the app) is recommended.

During **black-box testing**, you won't have access to the original form of the source code. You'll usually have the application package in [Android's APK format](https://en.wikipedia.org/wiki/Apk_(file_format) "APK file format"), which can be installed on an Android device or reverse engineered as explained in @MASTG-TECH-0017.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0050

---
title: Binary Analysis
platform: generic
---

Binary analysis frameworks give you powerful ways to automate tasks that would be almost impossible to do manually. Binary analysis frameworks typically use a technique called symbolic execution, which allow to determine the conditions necessary to reach a specific target. It translates the program's semantics into a logical formula in which some variables are represented by symbols with specific constraints. By resolving the constraints, you can find the conditions necessary for the execution of some branch of the program.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0121

---
title: Intercepting Non-HTTP Traffic Using an Interception Proxy
platform: generic
---

Interception proxies such as @MASTG-TOOL-0077 and @MASTG-TOOL-0079 won't show non-HTTP traffic, because they aren't capable of decoding it properly by default. They can, however, be extended using the following tools, allowing you to intercept and manipulate non-HTTP traffic:

- [Burp-non-HTTP-Extension](https://github.com/summitt/Burp-Non-HTTP-Extension "Burp-non-HTTP-Extension") and
- [Mitm-relay](https://github.com/jrmdev/mitm_relay "Mitm-relay").

Note that this setup can sometimes become very tedious and is not as straightforward as testing HTTP.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0119

---
title: Intercepting HTTP Traffic by Hooking Network APIs at the Application Layer
platform: generic
---

Depending on your goal while testing the app, sometimes it is enough to monitor the traffic before it reaches the network layer or when the responses are received in the app.

This means that you don't need to deploy a fully fledged MITM attack (including ARP Spoofing attacks, etc.) if you simply want to determine if certain sensitive data is being transmitted to the network. With this approach, you will not interfere with any TLS verification or pinning.

You can use [Frida as an alternative](https://gaiaslastlaugh.medium.com/frida-as-an-alternative-to-network-tracing-5173cfbd7a0b)

This technique is also useful for:

- Intercepting traffic in apps that use custom network stacks.
- Intercepting traffic in apps built with specific cross-platform frameworks such as Flutter.
    - Android: @MASTG-TECH-0109
    - iOS: @MASTG-TECH-0110
- Intercepting other types of traffic such as BLE, NFC, etc., where deploying a MITM attack might be very costly and complex.
- Analyzing protocols like MQTT and CoAP, which may require more specialized interception techniques.
- Monitoring WebSocket traffic, which can also necessitate unique interception strategies.

You just have to hook the right functions, e.g., `SSL_write` and `SSL_read` from OpenSSL.

This would work pretty well for apps using standard API library functions and classes; however, there might be some downsides:

- The app might implement a custom network stack and you'll have to spend time analyzing the app to find out the APIs that you can use. See section "Searching for OpenSSL traces with signature analysis" in [this blog post](https://web.archive.org/web/[PII_REDACTED]1718/https://hackmag.com/security/ssl-sniffing/ "Searching for OpenSSL traces with signature analysis").
- It might be very time consuming to craft the right hooking scripts to re-assemble HTTP response pairs (across many method calls and execution threads). You might find [ready-made scripts](https://github.com/fanxs-t/Android-SSL_read-write-Hook/blob/master/frida-hook.py) and even for [alternative network stacks](https://codeshare.frida.re/@owen800q/okhttp3-interceptor/), but depending on the app and the platform, these scripts might need a lot of maintenance and might not _always work_.

See some examples:

- ["Universal interception. How to bypass SSL Pinning and monitor traffic of any application"](https://web.archive.org/web/[PII_REDACTED]1718/https://hackmag.com/security/ssl-sniffing/), sections "Grabbing payload prior to transmission" and "Grabbing payload prior to encryption"
- ["Frida as an Alternative to Network Tracing"](https://gaiaslastlaugh.medium.com/frida-as-an-alternative-to-network-tracing-5173cfbd7a0b)
OWASP Mobile Application Security Testing Guide: MASTG TECH 0122

---
title: Passive Eavesdropping
platform: generic
---

This method involves passively capturing network traffic using tools such as @MASTG-TOOL-0081, @MASTG-TOOL-0080, or @MASTG-TOOL-0075. It is useful for identifying network endpoints, analyzing protocol metadata, and understanding how an app communicates with its server. However, it cannot automatically decrypt TLS-encrypted communication. That said, [TLS decryption is possible](https://wiki.wireshark.org/TLS#tls-decryption) if you can [obtain the pre-master secret](https://wiki.wireshark.org/TLS#using-the-pre-master-secret). For an example specific to Android, see [this article](https://nibarius.github.io/learning-frida/2022/05/21/sniffing-tls-traffic).

## When Is it Useful?

Passive eavesdropping is particularly useful in the following scenarios:

- **Troubleshooting active MITM issues**: Identifying TLS handshake errors, certificate validation failures, and routing anomalies that may cause active interception techniques to fail.
- **Analyzing plaintext non-HTTP traffic**: Monitoring protocols such as XMPP, MQTT, DNS, SMB, and custom UDP/TCP protocols used by the app. Also useful for analyzing push notification traffic from services like Google Cloud Messaging (GCM) / Firebase Cloud Messaging (FCM) on Android or Apple Push Notification Service (APNS) on iOS.
- **Analyzing traffic from non-proxy-aware apps**: Some mobile apps ignore system proxy settings or actively detect and block interception proxies.
- **Investigating network anomalies and unintended data leaks**: Passive monitoring can help detect unexpected third-party communication, data leakage via DNS requests, or unusual outbound connections. Additionally, even if TLS encryption prevents direct payload inspection, metadata leaks (e.g., request size, timing patterns, domain names, or packet sequences) can still provide valuable insights and may be useful for side-channel attacks.

## How Does It Work?

Passive eavesdropping can be performed in two ways:

1. **Directly on a rooted Android or jailbroken iOS device**
   If the device is rooted (Android) or jailbroken (iOS), you can capture network traffic directly using `tcpdump` or similar tools, without needing a host computer. This allows you to monitor all outgoing and incoming packets in real time.

2. **By routing traffic through a host computer (works on both rooted/jailbroken and non-rooted/non-jailbroken devices)**
   If direct packet capture on the device is not possible or preferred, you can route its network traffic to a host computer and analyze it using tools like @MASTG-TOOL-0081 or @MASTG-TOOL-0075. This method applies to **both rooted/jailbroken and non-rooted/non-jailbroken devices** and is typically achieved through:
   - **Using an interception proxy** to intercept and analyze HTTP/S traffic.
   - **Setting up a VPN-based capture** to redirect traffic through a controlled network tunnel.
   - **Performing ARP spoofing or setting up a transparent network tap** on a Wi-Fi network.

## Per-Platform Instructions

- **Android:** @MASTG-TECH-0010
- **iOS:** @MASTG-TECH-0062
OWASP Mobile Application Security Testing Guide: MASTG TECH 0120

---
title: Intercepting HTTP Traffic Using an Interception Proxy
platform: generic
---

Interception proxies are the most common method for intercepting mobile app traffic. They work by setting up a proxy server that intercepts and logs all HTTP/HTTPS traffic between the mobile app and the server. This allows you to view and modify the requests and responses in real-time.

Several free and commercial proxy tools are available. For example: @MASTG-TOOL-0097, @MASTG-TOOL-0077 and @MASTG-TOOL-0079.

## Rerouting Traffic to the Proxy

To use the interception proxy, you'll need to run it on your host computer and configure the mobile app to route HTTP(S) requests to your proxy. In most cases, it is enough to set a system-wide proxy in the network settings of the mobile device - if the app uses standard HTTP APIs or popular libraries such as `okhttp`, it will automatically use the system settings.

<img src="Images/Chapters/0x04f/BURP.png" width="100%" />

## Installing the Proxy Certificate

Using an interception proxy breaks SSL certificate verification and the app will usually fail to initiate TLS connections. Because of this, interception proxies require you to install a custom CA certificate on the mobile device, which allows the proxy to decrypt and inspect the encrypted HTTPS traffic. Depending on the platform, the installed certificate may or may not be automatically trusted by the application. Additionally, some apps implement certificate pinning, which requires additional effort to bypass.

## Per-Platform Instructions

- Android: see @MASTG-TECH-0011
- iOS: see @MASTG-TECH-0063
OWASP Mobile Application Security Testing Guide: MASTG TECH 0049

---
title: Dynamic Analysis
platform: generic
---

Dynamic Analysis tests the mobile app by executing and running the app binary and analyzing its workflows for vulnerabilities. For example, vulnerabilities regarding data storage might be sometimes hard to catch during static analysis, but in dynamic analysis you can easily spot what information is stored persistently and if the information is protected properly. Besides this, dynamic analysis allows the tester to properly identify:

- Business logic flaws
- Vulnerabilities in the tested environments
- Improper input validation and bad input/output encoding as they are processed through one or multiple services

Analysis can be assisted by automated tools, such as @MASTG-TOOL-0035, while assessing an application. An application can be assessed by side-loading it, re-packaging it, or by simply attacking the installed version.

## Basic Information Gathering

As mentioned previously, Android runs on top of a modified Linux kernel and retains the [proc filesystem](https://www.kernel.org/doc/Documentation/filesystems/proc.txt "procfs") (procfs) from Linux, which is mounted at `/proc`. Procfs provides a directory-based view of a process running on the system, providing detailed information about the process itself, its threads, and other system-wide diagnostics. Procfs is arguably one of the most important filesystems on Android, where many OS native tools depend on it as their source of information.

Many command line tools are not shipped with the Android firmware to reduce the size, but can be easily installed on a rooted device using @MASTG-TOOL-0013. We can also create our own custom scripts using commands like `cut`, `grep`, `sort` etc, to parse the proc filesystem information.

In this section, we will be using information from procfs directly or indirectly to gather information about a running process.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0123

---
title: Achieving a MITM Position via ARP Spoofing
platform: generic
---

When proxy-based interception fails due to non-HTTP protocols or non-proxy-aware apps, **ARP Spoofing** can be used to redirect network traffic. ARP Spoofing is a **Layer 2 attack** that allows an attacker to impersonate the network gateway, forcing the mobile device to send its traffic through the attacker's machine.

This technique works against any device and operating system as the attack is executed on OSI Layer 2. When you are MITM, you might not be able to see clear text data, as the data in transit might be encrypted by TLS, but it will give you valuable information about the hosts involved, the protocols used, and the ports the app is communicating with.

To execute an ARP Spoofing attack, you can use @MASTG-TOOL-0076.

> **Important:** Modern operating systems implement defenses such as encrypted DNS (DoH, DoT), MAC address randomization, and ARP spoofing detection, making this technique less effective on newer devices.

## Network Setup

To achieve a [Machine-in-the-Middle (MITM)](../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) position, your host computer must be on the same wireless network as the mobile device and the gateway it communicates with. Once this is set up, you need to obtain the IP address of the mobile device. For a complete dynamic analysis of a mobile app, all network traffic should be intercepted and analyzed.

## MITM Attack

Start your preferred network analyzer tool first, then start @MASTG-TOOL-0076 with the following command and replace the IP address below (X.X.X.X) with the target you want to execute the MITM attack against.

```bash
$ sudo bettercap -eval "set arp.spoof.targets X.X.X.X; arp.spoof on; set arp.spoof.internal true; set arp.spoof.fullduplex true;"
bettercap v2.22 (built for darwin amd64 with go1.12.1) [type 'help' for a list of commands]

[19:21:39] [sys.log] [inf] arp.spoof enabling forwarding
[19:21:39] [sys.log] [inf] arp.spoof arp spoofer started, probing 1 targets.
```

bettercap will then automatically send the packets to the network gateway in the (wireless) network and you are able to sniff the traffic. Beginning of 2019 support for [full duplex ARP spoofing](https://github.com/bettercap/bettercap/issues/426 "Full Duplex ARP Spoofing") was added to bettercap.

On the mobile phone start the browser and navigate to `http://example.com`, you should see output like the following when you are using Wireshark.

<img src="Images/Chapters/0x04f/bettercap.png" width="100%" />

If that's the case, you are now able to see the complete network traffic that is sent and received by the mobile phone. This includes also DNS, DHCP and any other form of communication and can therefore be quite "noisy". You should therefore know how to use [DisplayFilters in Wireshark](https://wiki.wireshark.org/DisplayFilters "DisplayFilters") or know [how to filter in tcpdump](https://danielmiessler.com/study/tcpdump/#gs.OVQjKbk "A tcpdump Tutorial and Primer with Examples") to focus only on the relevant traffic for you.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0047

---
title: Reverse Engineering
platform: generic
---

Reverse engineering is the process of taking an app apart to find out how it works. You can do this by examining the compiled app (static analysis), observing the app during runtime (dynamic analysis), or a combination of both.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0067

---
title: Dynamic Analysis on iOS
platform: ios
---

Jailbreaking a device simplifies many aspects of dynamic analysis. It provides privileged access and removes code signing restrictions, enabling the use of more powerful tools and techniques. On iOS, most dynamic analysis tools are based on @MASTG-TOOL-0139, a framework for developing runtime patches, or @MASTG-TOOL-0039, a dynamic introspection tool. For basic API monitoring, you can get away with not knowing all the details of how ElleKit or Frida work - you can use existing API monitoring tools.

On iOS, collecting basic information about a running process or an application can be slightly more challenging than on Android. On Android (or any Linux-based OS), process information is exposed as readable text files via [_proc filesystem_ (procfs)](https://en.wikipedia.org/wiki/Procfs). Thus, any information about a target process can be obtained on a rooted device by parsing these text files. In contrast, on iOS, there is no procfs equivalent present. Also, on iOS, many standard UNIX command-line tools for exploring process information, such as lsof and vmmap, are removed to reduce firmware size.

Since many of these tools are not present on iOS by default, we need to install them via alternative methods. For instance, lsof can be installed using @MASTG-TOOL-0047 (the executable is not the latest version, but it nevertheless addresses our purpose).
OWASP Mobile Application Security Testing Guide: MASTG TECH 0086

---
title: Method Tracing
platform: ios
---

Intercepting Objective-C methods is a useful iOS security testing technique. For example, you may be interested in data storage operations or network requests. In the following example, we'll write a simple tracer to log HTTP(S) requests made via iOS's standard HTTP APIs. We'll also show you how to inject the tracer into Safari.

In the following examples, we'll assume that you are working on a jailbroken device. If that's not the case, you first need to follow the steps outlined in @MASTG-TECH-0090 to repackage the Safari app with the Frida Gadget.

Frida comes with `frida-trace`, a function tracing tool. `frida-trace` accepts Objective-C methods via the `-m` flag. You can pass it wildcards as well-given `-[NSURL *]`, for example, `frida-trace` will automatically install hooks on all `NSURL` class selectors. We'll use this to get a rough idea about which library functions Safari calls when the user opens a URL.

For detailed tutorials on using frida-trace on iOS, see the [frida-trace section in the Frida Handbook](https://learnfrida.info/basic_usage/#frida-trace).

Run Safari on the device and make sure the device is connected via USB. Then start `frida-trace` as follows:

```bash
$ frida-trace -U -m "-[NSURL *]" Safari
Instrumenting functions...
-[NSURL isMusicStoreURL]: Loaded handler at "/Users/berndt/Desktop/__handlers__/__NSURL_isMusicStoreURL_.js"
-[NSURL isAppStoreURL]: Loaded handler at "/Users/berndt/Desktop/__handlers__/__NSURL_isAppStoreURL_.js"
(...)
Started tracing 248 functions. Press Ctrl+C to stop.
```

Next, navigate to a new website in Safari. You should see traced function calls on the `frida-trace` console. Note that the `initWithURL:` method is called to initialize a new URL request object.

```bash
           /* TID 0xc07 */
  20313 ms  -[NSURLRequest _initWithCFURLRequest:0x1043bca30 ]
 20313 ms  -[NSURLRequest URL]
(...)
 21324 ms  -[NSURLRequest initWithURL:0x106388b00 ]
 21324 ms     | -[NSURLRequest initWithURL:0x106388b00 cachePolicy:0x0 timeoutInterval:0x106388b80
```