El bootloader se puede usar de manera independiente, a mi es lo que me interesa de ese proyecto, aunque tiene muchas más cosas. Ahora mismo necesito sacar al mercado varios productos con Kinetis y necesitaba con urgencia un bootloader encriptado para poder dar actualizaciones de firmware a los clientes.
He configurado y compilado el Bootloader para Kinetis MK66, y el ejecutable tan solo ocupa 18K.
Ya he visto como funciona la encriptación. Dan un pequeño aplicativo para linea de comandos DOS (uTaskerConvert), le pasas como parámetro el binario a encriptar, un código de producto configurable para evitar que se carguen actualizaciones que no son para esa placa y una clave de encriptación, con todo eso te crea un nuevo fichero al que le añade una cabecera con un checksum, código de producto y el binario encriptado.
Una maravilla, justo lo que andaba buscando, de código abierto, gratuito y totalmente compatible con Kinetis y STM32. El resto de útiles de uTasker no lo he mirado, creo que tiene funciones de sistema operativo y algunas cosas más.
Encryption optionhttp://www.utasker.com/docs/uTasker/uTaskerBoot_003.PDFOften it is undesirable that the software which is up be updated to the remote device is available in a readable form. In order to make it difficult for the program content to be interpreted, the Boot Loader supports also an optional encryption/decryption function. Whether encryption is used or not is defined in the project setup and also in the use of the conversion utility.
When the conversion utility performs encryption it has the following use:
uTaskerConvert uTasker_demo uTasker_update.bin -0x1234 –a748b6531124 –ab627735ad192b3561524512 -17cc – f109
The additional parameters cause the encryption step to be performed.
ab627735ad192b3561524512 is an encryption key which is used to transform the data content. It must have a length dividable by 4) and its length determines the strength of the coding.
17cc is used to prime a pseudo-random number generator used during the process (should not be zero) which must also match.
F109 is a shift value in the code which makes it much more difficult to break using bruteforce techniques. Without this shift it would be much easier to match known code patterns at the start of the file. Since the start code can be anywhere in the data this avoids this possible weakness.
The header added to the upload file is increased slightly in length due to the need for a second CRC.
unsigned long ulCodeLength;
unsigned short usMagicNumber;
unsigned short usCRC16;
unsigned short usRAWCRC;In this case usCRC16 is the check sum of the encrypted file (as it is stored during the upload) and usRAWCRC is the check sum of the real code (before encryption) so that successful decryption can also be verified.
The decryption process is an additional step in the Boot Loader which is performed when the code is copied to its executable position in FLASH.
It is advisable to always use a different magic numbers for projects with and without encryption. This ensures that encrypted data will never be copied to its executable location by a project without decryption support.
The encryption method can be used with both internal FLASH and also external SPI FLASH