Failing eeprom-writes
Ok, so we found out that EEPROM-writes can be detected; perhaps that's usable to
disrupt the workings of the microcontroller and get to the juicy hard disk contents?
Perhaps there is: if we can detect the writes to the EEPROM, we may also be able to
disrupt them and make the PIC write random data or, even better, no data at all.
In order to do this, I created a small circuit, as documented in this sketch. PIC
is on the left, the AVR I used to be quick enough is on the right.
It works as follows: the 330 ohm resistor is used as a shunt: if the PIC draws more
current due to a write to the EEPROM, the voltage over the resistor will increase
slightly and the voltage on AIN0 on the AVR will lower slightly. The AVR compares
that to a threshold set on the AIN1-pin and when that pin is higher than the AIN0-pin,
it knows the PIC has started a write.
When the AVR has done that, it can decide to disrupt the write by making PB2 high. That will make the BC550 short the VCC-pin of the PIC to the voltage set by the constant voltage source made of the BC560 and its accompanying potentiometer. With the voltage on that potentiometer set to a sufficiently low level, the idea is that the code in the PIC keeps running but the write to the EEPROM gets disrupted.
The target for this attack is the factory reset procedure the hard disk enclosure has. The theory is as follows: When the hard disk factory reset is initiated, as you might rememberthe PIC will decideon a new key to send to the INIC-chip. It'll write that plus the default password to its EEPROM, overwriting the old password and key. If we can somehow make the writes to the new password not take place, we can reset the password we have to enter but not reset the key sent to the INIC, meaning the old data would be available by the known password.
To skip forward a bit: Did it work? The answer is: partly. I did manage to lower the voltage while the EEPROM-write happened to such a level that the write failed. The problem is that it didn't completely prevent the EEPROM from writing: it didn't write what the software intended but it did corrupt the data, making the hard disk completely inaccessible.
One good thing came out of it: this approach did affect the two bytes written when a wrong password was entered: the PIC would write bogus data when it tried to record the amount of tries left. At least that seems a viable way to disable the bruteforce check. Still, entering passwords one by one would be a bit slow, with at least two second taken by the PIC blinking its LED to indicate the password is wrong.