Bootloader Firmware Code Readout Protection

[RickMarsen]

I am wondering about the best way to protect my firmware from being read out by someone with access to the PIC's ICSP electrical connections.

I adapted the CCS bootloader example to use an FTDI device instead of RS232. That works well. I then provided the customer with the main application that gets loaded later on (using the bootloader).

The idea has always been that I load each unit with the bootloader using the CCS TagConnect and then let the customer load the main application at some later point in time. This way I can track how many units are in circulation. However, a real keen young engineer at the customer’s company hand soldered wires to the TagConnect pads and read out the entire contents of the PIC using an ICD-U40.

The readout contained both the bootloader and the main application, but he was able to extract just the bootloader and reload it on a bunch of new units, effectively cutting me out of the loop. It wasn’t a malicious move, but it definitely got me concerned.

It was my fault, in that I didn’t set the fuses to prevent the firmware from being read out. I now have a chance to make some tweaks on both pieces of firmware and wanted to build in the missing protection.

Q: Do I need to add a protection fuse to just the bootloader firmware, just the main application, or both?

I also have a lightly used 25LC512 serial eeprom on board if anyone has any slick suggestions on additional “hooks” that can be put into place.

Please let me know if/how any of you have successfully protected your bootloader-based projects.

Thanks;
Rick

Here are two snippets from my unprotected code

[asmallri]

It is possible to set the fuses to prevent both the bootloader and/or the application from being read via the ISCP port. However care still needs to be taken with a non encrypted bootloader as it is possible for someone to bootload code to the target that prints out the contents of the program memory.

For example, lots of bootloaders are located in low memory with the application loaded immediately above the bootloader. If the PIC program memory is not full, it would be possible to bootload a program into high memory and dump out the contents of program memory below this code. Doing this would mean the reset vector of the original code would be lost and it is possible the existing user application could be overwritten - either way this would be a destructive read method.

If you used an encrypted bootloader then the "reader code" could only be loaded to the PIC if it was encrypted with the appropriate encryption key.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!