Bob, Thanks for the info. The main chips I use are PIC18LF6720, PIC18LF2520 and PIC18LF1320. I do not have a programmer suitable for programming any of these SMD IC's before being placed into the target application. I do have a version of the Hi-Tech C Bootloader that does accept encrypted files (I encrypt the files with a VB program I wrote and use my updater software to enable users to update code). The problem was that if they read the entire chip with the bootloader then they will get a working copy of the code. The bootloader resides in memory from 0000 to 02ff and the application code is offset to 0x300. I suppose that once the bootloader is installed then I can set the code protect bits and rely on internal programming via the bootloader to get the application program on board. I am a little confused regarding which combination of bits to set in config to do this. Do I enable the Code Protect BOOT ? If so, will this still allow the bootloader to write to memory above 0x300 ? This morning I also added another mechanism (mainly for the PIC18LF1320 that I have not yet managed to get the bootloader to work with). I simply program the ID locations in Config area and the application checks that the correct ID code is their or it will not run the application. What I did was create an Array in code that was used to decode the 8-digit ID entered into the config ID area into a string that was compared against what represents a valid ID. The thing I am not sure of though is that if they read the micro via the ICSP, does MPLAB also read the ID from the config area ? I see there is a way to prevent writing to this area but cannot see that you can prevent reading from it. I am sure when someone really wants to copy the code they will find means and ways around security measures. My main objective is to make it a little more difficult than simply reading a chip and writing it to an imitation of my device or if the effort to use my code on other hardware is extensive enough then there is not mush more benefit in copying my code as them rewriting their own code. Most of my applications are wireless communications devices and it has taken quite a bit of effort to get reliable over-air communications running. Some of the applications are not much more than a micro and a small low powered RF module. The users generally have very little radio communication experience but some companies are so interested in their bottom line that they see the hardware does not appear to be very intricate and can easily copy the PCB. If they can also simply read my code and program it into copies then they have no need to purchase my devices. I suppose this is the type of thing that musicians go through with copying of their IP. Thanks Regards David Bob Axtell wrote: > David wrote: > >> Many of my applications run solely from 3V supply. Some circuits are >> very simple and most of the work has gone into the code development. >> >> I would like to provide a level of protection to each application to at >> least prevent someone directly reading the code via ICSP and then >> programming their own copy of my unit. >> >> First I was considering placing a code in the serial number part of each >> micro controller and have my code read and validate the correct code >> before running the application. (Have not tried it yet). >> >> For the 5V supply projects I could easily just set all the code >> protection bits and if I needed to reprogram the device I just did a >> bulk erase and reprogrammed it. >> The problem is that the bulk erase requires 4.5V. >> >> Can I partially protect the code that would prevent all the code being >> read but still enable me to reprogram the chip if I needed to. >> >> >> > You didn't say which chip. > > The answer is to go ahead and install raw firmware (with security bit > set) BEFORE the chip is > installed, NOT via ICSP. Then install new firmware after this through > the serial port, using a > "bootloader" program. You CAN replace most of the internal firmware > WITHOUT allowing > someone to see it at all, but this is not available on all devices. You > can self-program (erase and > install new firmware) at 3V all day long on some devices, and an > external programmer cannot read > the data at all. No real need for an ICSP connection at all. > > To further make things harder for a potential hacker, you can encrypt > the data being loaded from > the bootloader; to do this, you might need to write your own bootloader > rather than use someone's > published design (bootloaders are trivial to write, don't worry). > Usually, this means that the bits are > sent out of order, or a table of values is added to each word, giving > each word 65K chances to be > something else entirely. You can also install new firmware into the > device in a random order, not from > start to end; that makes it inordinately hard to hack when intercepting > the bootloader string. > > The scheme of installing a secret code and reading the firmware to see > if it matches is a good idea, > but you must be very careful to flash then verify each word as the > firmware is changed; sometimes > a word gets corrupted then everything grinds to a halt from which > recovery is not possible. > > Having said all this, you must know that Microchip's security scheme is > not foolproof, and there are > people that, for a fee, can extract the firmware. But it is destructive > and usually requires several devices > to be certain of recovery. In my opinion, unless you are hacking a > military device, it is not worth the > effort, so most designs are quite secure. > > --Bob > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist