Hardware Analysis Series – Part 1: Peripheral interfaces, the forgotten doors of silicon

By Kike Gandia · Hardware & OT · 5 min read

Illustration of four pin headers, UART, SPI, I2C and JTAG, connected by glowing traces to a microcontroller, with an orange digital signal

Embedded systems and industrial IoT devices are no longer mere auxiliaries: they control vital processes in power plants, automated factories and global logistics networks. This hyperconnectivity has expanded the attack surface exponentially. While logical access is hardened with authentication, encryption and firewalls, a less visible but equally critical dimension remains exposed: the physical interfaces built into the hardware.

These interfaces, originally designed for development, testing or debugging, often remain accessible in shipping products. Although invisible to the user, they are perfectly exploitable by anyone with the knowledge, the tools and physical access. Understanding them, mapping them and knowing how they interact with the system is essential, both to strengthen security and to carry out advanced audits or firmware recovery.

In this first installment of our Hardware Analysis series, we explore the most common peripheral interfaces: UART, SPI, I2C and JTAG. Each one offers a different way to get into the system, extract information, alter its behavior or even take full control of the device.

3 wires UART
The simplest and most common: TX, RX and GND. It yields boot logs, diagnostics and sometimes a system shell, often without asking for authentication.
4 lines SPI
Synchronous master-slave, the bus that connects the CPU to external flash. It allows a full firmware dump and reprogramming.
2 lines I2C
SDA and SCL for short-range communication: small EEPROMs, RTCs and sensors where debug flags and calibration data live.
4-6 pins JTAG
Low-level debugging with direct access to the processor: registers, RAM and CPU halt. If it is enabled, it means total control.

The four interfaces covered in this installment, each with its own way in.

UART (Universal Asynchronous Receiver/Transmitter)

UART is one of the simplest and most common interfaces in embedded systems. It is present in virtually every device with a microcontroller or processor, and it is the main debugging tool during development.

Key characteristics

  • Plaintext data transmission.
  • Needs only three wires: TX (transmit), RX (receive) and GND.
  • Configurable baud rate (9600, 115200, etc.).
  • Typically operates at 3.3V or 1.8V.

Offensive and defensive uses

  • Provides access to boot logs, diagnostics and sometimes even an operating system shell.
  • Many devices require no authentication to use UART when it is active, which is a critical exposure.
  • In audits it can be used to validate security configurations, protect the bootloader or disable consoles.

Use case: If during a physical penetration test we find a 4-5 pin header and get a U-Boot console or a terminal with a Linux prompt, we could escalate access with commands such as mount, cat /etc/shadow or even passwd if permissions are misconfigured.

SPI (Serial Peripheral Interface)

SPI is a synchronous master-slave communication protocol, frequently used to connect the CPU to external flash memory. In industrial environments, where firmware is stored outside the SoC, SPI is a gold mine for the auditor.

Key characteristics

  • Four lines: MOSI (Master Out Slave In), MISO (Master In Slave Out), CLK (Clock), CS (Chip Select).
  • High transfer speed.
  • Widely used in chips such as the W25Q64, MX25L128 and AT45DB.

Offensive and defensive uses

  • Allows a full firmware dump.
  • Ideal for spotting insecure configurations, embedded keys or boot scripts.
  • Can be reprogrammed to change behavior, restore configurations or apply patches.

Use case: With a SOP8 clip and a programmer (EZP2019+, CH341A, Bus Pirate), you can extract the binary from the SPI memory, analyze it with tools such as binwalk, strings and Ghidra, and uncover sensitive information such as internal paths, backdoors or hashes.

I2C (Inter-Integrated Circuit)

I2C is a serial interface designed for short-range communication between multiple components. It is common in small EEPROMs, RTCs, temperature or voltage sensors, and auxiliary controllers.

Key characteristics

  • Just two lines: SDA (data) and SCL (clock).
  • Devices are identified by addresses.
  • Slower than SPI, but simpler for multi-device buses.

Offensive and defensive uses

  • Persistent configuration can be read or modified.
  • I2C EEPROMs often store debug-mode flags, serial numbers, passwords or calibration data.
  • In critical environments it can be used to change behavior without touching the main firmware.

Use case: Dumping an AT24C I2C EEPROM with a Bus Pirate or a dedicated reader, then modifying a flag to unlock a hidden menu or enable debugging options.

JTAG (Joint Test Action Group)

JTAG is a low-level debugging interface that provides direct access to the processor. Although less visible than UART or SPI, when it is enabled it offers advanced reverse engineering capabilities and total control.

Key characteristics

  • Typical pins: TDI, TDO, TCK, TMS (sometimes TRST, SRST).
  • Access to registers and RAM, CPU halt.
  • Used for debugging, programming and factory validation.

Offensive and defensive uses

  • Can dump live RAM and uncover keys at runtime.
  • Ideal for auditing bootloader protections and verifying system integrity.
  • Requires tools such as JTAGulator, OpenOCD and FTDI adapters.

Use case: If an ARM CPU has JTAG enabled, we could halt execution, read the stack and access data in RAM that is not in the firmware, such as temporary TLS keys or heap data.

Audit considerations

Peripheral interfaces are a direct entry point into the system. If they remain active on production devices without proper protection, they can completely compromise security:

Where attackers get in what an auditor with physical access looks for

  • UART: boot logs, a U-Boot console or even an unauthenticated shell.
  • SPI: a full firmware dump, with embedded keys and boot scripts.
  • I2C: debug flags, serial numbers and passwords in small EEPROMs.
  • JTAG: CPU halt and live RAM reads, where temporary keys live.

How to close the door what the manufacturer should do

  • Obfuscate or remove silkscreen markings.
  • Disable UART and JTAG consoles via fuses or software.
  • Require authentication in bootloaders.
  • Verify firmware cryptographically.

Exposing these interfaces in production compromises the entire system.

Recommended tools:

  • Bus Pirate 5/6, CH341A, EZP2019+, FTDI232H.
  • Logic analyzer with PulseView.
  • Multimeter, microscope, SOP8 clips.
  • Software: flashrom, binwalk, strings, Ghidra, OpenOCD.

Peripheral interfaces are not vulnerabilities in themselves, but their exposure is a serious threat if the threat model does not account for them. Any connected or critical device must be assessed not only for its digital surface, but also for the physical backdoors engineers left behind during design. At QuantumSec we audit, understand and exploit those interfaces as part of a comprehensive security strategy.

Because in silicon there is no login and no firewall. Only electronics and know-how.

At QuantumSec we don't make assumptions. We reverse engineer.

If your device has silicon, it has a story to tell... and we know how to listen.

From hidden UART consoles to exposed SPI memory, every copper trace is an opportunity for anyone who knows where to look. While others audit the software, we go further: we audit the system from the physical layer, where there are no firewalls, no logs and no honeypots. Only signals, voltages and open doors into the heart of the device.

We combine electronic warfare techniques, firmware recovery, glitching and bus analysis on real devices, carried out by real experts.

Does your organization rely on embedded devices, IoT or critical infrastructure?

Then you need more than an audit: you need to know what others can't see.

👉 Get in touch

We'll show you how someone can get in through the port nobody documented, reprogram what seemed immutable and trigger alarms no one ever planned for.

Because when everything else fails, there are still voltages.

And that's where we come in.

Related service

OT/ICS security and industrial pentesting

Topics

#Bus-Analysis #Firmware-Extraction #Hacking-Hardware #Hardware #I2C #Physical-Reverse-Engineering

Keep reading

Talk about OT security