Reply by Tom Lucas April 3, 20062006-04-03
"Keith Wootten" <keith@nononono.cod.uk> wrote in message 
news:d1frD+ACabLEFwC4@ntlworld.com...
> > We have customers using PICs who sometimes need to re-program them with > updated firmware. It's inconvenient to have to ship the equipment back to > a service centre, and most customers are quite capable of doing it > themselves. >
Perhaps it would be easier to try a legal solution rather than a technical one. Supply the code under a license that forbids the disassembly of it and the use of any knowledge gleaned from doing so.
Reply by Spehro Pefhany April 1, 20062006-04-01
On Sat, 01 Apr 2006 16:15:15 +0100, the renowned Chris Jones
<lugnut808@nospam.yahoo.com> wrote:

>Keith Wootten wrote: > >> In message <442e6564.1170281@news.provide.net>, ---@---.?.invalid writes >>>On Fri, 31 Mar 2006 23:04:51 GMT, Keith Wootten <keith@nononono.cod.uk> >>>wrote: >>> >>>>...Obviously, a determined person could capture the ICSP data as it's >>>>loaded to the >>>>PIC, but we think the risk is small and is one we'd be prepared to take.. >>> >>>Then you should be willing to take the much smaller risk that they >>>would be able >>>to make any sense of the hex file. >> >> Disassembly is trivial with freeware tools and interpreting the result >> may even be fun. There are parts of the code which would give away the >> secrets of a proprietary protocol. Capturing the ICSP data requires, >> comparatively, a lot of effort and equipment. > >Not really, an old 80386 PC with a printer port could probably do it, or it >would be trivial with a 20 year old logic analyser or a $50 FPGA eval >board. > >Chris
Right, but you have to have some knowledge to make that work. You can download MPLAB for free, load the hex file, enter in the part number, and be off simulating in no time. Nothing's perfect, the PIC protection can be bypassed too, for a price, so it's all a trade-off. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Reply by Luhan April 1, 20062006-04-01
Here is a real simple methode for PIC code.  You generate a 'keysteam'
of bytes which you XOR for both the encode and decode process.  Look
for "Better, Faster, random numbers" on this page...

http://members.cox.net/berniekm/tricks.html

Luhan

Reply by Chris Jones April 1, 20062006-04-01
Keith Wootten wrote:

> In message <442e6564.1170281@news.provide.net>, ---@---.?.invalid writes >>On Fri, 31 Mar 2006 23:04:51 GMT, Keith Wootten <keith@nononono.cod.uk> >>wrote: >> >>>...Obviously, a determined person could capture the ICSP data as it's >>>loaded to the >>>PIC, but we think the risk is small and is one we'd be prepared to take.. >> >>Then you should be willing to take the much smaller risk that they >>would be able >>to make any sense of the hex file. > > Disassembly is trivial with freeware tools and interpreting the result > may even be fun. There are parts of the code which would give away the > secrets of a proprietary protocol. Capturing the ICSP data requires, > comparatively, a lot of effort and equipment.
Not really, an old 80386 PC with a printer port could probably do it, or it would be trivial with a 20 year old logic analyser or a $50 FPGA eval board. Chris
Reply by Keith Wootten April 1, 20062006-04-01
In message <442e6564.1170281@news.provide.net>, ---@---.?.invalid writes
>On Fri, 31 Mar 2006 23:04:51 GMT, Keith Wootten <keith@nononono.cod.uk> wrote: > >>...Obviously, a determined person could capture the ICSP data as it's >>loaded to the >>PIC, but we think the risk is small and is one we'd be prepared to take.. > >Then you should be willing to take the much smaller risk that they >would be able >to make any sense of the hex file.
Disassembly is trivial with freeware tools and interpreting the result may even be fun. There are parts of the code which would give away the secrets of a proprietary protocol. Capturing the ICSP data requires, comparatively, a lot of effort and equipment. Making the code hard to interpret with all the usual tricks isn't an option as it's pre-existing and tight. If we can't find something off the shelf, then we may try to commission a USB PIC programmer maker to do what should be a fairly easy enhancement. Cheers -- Keith Wootten
Reply by Robert Scott April 1, 20062006-04-01
On Fri, 31 Mar 2006 23:04:51 GMT, Keith Wootten <keith@nononono.cod.uk> wrote:

>...Obviously, a determined person could capture the ICSP data as it's loaded to the >PIC, but we think the risk is small and is one we'd be prepared to take..
Then you should be willing to take the much smaller risk that they would be able to make any sense of the hex file. Robert Scott Ypsilanti, Michigan
Reply by Ulf Samuelsson April 1, 20062006-04-01
> Personally I think something like DES is overkill for a bootloader. A > common "good enough", weak encryption method is to simply XOR the > plaintext with the secret key. Something like: > > #define KEY_LEN 22 > static char secret[] = "THiS is tHE sECrEt KeY"; > > void encrypt_decrypt (char *data,int len) > { > for (i=len; i>0; i--) > { > data[i] = data[i] ^ secret[i%KEY_LEN ]; > } > } > > takes very,very little program memory and can be easily included in a > bootloader.
If you really want to break in, it is not so secure. If it is compiled code, you can * Make sure you get * search for combinations normally generated by a compiler The larger the program is, the higher is the risk that you get a repeated string Assume you have the following code in several places: pop r<n> pop r<n> ret and several happen to be located aligned with the "secret" key. Then they happen to be at location 44 and 176. After factoring 44 = 2 * 2 * 11 176 = 2 * 2 * 2 * 11 you can probably soon find out the length of the key. Then you know that the start of the code is (often) the exception vectors. Search for valid keys generating subroutine call instructions. Methods like this compbined with cheap CPU power limits the number of keys very quickly. Your suggestion is only safe if noone tries or if the value of the code is small enough that it costs more to develop the code than to crack it. You would not, with any success, protect a settop box with your suggestion. DES/AES cost very little code in the bootloader compared to its value. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Reply by Keith Wootten April 1, 20062006-04-01
In message <1143848642.072446.248740@i40g2000cwc.googlegroups.com>, 
Luhan <luhanis@yahoo.com> writes
>Keith Wootten wrote: > >> I'd rather not - it can take a long time for a chip to get to a far >> flung place, and we don't really want customers soldering surface mount >> chips on site, at least not often. Sockets are out for environmental >> reasons. > >Ok, then how about a 'bootloader' program in a memory protected PIC? >Some PICs can write to their own program space. Put a decryption >algorythm in the bootloader and send it serial data from a PC com port. > You ship your customer the encrypted program. > >Luhan >
Another good idea, but this is pre-existing kit, none of it uses self-programming PICs. It tends to be mostly old 16F84 chips and similar. Cheers -- Keith Wootten
Reply by sleb...@yahoo.com April 1, 20062006-04-01
Luhan wrote:
> Keith Wootten wrote: > > > I'd rather not - it can take a long time for a chip to get to a far > > flung place, and we don't really want customers soldering surface mount > > chips on site, at least not often. Sockets are out for environmental > > reasons. > > Ok, then how about a 'bootloader' program in a memory protected PIC? > Some PICs can write to their own program space. Put a decryption > algorythm in the bootloader and send it serial data from a PC com port. > You ship your customer the encrypted program.
This is a good idea since even snooping the serial port while downloading will not give away the raw program code. Blowfish is quite simple to implement and is easily embeddable. You can get PIC implementation of DES and SKIPJACK at: http://www.brouhaha.com/%7Eeric/crypto/ Personally I think something like DES is overkill for a bootloader. A common "good enough", weak encryption method is to simply XOR the plaintext with the secret key. Something like: #define KEY_LEN 22 static char secret[] = "THiS is tHE sECrEt KeY"; void encrypt_decrypt (char *data,int len) { for (i=len; i>0; i--) { data[i] = data[i] ^ secret[i%KEY_LEN]; } } takes very,very little program memory and can be easily included in a bootloader.
Reply by Ulf Samuelsson March 31, 20062006-03-31
Keith Wootten wrote:
> Hi > > We have customers using PICs who sometimes need to re-program them > with updated firmware. It's inconvenient to have to ship the > equipment back to a service centre, and most customers are quite > capable of doing it themselves. > > The problem is that the PIC hex or bin file is easily disassembled, > and this may give away some proprietary secrets. If we could supply > our customers with a USB programmer and PC software which would allow > them to program a PIC from encrypted files we'd be a lot happier. > Obviously, a determined person could capture the ICSP data as it's > loaded to the PIC, but we think the risk is small and is one we'd be > prepared to take. > > Does anyone make a USB PIC ICSP programmer capable of using encrypted
files? You can get an AES bootloader for the AVR :-) Download the encrypted application and let the CPU decrypt and program, based on the key hidden in internal BootROM.
> > Thanks
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB