Connecting & Sniffing

You have identified your UART pins. Now you need to talk to the device. This lesson covers the hardware bridge between your computer and the target, how to wire it correctly, how to open a serial session, and how to move beyond basic terminal emulators into professional-grade monitoring with espilon-monitor.

USB-UART Adapters: Choosing the Right Chip

Your laptop does not have a native serial UART port. A USB-UART adapter bridges the gap — it presents as /dev/ttyUSB0 or /dev/ttyACM0 on Linux and speaks UART to the target. The chip inside the adapter is what matters.

CH340 / CH341

The budget option. Chinese-manufactured, widely cloned, found in sub-$2 adapters from AliExpress. Works fine for basic use.

• Linux: Kernel module ch341 is included in mainline since 3.x. Zero setup on any modern distro.
• macOS: Requires a third-party driver. Can be unstable depending on macOS version.
• Windows: Needs driver installation. Microsoft occasionally signs them out.
• Voltage: Most CH340 boards are 5V logic by default. Check if your board has a jumper for 3.3V. Sending 5V into a 3.3V RX line will damage the target.
• Best for: Learning, quick tests, high-quantity lab use where losing one is acceptable.

CP2102 / CP2104

Silicon Labs design. More reliable than CH340, slightly more expensive ($3–8). Common in quality breakout boards.

• Linux: Module cp210x, included mainline. Works out of the box.
• macOS / Windows: Silicon Labs provides official signed drivers. Reliable installation.
• Voltage: Most boards provide both 3.3V and 5V selectable via jumper. Confirm before connecting.
• Best for: General hardware security work. Good balance of cost, reliability, and OS compatibility.

FT232RL / FT232H

FTDI design. The most robust and most expensive ($10–20 for the breakout). Supports higher baud rates, wider compatibility.

• Linux: Module ftdi_sio, included mainline. Works immediately.
• macOS / Windows: FTDI provides official drivers. Extremely stable.
• Voltage: FT232RL boards typically have a voltage select jumper (3.3V / 5V). FT232H supports wider voltage ranges with level shifters.
• Extra capability: FT232H supports MPSSE mode — this same adapter can do SPI, I2C, and JTAG, making it a versatile research tool beyond UART.
• Warning: Counterfeit FTDI chips are common on cheap adapters. The genuine driver will detect fakes and may brick them. Buy from reputable sources or verify the chip markings.
• Best for: Professional research environments, high baud rate sessions, or when you need multi-protocol support from one adapter.

Quick selection guide: CP2102 for most research work. FT232RL when you want a multi-purpose tool. CH340 when budget is the constraint and you understand its limitations.

Wiring: The Cross-Connection Rule

UART wiring is point-to-point and crosses over:

  Target Device          USB-UART Adapter
  ─────────────          ────────────────
      TX      ──────────►    RX
      RX      ◄──────────    TX
      GND     ──────────     GND

  VCC: do NOT connect when the target is already powered.

TX on the target connects to RX on the adapter. RX on the target connects to TX on the adapter. This is the only correct wiring. The logic: what the device transmits, your adapter receives, and vice versa.

GND must always be connected. Without a shared ground reference, the voltage levels are meaningless and communication will not work. GND is not optional.

Do not connect VCC unless you are powering the target from the adapter. In most hardware hacking scenarios, the target device runs from its own power supply (its wall adapter or internal battery). Connecting VCC from your USB-UART adapter into an already-powered target creates a voltage conflict between two power sources. At best, nothing works. At worst, you destroy the target's voltage regulator or your adapter. Leave VCC disconnected unless you have a specific reason and have confirmed it is safe.

Finding the Device on Linux

After plugging in your USB-UART adapter, verify the kernel recognized it:

# List USB serial devices
ls /dev/ttyUSB*
# Example output: /dev/ttyUSB0

# Or check kernel messages immediately after plugging in
dmesg | tail -20
# Look for lines like:
# usb 1-1.2: new full-speed USB device number 4 using xhci_hcd
# usb 1-1.2: cp210x converter now attached to ttyUSB0

If /dev/ttyUSB0 does not appear, the driver is missing or the adapter is defective. On a properly configured Linux system with a CH340, CP2102, or FT232, the device node appears within 2 seconds of plugging in.

Permission denied? Add your user to the dialout group:

sudo usermod -aG dialout $USER
# Log out and back in, or run: newgrp dialout

Without this, all serial port access requires sudo.

Terminal Emulators

picocom (recommended for quick access)

Minimal, fast, no configuration file needed. Install once, use everywhere.

sudo apt install picocom

# Connect at 115200 baud (most common for modern embedded Linux)
picocom -b 115200 /dev/ttyUSB0

# Useful flags
picocom -b 115200 --flow none /dev/ttyUSB0   # Disable hardware flow control
picocom -b 9600 /dev/ttyUSB0                  # Legacy devices often at 9600

# Key bindings inside picocom:
# Ctrl+A then Ctrl+X  — exit picocom
# Ctrl+A then Ctrl+S  — send a file (XMODEM)
# Ctrl+A then Ctrl+H  — display help

picocom is the right tool when you need a quick interactive console session — checking boot output, running one-off commands, verifying baud rate.

screen

Available on virtually every Unix system. Slightly less ergonomic than picocom but useful when picocom is not installed.

screen /dev/ttyUSB0 115200
# Exit: Ctrl+A then K (kill), confirm with Y

minicom

Feature-rich with menus and configuration files. Useful for situations requiring hardware flow control configuration or XMODEM/YMODEM transfers. More setup than picocom. Run minicom -s to configure before first use.

Common Baud Rates to Try

When you connect and see garbage output — random characters, no readable text — the baud rate is wrong. Try these in order:

115200  →  57600  →  38400  →  19200  →  9600  →  4800  →  2400

115200 is correct for the vast majority of modern embedded Linux devices. 9600 appears on older devices and some industrial equipment. If none of these produce readable output, the UART logic level or wiring may be incorrect.

espilon-monitor: Purpose-Built for Security Research

picocom opens one session and lets you type. That covers a basic interactive console. It does not cover what happens when you are running a fuzzing campaign against 3 devices simultaneously, need every byte logged to disk, or want real-time alerting when a target crashes. This is where espilon-monitor fills a gap that general-purpose terminal emulators were never designed for.

espilon-monitor is a universal serial monitor built specifically for embedded security research. It was developed as part of the Espilon toolchain to address the real workflows of hardware security researchers: monitoring multiple targets at once, automated pattern detection, structured logging, and crash analysis.

Installation

git clone https://github.com/Eun0us/espilon-monitor
cd espilon-monitor
make

No external dependencies beyond a standard build toolchain. The binary is standalone.

Basic Usage

# Monitor a single target — replaces picocom for monitored sessions
./espilon-monitor /dev/ttyUSB0

# Monitor multiple devices simultaneously in a single terminal
./espilon-monitor /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyACM0

# Enable structured logging to a directory (auto-named per device and session)
./espilon-monitor --logdir ./logs /dev/ttyUSB0

# Enable ESP32 family pattern detection (crash analysis, guru meditation errors)
./espilon-monitor --family esp32 /dev/ttyUSB0

# Interactive mode — sends input as well as captures output
./espilon-monitor -i /dev/ttyUSB0

Multi-Device Monitoring

This is the core differentiator. When you are fuzzing a target via its network interface and monitoring its UART output, you often want to watch the serial console of multiple units — the device under test, a reference unit, and perhaps a third device running a companion service. picocom and screen require a separate terminal window per device. espilon-monitor handles all of them in one process, with each device's output clearly labeled in the output stream and separately logged to disk.

In a fuzzing campaign, this means you can run your fuzzer in one terminal and watch all targets' serial output in another. When a device panics, crashes, or drops into a debug shell, you see it immediately without switching windows.

Pattern Detection for Security Research

espilon-monitor includes a pattern detection engine designed around the types of signals that matter in security research:

• Crashes and panics: kernel oops, NULL pointer dereferences, assertion failures
• Stack overflows: stack canary violations, overflow signatures in debug output
• Watchdog resets: unexpected reboots often indicate a successful denial-of-service or a triggered bug
• Privilege escalation signals: sudo prompts appearing unexpectedly, root shell drops, su/sudo invocations in automated sessions
• ESP32-specific: Guru Meditation errors, task watchdog triggers, memory corruption indicators

When a pattern is matched, espilon-monitor can alert in real-time (console highlight, log marker) without stopping the monitoring session. This is fundamentally different from picocom, which gives you raw bytes with no awareness of what they mean.

Automated Logging

Every session can log to structured files in a directory. Log files are named with device path, date, and time — no manual log management needed. When you are running overnight fuzzing and need to review what happened at 3am, the logs are already there, timestamped, one file per device.

./espilon-monitor --logdir ./campaign_logs /dev/ttyUSB0 /dev/ttyUSB1
# Creates:
#   ./campaign_logs/ttyUSB0_2026-05-14_23-00-00.log
#   ./campaign_logs/ttyUSB1_2026-05-14_23-00-00.log

When to Use espilon-monitor vs picocom

Use picocom for quick, interactive one-off sessions. Use espilon-monitor when the session is part of a systematic research workflow.

Common Issues and Fixes

Permission denied on /dev/ttyUSB0:

sudo usermod -aG dialout $USER
newgrp dialout

Garbage output / unreadable characters: Wrong baud rate. Try 9600, 57600, 38400 in addition to 115200. Also verify TX/RX wiring is not swapped (TX→TX instead of TX→RX).

No output at all: Check GND connection. Verify the device is actually transmitting (probe TX with a multimeter during boot — it should fluctuate). Confirm the correct device node (ls /dev/ttyUSB*).

Device not detected after plugging in: Run dmesg | tail to see if the kernel logged an error. A missing driver or a defective/counterfeit chip will show up here. Try a different USB port or cable.

Device disconnects during session: USB cable quality issue, especially with cheap CH340 adapters under high throughput. Use a quality cable and avoid USB hubs for this work.

espilon-monitor monitoring multiple UART devices simultaneously.