Searching \ for '[PIC] Code Protection' 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: 'Code Protection'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Code protection'
2004\09\28@121655 by Mauricio Jancic

flavicon
face
Retagged...        

Hi, Marcio Wrote:
>>I am looking for a way to protect my product. I am thinking
>>about loading a bootloader and burning the pin B7.
>>
>>Burn would be a 12v surge applied to this pin.
>>
>>Does someone have this experience?


And I say:

Hi Marcio,
       I've been discussing this with some customers and partners... I
think it's not necessary... I assume that you want to load the PIC memory
with the bootloader, then damage the RB7 pin, and then load the program
trough the bootloader... Right?

Anyway:
- If you have a bootloader, unless you have a sophisticated bootloader
"password" someone might brake into it
- If you have code protection, some people claim to be able to brake it. I
think they would, but the cost and benefits from copying a given device must
be big, because those proceedings are not cheap. Sometimes it would be
cheaper to make the device starting from scratch...
- Some people tend to erase the part no on, for example, the PIC. Now, if
such a board is given to me, I think it might take me 5 to 10 minutes to
determine which PIC it has (or which kind... pIC16F873/6, for example...)

So, why not simple code protection?
Also, if you have a bootloader, you can make an special instruction that
makes the bootloader erase itself...

regards

Mauricio Jancic
Janso Desarrollos
Microchip Consultant Program Member
(54) 11-4542-3519
spam_OUTinfoTakeThisOuTspamjanso.com.ar
http://www.janso.com.ar

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist


'[PIC] Code Protection'
2006\01\03@001201 by Darren Gibbs
picon face
Howdy,

Does anyone have a pointer to a more thorough explanation of the PIC  
(in my case 18F1320 and 18F452) code protection options than the data  
sheet provides?  It's not clear to me after reading the very terse  
explanation exactly how this works.  For example, I'm not sure what  
the point of the code protection bits is if you can read code with  
the table read instructions (as seems to be suggested by the data  
sheet).  Any info much appreciated!

Happy New Year,

darren

2006\01\03@013717 by n Pergola (sent by Nabble.com)

flavicon
face

|
|
Darren Gibbs wrote:

=====
...I'm not sure what the point of the code protection bits is
if you can read code with the table read instructions...
=====


Hello Darren,

You have to think about what 'protection' means from two angles:

1) From a PIC MCU programmatic sense (PIC's perspective while executing code)
2) And from and external device programmer sense (External device programmer's perspective)


Sometimes you want the PIC MCU to be able to read/write some of its code memory (or combinations thereof) programmatically but you don't want a device programmer to do the same.


Perhaps this breakdown I whipped up will help you to understand things a bit more:


:: Code-Protect bit
  ----------------
1) The 'Code-Protect bits' do not affect the PIC in a programmatic sense (regardless of the fact that the bits are either enabled or disabled)

2) The 'Code-Protect bits' (when enabled) will affect the ability for a device programmer to read the PIC's "true" contents (unless the PIC's true contents are 0s for the applicable code memory locations).


:: Write-Protect bit
  -----------------
1) The 'Write-Protect bits' (when enabled) do affect the PIC in a programmatic sense. If a block is table write-protected, the PIC will not be able to erase or write code memory programmatically -- even if the table write attempt occurs in the *same* code memory block that is table write-protected.

2) The 'Write-Protect bits' setting (in isolation) do not affect the ability for a device programmer to erase or write to the PIC's code memory. I say 'in isolation' meaning that the 'code protection' bits are assumed to be disabled for this statement to be true.


:: External Block Table Read bit
  -----------------------------
1) The 'External Block Table Read bits' (when enabled) do affect the PIC in a programmatic sense. If a code memory block is external table read-protected, the PIC will not be able to read the PIC's "true" contents from a code memory block outside of the code memory block that is table read-protected. However, *any* external table read-protected block can read its own memory contents.

2) The 'External Block Table Read bits' (in isolation) do not affect the ability for a device programmer to read the PIC's code memory. Again, I say 'in isolation' meaning that the 'code protection' bits are assumed to be disabled for this statement to be true.  


Darren, just spend some more time reading the data sheet and it should eventually make sense -- even if you have to re-read it ten times that is perfectly fine -- do not feel bad.


Are you ok with the description of the Data EEPROM and configuration bits (aka configuration bytes, or configuration words) protection techniques?



Best regards,

Ken Pergola

P.S. What Microchip usually refers to 'program memory' I usually refer to as 'code memory' since it is less awkward to say "program code memory' instead of 'program program memory (when referring to the act of programming this type of flash memory in the PIC MCU).


--
Sent from the MicroControllers - PIC forum at Nabble.com:
www.nabble.com/-PIC-Code-Protection-t840970.html#a2179848

2006\01\03@015220 by Wouter van Ooijen

face picon face
> For example, I'm not sure what  
> the point of the code protection bits is if you can read code with  
> the table read instructions (as seems to be suggested by the data  
> sheet).  Any info much appreciated!

If you prevent the user from enetring his own code you can allow code
reading, which is usefull for storing constant data.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\03@083952 by Alan B. Pearce

face picon face
>> For example, I'm not sure what
> the point of the code protection bits is if you can
>> read code with the table read instructions (as seems
>> to be suggested by the data sheet).  Any info much
>> appreciated!
>
>If you prevent the user from enetring his own code you
>can allow code reading, which is usefull for storing
>constant data.

Or bootloader (but perhaps Wouter thinks of this as constant data, but I
think of constant data as strings or data constants that would not be in
RAM).

2006\01\03@221704 by Darren Gibbs

picon face
Hmm... thanks for the explanation.  I understand now the difference  
between what a device programmer is allowed to do or not, and what  
the program code is allowed to do or now.  So, if I'm interested in  
keeping someone from copying my application out of the PIC's flash, I  
only need to enable the CodeProtect bit(s)?  Or is it possible for  
someone to cleverly download a program into the PIC which would use  
table reads to grab a copy of my code?  From what I've seen around  
the net, it seems like some people have figured out a way around the  
PIC copy protection anyway, but I'd still like to do what I can to  
protect my code.

thanks,

darren

On Jan 2, 2006, at 10:37 PM, Ken Pergola (sent by Nabble.com) wrote:

{Quote hidden}

> --

2006\01\03@230621 by Bob Axtell

face picon face
Darren Gibbs wrote:

>Hmm... thanks for the explanation.  I understand now the difference  
>between what a device programmer is allowed to do or not, and what  
>the program code is allowed to do or now.  So, if I'm interested in  
>keeping someone from copying my application out of the PIC's flash, I  
>only need to enable the CodeProtect bit(s)?  Or is it possible for  
>someone to cleverly download a program into the PIC which would use  
>table reads to grab a copy of my code?  From what I've seen around  
>the net, it seems like some people have figured out a way around the  
>PIC copy protection anyway, but I'd still like to do what I can to  
>protect my code.
>  
>
I'm skeptical of these "ways around" the PIC copy protection. They
require major
physical changes to the device, including removal of the moisture
barrier layers,
to accommodate these "ways around". Some such schemes might even work
once or twice. But the efforts seem inordinately costly to most
hobbyists, and
many companies.

You can almost always do something once, and with luck, maybe twice. I'll be
convinced that the PIC copy protection scheme has been cracked when somebody
opens a business offering the service and guaranteeing the result.

I'm still waiting.

--Bob



>thanks,
>
>darren
>
>  
>

--
Note: To protect our network,
attachments must be sent to
.....attachKILLspamspam@spam@engineer.cotse.net .
1-520-777-7606 USA/Canada
http://beam.to/azengineer

2006\01\04@023224 by Wouter van Ooijen

face picon face
> Hmm... thanks for the explanation.  I understand now the difference  
> between what a device programmer is allowed to do or not, and what  
> the program code is allowed to do or now.  So, if I'm interested in  
> keeping someone from copying my application out of the PIC's
> flash, I  
> only need to enable the CodeProtect bit(s)?

correct, unless you allow the user to download his own code. In that
case you would also have to worry about that code reading your secret
code (using table reads).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\04@023224 by Wouter van Ooijen

face picon face
> You can almost always do something once, and with luck, maybe
> twice. I'll be
> convinced that the PIC copy protection scheme has been
> cracked when somebody
> opens a business offering the service and guaranteeing the result.

A 'guranteed' result would be required for a succesfull cracking
business. But a 'sometimes' result would be sufficient to 'sometimes'
ruin a buisiness based on the read protection.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\04@030235 by Jinx

face picon face
> A 'gauranteed' result would be required for a succesfull cracking
> business. But a 'sometimes' result would be sufficient to 'sometimes'
> ruin a buisiness based on the read protection.

I know people "get away with murder" every day, but how exactly
could you offer (and advertise ?) a successful cracking business ?
I'm sure you'd eventually attract some very "interesting" associates

(that's a very hypothetical "how would you" BTW - I can't even
crack a smile some days)


2006\01\04@040353 by Russell McMahon

face
flavicon
face
> when somebody
> opens a business offering the service and guaranteeing the result.

I recall the first half being confidently offered on-list by one
"Starfire Xhee" (second name may not be quite correct) long ago.


       RM


2006\01\04@043156 by Gerhard Fiedler

picon face
Bob Axtell wrote:

> You can almost always do something once, and with luck, maybe twice. I'll
> be convinced that the PIC copy protection scheme has been cracked when
> somebody opens a business offering the service and guaranteeing the
> result.

I'm not sure the absence of such a "business" is a good indicator for
anything. Since such a business would be illegal (AFAIK at least), I don't
think you can expect one anytime soon -- even if techniques for cracking
the protection should be widely known.

Gerhard

2006\01\04@105624 by Darren Gibbs

picon face

On Jan 3, 2006, at 11:32 PM, Wouter van Ooijen wrote:

>> Hmm... thanks for the explanation.  I understand now the difference
>> between what a device programmer is allowed to do or not, and what
>> the program code is allowed to do or now.  So, if I'm interested in
>> keeping someone from copying my application out of the PIC's
>> flash, I
>> only need to enable the CodeProtect bit(s)?
>
> correct, unless you allow the user to download his own code. In that
> case you would also have to worry about that code reading your secret
> code (using table reads).

So how does one disallow code downloads?

2006\01\04@112758 by Wouter van Ooijen

face picon face
> So how does one disallow code downloads?

you don't, you'd have to take special measures to allow that.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\05@160313 by andrew kelley

picon face
Or if you have need of a secure chip, pot the chip and run a thin thin wire
through the potting, tie the wire to a input and output, and check if the
wire is there.. If its not, the potting was removed and erase the code..
Also you can destroy the bond wires for RB7 and RB6, I've seen that was done
somewhere by someone, perhaps on the list archives..

andrew

2006\01\05@160834 by Herbert Graf

flavicon
face
On Thu, 2006-01-05 at 16:03 -0500, andrew kelley wrote:
> Or if you have need of a secure chip, pot the chip and run a thin thin wire
> through the potting, tie the wire to a input and output, and check if the
> wire is there.. If its not, the potting was removed and erase the code..
> Also you can destroy the bond wires for RB7 and RB6, I've seen that was done
> somewhere by someone, perhaps on the list archives..

Please correct me if I'm wrong, but the easiest way to get a chip out of
a potting compound is to use something to disolve the potting compound.
As such, the wire would survive?

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2006\01\05@162603 by Wouter van Ooijen

face picon face
Nice ideas, but...

> Or if you have need of a secure chip, pot the chip and run a
> thin thin wire
> through the potting, tie the wire to a input and output, and
> check if the
> wire is there.. If its not, the potting was removed and erase
> the code..

But you'd need power to do the erasing. You'd need to include a battery
in the potting. An attacker might cool the thing down below the
battery's working point and then remove the potting, and lateron
reisntall the wire.

> Also you can destroy the bond wires for RB7 and RB6, I've
> seen that was done
> somewhere by someone, perhaps on the list archives..

If you can destroy them someone else can reinstall them. After all
factories do that all the time.

Nothing wrong with extra security measures, but don't let them give you
a false sense of absolute (or even 'high') security.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\05@175923 by Bob Axtell
face picon face
Herbert Graf wrote:

>
>Please correct me if I'm wrong, but the easiest way to get a chip out of
>a potting compound is to use something to disolve the potting compound.
>As such, the wire would survive?
>
>TTYL
>
>-----------------------------
>Herbert's PIC Stuff:
>http://repatch.dyndns.org:8383/pic_stuff/
>
>  
>
Yes, you can use MEK on MOST potting compounds. The wire survives, yes, but
most PVC's do not. MEK will also destroy the seals on most capacitors,
so its a bit
of a mess, but the ICs seem to survive it OK.

MEK is Methyl Ethyl Ketone,

But it REALLY stinks... you will attract police, who think it is a
methamphetamine
lab...

--Bob

--
Note: To protect our network,
attachments must be sent to
attachspamKILLspamengineer.cotse.net .
1-520-777-7606 USA/Canada
http://beam.to/azengineer

2006\01\05@180203 by David VanHorn

picon face
Data stored in RAM isn't secure with power removal either.
I saw a case where encryption keys were retained not only after loss of
power, but even after shorting VCC to ground for days, and then powering up
the system and writing to the data area.  When powered down and back up, the
keys re-appeared!

Apparently long term storage in those SRAM cells caused a bias.. If the keys
had been stored a short time you couldn't recover them and if longer times
you'd get partial recovery, but if it was long enough, they'd come back from
the dead.

The problem was soved by keeping the key data on the move in a circular
buffer.

2006\01\08@184745 by andrew kelley

picon face
Hrm... maybe in that case, make a conductive layer in the potting
(that the potting solvent will dissolve) between the pins for the code
erase?

On 1/5/06, Bob Axtell <.....engineerKILLspamspam.....cotse.net> wrote:
> Yes, you can use MEK on MOST potting compounds. The wire survives, yes, but
> most PVC's do not. MEK will also destroy the seals on most capacitors,
> so its a bit
> of a mess, but the ICs seem to survive it OK.

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