Flash/eeprom based MCU code protection
HollyMinkowski
Posts: 1,398
As everyone here knows, there is no way to really protect your
code once you burn it onto flash or eeprom. Even MCUs that have
the code protection feature can be broken by unscrupulous Asian
hackers that sell their skills on the web.
I was running some code to see how many writes it would take to
totally fry a small section of the flash memory on an AVR. It was
quite a few I can tell you. It got me to thinking that if you used a program
to destroy small sections of the flash and then coded around those
sections while also routinely testing them so your code only will run if they
are destroyed that you could perhaps apply a lot of cleverness and
come up with a protection scheme that would make it a nightmare
for someone to get a working copy of your hex file
This is relying on the idea that anyone willing to pay to crack your
protected flash/eeprom code might not be skilled enough to easily
decompile your asm code and take out all the memory checks. It
might not be worth the effort, and a 3rd party would probably charge
a great deal to do it for them.
It occurred to me that this could also protect the hex file inside the
eeprom on a prop board. Just ruin several small sections of the eeprom.
Perhaps destroy the areas after your code is burned onto the chip.
Worth thinking about ? I wonder if this has been done already?
(every good idea I come up with seems to have been dreamed up already)
code once you burn it onto flash or eeprom. Even MCUs that have
the code protection feature can be broken by unscrupulous Asian
hackers that sell their skills on the web.
I was running some code to see how many writes it would take to
totally fry a small section of the flash memory on an AVR. It was
quite a few I can tell you. It got me to thinking that if you used a program
to destroy small sections of the flash and then coded around those
sections while also routinely testing them so your code only will run if they
are destroyed that you could perhaps apply a lot of cleverness and
come up with a protection scheme that would make it a nightmare
for someone to get a working copy of your hex file
This is relying on the idea that anyone willing to pay to crack your
protected flash/eeprom code might not be skilled enough to easily
decompile your asm code and take out all the memory checks. It
might not be worth the effort, and a 3rd party would probably charge
a great deal to do it for them.
It occurred to me that this could also protect the hex file inside the
eeprom on a prop board. Just ruin several small sections of the eeprom.
Perhaps destroy the areas after your code is burned onto the chip.
Worth thinking about ? I wonder if this has been done already?
(every good idea I come up with seems to have been dreamed up already)
Comments
The biggest issue I can see is how long it would take to "burn out" a section.
Say 4ms programming time for a page on flash, and 6ms erase - for a total of 10ms (approx. made-up numbers to make math easy)
Say it needs 1M program/erase cycles before it burns out.
1,000,000 cylces * 0.01sec = 10,000 sec = just under 3 hours per chip.
Doable, if you build a many-socket parallel destroyer.
But as you say - nothing stops removing the bad area checks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I think the plan of action would be to copyright your code.· I think you can do it on the web for $35 dollars:
http://www.copyright.gov/docs/fees.html
The second plan of action would be to include Easter Eggs.· Write a message backwards or sideways·in a program so that you can read it later to prove you wrote it.
A third plan of action would be to have a program to do a self-diagnostic with checksums.· If the program is altered or modified, you could simply tell it not to work or to phone home.
As far as protection goes, I think there are some microchip microprocessors that offer code protection.· I'm sure there are people who can find their ways around anything but that is what lawyers are for.
Making things hard to copy can also make things hard for the customer but they shouldn't be copying people's code.
Chuck
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2903
Doesn't really protect the software, but keeps it from running on another set-up unless you change the rom number in software.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm just 7*1027 atoms floating through time and space in close formation. -KF4IXM
Post Edited (kf4ixm) : 6/5/2010 6:17:03 PM GMT
copy your eeprom to another eeprom and get a working copy
that easily. Also just sending your ARM or AVR off to be surgically
altered and then read won't work. The data file won't work in
another chip with merely a copy operation. Make them work at it, maybe
make them work as hard as it would be if they just recoded the
functionality from scratch.... they are always free to do that anyway.
I had it in mind that if a copy was made it would check the flash/eeprom
for the damage and if it was not damaged the chip would run just a few
times without a hitch, then after a counter had been updated to a randomly
set number the whole thing just gets unreliable...maybe in a day, a week,
or a month
I have some 40pin universal zif sockets, I could fry several chips at once
with a homemade zapper.
-Phil
As I understand it, the fatigue does depend somewhat on the past history of zeroes written to the bit cells. When the cell is cleared of excess charge through erasure, it appears to be ones. To write a zero into the cell, charge is driven through the insulating oxide layer into a buried conductive gate where it's trapped until the next erasure happens. Fatigue occurs as repeated programming cycles cause a slow accumulation of trapped charges within the oxide layer that can not be cleared out with an erase cycle. If only ones are written to a location, it may never "wear out" and the worst case is when only zeroes are written into a location.
I don't know if the Propeller spin does anything like this? I've read that the Propeller assembly goes into memory "as is"?
Anyway be sure to read the EEPROM back to see if it was in fact stored.
You consistently post valuable info about any subject here on the forum.
How have you managed to learn it all! I'm always amazed.
It would be fun to work with you... of course I'd drive you
nuts asking endless questions
I read somewhere someone mentioned about DS2460. I checked & if it is coupled with DS28CN01 (1Kbit eeprom) & have the running apps on this eeprom, wouldn't the actual apps be protected? App loader will be on the primary eeprom (24LC512) & once authenticated with DS2460, will call the actual app & run it. Just in theory for now but I'm still reading the datasheet. Or, have someone done this already?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken
I have managed it with a Ramtron FM31L278 device in place of prop eeprom. In the 32k fram the prog is encripted. The encription key is stored in the counter registers. The prop read the counters to get the encription key that is not written in the program. If someone open the box (you can have any kind of sensor eg. temp, ir, door switch ...) the counters will advance for several counts thus changing the key: program unusable.
I have also to say that the RTC was mandatory for the application and so the FM31L278 was perfect
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search