How to protect a code uC?

Thread Starter

Tajiknomi

Joined Mar 18, 2010
34
Suppose i had made a program for a specific application and i want to protect this code from others to extract from uC.
Anyone can extract mu .Hex file & put it in their uC, How the industry products protect their code in uC ?
 

JohnInTX

Joined Jun 26, 2012
4,787
Most uC with internal memory have ways to prevent reading the embedded code. For Microchip uC, you set bits in the CONFIGURATION registers when blasting the chip. Go to microchip.com and search on Code Protect or download a couple of PIC datasheets and Programming Specifications for more information..
 

Papabravo

Joined Feb 24, 2006
21,159
In fairness I should point out that this protection only protects you from a hobbyist with a device programmer. It does not protect you from a determined villain with unlimited time and resources who will slice open the package, exposing the die to examination with high tech tools. He might have to ruin a handful of devices, but the code will be extracted. Have a look at Sergei's web page.

https://www.cl.cam.ac.uk/~sps32/mcu_lock.html

EDIT: Sorry I forgot the link
 
Last edited:

ScottWang

Joined Aug 23, 2012
7,397
Which uC do you want to use?
The uC use fuse to protecting the code, when you download the code into the uC and burn the fuse then from outside can't read the code.
 

ScottWang

Joined Aug 23, 2012
7,397
Yes you can; see post #3
What I said is the general method can't do it, and I knew if you willing to pay then such thing is easy.
The linking page is old, so I can't find any related with arduino.
I will look more carefully about what you linked, thanks.
 

Papabravo

Joined Feb 24, 2006
21,159
What I said is the general method can't do it, and I knew if you willing to pay then such thing is easy.
The linking page is old, so I can't find any related with arduino.
I will look more carefully about what you linked, thanks.
He decided to leave the original page alone, but there is a link to more processors that he has investigated.

http://www.cl.cam.ac.uk/~sps32/sec_news.html
http://www.cl.cam.ac.uk/~sps32/phd.html
http://www.springer.com/us/book/9781441980793

PS. I wouldn't give Springer a plugged nickel if my life depended on it.
 

spinnaker

Joined Oct 29, 2009
7,830
In fairness I should point out that this protection only protects you from a hobbyist with a device programmer. It does not protect you from a determined villain with unlimited time and resources who will slice open the package, exposing the die to examination with high tech tools. He might have to ruin a handful of devices, but the code will be extracted. Have a look at Sergei's web page.

https://www.cl.cam.ac.uk/~sps32/mcu_lock.html

EDIT: Sorry I forgot the link

Is that possible with chips that use EEPROM?

I find this one interesting.

Eavesdropping techniques monitor, with high time resolution, the analog characteristics of all supply and interface connections and any other electromagnetic radiation by the processor during normal operation

I remember back in the day of the old monochrome monitor someone demonstrating a device that could eavesdrop on a monitor remotely.
 

Papabravo

Joined Feb 24, 2006
21,159
Is that possible with chips that use EEPROM?

I find this one interesting.

Eavesdropping techniques monitor, with high time resolution, the analog characteristics of all supply and interface connections and any other electromagnetic radiation by the processor during normal operation

I remember back in the day of the old monochrome monitor someone demonstrating a device that could eavesdrop on a monitor remotely.
I think that EEPROM and Flash are basically the same technology. If they can dissolve the plastic package, they can probe the die. A Ceramic package is much harder to disassemble. They are made to be hardened agains physical attack, and some of them will eat carbide tools.
 

JohnInTX

Joined Jun 26, 2012
4,787
@Papabravo
Inteeeerrristing! I probably would assert that wafer probing is beyond the reach of all but the most determined hackers but your links indicate that for a lot of parts, its a more prevalent problem than I would have thought. I see that the list of PICs refers to older parts. I am assured by uCHIP that new ones are better but they have a disclaimer on pg2 of every datasheet saying that code protection is not absolute.. interesting indeed.

We think one of our 16F84A designs got stolen way back when. I did a controller for a client that private labeled them to a company in Australia. They suddenly quit buying ours and began marketing a veerrry similar device, right down to the pinout. There were a few detail differences but it sure looked familiar.

The 'F84 was used in Direct TV account cards so everyone and their crooked brother were cracking them and posting how to's. There even were (are?) services advertised that would help you 'recover your code from your own code-protected chips'. You would send them several exemplar chips and they would mess with them until they got the same image out of each one, thus verifying the 'recovery'. How nice. Here's what I did to at least slow them down and make them earn their money.

I split up the assembly language source files into individual functions - several hundred of them. I then wrote a Borland C program to generate a randomized #include file to shuffle the include order and reassemble for each and every hit on the PROGRAM CHIP button. I also sweetened the pot by rewriting the RAM allocation file to randomize each labeled RAM location for each build. I didn't calculate the number of permutations that resulted, satisfied that it was 'a lot'. Screw them and their verify.

After that experience, I will usually put something non-obvious in a design that is accessible from the outside and that can be readily discerned if you know what you are looking for. Maybe between any consecutive vowels in the LCD display the enable pulse is 1.2X what is usually is. Is that LED flashing or is it signaling? Stuff like that. Fool me once, shame on me. Fool me twice and .. won't get fooled again.
 
Last edited:

Papabravo

Joined Feb 24, 2006
21,159
Our defense was simply to improve and innovate faster than the copycats could keep up. Field updatable firmware was a big improvement for out customers and allowed us to keep ahead of allmost everyone.
 

spinnaker

Joined Oct 29, 2009
7,830
I think that EEPROM and Flash are basically the same technology. If they can dissolve the plastic package, they can probe the die. A Ceramic package is much harder to disassemble. They are made to be hardened agains physical attack, and some of them will eat carbide tools.
But isn't an EEPROM basically just an electrical charge on a floating-gate? That can be sen with a microscope?
 

spinnaker

Joined Oct 29, 2009
7,830
Who said microscope? @spinnaker, what do you mean by probe? I assumed probing bypassed the chips control circuitry and addressed the memory cells directly.

Ah I inferred it in my own mind "exposing the die to examination with high tech tools.". Should have realized there are other ways to do that.


I think I was thinking of the discussion on making knock off chips that went on in another forum.
 
Top