Erik Malund wrote:
-------------------------------
Jay, I were referring to your comments re. the possibility of a hacker changing the contents of a serial eprom.

- - - - - - - - - - - - - - - -
Oh, the point I was making there was that putting machine code into a serial EEProm to be loaded and run out of RAM is particularly bad. While serial EEProms are normally used for data, changing that data doesn't lose control over the microcontroller; ie the machine code remain unalterred even if someone were to pollute the calibration data. The until could always be recalibrated and messing with data isn't really an attractive hack since it may be overwritten.

What was particularly dangerous about storing machine code in EEProm would be that something more powerful is available to the hacker; control.

As I painted the scenario, a diabolical competitor could substitute the EEProm machine code segment with one that randomly cause a malfunction; not always which would be easily diagnosed, just infrequent enough for the customer to think the product was inferior. Consider it a false triggering of the alarm.

If not for the machine code in serial EEProm, the hack would not be as inviting. The rest of the machine code is safe inside the OTP offering no access.

I didn't say this was a likely scenario, just one a designer should be aware of. Why increase a products vulnerability if doing so is not an advantageous tradeoff for marketing?

aka j