Does a 'Secure' Bootloader that works w/ Code Protect exist?

[iso9001]

What I was wondering was if there was a way to distribute firmware to clients without them being able to reverse it. If you go with a normal bootloader you can update code no problem, but that code may as well be in plain text for even a basic hacker.

So, what I was thinking was if there was a deciphering bootloader that would update the code on a pic with the Protect fuse set.

Then source could be distributed freely and no one could reverse it without deciphering first.

Does somthing like that exist ?

(I've never looked at bootloader code so I'm not sure if its even possible)

[iso9001]

Sorry if this is a dumb question.

I'm just curious if its possible to offer code updates via web or such and still have code protection. I think the problem is the CodeProtect fuse....

No one ?

[ckielstra]

Please provide us with a bit more information.

Which processor are you using? For example the PIC18 has more protection options than the PIC16 series, some of the newer chip models might even have more options.

Protection is a word covering a very large area, what do you want to protect against? For example, I don't protect my application for it is running on dedicated hardware in a niche market. Anyone clever enough to reverse engineer my software can write the software himself in less time.

The different types of protection I can think of are, protection against:
1) unallowed copies of the hex-file (i.e. people have to pay for upgrades)
2) reading the program from the chip (for making copies, etc.)
3) reverse engineering your program
4) modification of the program hex-file
5) modification of the program on-chip

Some protections are easier to incorporate than others. I don't know if a bootloader exists that covers them all.

[iso9001]

Well....... all 5.

Mainly I'm pretty sure I need code protection on, its not like what going on is super top secret or anything its just that the math forumla's I've come up with took a very long time to figure out and I know people will want to try and hack it.

I also would like to offer upgrades to the software. Obviously I can not give out raw hex files b/c you could just figure out the processor (not yet determined but prolly an 18FXXX) and look at the asm.

What I wanted to do was install a modified bootloader that could decipher the data before writing it and have code protection on at the same time. However, I think if code protection where on then the bootloader could not rewrite the data no ?

If I could send out encrypted hex files with the serial number built in, set the pic to have code protection on, AND flash via bootloader over USB/RS232, thats a dream come true!

[iso9001]

Is it possible to have code protection on for the entire code , and use a bootloader ?

In any of the pic series ?

If not then it seems I have the choice of protected firmware in distributable format OR have a secure chip ... ?? That would be kinda lame.

[MikeValencia]

1-2 years ago, I think the following site claimed it was going to have firmware encryption for the PIC ready:
http://www.firmwareshield.com/

I did email them once a while back and asked if there was any PIC-related stuff for sale, and was bluntly told it wasn't ready yet and not to wait for it to be ready any time soon.

~~~~~~~~~~~~~~~~~~

Anyways, such a feature is pretty cool, but is it really practical to really have it?

In my case, my customers' idea of programming my embedded device is to have a screwdriver and to turn pots. It would be unthinkable for me to ask them to hook up a palm pilot to the device, or even to hook up the device to a laptop.

In my situation, my idea of a patch or upgrade is to ship a new unit and provide a UPS "RS" label (aka 'return shipment' label') for them to return the previous unit.

Think about what you're asking. You want to code protect that PIC. Protect it from who? The person who will physically be uploading the new .hex file into the PIC obviously has posession of the .hex file at some time before the PIC is actually re-flashed. So why protect the PIC at all?

[iso9001]

I want to encrpyt the hex AND have code protection ON.

I think it would be rather simple to modify a bootloader into decrypting before writing the data. But I think the problem is with the code protection part.

I'm shocked there isn't a way to do this, seems really simple and of value to anyone sending flashes out.

I could code an RS232 reflasher prety damn easy so.... I don't know, I'm just shocked this doesnt exist.

[Guest]

Hi iso9001,

I've been searching for something like this for a year or so. The closest I've gotten can be found on the microchip forum...

http://forum.microchip.com/tm.aspx?m=126770&mpage=1&key=&#133847

I contacted jbroadwell at the beginning of January asking for more in-depth details. He sent me a test program and told me to keep an eye on his website (www.serialwombat.com) for documentation supporting his encrypted bootloader.

I haven't had time to figure out the example he sent, it's written for Microchip C18.

-Paul

Ps This is something that's needed for PIC, Atmel have a free encrypting bootloader

[iso9001]

That guys code looks like he has code protection ON and is using eeprom_writes ???... I thought that was the problem.

I could do something very similar with twofish (much faster the xtea i think) but I thought the problem was the telling the pic to write over its own program memory when protection was ON.

I guess not ?

[newguy]

iso,

I'm pretty sure that code protection only scrambles external reads from program memory - I don't think it disables internal writes to it.

Why don't you throw together a really short program to test it? Something like this...

Do a read of certain address in memory - something 'high up' so it will be unused by your short program. Print this value to an lcd or spit it out the serial port. Then write something to that address. Once the write is complete, read it back and spit it out again (lcd or serial). If it spits out what you wrote, you have your answer. Of course, make sure the code protect fuse is enabled.

[ckielstra]

[iso9001]

Cool,

I'm away from my equipment right now, just researching an idea. But I will try it when I get back to work.

I guess all I'de need to do it find a bootloaded in C, preferably written for ccs and add my encryption code onto it.

Easy right

[iso9001]

For the serial, I'll just request the serial of the machine it plugs into and then ask them for that. So my chip knows the serial of the unit its talking to and I ask the user for / can make an encryption for it. And best of all I don't need to program with any serial numbers (yay!)

I wanted to use blowfish, but storing 4k worth of tables is NOT going to work. Also I'de have to work with all 8 byte blocks. I might be able to scoot away with some lame XOR deal but I think I'll look into that one guys xtea before I do that.

One concern I have is running out of room using a 16F876 size chip. Just the can driver from CCS is 30% rom... although it needs some optimizing badly! I'm not sure how large the bootloader will come out to, but add some there, then I'm not sure how much is really left for my program code, it will be fine I think, just was a little suprised to see the mcp2515 driver taking 30% !

You guys are always a help!

Anyone have a CCS compilable bootloader on hand ?

[ckielstra]