| View previous topic :: View next topic |
| Author |
Message |
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
| 3.3Volt system, code protection, and BootLoader |
 Posted: Sun Oct 10, 2004 5:38 pm |
 |
|
Last time I posted this topic, I came to the conclusion any new 3.3 Volt project PC board should have jumpers to allow the uP section to be powered at 5 Volt to allow complete chip erasure including FUSES.
On a new project I added a jumper and the CPU can be powered at 5Volts.
I'm not having consistant results, some chips that were programmed (at 3.3Volts) with the PROTECT fuse enabled will erase when powered at 5 Volts, other will not.
Has anyone had similar problems ?
On this same subject 3.3Volt and Code protection:
I would like to use a boot loader (via BlueTooth) and at the same time use the PROTECT fuse. Is that possible ?
As it seems to be impossible to erase fuses on a 3.3Volt system, does it mean code loaded with a boot loader must remain readable ?
There was a thread somewhere on the forum about bootloader and code encryption, it would seem if the Protect Fuse can't be used then there is little point in worrying about encryption !
Can a boot loader write program memory even if the PROTECT fuse is set ?
If so what's stopping somone from reading program memory with a modified boot loader ?
What am I missing here ? |
|
 |
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Sun Oct 10, 2004 7:14 pm |
|
|
| Quote: | Can a boot loader write program memory even if the PROTECT fuse is set ?
|
There are 3 types of settings for the program flash.
Code Protect
Table Read Protect
Table Write Protect
The first deals with reading/writing via external means. The pic itself can still read/write/erase its flash program
The latter two would prevent a bootloader from functioning correctly.
| Quote: |
Can a boot loader write program memory even if the PROTECT fuse is set ?
|
If code protect is what you mean then the answer is yes.
If you have a bootloader and someone has a means to access it and the code is not encrypted then your IP is out there for the taking. |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
|
| Posted: Sun Oct 10, 2004 8:55 pm |
|
|
So the trick is to protect the bootloader, and the program memory.
Of course I'll play with it all before too long.
I have not used table write/read protect, not sure if that leaves my code exposed or not.
Thanks for the tip. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sun Oct 10, 2004 10:17 pm |
|
|
| Bootloaders use table reads and writes. Enabling both leaves your code exposed. The 18F series enables you you perform code protection in selectable banks but IMHO the granularity of control is far too course to be of much use. |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Thu Oct 14, 2004 8:07 pm |
|
|
Then what would be the best way to protect out intelectual property?
I am thinking about to burn the bootloader and kill the B7 pin (applying 12v in it) so no one can read the pic, but I will still be able to do firmware updates. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Thu Oct 14, 2004 9:15 pm |
|
|
The problem occurs when someone loads a worm via the bootloader. Such an appication could perform a table read operation over the entire address space of the PIC and send that out via a serial HW or SW interface. The 18F provides mechanism to protect against this but, as I mentioned earlier, IMHO it is too course to be useful.
You end up with the choice, do I want to protect my IP [b]OR[/] do I want the flexibility of bootloading?
A work around is to use a proprietry bootloader (the encoding algorithm is not published) then you could implement proprietry encrytion of the hex file to be programmed. If the bootloader supports uploading the code from the PIC then obviously this needs to be encrypted as well.
Last edited by asmallri on Thu Oct 14, 2004 9:56 pm; edited 1 time in total |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Thu Oct 14, 2004 9:37 pm |
|
|
| Quote: | | I am thinking about to burn the bootloader and kill the B7 pin (applying 12v in it) so no one can read the pic, but I will still be able to do firmware updates |
B7 isn't the problem! The bootloader is! |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Thu Oct 14, 2004 10:23 pm |
|
|
Yes, but when someone tries to steal my code writing a worm into the pic, my code or part of it will be overwritten.
It will be very difficult to restore it into its original state. |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Thu Oct 14, 2004 10:35 pm |
|
|
| The first instruction is usually a jump to a routine. If someone were to load a "worm", they could load this at the beginning of the program and dump the rest of the memory. Then they would take another chip, load the "worm" at the end of the chip and dump the first part of the memory. So, an unencrypted bootloader opens yourself up. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Thu Oct 14, 2004 10:46 pm |
|
|
| future wrote: | Yes, but when someone tries to steal my code writing a worm into the pic, my code or part of it will be overwritten.
It will be very difficult to restore it into its original state. |
Not so. If I had access to two of your devices and guessed as to which class of loader you have used, I would almost be guarenteed to recover 100% of your code unless you have used some of the internal protection features.
With a single device I still have a very high probability of recovering your code as it it unlikely you would have filled the code space of the processor. If you use a "standard" loader I could guess the address map and place my worm in the address space in close proximity of the base of the loader (in the case of a loader in high memory).
On the other hand if you put some of your code in protected memory (stable code that you would never need to replace) then you could protect this code from table reads and writes.
I recently discovered a bug in one of my loaders that required me to replace a loader in multiple remote operational systems located 2000 kilometes away. The loader has inbuilt protection in the loader code to stop an application program from being loaded on top of the loader. I achieved the patching of the loader by using the existing loader to load a remapped stripped down version of the loader into a different part of memory and pass control to this patch loader. Once this was done I then was able to load the new (repaired) loader over the original bootloader. I could have done anything with this system. The patch loader is capable of modifying just a single byte of code if necessary.
For this particular application, I realised the security problem of using loaders but the benefits of bootloader outweighed the risk of someone stealing my IP and reproducing my systems. A also embedd copyright messages into the code space for what it is worth.
I have another project that does not use a loader today because of the IP problem but I have got to the stage where I need to be able to support remote code upgrade of for new versions of these devices. I am working on a loader that will support encryption to address this problem. |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Fri Oct 15, 2004 12:05 am |
|
|
I am using the tiny bootloader at the moment as I dont have the knowledge to write my own stuff.
http://www.ac.ugal.ro/staff/ckiku/software/picbootloader.htm
My project turned out a nice product and because of this I am now looking for security.
I know that a motivated person can do magic to get my code, but if I can make things harder to him I will do.
Maybe when I sell it, it will go without a bootloader... which fuses can make anyone unable to read the pic? |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Fri Oct 15, 2004 7:25 am |
|
|
| Quote: | | which fuses can make anyone unable to read the pic? |
Thank depends on the PIC. You will have to look up the spec sheets for your PIC. |
|
|
Guest
|
|
| Posted: Mon Oct 18, 2004 8:28 am |
|
|
The best solution is a proprietary bootloader that only loads encrypted hex-files. My company does this for years.
Regards |
|
|
theteaman
Joined: 04 Aug 2006
Posts: 98
|
|
| Posted: Tue Jan 30, 2007 5:48 am |
|
|
Sorry to bring this thread back from the dead but I thought people would prefer this to starting a new thread.
I too have a system where I need to enable 'firmware upgrades' via a bootloader (COLT). I am worried that, as I release new firmware upgrades (as .hex files), anyone can read them.
Can someone tell me examples of what these proprietary bootloaders are that use an encrypted hex file?
Thanks |
|
|
davekelly
Joined: 04 Oct 2006
Posts: 53
Location: Berkshire, England
|
|
| Posted: Tue Jan 30, 2007 7:15 am |
|
|
I made a simple encrypted bootloader a few years ago, by XORing every byte read with a constant.
The downloader XOR's with the same value before sending.
Simple, and can be cracked if someone wants to analyze it, but the technique can be expanded to improve the security should it be demanded. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
