Code Protect - Bootloader - Self-Programmable

[jfmateos2]

Nunca he protegido mis códigos pero ahora necesito hacerlo y no tengo ni idea de por dónde empezar... por lo que cualquier orientación será bienvenida.

Se trata de un programa que se carga en el PIC18f45k50 a través de un bootloader y que hace uso de la caracteristica self-programmable para aprovechar la memoria Flash del pic no usada por el programa (ni el bootloader) para almacenar datos.

He leído en el datasheet que hay que usar los registros cp0, cp1, cp2 y cp3 para proteger cada uno de los bloques de memoria, pero tengo un par de dudas:

- ¿Cómo averiguo qué bloques ocupa mi código?
- Si protejo los bloques que aprovecho para datas ¿podrá el programa acceder a ellos? Imagino que sí porque he creído entender en el datasheet que la protección de código sólo actúa para lecturas externas, no para operaciones iniciadas por el propio chip.

Muchas gracias

[omix]

Hola,
yo creo que mejor que averiguar los bloques que ocupa tu código, deberías reservar unos bloques de uso exclusivo para datos, ya que de lo contrario puede que en cada compilación te varíen los bloques ocupados.
Respecto a si puedes escribir en bloques protegidos la respuesta es afirmativa, la protección solo se aplica a operaciones externas por ICSP.

Saludos.

[jfmateos2]

Muchas gracias omix... finalmente he protegido todos los bloques porque los datos sólo necesitan ser consultados por el propio programa, no externamente.

El problema ahora es que como uso el bootloader de microchip sería muy fácil para cualquiera crear una aplciación que leyera el hex aprovechando el GET_DATA que usa el bootloader para verificar la grabación.

He visto que enel código del bootloader se menciona que comentando  ALLOW_GET_DATA_COMMAND se usarían checksums para la verificación en lugar de los verdaderos datos, pero parece que esto no se ha desarrollado porque no encuentro ninguna mención en el código a este comando ¿alguien puede aportarme alguna pista?

[EdoNork]

Hummm, otro peligro: alguien crea un programita que lee los datos que has bloqueado desde el mismo del PIC. Y lo instala con el bootloader...

[Picuino]

Creo recordar que Planeta9999 había escrito algo recientemente sobre bootloaders encriptados.

Saludos.

[Picuino]

http://www.todopic.com.ar/foros/index.php?topic=40379.0

Saludos.

[jfmateos2]

Gracias por las respuestas chicos.

Ahora mismo no tengo tiempo de liarme a crear un bootloader completo con encriptación así que he decidido meter estas 2 modificaciones al de microchip:

He comentado esta línea para que el bootloader no busque la señal de que la verificación se ha realizado correctamente:

//#define ENABLE_FLASH_SIGNATURE_VERIFICATION   

He modificado la línea siguiente para que el bootloader no se pueda usar para leer el programa (con esto, obviamente pierdo la opción de verificación)

//PacketToPC.Data[i+((USB_PACKET_SIZE - 6) - PacketFromPC.Size)]=TABLAT;
//Modificado para que no se pueda aprovechar el bootloader para leer el programa
PacketToPC.Data[i+((USB_PACKET_SIZE - 6) - PacketFromPC.Size)]=0;

[omix]

Hola,
desconozco como funciona el bootloader de microchip, pero lo que puedes hacer es cifrar la zona dedicada a datos. Así aunque te la puedan leer no podrán saber el contenido real, pero por contra si en tu programa vas acceder continuamente a dichos datos, el descifrado en tu aplicación puede llevar bastante tiempo (dependiendo del cifrado escogido), lo cual puede ralentizar la ejecución de la aplicación.

Saludos.

[BrunoF]

Hola,

deberías también elegir cuidadosamente todos los FUSES WRTx y los EBTRx. Los CP sólos no alcanzan. Nada impide, por ejemplo, que te carguen un firmware mediante el bootloader legítimo que se cargue dentro del uC y al ejecutarse habilite el puerto serie, por ejemplo, y vaya dumpeando todo el código del resto de los bloques de la FLASH y EEPROM. Está bien que este firmware pisará código del bloque donde se encuentra ubicado, pero con otro producto idéntico, pueden cargar el mismo codigo en otro bloque y mediante un sencillo salto dumpear los bloques restantes. Es un dolor de cabeza la protección de IP en estos uC. Incluso es mucho más sencillo si sobreescriben el sector del bootloader para ubicar el código malicioso, y dumpean todos lo bloques de la FLASH y EEPROM en una sola tirada. Si habilitas los EBTR que te darían verdadera protección frente a este ejemplo de ataque que te dí, hace muchas veces que el firmware tuyo termine ejecutándose erróneamente, ya que los Table Reads suelen ser muy utilizados por el compilador para generar internamente lecturas de elementos de arrays constantes, etc.

Como dije, todo un tema.

Saludos

[jfmateos2]

Muchas gracias Bruno... a ver si saco tiempo y puedo estudiar este asunto más cuidadosamente... ya os contaré