Hardware Simulation, Emulation, and Debugging Questions

Brief overview

I understand the JTAG TAP state machine as a 16-state finite state machine that controls access to device test logic (boundary-scan, IR/DR). Knowing it helps a forensic examiner reliably place the TAP in states that let you read IDCODE, boundary-scan, or device memory — and to recover from an unresponsive TAP.

Main groups of states

• Reset / Test-Logic-Reset
  • Forces TAP to a known safe state; entered by holding TMS high for 5 TCK cycles.
• Idle
  • Stable quiescent state between operations (Run-Test/Idle).
• Capture / Shift (IR & DR)
  • Capture-IR/DR: loads default patterns.
  • Shift-IR/DR: serially shifts instruction or data registers.
• Update
  • Latches shifted data into functional registers (applies changed IR/DR values).
• Select / Exit / Pause
  • Control flow states (e.g., Pause-DR) that allow interruption or extended testing.

Why this matters in forensics

• Predictable access: Reset→Capture→Shift→Update sequence is required to read IDCODE or boundary-scan safely; mis-sequencing can leave device in an undefined state or corrupt evidence.
• Recovering unresponsive TAP: Forensically, holding TMS high to enter Test-Logic-Reset is a primary recovery step; knowing Pause and Exit states helps avoid accidental long shifts that lock pins.
• Evidence integrity: Proper state transitions ensure you don’t alter system state inadvertently (important for chain-of-custody and reproducibility).
• Practical example: When extracting boundary-scan data from a damaged board, I first assert Test-Logic-Reset, confirm IDCODE via Shift-DR, then shift the boundary-scan chain — documenting each TAP transition to show non-destructive access.

Situation & goal
Capture a rare daily 100 µs event on a 20 MHz bus (50 ns period) with forensic chain-of-custody and minimal storage use.

Sample rate

• Use ≥4× Nyquist for timing and protocol edges. Minimum: 80 MS/s (12.5 ns) — prefer 100 MS/s (10 ns) to cleanly resolve edges and decode bus symbols.

Buffer depth

• Event length at 100 MS/s: 100 µs × 100e6 = 10,000 samples. Allocate margin → 16k–32k samples per event.
• Avoid allocating huge continuous buffers for 24 hours; use segmented/circular strategies.

Trigger strategy

• Multi-stage trigger:
  • Level/edge pre-trigger to capture context (e.g., 1–2k samples pre).
  • Pattern or protocol trigger (specific header, start bit pattern) to reduce false captures.
  • Use "armed" windows: only arm capture when a coarse condition is met (RTC/time window or periodic poll).

Segmented acquisition

• Configure segmented capture with small segments (e.g., 32k samples each). Let analyzer store thousands of segments with timestamps. This preserves only regions around triggers and saves storage.

Circular buffer + post-capture preservation

• Run continuous circular capture storing recent segments; when trigger fires, mark and preserve N segments (pre/post). Immediately copy preserved segments to permanent storage (encrypted image) and halt further overwrites to maintain chain-of-custody.

Forensic best practices

• Record precise timestamps, capture metadata, hashes of saved segments, and lock device image. Validate with CRC/SHA before analysis.

This config reliably captures the 100 µs event while minimizing storage and preserving evidence integrity.

Approach overview

• Combine memory forensics (pattern hunting) with dynamic instrumentation via JTAG to correlate in-memory metadata with runtime allocator events. Produce reproducible traces that show allocation -> free -> pointer dereference to support use-after-free/dangling-pointer findings.

Locating heap metadata

• Scan RAM image for repeated structures: size fields aligned to 4/8 bytes, prev/next pointers, free-bit flags, magic values or canaries, length-ordered bins. Use entropy and value-distribution heuristics: metadata has low entropy vs. application heap blocks.
• Search for common allocator signatures (dlmalloc-like: size | 1 bit used; simple freelist nodes: next/prev pointers at offset 0/4). Compare across offsets for consistent layout.
• Validate candidates by checking pointer-like values that fall inside RAM range and by following next/prev chains.

Instrumenting via JTAG

• Use OpenOCD/GDB to halt, set break/watchpoints, and dump memory. Example breakpoint/watch commands:

# halt CPU, set breakpoint and hardware watchpoint on address
monitor reset halt
break *0x08001234         # suspected allocator entry
watch *(uint32_t*)0x20001000  # watch pointer variable or freelist head
continue
# on hit: examine registers and memory, dump block metadata
x/8xw $sp
dump binary memory heap_dump.bin 0x20000000 0x20010000

• Insert code-path triggers (controlled inputs, IRQs) to force allocations/frees. Use single-step to capture prologue/epilogue where size/ptrs are manipulated.

Breakpoint strategy

• Set breakpoints on function epilogues found by scanning for common prologue bytes (push lr; stmfd) or by break-on-write to freelist heads.
• Use conditional breakpoints (e.g., size > N) to filter events.
• Use watchpoints on suspected metadata fields (size or next pointer) to catch frees/insertions.

Reconciling firmware versions

• Build a mapping table of metadata field offsets per firmware by comparing matched patterns and trace logs. Track changes: pointer sizes, alignment, extra canaries, or encryption/obfuscation.
• Use differential analysis: run same allocation sequence across versions, compare resulting memory layouts and register traces to pinpoint offset shifts or changed checks that could mask use-after-free.

Demonstrating use-after-free/dangling-pointer

• Correlate a dynamic trace: allocation at t1 -> free at t2 (freelist insertion observed) -> subsequent dereference at t3 where pointer points inside a freed block that was later reallocated. Produce:
  • Memory dumps before/after free showing metadata transition (in-use bit -> free list pointers)
  • GDB backtraces and register state at dereference
  • Repro script that repeats sequence to show deterministic reuse of freed block
• Quantify evidence: block addresses, sizes, timestamps, instruction addresses, and diffed memory regions. Package artifacts (memory dumps, trace logs, commands) for chain-of-custody.

Best practices

• Preserve original RAM image; work on copies. Note JTAG instrumentation can alter timing—document all actions. Use checksums, timestamps, and signed logs for evidentiary integrity.

Answer (Digital Forensic Examiner perspective)

Why consult the datasheet: When reconstructing serial device behavior or proving message corruption, the datasheet is primary evidence for device-spec behavior (timing, error reporting, clocking). I cite sections/figures to link observed trace patterns to expected device behavior.

Sections & figures to open first

• Functional description / UART block diagram (shows internal FIFOs, parity generator/checker)
• Register summary & map (addresses and R/W behavior)
• UART register descriptions (RX/TX control, baud/divider, parity, stop bits)
• Timing diagrams (TX/RX frame format, sample points, setup/hold)
• Clocking/baud-generation section and figures (source, prescalers, fractional dividers)
• Electrical characteristics & I/O timing (Voh/Vol, input thresholds, rise/fall)
• FIFO behavior and status figures (depth, almost-full/empty thresholds)
• Interrupts & error flags table
• Errata and application notes (known silicon issues)

Checklist to examine

• Registers:
  • Baud rate divisor + fractional registers
  • Line control: parity enable/type, stop bits, data length
  • FIFO control: enable/reset, trigger levels
  • Status: framing error (FE), parity error (PE), overrun (OE), break detect
  • Interrupt enables/masks for FE/PE/OE
• Timing diagrams:
  • Bit cell timing, sample point, minimum bit width
  • Inter-byte spacing and break timing
• Clock sources:
  • Primary clock freq, prescaler, external crystal tolerances
  • Asynchronous vs synchronous modes
• Electrical:
  • Input threshold voltages, allowable slew, noise margins
  • Line idle levels and voltage-level conversion notes (TTL/RS-232/RS-485)
• FIFO behavior:
  • Depth, how FE/PE reported when FIFO enabled, effect of DMA
  • Behavior on FIFO reset, when status bits latch/clear

Practical forensic checks

• Correlate scope/logic-analyzer captures to timing diagram sample point
• Verify baud divisor math with documented clock tolerances
• Show that FE/PE flags set in register snapshots or logs match captured waveform anomalies
• Note errata that could exculpate or explain intermittent framing errors

This checklist maps observed evidence (waveforms, register dumps) to authoritative datasheet items you can cite in reports or testimony.

Clarify requirements
I’d design for ingest, triage, deep analysis, and evidentiary preservation at scale (thousands devices/week), legal defensibility, repeatability, and minimal human bottlenecks.

High-level architecture

• Central orchestration + LIMS (case DB) + distributed test-bench clusters + secure evidence vaults + reporting/forensic VM farm.

Physical equipment

• JTAG/SWD banks: modular 32-port banks with level-shifters and per-port power control; automated fixtures for common SoC pinouts.
• Logic analyzer clusters: consolidated multi-channel analyzers (64+ channels) mounted on rackable PXI-style chassis; per-cluster timestamp sync (PTP).
• Oscilloscopes: 4–8 high-bandwidth scopes with remote-control APIs for spot measurements; probe carts for manual debugging.
• Imaging stations: write-blocked SD/eMMC/serial flash readers, high-resolution microscope cameras for PCB imaging, hot-air rework stations.
• Spare parts bench and universal adapters (BGA rework, pogo-pin fixtures).

Automation & orchestration

• LIMS stores case metadata, evidentiary chain, automated test recipes.
• Orchestration layer (Ansible + custom scheduler) assigns devices to benches, pushes scripts (JTAG scripts, UART logs, firmware dumps), collects artifacts to immutable object storage with checksums.
• Test benches run preflight checks (power rails, thermal), automated firmware extraction, memory carve, signal capture, and fuzz scripts.
• Forensic VMs auto-run analysis pipelines (strings, YARA, binwalk, JTAG RAM dumps) and generate flagged findings.

Chain-of-custody & compliance

• Barcode/RFID tagging at intake; LIMS records handlers/time. Evidence lanes: intake → quarantine → analysis → return/storage. All operations logged and signed. WORM storage + cryptographic hashes and periodic notarization (timestamping).

Environmental controls

• ESD-safe rooms, temperature/humidity control, filtered airflow for rework. Secure vault with access control and CCTV for evidence storage. UPS and surge protection for benches.

Triage & prioritization

• Intake triage rules: case severity, legal hold, volatility (battery-backed devices), ROI (likely evidentiary value). Priority queue in LIMS with SLA tiers; automated fast-path for volatile extraction (battery keep-alive, RAM capture) and slow-path for deep JTAG/decapping.

Trade-offs / scalability

• Use modular benches to scale horizontally; invest in automation to reduce per-device human time. Balance between full automation and manual deep-dive stations for complex SOCs.

This design ensures throughput, repeatability, and legally defensible evidence handling while allowing expert examiners to focus on high-value analysis.