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

  • That's what I've tried to say (and what I believe product specification describes clearly): NO, you cannot "flash a piece of code somewhere to the device flash" once you enable readback protection (UICR->RBPCONF register set to ALL = 0xFFFF00FF). The only way how to flash the code over SWD is to erase entire chip (again through UICR registers) and then flash it with your own code (but entire flash is set to default 0xFF..FF value at that moment so you cannot see the previous FW). However this is theory and in practice there are some (less comfortable but known and documented) ways how to defeat such a chip:

    (1/2 - continue)

Reply
  • That's what I've tried to say (and what I believe product specification describes clearly): NO, you cannot "flash a piece of code somewhere to the device flash" once you enable readback protection (UICR->RBPCONF register set to ALL = 0xFFFF00FF). The only way how to flash the code over SWD is to erase entire chip (again through UICR registers) and then flash it with your own code (but entire flash is set to default 0xFF..FF value at that moment so you cannot see the previous FW). However this is theory and in practice there are some (less comfortable but known and documented) ways how to defeat such a chip:

    (1/2 - continue)

Children
No Data
Related