Code Protection Again

Ok, ok, I might be beating a dead horse here. Sorry if my post seems demanding and to the point, but up to this point searching on the forum I can't find a straight answer.

Let's say I have a Pro Mini 328, and I've written a sketch that I don't want anyone with run of the mill programming skills to copy my code to DUPLICATE the product by copying the machine code and dumping it back onto another Pro Mini.

Let's get pass the part where: 1. is my product valuable enough to go through this,

  1. I don't care if they want to reflash the chip,

  2. I don't care if they use a microscope, or hundreds of dollars worth of equipment, or weeks on end to copy the code.

  3. I just want it "reasonably" difficult to do.

I want the ability to upload new code if necessary (bug fixes, etc)

I want to know:

  1. Can I maintain the standard Arduino bootloader and prevent copying of the code?

  2. If yes to above, can I use the Sparkfun Pocket AVR Programmer https://www.sparkfun.com/products/9825 in conjunction with AVRDude? If not, what do I use?

  3. If yes to above, can I have my sketch uploaded via the Arduino IDE and then proceed to protect the code?

  4. If yes, how do I proceed? Please do not refer me to the datasheet. Kindly just instruct me step by step; i.e., connect the device to the programmer pins; power up; open AVRDude or whichever program; type this command...

Thanks in advance.

post you code and we will tell you how to do it :)

You basically need to change the lock bits to prevent the code from being read. I'm not certain if the bootloader can be used after that, possibly not. To change the lock bits back the chip needs to be erased. I seem to recall the bootloader only does a partial erase.

I think a useful method would be to upload the sketch in the usual way, and test it. Rinse and repeat until you are happy with it. Then as a final step use an external programmer to set appropriate lock bits to zero (quite possibly, all of them).

My hex uploader can change the lock bits: http://www.gammon.com.au/uploader

It can also erase the chip. I must admit I haven't tested setting the lock bits to zero, because then I have to fool around erasing the chip, but I could do that. Give me a few minutes to try it ...

Judging by the datasheet:

Further programming of the Flash and EEPROM is disabled in Parallel and Serial Programming mode. The Fuse bits are locked in both Serial and Parallel Programming mode. (1)

...

Further programming and verification of the Flash and EEPROM is disabled in Parallel and Serial Programming mode. The Boot Lock bits and Fuse bits are locked in both Serial and Parallel Programming mode. (1)

This seems to me to be the only mode(s) that prohibits reading back the code. However they also stop you using ICSP programming. I don't want to test that because it involves pulling chips out of boards and the legs eventually break.

If I am right (and I will let others correct me if they want) once you set the LB1 and LB2 to zero, you need a high-voltage programmer to erase the chip. And to use that involves pulling the chip out of your board, unless you have carefully designed to allow for it in circuit (for example, by allowing /RESET to be isolated via a jumper).

This being the case, I would thoroughly test using the normal bootloader, before locking anything. Then before deploying to the field, you could set the lock bits appropriately, knowing it will be difficult or impossible to fix it afterwards. At the very least it would need to be returned and you would have to pull the chip, or set up a programming jig for the high-voltage programming method.

I suppose if you used a zero-insertion-force socket you could make it fairly easy to get the chip out for reprogramming.

Copy the code or copy the compiled bits/bytes?

  1. Can I maintain the standard Arduino bootloader and prevent copying of the code?

No. Optiboot supports reading from Flash.

If you modify the bootloader and modify the upload process to skip verification then yes.

You can change the lock bits so that the bootloader can't read from flash, as I read it.

That's the way I read it. BLB0 Mode = 4 --> write OK, read not. Sorry about the mistake. The upload process would still have to exclude verification.

It would be interesting to build a "secure" version of Optiboot. Something that requires a password before accepting an upload.

Or, drop support for reading Flash in favour of writing to EEPROM.

mistergreen: Copy the code or copy the compiled bits/bytes?

Copy the compiled bit/bytes.

And thanks to all your feedback so far. Reading and evaluating comments.

The great advantage of OpenSource code is that you don't have to worry about any of this stuff.

...R

[quote author=Nick Gammon link=msg=2282246 date=1434664714]

This seems to me to be the only mode(s) that prohibits reading back the code. However they also stop you using ICSP programming. I don't want to test that because it involves pulling chips out of boards and the legs eventually break.

If I am right (and I will let others correct me if they want) once you set the LB1 and LB2 to zero, you need a high-voltage programmer to erase the chip. And to use that involves pulling the chip out of your board, unless you have carefully designed to allow for it in circuit (for example, by allowing /RESET to be isolated via a jumper).

[/quote]

So, let me get this straight, after uploading my sketch I set LB1 and LB2 to zeroes and I would achieve relative safe protection of my code. However, I would need the high voltage programmer in order unprogram the bits in order to update my code.

Hmmmm, more than I bargained for, especially the latter part with the high voltage programmer. If it wasn't a requirement for updates to be applied, I probably would proceed with it.

Actually, this the most succinct answer I have gotten and I thank you all for your replies. With other threads, responses range from discouraging the initiating member by discounting the value of the member's project and by directing the member to the datasheet, which many of us cannot quite understand.

Just to say, for other newbies, that the high voltage programmer is a parallel programmer which initiates the parallel programing mode by placing a relatively high voltage (12v) applied to the reset pin in a particular manner. It took me a little while to figure that part out. ;)

Where does it say the lockbits disable ISP programming?

I thought ISP programming was only disabled by blowing the SPIEN bit of the high fuse (or RSTDSBL, ofc)

Reply #3.

Further programming of the Flash and EEPROM is disabled in Parallel and Serial Programming mode. The Fuse bits are locked in both Serial and Parallel Programming mode. (1)

ISP programming is “Serial Programming”.

You could blow the SPIEN bit, but without the lock bits, someone could put the chip in a high-voltage programmer and read the contents.

That statement in the datasheet does not specifically say that you cannot read the flash using high-voltage programming if the lock bits are zeroed. I better test that.

[quote author=Nick Gammon link=msg=2283615 date=1434752356] That statement in the datasheet does not specifically say that you cannot read the flash using high-voltage programming if the lock bits are zeroed. I better test that. [/quote]

Actually, it does. The high-voltage programming is "Parallel" programming.

remember the old days of dongles that had to be inserted into the printer ports. Maybe a more modern alternative would be something with a fixed address like a mac number. Then the program could compare itself to the mac number during setup. Each program would have to be customized based on the stored number.

I am certainly not trying to be argumentative with anyone, but out of curiosity I messed with the lock bits on a spare tiny85 I have laying around (because I really was not concerned if I bricked it). By setting 0x3C for the LB I was unable to upload to the chip further as long as I disabled flash erase (-D in avrdude); however, as long as I did not disable flash erase I was able to upload to the chip. I should note I am using a USBasp, not a high voltage programmer. From my testing it would appear as long as flash erase is specified you can readily upload to the chip regardless of state of lock bits, no high voltage programmer required.

avrdude.exe: 1 bytes of lock written avrdude.exe: verifying lock memory against 0x3C: avrdude.exe: load data lock data from input file 0x3C: avrdude.exe: input file 0x3C contains 1 bytes avrdude.exe: reading on-chip lock data:

Reading | avr_read(): error reading address 0x0000 read operation not supported for memory "lock" avrdude.exe: failed to read all of lock memory, rc=-2

It does appear that you can not read the state of the lock bits from within avrdude; however, these were my results. My test was simply... Upload a hex file without setting the lock bits with flash erase enabled (success) Upload again with flash erase disabled (success) Set lock bits to lock (I use a GUI for avrdude, there is a button to just write fuses and/or lock) Upload with flash erase enabled (success) Upload with flash erase disabled (fail)

avrdude.exe: verifying ... avrdude.exe: verification error, first mismatch at byte 0x0000 0xff != 0x19 avrdude.exe: verification error; content mismatch

Upload with flash erase enabled and set lock bits during upload (success) Upload with flash erase disabled setting lock bits during upload (fail) Upload with flash erase enabled setting lock bits to unlocked (success) Set lock bits to lock Upload sketch (that the above mentioned hex was generated from) from Arduino IDE.."avrdude: erasing chip".. (success)

It looks like the upload is taking place (red light goes on, progress shows) but fails verification if the lock bits are set.

I was unable to find my spare 328p to see if it functions the same, I did however repeat the tests on another tiny85 with the same results. In conclusion it appear "flash erase" will still allow upload, that being said I can not 100% guarantee that my results are accurate due to the inability to read the state of the lock bits.

Also.. Trying to execute a read while lock bits are set gives me an output file containing ":00000001FF" only. Prior to setting lock bits to locked I get the full hex. If I set the lock bits unlocked I still get ":00000001FF" any time after it has been locked until I do a chip erase and re-upload, it would appear that a chip erase cycle has to be preformed to execute a read after lock bits have been set.

Interesting. It seems logical to allow a chip erase by any method, although it seems to disagree slightly with the datasheet. I suppose it depends what they mean by the words "programming and verification".

I too read over the datasheet trying to find a definitive answer as to whether high voltage programmer would be required or not. Honestly I felt it was not clear in the datasheet, and since I had several spare 85s I figured I would try it and at worst would be out a couple of dollars if I bricked the chip.

Again I do not claim that my tests were totally accurate, everything seemed to work with a chip erase cycle and not work without; however I was unable to 100% know that the lock bits were properly set.

EDIT: On a side not I did manage to murder one of the 85s, when I went to put the original one back in the breadboard I put it one space off (5V to A1, ground to 5V pin..yes I know having a ground right next to 5v seems silly, it was there for a filter cap on a nasty noisy circuit), Analog input 1 no longer functions.

BH72: Also.. Trying to execute a read while lock bits are set gives me an output file containing ":00000001FF" only. Prior to setting lock bits to locked I get the full hex. If I set the lock bits unlocked I still get ":00000001FF" any time after it has been locked until I do a chip erase and re-upload, it would appear that a chip erase cycle has to be preformed to execute a read after lock bits have been set.

So, what you are saying is if I have the standard Arduino bootloader and I upload my sketch using the Arduino IDE, I proceed to setting the lock bits to locked using AVRDUDE, I will not be able to copy the contents of the flash memory. In order to upload a new sketch, I would have to perform a chip erase cycle.