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


15

Estoy tratando de proteger todo el flash de la lectura a través de ISP. Cuenta con gestor de arranque, capaz de programar la sección de aplicación.

Establecer el byte de bloqueo en:

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

BLB12/BLB11y BLB01&BLB02no evitaré leer 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:


18

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. La programación de estos (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 la 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?

Hasta donde sé (podría estar equivocado, pero creo que habría tenido problemas con esto antes) en dispositivos que tienen fusibles de protección del cargador de arranque (BLB12 y BLB11), puede bloquear su sección de cargador de arranque personalizado , 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 del 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 normal de flash o EEPROM, 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 para 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 ninguna garantía de seguridad de código, 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 de HV para LEER el flash? Sé que el programador de HV puede borrar el chip incluso si el ISP / Jtag está deshabilitado.

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

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

Creo que puede haber una manera de actualizar el flash bloqueado a través del cargador de arranque (¿algo que tenga que ver con un indicador de escritura interno y / o ISR tal vez?) Pero tendré que buscar mis notas y tal vez deba probarlo. No podré hacer esto por ~ 20 horas; así que recomiendo hacer una nueva pregunta centrada solo en esto y para el procesador que mencionaste. ¡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á.
helloworld922

@Garrett Fogerlie: no estoy seguro de qué te hace pensar que estoy tratando de robar el código, házmelo saber y corregiré mi pregunta para que otros no piensen de la misma manera. Estoy tratando de dar una protección mínima de mi propio código, mi propio gestor de arranque. De todos modos, un par de preguntas más sobre esto. Chip es ATMega328, pensó que la familia tendrá un uso común de bits de bloqueo. Has explicado LB1y LB2, lo que también describí en mi pregunta como una opción limitante para usar el gestor de arranque con fines de actualización. Entonces no es una opción. En cuanto a BLB12y BLB11, eso es lo que no entiendo. (continuará)
Pablo

Establecer esos bits NO impedirá que nadie lea el flash (aplicación + cargador de arranque) desde el exterior. De la hoja de datos parece que esos bits simplemente bloquearán los comandos LPM / SPM, pero el programador en serie no lo está usando. En cuanto a la desactivación de la programación en serie y jtag, esta es otra gran pregunta para mí. Para actualizar el gestor de arranque (ocasionalmente) pondré el encabezado de la interfaz de programación HV a bordo. ¿Pero alguien puede usar el programador HV para LEER el flash? Sé que el programador de HV puede borrar el chip incluso si el ISP / Jtag está deshabilitado.
Pablo

@pablo, lo siento, no quise ofenderte. Cuando vi por primera vez su pregunta, la idea del robo no se me ocurrió; y escribí escribí una respuesta que se centró 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 volví, noté que todavía no había respuesta y me sorprendió un poco, luego, al releer su pregunta, pensé que el "robo" pudo haber sido el motivo. No es tu culpa en absoluto, ahora he eliminado el descargo de responsabilidad. El modelo de procesador era necesario debido a las diferencias enumeradas en esa tabla y porque hay AVR de
8/16/32

1
rettGarrett Fogerlie: no quise poner el programador de HV a bordo, solo el encabezado :) Pero descubrí que no es necesario porque los bits de bloqueo funcionaron y por si puedo usar el encabezado ISP para borrar el chip y volver a escribir todo el flash en el dispositivo. Entonces, para resumir la respuesta a mi pregunta original: configurar LB1 y LB2 evitará que alguien lea toda el área de flash Y, al mismo tiempo, no me impedirá escribir la memoria del programa a través del cargador de arranque.
Pablo

3

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

Programé LB1 y LB2 en un ATMega 328. Luego invoqué el gestor de arranque, actualicé el programa principal, todo funcionó a la perfección.

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

Un borrado de chip 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 gestor de arranque no pueda ser pirateado)


3
¿Cómo mejora esto la respuesta actualmente aceptada?
Ignacio Vazquez-Abrams

Tenga en cuenta que siempre que tenga un residente estándar del cargador de arranque de estilo Arduino, la lectura de bloqueo 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, tendría que modificar el gestor de arranque para eliminarlo, a costa de no poder verificar la programación. (Potencialmente podría crear un mecanismo de verificación diferente, pero sería no estándar que requiera que también modifique / reemplace avrdude)
Chris Stratton
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.