Hardware Security

---
name: hardware-security
description: Use for authorized hardware and embedded interface security research including UART/JTAG discovery, debug pad triage, secure boot overview, and offline firmware extraction support.
---

# Hardware / Embedded Interface Security

## ACTION REQUIRED (execute immediately after reading)

1. `NOW`: Confirm **physical-access authorization** and device ownership
2. `NOW`: ESD/power safety; default to read-only probing
3. `NEXT`: Combine with firmware-pentest for image analysis
4. `ACT`: Enclosure and debug-interface identification → consoles → extraction

## Applicable Scenarios

- UART / JTAG / SWD debug-port discovery
- Boot logs, root shell, interrupting the bootloader
- Flash extraction in coordination with device teardown
- Feasibility assessment of secure boot / encrypted Flash (non-destructive methods first)

## Workflow

```text
□ Teardown of authorized devices; photograph and label test points
□ Use a multimeter to find GND/VCC/TX/RX; logic levels 1.8/3.3/5V
□ USB-TTL for read-only logs; record the baud rate
□ JTAG: enumerate IDCODE; assess whether it is locked
□ Extract images → hand off to firmware-pentest / ghidra
```

## Toolchain

| Tool | Purpose |
|------|---------|
| USB-TTL / logic analyzer | UART |
| J-Link / CMSIS-DAP | Debugging |
| bus pirate / flipper (lab) | Multi-protocol |
| binwalk / flashrom | Extraction |

## References

- `references/debug-interface-triage.md`
- `../firmware-pentest/` `../ot-ics/`

## Routing Context

**Upstream**: MASTER R34  
**MUST NOT**: tear down or damage others' devices without authorization

## Task Completion Checklist

- [ ] Were interface levels and pinouts documented?
- [ ] Were images hash-preserved?
- [ ] Checklist?