Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Software protection on a flash of Motorola 68376 CPU

Status
Not open for further replies.

mr_ghz

Full Member level 5
Joined
Apr 1, 2002
Messages
289
Helped
7
Reputation
14
Reaction score
5
Trophy points
1,298
Activity points
3,551
I have to protect a MCU software running out of a FLASH on a motorola 68376 CPU. The protection should work like this: If anyone copies the content of the flash and moves it to another target, the software should not work. I have no additional EEPROM's or somethink like this.
Has the 68376 CPU a unique (readable) serial number)?
 

Hmm,

I think you are confused about protecting an mcu and a OS based software.I advice you to protect your software with another way.In my old project, i cut all programming and reading pins on mcu and covered them with epoxy based adhesive.Of course i applied code protect ;) Now i can not see any reproduction of my device.
Any further questions, don't hesitate toask it ;)

Analyzer.
 

Analyzer said:
i cut all programming and reading pins on mcu and covered them with epoxy based adhesive
At one microchip forum I have read method of burning inside chip connection between pin and silicon wafer. Ones made this with very low probability of burning whole chip. The current flow thru the pin and then thru the diode that protect device from over/under voltage.
 

Re: Software protection

mr_ghz said:
I have to protect a MCU software running out of a FLASH on a motorola 68376 CPU. The protection should work like this: If anyone copies the content of the flash and moves it to another target, the software should not work. I have no additional EEPROM's or somethink like this.
Has the 68376 CPU a unique (readable) serial number)?



2 idea's:
=====
1) By means of a secret key/input combination / programming tool
write a 16-bit magic number into the flash.
Your software will work only when the magic is present.

2) Repeat writing a flash/eeprom location until if becomes defective
(if possible). Your software will only work when writing the location fails.
If writing succeeds the cel is fine, it is clearly a copied system.

Don't forget to hide the check from reverse engineering.

HTH
 

Re: Software protection

Hi analyzer

We already have had this idea. But to do so, we have to open our mcu system, what is not very easy (time!). Reprogramming can be done external. So a SW only protection is the way we want to go.

Hi BiTMan

Your 1st idea won't work, if I copy the whole content of the flash, because I also copy the magic number. Or did I forget something? It would be a better way if any device has a unique silicon ID. As written we have a 68376CPU and a AM29BL802 flash.
The 2nd idea sounds nice. But I think I have to write very often...

Are there other ideas?
 

Hmm,
Ok maybe you can combine your main mcu with another locked small mcu? Secret key locked on small mcu.By the way, why dont you trust code protection? It is safe to lock firmware, eh?

Analyzer.
 

Re: Software protection

Hmmm, some idea. If you have free pin of CPU, then burn it (destroy internal connection with crystal in chip or protection diode). This pin will not work as input anymore. Connect it to VCC (or ground) and test it on program. Any new CPU will work correctly and this pin will receive 1 or 0 accordingly with connection, but your CPU will not receive correct input and you will detect it by program. Also you can connect this pseudo-input to some output of CPU and check no changing when output is changing.

Or take 2 inputs - one is burned and second is working correctly. Connect them together with some output pin and test changing on inputs when output is changing. This will make additional protect in case when "anyone" will try to free these pins.
 

Re: Software protection

Hi analyzer

I have to protect my software in the external FLASH :( But I'll try to program some bytes in internal ROM and the software in the external FLASH will check these bytes.

Hi klug

Can these 'destroyments' be done without danger for other parts of the CPU?

Bye
 

Re: Software protection

mr_ghz said:
I have to protect my software in the external FLASH :( But I'll try to program some bytes in internal ROM and the software in the external FLASH will check these bytes.
Forget about it, external FLASH can be readed and copied at every possible way. It can be modified and monitored to recover even encrypted program. If You can not burn any part of Your code inside CPU, don`t use any kind of protection. You will spend too much time on protecting.
 

I agree with elektryk; don't trust external mem.I advice you to build a encryption section which is connected to a pin.For example some passive components combination.Then erase part numbers of them or cover them with epoxy based adhesives.I advice you to attack copiers in mechanical forehead.You know, if they can read your firmware, they can copy easily ;)

Analyzer.
 

Re: Software protection

Can these 'destroyments' be done without danger for other parts of the CPU?

In my practic I have a lot of PIC, AVR and Scenix processors with breaked pin input/output and only few with core damage (as a rule, these few are with bad flash). I think, it is easy to find solution to break pin correctly. Maybe, to give negative voltage with limited current from charged capacitor.
 

Re: Software protection

I read an email article about this from some new group a while ago.

This was summary

Flash can be read/copied very easy so the place to look to protect a ROM image is outside the box.

First, make it hard to read, disassemble.
Store the code compressed, and only execute decompression from the boot ROM on start up and run from volatile memory only (DRAM,SDRAM,SRAM). Any code should have multiple CRC checks to stop tampering.

If any CRC check fails additional code within the ROM should introduce only minor errors and at random. An example is a LED or LCD display. A good random error would be to flash the display all 88888888 for a few seconds then resume normal function. Hard to find, harder to patch.

Methods of locking ROM to box (e-marraige!)

First most devices might have a unique ID somewhere within some registers on some device that can be read (version, man, unique ID)

This ID should be read at first startup (at factory) and then stored encrypted within the flash. On each startup afterwards the ID should be compared. If the do not match then execute random minor errors.

Does not seem like much, but as a version of raw, virgin code will never leave the factory, every product will have its own unique signed version of code which will not run on another box.

So if no unique ID is available you have to give it one. if you have a spare PIO on the micro, either fit a device with a unique serial number like those available from dallas (single wire)

In the code once the system is running have the code check for the presence of this serial number at random. do not use fixed point checks.

No device = random error or run code to reprogram part of the flash, as you are running from volatile memory, this will not have an immediate effect, but the box will fail on next power up or reset (benifet of running from NVM).

If the check fails then it should execute a random failure or code coruption, not a fixed point. or it should say execute random reprogramming of registers of connected I2C devices etc.

The idea is not to stop copying, it is to cause failure of the code, or failure or the application to run or perform properly at random and in a subtle way so it is not easy to debug or disassemble.

If you use a serial number system you could also store valid serial numbers database (encrypted) within the code so that it executes only on presence of a valid number, as well as marrying the flash to the hardware. The valid number should be COPIED from the serial device into the flash at first run. If at any time the numbers do not match then you should execute the random errors code.

Just some ideas to add to the thread.

:R
 

Re: Software protection

Forgot

Main idea is not to stop copying but make it look like it can be copied successfully.

If someone copies it, chances are they will have spent a lot of time and money to copy a product that may randomly fail or at least cuase their reputation so much harm as to make it not woth while for them to do.

The time spent to disassemble and patch a compressed and CRC checked ROM as well as a marraige check on devices is a lot of work, unless your product is really expensive and makes a big and profitable target
 

Re: Software protection

mr_ghz said:
Hi BiTMan

Your 1st idea won't work, if I copy the whole content of the flash, because I also copy the magic number. Or did I forget something? It would be a better way if any device has a unique silicon ID. As written we have a 68376CPU and a AM29BL802 flash.
The 2nd idea sounds nice. But I think I have to write very often...

Are there other ideas?

I thought about cpu internal flash and a protection bit.
But, right, your flash is external.

The time to kill an eeprom cel bit is not necessary long.
Assuming 10ms write cycles ...
10.000 x 150%(assumption) take approx. 2.5 min.
100.000 x 150%(assumption) take approx. 25 min.
The kill process could run in background
during production functional tests or calibration etc.
Writing alternating bits (0-1-0-1) or a block of cels
might cause early failure to gain time.

I my opinion, blowing an I/O-pin or IO-diode is highly irreproducable
and may cause long term chip damage (risking failure in the field).
 

Re: Software protection

8) .... There is an other way to protect the external Flash :

U can use a special adress decoding for ur flash... so the adress lines
are not in the right order... (A0, A1, A2... could become A1, A2, A0...
for exemple) so if someone try to copy ur flash and put it in a diferent
target the contents of the flash will become un-readable...

(to make the decoder use a programable device with a copy protection
capability... so nobody can reproduce ur adress decoding... therefore
can not use ur Flash code).

What do u think of that ?? :wink:
 

Re: Software protection

Hi RNR

This is a commonly used method for a simple protection. In my case it's a little bit difficult, because I have to use a given hardware. So I cannot make any modifications...
But anyway: Thanks for all these replies!

Bye
 

Re: Software protection

hi,
Dallas have a serial eprom chip, i think its ds2505. it has a unique serial no: on it, for protecting your firmware u can easily attach this serial eprom with your design and the eprom is one time programmable, by simply adding this functionality to your design u could getaway from the piracy world

indy
 

Hi

I have heard that some RAMs when powered ON
could store unique information dependent on production parameters . If it is right , you can check at your startup program before memory initialization goes on content of RAM . If it is really unique , you can use its value as encription and decription key . So, before firmware is loaded , you must read the RAM content and make up unique key . Then used this key you can encript your firmware . and load into MCU . When firmware begins to run , startup program is executed and reads the RAM and built unique decription key . Then using this key the stored encripted executable is decripted and loaded into RAM area to execute .
I can not prove this concept - as i did not make any tests . But it will be interresting to have your test results , ig you will be willing to check that .

Also , there could be case when the RAM is not for 100 has reproducable power on state , but you can check and test towards less than 100 percent matching let say threshold could be set as 80 or 90 percent . But test must be done with quite big number of RAMs to verify said above .
 

Re: Software protection

Hi All,

I would suggest to use a small MCU to act as a key to unlock the actual code from the flash to the main processor. You may use PIC12F629 from Microchip. It is a small 8 pin part and looks and cost like an eeprom and it is a MCU. You may want to put your crypto algorithm into this chip and protect it. YOu main processor can read this chip then decrypt the data in the Flash memory for execution. Please advice if you may have other ideas. Thank you.
 

Re: Software protection

Hi artem

your idea sounds very interesting. Do you have any information on this topic?

Bye
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top