This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to protect chip from reflashing

Lets say, that I've got a chip with program in its flash. I know I can protect it from being read back, but can I protect it from flashing anything else through debugger interface? The thing I want to achieve is to disable the possibility of "program injection" which would steal the data.

Parents
  • Hi Konrad,

    It's true that you cannot by SW (= through registers) prevent erasing the chip and programming again (which saves a lot to SW guys who don't have time and budget to build custom HW - just pick some nRF5x based product with accessible JTAG/SWD on eBay/Aliexpress/anywhere and "hijack" it for your project - I know what I'm taking about;). However by design there should be no way how to "inject" the code and dump the memory. The only way to work with such a "locked" chip is to erase the flash (+UICR) and just benefit from the HW but not original FW.

    It's true that nRF51x22 has weaker read back protection and there already exists pretty detailed guidelines on the internet how to dump the FW (with a bit of luck and knowledge of SWD&OCD). However that particular attack isn't real program injection but rather problem with CPU registers being accessible (JTAG/SWD debugger isn't killed completely when read back protection is ON). So if you are really concerned about your FW reverse engineering then you should go with nRF52 which has this bug fixed (of course nRF5x isn't meant to be temper resistant HW so you should have in your HW separate IC - e.g. some smart card chip - to hold all your secrets and also perform all sensitive operations if possible). On nRF51 I can imagine only some HW ways how to make the attack more difficult (e.g. by shorting the SWD lines after production testing, using "hard" casing - e.g. complete plastic or epox shield - or similar). However if your FW is really valuable to the attacker then he can carefully extract the chip from PCB and explore the SW vulnerability anyway.

    Cheers Jan

  • Thanks for your answer. We're preparing our device for production, so we're searching for the way to protect it in every possible way. Thanks for some useful guidelines how to achieve that. As far as I understood, you are writing about entire program erase and reflashing. But is possible the scenario, that someone flashes a piece of his own code somewhere in the device, which will dump the memory from flash on the SPI lines and read the valuable data stored in the device and forces it to execute?

Reply
  • Thanks for your answer. We're preparing our device for production, so we're searching for the way to protect it in every possible way. Thanks for some useful guidelines how to achieve that. As far as I understood, you are writing about entire program erase and reflashing. But is possible the scenario, that someone flashes a piece of his own code somewhere in the device, which will dump the memory from flash on the SPI lines and read the valuable data stored in the device and forces it to execute?

Children
No Data
Related