View previous topic :: View next topic |
Author |
Message |
Fabri
Joined: 22 Aug 2005 Posts: 275
|
firmware protection and bootloader |
Posted: Tue May 28, 2013 7:59 am |
|
|
Hy Guys,
I often send firmware to customer for update PIC with bootloader. I don't send the boot sector included but in any case the update firmware is complete program that can be programmed with the ICD2. For update customer use PC software developed by myself. I'm thinking way to protect firmware, customer can update it with my PC software but doesn't use it with standard pprogrammer as ICD2.
Have you got any suggestion ?
Thanks for help, |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Tue May 28, 2013 8:48 am |
|
|
Do a search here, for 'encrypted bootloader'.
Best Wishes |
|
|
Fabri
Joined: 22 Aug 2005 Posts: 275
|
|
Posted: Wed May 29, 2013 2:06 am |
|
|
Thanks for suggestion.
Anyway, I did search but I don't want a encrypted bootloader.
My possible solution is read exported firmware by MPLAB and do some changes manually or by software. In this way my customers cannot use "Hex" file to program PIC with standard programmer directly. They can use only my bootloader software to upgrade firmware. Usually I compile firmware by MPLAB and I need a simple way to export firmware with a simply changes without produce software to do so.
In your opinion, is it possible ?
Thanks,
Fabri |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Wed May 29, 2013 4:01 am |
|
|
I say again, encrypted bootloader....
Seriously, All you need is a program at your end to encrypt the hex file, and an encrypted bootloader. Then you do your mods, encrypt the file, and send this to your customer. The file won't then work in a programmer other than your bootloader. How complex you need to make the encryption is down to whether you are just trying to stop 'casual' use, or a serious attack.
A simple encryption, could just use a 'keyphrase', and xor the data characters with the characters from this in turn.
Understand, a hex file is a hex file. Unless it is scrambled in some way, then 'of course' it can be used with a standard programmer. To stop it being used with a standard programmer, it _has_ to be scrambled/encrypted.
There are a couple of other 'lesser' tricks you could use to make it fractionally difficult. One (for instance), would be to just relocate the data in memory using MPLAB, and save it at the new location. So (for instance) the code that actually has to be at 0x800 to work, you relocate to 0x197. Then all the internal jumps etc., will be to the wrong addresses if this is simply loaded with a programmer. Make your bootloader add an offset of 669 to the addresses it receives. Choose an 'odd' number for the offset, and it would stop the code working without needing anything else, but (of course) be pretty easy to crack. Remember whatever you do read protect the bootloader itself, or somebody can disassemble what this is doing.
Best Wishes |
|
|
Fabri
Joined: 22 Aug 2005 Posts: 275
|
|
Posted: Wed May 29, 2013 6:52 am |
|
|
Thanks Ttelmah,
your advice is always appreciated.
Relocate firmware is good simple way and I'll try it.
Can you suggest me one encryption software to study and try ?
Regards,
Fabri |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Wed May 29, 2013 1:02 pm |
|
|
Do a search for TEA. This is simple to implement, and quick. If you protect your bootloader, you can 'cheat', and use (say) the bytes at locations 0x100 to 0x10F as your key. It is not very secure, but it'd take significant work to crack it.
Best Wishes |
|
|
Fabri
Joined: 22 Aug 2005 Posts: 275
|
|
Posted: Thu May 30, 2013 12:07 am |
|
|
Thanks again for suggestion. I'll work around.
Regards,
Fabri |
|
|
|