EmbeddedRelated.com
Forums
   Forums    More Forums    piclist  

16F88 bootloader

Started by upand_at_them ●August 8, 2004
Reply by rtstofer ●August 10, 20042004-08-10

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
> >
> >
> >
> >
> >
Reply by Wouter van Ooijen ●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 Michael Puchol ●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 rtstofer ●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 rtstofer ●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 Phil ●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 Michael Puchol ●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 Dave Mucha ●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 Dave Mucha ●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 Stef Mientki ●August 11, 20042004-08-11


Dave Mucha wrote:
--- In p...@yahoogroups.com, "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.
A good engineer (with the right tools) can watch the functionality and put it into another processor.
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



You might also like... (promoted content)
Check out Memfault's New Sandbox!
Check out Memfault's New Sandbox!
Check out Memfault's New Sandbox!