Hands-On: Mobile Traffic Interception

A Hands-On Guide to SSL Unpinning

I've extracted more valuable data from mobile apps in the last year than from traditional web scraping in the previous five years combined. The reason is simple: mobile apps often provide cleaner, more direct access to the same data that websites protect heavily.

But there's a catch. Modern mobile apps implement SSL certificate pinning specifically to prevent traffic interception. This guide shows you how to bypass these protections and analyze mobile app communications.

Why Intercept Mobile Traffic?

The API Advantage

Most mobile apps communicate with backend servers through clean JSON APIs. While websites load data through complex JavaScript and HTML rendering, mobile apps make direct HTTP requests that you can analyze and replicate.

Real Example: A major e-commerce website requires JavaScript execution, CAPTCHA solving, and complex session management. Their mobile app? Simple JSON API calls with bearer token authentication and a 500 requests/hour rate limit instead of 50.

Discover Hidden Endpoints

Mobile apps often use internal API endpoints not available through public web interfaces. These endpoints typically have:

• Better structured data formats

• Higher rate limits designed for mobile usage patterns

• Simpler authentication mechanisms

• Less sophisticated bot detection

Bypass Web Protection

While websites implement complex bot detection, mobile APIs rely on different security models. Certificate pinning and request signing replace browser-based detection, but once bypassed, the APIs are often more permissive than their web counterparts.

What is SSL Certificate Pinning?

SSL certificate pinning is a security technique where mobile apps refuse to trust certificates that don't match a pre-configured set of "pinned" certificates or public keys.

How Normal SSL Works

In standard HTTPS:

1. Your device connects to a server

2. Server presents its SSL certificate

3. Device validates certificate against trusted Certificate Authorities (CAs)

4. If valid, encrypted connection is established

How Certificate Pinning Works

With pinning:

1. App contains hardcoded certificate fingerprints or public keys

2. During connection, app checks server certificate against pinned values

3. If certificate doesn't match exactly, connection is rejected

4. This happens even if certificate is valid according to standard CA validation

Why Apps Use Pinning: Prevents man-in-the-middle attacks, including legitimate traffic analysis tools like mitmproxy. Even if you install a custom CA certificate on your device, pinned apps will reject connections routed through your proxy.

Types of Pinning

Certificate Pinning: App pins the entire certificate

• More restrictive but breaks when certificates are renewed

• Easier to implement but requires app updates for certificate changes

Public Key Pinning: App pins only the public key portion

• More flexible, survives certificate renewals if same key is used

• More complex to implement correctly

Certificate Authority Pinning: App pins the CA that issued the certificate

• Most flexible but provides least security

• Rare in mobile applications

What is SSL Unpinning?

SSL unpinning is the process of disabling certificate pinning validation in mobile apps, allowing traffic to be intercepted and analyzed through proxy tools.

How Unpinning Works

Runtime Modification: Use dynamic instrumentation tools (like Frida) to modify app behavior while it's running:

1. Identify pinning validation functions in the app

2. Hook these functions at runtime

3. Force them to return "valid" regardless of actual certificate

4. App continues normal operation but accepts proxy certificates

Static Modification: Modify the app's code before installation:

1. Decompile the APK file

2. Remove or modify pinning validation code

3. Recompile and re-sign the app

4. Install modified version

System-Level Bypasses: Modify the Android system itself:

1. Custom ROMs with pinning disabled

2. Xposed modules that hook system SSL functions

3. Magisk modules for rooted devices

We'll focus on runtime modification with Frida because it's the most flexible and doesn't require app modification.

Common Pinning Implementations

OkHttp CertificatePinner (most common):

CertificatePinner.Builder()
    .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
    .build();

TrustManagerImpl (Android system level):

TrustManagerImpl.verifyChain(chain, authType, host, ...);

Custom Implementations:

• Apps may implement their own certificate validation

• Can include additional checks beyond standard pinning

• May validate multiple certificate properties

Setting Up Your Environment

Required Hardware

Android Device: Physical device preferred for realistic behavior

• Android 7-11 work best (newer versions have stronger protections)

• Root access required for system certificate installation

• USB debugging enabled

Essential Software

Analysis Machine (Windows/Mac/Linux):

• mitmproxy for traffic interception

• Frida for runtime manipulation

• Android Debug Bridge (ADB)

• Text editor for script modification

Android Device:

• Frida server (architecture-specific binary)

• mitmproxy CA certificate

• Target applications to analyze

Installation Process

Install mitmproxy:

pip install mitmproxy

Install Frida:

pip install frida-tools

Setup Android device:

# Enable developer options and USB debugging
# Root device using appropriate method for your model

# Install Frida server ( download from github https://github.com/frida/frida/releases search for server)
adb push frida-server /data/local/tmp/
adb shell "chmod 755 /data/local/tmp/frida-server"
adb shell "/data/local/tmp/frida-server &"

Get app package name:

# List all installed packages
adb shell pm list packages

# Find specific app (example: Instagram)
adb shell pm list packages | grep instagram

# Get package name of currently running app
adb shell dumpsys window | grep mCurrentFocus

Execute Frida SSL bypass script:

# Start app with Frida script injection
frida -U -f com.target.app -l ssl_bypass.js --no-pause

# Or attach to already running app
frida -U com.target.app -l ssl_bypass.js

# List running apps to find package name
frida-ps -U

Configure network proxy:

1. Start mitmproxy web interface: mitmweb --web-host 0.0.0.0
or mitproxy cli: mitmproxy

2. Connect Android to same WiFi network

3. Set manual proxy: your computer's IP, port 8080

4. Install mitmproxy certificate on Android device

Verification

Test basic interception:

1. Open browser on Android device

2. Visit any HTTP website

3. Check mitmproxy web interface at

http://localhost:8081

1. Traffic should appear in the request list

Test HTTPS without pinning:

1. Visit any HTTPS website in browser

2. Traffic should appear after certificate installation

3. If not visible, certificate installation failed

Test pinning detection:

1. Open a secure app

2. HTTPS traffic from app should NOT appear in mitmproxy

3. This confirms pinning is active and needs bypassing

What to Look For During Analysis

Authentication Patterns

Token-Based Authentication:

• Look for Authorization: Bearer <token> headers

• JWT tokens contain user information (decode to understand structure)

• Note token expiration times and refresh mechanisms

• Document token acquisition flow (usually login endpoint)

API Key Authentication:

• Custom headers like X-API-Key, X-Auth-Token

• Sometimes embedded in URL parameters

• May be combined with HMAC signatures for request validation

• Often static and reusable across sessions

Session-Based Authentication:

• Traditional cookies or custom session headers

• Less common in mobile apps but still used

• May require maintaining session state between requests

API Endpoint Structure

Base URL Patterns:

• api.company.com/mobile/v2/

• mobile-api.service.com/v1/

• app.company.com/api/3.0/

Endpoint Naming Conventions:

• RESTful: /users/{id}, /products?category=electronics

• RPC-style: /getUserProfile, /searchProducts

• GraphQL: Single endpoint with query parameters

Versioning Strategies:

• URL path: /v1/, /v2.1/, /api/3.0/

• Header-based: API-Version: 2.0

• Parameter-based: ?version=1.2

Request/Response Formats

Data Structures:

• JSON (most common): Clean, predictable structure

• XML: Older apps, more verbose

• Protocol Buffers: Binary format, more efficient but harder to analyze

• Custom formats: Base64-encoded or encrypted payloads

Pagination Patterns:

• Offset-based: ?offset=20&limit=10

• Cursor-based: ?cursor=abc123&limit=10

• Page-based: ?page=3&per_page=20

Rate Limiting and Quotas

Rate Limit Headers:

• X-RateLimit-Limit: Maximum requests allowed

• X-RateLimit-Remaining: Requests left in current window

• X-RateLimit-Reset: When limit resets (timestamp)

Quota Information:

• Daily/monthly limits often in response headers

• May be user-specific or API key-specific

• Premium vs free tier limitations

Security Mechanisms

Request Signing:

• HMAC signatures in headers

• Timestamp-based nonces to prevent replay attacks

• Custom signature algorithms (may require reverse engineering)

Encryption:

• End-to-end encrypted payloads

• Custom encryption schemes

• Key exchange mechanisms

Device Fingerprinting:

• Device ID headers

• Hardware-specific identifiers

• App version and OS information

Error Handling

HTTP Status Codes:

• 200: Success

• 401: Authentication failure

• 403: Forbidden (rate limited or blocked)

• 429: Too many requests

• 500: Server error

Custom Error Formats:

• Structured error responses with codes and messages

• Localized error messages

• Debug information (in development builds)

Data Quality Indicators

Completeness:

• Which fields are always present vs optional

• Null value handling

• Default values and placeholders

Consistency:

• Data format consistency across endpoints

• Timestamp formats and timezones

• Numeric precision and units

Freshness:

• Last updated timestamps

• Cache headers and expiration

• Real-time vs cached data indicators

Documentation Strategy

As you analyze traffic, document:

• API Endpoints: URL patterns, HTTP methods, parameters

• Authentication: Token types, acquisition methods, expiration

• Rate Limits: Requests per hour/day, detection patterns

• Data Schemas: Request/response structures, field types

• Error Patterns: Common failures and retry strategies

This documentation becomes the foundation for building automated clients that can replicate the mobile app's API calls programmatically.

---

Thanks to Evomi for sponsoring this post. Check out their residential proxy service starting at $0.49/GB if you're looking for reliable data collection solutions.

---

The Bottom Line

Mobile traffic interception reveals the clean APIs that power mobile applications. While SSL pinning initially blocks analysis, runtime unpinning with Frida opens these communications for inspection.

The goal isn't just to see the traffic—it's to understand the API patterns well enough to build your own clients that can access the same data programmatically. Once you can replicate a mobile app's API calls, you often have cleaner, more reliable data access than traditional web scraping provides.

The key is patience and systematic analysis. Start with simpler apps to build your skills, then tackle more complex targets as you understand the common patterns and protection mechanisms.