Autor Tema: Bootloader  (Leído 587 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado remi04

  • PIC12
  • **
  • Mensajes: 73
Bootloader
« en: 10 de Septiembre de 2017, 16:15:13 »
Quiero cargar un bootloader de tal forma que el fichero HEX del programa a cargar por el boot solo pueda trabajar con ese bootloader.

  Es decir, que si cargas el hex directo al pic no sea posible, que sea necesario el uso de un bootloader.  Por temas de protección de proyecto.

 ¿sabe alguien qué boot puede hacer eso?.

  el pic es 18f26k20

saludos.

Conectado AcoranTf

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 923
Re:Bootloader
« Respuesta #1 en: 10 de Septiembre de 2017, 19:30:59 »
¿Y no es mas sencillo, practico y efectivo proteger el micro contra lectura?.

Saludos.

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 2760
Re:Bootloader
« Respuesta #2 en: 10 de Septiembre de 2017, 19:46:46 »
Todos los bootoader funcionan así, el programa a cargar nunca se puede grabar directamente porque está compilado para ejecutarse a partir de una dirección.

Lo importante no es eso, sino que el bootloader esté encriptado, de lo contrario, cualquiera con unos conocimientos muy básicos te lo puede copiar, descompilar o clonar. Date cuenta de que a partir de un binario o HEX (sin encriptar) se puede saber cual es la  dirección de arranque de tu programa, y a partir de ahí cualquiera puede crear una rutina previa que simplemente salte a la ejecución de tu programa, aparte de que tu programa se podrá descompilar y manipular (por ejemplo, parchearlo para que funcione de otra forma, saque unos textos distintos en un display, etc...).

Mira en Google por PIC18 bootloader Github, y seguro que encuentras unos cuantos bootloader, ahora lo importante es que les añadas un sistema de encriptación, por ejemplo XTEA, o si lo encuentras ya hecho, mejor.
« Última modificación: 10 de Septiembre de 2017, 20:09:36 por planeta9999 »

Desconectado elreypic2

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 755
Re:Bootloader
« Respuesta #3 en: 10 de Septiembre de 2017, 19:52:07 »
Me ha ganado la respuesta planeta9999.
Para esto existe un bootloader comercial realizado por:
http://www.brushelectronics.com/

Este usa precisamente el algoritmo de encriptado XTEA. Esto tiene un costo de $150.00 USD. Pero creo que si tienes los conocimientos necesarios tu podrás implementarlo basado en alguno que ya exista.

Encontré este otro que es gratuito. Espero te pueda servir:

https://diolan.com/pic-bootloader

Saludos,

elreypic.
« Última modificación: 10 de Septiembre de 2017, 19:56:40 por elreypic2 »

Conectado AcoranTf

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 923
Re:Bootloader
« Respuesta #4 en: 10 de Septiembre de 2017, 22:37:08 »
Planeta9999 y elreypic, me gustaria saber que ventajas, a nivel de proteccion del codigo representa poner un bootloader en lugar de simplemente proteger contra lectura el PIC.
Ya se que con un bootloader hay otras ventajas, como no necesitar programador externo y/o poder realizar la carga del codigo por RS232 y/o USB, pero a nivel simplemente de seguridad, no le veo el sentido.

Saludos.

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 2760
Re:Bootloader
« Respuesta #5 en: 10 de Septiembre de 2017, 23:17:55 »
Planeta9999 y elreypic, me gustaria saber que ventajas, a nivel de proteccion del codigo representa poner un bootloader en lugar de simplemente proteger contra lectura el PIC.
Ya se que con un bootloader hay otras ventajas, como no necesitar programador externo y/o poder realizar la carga del codigo por RS232 y/o USB, pero a nivel simplemente de seguridad, no le veo el sentido.

Saludos.

A nivel de seguridad no hay diferencias. El bootloader se emplea para comercializar productos, para los que quieres poder dar a los clientes, actualizaciones de firmware para corregir bugs, sacar versiones con nuevas prestaciones, crear versiones personalizadas, desactivar placas piratas, etc...

Si tu producto, nunca se va a actualizar, no tiene sentido poner un bootloader, lo grabas con protección de lectura y arreando.

Precisamente hace poco he estado trabajando con el bootloader encriptado uTasker para implementarlo en varios de mis productos con micros Kinetis, y va de maravilla. Así puedo colgar en un Github, actualizaciones del firmware, para que el cliente las descargue y actualice el producto, con total seguridad para mí. Los archivos de actualizaciones que doy están encriptados, si los editas no verás más que garabatos, sin posibilidad alguna de copiarlo o descompilarlo. Una maravilla de bootloader encriptado, que también se puede usar con los STM32, y totalmente gratuito.
« Última modificación: 10 de Septiembre de 2017, 23:25:44 por planeta9999 »

Conectado AcoranTf

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 923
Re:Bootloader
« Respuesta #6 en: 11 de Septiembre de 2017, 05:55:06 »
Gracias planeta9999, justamente eso es lo que tenia entendido. Pero con el planteamiento de remo04 me confundio.

Saludos.

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 2760
Re:Bootloader
« Respuesta #7 en: 11 de Septiembre de 2017, 08:02:34 »


Un bootloader no protege de nada, salvo que esté encriptado.

Que un programa no se pueda cargar si no es a través de un bootloader, no impide que te copien el producto. Simplemente con que te hagan una mini rutina, que en el arranque, salte a la dirección de tu programa, ya está clonado el producto.

Si quiere un bootloader, será porque quiere dar actualizaciones, pero para eso hay que encriptarlo.


Desconectado remi04

  • PIC12
  • **
  • Mensajes: 73
Re:Bootloader
« Respuesta #8 en: 11 de Septiembre de 2017, 09:24:11 »
Exacto eso es. Quiero poder reparar bugs y que el usuario desde su casa pueda actualizarlo con un simple usb y a su vez, proteger el hex para que no se pueda duplicar así por que si.

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 2760
Re:Bootloader
« Respuesta #9 en: 11 de Septiembre de 2017, 09:36:56 »

Pues tendrás que encriptarlo. Yo hace años me hice uno para PIC32, a partir de una nota aplicativa de Microchip, y le añadí mi propia rutina para desencriptar con XTEA. También me hice un programa en VC++ para encriptar los HEX. Incluso me lo compraron de algunas empresas.

Ahora ya solo trabajo con ARM, y para estos encontré el uTasker, que va de maravilla.

Desconectado remi04

  • PIC12
  • **
  • Mensajes: 73
Re:Bootloader
« Respuesta #10 en: 11 de Septiembre de 2017, 18:23:45 »
Gracias a todos por las respuestas. He estado estudiando bastante toda la info que habéis puesto y de momento al estar muy "verde" en el tema de bootloader pues he empezado por lo mas básico como usar los ejemplos de CCS exbootloader.c

  Por lo menos ya he conseguido cargar el programa a través de este sistema usando el SIOW.exe del ccs.

El problema es que este bootloader no carga los datos de la eeprom interna que están incluidos en el hex del programa.  Sin esos datos no funciona la lcd por que contiene constantes como valores de bias, contraste entre otros muchos datos que deben permanecer no volátiles.

 ¿ como se puede hacer para que el bootloader cargue también la eemprom?

Desconectado elreypic2

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 755
Re:Bootloader
« Respuesta #11 en: 11 de Septiembre de 2017, 19:32:05 »
Que tal remi04,

Puedes usar el "Tiny Multi Bootloader+", este te permite cargar datos en la eeprom como lo necesitas.
Este es el link:

http://tinypicbootload.sourceforge.net/

elreypic.

Desconectado remi04

  • PIC12
  • **
  • Mensajes: 73
Re:Bootloader
« Respuesta #12 en: 12 de Septiembre de 2017, 09:34:28 »
Gracias. Le echaré un vistazo, el problema es que está en asm....  Pero lo veré

  De momento lo he solucionado cargando los datos de la eeprom en el propio bootloader. Es decir, cuando grabo el bootloader en el micro también grabo los datos de la eeprom.

Saludos.

Desconectado elreypic2

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 755
Re:Bootloader
« Respuesta #13 en: 12 de Septiembre de 2017, 12:21:45 »
Gracias. Le echaré un vistazo, el problema es que está en asm....  Pero lo veré

  De momento lo he solucionado cargando los datos de la eeprom en el propio bootloader. Es decir, cuando grabo el bootloader en el micro también grabo los datos de la eeprom.

Saludos.

No veo cual sería el problema de que estuviera en ASM. De hecho este bootloader realmente es muy pequeñito, y comparado con otro que tengas en C, te darás cuenta que tienes mas espacio en memoria de código.

Saludos,

elreypic.

Desconectado remi04

  • PIC12
  • **
  • Mensajes: 73
Re:Bootloader
« Respuesta #14 en: 14 de Septiembre de 2017, 05:00:08 »
Problema en verdad ninguno, salvo que tengo que hacer modificaciones y al intentar compilar el fichero de tiny en mplabx me lanza muchos errores de compilación, algunos diciendo "can´t open the file" de los includes estando la ruta de acceso bien, y de hecho haciendo "control + click" sobre el fichero del include te lo abre perfectamente, pero al compilar dice que no los encuentra.  Ello ocasiona una larga lista de errores.    De todas formas todo lo que pueda hacer directamente en C mucho mejor. El assembler lo leo bien, pero meterme a hacer cosas en asm me da un poco de grima.

  Al margen de todo, he estado estudiando los ejemplos del bootloader del CCS para ver por qué no graba la eeprom y en principio y viendo tambien el datasheet del 18f26k20 entiendo que la eeprom está separada de program memory y de ram. viendo entonces que en el caso de mi cpu, program memory = 65535 bytes (0xFFFF). Entiendo que la eeprom interna debe ser accedida a través de sus registros (funciones en C para ello "read_eeprom(a,d);, write_eeprom(a,d);


  a modo de entender como el compilador incrusta los datos para la eeporm, he compilado un pequeño programa que lleva incrustados 25 bytes de datos en la eeprom. El archivo HEX resultante es este:

   
Código: [Seleccionar]
:1000000002EF00F0F86AD09E700ED36E9B8C9B9E20
:10001000000E7E6EC198C19A7F50E00B7F6E799A78
:0A00200079987A6A7B6AFFD7030023
:0200000400F00A                                                        ; Aquí está el linetype = 04 y los bytes altos de ADDR (00F0) es decir, que la dirección sería 
                                                                                   ; 000000F000000000,   Totalmente fuera de rango. por lo que el loader del exboot ccs lo ignora.
:1000000032463201290E0B01020000010001011AE3     ; Aquí están los primeros 16 bytes de datos a cargar en la eeprom
:09001000015E0000000000000088                              ; Aquí están los otros 9 bytes que van a la eeprom.

:020000040030CA
:0E00000000C81E1E000F81000FC00FE00F4051
:00000001FF
;PIC18F26K20
;CRC=CFE6  CREATED="14-sep.-17 09:10"

   
   Entiendo que lo que puedo hacer es añadir en el cargador un If que detecte esta dirección y grabar el buffer uno a uno usando la función (write_eeprom(address,data)

  ¿ lo veis viable?

¿ se nota que no he tocado bootloader en mi vida?, madre mía lo que se aprende...   La base de todo.  Es lo malo de aprender directo alto nivel, que luego hacen falta cosas asi y empiezan los cortocircuitos cerebrales  :D
« Última modificación: 14 de Septiembre de 2017, 08:42:28 por remi04 »