R&D

Debug Interface: Flash Memory Dump Using SWD

한국어로 읽기 →
Contents
  1. 1☑️ Overview
  2. 2Differences Between General Software Debugging and IoT/Embedded Debugging
  3. 3The Importance of Debug Interface in IoT and Embedded Systems
  4. 4☑️ IoT and Embedded Debug Interface - JTAG, SWD
  5. 5JTAG(Joint Test Action Group)
  6. 6SWD
  7. 7J-link
  8. 8☑️ Main Flash Dump Using J-Link SWD
  9. 9Hardware Connection
  10. 10Installing and Using J-Link Software - for Windows
  11. 11Installing and Using J-Link Software - for Linux
  12. 12Main Flash Dump
  13. 13☑️ Closing Remarks

☑️ Overview

In software development, debugging is a crucial process that allows developers to analyze program behavior, troubleshoot issues, and ultimately create stable products. Typically, software debugging is performed within an IDE (Integrated Development Environment), where developers can execute source code step-by-step, check variable values, and output logs to identify errors.

For instance, when developing desktop applications, tools like Visual Studio or Eclipse let you set breakpoints and run code line by line, allowing you to inspect variables and memory states. This process primarily occurs at the software level, focusing on ensuring that the source code functions correctly.

However, in the realm of IoT and embedded devices, relying solely on software debugging has its limitations. This is because firmware directly controls the hardware, and the device's behavior is determined by the interplay between software and hardware.

When sensor data fails to input correctly, specific GPIO pin settings are misconfigured, or memory access behaves abnormally, it can be challenging to pinpoint the issues using software debugging tools alone. This is why the Debug Interface has become an essential tool in the development of IoT and embedded devices. Developers can use the Debug Interface to monitor internal states (such as memory, registers, and clock settings) in real-time, allowing for a comprehensive analysis of issues that arise between hardware and software.

Differences Between General Software Debugging and IoT/Embedded Debugging

The Importance of Debug Interface in IoT and Embedded Systems

IoT and embedded devices interact closely with the physical environment, which is why a Debug Interface is essential for addressing complex issues like the following:

  1. Firmware Debugging
    Check the code flow, variable values, and hardware control states of the firmware running on the MCU.

    • Ensure that functions processing sensor data are functioning correctly.

  2. Hardware Integration Troubleshooting
    Analyze errors that arise during interactions with external hardware (sensors, actuators, communication modules).

  3. Device Status Analysis and Recovery
    Inspect and recover the internal state when a device fails to boot or operate.

    • This includes situations where firmware may be corrupted or issues arise during the initialization routine.

  4. Security Vulnerability Analysis
    Use debugging tools to conduct vulnerability research through memory dumps and firmware extraction.

    • For example, finding encryption keys in flash memory via SWD or identifying methods to bypass bootloader authentication.

The Debug Interface is not just a simple debugging tool; it plays a crucial role in understanding the operation of IoT and embedded devices, solving problems, and researching security.

In this article, we will explore how to access ARM-based devices using SWD and J-Link and how to utilize them effectively.

☑️ IoT and Embedded Debug Interface - JTAG, SWD

JTAG(Joint Test Action Group)

As previously discussed in the tech blog post "Hardware Analysis Process for IoT Hacking - 2," JTAG serves as a Debug Interface.

During the design and development phases, hardware or firmware is prone to errors and bugs. To address these issues, a method for inspecting the internal state of the device is necessary, which is where the Debug Interface comes into play.

The Debug Interface allows low-level hardware access, enabling the verification of internal memory states, register values, and code execution flow. This capability is used during product manufacturing to ensure normal operation and fix bugs. However, if this Debug Interface is not removed during the product release phase, it becomes a valuable resource for researchers studying IoT and embedded vulnerabilities.

JTAG stands for Joint Test Action Group and typically uses a standard 20-pin configuration, though modern JTAG implementations can take various forms, such as 10-pin or 14-pin, as shown in Figure 1.

<Figure 1>

While there are several pin maps for JTAG, the key pins are as follows:

  1. TDI (Test Data In)

    • A pin for inputting data into the test device, used for sending test commands or data.

  2. TDO (Test Data Out)

    • A pin for outputting data from the test device, used for returning test results and data.

  3. TCK (Test Clock)

    • Provides a clock signal to synchronize data transfers during JTAG operations.

  4. TMS (Test Mode Select)

    • Used to switch between JTAG states (between the instruction register and data register).

  5. TRST (Test Reset) - Optional

    • A pin for resetting the JTAG state machine; not all devices utilize this pin (optional).

  6. GND (Ground)

    • Ground pin.

  7. VCC (Voltage of Common Collector)

    • Used to detect the voltage level of the target device to ensure compatibility.

Key Pin Configuration

  1. Input/Output (TDI, TDO)

  2. Timing Control (TCK)

  3. Ground and Power (GND, VCC)

SWD

SWD (Serial Wire Debug) is a Debug Interface developed by ARM, serving as an alternative to JTAG. It has the advantage of requiring only a minimum of two pins for communication.

Thanks to its simple configuration and efficiency, SWD is widely used in ARM-based systems, particularly in embedded systems with space constraints. While SWD is limited to ARM devices, its ease of use makes it a good option for debugging ARM devices.

The SWD PIN MAP is configured as shown in Figure 2.

<Figure 2>

Pin Configuration

  1. Vref or VTref (Voltage Reference)

    • Responsible for setting the voltage on the SWD line (some JTAG adapters, like J-Link, require Vref voltage).

  2. SWDIO (Serial Wire Data Input/Output)

    • A single bidirectional data pin.

  3. SWCLK (Serial Wire Clock)

    • Provides the clock signal.

  4. GND (Ground)

    • Ground pin.

  5. SWO (Serial Wire Output) - Optional

    • Used with SWD to output real-time trace data.

  6. RESET - Optional

    • A pin for sending a reset signal to the target CPU.

Key Pin Configuration

  1. SWCLK (Serial Wire Clock)

    • A pin that transmits the clock signal, synchronizing the debugging device with the MCU.

  2. SWDIO (Serial Wire Data I/O)

    • A pin responsible for bidirectional data transfer, handling debugging commands, data, and responses.

J-link

J-Link is a Debug Probe developed by SEGGER, extensively utilized for debugging and flash programming in embedded system development. Here are its main features.

<Figure 3>

Supported Interfaces

  • JTAG

  • SWD

  • cJTAG

  • FINE

  • SPD

  • ICSP

Supported Processors

J-Link supports a wide range of CPUs and MCUs, including models from 8051 to ARM Cortex-M and Cortex-A series.

Connection Method

J-Link employs a 20-pin JTAG connector and is compatible with ARM's Multi-ICE. For SWD, it utilizes only two pins—SWCLK and SWDIO—replacing the five pins used by JTAG.

Software

J-Link can be utilized by installing the J-Link software.

SWD Pin Matching

The SWD interface of J-Link supports all previously mentioned pins (SWDIO, SWCLK, Vref, GND, SWO (optional), RESET (optional)).

☑️ Main Flash Dump Using J-Link SWD

This section outlines the process of performing a Main Flash Dump using J-Link and SWD.

The procedure consists of the following steps:

  1. Identify the SWD on the PCB.

  2. Establish a hardware connection using J-Link (PC - Device).

  3. Configure the debugging environment.

Hardware Connection

Datasheet

Before establishing the hardware connection, it is essential to identify the target chipset and consult the Datasheet.

The Datasheet provides critical information for hardware connections, including technical specifications, pinout, and pin definitions, making it imperative to review.

This article focuses on the GigaDevice GD32F307xx chip, which features 100 pinouts.

<Figure 4>

The pinout in Figure 4 and the pin definitions in Figure 5 confirm that both JTAG and SWD can be utilized.

<Figure 5>

<Figure 6>

Additionally, Figure 6 displays the Main Flash address as detailed in the datasheet.

<Figure 7>

Next, the SWD interface will be examined. The board is clearly marked for SWD, facilitating easy identification.

<Figure 8>

<Figure 9>

As shown in Figure 9, the SWD, CLK, GND, and 3V3 (3.3V, VTref) pins can be identified.

<Figure 10, 11>

The J-Link Pinout from Figure 10 will then be mapped to the board's SWD, CLK, GND, and 3V3 as illustrated in Figure 12.

<Figure 12>

With this setup, J-Link's SWD can now be utilized.

Installing and Using J-Link Software - for Windows

To begin, download and install J-Flash from the SEGGER official website.

🔗 Link : SEGGER - The Embedded Experts - Downloads - J-Link / J-Trace

Select "Create New Project" and then click "Start J-Flash.”

Set the Target Interface to SWD and configure the Speed to 1000 kHz (this may vary based on the target device).

Set the target device to the identified chipset.

Installing and Using J-Link Software - for Linux

For Linux, J-Flash should be downloaded, and the J-Link connection established using the following method.

The GUI version is available; however, this article will focus on the CLI environment for demonstration.

Command : JLinkExe -device GD32F307VC -if SWD -speed 1000 (Run as an option for single execution)

Command Sequence

  1. Execute JLinkExe

  2. Connect

  3. Enter Default Device (chipset name) : GD32F307VC

  4. SWD: S

  5. Speed : 1000

Upon completion of these steps, the connection will be established, and the device information will be displayed.

At this point, a variety of J-Link commands can be utilized.

For more information on J-Link commands, please refer to the following link: https://wiki.segger.com/J-Link_Commander

<J-link Command Table>

Main Flash Dump

The Main Flash contains firmware, bootloader, memory structure, and various data.

To analyze the target device, a Main Flash dump will be performed.

The savebin command will be used to execute the Flash dump. This command saves the specified memory range as a binary file.

savebin Syntax : savebin <file path to save> <start address to read> <size to read>

As confirmed earlier in Figure 6, the address range for the Main Flash is from 0x08000000 ~ 0x080FFFFF, leading to the following command formulation.

Command : savebin C:\ftp\firmware.bin 0x08000000 0x100000

The resulting output will reflect the Main Flash dump.

☑️ Closing Remarks

In IoT and embedded devices, the Debug Interface serves a purpose that extends beyond mere development tools. Debugging interfaces such as UART, JTAG, and SWD facilitate an understanding of the connection between hardware and software, enable detailed analysis of device behavior, and support efficient problem resolution. Notably, SWD has become the standard for debugging ARM-based systems, offering a streamlined configuration and powerful features that are invaluable for developers.

However, these interfaces, while serving as debugging tools, can also represent potential access points for security vulnerabilities. Properly disabling or strengthening security settings for Debug Interfaces before product release is essential; failure to do so may expose devices to threats.

This article aims to provide insights into the operational principles and applications of Debug Interfaces like SWD, facilitating effective application in the analysis and development of IoT devices.

Future discussions will expand on the understanding of IoT and embedded systems using various debugging techniques and analysis tools.


<Reference Sources>

Z ZIEN
{# 쿠키 수집 안내 팝업 — 선택 전 방문자에게만(cookie-consent '쿠키 안내 팝업'). 버튼은 폼 POST 라 JS 없이 동작하고, 닫기(×)는 '거부' 와 같이 저장된다. source·close 는 누른 버튼별 집계용 — 닫기를 거부와 따로 센다(cookie-consent '쿠키 선택 집계'). #}