PIC protegidos ??

[dakarlcts]

Buenas a todos, soy nuevo en el foro, llevo tiempo queriendo emprender al camino de los microprocesadores y me he estado empapando un tiempo para ponerme con ello.
Tengo dudas sobre las protecciones de los microcontroladores, he conseguido unas placas antiguas las cuales traen pic 18f87j50 que me gustaría reutilizar.

Esas placas son actualizables mediante usb y para actualizar hacia falta un software y te mandaban el archivo .hex .

Mi duda es, puede que esos pic o bien no estén protegidos contra escritura, o el software de actualización tenga la clave para desbloquear esa escritura verdad .
 
¿Alguna idea donde mirar en el .hex para ver si escribe en el CP?  He abierto en codigo en winpi800 y hecho disasembly.

Muchas gracias de antemano.

[Sispic]

Hola  dakarlcts
Si lees el PIC veras el bit

CP0: Code Protection
1 = Program memory is not code-protected
0 = Program memory is code-protected

si lo desensamblas y no esta todo a nop es que no esta protegido .

[KILLERJC]

Si te dan el .hex

Puede ser que:
- Al tener el .hex es lo mismo que leer el micro (en caso de que el .hex no este codificado), entonces aca ya tenes tu codigo....
- El .hex este codificado. Caso mas probable..

Según como actualiza el software el micro.
Si posee un bootloader y ahi desencripta no vas a poder hacer nada.
Si es la PC quien desencripta el .hex y lo envia al PIC entonces podes ponerte en el medio de la comunicacion y captar todos los datos enviados, es decir el programa.

Finalmente leer el PIC, y si lees todo 0x000 seguramente este protegido contra escritura. Recorda que 0xFFF es el estado natural del micro.

¿Alguna idea donde mirar en el .hex para ver si escribe en el CP?

Usualmente al final. Pero si podes abrirlo con un programador te vas a dar cuenta si tiene el bit CP activo, tal y como dijo Sispic

[dakarlcts]

Muchas gracias por las respuestas.
Con el winPic800 cargo el .hex configurando el pic usado 18f87J50 y me  da el siguiente error:

Error, linea 7370, dirección invalida para el dispositivo seleccionado.

Acepto y carga todas las lineas a partir de la 7370. Si que es verdad que hay lineas con FFFF pero tambien muchas con contenido.

Por ejemplo el inicio y el final :

Código: [Seleccionar]

  0x0000 : 0xEF33   goto    0x013666        ; 1st word
  0x0002 : 0xF09B                           ; 2st word
  0x0004 : 0x0012   return  0
  0x0006 : 0xFFFF   Data    0xFFFF
  0x0008 : 0xEF04   goto    0x002008        ; 1st word
  0x000A : 0xF010                           ; 2st word
  0x000C : 0x0012   return  0
  0x000E : 0xFFFF   Data    0xFFFF
  0x0010 : 0xFFFF   Data    0xFFFF
  0x0012 : 0xFFFF   Data    0xFFFF
.....
  0x1FFFE : 0xFFFF   Data    0xFFFF

     ORG 0x1FFF8      ; CONFIG

       Data   0xF7F8
       Data   0xFF3D
       Data   0xF7FF
       Data   0xFFFF

 end ;

Intuyo que ahí esta todo el programa y no hay codificacion de ningun tipo.

Si leo en la configuración veo que en el cuadradito de CP0 esta desclicado, es decir el chip tiene code-protect ¿Cierto?
Entonces si yo cambio ese bit, desde el .hex ¿podría dejar ese pic liberado para hacer lo que quiera con el?

Cuando cambio el bit CP0 y dejo el cuadro con el clic los ultimos datos se quedan así:

Código: [Seleccionar]

     ORG 0x1FFF8      ; CONFIG

       Data   0xF3F8
       Data   0xFF3D
       Data   0xF7FF
       Data   0xFFFF

 end ;

Es decir que hay posibilidades.  Es la primera vez que lo hago y no me gustaría perder el pic.

Si es la PC quien desencripta el .hex y lo envia al PIC entonces podes ponerte en el medio de la comunicacion y captar todos los datos enviados, es decir el programa.

¿Podrías explicarme más sobre esto?.

Muchas gracias!!

[DominusDRR]

Si leo en la configuración veo que en el cuadradito de CP0 esta desclicado, es decir el chip tiene code-protect ¿Cierto?
Entonces si yo cambio ese bit, desde el .hex ¿podría dejar ese pic liberado para hacer lo que quiera con el?

La protección de lectura de la memoria de programa es una garantía que MCHP ofrece en sus productos para evitar que alguien robe el código programado en el microcontrolador.

Si lees las hojas de datos que se refieren a la programación de la memoria flash, te dice que la única manera de borrar el bit CP es mediante un borrado completo de la memoria de programa. Si no borras completamente la memoria de programa, no puedes cambiar el estado del bit CP.

Dentro del microcontrolador existe un motor ICD (que puede decirse que es como otro micro) que realiza la programación lectura, borrado y depuración del código y es ese dispositivo quien garantiza la protección de la propiedad intelectual del firmware interno.

Obviamente hay otras técnicas para romper la seguridad, que es utilizar un solvente para retirar el plástico o cerámica del micro y exponer a la  vista el silicio interno y mediante un microscopio electrónico analizar el contenido de la memoria flash, pero eso ya es otro nivel de reingeniería inversa.

[DominusDRR]

Si es la PC quien desencripta el .hex y lo envia al PIC entonces podes ponerte en el medio de la comunicacion y captar todos los datos enviados, es decir el programa
 ¿Podrías explicarme más sobre esto?.

Muchas gracias!!

En el firmware que utilizamos en nuestros productos, el archivo hexadecimal (que es una archivo de texto), lo encriptamos de 3 maneras diferentes y al final es un archivo con otra extensión.

Si tu abres con un blog de notas el archivo nuevo, verás que literalmente está en chino escrito todo.

Este es el archivo que distribuimos al usuario del hardware, es decir las actualizaciones, para que el mismo reprograme la memoria flash

La única manera para regresar al hexadecimal original es mediante el código desencriptado y conociendo las llaves que lo permiten.

El software que utiliza el usuario para actualizar el firmware de sus equipos posee la llave y cuando abre el archivo encriptado, obtienen el archivo hexadecimal original, pero este está en memoria RAM, no lo guardan en algún disco del PC.

Cuando empiezas a enviar el código al microcontrolador para que reprogramar su memoria (vía USB, UART, Ethernet, etc.)  podrías colgarte a ese bus mediante un sniffer  y ver que está enviando el software al hardware y obtener tu archivo hexadecimal.

Pero nosotros tenemos un nivel extra se protección, y al transmitir y recibir datos en la comunicación ethernet ,también existe encriptación para evitar lo anterior, es decir evitar que mediante un sniffer se puede obtener los datos enviados y recibidos.



 

[dakarlcts]

En el firmware que utilizamos en nuestros productos, el archivo hexadecimal (que es una archivo de texto), lo encriptamos de 3 maneras diferentes y al final es un archivo con otra extensión.

Si tu abres con un blog de notas el archivo nuevo, verás que literalmente está en chino escrito todo.

En mi caso entonces el .hex no está encriptado porque si lo abro y es código, de todas formas entonces lo que yo te he entendido es que la protección es sobre lectura, pero no sobre escritura y voy a poder escribirlo. No puedo hacer las pruebas porque estoy esperando un pickit3 y una placa easypic donde podre hacer pruebas de lectura y escritura directas en el pic.


Las últimas actualizaciones que proporcionaron fueron mediante un archivo .exe directamente personalizado con el número de serie del aparato, ahí si me interesa la parte del sniffer para intentar saber los cambios realizados, al menos tengo el .exe de mi placa. (Tema sniffer acepto recomendaciones.)

Pero nosotros tenemos un nivel extra se protección, y al transmitir y recibir datos en la comunicación ethernet ,también existe encriptación para evitar lo anterior, es decir evitar que mediante un sniffer se puede obtener los datos enviados y recibidos.

Sí, en la ethernet si tenemos una encriptación propia, pero en las comunicaciones por usb o rs232 ¿existe ese tipo de encriptación? yo diría que no pero me gustaría hacer el experimento.

Ya dispuestos a leer la conexión que se realiza por USB, ¿necesitaré un adaptador de nivel para interpretar los datos correctamente?
 
Muchas gracias!

[DominusDRR]

Sí, en la ethernet si tenemos una encriptación propia, pero en las comunicaciones por usb o rs232 ¿existe ese tipo de encriptación? yo diría que no pero me gustaría hacer el experimento.
 
Muchas gracias!

¿Por qué no podría existir?

Es un algoritmo que, podríamos decir que alteras a la trama que envías. En el microcontrolador, también podrías implementar un encriptador y desencriptador (sea por software o por hardware).

Ya depende del nivel de protección que desarrollador desee implementar a su código.

[DominusDRR]

En mi caso entonces el .hex no está encriptado porque si lo abro y es código, de todas formas entonces lo que yo te he entendido es que la protección es sobre lectura, pero no sobre escritura y voy a poder escribirlo. No puedo hacer las pruebas porque estoy esperando un pickit3 y una placa easypic donde podre hacer pruebas de lectura y escritura directas en el pic.

Si tienes el hexadecimal, no importa como esté el microcontrolador, es decir con CP activado o no.

Pero lo que podría ser es que tengas una parte o una tabla de datos y no necesariamente el código completo.

Por ejemplo, una parte de la memoria flash es el código principal, esa parte está protegida contra lectura externa de un programador (CP activado), mientras que otra región es utilizada para algún tipo de datos.

Ese es el hexadecimal que distribuyen y sólo sirve para actualizar esa región, nada más.

Ya con el microcontrolador a la mano y tu programador descubrirás si tienes el código fuente o sólo una parte.

[Eduardo Rodas]

DominusDRR como proteges tus firmware cuando están en la PC? porque las empresas de internet saben todo lo que tenemos en ella y también en los teléfonos. Yo programo los firmware para productos en una PC que no se conecta a internet.

[DominusDRR]

DominusDRR como proteges tus firmware cuando están en la PC? porque las empresas de internet saben todo lo que tenemos en ella y también en los teléfonos. Yo programo los firmware para productos en una PC que no se conecta a internet.

Bueno, si te pones en el plano que saben todo de ti, obviamente es posible que te extraigan la información, así tengas las mejores protecciones informáticas.

Yo trabaje en una empresa israelí, donde el control de la protección intelectual era muy alto, pero a la final podías llevarte el código fuente si deseabas.

Obviamente se pueden romper las seguridades, como el candado o la cerradura de una casa. La idea es darle un poco más de trabajo aquellos que roban la información que entregarles todo en bandeja de plata.

[remi04]

En estos casos donde las actualizaciones se distribuyen mediante ficheros hex no encriptados, si hay protección de lectura en el micro es por que hay un bootloader normalmente al final de la flash y hay un salto de línea al principio que apunta directo a este bootloader.

  Seguramente ese bootloader contenga datos importantes que necesita el programa, como constantes de control, valores de configuración, etc.

 El fichero hex que te envían normalmente solo puede ser cargado mediante el bootloader no siendo funcional si lo intentas cargar directamente vía icsp. He visto varios tipos de métodos que usan, y uno de ellos consistía en un cambio en el orden de las líneas hex. Aunque en el hex, están ordenadas las posiciones de memoria, realmente el boltloader no graba cada línea donde pone en el hex directamente, sino que va en otro sitio que conoce el bootloader (Tabla de cruces).

 Esto lo pude ver gracias a que en una aplicación, tuvieron la torpeza de no proteger las lecturas del bloque del bootloader ejecutadas desde otro bloque y además, vi que una parte del hex de actualización si que guardaba orden correcto y contenía código ejecutable.  Solo tuve que crear un programa muy sencillo que leía las posiciones flash del boltloader y sacaba sus valores por uart emulado y luego introducirlo en esa porción del hex actualizable y esperar a que el bootloader lo admitiese, y funcionó. Así obtuve el código del propio bootloader completo y por tanto pude ver lo que hacía y como trabajaba.

  Yo en mis proyectos uso siempre xtea o similares y con desencriptado interno en el micro.  Jamas se desencripta nada fuera.

[AnitaMalhereux]

El software que utiliza el usuario para actualizar el firmware de sus equipos posee la llave y cuando abre el archivo encriptado, obtienen el archivo hexadecimal original, pero este está en memoria RAM, no lo guardan en algún disco del PC.

Eso de abrir el hexadecimal y mantenerlo en la RAM, también no es seguro. Existe manera de analizar lo que contiene en la memoria RAM una aplicación que se está ejecutando en un PC. Y por ahí también te pueden robar tu trabajo.

[DominusDRR]

El software que utiliza el usuario para actualizar el firmware de sus equipos posee la llave y cuando abre el archivo encriptado, obtienen el archivo hexadecimal original, pero este está en memoria RAM, no lo guardan en algún disco del PC.

Eso de abrir el hexadecimal y mantenerlo en la RAM, también no es seguro. Existe manera de analizar lo que contiene en la memoria RAM una aplicación que se está ejecutando en un PC. Y por ahí también te pueden robar tu trabajo.

SI esto también se ha tomado en cuenta. No soy el desarrollador del software pero lo que me explicaron es que hay una manera de poner unas variables en la memoria RAM en diferentes regiones, no agrupado todo en una sola parte. Y esas regiones no son las mismas, cada vez que cargas otra vez el mismo hex, se coloca en otras regiones de manera aleatoria y de esa manera se intenta proteger de alguna manera el hexadecimal.

Claro que para grandes empresas esas protecciones son casi nulas, por ejemplo los chinos se que disuelven el encapsulado para acceder al silicio y ver que está programado dentro del microcontrolador.

No conozco si existe una manera efectiva de protegerse contra eso.

How to «open» microchip and what's inside? Z80, Multiclet, MSP430, PIC and more

https://zeptobars.com/en/read/open-microchip-asic-what-inside-II-msp430-pic-z80