Searching \ for 'Security' 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/index.htm?key=security
Search entire site for: 'Security'.

Truncated match.
PICList Thread
'Security'
1996\09\09@003013 by Carson S. Meyers

picon face
Greetings;
I have been following the discussion of security problems w/ the 16C84
with great interest!  We are currently implementing a design onto a 16C84
because of it's 'security'.  What I have been reading about the lack of
real security is rather terrifying, as our project dare have such a lack
of security!  The product is not a 'low-cost' unit, so a higher priced
PIC would be acceptable if it really has greater security.

We are stopping development immediately using the 16C84 unit!

Does anyone know of any other PICs that are MUCH more secure???

Your help will be greatly appreciated!

--
                  Carson S. Meyers
                  Meyers Services
         (704)926-8860 / FAX (704)926-8860
            spam_OUTcarsonTakeThisOuTspamprimeline.com

It's not a matter of can or cannot;  it is a matter of will or will not!

1996\09\09@004507 by Robert Lunn

flavicon
face
>We are stopping development immediately using the 16C84 unit!
>
>Does anyone know of any other PICs that are MUCH more secure???

       Well, if you've been following the discussion you know
       what various people would say about "MUCH more secure!!!"

       In any case, the security hole with the 'C84 is strongly
       related to its use of EEPROM code memory.  So as a *general*
       statement the EPROM PIC's don't suffer this problem.

       You will probably find that a 16C61 + 24LC01 is actually
       cheaper than a 16C84 (but takes more pcb space and costs
       two I/O lines).

___Bob

1996\09\09@052015 by Dave Mullenix

flavicon
face
>        In any case, the security hole with the 'C84 is strongly
>        related to its use of EEPROM code memory.  So as a *general*
>        statement the EPROM PIC's don't suffer this problem.

Can anybody outline exactly how this security hole works?  I've had a couple
of FTP and Web sites suggested and one seems to have a program that will break
the security on a PIC chip, but it has no source code, so I have no idea
what it's doing.

I assume that anybody who wishes to compromise the security on a PIC chip
for nefarious purposes already knows how to do it, so no cats will be let
out of the bag by divulging the general method here.

1996\09\09@072314 by fastfwd

face
flavicon
face
Dave Mullenix <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU> wrote:

> I assume that anybody who wishes to compromise the security on a PIC
> chip for nefarious purposes already knows how to do it, so no cats
> will be let out of the bag by divulging the general method here.

I don't follow your logic here, Dave...

Your purposes are -- presumably -- educational only, but YOUR wish
to know hasn't magically given you the information, right?  How do
you figure that it's any different for "nefarious" persons?

-Andy

Andrew Warren - fastfwdspamKILLspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\09\09@080819 by Jim Robertson

flavicon
face
At 02:44 PM 9/9/96 +1000, you wrote:
>>We are stopping development immediately using the 16C84 unit!
>>
>>Does anyone know of any other PICs that are MUCH more secure???

>
>        In any case, the security hole with the 'C84 is strongly
>        related to its use of EEPROM code memory.  So as a *general*
>        statement the EPROM PIC's don't suffer this problem.

Agreed! No security is "bullit proof" but the 16C84 is particularly
problem, as Bob pointed out, because of the EEPROM memory.

>
>        You will probably find that a 16C61 + 24LC01 is actually
>        cheaper than a 16C84 (but takes more pcb space and costs
>        two I/O lines).

Or a 16C621 is cheaper again and provides better security [IMCO] than the
older 16C61. Also consider the emerging 16C55x parts for the same reasons.

>
>___Bob
>

Jim

1996\09\09@215859 by Carson S. Meyers

picon face
Greetings;

A postscript to my earlier question about security with the 16C84:
       Is the One Time Programmable unit the one being spoken of with
the security problem, or is it just the EEPROM unit that I thought was
just for development?
       Has anyone worked with a much more secure PIC (or even heard of
such) - even by another manufacturer?

Thanks for your help!
--
                  Carson S. Meyers
                   Meyers Services
         (704)926-8860 / FAX (704)926-8860
            .....carsonKILLspamspam.....primeline.com

It is not a matter of Can or Can Not, it is a matter of Will or Will Not.

1996\09\09@225208 by Robert Lunn

flavicon
face
>A postscript to my earlier question about security with the 16C84:
>        Is the One Time Programmable unit the one being spoken of with
>the security problem, or is it just the EEPROM unit that I thought was
>just for development?

       There is no 'OTP' 16C84.

       The 16C84, being EEPROM based, is always reprogrammable.

       (and I do mean _always_ :) )

___Bob

1996\09\10@190404 by Les Gruebner

flavicon
face
Andy Warren wrote:
>Dave Mullenix <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> wrote:
>
>> I assume that anybody who wishes to compromise the security on a PIC
>> chip for nefarious purposes already knows how to do it, so no cats
>> will be let out of the bag by divulging the general method here.
>
>I don't follow your logic here, Dave...
>
>Your purposes are -- presumably -- educational only, but YOUR wish
>to know hasn't magically given you the information, right?  How do
>you figure that it's any different for "nefarious" persons?

Since anyones purpose for needing to know how the 16C84 security was cracked
seems immediately suspect, lets consider this-

A product designer is nearly finished developing a 16C84 project for a major
client when it is learned that the code security may be weak.

The customer insists on the best security rather than the *await theft and
then sue* options.
The 16c84 is otherwise the best chip for the application (some more I/O
would have made it ideal...)

The chip suppliers claim that Microchip verbally assure them that code
security has been enhanced in more recent silicon, but can not (will not)
supply any documentation to support this.

Baffled and not reassured by this response, the query is re-sumitted this
time clarifying that the briefest of written reassurances from a chipmaker
of such superb repute would be adequate - it was _not_ intended to offend,
_not_ expecting the chipmaker to divulge exact changes made to the code
protection mechanism.
Same vague response. Uh oh, have names been written into a "nefarious"
persons list already?

The designer turns to the helpful resources of the internet and the piclist
in particular. SVR. (Is near-silence worse than being flamed?)

The big question seems to be, if you _really_ want to use this chip or any
EEPROM uC, do you _really_ have to do your own security code effectiveness
tests?

That could mean collecting cracking methods, trying them on earlier 16C84s
such as those old prototyping chips you've been using for months and if
their code protection fails, try the same methods on new chips to see if
there is at least some improvement, for starters.
If anyone has been down this road and can figure it OK to entrust their
discoveries to others, I know a frustrated product designer who would be
keen to hear from you please.

-Les

Les Gruebner - lesgruebspamspam_OUTwave.co.nz
-Electronic Remedies, Tauranga, New Zealand

1996\09\11@022123 by fastfwd

face
flavicon
face
Carson S. Meyers <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU> wrote:

> Is the One Time Programmable unit the one being spoken of with the
> security problem, or is it just the EEPROM unit that I thought was
> just for development?

   Carson:

   There IS no OTP 16C84... They're ALL EEPROM, except for the
   masked ROM 16CR84.

> Has anyone worked with a much more secure PIC (or even heard of
> such) - even by another manufacturer?

   The EPROM PICS (any PIC other than the 16C8x series) don't have
   the EEPROM-specific security problems, so I guess you could say
   that they're "much more secure".

   -Andy

Andrew Warren - KILLspamfastfwdKILLspamspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\09\11@030353 by Bob Blick

picon face
This whole security thing is getting a little spidery, can someone fill me
in on all the details at once? I have some specific questions, too:

Am I correct in assuming a code-protected 16c84 can be read using a modified
programmer and some software gotten from an ftp site that caters to pe0PL<
Wh0 spEL funny?

Am I also correct in assuming that the software only works on one of the
homemade type of programmers, ie the AN589 or the David Tait programmer?
If this is the case it means I'm going to try it out for myself, because all
this vague talk going around doesn't inspire confidence or keep things
secret, the cat's out of the bag and there's no putting it back. I hadn't
heard about it before last week, but by now anyone really interested in
ripping off code has heard about it and probably found the tools to do it
with, if it is actually possible. They've certainly gotten what I got,
because I only spent 5 minutes with one of the search engines and turned up
something that seems likely.

I downloaded a program that promises to be a pic buster and I guess I'll try
to figure out what programmer it runs on and build one, and I'll see if it
works. If anyone has already done this and wishes to share their findings,
please do so and save me the trouble, because mostly what I want to know is
the truth about the 16c84 from SOMEONE WHO ACTUALLY HAS FIRSTHAND KNOWLEDGE.
If this thing does not work, I think we can all breathe easier, because a
fake pic buster may actually enhance the security of the 16c84(especially if
it ruins the chip). Hmmm, maybe I'd better not try it :-)

1996\09\11@031817 by John Payson

flavicon
face
> If this thing does not work, I think we can all breathe easier, because a
> fake pic buster may actually enhance the security of the 16c84(especially if
> it ruins the chip). Hmmm, maybe I'd better not try it :-)

There is a way of rendering any PIC secure against all non-invasive attacks
though it will cost an I/O pin and is not guaranteed by Microchip or
anyone else not to render a chip unreliable.  But here goes: real simple...

[1] Write the software on the chip so as not to use port bit B6.  (or if
   you prefer B7)

[2] Connect port bit B6 (or B7) to some nice friendly voltage (I used AC120
   once by mistake; you may want something a little milder) while ensuring
   that VDD and Ground are not allowed to go more than five volts apart.

From the times this accidentally happened to me (working on a power control
circuit) my perceptions are:

[1] The pin inputs and drivers will be pretty well 100% blown.

[2] Nothing else on the chip SEEMS to be damaged.

Note that without the ability to electrically tell the chip to read the
program data, the crackability of the code-protect fuse will be a moot issue;
if the i/o transistors for PB6 are blown, it's a bit hard to "unblow" them.

1996\09\11@041358 by Onat Ahmet

flavicon
face
<stuff deleted>
       [1] The pin inputs and drivers will be pretty well 100% blown.

       [2] Nothing else on the chip SEEMS to be damaged.

       Note that without the ability to electrically tell the chip to read
       the program data, the crackability of the code-protect fuse will be
       a moot issue; if the i/o transistors for PB6 are blown, it's a bit
       hard to "unblow" them.

Hmm, nice idea, but how does one make sure that nothing else is
blown(quality control issue)... Field upgrades are not possible
anymore either(replacement upgrade chip, rather than reprogramming?)...

1996\09\11@103049 by myke predko

flavicon
face
Never being shy about jumping in to a topic, let me add my two cents worth.

I'm convinced that there is any way in which you can prevent somebody from
stealing your object code.  This feeling comes from an experience we (at
Celestica) had with a customer that was terrified that his product's code
(mask programmed inside a Motorola DSP65K) would be ripped off.

We told him that, from our experience with a pretty wide range of products,
we didn't think going to extreme lengths was necessary.  Two months after
the products First Customer Ship (FCS), we got a card back where somebody
had taken off the DSP56K, broke open the top of the component to look inside
(we were amazed that the guy had the gall to return the card for a "warrenty
repair").

The customer freaked and the product was redesigned to use a chip die, was
wirebonded to the card and potting compound was glopped over the top.  This
cost the customer an ungodly amount of money (basically his expected profits
for the first two years of the product).

And guess what happened two or three months after this happened?  Somebody
else returned a card for warrenty repair because the card was dropped by his
kid and the DSP56K "fell off".  (As Dave Barry would say, I'm not making
this up.)

At this point we (basically me with the help of the Celestica device lab)
investigated how easy it was to read an EPROM, Mask ROM, Fuse Link PROM, and
EEPROM (and with it, FLASH), with a variety of different packages and we
found that nothing was safe.  Actually, nothing we investigated could keep
the contents safe from someone who was serious for more than an hour.  (And
this included encasing a product in a block of epoxy!)  To make matters
worse, many Micros and Memories have undocumented features for reading out
data (used in the device development and test) that are widely known and
exploited in the hacker community.  (Part of the investigation was taking a
spin on the Web and looking at Hacker sites.  Bob Blick found a number when
he spent five minutes with a search engine, you can't imagine what you can
find when you look for a week (and say you want to hack a DSS security card).)

But, as a postscipt, the product was originally FCS'd in January of 1995.
The product is designed for PCs and since it's original introduction, there
have been a number of competitors.  But, it number one it's niche because of
their technical support and continuous upgrades.  Other than the first
upgrade, the following upgrade (and the next one we're getting read) use the
standard DSP56K PGA (Pin Grid Array) package, rather than the COB (Chip On
Board) Packaging that was "supposed" to keep the hackers out.

The customer is still not happy; he feels that he should have the only
product in the niche, not just lead in sales (a tough perception to deal
with).  He was/is very upset that there is no way to "absolutely" guarantee
the security of his code.  But, he also accepts that trying to make
something absolutely inpenatrable is impossible; his strategy now is to
continually improve the product so he can stay ahead of his competitors.  I
think the customer felt they had a "revolutionary" product that they could
design, let somebody else build, sell, and they would grow fat on the
royalties.

Obviously, there's a very significant message in this; you are only going to
have a maximum of six months exclusivity in a product before you better have
something better to replace it in the market.  If the product has the
potential of making a lot of money, you're gonna have competition whether
people are going to design their own or steal your designs.


Now, having pretty much said that it's impossible to copy protect a design,
would it be possible for a Chip Manufacturer to "scramble" the instructions
of one of their standard products (ie redirect the outputs of a MUX would be
pretty simple and would change the instructions radically)?  In this way, a
product could be designed using the standard products, but once production
was to start, the code could be recompiled for the "scrambled" product.
Obviously, the Chip Manufacturer would only sell this part to one customer
(to prevent anybody else from getting their hands on it).

I don't know if the Microchip products would be prime candidates for this
(becuase their limited instruction set wouldn't make the scrambling that
difficult to figure out).  But a CISC processor or DSP might be.  Any comments?

And if Microchip does offer this to their customers, I hope they remember
where the idea came from originally :)

Myke
{Quote hidden}

Do you ever feel like an XT Clone caught in the Pentium Pro Zone?

1996\09\11@114733 by R.J.Smith

flavicon
face
I personally think it's foolhardy to think that any one particular device
can give adequate copy protection. If a design engineer assumes the
product is 100% safe then they deserve what they get.

Perhaps there is a moral here: you only get what you pay for.

Rich


Department of Applied Physics, University of Hull, HU6 7RX
Tel 01482 465135  Fax 01482 465606 // E-mail EraseMER.J.Smithspamapphys.hull.ac.uk

1996\09\11@120032 by P{r Ligander

flavicon
face
<cut>

>
> Now, having pretty much said that it's impossible to copy protect a design,
> would it be possible for a Chip Manufacturer to "scramble" the instructions
> of one of their standard products (ie redirect the outputs of a MUX would be
> pretty simple and would change the instructions radically)?  In this way, a
> product could be designed using the standard products, but once production
> was to start, the code could be recompiled for the "scrambled" product.
> Obviously, the Chip Manufacturer would only sell this part to one customer
> (to prevent anybody else from getting their hands on it).
>
> I don't know if the Microchip products would be prime candidates for this
> (becuase their limited instruction set wouldn't make the scrambling that
> difficult to figure out).  But a CISC processor or DSP might be.  Any
comments?

Have you looked at the Dallas line of secure microcontrollers ??? It's about
what you are suggesting but much more advanced. Look at http://www.dallas.com for
more info.

/Pelle

1996\09\11@133119 by John Payson

flavicon
face
> <stuff deleted>
>         [1] The pin inputs and drivers will be pretty well 100% blown.
>
>         [2] Nothing else on the chip SEEMS to be damaged.
>
> Hmm, nice idea, but how does one make sure that nothing else is
> blown(quality control issue)... Field upgrades are not possible
> anymore either(replacement upgrade chip, rather than reprogramming?)...

The inability to reprogram the chip is just a consequence you'll have to
accept I guess.  As for ensuring nothing else is blown, there are only
two thing you can do:

(a) Ensure that any spike current has many, fairly well-balanced paths
   it can take so you don't blast out the power or ground wires and
   you don't push VDD and VSS more than 5v apart.

(b) You don't do this in applications where a failure would have severe
   consequences.

1996\09\11@154404 by peter

flavicon
face
Bob Blick wrote:
{Quote hidden}

   This could have been written by me. I am at the same stage.I have no
time to get any further yet.
So maybe this would be a good time to warn everybody suffering
from chronic paranoia to stock up on tranquillisers.
As soon as I(and a couple of thousand people like me)have the
time I/we will spend our every waking minute extracting the code from
your chip

To the people who don't spend their time looking over their shoulders
and biting their nails, I have reverse engineered thousands of products.
But not to copy them and take the bread from your childrens' mouths.
Mostly to repair them (in almost all cases without any help from the
manufacturers), other times for my own curiosity/knowledge but never
to manufacture copies (I don't want to be second best).

I defy all the paranoid people to tell me they have NEVER reverse
engineered some one else's product just to see how it's done !!.
I will tell you that I have NEVER manufactured someone else's
product.
By manufacture I do not include making a copy for my own use
to modify/improve. Having bought the product once this would not
financially affect anyone.

What is the purpose of the list if not educational? Now who is going
to decide what we should not learn?
Maybe we should look at advertising on the list before deciding what
pic info we should not give to the list?

 So lets have the picbust info PLEASE
--
Peter Cousens
email: RemoveMEpeterEraseMEspamEraseMEcousens.her.forthnet.gr
snailmail: Peter Cousens, Karteros, Heraklion, Crete, 75100, Greece,

1996\09\11@164549 by Roger Books

flavicon
face
Well, I have but one thing to say about the current discussion.  If you
practice security by obscurity then you have no confidence in your security
and nobody else should have any confidence either.

Roger

1996\09\12@070841 by Scott Stephens

picon face
At 11:00 AM 9/11/96 +1200, you wrote:
>Andy Warren wrote:
>>Dave Mullenix <RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU> wrote:
>>
>>> I assume that anybody who wishes to compromise the security on a PIC
>>> chip for nefarious purposes already knows how to do it, so no cats
>>
>>I don't follow your logic here, Dave...
>>
>>Your purposes are -- presumably -- educational only, but YOUR wish
>>to know hasn't magically given you the information, right?  How do
>>you figure that it's any different for "nefarious" persons?

I think most of us get a thrill from cracking tough problems and finding
creative, unconventional solutions. But our moral values make us reluctant
to steal, and inclined to pay others for thier hard work. And we're not
privey to the dark secrets of the underworld :(

Nefarious characters get a thrill from damaging and theft. They devote the
time and effort required to steal or break a system, and network with other
criminals. They have no morals to impede there  efforts.

>If anyone has been down this road and can figure it OK to entrust their
>discoveries to others, I know a frustrated product designer who would be
>keen to hear from you please.

I've collected a few cracking methods that have been posted here and the
electronics news group, that I'll post or E-mail as requested. I havn't
tried them. I dont think its wise to choose ignorance of evil. Do you trust
your competition to do likewise? I thought so.

The satallite TV industry makes me think of a girl who says, "no, please
stop" with a big satisfied delighted smile. Articles I've read about the
satalite pirate industry state it has popularized and made money for the
industry in the past. They could stop it but want to get subscribers hooked.
Then later, with expensive recievers and no more codez, they'll start
subscribing.

Seems to me weak security is a feature that benefits big corporate and
government thieves and spooks, organized criminals and those wishing to hook
customers on cheap, illigitimate service so they can make them pay later.

Small developers are those most damaged by this 'feature'. If Microchip
understands this 'feature' harms sales more than helps, they'll fix the
holes or eliminate them.

1996\09\12@070844 by Scott Stephens

picon face
>There is a way of rendering any PIC secure against all non-invasive attacks

>[2] Nothing else on the chip SEEMS to be damaged.

Good point. Best put some type of test routine in to test all the
instructions and features. Even then, Who knows what chemical reactions,
thermal stress or lattice metal migration changes have taken place?

>Note that without the ability to electrically tell the chip to read the
>program data, the crackability of the code-protect fuse will be a moot issue;
>if the i/o transistors for PB6 are blown, it's a bit hard to "unblow" them.

Be carefull. I've heard you can recover data from a hard drive that's been
over-written. The magnetic media is not 'digital', its analog. If you read
it using an analog head, the level of magnetization will vary according to
the previouse data. I've read to be realy safe you should overwrite with
random data at least 5 times!  Like a desk blotter or typewriter ribbon, you
can read a faint analog imprint of what was there.

Has anyone taken an analog scope and seen if any weak signal leaks past a
blown driver?

1996\09\12@113714 by John Payson

flavicon
face
> >Note that without the ability to electrically tell the chip to read the
> >program data, the crackability of the code-protect fuse will be a moot issue;
> >if the i/o transistors for PB6 are blown, it's a bit hard to "unblow" them.
>
> Be carefull. I've heard you can recover data from a hard drive that's been
> over-written. The magnetic media is not 'digital', its analog. If you read
> it using an analog head, the level of magnetization will vary according to
> the previouse data. I've read to be realy safe you should overwrite with
> random data at least 5 times!  Like a desk blotter or typewriter ribbon, you
> can read a faint analog imprint of what was there.
>
> Has anyone taken an analog scope and seen if any weak signal leaks past a
> blown driver?

Bear in mind that the signal would have to be able to go INTO the PIC via
the blown driver; from my understanding of how VLSI works, it's very
unlikely that the PIC would be able to detect the input from a fried pin
since it won't "know" to look for sub-volt signals in nearby parts of the
chip.

1996\09\13@030455 by Ing. Pablo Otero

flavicon
face
At 07:08 AM 9/12/96 -0400, you wrote:
>CUT..
>
>I've collected a few cracking methods that have been posted here and the
>electronics news group, that I'll post or E-mail as requested. I havn't
>tried them. I dont think its wise to choose ignorance of evil. Do you trust
>your competition to do likewise? I thought so.
>
>CUT..
       I will like to recive it either direct or posted here in the list,
maybe this security issue will be a long one, so let's Open it once for all
and it will be finished sooner than if small things continue Confusing a lot
of people, like now.

Pablo.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                              _/
_/                   N  A  F    Electronic                      _/
_/                       M e x i c o                            _/
_/                                                              _/
_/             e-mail: RemoveMEnafpocTakeThisOuTspamspammail.giga.com                     _/
_/                                                              _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1996\09\14@061417 by Scott Stephens

picon face
At 02:08 AM 9/13/96 -0600, you wrote:
>At 07:08 AM 9/12/96 -0400, you wrote:
>>CUT..
>>
>>I've collected a few cracking methods that have been posted here and the
>>electronics news group, that I'll post or E-mail as requested. I havn't
>>tried them. I dont think its wise to choose ignorance of evil. Do you trust
>>your competition to do likewise? I thought so.
>>
>>CUT..
>        I will like to recive it either direct or posted here in the list,
>maybe this security issue will be a long one, so let's Open it once for all
>and it will be finished sooner than if small things continue Confusing a lot
>of people, like now.
>

You could do better than asking me by dregding up what people have been
saying for the last few years, so:

1)      Use the "INFO REFCARD" command in a mail message body to
"EraseMElistservspamspamspamBeGonemitvma.mit.edu"
       and find out how to search the list digest or archive for relevant
postings.

2)      Use "DeJa News" or AltaVista, or whatever to search relavant news
group archives.

3)      Write Microchip asking them to either fix the holes or state their
protection is not secure.

You will find more information as I only collected enough info to become
convinced the C84 and most processors are not secure. But I will mail you or
whomever my 30K tid-bit info file I collected.

1996\09\14@133242 by Mark K Sullivan

flavicon
face
>It [code protection] is ineffective as a defense against those who
>have an economic motive to copy the product.  For the real pirates, if
>it is worth copying, then it is worth the effort to defeat the
>protection scheme.

I think this is an oversimplification.  Certainly both extremes exist but there
are shades of gray in between.  Any kind of security is a percentage game.  The
better your security, the fewer people can or will pirate your intellectual
property.  The "economic motive" must be stronger than the "effort to defeat"
and both will vary widely.

The cost of copying varies not only with the strength of protection, but with
the skill and other resources of the pirate.  Likewise the benefit to him
depends on his skill.  A skilled pirate may find it just as easy to code the
application from scratch (or, better yet, think of his own product and not have
to copy yours).  Even from following this thread, you can see that there are
people who
a> can figure out how to pop a chip by themselves,
b> can't figure it out but can find it on the 'net,
c> can't find it on the 'net but no doubt could copy an unprotected part.
Although probably not on the PICLIST, there are those who
d> could copy a product with no programmed parts in it but don't realize that
you can't just order a PIC16C54RC/P from the local distributor and solder it in.

And everything in between.  Also, this is a pyramid. There are more Ds than Cs,
more Cs than Bs, more Bs than As.

So your choice of code security draws a line and people above the line can copy
it but people below can't.  Satellite TV is widely hacked, but there are still
people paying for subscriptions.  Just because you can't drive the number of
"real pirates" for whom cracking your product is both possible and worth the
effort to zero doesn't mean you should give up and not try to minimize that
number.

I used to use the 8748 and have had designs stolen.  Twice by the customers they
were being custom made for!  Interestingly, neither could understand that they
had done anything wrong.  In one case, their corporate counsel couldn't
understand that they had done anything wrong.  In another, they actually sent a
pirate copy to us for repair!  So now I stick to code protected parts.  Even
though the 16C5x are amoung the easiest to crack (easier than the '84 in my
opinion), I haven't (so far as I know) had a design stolen yet.  That's not to
say it can't or won't happen, just to say that a little, imperfect, code
security has made a statistical difference in my admittedly small sample.

- Mark Sullivan -

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