David wrote: > 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. > Emulation Technology makes these adaptors. You can then buy a standard DIP programmer and they can be programmed in their SMD form before being populated. Cost is about $100 USD. I am not familiar with those devices, but I believe everything I said below will work for these devices, too. --Bob > 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