Hardware Security

Skill: Hardware Security

Supplementary Files:

• payloads.md — Hardware attack commands, debug interface payloads, firmware extraction one-liners, and RFID/NFC cloning commands organized by attack phase
• test-cases.md — Structured test cases for UART root shell access, SPI firmware extraction, JTAG memory dump, firmware secret scanning, and RFID card cloning
• guides/ — Deep-dive methodology guides for embedded firmware analysis and hardware assessment

Summary

Hardware Security skill domain covering hardware operations.

Domain: hardware

Description

Hardware and embedded system security testing covering physical interface exploitation, firmware extraction and analysis, side-channel attacks, RFID/NFC cloning, and fault injection. This skill addresses the full lifecycle of hardware penetration testing: from physical reconnaissance of an unknown device through debug interface access, firmware acquisition, static analysis, and exploitation.

Runtime context: Kali Linux 2025-2 (ARM64). Physical hardware tools (UART adapters, logic analyzers, SPI flash programmers, Proxmark3) are required for active engagement phases.

Difference from binary-reverse: binary-reverse focuses on analyzing binaries already in hand (reverse engineering, decompilation, patching). This skill handles the upstream problem of physically acquiring firmware from a target device and identifying hardware-level attack vectors before binary analysis begins.

Use Cases

• IoT device security assessment (routers, smart home devices, IP cameras)
• Embedded firmware audit for proprietary devices without public firmware
• RFID/NFC security testing (access cards, smart cards, key fobs)
• Industrial control system (ICS/SCADA) hardware security review
• Hardware-based authentication bypass (JTAG debug, UART shell)
• Supply chain hardware integrity verification (detecting implants, backdoors)
• Bootloader security assessment (secure boot bypass, U-Boot exploitation)
• Medical device security testing

Methodology

Phase 1: Physical Reconnaissance

Goal: Identify all external interfaces and collect device intelligence before applying probes.

• Photograph all PCB surfaces; annotate visible chip markings
• Look up FCC ID on fcc.gov to obtain internal photos, test reports, and sometimes full schematics
• Identify chip families from markings: SoC, flash chip, EEPROM, RF modules
• Map all exposed connectors: USB, UART headers, JTAG/SWD pads, SPI test points, I2C headers
• Note unpopulated PCB footprints — these often hide debug headers removed for production
• Record chip datasheets for pinout reference

Tools: Multimeter, magnification lens, logic analyzer, FCC ID database (fcc.gov), Shodan for firmware version fingerprinting

Phase 2: Debug Interface Access

Goal: Establish a communication channel with the device at a privileged level.

UART (Universal Asynchronous Receiver/Transmitter):

• Probe candidate pins with multimeter for 3.3 V or 5 V idle-high TX line
• Try common baud rates: 115200, 57600, 38400, 19200, 9600
• Connect with USB-to-UART adapter (CP2102, CH340, FTDI FT232R)
• Many devices expose a root shell or U-Boot console on UART

JTAG/SWD (Joint Test Action Group / Serial Wire Debug):

• Identify JTAG pins (TDI, TDO, TCK, TMS, TRST, GND) using JTAGulator or UrJTAG
• Connect OpenOCD with appropriate target configuration
• Use JTAG to halt the CPU, dump memory, and read/write registers

SPI/I2C:

• Attach logic analyzer to candidate bus lines during device boot to capture traffic
• Identify clock, data, chip-select lines
• Use Bus Pirate or Raspberry Pi to replay or intercept transactions

Phase 3: Firmware Extraction

Goal: Obtain a complete binary image of the device firmware for offline analysis.

Methods in preference order:

1. JTAG readout — halt CPU, dump flash memory ranges via OpenOCD dump_image
2. SPI flash direct read — desolder or clip onto SPI NOR/NAND flash chip, use flashrom with CH341A programmer
3. UART bootloader — interrupt U-Boot at startup, use md (memory display) or TFTP to extract
4. Firmware update interception — capture OTA update via MITM proxy or download from vendor
5. Filesystem from update package — vendor-supplied .bin or .zip update files often contain the full filesystem

Verify extracted image: md5sum firmware.bin, compare with known-good hash if available.

Phase 4: Firmware Analysis

Goal: Unpack the firmware and identify vulnerabilities in the embedded system.

firmware.bin
  ↓ binwalk -B (signature scan)
  ↓ binwalk -e (extract embedded filesystems)
  ↓ unsquashfs / jefferson / cramfsck (mount filesystem)
  ↓ strings + grep (find secrets, hardcoded credentials)
  ↓ find . -name "*.conf" -o -name "*.sh" (audit configs and scripts)
  ↓ radare2 / Ghidra (reverse engineer key binaries)
  ↓ semgrep / custom patterns (vulnerability pattern scan)

Key targets: /etc/passwd, /etc/shadow, web server configs, init scripts, private keys, API tokens, hardcoded IPs.

Phase 5: Exploitation

Goal: Demonstrate impact of identified vulnerabilities with working proof-of-concept.

• UART root shell: If bootloader drops to root shell, document full system access
• Bootloader bypass: Interrupt U-Boot, set bootargs to single-user mode or disable secure boot checks
• RFID cloning: Use Proxmark3 to read and emulate access cards
• Credential reuse: Use extracted credentials against web interface, SSH, Telnet
• Command injection: Exploit web interface vulnerabilities identified through firmware code review
• Fault injection: Voltage or clock glitching to bypass secure boot (specialized hardware required)

Core Tools

Defense Perspective

Detection Methods

Hardware Attack Indicators

• JTAG/SWD access: Debug interface activity on production hardware (should be disabled).
• Glitch detection: Voltage/clock glitching signatures in power monitoring.
• Side-channel anomalies: Unusual power consumption patterns during crypto operations.
• Physical tamper: Anti-tamper mesh break; chassis intrusion switch activation.

SIEM Detection Rules

• Splunk SPL (IoT): index=iot event_type="jtag_access" | stats count by device_id
• Hardware security modules (HSM): Audit log monitoring for tamper events.
• TPM measurements: Verify boot measurements against golden baseline.

Defense Evasion Techniques

Physical Exploitation Stealth

• Non-invasive attacks first: Use power/clock glitching before invasive (decapping); preserves device.
• Laser fault injection: Use IR laser through backside of die; minimal physical evidence.
• Cold boot attacks: Freeze RAM to preserve keys; minimal trace.
• Glitch detection bypass: Find devices without glitch detectors (older models).

Side-Channel Stealth

• Tolerated side-channels: Use Spectre/Meltdown variant that's "tolerated" (allowed by design).
• Slow acquisition: Pace power analysis over long period; reduces pattern detection.
• Cross-device averaging: Use multiple identical devices; average noise to recover key.

Orchestration

ECC Loop Pattern: Sequential Pipeline

Rationale: Hardware security testing follows a strict physical dependency chain. You cannot extract firmware without first identifying debug interfaces, and you cannot perform meaningful vulnerability analysis without firmware in hand. Each phase gates on the success of the previous one — skipping reconnaissance leads to missed interfaces, and skipping extraction leaves analysis working on assumptions. The Sequential Pipeline enforces this physical causality.

Integration:

• Feeds into: binary-reverse (deep binary analysis of extracted firmware), security-review (audit firmware configs, secrets, and services), chronicle (document findings and evidence)
• Consumes from: search-first (device CVEs, known firmware vulnerabilities, FCC database), repo-scan (when vendor source code is available)

Cross-Skill Pipeline:

search-first → [device CVEs, known vulnerabilities, FCC database lookup]
     ↓
hardware-security → [Phase 1: physical interface identification and chip mapping]
     ↓
hardware-security → [Phase 2-3: debug access + firmware extraction + hash verification]
     ↓
binary-reverse → [deep binary analysis: decompilation, vulnerability discovery]
     ↓
security-review → [audit firmware configs, hardcoded secrets, network services]
     ↓
verification-loop → [confirm exploitability of identified issues with PoC]
     ↓
chronicle → [archive findings, evidence, and final report]

Quality Gate: Before marking a hardware assessment complete —

1. All external physical interfaces identified and documented with photos
2. At least one debug interface accessed (UART, JTAG, or SPI)
3. Firmware extracted and MD5/SHA256 hash recorded
4. Filesystem successfully unpacked and inventoried
5. Secrets and credential scan completed with findings documented
6. Network services in firmware identified (telnetd, httpd, sshd, ftpd)
7. Exploitation path or proof-of-concept documented for each critical finding

Report Template

# Hardware Security Assessment Report
*Target: [device make/model/firmware version] | Date: [date] | Scope: [physical access level]*

## Executive Summary
[Overall risk rating, key findings summary, physical access requirements]

## Device Intelligence
- FCC ID: [if applicable]
- Processor: [SoC make/model]
- Flash: [chip make/model/capacity]
- Interfaces identified: [UART / JTAG / SPI / I2C / USB]

## Findings

### [SEVERITY] [Title]
- **CWE**: [CWE-ID]
- **Interface**: [UART / JTAG / SPI / Firmware / RFID]
- **Location**: [pin / binary path / register]
- **Description**: [what was found]
- **Evidence**: [reproduction steps, commands used]
- **Impact**: [what attacker with physical access can achieve]
- **Remediation**: [how to fix — disable debug port, secure boot, credential rotation]

## Summary Statistics
| Severity | Count |
|----------|-------|
| Critical | N |
| High | N |
| Medium | N |
| Low | N |
| Info | N |