Forums

ISP programming and code prrotection

Started by eeh March 11, 2005
Hi,

I know that many products support ROM upgrade or in system programming
(ISP). However, from my brain that logically to enable this feature the
mcu should not be locked.

So I have a question that whether the above thinking is right ro not.
Or if it is right, is it possible to make ISP possible and
simultaneously protect our firmware code from being read during
verification?

Thanks!

> So I have a question that whether the above thinking is right ro not. > Or if it is right, is it possible to make ISP possible and > simultaneously protect our firmware code from being read during > verification? >
Depends on the micro. Often, ISP is locked out once you enable the protection bits. Sometimes the verification process works by sending the new data to the micro twice; first time to burn, second time to verify. Sometimes you simply can't verify after setting the protection bits, in which case the procedure is to erase the device, program code memory, verify code memory, then program security bits. By definition, anyone who has the power to ISP-burn your micros has enough information to copy them.
Most firmware is encrypted and us e a bootloader with the right key. Look at 
the avr site and search for DES application.

SFC


"eeh" <eehobbyist@yahoo.com.hk> schreef in bericht 
news:1110527595.935544.315770@o13g2000cwo.googlegroups.com...
> Hi, > > I know that many products support ROM upgrade or in system programming > (ISP). However, from my brain that logically to enable this feature the > mcu should not be locked. > > So I have a question that whether the above thinking is right ro not. > Or if it is right, is it possible to make ISP possible and > simultaneously protect our firmware code from being read during > verification? > > Thanks! >
eeh wrote:
> Hi, > > I know that many products support ROM upgrade or in system
programming
> (ISP). However, from my brain that logically to enable this feature
the
> mcu should not be locked. > > So I have a question that whether the above thinking is right ro not. > Or if it is right, is it possible to make ISP possible and > simultaneously protect our firmware code from being read during > verification? > > Thanks!
Well you can't verify code if you can't read it!! What happens is you verify and then you set the code lock fuses, the code cannot be read then. To upgrade you have first to bulk erase the chip. The code is protected against all but the most determined attackers, some chips are better than others, in practice there are only a few instances where it's not easier to do your own. You need to take precautions when using chips with a self programming ability to make sure they don't modify themselves during powerup, brown outs, glitches, noise spikes ect.
On 10 Mar 2005 23:53:15 -0800, "eeh" <eehobbyist@yahoo.com.hk> wrote:

>Hi, > >I know that many products support ROM upgrade or in system programming >(ISP). However, from my brain that logically to enable this feature the >mcu should not be locked. > >So I have a question that whether the above thinking is right ro not. >Or if it is right, is it possible to make ISP possible and >simultaneously protect our firmware code from being read during >verification? > >Thanks!
For those chips that have self-programming capability, it would be possible to program using an encrypted comms protocol implemented in the bootloader. The bootloader would contain the decryption key. Some chips have limitations on the code protection possibilities when self-programming is enabled, but these can be worked around, e.g. by the main code making calls to routines 'hidden' in the protected bootloader area, and the bootloader validating the main code before allowing execution.
In article <d0ro58$6h7$1@reader08.wxs.nl>, sf-cillari@hetnet.nl says...
> Most firmware is encrypted and us e a bootloader with the right key. Look at > the avr site and search for DES application.
On what do you base that assertion? It certainly runs counter to my (limited) experience and none of the micros's I've worked with support this. The closest I've seen is a few chips that have an unlock key to enable reading of the OTP/EPROM on board but the firmware certainly wasn't encrypted. Robert
Maybe he's thinking of this...

http://www.atmel.com/products/SecureAVR/Default.asp

--
MT 


> Depends on the micro. Often, ISP is locked out once you enable the > protection bits. Sometimes the verification process works by sending > the new data to the micro twice; first time to burn, second time to > verify. Sometimes you simply can't verify after setting the protection > bits, in which case the procedure is to erase the device, program code > memory, verify code memory, then program security bits. > > By definition, anyone who has the power to ISP-burn your micros has > enough information to copy them. >
You can put an AVR in a state where you cannot read out and verify but you can still erase it. Protection AND reprogrammability. You can also have a selfprogramming application where you send down a 3DES encrypted file which is decrupted and programmed into the flash. There is an application note available on that subject. -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.
In article <z6KdnUEOHo4VTazfRVn-pA@golden.net>, marycoy4@execyulinky.comy 
says...
> Maybe he's thinking of this... > > http://www.atmel.com/products/SecureAVR/Default.asp
Beg pardon? Context man, context. Who's thinking of it in respect to what? Robert
Hi,

Alot of the new Motorola ( freescale ) parts have code protection based
around the interrupt vector table in flash... so to unlock the CPU for
reading/writing you need to have the hex file of the previously loaded
firmware in that device. When the device programmer wants to unlock the CPU
it starts the programming cycle by sending the vector table down, if it
matches the table on the device, the device is unlocked.

Renesas CPUs allow you to set a 10 byte code when your ISP programming the
device, then the next time you want to access the device ( to read / write
flash ) you are required to send the 10byte code, much like the Motorola
method above.

Most of the ISP programmers I've seen do this for you automatically, in the
first case they ask for the previous hex file and in the second case it can
load the 10 byte unlock code manually or from a file.




"eeh" <eehobbyist@yahoo.com.hk> wrote in message
news:1110527595.935544.315770@o13g2000cwo.googlegroups.com...
> Hi, > > I know that many products support ROM upgrade or in system programming > (ISP). However, from my brain that logically to enable this feature the > mcu should not be locked. > > So I have a question that whether the above thinking is right ro not. > Or if it is right, is it possible to make ISP possible and > simultaneously protect our firmware code from being read during > verification? > > Thanks! >