¿Proteger el flash AVR de la lectura a través del ISP?

Estoy tratando de proteger todo el flash de la lectura a través de ISP. Tiene bootloader, capaz de auto programar la sección de aplicaciones.

Configuración del byte de bloqueo en:

LB1/LB2no permitirá que el usuario use el gestor de arranque para cargar nuevo firmware.

BLB12/BLB11y BLB01&BLB02no impedirá la lectura de flash a través de ISP, si no me equivoco.

Entonces, ¿no hay forma de permitir que el usuario actualice el firmware mediante un cargador de arranque personalizado y proteja el flash de la lectura al mismo tiempo?

Respuestas (2)

No especificó un chip, lo siguiente está orientado principalmente a los dispositivos atmega de 8 bits, pero es información general. ¡Lea la sección 'Programación de memoria' para la hoja de datos de su chip específico para obtener información más específica!

Dicho esto, y como dijiste, todos los dispositivos AVR contienen dos bits de bloqueo llamados LB1 y LB2. Programarlos (a 0, bajo) agregará protección a los contenidos escritos en las memorias Flash y EEPROM de acuerdo con la tabla a continuación. El nivel de protección se divide en tres modos, donde el modo 1 no ofrece protección y el modo 3 ofrece máxima protección. Es posible pasar a un modo de protección superior simplemente reprogramando los bits de bloqueo.

El AVR permite cambiar bits "altos" a "bajos", pero no al revés. No es posible cambiar un bit de bloqueo "bajo" a "alto", por lo que no es posible reducir el nivel de protección. Para borrar los bits de bloqueo, se requiere un borrado de chip completo, que borra la memoria Flash.

Tabla de bits de bloqueo AVR

¡Estos 2 bits de bloqueo solos (LB1 y LB2) cuando están bajos evitarán que el 99.9% de las personas roben su firmware! Probablemente más del 99,9%. Casi siempre sería más fácil aplicar ingeniería inversa a su código.

Entonces, ¿no hay forma de permitir que el usuario actualice el firmware mediante un cargador de arranque personalizado y proteja el flash de la lectura al mismo tiempo?

Que yo sepa (podría estar equivocado, pero creo que habría tenido problemas con esto antes) en los dispositivos que tienen los fusibles de protección del cargador de arranque (BLB12 y BLB11), puede bloquear su sección personalizada del cargador de arranque, deshabilitar SPI y ser protegido del 97-98% de las personas.

Sin embargo, cuando ninguno de los bits de bloqueo está programado, ¡no hay funciones de bloqueo de memoria habilitadas! La desactivación de ISP solo es suficiente para bloquear al 70% de las personas.

Para obtener información adicional, los bits de bloqueo y los fusibles no se encuentran en el espacio flash o EEPROM normal, ni son accesibles desde el software, a excepción de los bits de bloqueo relacionados con el cargador de arranque en dispositivos con la función de autoprogramación. La Tabla 2 en esta nota de la aplicación lo ayudará a identificar lo que puede hacer por su dispositivo en particular.

La línea AVR de Atmel no son dispositivos de alta seguridad (¡a menos que se indique explícitamente!) y, como tales, no vienen con ningún código de garantía de seguridad, ¡ni deberían hacerlo! Como todos los dispositivos no seguros (y lamentablemente incluso algunos seguros), ¡son propensos a ataques comunes!


Editar

Pondré el encabezado de la interfaz de programación HV a bordo. Pero, ¿alguien puede usar el programador HV para LEER flash? Sé que el programador HV puede hacer que el chip se borre incluso si ISP/Jtag están deshabilitados.

No creo que deba incluir el programador HV en el diseño de su placa a menos que sea absolutamente necesario y sepa con certeza que no causará problemas con nada. Los programadores HV (señales de 12 voltios) están disponibles solo como medida de seguridad para programar chips bloqueados (bloqueados por error, en su mayoría). En teoría, esto solo está destinado a programar el dispositivo, no leer nada. Y nunca he oído hablar de un exploit que permita la lectura.

Para actualizar el gestor de arranque (ocasionalmente), colocaré el encabezado de la interfaz de programación HV a bordo. Pero, ¿alguien puede usar el programador HV para LEER flash? Sé que el programador HV puede hacer que el chip se borre incluso si ISP/Jtag están deshabilitados.

Creo que puede haber una manera de actualizar el flash bloqueado a través del gestor de arranque (¿algo relacionado con un indicador de escritura interno y/o ISR tal vez?) Pero tendré que buscar mis notas y tal vez tenga que probarlo. No podré hacer esto por ~20 horas; por lo tanto, recomiendo hacer una nueva pregunta centrada solo en esto y para el procesador que mencionó. ¡Es una muy buena pregunta !

+1 para el último comentario, si todo lo demás falla, cualquier tipo puede simplemente desoldar el chip y pegarnos un depurador / programador AVR para restablecer los bits de bloqueo y su seguridad desaparecerá.
@Garrett Fogerlie: no estoy seguro de qué lo llevó a pensar que estoy tratando de robar el código, por favor hágamelo saber y corregiré mi pregunta para que otros no piensen de la misma manera. Estoy tratando de brindar una protección mínima a mi propio código, mi propio gestor de arranque. De todos modos, un par de preguntas más sobre esto. El chip es ATMega328, aunque la familia tendrá un uso común de bits de bloqueo. Ha explicado LB1y LB2, que también describí en mi pregunta como una opción limitante para usar el gestor de arranque con fines de actualización. Así que no es una opción. En cuanto a BLB12y BLB11- eso es lo que no entiendo. (continuará)
Establecer esos bits NO evitará que nadie lea el flash (aplicación + cargador de arranque) desde el exterior. Según la hoja de datos, parece que esos bits solo bloquearán los comandos LPM/SPM, pero el programador en serie no los está usando. En cuanto a Deshabilitar la programación en serie y jtag, esta es otra gran pregunta para mí. Para actualizar el gestor de arranque (ocasionalmente), colocaré el encabezado de la interfaz de programación HV a bordo. Pero, ¿alguien puede usar el programador HV para LEER flash? Sé que el programador HV puede hacer que el chip se borre incluso si ISP/Jtag están deshabilitados.
@pablo, lo siento, no quise ofender. Cuando vi su pregunta por primera vez, no se me ocurrió la idea del robo; y escribí una respuesta que estaba algo enfocada en recuperar el código bloqueado. Sin embargo, estaba en el trabajo y antes de enviar esa respuesta tuve una pausa de ~ 2 horas. Luego, cuando regresé, noté que todavía no había respuesta y me sorprendió un poco, luego, al volver a leer su pregunta, pensé que el "robo" podría haber sido el motivo. No es tu culpa en absoluto, ahora he eliminado el descargo de responsabilidad. Se necesitaba el modelo de procesador debido a las diferencias enumeradas en esa tabla y porque hay AVR de 8/16/32 bits...
@Pablo con respecto a sus preguntas, vea mi Edición al final de mi publicación.
@Pablo, por alguna razón, ¡mi edición en la parte inferior no se había publicado! Lo volví a agregar, lo siento.
ъGarrett Fogerlie: No quise poner el programador HV a bordo, solo el encabezado :) Pero descubrí que no es necesario porque los bits de bloqueo funcionaron y, en caso de que pueda usar el encabezado ISP para borrar el chip y reescribir todo el flash en el dispositivo. Entonces, para resumir la respuesta a mi pregunta original: configurar LB1 y LB2 evitará que alguien lea el área flash completa Y, al mismo tiempo, no me impedirá escribir la memoria del programa a través del cargador de arranque.
@Pablo Tener el pinout HV en la placa puede causar problemas a otros componentes de la placa, como un regulador de voltaje, etc. Además, ¿su pregunta resumida está respondida ahora? No puedo decirlo por lo que dijiste. De lo contrario, realmente recomiendo hacer una nueva detallada y dejar un enlace aquí para mí, o desmarcar esta como respondida y actualizar tu pregunta para que tu pregunta real sea más clara. Además, +1 No me di cuenta de que no había hecho eso, lo siento.

Puede usar los bits de bloqueo en algunos dispositivos ATMega y aún así actualizar su código con el gestor de arranque.

Programé LB1 y LB2 en un ATMega 328. Luego invoqué el cargador de arranque, actualicé el programa principal, todo funcionó perfectamente.

El ISP no puede leer ni escribir ningún flash / eeprom / fusibles, pero el cargador de arranque aún puede escribir la sección de la aplicación.

Un Chip Erase con el ISP borrará los bits de bloqueo (LB1 y LB2), pero también borrará todo el flash / eeprom, por lo que puede proteger su código (sin embargo, debe asegurarse de que su cargador de arranque no pueda ser pirateado)

¿Cómo mejora esto la respuesta actualmente aceptada?
Tenga en cuenta que, siempre que tenga un residente de cargador de arranque estándar de estilo Arduino, el bloqueo de la lectura sería casi inútil, ya que el cargador de arranque en sí tiene una capacidad de lectura, a menos que use el modo avanzado solo 328P que deshabilita el LPM del cargador de arranque en la memoria de la aplicación. De lo contrario, deberá modificar el gestor de arranque para eliminarlo, a costa de no poder verificar la programación. (Posiblemente podría crear un mecanismo de verificación diferente, pero no sería estándar y requeriría que también modifique/reemplace avrdude)