Searching \ for '[PIC]: FINAL WORD: A great solution for the PIC16' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'FINAL WORD: A great solution for the PIC16'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: FINAL WORD: A great solution for the PIC16'
2001\07\25@082303 by Ron Anthony

flavicon
face
Hello all.  Well I got the word today from Microchip, the 18F442-I/L (40 MHz
only standard, Industrial rating standard) will not be availbe in shipping
quantity until December at the earliest.  Those engineering samples were
first run only, they need more runs, and then wide distribution samples
before they ship in qty.  As for the 77A revision to the F877, it won't be
out until after the new year, likely March.

So, if anyone is using the F877, you are stuck with the copyable flash and
memory-dumpable code protected region from pirate code getting past your
bootloader.  Basically the chip is very, very weak and unfortunately is a
poor design.  They've fixed it in the 77A and 18Fxx2, but it took forever,
and is stil not fixed for another 5 months.  And, if weak chips get into the
stream, you can't close pandora's box.

So, do your best, but know you are delaing with a weak chip.  Darn!!!!!  And
to think the 18F gave me that glimmer of hope, just to take it away again.
That was a mind screw I didn't need.  The 16F877:  great little chip, even
better for hackers and reverse engineers and code copyers.

Ron

{Original Message removed}

2001\07\25@170824 by David Dunn

flavicon
face
i still think you're taking a fringe view on this. very few people  use a bootloader in a production environment, so
for 99% of everybody out there, including myself, thier code on a 16F877 is perfectly safe from all these evil
hackers you refer to with the available-right-now code protection features.

i'm sure since it won't do what *YOU* want it to do, and that's all *YOU* care about, it seems like it's a bad part,
but i think you are out of line posting things like this. back in the real world, *YOU* are probably the only one
having a problem because *YOU* failed to design with parts that are available.

dld


{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\07\26@022746 by Ron Anthony

flavicon
face
David, with all due respect, and to be perfectly and objectively factual,
with no reasonable debate about it, Microchip TOTALLY BLEW IT on the flash
part.  Case closed.  They blew it so badly that between the 77 and 77A, they
completely revamped their fundamentally flawed design.  They made some
horrendous design decisions and committed them to silicon with the 77.  It's
a flash part, but if you want it flashable, it must be naked.  If you want
it secure, you must turn the flash into OTP.  This couldn't be a worse
situation.

Now don't get me wrong, it is a great chip.  As far as designing for the
wrong part, this could not be further from the truth.  It is what was
available, and we designed for it.  However, to overcome the chip's
weakness, I'm at this very moment spending hour after hour on a
mind-numbingly complex kernel that every thread must jump into code
protected space and out again, to keep the code secure.  And the encrypted
bootloader?  Unbelievably complex.  All this wasted effort to overcome a
very bad design decision by Microchip. And that the 77A was slated for
release more than 7 months ago?  Inexcusable.  Basically, Microchip was
aware of the code protect flaw but determined that a part that was selling
well (the 77) didn't have pressure on the revision A to come out, what's the
big deal if it slipped and people's code gets whacked by their respective
mortal enemies?  By the time the 77A ships, AFTER the 18F series, it will
have been more than a year late.  Why??  For a die shrink?  Come on.

And, beyond that, you can't even flip pages reliably with a single
instruction, so it takes massive code space over the course of the code just
to handle the flips.  I will say thay by the time I'm done, at least 25% of
the code space will be the page flipping instructions, and another 25% will
be the mind numbing encryption algorithms.  So my 8k chip is now a 4k chip,
with only half of the lower 4k (open and naked flash memory) available for
flash updates, which will be naked to ICSP reads once they land on the chip.
So instead of 8k secure flash memory, 100% updatable, I get 2k of flashable
memory that is naked to ICSP reads, and 6k of flash that is no longer flash,
but is OTP.

And I've got to grind off the chip markings to throw one more road block at
some unknown hacker who may not even exist.  What a joy!

The fact remains that little old me is picking up the slack of a
multi-billion dollar company that gave **no consideration whatsoever** to
the fact that the ONLY part of their chip that is not a commodity is the
code that resides inside.

Defend that?  NEVER!!!!

{Original Message removed}

2001\07\26@024019 by David Dunn

flavicon
face
On Wed, 25 Jul 2001 19:57:30 -0400, Ron Anthony wrote:

>David, with all due respect, and to be perfectly and objectively factual,
>with no reasonable debate about it, Microchip TOTALLY BLEW IT on the flash
>part.  Case closed.  They blew it so badly that between the 77 and 77A, they
>completely revamped their fundamentally flawed design.  They made some
>horrendous design decisions and committed them to silicon with the 77.  It's
>a flash part, but if you want it flashable, it must be naked.  If you want
>it secure, you must turn the flash into OTP.  This couldn't be a worse
>situation.



your thinking is fundamentally flawed already. it's perfectly secure as a part you can reprogram as many times as
you like. i know this, because i've done it, hundreds of times already.

flash the chip / erase the chip / flash the chip / erase the chip . . . ad infinitum

there is nowhere in that cycle that anybody can get to your code. it's secure.

when the write protect is on, you can't flash the chip, it must first be erased, which means the chip is perfectly
secure, and perfectly reusable, as many times as you like. i simply can't understand why you can't see this; it's
not even close to a OTP part.

somewhere along the line you've gotten a poor understanding of how the flash / code protect works together.  i
don't know where you got this bad info but i think you need to step back and look at it anew.



{Quote hidden}

again, this is all based on your presumption that the part is flawed, which it clearly is not.  the bottom line is
that you designed for a part that doesn't exist. period.

your mistake, not microchip's.

again, i appreciate your dilemma, and i hope you find a solution, but i think you are out of line blaming microchip
for a part that works just fine, exactly as it was intended to, and is being used by thousands every day with no
problems whatsoever.


david dunn

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@024643 by David Duffy

flavicon
face
Ron Anthony wrote: (to another David !)
>David, with all due respect, and to be perfectly and objectively factual,
>with no reasonable debate about it, Microchip TOTALLY BLEW IT on the flash
>part.  Case closed.  They blew it so badly that between the 77 and 77A, they
>completely revamped their fundamentally flawed design.  They made some
>horrendous design decisions and committed them to silicon with the 77.  It's
>a flash part, but if you want it flashable, it must be naked.  If you want
>it secure, you must turn the flash into OTP.  This couldn't be a worse
>situation.
<snip>

Why does it become OTP if you want it protected? If you set the code protect
on the 'F877, you can still re-flash the chip any time you like can't you? It's
just that you can't have a protected chip and a boot-loader at the same time.
Correct me if I'm wrong, but that's the way I understand it to work. If I'm
right,
the protect thing is not an issue for the rest of us who don't use
boot-loaders.
Regards...

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@025944 by Ron Anthony

flavicon
face
The chip is 100% re-flashable after code protection only if you get your
hands on the chip again, or recall every unit from around the world to do in
house flash updates.  The logistics of that are so overwhelmingly
prohibitive that it can't be done.

You are presuming that I can get my hands on the chip again once it's in the
field.  Let's assume that's possible.  Do you think I am going to receive
envelopes mailed from around the world with chips inside, erase, reflash and
code protect, and then mail back out to everyone?  The postage and handling
will exceed the value of the chip.  Better yet, let's say every six months I
re-issue a new chip.  Now I've got tens of thousands  (and more!) of
consumers, not engineers, removing their circuit boards, using a butter
knife to pop out the old chip, and put in the new?  One cracked socket and
now we've got to replace the boards.  And, who is going pay for all the new
chips?  Me?  Them?  Nobody wins except microchip, and I'll be damned if I am
going to reward them by buying any more of this chip than I need to.  My
only solution to preserve in-the-field-flash-upgradability and lower-half
security is to go through the coding hell I'm going through as I write this.
And the chip spends about 20% of its time just coping with the page flips
(which in and of themselves are ridiculous) and as well decrypting the
encrypted code.  And the upper half is locked OTP, the lower half is all
naked, with half of it just jumping in and out of the upper OTP half.  Talk
about a total freakin' MESS!!!!!!

Very simple:  Allow me to disable ICSP reads no matter what, and allow me to
disable internal reads of the flash memory, but allow internal flash to be
re-written.  So simple, they've done it now with the 77A and 18F series.
And left me holding the bag with the miserable 77 for at least the next half
of a year.

Face it, I'm screwed.  Can't do a chip recall, it's far too
expensive/inconvenient/ridiculous/pathetic.

Ron


{Original Message removed}

2001\07\26@031412 by David Duffy

flavicon
face
Ron Anthony wrote:
>The chip is 100% re-flashable after code protection only if you get your
>hands on the chip again, or recall every unit from around the world to do in
>house flash updates.  The logistics of that are so overwhelmingly
>prohibitive that it can't be done.

This applies to your situation - not everyone else works the way you do.
Every engineer has to way up the cons & pros before committing the design.

{Quote hidden}

If your product can be upgraded, then charge them for the upgrade chips.
That's exactly what other companies do. If the upgrades are to fix problems
with your product in the field, then that's another matter entirely. Yes. it
would be nice to have a protected boot-loader but that's life for now.  :-)

>Very simple:  Allow me to disable ICSP reads no matter what, and allow me to
>disable internal reads of the flash memory, but allow internal flash to be
>re-written.  So simple, they've done it now with the 77A and 18F series.
>And left me holding the bag with the miserable 77 for at least the next half
>of a year.
>
>Face it, I'm screwed.  Can't do a chip recall, it's far too
>expensive/inconvenient/ridiculous/pathetic.

Yes, you are screwed. Sorry, but I can't think of a way around it.
Regards...

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@040429 by Alan B. Pearce

face picon face
>Very simple:  Allow me to disable ICSP reads no matter what, and allow me
to
>disable internal reads of the flash memory, but allow internal flash to be
>re-written.  So simple, they've done it now with the 77A and 18F series.
>And left me holding the bag with the miserable 77 for at least the next
half
>of a year.
>
>Face it, I'm screwed.  Can't do a chip recall, it's far too
>expensive/inconvenient/ridiculous/pathetic.

Having followed your rant somewhat I suspect you are going about your design
philosophy and reprogramming the wrong way

First, I wonder how often you will really need to do an update in the field.
If you really expect to upgrade more than a couple of times, I suspect that
that design procedure/verification has some holes.

Second, if you see reprogramming as feature upgrading this is surely a
chargeable thing in which case you build in the cost of a chip, including
some sort of carrier PCB if necessary. This is not that hard to do, for a
DIL chip it may just mean having the chip in another socket. Been there done
that swapped out thousands of EPROM's this way when I was doing technical
support and had some ham fisted engineers in the field.

Third, if your product is such that it is worth reverse engineering, and you
are thinking of having it field upgradeable by a bootloader, the very first
upgrade will be reverse engineered no matter how encrypted the download code
is. You only have to look at the hackers involved in disabling/reverse
engineering PC based code using all sorts of protection schemes to realise
that nothing is unbreakable. This would apply even if you could get your
hands on an F877A.

Fourth, your comment about having a quarter of the code as bank/page
switching as you go in and out of the protected area of the chip suggests to
me that you need to rethink the design philosophy of the code. When RCA
brought out the COSMAC chip they had an interpreter system that they wrote
their editor in which had subroutines represented by tokens. It was very
efficient and as a scheme would suit your purpose well. Have the subroutines
in the protected area and the tokens in the unprotected area would make it
very hard to reverse engineer the product. You then only ever upgrade the
tokens using the bootloader. I do not know if any of the Basic products for
the PIC could be set up this way, but there is certainly the basics of an
interpreter available on the web.

I suspect that you have not really thought through the problems associated
with the access you make available by having the code available through
download. If it is really such a precious commodity the only way to make it
hard for a reverse engineering attempt is chip exchange.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@040838 by V sml

picon face
Ron, assuming you have your wish list fulfill, but bootloader is still
bootloader, how are you to protect the code that you are sending into the
chip?  and you would probably need a modem onboard for you to do it
professionaly and trouble-free for the customer.  You need a total solution.
There are people selling that.

cheers, ling sm

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@043623 by Roman Black

flavicon
face
Ron Anthony wrote:
>
> The chip is 100% re-flashable after code protection only if you get your
> hands on the chip again, or recall every unit from around the world to do in
> house flash updates.  The logistics of that are so overwhelmingly
> prohibitive that it can't be done.

Hmmm.

{Quote hidden}

Hi Ron, i've been watching this thread and I dont
like to sound mean, but "fix the solution, not the
problem" to butcher a Japanese expression.

There are a number of solutions, given that:
* you want the customer to upgrade their own product
* you must use a 16F877
* code must be protected

How about adding a 80 cent 12C508 to your board,
which programs your 16F877 with data from an external
port (which you must already have). The user could
download new firmware from you via the net, plug their
PC into the product, the 12c508 de-crypts the firmware
and programs the 16F877 in standard ICSP mode.
Full security, solution fixed. This gives you the same
functionality you are asking for now, at the expense
of adding a tiny cheap PIC.

Now before you say that the boards can't be modded
to add the 12c508, you could put the 12c508 plus
a few parts in a tiny potting box, as part of the
programming lead that goes from the product to the
the PC. Neat and cheap.

I think you are just hung up on bootloading, and I don't
know why. It's never been as good a programming option
as a proper ICSP dump. :o)
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@051548 by Ashley Roll

flavicon
face
Hi All,

I'm afraid that this means that it would be simple to get the code - you
have it in "clear text" going from the 12c508 to the F877.. In a well known
and understood format. (ICSP)

You also have the general problem that you can't supervise the equipment or
the update code that you send out! Look at Pay/Cable TV Smartcards, these
are cracked all the time, yet are supposed to be "secure".

This means that a sufficiently determined person could "crack it".
Unless you have lots of free space and RAM on the PIC I doubt that you can
implement a good cipher anyway. I could be wrong here - I haven't tried to
implement any good ciphers on a PIC. A GOOD cryptography reference is
"Applied Cryptography" by Schneier. I have the 2nd Ed, but I think there is
a 3rd.

It all comes down to "acceptable risk". Making it hard for the casual
cracker to copy it but probably not impeding a determined and well resourced
person for too long. Basically you have to make it harder to copy it then to
just design it from scratch.

One Possibility:

Store your "program" in an external EEPROM. The program would be some kind
of encrypted interrupter. A little like BASIC on a BASIC stamp. The thing is
that you will need to write the interrupter to run internal "routines" so
you get enough speed. You will also have to ensure that you have all the
routines that you will ever need and some lower level commands to help make
any new ones if you forget one. Not to mention the tools to generate this
code..

I don't know if this will be applicable to your application or not. Just
wild idea..

Cheers,
Ash.

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@063648 by uter van ooijen & floortje hanneman

picon face
> >Very simple:  Allow me to disable ICSP reads no matter what, and allow me
> to
> >disable internal reads of the flash memory, but allow internal flash to
be
> >re-written.

Bad idea, how would you VERIFY?

Wouter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@065136 by Ron Anthony

flavicon
face
You wouldn't verify the written flash, you'd verify the data in ram before
writing.  With bad operation, you could always re-flash (up to 1,000 times).
You can't verify, but also no one else can ever see your ROM image.  It's
locked down. :)
{Original Message removed}

2001\07\26@070837 by V sml

picon face
ron,

one way is to use a dallas button, maybe maxim button now, roman may say to
do it in a pic12.  this could act like a "key" to your code.  you could even
time-out your code when you want to.

cheers, ling

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@073212 by Vasile Surducan

flavicon
face
Ron,
As you see, ( and probably test on your skin) a half from the people of
this planet try to protect something and the other half are trying to find
what the first half has done...
It's crazy !
Maybe you was to angry today, but what if someone read your
code, what's so big deal ?... what if he/she made a clone of your product,
( which could be better than yours, you must admit this...)
It's not the end of your life...
The best method to protect your firmware is to put the source code on your
web page...then no one will attempt to read your pic.
[ smile on your face ? ]
Cheers, Vasile

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@075142 by uter van ooijen & floortje hanneman

picon face
Hmm, I'm only a PIC hobbyist, but I would never use a programming tool (HVP,
LVP, bootloader) that does not at least read back the programmed data at the
nominal Vcc (preferrably at other Vcc's too!). The flash-writing itself
could go wrong, so you might end up with a PIC that has a partially 'random'
program. I hope you don't do nuclear, avionics, medics etc?

> You wouldn't verify the written flash, you'd verify the data in ram before
> writing.  With bad operation, you could always re-flash (up to 1,000
times).

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@081153 by mike

flavicon
face
On Thu, 26 Jul 2001 12:30:04 +0200, you wrote:

>> >Very simple:  Allow me to disable ICSP reads no matter what, and allow me
>> to
>> >disable internal reads of the flash memory, but allow internal flash to
>be
>> >re-written.
>
>Bad idea, how would you VERIFY?
Simple - you have a 'read enable' bit in the hardware, which is set
when a cell is erased, and cleared when the address register is
written to. This allows you to erase, write and read back a location
until it verifies OK, but then doesn't allow any 1-bit-at-a-time type
attack. Should use minimal silicon - one set/reset latch and a few
gates



--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@081233 by Spehro Pefhany

picon face
At 01:44 PM 7/26/01 +0200, you wrote:
>Hmm, I'm only a PIC hobbyist, but I would never use a programming tool (HVP,
>LVP, bootloader) that does not at least read back the programmed data at the
>nominal Vcc (preferrably at other Vcc's too!). The flash-writing itself
>could go wrong, so you might end up with a PIC that has a partially 'random'
>program. I hope you don't do nuclear, avionics, medics etc?

This one can check its own program so that is a possibility. It would catch
bits that go bad gradually in the field as well as programming problems.
Just do a checksum or (preferably) a CRC.

Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@081559 by Kevin Blain

flavicon
face
why does it matter if the part is not protected if you are going to, for
example email out hex code to update the part with anyway??????

Sure if you code protect the part, the hacker can't read the part using a
PIC programmer, but they can read the hex file using notepad......


Regards, Kevin

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@081807 by M. Adam Davis

flavicon
face
Ideally the code protect (including the ICSP disable) would occur AFTER
the verify.

-Adam

wouter van ooijen & floortje hanneman wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@085048 by M. Adam Davis

flavicon
face
I'm somewhat confused here...

Are you saying that you are still going to leave a portion of the code
unprotected?  Not only that, but the lower portion?

This means that I can write, oh, a 10 word program that I can place at
the beginning of memory to read code out of your entire chip.  Since the
start is unprotected, I can simply read out the program I overwrote, and
I've got the code on the entire chip.

I still don't see how this method will prevent anyone from getting your
code - perhaps you could enlighten me.

I have two more questions for you, which you'll perhaps not answer (you
haven't answered them before, but I didn't ask them outright)
1) What is your product (or) what about your product requires a free,
secure, field-upgrade?
2) You state boldly and outright several times that Microchip
"...made some horrendous design decisions and committed them to silicon
with the 77..."
"[was] aware that their chip architechture was fundamentally flawed..."
"...made a business decision to delay the fix..."
"...[payed] no heed whatsoever to the fact that their very customers are
put at severe risk of code copying."
"...did not give a sh*!*t."

Now, IIRC, they came out with the f877 as an answer to our prayers for a
larger better version of the f84 - we weren't even hoping for the
ability to self read and write the program memory in code, and when they
released the preliminary data sheet we were ecstatic!

The f877 was designed, and the community was happy with it.  I don't
ever remember Microchip releasing a sheet which showed better code
protection, or discussing better code protection with anyone.  It was
*never* in the original design.

Quite frankly I think that the reason many are defending Microchip
instead of you is the old man mentallity.  "We ate dirt for breakfast
and we *liked* it!"  We knew the f877 didn't have *everything* we could
possibly ever want, but it had so much of what the other chips lacked
that we were content with it and the knowledge of the soon-to-come 18
series, and the knowledge that Microchip was aware of another *want*
(namely better code protection).

You make the case that Microchip purposefully made decisions which they
knew were 'wrong' - but I don't see any evidence of that at all, and you
have not spent any time backing up your statements, only to say that it
is 'obvious', it's a 'fact', and to use (what many see as) rather
caustic phrasing and wording.  What I would like to see are documents
you have that show that Microchip had orignially considered greater code
protection but threw it out knowing it was the worst possible thing to
to to this chip, any document signed by an executive of Microchip that
gives promises pertaining to the availability of the newer 77a, or any
document which shows the chip having the better code protection which
does not say "preliminary" or "this document contains forward looking
statements...".

In short, I'd like to see you back up your statements with more than
your word.  I honestly do not see where Microchip has made a misstep, or
'screwed' its customers.  I'm sorry if you feel that way - and I hope
you're not offended by us or our defense of Microchip.  Just look
forward to the happy day when either your project is complete, or
microchip /finally/ releases the chip that will allow you to have your
cake and eat it too.  ;-)

However, I'd at least like an answer to my first question (how does your
current scheme protect your code?)

Thanks!

-Adam



Ron Anthony wrote:

{Quote hidden}

>{Original Message removed}

2001\07\26@085517 by Ron Anthony

flavicon
face
who says I need to distribute a naked hex file?  it'll be a massive, messy,
non-sensical, arbitrary, encrypted-out-the-wazoo tornado of CHAOS!!!!!!!!
if you can crack it, you can have it.  only a moron would spend the time it
would take.

{Original Message removed}

2001\07\26@090457 by Byron A Jeff

face picon face
On Thu, Jul 26, 2001 at 08:12:15AM -0400, M. Adam Davis wrote:
> Ideally the code protect (including the ICSP disable) would occur AFTER
> the verify.

This is not possible. When programming the chip with internal writes, the
config word is inaccessible. You can't change any of the config bits. That
can only be done when programmed externally.

What Ron proposes is a black hole. You have to trust that the write works
correctly.

BAJ

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@090650 by uter van ooijen & floortje hanneman

picon face
[ James, are we in for the longest not-totally-off-topic thread yet? ]

On the problem of distributing a new hex image: with a few checks &
procedures you could distrubute the XOR of the old and the new image.
Cryptographically this is (almost?) equal to the 'one time pad', the
strongest possible cypher. Of course this requires that the loader can read
the old content....

Wouter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@091934 by V sml

picon face
As mentioned in my previous mail, save all the complexities, use a key
system.

You can have your source naked with usual bootloader, but your code look
for, and need an external private key to run.  Sure theft can be done
through unassembled, etc... but it would be easier to redo the system from
scatch.

cheers, ling sm

----- Original Message -----
From: "Ron Anthony" <ronantspamKILLspamOPTONLINE.NET>
To: <.....PICLISTKILLspamspam.....mitvma.mit.edu>
Sent: Thursday, July 26, 2001 8:57 PM
Subject: Re: [PIC]: FINAL WORD: A great solution for the PIC16F877 problems
(code protect,bootloader)


> who says I need to distribute a naked hex file?  it'll be a massive,
messy,
> non-sensical, arbitrary, encrypted-out-the-wazoo tornado of CHAOS!!!!!!!!
> if you can crack it, you can have it.  only a moron would spend the time
it
> would take.
>
> {Original Message removed}

2001\07\26@092340 by M. Adam Davis

flavicon
face
Sorry, I mis-read the original statement.

Disabling the internal reads is not necessary, as long as external reads
and writes are disabled.

The reason the idea of disabling internal reads came up is that someone
could write code using icsp to read out the internal memory.  If you
can't read or write code to the chip except through secure bootloader,
then internal reading becomes secure.  So it's really a moot point.

-Adam

Byron A Jeff wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@093145 by Ron Anthony

flavicon
face
That's EXACTLY correct BAJ, trust the write.  If you can't read it back,
neither can anybody else.  And that's a good thing.  A write went bad?  What
are the odds of that?  Slim.  So?  Just flash it again.  No problem.

{Original Message removed}

2001\07\26@093559 by Ron Anthony

flavicon
face
Adam, that's not so.  If internal reads are diabled, then the entire chip is
locked for good.  If they crack the bootloader, they are only going to get
the code that "patches" what's there already.  They'll get fragments only,
in the best case.  The truth is they;ll drop the effort and just try to
emulate from scratch.  And that they can do no matter what.

{Original Message removed}

2001\07\26@094029 by Ron Anthony

flavicon
face
Adam, if any part of the chip is code protected, that is, 50% or 256 bytes,
then ICSP writes are disabled.  Only ICSP reads can be done on the open
half.  The only way to get the memory dump of the code protected upper half
is to crack the proprietary bootloader that uses the same protocol.  But
like I said, if you can do that, you can have it.  I've got no problems with
that.  The real problem is that the 77A can disable ICSP reads and all
internal flash reads, but still keep the chip 100% flashable.  So it's easy.
And then the only way at the code is to crack the bootloader, and then
you'll only get that fragment of code that is in the given update.  With
internal flash reads disabled, you're locked out every which way.  So the
77A, which was supposed to be out a looooooong time ago, was sidelined for
the exact reason I said previously:  Microchip couldn't care less about you
or the security of your code.  At least for the next half a year.  They gave
this no priority even though they were aware 2 years now.

Microchip was aware of the problems, I spoke to many in the company and
raised hell about it from the first time I saw the data sheet.  Even way
back then, I was told "We are aware, we respect your code, there's no higher
priority for us, we're on the problem, it's already designed out, the first
revision will fix it shortly.  We here at microchip make it the highest
priority to protect the code that our customers write, so have no fear, the
77A is on it's way".

Look, I'll have my workaround at massive expense of effort and energy,
almost crippling the chip to make a difficult workaround that still has the
weakness of a memory dump past my bootloader.  That's why a 2k flash update
is going to be a several-hour conversation with the chip.  In fact I may
even write bogus code 3 times before writing the real code, and dot the real
code in with the garbage.  If I hit every location 3 time, I still get 333
flash updates of that 2k before the flash loses its adhesion.

THE WHOLE SITUATION STINKS MAN!!!!!!!!!!!  MICROCHIP, FINE -- TAKE MY
MONEY -- BUT AS SOON AS I CAN MIGRATE, I'M GONE!  And what's with no
hardware USB built into these chips?????  How long has USB been out?  3
years now!!!!!!!!!!  Hire some more engineers.  I think you guys are
ridiculous in your lotalty:

Here's the latest quote:
http://finance.yahoo.com/q?s=mchp&d=c

P/E 26.18
Mkt Cap
4.308B          -- for those who don't get the "B" part, that's FOUR THOUSAND THREE
HUNDRED AND EIGHT MILLION DOLLARS

Last year Microchip earned a profit of 165 million dollars.  You telling me
they couldn't have spent what it took to add hardware USB to their flash
line by now?  At 26.18 times earnings?????  Hell every time I buy one single
chip they make at least $75 in market cap at 26+ P/E.

Look, I like the 77, but the fact is the chip has non-existent protection.
It's a JOKE, on you or me or anyone else who buys the chip.  And I'm so
disgusted by it that I have to sit here and overcome it fifty-miles-wide
gaping hole with tons of code, and on top of that, page flips EVERYWHERE, to
ram and flash, and then to bank 3 to read and write.

Yes the 18F is good, but it's half a year away.  And the 77A?  Later than
hell.

Guys, I give up.  The 77 is a perfect chip, i love writing cryptic and mind
numbing code for no reason other than some wealthy buffoon who's on the
board making a business decision to leave our code wide open.  The dumb
wealthy bastard.  Couldn't care less.



{Original Message removed}

2001\07\26@094456 by Alan B. Pearce

face picon face
>That's EXACTLY correct BAJ, trust the write.  If you can't read it back,
>neither can anybody else.  And that's a good thing.  A write went bad?
What
>are the odds of that?  Slim.  So?  Just flash it again.  No problem.

Are you serious? I would not want to carry your liability insurance with
that attitude. I do not know what your product does, but it better not be
possible to damage life, limb or property.

If you reprogramm a device and it fails to write properly, what are the
chances of it operating in a manner that does serious damage resulting in
BIG lawsuits.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@101252 by Byron A Jeff

face picon face
On Thu, Jul 26, 2001 at 09:33:34AM -0400, Ron Anthony wrote:
> That's EXACTLY correct BAJ, trust the write.  If you can't read it back,
> neither can anybody else.  And that's a good thing.  A write went bad?  What
> are the odds of that?  Slim.  So?  Just flash it again.  No problem.

Personally I still think that worrying about a cracked bootloader isn't as
severe a problem as you think. I've been checking out the Program Memory
Proection State Table in the datasheet (Page 46). The problem isn't the
internal read, it's the interaction between the internal write and the
external read. There's no state where the chip memory can be written internally
and not be read externally. The lack of this mutual exclusion make it very
difficult to create a situation where a bootloader can operate in a protected
fashion. What seems to be missing is a state where all internal operations are
allowed and all external operations are disallowed. This would create a
situation where the bootloader is the sole determinant of control of the
program memory. The all of the encryption/protocol protection can come to bear.

Also it's a bit annoying that they don't have a 1/4 protect setting in addition
to the 256 byte and the 1/2.

The best compromise seems to be protect 1/2, putting an encrypting bootloader
and a threaded interpreted kernel in that space, and writing a somewhat
encrypted set of tokens in clear space. The cracker would then have the triple
task of figuring out what the encrypted bootloader protocol is, what the token
encryption is, and what the token meaning is. And it solves your jump issues
because the data in unprotected region is never executed (except for the 1st
6-8 words for the reset and interrupt vectors)

That should be sufficient to deter all but the most determined.

Personally I don't think the black hole writes are the best thing. I think that
a mode where all external access is prohibited and all internal access allowed
should provide sufficient protection.

BAJ
>
> {Original Message removed}

2001\07\26@102128 by Byron A Jeff

face picon face
On Thu, Jul 26, 2001 at 02:59:15PM +0200, wouter van ooijen & floortje hanneman wrote:
> [ James, are we in for the longest not-totally-off-topic thread yet? ]
>
> On the problem of distributing a new hex image: with a few checks &
> procedures you could distrubute the XOR of the old and the new image.
> Cryptographically this is (almost?) equal to the 'one time pad', the
> strongest possible cypher. Of course this requires that the loader can read
> the old content....

Wouter,

The problem is that anywhere a 16F87X part can do an internal write, it can
also do an external read. So someone could read out the existing code, write
their new HEX file, do the XOR, and use the bootloader to write their own
code into the chip, which is exactly what Ron is trying to prevent.

Bootloading and code proection don't go well together. ICSP and security
don't go well together because the serial programming protocol is done in
the clear and is well documented.

So you end up with an encrypted, protected bootloader, a protected execution
kernel, and an encrypted set of tokens in clear space. Not the prettiest
solution.

Ideally there should be a mode where all external access is prohibited and
all internal access allowed. This would let the bootloader be the sole gate
into updating the chip, and it can made as hard as required on a per
application basis.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@105611 by uter van ooijen & floortje hanneman

picon face
> > On the problem of distributing a new hex image: with a few checks &
> > procedures you could distrubute the XOR of the old and the new image.
> > Cryptographically this is (almost?) equal to the 'one time pad', the
> > strongest possible cypher. Of course this requires that the loader can
read
> > the old content....
>
> (snip comments from BAJ)
>

I was not addressing that issue, but a related point: once you have a secure
chip (bootloader, ICSP disabled), how do you distribute a new version of
your application without giving the 'customer' the ability to get access to
the actual code? The answer that I gave is: just distribute the XOR of the
old and the new application.

Wouter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@111508 by Dale Botkin

flavicon
face
On Thu, 26 Jul 2001, Ron Anthony wrote:
<lengthy rant we've seen several times snipped...>

Ron, if you have a problem with Microchip, deal with them.  You originally
asked how many others were upset about the same problem -- as far as I can
tell the answer to that so far has been zero.  Sorry about your problem,
but there is nothing anyone on the list can do about it, so repeating the
same gripes here day after day is not going to be a very productive use of
anyone's time.  Migrate to a different CPU, sue Microchip, I don't care,
but I for one am getting tired of hearing about it.

As for Microchip's size and priorities...  if the revision to the 'F87x is
late it's probably because so few peope complain that they have higher
priorities (like new products everyone is asking for).  I have yet to see
anything detailed in your messages that does not work exactly as specified
in the 16F877 data sheet.  One does what one can with what one has and
moves on, usually.

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@115249 by David Dunn

flavicon
face
i'd bet money that with all the crap he's going thru trying to make his product field upgradable and secure,
something is going to go wrong elsewhere, and it's going to end up not working right in the field. can almost
guarantee it. you just can't out-think the idiots in the field, many of them will find a way to make it not work
right, and end up screwing the device in the process.

3 hours to flash upgrade a product ? lol ! this thing is doomed before it ever hits the UPS shipping dock.

dld





On Thu, 26 Jul 2001 14:43:59 +0100, Alan B. Pearce wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\26@120747 by Olin Lathrop

face picon face
> Very simple:  Allow me to disable ICSP reads no matter what, and allow me
to
> disable internal reads of the flash memory, but allow internal flash to be
> re-written.  So simple, they've done it now with the 77A and 18F series.
> And left me holding the bag with the miserable 77 for at least the next
half
> of a year.

I agree that what you describe is a better protection strategy than what is
in the 16F877.  However, that's not what Microchip did.  Perhaps the other
way would have cost more, delayed the product, or they just missed that
point and they were willing to walk away from the small segment of the
market that:

1 - Cares about code protection.

AND

2 - Wants customers to field-upgrade firmware via an internal uploader.

You can argue that Microchip made a bad choice, but you can't blame your
predicament on them because the F877 does work as documented.  In other
words this part doesn't suite your needs, and YOU therefore shouldn't have
picked it.  Or if after doing a competitive search discovered that the F877
was still the best choice, live with the restrictions.

> Face it, I'm screwed.

Yup, I guess so.  Can we stop hearing about this now unless you've got NEW
information to inform us of?


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, EraseMEolinspam_OUTspamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\27@063114 by Germain Morbe

flavicon
face
> it'll be a massive, messy,
> non-sensical, arbitrary, encrypted-out-the-wazoo tornado of CHAOS!!!!!!!!

Terms like the above a usually applied to non standard encryption schemes
which are not publicly tested but homemade and therefore considered to be
secure.

Unless you are a cryptologist i fully agree:
You4re screwed!

> if you can crack it, you can have it.  only a moron would spend the time
it
> would take.

Sounds like you did not expect someone out there to be more genius than the
author of that piece of code. A somewhat naive perspective of the reality.

Germain

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\27@070909 by Ron Anthony

flavicon
face
Not naive, just reality, and really quite sincere, if someone spends the
time to crack it, be it 5 minutes or 5 years, in any case, they've earned
whatever jewels of wisdom they can divine from my code.  Basically, by
expending considerable effort in working around the 77's woeful flash
protection, I've clearned my conscience of the matter.  In other words, I've
done what I was able to do given the circumstances.  And I'm fine with that.
:)

{Original Message removed}

2001\07\27@083048 by Peter L. Peres

picon face
The problem on how to protect code and data in devious ways was solved in
a very good way. It is the way Unix file permissions work, and the way
memory protection works in ix86 and Pentium etc chips: There are three
bits for each page or unit, one allows read, one allows write, and one
allows execution.

Moreover, it can be shown that this scheme is the minimum and the maximum
necessary to implement access control to one page of information, i.e. it
is optimal.

So, knowing this, may I ask why every time a new product appears it uses a
*different* scheme that fails to implement this very basic and sane idea ?

F.ex. you could have firmware code shipped in a PIC and marked execute
only. The write bit would be cleared so the area would not be erased by
flashing (the security bits would be a part of the page - perhaps a normal
code location in it you'd have to jump around in your code - and clearing
the w bit would render that page OTP except for device erase commands).

The read bit would be cleared so no-one could read your code out.
Obviously table reads inside the same page by the code itself pose a
logical problem. This might be solved by allowing any read if the IP is
within the same page. Questions ?

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\27@083051 by Peter L. Peres

picon face
I think that there is a small misunderstanding here. The people who are
complaining about the program areas left open to read by partial
protection are those who sell or make field upgradeable firmware. This
implies that they have to allow the client (who has ICSP) to write and add
his own code to the free parts of the chip. This is where the current
security scheme fails.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\27@083054 by Peter L. Peres

picon face
wouter van ooijen & floortje hanneman <wfspamspam_OUTXS4ALL.NL> wrote:
> On the problem of distributing a new hex image: with a few checks &
> procedures you could distrubute the XOR of the old and the new image.
> Cryptographically this is (almost?) equal to the 'one time pad', the
> strongest possible cypher. Of course this requires that the loader can
> read the old content....

That depends on the relative sizes of them. One time pads rely on the
Shannon (information entropy) law by using more than one bit of pad per
bit of data (the more than one can come from the decision on which bit of
pad to use for which bit of data if the apparent data quantity is 1:1).
Thus the fundamental condition for using one time pads is that the pad be
at least the size of the data to be sent. Otherwise you are trying to
redefine what a 'bit' is in your context. And if the update is smaller
than what is inside there will be a way to crack it ...

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\27@093107 by Byron A Jeff

face picon face
On Fri, Jul 27, 2001 at 02:07:39PM +0300, Peter L. Peres wrote:
> I think that there is a small misunderstanding here. The people who are
> complaining about the program areas left open to read by partial
> protection are those who sell or make field upgradeable firmware. This
> implies that they have to allow the client (who has ICSP) to write and add
> his own code to the free parts of the chip. This is where the current
> security scheme fails.

This isn't exactly what Ron is talking about, beause the proposal on the
table isn't using ICSP for update. We all know that's a well known standard
that essentially requires the data to be passed to the chip in cleartext.
Also once protection is turned on, even partially, ICSP writes are disabled
for the whole chip. It's the reads that are the problem.

Ron wants an encrypted channel to the chip. The can be done with a bootloader.
However internal writes unfortunately have only the same priveledge as
external reads. This means that any location that can be written internally
can also be read externally.

There are a couple of different solutions. Ron is calling for a blind internal
write where reading the location is disallowed. A dangerous proposition for
sure. My proposal was simply having a mode where everything internal is
allowed and everything external is disallowed. Then the bootloader becomes
the only way to update the chip. Then one can encrypt to their hearts
content.

It's a slight oversight. Personally I'm only examining it as an intellectual
excercise. If the code Ron wants to protect is really so important, the best
course of action is to fully protect the chip and simply send new chips
when upgrades are required. If the code is that important, the clients would
have no problem pulling the boards and upgrading.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\27@095007 by uter van ooijen & floortje hanneman

picon face
> Thus the fundamental condition for using one time pads is that the pad be
> at least the size of the data to be sent. Otherwise you are trying to
> redefine what a 'bit' is in your context. And if the update is smaller
> than what is inside there will be a way to crack it ...

PAD=application that is already in the chip (stuffed with random bits to
flash size)
MSG=new application
so per definition MSG =< PAD
the weak point is of course when you apply this scheme over and over again.

Wouter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\28@143210 by Alexandre Domingos F. Souza

flavicon
face
>How about adding a 80 cent 12C508 to your board,
>which programs your 16F877 with data from an external
>port (which you must already have). The user could
>download new firmware from you via the net, plug their
>PC into the product, the 12c508 de-crypts the firmware
>and programs the 16F877 in standard ICSP mode.
>Full security, solution fixed. This gives you the same
>functionality you are asking for now, at the expense
>of adding a tiny cheap PIC.

       So I would hack a PC into the ICSP line, read the code being program, put in a nice flashy page on the internet saying Me 0wNz th1s pr0gr4m ;o) Too easy ;o)

       Maybe if the 877 and the 508 would be potted...but it's an easy task to break the potting compound anyway...


---8<---Corte aqui---8<----

Alexandre Souza
@spam@taitoKILLspamspamterra.com.br
http://planeta.terra.com.br/lazer/pinball/

---8<---Corte aqui---8<----

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...