re-hw-chip

Chip/PCB hardware reverse engineering

When to use / when not to use

• Use: physical chip/board-level analysis (physical layer after firmware extraction fails), chip decryption, hardware trojan detection
• Don't use: firmware-level analysis (go to [[re-fw-extract]]); interface extraction (go to [[re-hardware-io]]); wireless signals (go to [[re-sdr]])

Tool preparation

Microscope/probe station (observation and contact)

• Purchasing guide: stereo microscope (initial inspection) → metallurgical microscope (bare die); probe station tiered by budget
• Verification: no software verification—acceptance by imaging clarity

decapping equipment and consumables (decapsulation)

• Chemical decap: fuming nitric acid/sulfuric acid + heating stage (protection: fume hood/goggles); laser decap: dedicated laser (high cost, outsourcing optional)
• Verification: no software verification—acceptance by degree of exposure

Logic analyzer (signal extraction)

• Multi-platform: Saleae-type (bundled software available on each platform) or open-source solutions (sigrok/PulseView:apt install sigrok-cli pulseview / brew install sigrok-cli pulseview(sigrok has no PyPI package))
• Verification: pulseview --version

Thermal imaging (power/timing anomalies, optional)

• Purchasing guide: select by resolution and temperature measurement range; verification: imaging acceptance

Operating steps

Execute in order; pay attention to protection and destructive risks throughout (step 1 is irreversible).

1. Decapping：

   • Chemical method: preheat on heating stage → drip fuming nitric acid to dissolve epoxy → clean (acetone) → microscope inspection
   • Laser method: layer-by-layer laser ablation (high precision, high cost)
   • Risk control: fume hood, acid-resistant gloves/goggles, waste liquid disposal; practice on scrap chips first
   • Acceptance: metal layers visible, no over-etching (damage to the wafer)

2. Bare die analysis：

   • Microscopic imaging (metallurgical microscope/electron microscope) → metal layer trace observation
   • ROM/fuse extraction: imaging → bitmap reconstruction (metal layer/polysilicon layer patterns → binary)
   • Output: ROM bitmap → data (compare with [[re-fw-extract]] firmware)

3. Probing and signal extraction：

   • Probe station contacts test points (bus/clock/data lines)
   • FIB (focused ion beam): modify interconnects/expose internal nodes (high cost, outsourcing)
   • Signal sniffing: logic analyzer attached to bus (timing compared against datasheet)
   • Note: probe loading may change the signal (see pitfall 2)

4. PCB circuit analysis：

   • Trace reconstruction (multimeter continuity/imaging → netlist)
   • IC marking identification (silkscreen → model → datasheet → pin functions)
   • JTAG/SWD pin locating (test points/trace features → debug interface enumeration)

5. Hardware trojan detection：

   • Redundant logic features (flip-flops/counters with no functional path)
   • Power/timing anomalies (thermal imaging + current curve compared against baseline)
   • Trigger condition analysis (specific input combinations/temperature/time conditions)

Side-Channel and Fault Injection

Power Side-Channel (SPA/DPA)

• SPA (Simple Power Analysis): Directly observe key-related operations from a single or a few power traces (number of bits in exponentiation operations, current differences in conditional branches), suitable for scenarios where the algorithm structure is known.
• DPA (Differential Power Analysis):
  • Acquisition principle: Perform multiple encryptions/decryptions under the same key, recording power traces one by one.
  • Differential approach: Group by guessed key bit (e.g., group by whether a certain bit of an S-box output in a certain round is 0/1), average within each group and subtract; if a significant peak appears under a certain guess, it indicates a correlation between that intermediate value and power consumption.
  • Correlation analysis: Perform point-by-point correlation calculation between intermediate value bits and traces (CPA approach); the peak position corresponds to the moment the operation occurs, allowing reverse verification of the guess.
• Key points for purchasing acquisition equipment (chipwhisperer class):
  • Sampling rate: Not lower than several times the target clock (beyond the Nyquist requirement); GHz-level sampling is required for high-speed clocks.
  • Trigger synchronization: Support external trigger signals (aligned to the start of encryption/decryption); aligning traces one by one is a prerequisite for differential analysis.
  • Signal-to-noise ratio: High-impedance differential probes, short ground leads, and shielding can reduce noise; when noise is high, compensate by averaging over more acquired traces.
  • Verification: No software verification—acquire traces with a known key and confirm that differential peaks appear.

Fault Injection (Clock Glitch/Voltage Glitch)

• Principle: A clock glitch inserts a too-narrow clock cycle at the moment a target instruction executes, causing fetch/decode/execute failure and producing effects such as skipping branches or corrupting intermediate values; a voltage glitch achieves similar effects via instantaneous undervoltage.
• Parameter sweep process:
  1. Coarse sweep: Spread out width and phase (injection timing) in large steps, recording parameter points that show a response.
  2. Refinement: Reduce the step size for the hit region to locate the stable window.
  3. Re-test: Inject multiple times with the same parameters to confirm the effect is reproducible.
• Result determination: Branch skipped (authorization check passes directly), return value altered (verification function returns corrupted), no effect or crash (parameters out of range, fall back and re-sweep).
• Connection with decapsulation: Bare-die probes can contact clock/bus nodes; the glitch injection point coincides with the power observation point, and side-channel traces can corroborate probe waveforms; after decapsulation, there are more choices for injection points (see steps 1/3 above).

Security Boundary

• Consistent with the overall boundary of the skill library: limited to authorized own devices/laboratory samples within scope, not involving specific attack targets.
• This section is a methodological description and does not provide operational guidance for specific targets.

Common Pitfalls and Traps

• Waveform desynchronization leads to no correlation in DPA: Symptom—no peaks in the differential trace, correlation values near zero; Cause—trace starting points are not aligned (trigger not aligned, software trigger delay jitter); Countermeasure—switch to a hardware trigger signal, or re-align afterward based on a fixed feature point.
• Glitch parameter sweep cannot find the window: Symptom—no effect at all when sweeping the full parameter range; Cause—the width/phase sweep step size is larger than the hit window; Countermeasure—first perform a coarse sweep to locate the interval, then refine the step size, and increase the number of repetitions if necessary.
• Device locks up after fault injection: Symptom—the device does not respond or enters an abnormal state after injection; Cause—the glitch corrupts the running state or mistakenly writes to storage; Countermeasure—back up the firmware before the experiment and prepare a re-flash recovery process; when injecting in batches, restart by batch.
• Insufficient acquisition device bandwidth: Phenomenon—waveform distortion under high-speed clocks (slower edges, loss of high-frequency detail); Cause—acquisition bandwidth lower than the signal spectrum requirement; Countermeasure—select a device with sufficient bandwidth according to the target clock, or reduce the clock rate

Cross-domain integration

• [[re-hardware-io]]: Interface extraction linkage (JTAG/UART are software-side entry points)
• [[re-fw-extract]]: Firmware-side comparison (compare ROM extracts with firmware dumps)
• [[re-sdr]]: Wireless side (RF interface)
• [[re-triage]]: Preliminary survey of extracts

Common pitfalls and traps

• Decap is irreversible: Phenomenon—cannot be recovered after the package is destroyed; Cause—physical destruction; Countermeasure—archive the firmware first ([[re-fw-extract]]) before performing physical operations
• Probe loading changes the signal: Phenomenon—timing anomalies after attaching a probe; Cause—capacitive loading; Countermeasure—use high-impedance probes and record a baseline before and after attachment
• FIB is costly and easily damaging: Phenomenon—failed FIB modification scraps the wafer; Cause—ion beam damage; Countermeasure—plan imaging first and outsource to professional services
• Trojan false positives: Phenomenon—normal redundant logic is mistaken for a Trojan; Cause—vendor designs include test/repair logic; Countermeasure—compare against datasheets and known circuit patterns, and do not publish low-confidence findings
• Lack of safety protection: Phenomenon—chemical decap accidents; Cause—failure to use a fume hood/protective equipment; Countermeasure—mandatory pre-step risk control at step 1