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...
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!
=====
...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
> 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
>> 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).
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:
>
> |
> |
> 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
>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.
> 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
> 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
> 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)
> 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.
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).
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..
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?
> 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
>
>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...
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.
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 <.....engineerKILLspam.....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.
janso.com.ar
