Bootloader Encriptado para PIC32

[planeta9999]

El año pasado me planteé disponer de un bootloader encriptado para PIC32, imprescindible para comercializar productos que precisan actualizaciones, para mejorar prestaciones, cambiar o añadir nuevas opciones, corregir bugs, etc...  Primero busqué por si había código fuente disponible, para mi sorpresa nada de nada, salvo un engendro de una empresa llamada Diolan, para PIC18, con un código fuente mezcla de C y ensamblador, además con los programas para PC, ejecutables desde una ventana DOS escribiéndolos a mano.

Luego busqué algún producto comercial, si no hubieran sido caros, lo hubiera comprado, para no perder el tiempo. Encontré dos, uno bastante caro, y el otro aunque con un precio asequible, con un problema importante, necesita un código de activación para su instalación, con lo cual si un día te casca el disco duro y ese chiringuito ha cerrado, te quedas totalmente colgado, sin poder dar actualizaciones, ni programar nuevas placas.

Así que tocaba programar mi propio Bootloader encriptado, no he partido de cero, he utilizado el AN1388 de Microchip, al que he añadido el algoritmo XTEA, para la desencriptación (clave de 128 bit y 64 iteraciones), y he creado un par de programas para el PC, con Visual Studio en C++, uno para encriptar el HEX del firmware, y otro para que el cliente cargue las actualizaciones en la placa. Creé dos bootloader, uno para USB y otro para tarjetas SD, que son los que necesito por ahora, una vez hecho el trabajo gordo, se puede extrapolar con facilidad para Pendrives USB, Ethernet o RS232.


De, bootloader para USB, tengo dos versiones, una básica y otra para uso profesional. La versión básica, la podeis descargar del siguiente link, es totalmente funcional, incluye el programa para encriptar el firmware, el HEX con el bootloader y el programa para transferir el firmware a la placa por USB:
http://www.pinballsp.com/PinballSP_Encrypted_Bootloader_Solution_Basic_Version.zip

También hice una modificación del AN1388 (sin encriptación), quitando el pulsador y los LED, con esta modificación se entra automáticamente en modo bootloader, sin necesidad de apretar ningún pulsador, lo que simplifica el hardware. Al dar tensión a la placa, el bootloader espera durante 5 segundos la comunicación con el PC por USB, si se establece comunicación se queda en modo bootloader, de lo contrario salta automáticamente a la aplicación del usuario (firmware), si existe.
http://www.pinballsp.com/PINBALLSP_Bootloader_USB_PIC32_AN1338_Modified.zip

Las versiones profesionales del bootloader, las voy a utilizar para los productos comerciales que estoy diseñando y también las he vendido a algunas empresas.

Las diferenciass entre la versión básica y la profesional son las siguientes:

1.- La versión básica utiliza una clave de encriptación/desencriptaciçon única, no se puede cambiar, aunque el producto es 100% funcional, todo el mundo trabaja con la misma clave. La versión profesional está personalizada, yo utilizo una clave diferente para mis aplicaciones y las que he vendido también reciben una clave única y distinta para cada cliente.

2.-  La versión básica entra en modo bootloader pulsando un switch, en la versión profesional se entra en modo bootloader automáticamente sin necesidad de pulsadores, en cuanto le das tensión, espera 5 segundos la comunicacion con el PC, de lo contrario salta automaticamente a ejecutar el firmware.

3.- La versión profesional añade 4 campos en flash, para personalizar el bootloader, de esta manera se puede tracear cada placa por nº de serie, comprobar que producto y firmware tienen instaladas, detectar producto pirata, etc..
  
     Nº de serie: Cada placa se puede personalizar con un nº de serie único, para tracearla, proporcionar firmware personalizado, chequear producto pirata, etc..
     Código de producto: Permite identificar el producto instalado, para por ejemplo evitar que se cargue en una placa, firmware de otro producto, por error.
     Versión de firmware: Lo que su propio nombre indica, identifica la versión de firmware instalada, en mi caso, lo utilizo también para evitar que se carguen versiones antiguas de firmware.
     Seguridad: Sirve para bloquear placas pirateadas, tras chequear el nº de serie. Se puede utilizar como contador de usos, para no bloquear la placa de inmediato, sino tras 15 ó 20 usos, por ejemplo.


Os dejo unas imágenes de los programas para PC del bootloader encriptado para USB, en la versión básica está el encriptador (con clave de encriptación fija), y el programa para volcar el firmware a la placa. En la versión profesional, hay además otro programa para inicializar el bootloader con un nº de serie único, código de producto y versión de firmware.


Programa para encriptar el firmware con el algoritmo XTEA, clave de 128 bits, 64 iteraciones, desarrollado en C++ con Visual Studio 2010




Programa para transferir el firmware a la placa, por USB. En la versión profesional, permite también leer el nº de serie, código de producto y versión de firmware instalado.




Este programa solo está en la versión profesional, permite personalizar el bootloader, con un nº de serie único por placa, código de producto y versión de firmware, además permite cargar el firmware, todo del tirón.

[BrunoF]

Hola!

Muy bueno!

Yo hace unos años hice uno exáctamente igual, utilizando XTEA.

Saludos!

[Nocturno]

¡Genial!

[MerLiNz]

Yo creo que es mejor hacerte tu propia encriptacion, si usas una que este por ahi siempre es posible desencriptarlo viendo el codigo, y utilizando ingenieria inversa. Ahora si te haces el tuyo propio solo lo sabras tu.

[BrunoF]

No siempre es así.

Muchos sistemas de seguridan poseen seguridad conocida, y no por ello significa que sea posible romper su seguridad; al menos no en un tiempo prudente, objetivo de toda encriptación. Siempre habrá formas de romper una seguridad. Recordemos que cuando uno protege algo debe hacerlo para desalentar lo suficiente como para que el atacante desista o bien el esfuerzo requerido para romper la seguridad exceda el beneficio obtenible e incluso resulte más redituable/rentable en dinero y tiempo desarrollar un producto de cero con las mísmas funcionalidades.

Hace tiempo se me ocurrió una forma sencilla y muy segura de proteger un firmware, pero tiene sus serias desventajas.

La idea básica sería una vez generado el .hex, rellenar con valores alearorios toda la memoria disponible pero no utilizada del uC. De esa manera generaríamos un nuevo hex, con toda la memoria en uso.

Ahora, tras una nueva versión, al nuevo .hex le haremos lo mísmo, lo rellenaremos con valores aleatorios en toda la memoria no usada.

Ahora sólo nos resta crear crear un nuevo archivo, que no sera ni mas ni menos que una XOR byte a byte de ambos firmwares rellenados resultantes. Dicho resultado será entregado para que el cliente actualice. El cliente no tendrá nunca forma de saber realmente el contenido del código original. Sólo tendrá una parte, la necesaria para que al procesar la XOR nuevamente dentro, el uC recomponga el firmware deseado.

Las limitaciones son que este método solo funcionaría con memoria que no sea modificada durante runtime, y que en caso de que durante el proceso de actualización algo falle, no habrá forma de recuperar el firmware, al menos no con este método. Fuera de eso, sería un método bastante seguro.

Saludos!

[MerLiNz]

Por eso te digo brunof, es mejor hacerlo tu mismo a tu antojo, si coges un programa externo que lo haga, y sobretodo si es codigo-libre es mas sencillo de utilizar ingenieria inversa y conseguir ese .hex, ahora si tu haces una encriptacion propia sea como sea (valores aletorios, cada x byte poner algo raro....) sera muy dificil que te lo descubran, mas que nada porque solo tu sabras como lo has hecho y como revertirlo.

[planeta9999]

Yo creo que es mejor hacerte tu propia encriptacion, si usas una que este por ahi siempre es posible desencriptarlo viendo el codigo, y utilizando ingenieria inversa. Ahora si te haces el tuyo propio solo lo sabras tu.

Normalmente, no se rompen estos sistemas atacando al software, sino al hardware, y en eso los chinos son unos expertos, no hay nada que se les resista.
Sin ir más lejos, mi amiguete chino, el que me hace las placas, lo clona TODO, compra productos europeos o americanos, y en una semana está clonado, da igual que lleven un micro con encriptación por hardware, todo termina cayendo.

Además, en China, parece que eso es totalmente legal (reventar hardware), según ellos con fines educativos, hay tropecientas mil empresas que se dedican a eso, a mi hace tiempo me pasaron tarifas para clonar chips, por unos 500 dólares te sacan el objeto de prácticamente cualquier PIC, los ARM son algo más caros, los CPLD por 1200 dólares, etc...

Lo mejor es adelantarse al pirata, y pensar como lo harías tú, para meter trampas que lo hundan en la misería.
Recuerdo un caso muy sangrante (para el pirata, chino por supuesto), clonaron un interface americano de diagnosis para automoción de vehículos Volkswagen, cada versión original era clonada por los chinos, sin el menor esfuerzo, hasta que al fabricante original se le ocurrió poner una pequeña "trampa" en su firmware, incluyó una lista negra con los números de serie de las placas clonadas y un contador de usos, el chino clonó el producto como siempre, lo probó (aparentemente funcionaba cargando la última versión del firmware), y se puso a fabricarlo por miles, como siempre. No contó que está vez el chequeo por número de serie, dejaba que el producto siguiera funcionando, aunque fuese pirata, pero al cabo de haberlo utilizado 15 ó 20 veces, el inteface se bloqueaba irreversiblemente. El caos fué total para el pirata, miles o decenas de miles de interfaces bloqueados, reclamaciones a porrillo.


Ya estuve mirando lo de hacer un algoritmo propio con el XOR, tablas y contadores, pero por software, no creo que el XTEA se pueda romper con facilidad, sin saber la clave de encriptación, y desde luego si lo cascan los chinos, no será por software, será por hardware, y contra eso no hay algoritmo que se resista. De todas formas ya tengo pensadas varias formulas para proteger y cascar placas piratas, si vieran la luz, incluso se podría actualizar el bootloader desde el firmware, para cambiar las claves de encriptación.


 

[RICHI777]

Hola MerLiNz, justamente es al revez. Normalmente los algoritmos conocidos o mas populares están diseñados y probados por matemáticos que prueban la vulnerabilidad del mismo. Si ir mas lejos en el cifrado por RSA el algoritmo se basa en la multiplicación de dos números primos gigantescos ( es decir el algoritmo es simplemente una multipliación ) , como muchos sabrán la factorización de números enormes es en tiempos computaciones una tarea casi imposible. Y si todas las maquinas del mundo se ponen de acuerdo para romper una clave simplemente se aumenta el tamaño de las claves. Por eso se recomienda utilizar algoritmos probados y no los desarrollados en forma casera. También es necesario tener en cuenta donde se almacenan las claves, hoy x hoy existen chips crytográficos donde los mismos chips contienen hardware necesario para poder protejerse de ataques como volar encapsulado y otras yerbas.

Saludos !

[Geo]

En efecto, la seguridad "por oscuridad" no es lo mejor (como es el caso de "crear" tu propio tipo de encriptación).

A mi me han encargado el diseño de una llave USB para actualización de un software, si tienen más información con respecto a estos temas les agradezco puedan compartirla .

[MerLiNz]

A ver, este software que habeis puesto es muy sencillo de "desencriptar" basta con poner un sniffer en el usb, o crear un usb virtual y hacerlo pasar por el "pic". Segun veo lo que hace el software es desencriptar el .hex y enviarlo al pic por usb, entonces si este es el caso ya tenemos el codigo fuente del pic.

No le deis mas vueltas... No hay que ponerse a desencriptar nada, simplemente buscar la forma mas sencilla. Ahora bien, si yo hago una encriptacion, a la hora de actualizar el .hex el usuario recibe el .hex encriptado, una vez envia el .hex el propio pic tiene un algoritmo de desencriptacion y actualiza el firmare una vez que lo desencripte internamente, ¿cuanto años se va a tirar alguien buscando la forma de desencriptar solo teniendo el .hex? Incluso hay miles de cosas que poner, como meterle un byte erroneo cada X bytes (o bien bytes que existan en una tabla para ignorarlos), de una vez se envia volverlo a encriptar para confundir al usuario, o miles de cosas mas, como añadir una firma y que el propio pic confirme de que esa firma es correcta (ya sea un numero de serie o lo que sea...) en caso incorrecto que el pic funcione, pero que funcione mal...

No se vosotros, yo seguire usando mis propios medios, recuerdo en la programacion de un juego la lucha contra los "cheats" o tramposos... pusismos una encriptacion, se llamaba blowfish utilizaba una clave de 16bytes y tardaron unos meses en averiguar como desencriptar, ahora bien le pusismos la cosa mas tonta del mundo, el servidor enviaba un caracter y el cliente respondia con otro, si no respondia entonces ese cliente es modificado, pues asi calleron muchos y muchos tramposos, y segun me comento uno que aun sigue programando en el juego, aun siguen callendo la gente. Como yo siempre digo la improvisacion es la mejor seguridad, mucho mejor que poner una megaencriptacion de 10000000bytes, al final si alguien quiere desencriptar no se va a buscar como hacerlo, sino como evitarla. Sin contar claro, que muchas veces los creadores de este tipo de programas "se venden" y cuando les interesan filtran claves y cosas asi por el estilo, dependes de otra persona, no de ti mismo...

[planeta9999]

A ver, este software que habeis puesto es muy sencillo de "desencriptar" basta con poner un sniffer en el usb, o crear un usb virtual y hacerlo pasar por el "pic". Segun veo lo que hace el software es desencriptar el .hex y enviarlo al pic por usb, entonces si este es el caso ya tenemos el codigo fuente del pic.

No, obviamente no sabes lo que es un bootloader encriptado.

[BrunoF]

El archivo se envía encriptado al uC. O al menos así debería hacerse. El archivo que se le envía al cliente está encriptado con una Key que ha sido prepactada por el usuario de 128 bits de longitud. Por más que snifees el paquete USB o revuelvas el ejecutable que se le da al cliente no vas a encontrar subrutina de desencriptación. La PC sencillamente transporta el archivo, nada más. Es el uC el que posee la subrutina dentro y la llave necesaria, también protegida. Esta seguridad funciona más que bien.

Y estoy de acuerdo con otros en que es mejor reposar en un algoritmo conocido y comprobado por personas que dedican su vida a la criptografía. El problema es que muchas veces meter, por ejemplo, AES, que es una protección sumamente superior a XTEA, no es para nada sencillo debido a la baja ROM/RAM y capacidad de procesado del uC.

Y con respecto a esos trucos de hacer cosas a medida, por lo general funcionan bien para quien es un novato en crackeo o bien no posee un terminal original. Pero teniendo un terminal original, u obteniendo los datos de ellos, no seria dificil darse cuenta de que el servidor espera una respuesta o te banea.

Hace añares a alguien se le ocurrió incluso que una forma de contraseña podía ser ir conectandose en determinado orden a los puertos de un servidor, sin siquiera enviar datos. Sencillamente iniciar el request de conexión a puertos TCP/UDP en determinado orden y dentro de ciertos intervalos de tiempo.

Podés inventar los mil y un artilugios. Nadie te va a decir qué es mejor. A veces es mejor ser tramposo, pero creeme que ser tramoso muchas veces también hace que ignores ciertos factores muy importantes, como propias vulnerabilidades que abren tus trampas.




 

[MerLiNz]

A ver, este software que habeis puesto es muy sencillo de "desencriptar" basta con poner un sniffer en el usb, o crear un usb virtual y hacerlo pasar por el "pic". Segun veo lo que hace el software es desencriptar el .hex y enviarlo al pic por usb, entonces si este es el caso ya tenemos el codigo fuente del pic.

No, obviamente no sabes lo que es un bootloader encriptado.

Si lo se, lo se porque he hecho varios de varios tipos para mi uso personal, lo unico que no se es como trabaja ese bootloader, si no lo se es porque no he trabajado con el ni tampoco lo he diseñado.

El archivo se envía encriptado al uC. O al menos así debería hacerse. El archivo que se le envía al cliente está encriptado con una Key que ha sido prepactada por el usuario de 128 bits de longitud. Por más que snifees el paquete USB o revuelvas el ejecutable que se le da al cliente no vas a encontrar subrutina de desencriptación. La PC sencillamente transporta el archivo, nada más. Es el uC el que posee la subrutina dentro y la llave necesaria, también protegida. Esta seguridad funciona más que bien.

Y estoy de acuerdo con otros en que es mejor reposar en un algoritmo conocido y comprobado por personas que dedican su vida a la criptografía. El problema es que muchas veces meter, por ejemplo, AES, que es una protección sumamente superior a XTEA, no es para nada sencillo debido a la baja ROM/RAM y capacidad de procesado del uC.

Y con respecto a esos trucos de hacer cosas a medida, por lo general funcionan bien para quien es un novato en crackeo o bien no posee un terminal original. Pero teniendo un terminal original, u obteniendo los datos de ellos, no seria dificil darse cuenta de que el servidor espera una respuesta o te banea.

Hace añares a alguien se le ocurrió incluso que una forma de contraseña podía ser ir conectandose en determinado orden a los puertos de un servidor, sin siquiera enviar datos. Sencillamente iniciar el request de conexión a puertos TCP/UDP en determinado orden y dentro de ciertos intervalos de tiempo.

Podés inventar los mil y un artilugios. Nadie te va a decir qué es mejor. A veces es mejor ser tramposo, pero creeme que ser tramoso muchas veces también hace que ignores ciertos factores muy importantes, como propias vulnerabilidades que abren tus trampas.

Si, con el tiempo se dan cuenta, sin embargo antes de que se den cuenta se ha sacado otra version la cual ha cambiado el comando o la forma de transmitirlo, es como todo, la idea es seguir innovando. De todas formas una vez se descubre un tramposo se le banea la cuenta y es una pena que una persona eche 200h en una cuenta para que al final se le banee por usar clientes modificados. Podra volver a entrar con otra cuenta, usar trampas hasta que se le coja y luego otra vez baneada/borrada una cuenta con mas de 200h de juego..

[Picuino]

Voy a abrir un hilo relacionado:
    
Bootloader encriptado para Attiny88.
http://www.todopic.com.ar/foros/index.php?topic=45149