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/LB2
no permitirá que el usuario use el gestor de arranque para cargar nuevo firmware.
BLB12/BLB11
y BLB01&BLB02
no 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?
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.
¡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 !
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)
holamundo922
Pablo
LB1
yLB2
, 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 aBLB12
yBLB11
- eso es lo que no entiendo. (continuará)Pablo
garrett fogerlie
garrett fogerlie
garrett fogerlie
Pablo
garrett fogerlie