I don't know how the code protection bits work when a boot loader is in play - worth investigating. I would add some type of encryption to the datafile (maybe single DES if the code is small enough) and have the key unique to each chip. I don't know if this will work. --- In , Vasile Surducan <vasile@s...> wrote: > > > Hi Stef, > Suppose you are living in the East and send a hex file for uploading to > one of your customers (which have already bought your tool), learning him how > to upload and configure the stuff, you have created your own competitor. > He will produce a tool with your last firmware inside. And maybe will be > better than yours just by 30% modification he made. Reverse PCB to SCH is > a joke for someone having good eyes (and some years of experience). > > Of course a bootloader is a cool stuff. But I didn't see yet a mass > product (OTP, flash) without code protecting (only by mistake). > Looking to 16F88, a bootloader of 100 bytes without protecting the > page where the bootloader is located, means almost 4kbyte of memory, isn't > it ? It's ok. Unfortunately the Microchip distributors in the East of > Europe just say this chip exist. If you want to buy it is much difficult. > Like with the LF versions. > > top 10 wishes, > Vasile > http://surducan.netfirms.com > On Mon, 9 Aug 2004, Stef Mientki wrote: > > > > > > > > > > > >>If ICSP interface is the same as that for bootloader, then why using > > >>bootloader? > > >> > > >> > > > > > > > > >16F88 is not an ideal device for bootloader. > > > > > Hi Vasile, tell me why not ? > > > > > However, why using a > > >bootloader? A bootloader is usefull only in prototyping/developing stage > > >when the user is testing multiple routines and need too many > > >programming-erasing sequences. > > > > > Depends on what you want to achieve. > > As almost all my designs already I have need for USB communication (is > > functionality), > > bootloading is the most fantastic thing I've ever seen. > > Development and serial debugging is fast and easy. > > But even when the products are at my customers, > > I just send a them file, and they load it up. > > Sorry but I don't know any other way to achieve such easy upgrading. > > > > cheers, > > Stef > > > > > > > > > > > > > > > > to unsubscribe, go to http://www.yahoogroups.com and follow the instructions > > Yahoo! Groups Links > > > > > > > > > > |
|
16F88 bootloader
Started by ●August 8, 2004
Reply by ●August 10, 20042004-08-10
Reply by ●August 10, 20042004-08-10
> I would add some type of encryption to the datafile (maybe single > DES if the code is small enough) and have the key unique to each > chip. > > I don't know if this will work. It certainly won't create the worlds smallest bootloader. Note that breaking a cypher is much easier for a known-plaintext attack, and with PIC programs the first few instructions can almost be regarded as known. The choosen-cypher attack might crack the cypher even faster. There is some webpage about this approach (for a 8051 with external (encrypted) code). Bootloaders and code protection (in the sense of keeping your code secret) don't go together very well. Wouter van Ooijen -- ------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products |
|
Reply by ●August 10, 20042004-08-10
If you are REALLY that desperate to protect your work, then an option is
to send a replacement chip pre-programmed and protected, instead of a field update. If you give out the hex file in any form, it WILL come out in the open at some stage of the upgrade process - it can be captured right off the serial data stream to the bootloader. To implement any form of useful encryption in a bootloader is not AFAIK viable due to space. A simple XOR or substitution cypher can be easily hacked. There are some other ways around this, for example, one is choosing a chip that has individual bank read/write protection, so you can protect your bootloader, and load the useful code in the remaining banks - you can set the fuses as needed. In the case of an 18F452, you have 4x8kB banks, which make for a hefty bootloader which could incorporate a tougher encryption system. Personally, the only project that I've had to really protect I didn't allow the client to perform field updates, and a Dallas iButton served as a dongle to the PIC, so I could in fact "license" the hardware as required. The client could even have spare boards, but only so many iButtons. Best regards, Mike ----- Original Message ----- From: "rtstofer" <> To: <> Sent: Tuesday, August 10, 2004 9:14 PM Subject: [piclist] Re: 16F88 bootloader > > I don't know how the code protection bits work when a boot loader is > in play - worth investigating. > > I would add some type of encryption to the datafile (maybe single > DES if the code is small enough) and have the key unique to each > chip. > > I don't know if this will work. > --- In , Vasile Surducan <vasile@s...> wrote: > > > > > > Hi Stef, > > Suppose you are living in the East and send a hex file for > uploading to > > one of your customers (which have already bought your tool), > learning him how > > to upload and configure the stuff, you have created your own > competitor. > > He will produce a tool with your last firmware inside. And maybe > will be > > better than yours just by 30% modification he made. Reverse PCB to > SCH is > > a joke for someone having good eyes (and some years of experience). > > > > Of course a bootloader is a cool stuff. But I didn't see yet a mass > > product (OTP, flash) without code protecting (only by mistake). > > Looking to 16F88, a bootloader of 100 bytes without protecting the > > page where the bootloader is located, means almost 4kbyte of > memory, isn't > > it ? It's ok. Unfortunately the Microchip distributors in the East > of > > Europe just say this chip exist. If you want to buy it is much > difficult. > > Like with the LF versions. > > > > top 10 wishes, > > Vasile > > http://surducan.netfirms.com > > > > > > On Mon, 9 Aug 2004, Stef Mientki wrote: > > > > > > > > > > > > > > > > >>If ICSP interface is the same as that for bootloader, then why > using > > > >>bootloader? > > > >> > > > >> > > > > > > > > > > > >16F88 is not an ideal device for bootloader. > > > > > > > Hi Vasile, tell me why not ? > > > > > > > However, why using a > > > >bootloader? A bootloader is usefull only in > prototyping/developing stage > > > >when the user is testing multiple routines and need too many > > > >programming-erasing sequences. > > > > > > > Depends on what you want to achieve. > > > As almost all my designs already I have need for USB > communication (is > > > functionality), > > > bootloading is the most fantastic thing I've ever seen. > > > Development and serial debugging is fast and easy. > > > But even when the products are at my customers, > > > I just send a them file, and they load it up. > > > Sorry but I don't know any other way to achieve such easy > upgrading. > > > > > > cheers, > > > Stef > > > > > > > > > > > > > > > > > > > > > > > to unsubscribe, go to http://www.yahoogroups.com and follow the > instructions > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > to unsubscribe, go to http://www.yahoogroups.com and follow the instructions > Yahoo! Groups Links |
Reply by ●August 10, 20042004-08-10
I haven't thought this all the way through but you are certainly correct: if you know what the first few bytes must be then you are well on the way to breaking the cipher. But of course, the byte stream in the file doesn't have to be in memory address order as long as there is space available for reassembling it. Maybe there is an off-chip (E)EPROM... I doubt the approach is cryptographically secure but it just might be good enough to keep the curious at bay. Nothing is secure from the determined individual. --- In , "Wouter van Ooijen" <wouter@v...> wrote: > > I would add some type of encryption to the datafile (maybe single > > DES if the code is small enough) and have the key unique to each > > chip. > > > > I don't know if this will work. > > It certainly won't create the worlds smallest bootloader. Note that > breaking a cypher is much easier for a known-plaintext attack, and with > PIC programs the first few instructions can almost be regarded as known. > The choosen-cypher attack might crack the cypher even faster. There is > some webpage about this approach (for a 8051 with external (encrypted) > code). > > Bootloaders and code protection (in the sense of keeping your code > secret) don't go together very well. > > Wouter van Ooijen > > -- ------- > Van Ooijen Technische Informatica: www.voti.nl > consultancy, development, PICmicro products |
|
Reply by ●August 10, 20042004-08-10
Another approach if the encryption is trash is to hide the data in a snowstorm. Send a ton of bytes, some of which have useful data. --- In , "rtstofer" <rstofer@p...> wrote: > > I haven't thought this all the way through but you are certainly > correct: if you know what the first few bytes must be then you are > well on the way to breaking the cipher. > > But of course, the byte stream in the file doesn't have to be in > memory address order as long as there is space available for > reassembling it. Maybe there is an off-chip (E)EPROM... > > I doubt the approach is cryptographically secure but it just might > be good enough to keep the curious at bay. Nothing is secure from > the determined individual. > > --- In , "Wouter van Ooijen" <wouter@v...> > wrote: > > > I would add some type of encryption to the datafile (maybe > single > > > DES if the code is small enough) and have the key unique to each > > > chip. > > > > > > I don't know if this will work. > > > > It certainly won't create the worlds smallest bootloader. Note that > > breaking a cypher is much easier for a known-plaintext attack, and > with > > PIC programs the first few instructions can almost be regarded as > known. > > The choosen-cypher attack might crack the cypher even faster. > There is > > some webpage about this approach (for a 8051 with external > (encrypted) > > code). > > > > Bootloaders and code protection (in the sense of keeping your code > > secret) don't go together very well. > > > > Wouter van Ooijen > > > > -- ------- > > Van Ooijen Technische Informatica: www.voti.nl > > consultancy, development, PICmicro products |
|
Reply by ●August 10, 20042004-08-10
The key issue here is that if you can't code protect, any one can copy your bootloader and once that happens, all bets are off since the device would look and respond just like yours. Which PICs support CP of individual banks? It is probably a good idea to include a copyright statement in the code itself. This wont prevent theft but will allow easy proof of willfull infringement and, I'm-no-lawyer-but-pretty-sure, allow you to claim treble damages. On a side note - how secure is the code protection in the PIC line? I suppose some one with a scanning microscope could pry off the lid and figure it out. --- In , "rtstofer" <rstofer@p...> wrote: > > Another approach if the encryption is trash is to hide the data in a > snowstorm. Send a ton of bytes, some of which have useful data. > --- In , "rtstofer" <rstofer@p...> wrote: > > > > I haven't thought this all the way through but you are certainly > > correct: if you know what the first few bytes must be then you are > > well on the way to breaking the cipher. > > > > But of course, the byte stream in the file doesn't have to be in > > memory address order as long as there is space available for > > reassembling it. Maybe there is an off-chip (E)EPROM... > > > > I doubt the approach is cryptographically secure but it just might > > be good enough to keep the curious at bay. Nothing is secure from > > the determined individual. > > > > --- In , "Wouter van Ooijen" <wouter@v...> > > wrote: > > > > I would add some type of encryption to the datafile (maybe > > single > > > > DES if the code is small enough) and have the key unique to > each > > > > chip. > > > > > > > > I don't know if this will work. > > > > > > It certainly won't create the worlds smallest bootloader. Note > that > > > breaking a cypher is much easier for a known-plaintext attack, > and > > with > > > PIC programs the first few instructions can almost be regarded > as > > known. > > > The choosen-cypher attack might crack the cypher even faster. > > There is > > > some webpage about this approach (for a 8051 with external > > (encrypted) > > > code). > > > > > > Bootloaders and code protection (in the sense of keeping your > code > > > secret) don't go together very well. > > > > > > Wouter van Ooijen > > > > > > -- ------- > > > Van Ooijen Technische Informatica: www.voti.nl > > > consultancy, development, PICmicro products |
|
Reply by ●August 10, 20042004-08-10
Hi, The 18F452, for example, has four main banks, each of which can have different fuses, such as CP, read/write protect, etc. There is also a special 'boot' block that can be sepparately protected. I suspect other PICs in this series have similar configurations, but the one I've worked with hands-on is the 452. Regards, Mike ----- Original Message ----- From: "Phil" <> To: <> Sent: Wednesday, August 11, 2004 1:41 AM Subject: [piclist] Re: 16F88 bootloader > The key issue here is that if you can't code protect, any one can > copy your bootloader and once that happens, all bets are off since > the device would look and respond just like yours. > > Which PICs support CP of individual banks? > > It is probably a good idea to include a copyright statement in the > code itself. This wont prevent theft but will allow easy proof of > willfull infringement and, I'm-no-lawyer-but-pretty-sure, allow you > to claim treble damages. > > On a side note - how secure is the code protection in the PIC line? > I suppose some one with a scanning microscope could pry off the lid > and figure it out. > > --- In , "rtstofer" <rstofer@p...> wrote: > > > > Another approach if the encryption is trash is to hide the data in > a > > snowstorm. Send a ton of bytes, some of which have useful data. > > > > > > --- In , "rtstofer" <rstofer@p...> wrote: > > > > > > I haven't thought this all the way through but you are certainly > > > correct: if you know what the first few bytes must be then you > are > > > well on the way to breaking the cipher. > > > > > > But of course, the byte stream in the file doesn't have to be in > > > memory address order as long as there is space available for > > > reassembling it. Maybe there is an off-chip (E)EPROM... > > > > > > I doubt the approach is cryptographically secure but it just > might > > > be good enough to keep the curious at bay. Nothing is secure > from > > > the determined individual. > > > > > > --- In , "Wouter van Ooijen" <wouter@v...> > > > wrote: > > > > > I would add some type of encryption to the datafile (maybe > > > single > > > > > DES if the code is small enough) and have the key unique to > > each > > > > > chip. > > > > > > > > > > I don't know if this will work. > > > > > > > > It certainly won't create the worlds smallest bootloader. Note > > that > > > > breaking a cypher is much easier for a known-plaintext attack, > > and > > > with > > > > PIC programs the first few instructions can almost be regarded > > as > > > known. > > > > The choosen-cypher attack might crack the cypher even faster. > > > There is > > > > some webpage about this approach (for a 8051 with external > > > (encrypted) > > > > code). > > > > > > > > Bootloaders and code protection (in the sense of keeping your > > code > > > > secret) don't go together very well. > > > > > > > > Wouter van Ooijen > > > > > > > > -- ------- > > > > Van Ooijen Technische Informatica: www.voti.nl > > > > consultancy, development, PICmicro products > > > to unsubscribe, go to http://www.yahoogroups.com and follow the instructions > Yahoo! Groups Links |
Reply by ●August 10, 20042004-08-10
--- In , "rtstofer" <rstofer@p...> wrote: > > Another approach if the encryption is trash is to hide the data in a > snowstorm. Send a ton of bytes, some of which have useful data. Kinda like Windows ! ton of code, most is useless. I've never heard of it being called snowstorm, but it seems to fit. Dave |
|
Reply by ●August 10, 20042004-08-10
--- In , "Phil" <phil1960us@y...> wrote: > The key issue here is that if you can't code protect, any one can > copy your bootloader and once that happens, all bets are off since > the device would look and respond just like yours. > > Which PICs support CP of individual banks? > > It is probably a good idea to include a copyright statement in the > code itself. This wont prevent theft but will allow easy proof of > willfull infringement and, I'm-no-lawyer-but-pretty-sure, allow you > to claim treble damages. > IIRC, Tandy/Radio Shack took someone to court over the theft of their operating system. TRSDOS ???? The court was so stupid and so nieve about anything to do with compters. After much debate on both sides and huge sections of code being compared on the Tandy guys went to the other guy's box, hit some keys on the keyboard and brought up an Easter Egg that was a black screen with TANDY RADIO SHACK filling the screen. The opposing attourney claimed that is was a coincecence that some bits here and there could magically create the screen shot. Tandy lost. Go figure. |
Reply by ●August 11, 20042004-08-11
Dave Mucha wrote: A good engineer (with the right tools) can watch the functionality and put it into another processor.--- In p...@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:Another approach if the encryption is trash is to hide the data inasnowstorm. Send a ton of bytes, some of which have useful data.Kinda like Windows ! ton of code, most is useless. I've never heard of it being called snowstorm, but it seems to fit. So the real thing to worry about is protection of the functionlity of an idea and not the byte-code. And again Bill has found a trick to protect that: ensure that the behaviour differs every time ;-) Stef Dave ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Domains - Claim yours for only $14.70 http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/dN_tlB/TM --------------------------------~-> to unsubscribe, go to http://www.yahoogroups.com and follow the instructions |
|