Encrypted bootloader.

[HenrikOlsson]

Hi eveyone,
I'm looking for pointers towards an encrypted serial (not USB) bootloader that will work with PBP. I've found the one from Brush Electronics (http://www.brushelectronics.com/) which seems to be what I'm looking for at a reasonable price ($150) but it says it's meant to be used with the CCS PCH compiler.

Has anyone seen anything simmilar for use with PBP?

Thanks!
/Henrik.

[ScaleRobotics]

First off, I don't have any experience with this one. But it looks like it encodes/decodes with an XTEA algorithm. Key is a 16 byte code. Here is some info on it from their readme file. And best of all, it is free.

I would think that hex is hex, and whether it is PBP, CCS, etc, the hex would not look any different to a bootloader.

http://www.diolan.com/pic/bootloader_dwn.html



XTEA Encoder/Decoder
====================

XTEA Algorithm backgrounds
---------------------------
The XTEA encoder/decoder input byte stream is separated into 8 byte chunks
[ b0 b1 b2 b3 b4 b5 b6 b7 ], [ b8 b9 ........... ], ...
Chunk is treated as two 32 bit little endian integers x1 and x2.
For chunk0:
x1 = (b3<<24) + (b2<<16) + (b1<<8) + b0
x2 = (b4<<24) + (b5<<16) + (b6<<8) + b7

Encoding/Decoding is performed for every single chunk.

KEY is a 16 bytes string treated as key[4], where key[i] is
32 bit little endian integer
KEY k0 k1 k2 k3 k4 ..... k15
key[0] = (k3<<24) + (k2<<16) + (k1<<8) + k0

DELTA is 32 bit integer constant
DELTA = 0x9E3779B9

Chunk Encoding:
sum=0;
for( i=0; i<XTEA_ITER; i++ )
{
x1 += (((x2<<4) ^ (x2>>5)) + x2) ^ (sum + key[sum&0x03]);
sum+= DELTA;
x2 += (((x1<<4) ^ (x1>>5)) + x1) ^ (sum + $KEY[(sum>>11)&0x03]);
}

Chunk Decoding:
sum = DELTA* XTEA_ITER;
for( i=0; i<XTEA_ITER; i++ )
{
x2 -= (((x1<<4) ^ (x1>>5)) + x1) ^ (sum + key[(sum>>11)&0x03]);
sum-= DELTA;
x1 -= (((x2<<4) ^ (x2>>5)) + x2) ^ (sum + key[sum&0x03]);
}


XTEA Encoder/Decoder configuration
----------------------------------
You can change following parameters to configure XTEA encoder/decoder

- XTEA encoder/decoder KEY

File : xtea.asm
Identifier : XTEA_KEY

- XTEA encoder/decoder number of iterations

File : xtea.asm
Identifier : XTEA_ITERATIONS and DELTA_ITER

The number of iterations defines level of security. The 16 iterations are
quite enough for bootloader. Default value is 64 iterations.
If you change number of iterations do not forget to change DELTA_ITER,
that is precalculated value of DELTA*XTEA_ITERATIONS used by decoder

Example:
XTEA_ITERATIONS equ 0x40 ; Number of iterations on x1,x2
DELTA_ITER db 0x40,0x6e,0xde,0x8d ; Delta*XTEA_ITERATIONS


Code Protection
===============
Following Configuration Registers settings are recomended to secure
FW from anauthorised access and protect bootloader section from undesired
changes by external or internall agent. This setting will allow proper
operation of bootloader but will not let any external access to FW.

Config Register Value Description
0x300006.bit7 1
Background Debug Disabled
0x300008 0x08
Code Protect 0x0800-0x1FFF Enabled
Code Protect 0x2000-0x3FFF Enabled
Code Protect 0x4000-0x5FFF Enabled
0x300009 0x80
Data EE Read Protect Disabled
Code Protect Boot Enabled
0x30000A 0x0F
Table Write Protect 0x0800-0x1FFF Disabled
Table Write Protect 0x2000-0x3FFF Disabled
Table Write Protect 0x4000-0x5FFF Disabled
0x30000B 0x80
Data EE Write Protect Disabled
Table Write Protect Boot Enabled
Config Write Protect Enabled
0x30000C 0x0F
Table Read Protect 0x0800-0x1FFF Disabled
Table Read Protect 0x2000-0x3FFF Disabled
Table Read Protect 0x4000-0x5FFF Disabled
0x30000D 0x00
Table Read Protect Boot Enabled

[HenrikOlsson]

Hi,
Yes, I've seen that one too. The "problem" is it's USB and I don't have a USB enabled chip in this project. Usin XTEA however seems like the common way to handle the encryption as the one from Brush Electronics uses that as well. I guess I COULD have a go at writing one but I really don't need another project so I went looking for an of the shelf product at a reasonable price.


I would think that hex is hex, and whether it is PBP, CCS, etc, the hex would not look any different to a bootloader.
Agreed, problem is that the actual boorloader code on the PIC needs to be customised, ie. oscillator frequency, baudrate, CONFIGs and the "key" etc which means that I must have the compiler for which the bootloader source was written - which is why I'd like to find one for PBP.

Still looking....

/Henrik.

[aberco]

Looking into encrypted USB bootloaders too, it seems that diolan's is the only one available (free or not, though diolan has the big advantage of being free!). Though, it uses the extended PIC18 instruction set which is not compatible with PBP compiled code... There's probably no chance to make it work as is.

Microchip's HID bootloader does work with the standard instruction set, but does not support encryption.

Any idea if there's such thing available?

[ScaleRobotics]

though diolan has the big advantage of being free!). Though, it uses the extended PIC18 instruction set which is not compatible with PBP compiled code... There's probably no chance to make it work as is.

You could do something similar to what these guys did, and turn off the extended instruction bit before you code: http://www.sfcompiler.co.uk/forum/viewtopic.php?p=6939&sid=e520961f7670c99ca5082c05cc975a5a

Maybe an assembly version of run-time config: http://www.picbasic.co.uk/forum/content.php?r=181-Run-Time-Config

Walter

[aberco]

Haha!!! I just found the same solution in another forum as well :)
Will quote it here:



Some of the newer PIC18s (e.g. 2480, 2580, 4550 etc) support the 'Extended Instruction Set', which enables them to do the offset indexed addressing. However, that's not how mikroC (or any of the MikroE's compilers) has been designed to do. The explanation from Microchip's datasheets for relevant PICs says: When the extended set is disabled, addresses embedded in opcodes are treated as literal memory locations: either as a location in the Access Bank (a = 0), or in a GPR bank designated by the BSR (a = 1). When the extended instruction set is enabled and a = 0, however, a file register argument of 5Fh or less is interpreted as an offset from the pointer value in FSR2 and not as a literal address. For practical purposes, this means that all instructions that use the Access RAM bit as an argument – that is, all byte-oriented and bit-oriented instructions, or almost half of the core PIC18 instructions – may behave differently when the extended instruction set is enabled.

This 'problem' can be solved in two ways:
1. Disable the extended instruction set (e.g. for PIC18F2480, it's in the 4th config word - _CONFIG_4L: _XINST_OFF_4L); it can be done either from the compiler itself (<Project>-><Edit Project>), or in the PICFLASH tool.

2. Leave the extended set enabled, but set the FSR2L and FSR2H to 0's at the beginning of your code; this will make the offset from the location 0x000000, which is the actual address stated. In this case you lose the FSR2 register pair.


I've also seen that config registers can be changed as you said, and thought about disabling extended instructions before running PBP code. It's just a matter of knowing if that can be done within a running program, without messing it up.

First I have to succeed running the bootloader code, and then I'll try these tricks to see if I can get PBP code running smoothly.

Will update progress here, thanks!

[aberco]

I've found a pretty nice tutorial with instructions to set up the diolan bootloader (http://www.nilok.ca/products/bootloader/index.php), with extra infos added to diolan's official website (which are pretty straightforward already). There's apparently a bug in EEPROM bootloader triggering with a proposed fix for it.

So far I'm having a hard time running the code. I ported it to 18F4550 by modifying all the references to the 18F4455, and added the missing config bits for the extra code space. All the define for the config (and especially the oscillator) should be ok, as I made a little LED blink program in PBP using the same config and which does work.

The bootloader compiles in MPLAB, I programmed it and inserted by hand the HEX code of my blinking led program at address $0800. The bootloader does behave as expected, after reset, if the loader button is pressed, the LED never blinks which tells that the bootloader is engaged. However it does not shows on the USB peripherials (and I declared existing VID/PID in the config). Bootloader LED never light up too...

Time for more troubleshooting!

[HenrikOlsson]

Guys,
I'm following this with interest and please continue the discussion. However, I was and still am looking for an encrypted serial non USB bootloader so if anyone stumbles across one please let me know!

/Henrik.

[aberco]

Hi Henrik! I would rather work with serial communication too! USB is clean and easy on the user side of things but it is far more challenging for us programmers. Maybe diolan's encryption routine can be reused within a serial bootloader, but that mean coding in ASM. The good side of things is that the code for encrypting the HEX code for the target is available, and communication protocol would still be handled by the original serial loader.

Well, it seems that I have no luck with USB on my little 18F4550 development board. Since I switched to 13/14K50 I have not managed to get anything running again on the 4550. I think that I managed to implement correctly the bootloader, but the USB interface is completely unresponsive. This is also true with a couple of other test programs (DT_HID260, HID demo, CDC demo). The configuration seems to be fine though, it run at the correct speed and USB module should be clocked at 48Mhz...

Maybe I'll concentrate my next efforts on porting the bootloader to 13/14K50, which is the MCU I really need for my projects (and I have USB working with it!).

[ScaleRobotics]

A commercial serial bootloader that has encryption. The price looks to be the only issue ..... well, that and it only works with 3 chips.
(Please be seated, I don't want anyone getting hurt)

http://www.auelectronics.com/Software-BTLD_RS232.htm

$1,999.00

[HenrikOlsson]

Thanks guys!
Walter, I'm afraid it ain't goin' to happen' at that price..... ;-)

The one from Brush Electronics is priced reasonably at $150 but seems it's not meant to be used with PBP and I'd really prefer something that works instead of me trying to hack something together.

Well, I'll keep my eyes and ears open, thank you both!

/Henrik.