Is it possible to c*rack pic programs?

[Analyzer]

Hi there,
I'm writing a program for pic 16f628 and i'm curious about cracking code protection algorithm.Is it possible to do that?If so, is there a mcu which has non-defeatable code protection?
Thank you.

 

[Nick C.]

Re: Is it possible to patch pic programs?

Hi there,
I'm writing a program for pic 16f628 and i'm curious about cracking code protection algorithm.Is it possible to do that?If so, is there a mcu which has non-defeatable code protection?
Thank you.

I wouldn't worry about it. Cracking MCU's is not as easy as it used
to be. Somebody would have to want your code REALLY badly to go
through the trouble and expense. I would be cheaper for them to
simply hire a programmer to reverse engineer the code. Microchip
has gotten a lot better about code security over the past 5 years.

Nick C.

 

[btbass]

Here is a hack for a 84, haven't tried it myself.
:?:
The vulnerability of the 16C84 is of particular concern. The 16C84 is
often used in smart cards issued by the satellite TV industry. These
cards are intended to permit access to encrypted TV channels, and
clearly there is a lot of interest in being able to clone the cards
thereby avoiding payment to the TV providers. This means the
protection topic is endlessly discussed in newsgroups like
alt.satellite.tv.europe. Every so often this newsgroup carries
adverts for hardware which is claimed to be capable of reading
protected PICs. I have always been skeptical of these claims. I have
changed my mind.

The fact that I provide information on a homebrew 16C84 programmer
means that I often get asked whether I know how to read protected
PICs. Recently an interesting situation arose. I received yet
another request for this information at exactly the same time that
someone happened to send me details of a technique claimed to
unprotect PICs. I simply passed these on from one correspondent to
the other. Much to my surprise the requester later wrote back to say
the technique worked (but he destroyed 3 PICs in the attempt). The
originator of the method is happy for the information to be placed in
the public domain although he wants to remain anonymous for some
reason. So for the benefit of PICLIST readers (and I know that
includes Microchip employees) here are his instructions more or less
verbatim (although the description is tied to his programmer the other
guy used a variant of mine):


> 1. I use the PIC16 programmer from Farnell Components (part no. 459-471).
>
> 2. The standard programming software supplied is ASLPIC from Application
> Solutions Ltd.
>
> 3. Install the 16C84 into a turned pin socket with pin 14 (VDD)
> cut off. Attach a flying lead to the stub of pin 14 and
> connect this to a power supply (0V to +14V) sharing a common
> ground with the programmer.
>
> 4. Run ASLPIC.
> Insert the PIC+socket into the ZIF on the programmer board and switch
> VDD to 5V.
> From the menu set the CP configuration fuse to OFF.
> Now set VDD to VPP-0.5V (approx 13.5 volts).
> Program the configuration fuses. (Reply on screen saying
> error invalid?? Ignore this error and set VDD back to 5V.)
> Switch VDD supply off at the power supply.
> Switch off programmer supply.
> Wait 10 to 20 secs.
> Switch on programmer supply.
> Switch the VDD supply to 5V.
> Read PIC.
>
> What may be confusing to people is the error message displayed
> when programming the configuration fuses, and next not waiting for
> the charge on the cells to fall back to 5 volts after setting the
> fuses. This is why I say switch off for 10 to 20 secs, but don't
> forget to reset the VDD supply to 5 volts first.


I must admit it looks like a surefire way to destroy PICs to me so I
haven't tried it myself even though the originator claims that he has
never fried a 16C84 this way. I realise the fact that I have never
tried it myself means that all this is just hearsay, but although
there are some points left to the imagination, the description is
explicit enough to be tested by those worried by such things.

 

[trevelyn]

From the datasheet:

Note the following details of the code protection feature on PICmicro® MCUs.
• The PICmicro family meets the specifications contained in the Microchip Data Sheet.
• Microchip believes that its family of PICmicro microcontrollers is one of the most secure products of its kind on the market today,
when used in the intended manner and under normal conditions.
• There are dishonest and possibly illegal methods used to breach the code protection feature. All of these methods, to our knowledge,
require using the PICmicro microcontroller in a manner outside the operating specifications contained in the data sheet.
The person doing so may be engaged in theft of intellectual property.
• Microchip is willing to work with the customer who is concerned about the integrity of their code.
• Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. Code protection does not
mean that we are guaranteeing the product as “unbreakable”.
• Code protection is constantly evolving. We at Microchip are committed to continuously improving the code protection features of
our product.

...All of these methods, to our knowledge,
require using the PICmicro microcontroller in a manner outside the operating specifications contained in the data sheet...

:lol:

 

[neuralc]

Hi,

I think, in some cases, the only way it's make a small routine that reads the content of the code memory and put it to the avaliable port's. Next we write it at the top of code space (only write this positions that should be free!) and hope that no code is there and of course, rewrite the reset position with a jump to the location of this code.
Of course you can loose every thing!

NeuralC

 

[hashim]

yes it is possible

Yes friend this is that a pic can be cracked but it is possible in some conditions please read the data sheet care fully you will found some good tips to protect your programe first one is to program the pic with ID SETTINGTHIS this will protect in some way

regards
Hashim

 

[Analyzer]

I've heard from somewhere 16f84 and 16c84 can be c*racked with some technics.For example with some laser pointers, they burn a small part of the package with a CAM device and paint there with conducting liquid.Then pic becomes readable.But i heard another thing, the microch*ip developed another software protection system and 16f628 uses that.Is that true? Did someone hear same thing and/or something useful about f628? Thanks

 

[ZeleC]

its a bit hard
here is a link u may find a lot in google if u search
https://www.cl.cam.ac.uk/~sps32/mcu_lock.html.
regards

 

[ZeleC]

its a bit hard
here is a link u may find a lot in google if u search
https://www.cl.cam.ac.uk/~sps32/mcu_lock.html
https://www.cl.cam.ac.uk/~sps32/mcu_sec.html
regards

 

[btbass]

neuralc's idea is good but it can't work with a pic.
You cant read the code memory, if you need constants in rom, you have to use a jump to a table of retlw instructions.
:!: