Hardware Simulation, Emulation, and Debugging Questions

Validating hardware and firmware before and without full physical availability, and diagnosing problems on real boards. Covers simulation and emulation of hardware behavior, on-chip debugging via JTAG and SWD, protocol implementation testing, and instrumentation with logic analyzers and probes. Includes strategies for reproducing and isolating hardware-dependent bugs.

EasyTechnical

77 practiced

Explain when to use CRCs vs cryptographic hashes (SHA-256, SHA-512) for verifying firmware or memory images in investigations. Describe how you would compute, store, and present these hashes so that they are defensible in court.

Sample Answer

**When to use CRC vs cryptographic hash**

- CRC (e.g., CRC32): fast, detects accidental corruption (transmission/storage errors). Not suitable for forensic integrity or anti-tamper proofing because collisions and intentional modifications are trivial.- Cryptographic hashes (SHA-256, SHA-512): slow(er), collision- and preimage-resistant; appropriate for verifying firmware/memory images in investigations and for court evidence.

**How I would compute**

- Use vetted tools on write-blocked media or from a forensically sound image. Example commands:

bash

# create forensic image (example)
dc3dd if=/dev/sdb of=/evidence/img.dd hash=sha256
# or compute hash on file
sha256sum firmware.bin > firmware.bin.sha256
sha512sum firmware.bin > firmware.bin.sha512
crc32 firmware.bin > firmware.bin.crc32

**How I would store and present (defensible practices)**

- Record tool versions, OS, command lines, timestamps, examiner name, hardware, and chain-of-custody steps in the case log.- Store raw hashes and signed manifests: produce a manifest file containing filename, size, SHA-256/SHA-512, and CRC (optional), then sign the manifest with examiner’s private key or time-stamp via a trusted TSA.- Preserve originals and copies; export hashes from multiple independent tools to show reproducibility.- In reports and testimony: present the hash algorithm, full hex digest, creation method, environment, and verification steps; explain why CRC alone is insufficient and that SHA-256/512 provide court-admissible integrity evidence.

EasyTechnical

66 practiced

Describe how you would use an oscilloscope to investigate intermittent hardware resets in an embedded device. Specify probe type and grounding, coupling (AC/DC), trigger configuration (edge, single-shot, pre-trigger), bandwidth/sample rate considerations, and what signals you would probe (e.g., VCC, Vbat, RESET, CLK).

MediumTechnical

66 practiced

Given a UART peripheral showing framing errors, explain in detail how you would read and interpret relevant memory-mapped registers via JTAG and what diagnostic steps you would take (register snapshots, clock source verification, FIFO status) to determine whether the cause is configuration, timing, or an electrical fault.

Sample Answer

**Approach / objective**As a forensic examiner I treat the UART as evidentiary hardware: preserve state, collect reproducible snapshots, and build a chain of custody. My goal is to determine whether framing errors are due to misconfiguration, timing/clock drift, or physical/electrical faults.

**Registers to read via JTAG**- Control/Config registers (baud divisor, parity, stop bits, word length)- Status register (framing, overrun, parity flags)- FIFO level / RX/TX pointers and watermark registers- Clock control and source selection registers for UART and system clock- Interrupt and error-mask registers

**Diagnostic steps**1. Freeze & snapshot: Halt CPU via JTAG, dump the above registers and memory-mapped UART buffers to immutable images. Log timestamps and tool versions.2. Verify config: Compare baud divisor calculation against expected baud (show calculation). Check parity/stop/word-length consistency with peer device.3. Clock verification: Read clock source registers; if possible sample clock on pin with oscilloscope/logic analyzer to measure bit-period jitter and nominal rate. Correlate measured baud to divisor.4. FIFO / timing: Inspect FIFO levels and RX pointer to see partial frames or repeated framing flags. Capture consecutive snapshots to see pattern (bursty vs constant).5. Electrical checks: Probe RX/TX lines for ringing, level shifts, common-mode noise; check grounding and ESD diodes. Use eye diagram or high-sample capture to reveal timing violations.6. Cross-check firmware: Ensure error handling/clearing is correct (errors not masked and later overwriting buffers). Capture stack/PC to see ISR behavior.7. Hypothesis mapping: - If divisor wrong or parity/stop mismatch → configuration. - If baud matches divisor but measured clock drifts/jitter → timing/clock. - If signal integrity issues on scope/eye → electrical fault.8. Reporting: Preserve raw captures, annotate evidence, include methodology, tools, and reproducible steps for court.

This process yields objective evidence distinguishing config, timing, and electrical causes while maintaining forensic integrity.

MediumTechnical

65 practiced

An embedded Linux device intermittently crashes with no kernel oops printed. Describe concrete steps to configure the device to collect kernel crash dumps (kexec/kdump), or alternative methods (netconsole, kgdb, serial logging) to capture a crash for later symbolized analysis with gdb (include expected commands/config snippets).

Sample Answer

**Approach — goal:** reliably capture kernel state when device crashes so I can later symbolize with vmlinux and gdb. I prefer kexec/kdump for full crash dump; fallbacks: netconsole, kgdb, persistent serial logging.

**1) kexec/kdump (preferred)**- Build kexec-tools in rootfs and ensure crashkernel=128M in kernel cmdline (u-boot):

bash

# /proc/cmdline via u-boot env
setenv bootargs "${bootargs} crashkernel=128M@16M"
saveenv

- Enable kdump in kernel config (CONFIG_CRASH_DUMP, CONFIG_KEXEC).- Start kdump script on boot:

bash

# example
modprobe kexec_crash
kexec -p /boot/vmlinuz --initrd=/boot/initramfs --command-line="$(cat /proc/cmdline)"
echo "/proc/sys/kernel/panic" # set auto-reboot

- On crash, capture /proc/vmcore from capture kernel, copy to host for analysis.

**2) Netconsole (low overhead, remote logging)**- On device:

bash

modprobe netconsole netconsole=@/eth0,6666@192.168.1.100/eth0,6667

- On host listen:

bash

nc -u -l 6666 > kernel.log

**3) kgdb (interactive)**- Compile kernel with CONFIG_KGDB and KGDB_SERIAL_CONSOLE or KGDB_ETHERNET.- On device enable:

bash

echo ttyS0,115200 >/sys/module/kgdboc/parameters/kgdboc
echo g > /proc/sysrq-trigger   # break into kgdb when configured

- From host: use gdb with vmlinux:

bash

gdb vmlinux
target remote /dev/ttyUSB0

**4) Serial persistent logging**- Ensure serial console in kernel cmdline: console=ttyS0,115200- Use a hardware logic analyzer or a UART-over-USB to capture entire boot/crash.

**Symbolization with gdb**- Copy vmlinux (uncompressed, with symbols) and vmcore:

bash

gdb vmlinux vmcore
# then use bt, info registers, list <addr>
(gdb) bt
(gdb) x/i $pc

**Forensic notes**- Preserve original images and logs; document chain-of-custody.- Prefer remote capture (netconsole/rdump) to avoid modifying evidence on-device.- Test the pipeline by forcing a panic: `echo c > /proc/sysrq-trigger` and verify vmcore/log capture.

HardTechnical

114 practiced

You need to extract and reconstruct heap/allocator state from a bare-metal microcontroller running a closed-source custom allocator with stripped symbols. Describe methods to locate heap metadata patterns in memory, instrument the code via JTAG to capture allocator calls, set breakpoints on suspected allocation routines, and reconcile differences across firmware versions to demonstrate use-after-free or dangling-pointer evidence.

Sample Answer

**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:

gdb

# 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.

Unlock Full Question Bank

Get access to hundreds of Hardware Simulation, Emulation, and Debugging interview questions and detailed answers.

Join thousands of developers preparing for their dream job.