Searching \ for '[SOT] Copy Protection; Reverse engineering vs Thef' 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=copy+protection
Search entire site for: 'Copy Protection; Reverse engineering vs Thef'.

Exact match. Not showing close matches.
PICList Thread
'[SOT] Copy Protection; Reverse engineering vs Thef'
1999\04\30@144336 by Barry King

flavicon
face
Let me throw in my two cents on copy protection and why its
important.  I've moved this [OT], but it is related- the question is
what is the purpose of the copy protection bits, and whether is is
legitimate to defeat them (If you can).

Reverse engineering is the process of figuring out how someone else
did it.  Maybe OK, maybe not, it depends.

Plagarism is passing off someone elses work as your own.  That's
dishonest.  NOT OK.  If you are doing reverse engineering of a
product and plagarising it, don't expect any help from honest folks.

Theft is taking something away from its owner.  NOT OK.  If you are
reverse engineering a product so you can steal the development effort
by making "knock off" copies, don't expect any help from honest
folks.

With intellectual property, its often hard to know what the
"something" is, and who owns it, which is the distinction some of
us are trying to make.  But like I always tell my kids-you don't
HAVE to know who it belongs to- if you know it ISN'T yours,
that's all you need to know.

When someone new drops onto the list asking about cracking 'F84s, we
don't know what the PURPOSE is.  Some of us (including me) assume the
worst, and either ignore the post or get sarcastic with the person.

If the guy who asked about cracking a PIC gave more background
information, and so managed to convince us that he really wasn't a
crook, he might even get some help.

Now, I send product based on PICs all over the world, and I know that
none of the parts I use are unique.  Its my PROGRAM is what makes
it great (If I say so myself).  So if crooks can copy my code, there
could be knock-offs almost immediately (perhaps I flatter myself
that anyone would bother...) But that would mean a real loss of
real money.  That's THEFT.  SO, I use the "anti-theft" bits on my OTP
PICs.

Which brings me back ON topic: Is there any evidence that OTPs are
vulnerable to attack?  I know there were some infamous problems with
early OTPs and selective EPROM erasure attacks.  But the fact is
that many of us have ruined more recent /JW parts by programming
the code protects.  I suspect MicroChip buried the code protect bits
on the newer dies, or that they aren't EPROM.  I'm guessing you'd
need a Voltage Contrast electron microscope or other exotics to
defeat this.  Any comments?

Regards,
------------
Barry King
Engineering Manager
NRG Systems "Measuring the Wind's Energy"
spam_OUTbarryTakeThisOuTspamnrgsystems.com
Phone: 802-482-2255
FAX:   802-482-2272


'[SOT] Copy Protection; Reverse engineering vs Thef'
1999\05\03@123520 by John Payson
flavicon
face
|Which brings me back ON topic: Is there any evidence that OTPs are
|vulnerable to attack?  I know there were some infamous problems with
|early OTPs and selective EPROM erasure attacks.  But the fact is
|that many of us have ruined more recent /JW parts by programming
|the code protects.  I suspect MicroChip buried the code protect bits
|on the newer dies, or that they aren't EPROM.  I'm guessing you'd
|need a Voltage Contrast electron microscope or other exotics to
|defeat this.  Any comments?

All Microchip would have to do to make lots of people on this list
very happy would be to release, and adhere to a spec something like
the following:

**NOTE** NOT A REAL MICROCHIP SPEC **
 "On all PICmicro devices produced after 5/15/99, with the exception of
  those windowed parts featuring an unerasable code-protect fuse, the LSB
  of the memory cell following the last documented customer-ID address
  will be "zero".  On windowed parts with an unerasable code-protect fuse,
  that bit will be "one".  On windowed parts with an erasable code-protect
  fuse, the bit will be initially "zero", but UV exposure may subsequently
  change it to a "one".
**NOTE** NOT A REAL MICROCHIP SPEC **

Although I don't know the specifics of the PICs' "factory test" area, I
would suspect that there's at least one bit in there that Microchip could
burn on OTP's and leave blank on UV devices.  If Microchip were to do this
and document it, it would allow programming devices to avoid destroying
window parts (when burning older PICmicro OTP's, it would be necessary to
override the feature, but that shouldn't be a problem).

Could any of the Microchip people reading the list comment on the feasibi-
lity of this?  Note that it would probably not entail *ANY* change to the
silicon--merely to the documentation and (possibly) testing procedure.

1999\05\03@143947 by Tjaart van der Walt

flavicon
face
John Payson wrote:
{Quote hidden}

Hey! This is a swell idea! Dreaming up Mchip literature to
vent some frustration. Here's another one :

**********************************************
**NOTE** NOT A REAL MICROCHIP PRESS RELEASE **
**********************************************

         MCHIP SET TO SLASH PRICES WITH IMMEDIATE EFFECT

CHANDLER, Ariz., April 12, 1999 ÷ Mchip Technology Inc. today announced
that all PIC micro prices are set to be cut with up to 50% on some devices.
The price reductions are with immediate effect and will make thousands of
loyal PIC micro users world wide very happy. "We couldn't go on making our
loyal customers pay double for less functionality than what our competitors
offer" said Mr JB Goode, chief president in charge of many other chief persons.
"We have been consistently making more and more money each year, with
record profits each quarter. We felt that it was high time we reward our
users with the prices they deserve. Truth is, we really can afford it!" said
Mr B Counter, chief president, bean counting.

ADD ONE ÷ NEW PRICES MAKE PICMICROs COMPETITIVE AGAIN

Users of PICMicro can now rest assured that they can continue designing
new projects with confidence, knowing that their products will compete
against those of competitors using other micros.

ADD TWO ÷ DESIGNERS DON'T HAVE TO BEG FOR FUNDS FOR NEW DEV TOOLS

By this dramatic and bold move, Mchip ensured that designers won't
have to feel like idiots for asking for new development tools.

**********************************************
**NOTE** NOT A REAL MICROCHIP PRESS RELEASE ** <sigh>
**********************************************

I guess I really stepped into it now!

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
.....tjaartKILLspamspam@spam@wasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : tjaartspamKILLspamsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\04@062457 by Caisson

flavicon
face
> Van: John Payson <.....supercatKILLspamspam.....CIRCAD.COM>
> Aan: EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU
> Onderwerp: Re: [SOT] Copy Protection; Reverse engineering vs Theft
> Datum: maandag 3 mei 1999 18:37
>
> Although I don't know the specifics of the PICs' "factory test" area, I
> would suspect that there's at least one bit in there that Microchip could
> burn on OTP's and leave blank on UV devices.  If Microchip were to do
this
> and document it, it would allow programming devices to avoid destroying
> window parts (when burning older PICmicro OTP's, it would be necessary to
> override the feature, but that shouldn't be a problem).

Something TOTALLY different:  We've got fusable Code-protect bits.  That
will dis-allow the code to be read.  Why can't they introduce a
"Code-protect disable bit" ?  It would enable JW-part users to disable the
Code-protect bit, thus NOT keeping them on their toes when programming such
a part.

Greetz,
 Rudy Wieser

1999\05\04@101116 by Mark Willis

flavicon
face
Caisson wrote:
{Quote hidden}

 IIRC the die for a /JW part is *identical* to that for an OTP part,
the only difference being that Quartz window.  John's idea might be
easier to get Microchip to implement, as it wouldn't require a silicon
change, just a test procedure change, which Microchip might be far more
agreeable to than changing their silicon so us developers won't have to
buy more pricey /JW parts...  I imagine the OTP parts make up most of
their sales, after all.

 Thought that occurs to me is that Microchip could burn this bit on ALL
devices - /JW or not - in a UV erasable area, and then require that you
erase the /JW device before first use, at which point you can tell (once
that bit erased) whether you have a JW or a OTP part.  (Flash parts
could be confusing in this situation, except the part NUMBER tells you
they're flash parts, rather clearly <G>)

 Mark

1999\05\04@115704 by John Payson

flavicon
face
> > Although I don't know the specifics of the PICs' "factory test" area, I
> > would suspect that there's at least one bit in there that Microchip could
> > burn on OTP's and leave blank on UV devices.  If Microchip were to do
> this
> > and document it, it would allow programming devices to avoid destroying
> > window parts (when burning older PICmicro OTP's, it would be necessary to
> > override the feature, but that shouldn't be a problem).

|  Thought that occurs to me is that Microchip could burn this bit on ALL
|devices - /JW or not - in a UV erasable area, and then require that you
|erase the /JW device before first use, at which point you can tell (once
|that bit erased) whether you have a JW or a OTP part.  (Flash parts
|could be confusing in this situation, except the part NUMBER tells you
|they're flash parts, rather clearly <G>)

Requiring that /JW parts be customer-erased prior to use in order to
take advantage of this feature seems unduly annoying, especially with
parts like the PIC14000 which have useful information in the EPROM.

As for the part number indicating that a part is "flash", it'd be nice
if Microchip could include an indication of the part number in a read-
able part of the customer area.  Unfortunately, a die change would be
needed for that to work with /JW parts so that probably isn't going to
happen.  Still, a bit in the factory area that indicated the part was
"flash" might be a good thing, since trying to program an ordinary part
with the "flash" algorithm will in many cases slag the part (turning on
programming for 10+ms is a bit too much I think).

1999\05\04@163512 by Mark Willis

flavicon
face
John Payson wrote:
> <snipped>
> |  Thought that occurs to me is that Microchip could burn this bit on ALL
> |devices - /JW or not - in a UV erasable area, and then require that you
> |erase the /JW device before first use, at which point you can tell (once
> |that bit erased) whether you have a JW or a OTP part.  (Flash parts
> |could be confusing in this situation, except the part NUMBER tells you
> |they're flash parts, rather clearly <G>)
>
> Requiring that /JW parts be customer-erased prior to use in order to
> take advantage of this feature seems unduly annoying, especially with
> parts like the PIC14000 which have useful information in the EPROM.

 Good point, I haven't played ^H^H^H^H^H^H^H^H worked with the 14k
parts yet.  <G>

> As for the part number indicating that a part is "flash", it'd be nice
> if Microchip could include an indication of the part number in a read-
> able part of the customer area.  Unfortunately, a die change would be
> needed for that to work with /JW parts so that probably isn't going to
> happen.  Still, a bit in the factory area that indicated the part was
> "flash" might be a good thing, since trying to program an ordinary part
> with the "flash" algorithm will in many cases slag the part (turning on
> programming for 10+ms is a bit too much I think).

 Factory area makes total sense to me, 2 bits should be available, I
hope?  I'd think we developers CAN tell the difference between Flash &
non-flash parts, though, on good days anyways, if we tell the programmer
which part we're programming, is this necessary or just a would be
nice?  (I'm sure you're using some part that I'm not thinking of <G>)

 Mark

1999\05\05@102603 by John Payson

flavicon
face
> As for the part number indicating that a part is "flash", it'd be nice
> if Microchip could include an indication of the part number in a read-
> able part of the customer area.  Unfortunately, a die change would be
> needed for that to work with /JW parts so that probably isn't going to
> happen.  Still, a bit in the factory area that indicated the part was
> "flash" might be a good thing, since trying to program an ordinary part
> with the "flash" algorithm will in many cases slag the part (turning on
> programming for 10+ms is a bit too much I think).

|  Factory area makes total sense to me, 2 bits should be available, I
|hope?  I'd think we developers CAN tell the difference between Flash &
|non-flash parts, though, on good days anyways, if we tell the programmer
|which part we're programming, is this necessary or just a would be
|nice?  (I'm sure you're using some part that I'm not thinking of <G>)

The problem comes when somebody else uses the programmer and sets it
to do the parts they're doing, and then I go ahead and use it without
realizing the change (expecting it to still be set the old way).  It'd
be nice to have the programmer detect the "oops" condition without any
damage to the part.

1999\05\05@125436 by Gerhard Fiedler

picon face
At 09:25 05/05/99 -0500, John Payson wrote:
>|  Factory area makes total sense to me, 2 bits should be available, I
>|hope?  I'd think we developers CAN tell the difference between Flash &
>|non-flash parts, though, on good days anyways, if we tell the programmer
>|which part we're programming, is this necessary or just a would be
>|nice?  (I'm sure you're using some part that I'm not thinking of <G>)
>
>The problem comes when somebody else uses the programmer and sets it
>to do the parts they're doing, and then I go ahead and use it without
>realizing the change (expecting it to still be set the old way).  It'd
>be nice to have the programmer detect the "oops" condition without any
>damage to the part.

i think the processor type should be in the hex file and read by the
programmer. of course it would be nice if the programmer could verify that
the right part is in the socket, but that's then a more rare error (and
equal to using the wrong program, which it couldn't verify anyway).

ge

1999\05\06@061349 by Caisson

flavicon
face
> Van: Gerhard Fiedler <KILLspamlistsKILLspamspamHOME.COM>
> Aan: RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU
> Onderwerp: Re: [SOT] Copy Protection; Reverse engineering vs Theft
> Datum: woensdag 5 mei 1999 18:51

Hello Gerhard,

> i think the processor type should be in the hex file and read by the
> programmer. of course it would be nice if the programmer could verify
that
> the right part is in the socket, but that's then a more rare error (and
> equal to using the wrong program, which it couldn't verify anyway).

Hmmm...  The controller-type as first line in the hex-file.  To be
"programmed" at an adress that is _equal_  on _all_ types of PIC's.  This
couple of bytes contains the Pic's identification (maybe coded) and is
_read-only_. The programmer tries to write this controller-type value into
the Pic's (read-only) memory, and will fail if that couple of memory-cells
do not contain the same value.

Ofcourse, the programmer could be queried to what kind of controller it has
got in it's socket, so that a warning could be displayed before the actual
programming took place ...

It would stop the killing of PIC's by supplying them with a wrong (read:
targetted to another type of PIC) Hex-code.

Now let's see if MC pick's up the idea :-)

Greetz,
 Rudy Wieser

1999\05\06@075107 by Walter Banks

picon face
> From: Caisson
> Hmmm...  The controller-type as first line in the hex-file.  To be
> "programmed" at an address that is _equal_  on _all_ types of PIC's.
This
> couple of bytes contains the Pic's identification (maybe coded) and is
> _read-only_.

Most of the Hex formats have information type record types in their format
what has been missing is universal consensus over the format of an
identification type record.

I am all in favor of putting identifying information in the HEX file.
The MPC compiler has processor and configuration information
internally and it is easy to bring this information out.

We believed that processor identification was important and when we
developed the .COD file format included it in Byte Craft's .COD file.


Walter Banks
http://www.bytecraft.com

1999\05\06@134024 by w. v. ooijen / f. hanneman

picon face
> Most of the Hex formats have information type record types in their
format
> what has been missing is universal consensus over the format of an
> identification type record.
>
> I am all in favor of putting identifying information in the HEX file.
> The MPC compiler has processor and configuration information
> internally and it is easy to bring this information out.

When the 'world' comes to a standrd for putting this info in a hex
file let me know, I'll be happy to generate it with my humble
JAL compiler (humble at least compare to HT-C).

Wouter.

1999\05\06@134844 by mathias

flavicon
face
>
>Most of the Hex formats have information type record types in their format
>what has been missing is universal consensus over the format of an
>identification type record.
>
>I am all in favor of putting identifying information in the HEX file.
>The MPC compiler has processor and configuration information
>internally and it is easy to bring this information out.
>
>We believed that processor identification was important and when we
>developed the .COD file format included it in Byte Craft's .COD file.
>
>
>Walter Banks
>http://www.bytecraft.com
>

I believe Parallax implemented some of the earliest HEX file encodings of
PIC device types.  This is probably the nearest thing to a standard.  It is
compatible with the last Parallax tools (SPASM and SPEP) and all current
TechTools tools (CVASM, PICWriter and TDE).  I believe there are also a
number of 3rd party programmers, assemblers and compilers that adopted this
encoding as well.

This format is accepted by many, but the device code selections may have
diverged recently.  We added about 40 new devices to our assembler and
programmer recently and,of course, made up new device codes for these new
devices.

I would be willing to document the Parallax encoding and the TechTools
extent ions and open it for comments, if there is enough interest.


Jerry Merrill

spamBeGonejerrymspamBeGonespamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

1999\05\07@065447 by Caisson

flavicon
face
> Van: Walter Banks <TakeThisOuTwalterEraseMEspamspam_OUTBYTECRAFT.COM>
> Aan: RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU
> Onderwerp: Re: [SOT] Copy Protection; Reverse engineering vs Theft
> Datum: donderdag 6 mei 1999 13:41

Hello Walter,

<Snip>

> Most of the Hex formats have information type record types in their
format
> what has been missing is universal consensus over the format of an
> identification type record.
>
> I am all in favor of putting identifying information in the HEX file.
> The MPC compiler has processor and configuration information
> internally and it is easy to bring this information out.
>
> We believed that processor identification was important and when we
> developed the .COD file format included it in Byte Craft's .COD file.

It's not really the information in the .HEX-file I was referring to, but a
few bytes in the controller itself that will hold the controllers type.
This way several checks can be done, ranging from trying to overwrite the
data (and failing if the .HEX-file targets another controller-type) and to
be able to query (and display) the controllers type by the PC (or
programmer).

Information about the controller in a "Information-record" has got no value
(IMHO) if nobody can use this data.  It's (maybe) valuable if non-telling
filenames are used, or when dis-assembling the .HEX -file.  In the first
case I would prefer a Human-readable header .  And the second case ....
should never occur :-)

Greetz,
 Rudy Wieser

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