Hacker News new | ask | show | jobs
by mechagodzilla 2714 days ago
1) One could feasibly wire to nearby power/ground, although that would certainly be more obvious. The clock for this is ~17 MHz (I believe), so one can certainly achieve 'good enough' with a microcontroller's internal clock.

2) While that is an obvious countermeasure, it's one nobody is currently taking (judging by the large block of 1's in the SPI flash chip he read from the server).

3) You're thinking of a protocol like I2C, not SPI. For SPI it's 1 input driving 1 output, and nothing is bi-directional, so a microcontroller or FPGA interposing itself on a data line can definitely modify the state (or pass it through unchanged) as it pleases.

<edit> It's worth pointing out that, given that the contents of the flash get predictably read out at boot time, you could probably let the device 'train' to calibrate it's internal (poor) clock and any software-based adjustments to its timing guesses over multiple boot cycles. Especially if you have access to identical hardware for initial lab testing.

1 comments

Okay, I am in the habit of using pulls, and even some micros have pulls that can be switched in. That may be pointless when there is only one slave on the SPI, as it probably is in the attacked system, as the /CE is probably strapped active so the device will never switch that pin to high Z.