Device Code Security

Hello All,

It just occoured to me: How do we protect our IP (that’s intelectual property) on the end products that we create?

I’ve seen in the past that microcontroller manufactures have encrypted rom and other “IP saftey” features built in to prevent ppl from obtaining the program that is on the microcontroller. Additionaly how do we prevent somone from “overwriting” my program that is already on the Usbzi?

Any Ideas?

Look through he USBizi and EMX manual. There are options to protect the integrity of the device.

I think you can use the bootloader L command in 1K Send mode. This is to load you production application. You can then use the P command to apply read protection.

Em… I was kinda look for something a little more permanant. LIke being able to permantly disable the abilty update the device’s firmware; the user application AND the .netMF as well (can’t be so safe)

I ask because I want to have my own “boot loader” of sorts that will read the application of out of storage (encrypted of couse) and dynamically load it into memory. This of couse would also allow me to do updates, in the field, in my own weird way :slight_smile:

I have been told that In Field Update is in development. Why not just use that?

Are you looking for the ability to load an application PE from the SD or USB ? If so please search and go through the Netby forum for ideas.

Load from the SD; yea I know how to do that. But I want to ensure that my boot loader with the embedded private key (for the data) isn’t comprimized.

I know GHI doesn’t offer an gaurentee in this regard so I’m looking at all my options.

JTAG and low level access to USBizi is permanently disabled, to protect our IP and yours. Now, the only way to read your application is through the read-application-command in loader in which you can disable. See USBizi manual for more details

Chris, he is not going to use in-field update and this feature is not going to be available on USBizi anyways. The update will be done by loading assemblies dynamically like we talked about fro the Chumby-like project.

Yeh I was going to say that this actually seemed more like something that the GHI forums may have discussed, since it is less likely to be needed in the Fez/USBizi “enthusiast” market.

So it sounds like the code is reasonably secure (no JTAG) so I feel a bit better.

So with the security “On”, someone won’t be able to overwrite the User Application, nor will they be able to “update” the .net framework on the device.


We do not protect writing, only reading. The concern is you IP


My concern is not only my IP but also the security of the physical device. What I don’t want happening is for someone to overwrite the application with something else, as well as not being able to get the the application that is on it. This includes being able to overwrite any part of the .netmf or GHI’s code.

How would someone overwrite your code accidentally? It is not possible and if you want to make more difficult I have an option for you.

  1. switch debugging to COM1 (using a pin) on your board
  2. Do not make UART available on your board

Then how would someone now try to write it? They would have to hack in the whole board, assuming they know USBizi and your board design…and if they did, how would this be a harm to your product? They obviously lost the warranty on it after hacking the design.

And if someone just wanted a board to play with USBizi, isn’t buying FEZ cheaper than buying your board. Another reason on why not to worry about this possibility.

And you can add some more security in addition to Gus’s recommendations :smiley:

Put your device in a mold and fill in some liquid synthetic resin.

So with the other security mechanism it’s impossible to crack your IP

But normally the built-in security features are enough. As Gus said , when somebody overwrite your firmware it is easier to buy a FEZ directly at GHI.

Hehe… Ok I’ll have to give full disclosure to explain properly.

I have a number of security devices being considered for the Fez. This includes vehicle tracking and remote disabling, UAVs and building security systems. Since the Fez would be connected to the Vehicle’s on board computer, I don’t want someone with physical access to the vehicle to overwrite the good security program (mine) with another program that will cause the vehicle to “some random undesired action whilst in operation”. This applies for the other fields.

The resin Idea sounds good, I’ll research that.

How would they program it if you do what I suggested before?
Also, if they can program and understand your circuitry then they can just buy USBizi 144 chip and replace the chip you have on-board with new blank chip then do whatever you like.

Note that this has nothing to do with USBizi. Any processor you use can be replace d with a blank one to be programmed to the hacker’s desires :o

True, they could just replace the board, and true they won’t be able to write to the device. So that satisfies my request. It’s reasonably safe.