SWD Sniffing on Android: A Comprehensive Guide to Extracting Firmware & Debug Data

Introduction to SWD and Android Reverse Engineering

The Serial Wire Debug (SWD) interface is a two-pin debug port (SWCLK, SWDIO) developed by ARM, offering a low-pin-count alternative to JTAG. It’s a fundamental interface for debugging embedded systems, including the complex System-on-Chips (SoCs) found in Android devices. For hardware reverse engineers and security researchers, SWD presents a golden opportunity to gain deep insights into an Android device’s boot process, firmware, and runtime behavior, often bypassing higher-level software protections.

This guide will demystify SWD sniffing on Android, providing a comprehensive, expert-level walkthrough from identifying test points to extracting valuable debug data and firmware. Understanding and exploiting SWD is a critical skill for anyone looking to perform advanced hardware security analysis on Android platforms.

Why SWD Sniffing? Unlocking Hidden Depths

SWD sniffing isn’t just about curiosity; it’s a powerful technique with several practical applications:

Firmware Extraction: Directly read memory contents, including bootloaders, trusted execution environment (TEE) code, and other sensitive firmware components that might be protected against software-based extraction.
Runtime Debugging & Analysis: Monitor processor state, register values, and memory access patterns in real-time, even when traditional software debuggers are disabled.
Vulnerability Research: Identify potential hardware-level vulnerabilities, analyze proprietary peripheral interactions, or understand undocumented features.
Forensics: Extract critical data from damaged or locked devices by directly accessing memory.

Identifying SWD Pins on Android Devices

Before you can sniff, you need to find the pins. This is often the most challenging step:

1. Physical Inspection and Test Points

Many Android boards, especially development boards or devices with accessible PCBs, feature unpopulated JTAG/SWD headers or exposed test points. Look for:

Unpopulated Headers: Rows of small pads (e.g., 2×5 or 2×10) often labeled JTAG, DEBUG, or similar.
Test Points: Small, unlabeled pads (often circular or square) scattered across the board. SWD lines (SWCLK, SWDIO, GND, VDD/VTref) are commonly found near the main SoC or power management ICs (PMICs).
Silkscreen Markings: Rarely, you might find ‘SWD’, ‘JTAG’, ‘TCK’, ‘TDO’, ‘TDI’, ‘TMS’, ‘TRST’, ‘RTCK’ printed on the PCB.

2. Schematics and Boardviews (If Available)

If you’re fortunate enough to have access to schematics or boardview files for your specific device, they will explicitly label the SWD/JTAG pins. This is the fastest and most reliable method.

3. Continuity Testing and Signal Tracing

Without schematics, you’ll need a multimeter and potentially an oscilloscope:

Identify GND and VCC: Easily found using a multimeter in continuity mode against known ground planes and power rails. SWD pins typically operate at 1.8V or 3.3V.
Trace from SoC: The SWD pins will originate directly from the main application processor (SoC). Use a microscope to identify possible pin groupings around the SoC.
Look for Clocks/Pulses: Connect an oscilloscope to suspected pins. SWCLK will be a periodic clock signal (often between 1-50 MHz) when the debugger is active. SWDIO is a bidirectional data line that will show activity synchronized with SWCLK.

Required Hardware for SWD Sniffing

Logic Analyzer: Essential for capturing the high-speed SWD signals. Recommendations include:
- Saleae Logic Pro 8/16 (professional, high bandwidth)
- DreamSourceLab DSLogic (mid-range, good features)
- Generic inexpensive ‘Saleae clone’ (e.g., 8-channel, 24MHz for basic sniffing, but often limited)
Probes and Wires: Fine-gauge wires and sharp probes (e.g., pogo pins, fine-tipped multimeters probes) for connecting to small test points.
OpenOCD/J-Link Compatible Debugger: While sniffing doesn’t require a debugger actively connected to the target, you might want one for later stages (e.g., flashing, direct memory reads). A basic ST-Link V2/V3 or J-Link EDU Mini can be useful.
Soldering Iron and Supplies: For attaching wires to test points if necessary.

Setting Up the Sniffing Environment

1. Physical Connection

Carefully solder or probe the SWCLK and SWDIO pins on your Android device. Connect them to two input channels of your logic analyzer. Ensure you also connect the logic analyzer’s ground to the Android device’s ground.

Android Device       Logic Analyzer----------------   ----------------SWCLK       ----->   Channel 0 (SWCLK)SWDIO       ----->   Channel 1 (SWDIO)GND         ----->   GND

2. Software Configuration (PulseView Example)

PulseView (part of the sigrok project) is a popular open-source logic analyzer software with excellent protocol decoding capabilities.

Install PulseView: Download and install PulseView from the official sigrok website. Ensure your logic analyzer’s drivers are correctly installed.
Configure Channels: In PulseView, select the correct input channels for SWCLK and SWDIO.
Set Sample Rate: Choose a sample rate significantly higher than the expected SWCLK frequency (e.g., 50 MHz or 100 MHz for a 10 MHz SWCLK). Aim for at least 5-10 times the clock frequency for reliable decoding.
Triggering: Set up a trigger on the SWCLK signal (e.g., rising edge) to capture data efficiently. You might want to capture when the device boots or when you attempt a debug connection.
Enable SWD Decoder: Go to ‘Decoders’ -> ‘Add Decoder’ and select ‘SWD’. Configure it to use your SWCLK and SWDIO channels.

# Example PulseView settings (conceptual)Sampling Rate: 100 MHzTrigger: Channel 0 (SWCLK), rising edgeChannels:  Channel 0: SWCLK  Channel 1: SWDIODecoder: SWD  SWCLK Channel: Channel 0  SWDIO Channel: Channel 1

The SWD Protocol Basics

SWD is a synchronous, half-duplex protocol. Understanding its basic frame structure is crucial for manual analysis, though decoders automate much of this:

SWCLK: The clock signal, always driven by the debugger.
SWDIO: Bidirectional data line. Driven by the debugger for requests, by the target for responses.
Packet Structure: A typical SWD transaction consists of:
- Start Bit: Always ‘1’.
- APnDP: Address for Access Port (AP) or Debug Port (DP) register access.
- RWn: Read (‘1’) or Write (‘0’) operation.
- Addr: 2-bit address for the selected register.
- Parity: Parity bit for APnDP, RWn, and Addr.
- Stop Bit: Always ‘0’.
- Park Bit: Always ‘1’.
- Turnaround: Idle cycles where bus ownership changes.
- ACK: 3-bit acknowledge from the target (OK, WAIT, FAULT).
- Data (32-bit): For read/write operations.
- Parity: Parity bit for data.

The Sniffing and Data Extraction Process

1. Capturing SWD Traffic

With PulseView configured, start capturing data. Power on your Android device. If a debugger (like OpenOCD or J-Link) is attempting to connect, you’ll see a burst of SWD activity. You can also trigger captures during specific actions, like booting the device, which might reveal bootloader-level interactions.

2. Decoding the Protocol

Once you have a capture, the SWD decoder in PulseView will automatically parse the raw bitstream into meaningful transactions (read/write operations, addresses, data, ACKs). This provides a human-readable log of what the debugger (or the target itself, if in SWD mode) is doing.

3. Identifying Memory Accesses

The decoder output will show transactions to specific Debug Port (DP) and Access Port (AP) registers. For firmware extraction, we’re particularly interested in AP transactions, especially those targeting the MEM-AP (Memory Access Port).

Look for sequences like:

DP write to select a specific AP (e.g., MEM-AP).
DP write to configure AP (e.g., TAR – Transfer Address Register).
AP write to TAR with a memory address (e.g., 0x00000000 for bootloader start).
Repeated AP reads from DRW (Data Read/Write Register) to sequentially fetch data.

The extracted data from DRW after a TAR setup and read operations constitutes the firmware or memory dump.

# Example SWD Decoder Output (simplified)0.000000000 SWD DP write: WCR=0x00000000 (JTAG to SWD, reset)0.000001234 SWD DP write: CTRL/STAT=0x50000000 (powerup system)0.000002100 SWD DP read: RDBUFF=0xXXXXXXXX (ACK OK)0.000003500 SWD DP write: SELECT=0x00000000 (select APB-AP 0, Bank 0)0.000004800 SWD AP write: CSW=0x23000042 (configure MEM-AP, 32-bit access, auto-increment)0.000006100 SWD AP write: TAR=0x00000000 (set address to 0x0)0.000007400 SWD AP read: DRW=0xE59FF018 (data from 0x00000000, ACK OK)0.000008700 SWD AP read: DRW=0xE59FF018 (data from 0x00000004, ACK OK)0.000010000 SWD AP read: DRW=0xE3A00000 (data from 0x00000008, ACK OK)... continues for full memory dump

4. Reconstructing Firmware

You’ll need to parse the decoder’s output (often exportable as CSV or text) to collect the 32-bit data words and assemble them into a binary file. Custom Python scripts are excellent for this, filtering for AP DRW reads and concatenating the hex values.

# Pseudo-code for parsing and reconstructing firmwaredata_dump = bytearray()with open('swd_capture.csv', 'r') as f:    for line in f:        if 'SWD AP read: DRW=' in line:            # Extract hex value, e.g., '0xE59FF018'            hex_str = line.split('DRW=')[1].split(' ')[0]            value = int(hex_str, 16)            # Append bytes in little-endian (or big-endian depending on target)            data_dump.extend(value.to_bytes(4, 'little'))with open('firmware_dump.bin', 'wb') as f:    f.write(data_dump)

Advanced Techniques and Considerations

Triggering on Specific Events: Use advanced trigger capabilities of your logic analyzer to capture only when certain conditions are met (e.g., a specific memory address is accessed, or a particular instruction sequence occurs).
Filtering and Search: Many tools allow filtering capture data to focus on specific types of transactions or search for known byte sequences (e.g., magic numbers in bootloaders).
Timing Analysis: Analyze the timing relationships between SWCLK and SWDIO to identify potential glitches, bus contention, or unusual behaviors.
Automated Extraction: For repeated extractions, consider scripting the capture and parsing process using tools like OpenOCD in conjunction with a connected debugger that can actively read memory. While this isn’t strictly

Android Mobile Specs & Compare Directory

Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
Compare Devices Specs →