Searching \ for '[pic]: lousy code protection on F87X !!! Are you k' 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: 'lousy code protection on F87X !!! Are you k'.

Exact match. Not showing close matches.
PICList Thread
'[pic]: lousy code protection on F87X !!! Are you k'
2000\08\30@091538 by Andrew Kunz

flavicon
face
Dear Anon,

You should have enough guts to at least post your name with this.

Yes, it's a horrible screwup by them.  I mentioned this at the Masters
conference a couple weeks ago, and their was a very defensive reaction from some
of the people who gave input to it.  I explained exactly the same situation you
brought up - it's about the stupidest way to do it.  Almost - wait until you
hear the next fix...

... in the future (supposedly, this is what they said at the conference but
there was sufficient adverse reaction that maybe it isn't etched into silicon
yet), now code protect will function sorta the same way, but be read/write
protected internally on a bank-by-bank basis (typical flash sectoring, it
sounds).  Any bank will be able to read itself just fine.

Sounds good, right?  But wait - this means that you can no longer checksum your
program!  And instead of 1 boat loader, you might need 4!  Hello?!?!  Anybody at
home in Arizona?

What we need is a way to set the chip so that it can do whatever it wants
internally (ok, so make it a config bit if you must), but is not visible to the
outside world w/o a full erase first.  That sounds like what you are asking,
right?  What makes it so difficult?!?!?!

Sometimes I think they get too many sales people in the way, and forget to allow
engineers to talk to each other.

Andy









anonlistpost anonlistpost <spam_OUTanonlistpostTakeThisOuTspamHOTMAIL.COM> on 08/30/2000 08:51:51 AM

Please respond to pic microcontroller discussion list <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>








To:      PICLISTspamKILLspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: [pic]: lousy code protection on F87X !!!  Are you
         kidding me?








Hello to all.  I require help to try and survive a horrible blunder by
Microchip.

On the F87X flash series, Microschip seemed to adopt a miserable philosophy
with regard to the copy protection on this chip.

If I leave the chip flash writeable, so I can update my code with my own
bootloader program, the code must remain naked so that anyone can drop the
chip in a programmer and read its contents.

If I code protect the chip, it becomes non-flashable.

I am sure many of you are aware of this limitation.

Has anybody discovered a way to disable external reads and internal reads of
the flah but still writing over existing flash locations?

Bscially I am stuck with a flash chip that requires me to compromise my code
if I am to flash update the chip.  If I code protect the chip, I lose the
flash capability.

What a joke, huh?  They need to fire the guy who came up with that mess.

Now, for the scheduled A revision of this chip, they have fixed the code
protect to disable internal reads and external reads, but still allow
overwriting existing flash rom, so the problem is solved.  But until then
(say 8-12 months away) we are stuck with flash that is naked, or code
protected flash that becomes OTP.

What has anyone done about this???

Now, this whole thing becomes moot if there is a way to defeat the code
protect the chp anyway.  Why should I go through all the trouble of code
protecting various blocks of flash rom if it can be defeated?  I truly hope
the code protect is durable, but it will make my life easier to accept
defeat and keep my code naked for all to see, but enjoying the flash
upgradability.

What to do?

Lay it on me!!!!!!!
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@093853 by Bob Ammerman

picon face
Ok, If everybody thinks Microchip's code protect ideas for flash devices are
lousy, why don't we brainstorm up a good solution here on the PICLIST? I
don't know if mchip will pay any attention, but it would perhaps be a useful
excersize anyway.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2000\08\30@111502 by Barry King

flavicon
face
Andy said:

> yet), now code protect will function sorta the same way, but be read/write
> protected internally on a bank-by-bank basis (typical flash sectoring, it
> sounds).  Any bank will be able to read itself just fine.
>
> Sounds good, right?  But wait - this means that you can no longer checksum your
> program!  And instead of 1 boat loader, you might need 4!  Hello?!?!  Anybody at
> home in Arizona?

Andy, I don't understand the problem.  If you have 4 banks of Flash,
and you can write protect them independently, then why does that
imply 4 boot-loaders?  I think it implies 1 boot-loader in one bank,
which is code protected.

If you do a field update, the boot loader erases the old code,
programs the new, and copy protects it after it verifies.  What's
wrong with that?

And the checksum thing is not a problem- if you want to make a
program be field updated, then its got to be modularized, and each
module will need to be verifiable seperately anyhow.  4 checksums,
yes, but that's what you want.

> What we need is a way to set the chip so that it can do whatever it wants
> internally (ok, so make it a config bit if you must), but is not visible to the
> outside world w/o a full erase first.  That sounds like what you are asking,
> right?  What makes it so difficult?!?!?!

So you're advocating a copy-protect bit similar to the 16C family,
where once its set, you cannot read or write the Flash in a
programmer (or via ICSP).  But even with the bit set the chip can
read or write or erase internally, letting a boot-loader do updates,
for example.

I *think* what makes it so difficult is that ICSP is a microcoded
boot loader, that is, there is NO difference between the ICSP doing a
Flash write and your program doing it.  So its both or neither,
unless there is a change to the Flash interface to the CPU.  And
*that* is a major change.

Anyone have further insight into this, especially from the arizona
horses' mouths?

Regards,

Barry.
------------
Barry King, KA1NLH
NRG Systems "Measuring the Wind's Energy"
http://www.nrgsystems.com
Check out the accumulated (PIC) wisdom of the ages at:
PIC/PICList FAQ: http://www.piclist.org

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@114853 by Andrew Kunz

flavicon
face
>Andy, I don't understand the problem.  If you have 4 banks of Flash,
>and you can write protect them independently, then why does that
>imply 4 boot-loaders?  I think it implies 1 boot-loader in one bank,
>which is code protected.

Sorry.  Each bank only has access to itself when protected.

>If you do a field update, the boot loader erases the old code,
>programs the new, and copy protects it after it verifies.  What's
>wrong with that?

Nothing, except it can only do it to its own bank.  So I can't have a bootloader
which has access to the entire chip at once (after protection).

Also, boot loaders don't have access to the config bits, so they cannot copy
protect the block.  Only normal HVP or LVP can give that.

>And the checksum thing is not a problem- if you want to make a
>program be field updated, then its got to be modularized, and each
>module will need to be verifiable seperately anyhow.  4 checksums,
>yes, but that's what you want.

No, I want 1 checksum for the entire program, which spans multiple banks.  It
doesn't have to be "modularized" itself because the boot loader lives in high
memory and is a distinct application.  I don't want to know which portions of
the chip the linker will stick stuff.

>So you're advocating a copy-protect bit similar to the 16C family,
>where once its set, you cannot read or write the Flash in a
>programmer (or via ICSP).  But even with the bit set the chip can
>read or write or erase internally, letting a boot-loader do updates,
>for example.

I think we're saying the same thing here.

Programmers can do ICSP or standard unconnected burn.  No difference there.

>I *think* what makes it so difficult is that ICSP is a microcoded
>boot loader, that is, there is NO difference between the ICSP doing a
>Flash write and your program doing it.  So its both or neither,
>unless there is a change to the Flash interface to the CPU.  And
>*that* is a major change.

No.

ICSP is NOT ICD! ICSP has access to everything - config bits and all.  ICSP is
what we use to burn the bootloader into the chip, which later will have app code
burned.  It can be done with either HVP or LVP mode (as long as LVP isn't
disabled).

ICD is really an application with hardware support that resides in the same
bootloader area I would use.

>Anyone have further insight into this, especially from the arizona
>horses' mouths?

I must be looking at the wrong end of the horse.  There's no mouth on this end.
<G>  JUST KIDDING!

To be clear, I want the application to be able to read and write itself anywhere
in memory, whether copy protected or not.  If you insist on it, you may disable
this feature with a config bit.  I like that feature of being able to block
external access to individual blocks.  This is good to allow me to LVP or HVP
burn configuration data, etc. into an otherwise unreadable chip.  I also like
being able to selectively control access to the EEPROM.

I want to be able to burn the chips using standard LVP or HVP modes after they
are plunked onto the board.

Andy

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@122411 by onlistpost anonlistpost

picon face
Hello again.  Sorry about the anon name fellas.  We're wroking on a
sensitive app and don't want to let any possible chip breakers know that we
are using the F87 series.

For the code protection, the ideal solution seems very simple.  Never allow
any reads of any kind, either internal or external.  Disable ICSP.  This
way, only the bootloader can overwrite the flash, and even the bootloader
does not know what it is overwriting -- and will destroy what was there with
what is known currently to the bootloader already.  The underlying goal is
to let the bootloader write to the flash, directly over code protected
memory.  With internal reads disabled and external reads disabled, only the
internal bootloader can write code, and even the bootloader can't insert
code that bitbangs the ROM out of a serial port, because internal flash
reads are disabled.

In the end, this will prevent you from using flash as extended non-volatile
RAM, but not necessarily -- if you can leave one bank or more banks open and
unrestricted against reads.

With a proprietary bootloader, only you will have access to overwrite the
chip.  And you'll have to get through the bootloader's own security to
initiate a transfer to the micro, and you can transmit massive amounts of
data to get at one real byte.  Who cares if the update takes 30 seconds
instead of 3? For that matter, let it take 3 minutes, I don't care.  Code
protection is paramount!!! There are any number of creative things one can
do to encrypt the actual code into mess before sneding it to the chip,
whereupon the bootloader decrypts it and dumps it to memory.  An
eavesdropper on the data transmission will never know what is code and what
is key.  Good luck pal, nemesis of the code originator.  Write your own
code!  If it's good enough to steal, it's good enough to buy, right?  They
don't agree with this -- and so must be trounced by being faced with such a
massive convoluted effort that he gives up.

Again, with reads diabled (both internal and external via no ICSP allowed),
the code is secure during transmission if properly encrypted, AND in stored
form once the bootloader distills the proper code from the transmission.

Also, the bootloader itself can be updated during a rewrite by changing the
bootloader's vector with each write cycle.  The new bootloader can write its
new clone, and then hand it control, which then erases the original
bootloader allowing its old space to be used as normal flash rom again, with
the bootloader now residing at a new location.

So, I repeat from the start:
In the end, Microchip must allow one or more config bits to say:
DISABLE INTERNAL READS OF FLASH MEMORY
DISABLE ICSP
ACTIVATE CODE PROTECTION FOR FLASH
ALLOW OVERWRITING CODE PROTECTED FLASH

That leaves us with permanently secure program ROM inside flash, with only
the programmer having access to overwriting memory via a bootloader.  Good
luck to anyone trying to get in.  If you can get in, you can have it.

Not lost in all this, of course, is that if Microchip's disabling of ICSP or
disabling of internal reads can be undone, then the chip is never secure
anyway, regardless, making all this effort a waste of time.  Does anyone
know of any way to crack the code protect options on this chip?  Let's hope
microchip did their homework.

The sad thing is that Microchip's first philosophy on code protecting the
F87X was protecting the original programmer from himself.  Who the hell
needs that?  What are we, idiots?  They thought "Hey, wouldn't it be nice to
keep a programmer from overwriting his own code that is matured?"  No, it
would not be nice, you fools.  You blew it big time.  If I wreck my own
code, then leave it to me to suffer properly and to engineer a proper
solution.  Ever hear of an in circuit emulator??  Sheesh.  I can't believe
they did things this way.

In the end, the F87X becomes an OTP part if you code protect the flash.
What a pitiful situation.  FIX IT MICROCHIP!!!!!  You owe it to your
customers to fix it FAST.  Our code is all we have.  Thanks for nothing.

So there it is again... lay it on me!!!!  What do you guys think?

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@123830 by Olin Lathrop

flavicon
face
> To be clear, I want the application to be able to read and write itself
anywhere
> in memory, whether copy protected or not.  If you insist on it, you may
disable
> this feature with a config bit.  I like that feature of being able to
block
> external access to individual blocks.  This is good to allow me to LVP or
HVP
> burn configuration data, etc. into an otherwise unreadable chip.  I also
like
> being able to selectively control access to the EEPROM.
>
> I want to be able to burn the chips using standard LVP or HVP modes after
they
> are plunked onto the board.

I've been following this thread with interest because I've done a couple
dozen PIC projects and never had occasion to care about code protection.
I'd be curious to hear what applications warrant this kind of paranoia.  I'm
not saying it isn't warranted on occasion, but am surprised by the hornet's
nest this topic has stirred up.

Even if someone could read every bit on the chip, that would get them only
to a dissassembly listing at best.  This is a long way from useful source
code that can then be modified in a meaningful way.

If I was really paranoid, however, I could claim that partial over-write
access without requiring a complete erase and unlimited internal read access
is a security hole.  I could program a snoop program into the bank 0 that
can then read out the remaining banks for me.  Using a different chip, I
could program the snoop program into some other part of memory and just
insert a jump or whatever at 0, an interrupt vector, or someplace I think
execution might get to.  It might require some experimenting with multiple
chips, but the whole program could eventually be discovered.  Therefore
partial external write access IS read access.  The only secure external
write access is one that requires complete erasure regardless of how little
is written.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam.....cognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@123840 by Andrew Kunz

flavicon
face
When you say "ICSP" do you mean

    a)   Programming a chip in circuit, like we've been doing for years?
    b)   A chip programming itself (only available since Flash)?
    c)   Programming a chip with the ICD?

Some of us use the 14-bit memory to store text messages.  You can get double the
text from 14 bits vs using RETLW instructions.  We also use it to save
calibration items which do not fit (or cannot be accessed quickly enough) into
EEPROM or RAM.

Obviously, then, read access is going to be necessary.  Some of us need to be
able to program our chips while they are deeply embedded in the target system.
Right now for me, that means DEEP!  Like inside a rack with 480V 10,000A ready
to zap me.  The only portal to the chip is an RS-485 port, so I NEED
self-programmability.  So we have an absolute need for write access.

Code protection, like ALL forms of security, is only as secure as the hostile's
budget will make him.  There is no such thing as absolute security.  The best
you can do is physically isolate the protected item from the hostile, ie,
"physical security."  But people won't buy widgets if they can hold them!

Security, therefore, is only a panacea for management.  We tell our customers
that "we are using the chip's security features" but, in our own minds, know
that these security features (like anybody's) are not fail-proof.  They will
only slow down a determined bad guy.  All processors have this problem; some
companies have adopted better schemes to allow us programmers to get the job
done while still maintaining the air of security.

The bootloader has to get it's data from somewhere.  A determined hostile WILL
figure out your protocol.  Besides, if it runs on a PC, it's actually quite
simple to get both the algorithm and the transferred data.

Andy









anonlistpost anonlistpost <EraseMEanonlistpostspam_OUTspamTakeThisOuTHOTMAIL.COM> on 08/30/2000 12:22:23 PM

Please respond to pic microcontroller discussion list <PICLISTspamspam_OUTMITVMA.MIT.EDU>








To:      @spam@PICLISTKILLspamspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: [pic]: lousy code protection on F87X !!! Are
         you kidding me?








Hello again.  Sorry about the anon name fellas.  We're wroking on a
sensitive app and don't want to let any possible chip breakers know that we
are using the F87 series.

For the code protection, the ideal solution seems very simple.  Never allow
any reads of any kind, either internal or external.  Disable ICSP.  This
way, only the bootloader can overwrite the flash, and even the bootloader
does not know what it is overwriting -- and will destroy what was there with
what is known currently to the bootloader already.  The underlying goal is
to let the bootloader write to the flash, directly over code protected
memory.  With internal reads disabled and external reads disabled, only the
internal bootloader can write code, and even the bootloader can't insert
code that bitbangs the ROM out of a serial port, because internal flash
reads are disabled.

In the end, this will prevent you from using flash as extended non-volatile
RAM, but not necessarily -- if you can leave one bank or more banks open and
unrestricted against reads.

With a proprietary bootloader, only you will have access to overwrite the
chip.  And you'll have to get through the bootloader's own security to
initiate a transfer to the micro, and you can transmit massive amounts of
data to get at one real byte.  Who cares if the update takes 30 seconds
instead of 3? For that matter, let it take 3 minutes, I don't care.  Code
protection is paramount!!! There are any number of creative things one can
do to encrypt the actual code into mess before sneding it to the chip,
whereupon the bootloader decrypts it and dumps it to memory.  An
eavesdropper on the data transmission will never know what is code and what
is key.  Good luck pal, nemesis of the code originator.  Write your own
code!  If it's good enough to steal, it's good enough to buy, right?  They
don't agree with this -- and so must be trounced by being faced with such a
massive convoluted effort that he gives up.

Again, with reads diabled (both internal and external via no ICSP allowed),
the code is secure during transmission if properly encrypted, AND in stored
form once the bootloader distills the proper code from the transmission.

Also, the bootloader itself can be updated during a rewrite by changing the
bootloader's vector with each write cycle.  The new bootloader can write its
new clone, and then hand it control, which then erases the original
bootloader allowing its old space to be used as normal flash rom again, with
the bootloader now residing at a new location.

So, I repeat from the start:
In the end, Microchip must allow one or more config bits to say:
DISABLE INTERNAL READS OF FLASH MEMORY
DISABLE ICSP
ACTIVATE CODE PROTECTION FOR FLASH
ALLOW OVERWRITING CODE PROTECTED FLASH

That leaves us with permanently secure program ROM inside flash, with only
the programmer having access to overwriting memory via a bootloader.  Good
luck to anyone trying to get in.  If you can get in, you can have it.

Not lost in all this, of course, is that if Microchip's disabling of ICSP or
disabling of internal reads can be undone, then the chip is never secure
anyway, regardless, making all this effort a waste of time.  Does anyone
know of any way to crack the code protect options on this chip?  Let's hope
microchip did their homework.

The sad thing is that Microchip's first philosophy on code protecting the
F87X was protecting the original programmer from himself.  Who the hell
needs that?  What are we, idiots?  They thought "Hey, wouldn't it be nice to
keep a programmer from overwriting his own code that is matured?"  No, it
would not be nice, you fools.  You blew it big time.  If I wreck my own
code, then leave it to me to suffer properly and to engineer a proper
solution.  Ever hear of an in circuit emulator??  Sheesh.  I can't believe
they did things this way.

In the end, the F87X becomes an OTP part if you code protect the flash.
What a pitiful situation.  FIX IT MICROCHIP!!!!!  You owe it to your
customers to fix it FAST.  Our code is all we have.  Thanks for nothing.

So there it is again... lay it on me!!!!  What do you guys think?

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@125116 by Andrew Kunz

flavicon
face
>The only secure external write access is one that requires complete erasure
regardless of how little is written.

Very good point, Olin, but still it only applies to "standard methods" of chip
content disclosure.  There is no such thing as absolute code protection.

Andy

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@152208 by onlistpost anonlistpost

picon face
Hello all.

First let me say that using the two ICSP pins is not an option.  All
available 33 I/O pins are being used for critical purposes.  In fact, we are
having some pins do double and triple duty with switching gates due to lack
of sufficient I/O.  But we pulled it off just fine-- however, we can not
sacrifice two pins for ICSP.  But, this would not have been a problem if the
code protect was done correctly.

As far as the suggeston for using another chip as the bootloader over ISCP,
this is no good as it would still require two pins on the F87X.  And, it a
waste of resources, and is unecessary, and actually facilitates code copying
due to how well known the ICSP protocols are.  They can be recorded easily.

For suggestions that using a socket is a wise choice, we already do that.
This allows the possibility of physical chip swapping, and throwing away of
the existing chips until the A revision comes out -- IF they get their act
together with the code protect.

As far as saying a bootloader is easily broken, I can tell you it will be
nearly impossible to determine what code is being sent to the micro.  For
example, I can send 8 megabytes to the CPU, with only 8k being valid, on a
rotating key system that is so convoluted that it would take years to
determine what data was code and what was key, and once the data ws know,
what encryption was used on that data before is was written to flash -- IF
the flash code protect could be relied on.  Now, if someone wants to spend
all that time decrypting the transmission and data encryption scheme, they
have earned it.  What I don't want to do is ***GIVE*** the code to them on a
silvber platter, solely because microchip decided to see flash cips that
require exactly that if the chip is to remain FLASH.  As we all know from
this discussion, Microchip totally blew it, and it is not possible to flash
update ROM while maintaining code protection.

So we still remain at square one.

And, a far a replacing chips, how'd you like to eat $5 per chip times
several tens of thousands of installations evry time you want to change, oh,
a single line of code.  Ridiculous.  And, to boot, having your customer open
a circuit, and having the inconvenience of a physical swap.

What the heck is this, an OTP part in a socket for poor man's
"upgradbility", or is this a FLASH chip?????

Come on Microchip, pick up the damn slack!!!!!

Do they read this?


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@152837 by Olin Lathrop

flavicon
face
>...
> In the end, the F87X becomes an OTP part if you code protect the flash.
> What a pitiful situation.  FIX IT MICROCHIP!!!!!  You owe it to your
> customers to fix it FAST.  Our code is all we have.  Thanks for nothing.
>
> So there it is again... lay it on me!!!!  What do you guys think?

I think you may have a valid point but I'm getting tired hearing you bitch
about it.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, KILLspamolinKILLspamspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@154957 by M. Adam Davis

flavicon
face
It would be interesting to me to see you build a flash microcontroller with half
the features that Microchip has.  You seem to have a lot of animosity towards
Microchip for what you believe is a ridiculous design.  If you don't like it, go
with another chip!  Frankly, I haven't yet seen a flash microcontroller with
decent code protection that can write its own memory under code protection.

Microchip developed an OTP device with code protection, then replaced the PROM
with flash for these particular chips.  That was a great improvement, but you
can't really expect them to make more than a few changes per upgrade.  It takes
a lot of manpower, and the way the code protect has been developed I doubt it is
an easy change for them to make.

I'm sure they are completely aware that this FEATURE is desired very strongly by
a portion of their customer base.

As far as your particular situation, unless your product is selling for less
than $500  then your customers won't balk at a $5 S&H fee for an upgrade.  You
send them a new chip, they send you the old one and a check for $5.  You
reprogram the old one for the next customer.

Of course, with adequate testing you shouldn't have to update older products.
If they want the latest and greatest they won't mind paying for an upgrade.

If you REALLY have to have these features EXACTLY the way you want them, there
are other solutions (which have been suggested).

I don't mean to offend you, but your approach to this problem seems bass
ackward.  You are trying to make a circle fit into an oval hole.  The PIC is
obviously not the solution to your problem at this time.  And I would not bet on
what they say about changing it any time soon, even if they are making the
changes now, it's going to be at least a year before we see them in the product.

As far as my opinion on how it should be done when it happens, I think it would
be overkill to have 4 bits of code protection for each block (external read and
write, and internal read and write)

It should be completely adequate to have 2 bits, one for external read and write
without a bulk erase, and one for internal read and write.  However, I fully
believe that the internal commands should include the chip configuration area,
so the program can change its own fuses.  All of these changes leaves more
vulnerabilities in the code protect, though.  External cracking becomes easier
with each function you have.

-Adam

anonlistpost anonlistpost wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@165232 by Lance Allen

picon face
On 30 Aug 2000, at 15:49, M. Adam Davis wrote:

> It would be interesting to me to see you build a flash microcontroller with half
> the features that Microchip has.  You seem to have a lot of animosity towards
> Microchip for what you believe is a ridiculous design.  If you don't like it, go
> with another chip!  Frankly, I haven't yet seen a flash microcontroller with
> decent code protection that can write its own memory under code protection.
>
.......
{Quote hidden}

I have been reluctant to enter this intense 'discussion' but I agree
with Adam here... if there is a better solution elsewhere, use it.

The on site product enhancements (in my Security days) were
based on chip replacements, I dont remember anybody ever
moaning about paying for an upgrade , a fault was eaten by the
supplier( you arent Beta testing the clients are you?.. very
dangerous ground ) but an upgrade was an option for the client.
The cost of the chip was nothing compared to the field service.
Tele-updating arrived as I left the industry but it was usually better to
replace the chip, you had to go out there anyway. The concept of
anyone dialing up and reprogramming the system, no matter how
good the passwording etc was seriously unpopular with clients.

Now comes the "you know nothin.. moron" comments.
_____________________________

Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand

http://www.psych.auckland.ac.nz

_____________________________

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@173108 by Don Hyde

flavicon
face
I'm disappointed with the flamish tone this thread has, since some really
good points have been made, and I suspect that good suggestions could find
their way into a Microchip part, if not a B or C version of F87X, then maybe
one that's not into production yet.

I like the idea of several "fuse" bits for each block of flash.  It doesn't
seem like a huge hardware burden, but could reconcile the vastly different
needs of different users.

A write-only update might be really secure -- at least sometimes, but I
always like to do a read-after-write verify.  Am I being overly cautious?
What are the chances of a write failing, and could I do anything about it if
I knew anyway?

I'm about 3/4 through reading Bruce Schneier's latest book "Secrets and
Lies" (and highly recommend it to anybody interested in computer security).
I think we are all going to be building a lot more devices that will need
well-thought-out security.

It's fascinating reading about the efforts to build secure smart cards and
cell phones and such.  Lots of the successful attacks rely on the fact that
critical data like encryption keys and ID codes are in separate parts
(usually EEROM's) where it is easy to hook up a logic analyzer to capture
the keys.  That's how pocket pagers get their passwords extracted so that
stolen ones can easily be reused, and how cell phones get cloned.

An all-in-one-chip microcontroller at least moves the problem into the
domain of dissolving the chip package and needing microscopes to see what
you're doing.  It seems less likely to be packaged for a couple hundred
bucks like the pocket pager "password recovery" tools.

With stuff like Bluetooth, wireless internet, and wireless LAN technology
about to descend on us in a mass-produced flood, we're going to find
ourselves wirelessly connecting stuff we would never have thought of.
(Think weird stuff like "Can you put a pig on the internet for $5?  We'll
buy 10,000,000 the first year if you can.")  Weird information can be
surprisingly valuable.  Suppose you knew that hogs all over the country were
running a fever.  Maybe you should buy pork bellies, especially if nobody
else knows.

In this context, security in a PIC is going to mean more than protecting the
code we wrote.   Reprogrammability may be essential when the security
algorithms are compromised or cracked.  Mailing a $5 replacement chip may be
too slow and too much of a logistic nightmare.  Catch 50000 pigs and plug in
a chip?  No thanks, but I might hold my nose long enough to step into the
confinement and wave a transmitter around and download new code into their
eartags.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@183323 by Tony Nixon

flavicon
picon face
Andrew Kunz wrote:

> What we need is a way to set the chip so that it can do whatever it wants
> internally (ok, so make it a config bit if you must), but is not visible to the
> outside world w/o a full erase first.  That sounds like what you are asking,
> right?  What makes it so difficult?!?!?!

Sounds a good idea to me, and this idea has been thrashed about in the
past, but as it is now, the fuse register is always accessable which
means you can change the internal protect fuse and defeat it.

To overcome this, why not make the fuse register protected as well if a
certain fuse bit is set, the spare bit 10 for example. If it is default,
set = 1, then the fuse register can be altered by ICP or what ever, and
the chip functions as it does now. However, if it is set = 0, then the
fuse and the ROM can NOT EVER be accessed by the outside world unless a
total erasure is requested through RB6 and RB7.

To make this functional, and this has been mentioned many times in the
past, the ROM must be able to be reprogrammable from within the chip,
and be independant of code protection. Thus a resident boot loader,
encypted or not, can be used for upgrades, and you can checksum and
modify your code.

In other words, this Total Protection bit is a gateway to the outside
world. The only way to open the gate after is has been closed, is to
totally erase the chip. The bootloader, if resident, is a secret back
door.

It may be a good idea to have the fuse accessable internally, but
perhaps only if the TP bit is disabled.

I'm sure these functions could be implemented easily, but I would
imagine the simplest die change is quite an involved and 'costly' task.

> Sometimes I think they get too many sales people in the way, and forget to allow
> engineers to talk to each other.

If it's like what happens here at times, the people with the loudest and
fastest mouths manage to get priority over the thinkers.


--
Best regards

Tony

ICmicro's
http://www.picnpoke.com
RemoveMEsalesTakeThisOuTspampicnpoke.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\30@185028 by onlistpost anonlistpost

picon face
Who can argue against the blatantly obvious need for being able to flash
update your own code while simultaneously protecting your code from illegal
duplication and reverse engineering?

Certainly it should be harder than saying "Hey if you flash update, your
code is going to get robbed" or "Don't use the flash memory on your flash
part if you want secure code -- gee whiz, just socket the part and deal with
the logistical nightmnare of perpetual chip recalls at each update -- won't
that be fun, and your customers will love it!"

Perhaps I seemed a bit angry at Microchip in my few posts here.  That's
because I am.  It's not bitching, as one guy just said, it's an honest
reaction to having a bad flash design in an otherwise marvelous chip.
Whaat's the point of flash if it can be used due to security constraints?

Look, if someone tells me code protection is an illusion because mchip's
line of F8XX parts can be cracked anyway, then so be it, I'll save myself
the trouble and leave my code naked -- but at least I'll be able to flash
update it without trouble.  This of course means it can be readily copied by
any number of black marketers.

So again I post the known solution as I see it, and ask you guys to think
about it, and get behind it, let's shake the tree at mchip and get their
attention.  If all 1,700 people on this list all send an email (I'll find
the address if the general attitude is to follow up on this) to mchip about
this, we may get that A revision that works properly.

Here is the soluion as I see it, that is, allow code protect bits to be set
as follows:
DISABLE INTERNAL READS OF FLASH MEMORY
DISABLE ICSP
ACTIVATE CODE PROTECTION FOR FLASH ROM, perhaps bank by bank of you like
ALLOW OVERWRITING CODE PROTECTED FLASH (but never can read it!)

It seems very simple to me, and they've already fixed this and have it
slated for the 40 MHz parts to replace the F87X series.  But let's not let
them wait 1 to 1.5 years to roll it out.

Should we try and arrange an email think tank to hit em with the solution
and ask them to post their reaction to the list?

Or should I give up?

You tell me.

Lastly, let me say I am thoroughly surprised at the defensive tone small
embedded systems poeple have taken in defending Microchip, in what is, quite
plainly, a bad design philosophy with regard to their code protection on
their F87X flash parts.  Microchip, as of today's market close, is a 5.457
***B***illion dollar company.  Most of us are small by comparison to say the
least.  Hell, if I had a spare five thousand million dollars in my wallet,
you can damn well bet I'd allow my customer to leverage flash technology
properly by protecting their code while still using the flash.


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\08\31@055410 by w. v. ooijen / f. hanneman

picon face
> A write-only update might be really secure -- at least sometimes, but I
> always like to do a read-after-write verify.  Am I being overly cautious?
> What are the chances of a write failing, and could I do anything about it
if
> I knew anyway?

Of course you want to check the code written, especially since you are gona
execute it soon! Why not have separate read/write-disable bits for external
(ICSP) and internal access? Each bit can be activated by external
programming, and can be cleared only by (external) erase. The bootloader
itself can take care of not overwriting itself, so having the bits separate
for each bank is not really needed, although it could be handy (for
instance when part of the flash is used as data store).

NB For me (hobby, experiments, no professional involvement) the 16F877
seems the best chip available, I expect it will soon reach and surpass the
16c84/16f84 in web coverage. Please point me to be better chip if one
exists!

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

2000\08\31@070337 by Andrew Kunz

flavicon
face
I agree 100% with you Tony.  Good points, good idea!

>If it's like what happens here at times, the people with the loudest and
>fastest mouths manage to get priority over the thinkers.

Does that mean I'm at the head of the line? <G>

Andy







Tony Nixon <spamBeGoneTony.NixonspamBeGonespamENG.MONASH.EDU.AU> on 08/30/2000 06:28:12 PM

Please respond to pic microcontroller discussion list <TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU>








To:      RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: [pic]: lousy code protection on F87X !!! Are
         you kidding me?








Andrew Kunz wrote:

> What we need is a way to set the chip so that it can do whatever it wants
> internally (ok, so make it a config bit if you must), but is not visible to
the
> outside world w/o a full erase first.  That sounds like what you are asking,
> right?  What makes it so difficult?!?!?!

Sounds a good idea to me, and this idea has been thrashed about in the
past, but as it is now, the fuse register is always accessable which
means you can change the internal protect fuse and defeat it.

To overcome this, why not make the fuse register protected as well if a
certain fuse bit is set, the spare bit 10 for example. If it is default,
set = 1, then the fuse register can be altered by ICP or what ever, and
the chip functions as it does now. However, if it is set = 0, then the
fuse and the ROM can NOT EVER be accessed by the outside world unless a
total erasure is requested through RB6 and RB7.

To make this functional, and this has been mentioned many times in the
past, the ROM must be able to be reprogrammable from within the chip,
and be independant of code protection. Thus a resident boot loader,
encypted or not, can be used for upgrades, and you can checksum and
modify your code.

In other words, this Total Protection bit is a gateway to the outside
world. The only way to open the gate after is has been closed, is to
totally erase the chip. The bootloader, if resident, is a secret back
door.

It may be a good idea to have the fuse accessable internally, but
perhaps only if the TP bit is disabled.

I'm sure these functions could be implemented easily, but I would
imagine the simplest die change is quite an involved and 'costly' task.

> Sometimes I think they get too many sales people in the way, and forget to
allow
> engineers to talk to each other.

If it's like what happens here at times, the people with the loudest and
fastest mouths manage to get priority over the thinkers.


--
Best regards

Tony

ICmicro's
http://www.picnpoke.com
salesEraseMEspam.....picnpoke.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

--
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

2000\08\31@070753 by Andrew Kunz

flavicon
face
I for one will not be responding to your posts until you get yourself a real
name.

I have spoken critically of Microchip (and others) publicly, and probably will
again.  I have also spoken very favorably of them (and those same others).
Nobody will ever accuse me of cowardice because I hide behind anonymity.

Andy


1





anonlistpost anonlistpost <EraseMEanonlistpostspamHOTMAIL.COM> on 08/30/2000 06:48:41 PM

Please respond to pic microcontroller discussion list <RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU>








To:      RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: [pic]: lousy code protection on F87X !!! Are
         you kidding me??








Who can argue against the blatantly obvious need for being able to flash
update your own code while simultaneously protecting your code from illegal
duplication and reverse engineering?

Certainly it should be harder than saying "Hey if you flash update, your
code is going to get robbed" or "Don't use the flash memory on your flash
part if you want secure code -- gee whiz, just socket the part and deal with
the logistical nightmnare of perpetual chip recalls at each update -- won't
that be fun, and your customers will love it!"

Perhaps I seemed a bit angry at Microchip in my few posts here.  That's
because I am.  It's not bitching, as one guy just said, it's an honest
reaction to having a bad flash design in an otherwise marvelous chip.
Whaat's the point of flash if it can be used due to security constraints?

Look, if someone tells me code protection is an illusion because mchip's
line of F8XX parts can be cracked anyway, then so be it, I'll save myself
the trouble and leave my code naked -- but at least I'll be able to flash
update it without trouble.  This of course means it can be readily copied by
any number of black marketers.

So again I post the known solution as I see it, and ask you guys to think
about it, and get behind it, let's shake the tree at mchip and get their
attention.  If all 1,700 people on this list all send an email (I'll find
the address if the general attitude is to follow up on this) to mchip about
this, we may get that A revision that works properly.

Here is the soluion as I see it, that is, allow code protect bits to be set
as follows:
DISABLE INTERNAL READS OF FLASH MEMORY
DISABLE ICSP
ACTIVATE CODE PROTECTION FOR FLASH ROM, perhaps bank by bank of you like
ALLOW OVERWRITING CODE PROTECTED FLASH (but never can read it!)

It seems very simple to me, and they've already fixed this and have it
slated for the 40 MHz parts to replace the F87X series.  But let's not let
them wait 1 to 1.5 years to roll it out.

Should we try and arrange an email think tank to hit em with the solution
and ask them to post their reaction to the list?

Or should I give up?

You tell me.

Lastly, let me say I am thoroughly surprised at the defensive tone small
embedded systems poeple have taken in defending Microchip, in what is, quite
plainly, a bad design philosophy with regard to their code protection on
their F87X flash parts.  Microchip, as of today's market close, is a 5.457
***B***illion dollar company.  Most of us are small by comparison to say the
least.  Hell, if I had a spare five thousand million dollars in my wallet,
you can damn well bet I'd allow my customer to leverage flash technology
properly by protecting their code while still using the flash.


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

--
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

2000\08\31@090346 by Olin Lathrop

flavicon
face
> Who can argue against the blatantly obvious need for being able to flash
> update your own code ...
>
> <snip rant>
>
> ... If all 1,700 people on this list all send an email (I'll find
> the address if the general attitude is to follow up on this) to mchip
about
> this, we may get that A revision that works properly.

If you do contact Microchip directly about this, I strongly suggest you do
it more politely than your posts here have been.  You are much more likely
to be successful by making your case on the merits and leaving emotional
rants and childish name calling out of it.  These people are only human too.
How would you feel about a customer that called you up to yell and scream
and insult you about your product as opposed to a customer that politely
pointed out a flaw, how it was effecting him, and suggestions for you to
improve your product?


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinTakeThisOuTspamspamcognivis.com, http://www.cognivis.com

--
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

2000\08\31@174804 by Tony Nixon
flavicon
picon face
Andrew Kunz wrote:
>
> I agree 100% with you Tony.  Good points, good idea!
>
> >If it's like what happens here at times, the people with the loudest and
> >fastest mouths manage to get priority over the thinkers.
>
> Does that mean I'm at the head of the line? <G>

I'm thinking, I'm thinking ;-)

--
Best regards

Tony

ICmicro's
http://www.picnpoke.com
EraseMEsalesspamspamspamBeGonepicnpoke.com

--
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

2000\08\31@205805 by Dwayne Reid

flavicon
face
At 10:48 PM 8/30/00 +0000, anonlistpost anonlistpost wrote:
>Who can argue against the blatantly obvious need for being able to flash
>update your own code while simultaneously protecting your code from illegal
>duplication and reverse engineering?
><snip>
>
>Lastly, let me say I am thoroughly surprised at the defensive tone small
>embedded systems poeple have taken in defending Microchip, in what is, quite
>plainly, a bad design philosophy with regard to their code protection on
>their F87X flash parts.  Microchip, as of today's market close, is a 5.457
>***B***illion dollar company.  Most of us are small by comparison to say the
>least.  Hell, if I had a spare five thousand million dollars in my wallet,
>you can damn well bet I'd allow my customer to leverage flash technology
>properly by protecting their code while still using the flash.

Part of the problem might be that many of us on the Piclist do not use code
protection and therefore don't care how badly it might be implemented.

Most of my designs wind up in industrial settings, where code protection
simply is not allowed.  The client MUST be able to keep its equipment
running, even if the supplier has been out of business for years.  Same
goes for Broadcast installations - they have to be able to take a part from
a working system and copy it to make a non-working system function
again.  And still the same for Museum and Interpretive Centres.

I'm part of a very small company and we only ship a few thousand PICs per
year - less than 10k.  None of them are code protected.  Sorry, but I am
not about to complain to MicroChip.

dwayne



Dwayne Reid   <RemoveMEdwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 16 years of Engineering Innovation (1984 - 2000)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
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

2000\08\31@214706 by Djula Djarmati

flavicon
face
............

> So, I repeat from the start:
> In the end, Microchip must allow one or more config bits to say:
> DISABLE INTERNAL READS OF FLASH MEMORY
> DISABLE ICSP
> ACTIVATE CODE PROTECTION FOR FLASH
> ALLOW OVERWRITING CODE PROTECTED FLASH

............


   I disliked your tone also but I guess I've been reading piclist too
much lately, lost contact with the real world.
   As for the problem, I think that the solution you suggest isn't clear
enough. I would use only 2 bits:

- Disable external R/W access (except ERASE ALL)
- Disable internal R/W access

   You could then program/verify the chip, disable external access and
make a real good bootloader with encryption and all kinds of protection and
then give the customer the encrypted file to upload.

   While you are waiting for the new revision, you could put the
bootloader in, leave the chip unprotected, and burn (destroy) one of the
two pins used for ICSP disabling any external access - of course if you can
spare that pin since your design is so critical ;)

Regards,
Djula

--
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


'[pic]: lousy code protection on F87X !!! Are you k'
2000\09\01@074923 by Andrew Kunz
flavicon
face
:-)









Tony Nixon <Tony.NixonSTOPspamspamspam_OUTENG.MONASH.EDU.AU> on 08/31/2000 05:47:41 PM

Please respond to pic microcontroller discussion list <spamBeGonePICLISTSTOPspamspamEraseMEMITVMA.MIT.EDU>








To:      KILLspamPICLISTspamBeGonespamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: [pic]: lousy code protection on F87X !!! Are
         you kidding me?








Andrew Kunz wrote:
>
> I agree 100% with you Tony.  Good points, good idea!
>
> >If it's like what happens here at times, the people with the loudest and
> >fastest mouths manage to get priority over the thinkers.
>
> Does that mean I'm at the head of the line? <G>

I'm thinking, I'm thinking ;-)

--
Best regards

Tony

ICmicro's
http://www.picnpoke.com
EraseMEsalesspamEraseMEpicnpoke.com

--
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

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

2000\09\01@090703 by Alan B. Pearce

face picon face
>Not lost in all this, of course, is that if Microchip's disabling of ICSP or
>disabling of internal reads can be undone, then the chip is never secure
>anyway, regardless, making all this effort a waste of time.  Does anyone
>know of any way to crack the code protect options on this chip?  Let's hope
>microchip did their homework.

If your code is really that valuable, then some one will get a programmed chip,
and remove the epoxy so they can get at the bare chip. It would then be a
reasonably simple process to erase the code protect bits and read your code.
Especially if the person(s) involved are in any way familiar with the Microchip
die layouts. Even if they were not familiar, it would not be too hard to figure
out likely places to bombard with alpha particles to clear the relevant
protection bits.

Information on how to remove the epoxy has been on this list in the past - look
for references to fuming nitric acid if I remember correctly.

If this has already been covered by others, I apologize, but have just read this
message while catching up after a holiday weekend, and busy week.

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

2000\09\01@102322 by onlistpost anonlistpost

picon face
Hello all, from Bill Davis.  So my anonymity is blown, people seemed to be
very insulted by my hidden name.  Call me paranoid, but always better safe
than sorry.

My easiest path will be if I just give up the idea of safe code. I can throw
some road blocks by code protecting certain stable blocks and hiding code
with bank specific code protection, but the more code that is code protected
the fewer banks that remain that can be flashed, ultimately giving me a chip
I need to consider OTP, or do a physical recall and/or chip swap.

Beyond that, how difficult is it for someone to, as Alan just suggested,
remove the epoxy on the chip and erase the code protct bits to then download
all the hex code?  Sure, they've got to disasseble it and reverse engineer
it, but can they easily get at it?  Is removing the epoxy to expose the die
a real possibility or just a very difficult to achieve project or outright
myth?

If one can erase the code protect, than it stands to reason chip recalls
with 100% code protect are futile.  And best to just use flash for flash and
only try and use code protection to dissuade the ambivalent.  The determined
thief, it appears, can aways expose the die and get at your code by erasing
the bits.  Is this a real possibility?

Shall I surrender to defeat on this and just use flash and leave my code
naked??

Thanks...
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

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

2000\09\01@104608 by M. Adam Davis

flavicon
face
Well, the determined thief needs BOTH time and (money or equipment).  One would
require a very powerful microscope with some sort of alpha bombardment device
(or very, very, very tiny probes).  In other words, only a chip fabrication
plant would have the resources to perform this kind of operation.

However, the cost to do so, even with the right equipment, would be very high.
High enough that it would be cheaper for someone to hire a programmer and
duplicate your functionality.  The only thing you might be protecting in your
chip which they may not be able to duplicate are keys or passwords.  But give
enough time, they could probably determine reasonable approximations such that
they could replace your chip with theirs.  This is also the best legal route to
go.

So, in other words, you need to weigh your need for code protection and what
lengths you need to go to for protection, over their need to make your chip
cheaper by burning their own.

Again, use the right tool for the right job.  It appears that your two top
prioritys are code protection and flash upgradability.  You cannot achieve both
completely in the PIC.  The best you can do is a reasonable approximation.  As
indicated above, the ONLY part of a PIC program which cannot be eaily duplicated
by a good programmer are keys and passwords.  Those, hopefully are either not be
used, or not going to change.  If you aren't using them, then there is no big
reason to code protect your chip, all it does it force someone to program a
reasonable approximation of what you're doing, rather than an exact copy.

So, yes, you may as well surrender one to the other if you are heck bent on
using a 16f8xx.

-Adam

anonlistpost anonlistpost wrote:
> If one can erase the code protect, than it stands to reason chip recalls
> with 100% code protect are futile.  And best to just use flash for flash and
> only try and use code protection to dissuade the ambivalent.  The determined
> thief, it appears, can aways expose the die and get at your code by erasing
> the bits.  Is this a real possibility?
>
> Shall I surrender to defeat on this and just use flash and leave my code
> naked??

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

2000\09\01@111300 by Don Hyde

flavicon
face
You should take a few minutes to evaluate the threats to your intellectual
property (your code).

A customer who wants to buy one and clone a handful for his own use would
probably have to spend more money doing the epoxy melting thing than what it
would cost to buy them from you.  He might do it anyway, but it would not
make good economic sense for him to do so.  It'll be hard to tell if he does
because he's only going to make a few units, and may not have to tell
anybody else he's doing it.  Code protect will probably stop him, he's
probably lazy as well as dishonest.  Just about anything non-trivial will do
the job.

On the other hand, if your code protection scheme makes your product harder
to use and maintain, a competitor who doesn't bother may lose more sales to
cloning, but capture the market.  That's why big outfits like Microsoft
don't mess with dongles and stuff.  They figure that when people steal their
stuff, it's still increasing their market share and decreasing their
competitors sales.

Someone who is cloning thousands either for his own use or for sale is
ripping you off for some real money.  He could afford the time and trouble
to do the epoxy melting and all that.  By the same token, he's ripping you
off for enough to make it worth your while to hire a lawyer to sue his @ss.
It'll also be easier to discover that he's doing it because if he's using
thousands himself he has enough employees that one is likely to talk, and if
he's selling them, he has to get the word out somehow, and if you listen,
you're likely to hear.

If some company in China is cloning your stuff by the millions, they can
clone the whole chip.  Welcome to the big time along with Microsoft, etc.
Your schools of lawyersharks can at least stop them from flooding the U.S.
market, but you're not likely have any more success stopping them on their
home ground than Bill has.

> {Original Message removed}

2000\09\01@111507 by Alan B. Pearce

face picon face
>If one can erase the code protect, than it stands to reason chip recalls
>with 100% code protect are futile.  And best to just use flash for flash and
>only try and use code protection to dissuade the ambivalent.  The determined
>thief, it appears, can aways expose the die and get at your code by erasing
>the bits.  Is this a real possibility?

Check out this web site. http://www.cl.cam.ac.uk/~mgk25/tamper.html

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

2000\09\01@161400 by Olin Lathrop

flavicon
face
> Hello all, from Bill Davis.  So my anonymity is blown, people seemed to be
> very insulted by my hidden name.  Call me paranoid, but always better safe
> than sorry.

So I'm curious.  What kind of product is this PIC going into where code
protection is so important?  Is this a high volume ultra-competitive low
margin consumer product?  Is the PIC a major part of the product in terms of
final end user price?  I've done a lot of PIC projects and have not had much
reason to care about code protection.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, @spam@olin@spam@spamspam_OUTcognivis.com, http://www.cognivis.com

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

2000\09\01@214654 by Ray Gardiner

flavicon
face
>
>Shall I surrender to defeat on this and just use flash and leave my code
>naked??
>

A few years back, I used the following scheme, you might be able to adapt it
to slow down would be copiers of your product.

First dervive a number from the object code, using a suitable algorithm.
This number is stored in eeprom during the manufacturing process. Hash it
with
a unique serial number. (I had a DS1994 which claims to have a unique serial
number) If you don't have this then generate a unique 64 bit serial number
for each unit manufactured. This then provides a means for your code to
validate itself, by comparing the derived number with the number installed
during manufacturing.

Now the clever bit. If you detect a mismatch indicating that the product
has not been "registered", generate a random time delay say 10 - 48 hours.
Then, after that time, fail the product in some subtle way that will not
be easy to debug for the copier. Preferably causes some damage, maybe self
destruct, depends on what hardware you have at your disposal. At very least
you should erase any configuration data in eeprom etc. etc.

Now, what happens is the copy of the product will appear to function for a
while and then start to screw up, preferably at random, and with maximum cost
to the environment it is placed in.

It won't stop them but it will sure cost them more.

Good luck with the project.

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

2000\09\01@221850 by Dale Botkin

flavicon
face
> First dervive a number from the object code, using a suitable algorithm.
> This number is stored in eeprom during the manufacturing process. Hash it
> with
> a unique serial number. (I had a DS1994 which claims to have a
> unique serial
> number) If you don't have this then generate a unique 64 bit serial number
> for each unit manufactured. This then provides a means for your code to
> validate itself, by comparing the derived number with the number installed
> during manufacturing.
>
> Now the clever bit. If you detect a mismatch indicating that the product
> has not been "registered", generate a random time delay say 10 - 48 hours.

Maybe I'm just dense this evening.  If the PIC itself contained the unique
serial number and the hash, and I copied the PIC, wouldn't it work forever?

I spent most of today working with a product from a very nice company that I
won't name.  They sell an "appliance", which is really nothing more than a
fairly standard PC running a pretty standard UNIX.  Their *software* is what
turns a $1200 PC into a $50K appliance.

Their copy protection method is to key the software to the MAC address of
the network card(s) installed by the factory (sound familiar?).  You could
clone the software, but it won't run in a box with different network cards.
Unless, that is, you happen to have some of the older $10 ISA 10Mbit cards
that would allow you to set the MAC address with the factory setup/diag
floppy.  Only one or two (depending on the model) would be needed, and you
could use "real" NICs for the real work.

Interesting approach.  I figure if I had larceny in my heart, it would take
me a couple of hours to have a hardware workaround, and probably a week to
find & rewrite the code that checks the key to produce a cracked copy that
would run on anything.  I haven't bothered, and won't either.  There's a
built-in gotcha -- if you'd pay $50K for the first one, most likely you've
got the bucks and the business justification to pay for the rest.  And if
you're going to rip off a company to compete with their $50K appliances, you
can bet they're figuring about $10K per unit (or more) of that for lawyers
to smother you in lawsuits.

There's a message in there somewhere, I think.  Maybe a couple of them.

Dale

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

2000\09\02@034634 by Ray Gardiner

flavicon
face
>Maybe I'm just dense this evening.  If the PIC itself contained the unique
>serial number and the hash, and I copied the PIC, wouldn't it work forever?
>

Yes, I used a DS1994 which contains a unique 64 bit serial number
(call it a key if you like). It is not stored on the PIC.

The DS2401 or similar would be a cheaper alternative than the DS1994.

Go to www.dalsemi.com/products/autoinfo/autoinfo.html
for more info on the DS2401.

To "register" a 16F877 PIC at manufacturing time, you would do something like,

       1. Generate a number from the object code, hashed in some
          way with the serial number.

       2. Program that "registration" number into the PIC's code
          space. Thereafter that particular chip is "locked" to
          that serial number.

       3. At run time recalculate the "registration" number. And
          compare with the number generated at time of manufacture.
          If the comparison fails then cause the product to
          fail in some random, time consuming, expensive fashion.

I hope that conveys the general idea a bit better.

For PICS that can't read the code space directly, you would have to use
RETLW's or something similar.

The scheme  will fail if the serial number is easy to copy. But
The aim of the exercise is to make life as hard as possible for
would be copiers. The purpose here is to make the enemy spend more
resources, making their copy fail in an "expensive" way could do this.

Depending on what hardware is controlled by the product, you could
be fairly imaginative about the type of failures your code produces.
For example, making the ADC read weird numbers at random might send
them off looking for a hardware problem.  If it has to communicate
with other devices, then randomly sending stuff that will confuse
the other devices will spread the symptoms out more. Don't fail
completely, just randomly and relatively infrequently, so that it
is as time consuming as possible to trace.

Ray Gardiner spamBeGonerayspamKILLspamdsp.com.au
mail from: dsp systems

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use .....listservspam_OUTspammitvma.mit.edu?body=SET%20PICList%20DIGEST>

2000\09\02@061701 by Alan B. Pearce

face picon face
>Their copy protection method is to key the software to the MAC address of
>the network card(s) installed by the factory (sound familiar?).  You could
>clone the software, but it won't run in a box with different network cards.
>Unless, that is, you happen to have some of the older $10 ISA 10Mbit cards
>that would allow you to set the MAC address with the factory setup/diag
>floppy.  Only one or two (depending on the model) would be needed, and you
>could use "real" NICs for the real work.

>Interesting approach.  I figure if I had larceny in my heart, it would take
>me a couple of hours to have a hardware workaround, and probably a week to
>find & rewrite the code that checks the key to produce a cracked copy that

I think every NIC I have seen has a small EEPROM on it to hold the MAC address
for the card. It would not take much effort at all to remove one of these and
copy it. What happens on a system when you have multiple NIC's with the same
MAC?

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use TakeThisOuTlistserv.....spamTakeThisOuTmitvma.mit.edu?body=SET%20PICList%20DIGEST>

2000\09\02@063815 by Alan B. Pearce

face picon face
>The scheme  will fail if the serial number is easy to copy. But
>The aim of the exercise is to make life as hard as possible for
>would be copiers. The purpose here is to make the enemy spend more
>resources, making their copy fail in an "expensive" way could do this.

The other trick here is to have the serial number reported to a console at some
stage so it appears that is what the unique serial number chip is for, otherwise
they may suspect some form of hashing of code, and go looking for it.

Another trick which was mentioned in this list some months ago was to use a
diode matrix in a keyboard or some such, where certain diodes were got at during
manufacture to blow them short or open. Another trick you could do here is to
remark a resistor - probably a zero ohm one as some reasonable value, and mark
it on any circuit diagram as a select on test, and use this as part of a divider
attached to an A/D port. If they copy the circuit and put in a resistor of the
marked value, then the results will be all up the creek, and they will need a
big paddle to get back on track.

It reminds me of the story of two golfers going to play a game. One of them was
a much better player than the other. The bad golfer agreed to the game on the
condition he was allowed two "gotchas". The good golfer agreed to this, and so
they went off to the course. The first hole went OK, with the good golfer
winning the hole very easily. They go to tee off at the second hole, and just as
the good golfer swings his club, the other golfer manages to spoil the swing, so
the ball goes only a short distance. The good golfer turns around to abuse the
other player, only to be told that was the first "gotcha". They play on, and the
good golfer is now that nervous of what the other golfer might do, he has a bad
game, and the poor golfer wins the game. Back at the clubhouse the good golfer
says to the other player about how he used only one gotcha. The other one says
he did not need too, as he one the game.

The moral is to make it as hard and expensive as possible to copy your device,
because the outfit doing the copying has to decide at some point if it is
financially worth their while debugging their copy of your design. If they find
some of these dinky little tricks that have taken significant time and expense
to debug, they will wonder how many more of them there are in the unit that they
have yet to find, and may give up trying to clone it. If you are making a
satellite TV scrambler card, then there are people who will set out to crack it
whatever time it takes, just because it is there!

If you are going to sell many units at small profit margin, then you have to
design so it will take them many units to recover the debug costs. If you are
making few costly units, you have to have enough profit margin that any clone of
your unit has to be expensive enough that you can cut your margin to undercut
its price, and shut them out of the market.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use TakeThisOuTlistservKILLspamspamspammitvma.mit.edu?body=SET%20PICList%20DIGEST>

2000\09\02@111021 by Dale Botkin

flavicon
face
On Sat, 2 Sep 2000, Alan B. Pearce wrote:

> I think every NIC I have seen has a small EEPROM on it to hold the MAC address
> for the card. It would not take much effort at all to remove one of these and
> copy it. What happens on a system when you have multiple NIC's with the same
> MAC?

Not a problem on the PC, as far as I know, as even the 4-port NICs have
different MAC addresses per port.  I know Suns do this, but this hardware
is PC.

You could indeed change the MAC by hardware hacking the SEEPROM.  I
strongly suspect there's a very simple way, using either documented or
undocumented commands, to do it with an application program on a PC as
well.  I haven't looked into it in several years, but I have seen it done.
In fact, we used to keep backup NICs for our critical servers that had the
same MAC programmed in as the old ones.  That way if a NIC failed we could
replace it and not worry about one or two devices with 4-hour ARP cache
timeouts and no convenient way to reset 'em.

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
               -- Isaac Asimov

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use .....listservspamRemoveMEmitvma.mit.edu?body=SET%20PICList%20DIGEST>

2000\09\02@130033 by Bob Ammerman

picon face
DECNET _requires_ (or at least used to require, I don't know if this is
still true) the ability to set the MAC address of a NIC to include the
DECNET address.

Some NIC chipsets provide the ability to change the MAC address:

A relatively few (maybe none?) provide a documented way to change the
power-on MAC address.

Quite a few provide a documented way to change the MAC address in such a way
that it will function for a single power cycle.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2000\09\02@191128 by Mitchell D. Miller

picon face
> Some NIC chipsets provide the ability to change the MAC address:

I know that Intel EtherExpress16 cards used to allow you to change the power
up MAC via their configuration software.  Most of the non-name brand
products today allow you to set the desired MAC via their driver, but it
does not make a firmware change; the driver changes the MAC every time it
loads.

-- Mitch

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservspamspamBeGonemitvma.mit.edu?body=SET%20PICList%20DIGEST>

2000\09\03@231851 by Lou

flavicon
face
No that is not the way __any__ OEM Ethernet card works (modern ones anyway)
part of the Ethernet driver's job is to read the serial eeprom ,or whatever,
and
program the mac address in to the respective registers of the Ethernet
controller.
Almost _no_ Ethernet card has a hard-wired address in its controller. think
of how difficult that would
be for the manufacturer's of the cards -- each of the gate-arrays (Asics)
would have to
be individually eeprom programmed at the factory, or would have to have
flash cells
built in to the controller-- not cost effective, and usually not the way it
is done.

 ---Lou
{Original Message removed}

2000\09\03@233137 by xandinho

flavicon
face
>No that is not the way __any__ OEM Ethernet card works (modern ones anyway)
>part of the Ethernet driver's job is to read the serial eeprom ,or whatever,
>and
>program the mac address in to the respective registers of the Ethernet
>controller.

       This is a nice intro for an Ethernet Hack...


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

       All the best!!!
       Alexandre Souza
       spamBeGonexandinho@spam@spamspam_OUTinterlink.com.br

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

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspamspammitvma.mit.edu>

2000\09\04@042139 by Alan B. Pearce

face picon face
>No that is not the way __any__ OEM Ethernet card works (modern ones anyway)
>part of the Ethernet driver's job is to read the serial eeprom ,or whatever,
>and program the mac address in to the respective registers of the Ethernet
>controller. Almost _no_ Ethernet card has a hard-wired address in its
>controller. think of how difficult that would be for the manufacturer's
>of the cards -- each of the gate-arrays (Asics) would have to
>be individually eeprom programmed at the factory, or would have to have
>flash cells built in to the controller-- not cost effective,
>and usually not the way it is done.

This is why they have a separate EEPROM on the board. My understanding is the
ASIC directly reads from the EEPROM as part of its initialization process, not
the driver transferring it to the ASIC. The driver can then access the MAC, and
presumably change it if desired.

Whichever way it occurs, I still do not recall anybody mentioning what happens
if you have multiple copies of the same MAC address on the same network. My
memories of watching a network sniffer was that everything was related to the
MAC address in terms of where the source and destination of the message were
concerned. It is now a long time ago since I did this, so the memory may be
getting hazy on this.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\09\04@044911 by Lee Jones

flavicon
face
> Whichever way it occurs, I still do not recall anybody mentioning
> what happens if you have multiple copies of the same MAC address
> on the same network. My memories of watching a network sniffer was
> that everything was related to the MAC address in terms of where
> the source and destination of the message were concerned.

Well, it depends on how the network is built.  I'll assume
that we're considering the case where both cards are on the
same network segment.  (Everything would probably be fine if
the 2 cards were on different segments separated by any sort
of router which filtered on a higher level protocol address.)

Ethernet was originally a party line style.  This is typified
by coax (either thick or thin) or a simple repeater-style hub
(where every packet received on one port is sent out on every
other port).

Each Ethernet packet contains the destination MAC address in
the packet header.  If the destination address matches the one
programmed into the Ethernet card, then the packet is accepted
and stored in buffer memory.  The packet is then processed by
the upper levels of the protocol stack(s).

Note that you might be using more than one protocol stack on
the machine.  Each Ethernet card could be handling traffic for
a different protocol.  For example, one card could be doing
TCP/IP while the other is Netware SPX/IPX.  In this case, it
might work just fine (if the software is robust enough).

If you try to run the same upper level protocol, e.g. TCP/IP,
on 2 Ethernet cards with identical MAC addresses on the same
network segment, you'll almost certainly run into problems.

Now consider the case of networks based on Ethernet switches
rather than simple hubs/repeaters.  A switch keeps track of
the MAC address associated with each port and only sends out
a packet if the destination address matches.  I'd say it's a
real toss-up as to what such an Ethernet switch would do if
it saw the same MAC address on 2 different ports.

A tier of switches would devolve into the above case at the
"upstream" switch where the identical MAC address came in on
2 different ports.

Overall, I'd stay away from using the same MAC address on 2 or
more different Ethernet cards on the same network segment. :-)

                                               Lee Jones

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\09\04@095850 by Olin Lathrop

flavicon
face
> This is why they have a separate EEPROM on the board. My understanding is
the
> ASIC directly reads from the EEPROM as part of its initialization process,
not
> the driver transferring it to the ASIC. The driver can then access the
MAC, and
> presumably change it if desired.

There are lots of ways of doing this.  I worked on an ethernet switch once,
and the MAC address was taken from one of those Dallas Semiconductor little
non-volatile RAMs with the one-wire serial interface.  These can be (as can
be other PROMs) bought serialized within specific ranges of numbers.

Keep in mind that ethernet MAC addresses are not arbitrary.  Every ethernet
product in the world is initialized to a unique MAC address, and address
ranges are assigned to different manufacturers by the IEEE.  You can't just
go changing the MAC address unless you know exactly what you are doing.

> Whichever way it occurs, I still do not recall anybody mentioning what
happens
> if you have multiple copies of the same MAC address on the same network.
My
> memories of watching a network sniffer was that everything was related to
the
> MAC address in terms of where the source and destination of the message
were
> concerned. It is now a long time ago since I did this, so the memory may
be
> getting hazy on this.

Individual ethernet packets are addressed to MACs at the lowest level.
Higher level protocol may deal with sockets, IP addresses and the like.  The
ethernet hardware knows nothing about this and deals with MAC addresses
only.  Two devices on the same segment with the same MAC address will cause
major trouble.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinEraseMEspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\09\04@100928 by Bob Ammerman

picon face
> > Whichever way it occurs, I still do not recall anybody mentioning what
> happens
> > if you have multiple copies of the same MAC address on the same network.

Normally, this is a _very_ bad idea. However, it does allow for a very slick
way to provide redundant hosts for a specific function (although normal
desktop OS's don't support this concept).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\09\04@135011 by Dale Botkin

flavicon
face
On Mon, 4 Sep 2000, Alan B. Pearce wrote:

> Whichever way it occurs, I still do not recall anybody mentioning what happens
> if you have multiple copies of the same MAC address on the same network. My
> memories of watching a network sniffer was that everything was related to the
> MAC address in terms of where the source and destination of the message were
> concerned. It is now a long time ago since I did this, so the memory may be
> getting hazy on this.

At Layer 2, systems do indeed use the MAC address.  Having the same MAC in
two places will have some undesired effects, the severity of which will
depend on the traffic.  If the two devices bearing the same MAC have
different IP addresses AND it's a shared media (hub or coax) environment,
I'm not sure you'd see a problem other than a little extra CPU load.  In a
switched network you'll see packet loss, as the "real" MAC holder may not
receive all packets that are sent to the "imposter's" switch port.  I
think the severity of the problems on a switched network will largely
depend on how the switch manufacturer deals with MAC learning.

In a switched network, we've seen switches hit near 100% CPU utilization
and drop horrendous numbers of packets while trying to keep up with the
same MAC address moving from port to port from the switch's point of view.
This was with about 70Mbit/sec of traffic on a 100M switch.  Effective
throughput was extremely low and connections timed out by the thousands.
it was really quite a mess, and it really sort of resembled a bridge loop.

But this is quickly moving in an [OT] direction, I think.

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
               -- Isaac Asimov

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\09\04@135219 by Dale Botkin

flavicon
face
On Mon, 4 Sep 2000, Lee Jones wrote:

> A tier of switches would devolve into the above case at the
> "upstream" switch where the identical MAC address came in on
> 2 different ports.

I've seen it happen due to some quirks in the way a particular device was
designed.  It would forward packets without changing the source MAC
address in the header.  The switch saw the MAC on port X, updated its MAC
table.  Then it saw the same MAC on port Y, updated the table again.  Mack
to port X, anothe table update.  Within a few seconds, the swich CPU was
spinning its wheels and most everything ground to a halt.

It was ugly.  It also had a major switch/router vendor who shall remain
nameless stumped for several weeks.  Odd, considering all the equipment
was wearing the same logo.

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
               -- Isaac Asimov

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\09\04@150705 by Olin Lathrop

flavicon
face
> Normally, this is a _very_ bad idea. However, it does allow for a very
slick
> way to provide redundant hosts for a specific function (although normal
> desktop OS's don't support this concept).

I don't think it's that easy.  In theory is wouldn't matter how many MACs
grab the data for the same address, since there is no ACK for ethernet
packets.  However, you get into trouble when either or both cards try to
write.  This can happen even when not obvious, like in response to certain
broadcasts for example.  What if someone simply did a PING to any IP address
supported by either card?  I think that would result in major confusion
because sooner or later both cards wouldn't respond identically at the
identical time (well within 100nS).


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinEraseMEspamspam_OUTcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\09\05@133811 by Mitchell D. Miller

picon face
Lou,

I said ...
> >products today allow you to set the desired MAC via their driver, but it
> >does not make a firmware change; the driver changes the MAC every time it
> >loads.

You said ...
> part of the Ethernet driver's job is to read the serial eeprom ,or
whatever,
> and program the mac address in to the respective registers of the Ethernet
> controller.

Seems like we're _both_ saying the driver sets the MAC address every time
the driver is initialized.

-- Mitch

--
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

2000\09\18@065103 by Marc

flavicon
face
> As far as the suggeston for using another chip as the bootloader over ISCP,
> this is no good as it would still require two pins on the F87X.  And, it a
> waste of resources, and is unecessary, and actually facilitates code copying
> due to how well known the ICSP protocols are.  They can be recorded easily.

Didn't you say yourself that the inners of the product are protected
by 480V 10000A?  You can establish a cryptographically secure link on
the RS485, and place the In-Circuit-Program slave chip physically near
to the F87x, and use reflective opto sensors or similar at the slave
as a tamper detector.  It can report tamper attempts and let you decide
yourself then whether you want to continue upload the firmware or
rather disconnect and unscrew the product to look inside whether a
"PIC ISP protocol tap" has been installed or not.  Such a tap btw I have
built already in the past, if someone is interested :---)

As long as the slave reports (cryptographically secure) no tamper attempts,
you should be quite safe that nobody records your firmware.

Once one product reports tampering, though, an attacker might have
learned how to avoid your detection traps in the future.

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu


2000\09\18@082904 by Andrew Kunz

flavicon
face
They are not "protected' by that stuff, just surrounded by it.

My point is, they aren't secure.  Forget it.  Anything you do (even like your
crypto system) only slows someone down, or tells you it might have been
compromised.

I don't expect PICs to be secure.  Just secure-enough.  That's what they are,
and I'm happy.

Andy










Marc <EraseMEmarcspam@spam@AARGH.FRANKEN.DE> on 09/18/2000 08:50:04 AM

Please respond to pic microcontroller discussion list <@spam@PICLISTspam_OUTspam.....MITVMA.MIT.EDU>








To:      spamBeGonePICLISTEraseMEspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: [pic]: lousy code protection on F87X !!! Are
         you kidding me???








> As far as the suggeston for using another chip as the bootloader over ISCP,
> this is no good as it would still require two pins on the F87X.  And, it a
> waste of resources, and is unecessary, and actually facilitates code copying
> due to how well known the ICSP protocols are.  They can be recorded easily.

Didn't you say yourself that the inners of the product are protected
by 480V 10000A?  You can establish a cryptographically secure link on
the RS485, and place the In-Circuit-Program slave chip physically near
to the F87x, and use reflective opto sensors or similar at the slave
as a tamper detector.  It can report tamper attempts and let you decide
yourself then whether you want to continue upload the firmware or
rather disconnect and unscrew the product to look inside whether a
"PIC ISP protocol tap" has been installed or not.  Such a tap btw I have
built already in the past, if someone is interested :---)

As long as the slave reports (cryptographically secure) no tamper attempts,
you should be quite safe that nobody records your firmware.

Once one product reports tampering, though, an attacker might have
learned how to avoid your detection traps in the future.

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

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-request@spam@spamspamBeGonemitvma.mit.edu


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