No has especificado un chip, lo siguiente está orientado principalmente a los dispositivos atmega de 8 bits, pero es información general. Lee la sección 'Programación de la memoria' de la hoja de datos de tu chip específico para obtener información más específica.
Dicho esto, y como has dicho, todos los dispositivos AVR contienen dos bits de bloqueo llamados LB1 y LB2. La programación de estos (a 0, bajo) añadirá protección a los contenidos escritos en las memorias Flash y EEPROM de acuerdo con la siguiente tabla. El nivel de protección se divide en tres modos, donde el modo 1 no ofrece ninguna 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 los 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 bajar el nivel de protección. Para borrar los bits de bloqueo, es necesario realizar un Chip Erase completo, que borre la memoria Flash.
Sólo estos dos bits de bloqueo (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 hacer ingeniería inversa de su código.
¿Entonces no hay manera de permitir al usuario actualizar el firmware por medio del bootloader personalizado y proteger la flash de la lectura al mismo tiempo?
Hasta donde yo sé (podría estar equivocado pero creo que ya habría tenido problemas con esto), en los dispositivos que tienen los fusibles de protección del bootloader (BLB12 y BLB11), se puede bloquear su gestor de arranque personalizado sección, desactivar el SPI y estar 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 sólo es suficiente para bloquear al 70% de las personas.
Para una información extra, los bits de bloqueo y los fusibles no se encuentran en el espacio normal de la flash o la EEPROM, ni son accesibles desde el software, excepto los bits de bloqueo relacionados con el cargador de arranque en los dispositivos con la función de autoprogramación. Tabla 2 en esta nota de la aplicación le ayudará a identificar lo que puede hacer para su dispositivo en particular.
La línea de AVRs de Atmel no son dispositivos de alta seguridad (a menos que se indique explícitamente) y como tal no vienen con ninguna garantía de seguridad de código, ¡ni deberían! Como todos los dispositivos no seguros (y tristemente incluso algunos seguros), son propensos a ataques comunes.
Editar
Pondré la cabecera de la interfaz de programación HV a bordo. Pero, ¿puede alguien usar el programador HV para LEER la flash? Sé que el programador HV puede hacer que el chip borrar incluso ISP / Jtag se desactivan.
No creo que debas incluir el programador HV en el diseño de tu placa a no ser que sea absolutamente necesario y sepas con seguridad que no va a causar problemas con nada. Los programadores HV (señales de 12 voltios,) están disponibles sólo como medida de seguridad para programar chips bloqueados (bloqueados por error, principalmente). En teoría esto es sólo se supone que es para programar el dispositivo, no para leer nada. Y nunca he oído hablar de un exploit que permita la lectura.
Para actualizar el cargador de arranque (ocasionalmente) pondré la interfaz de programación HV de programación HV en la placa. Pero, ¿puede alguien 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 deshabilitado.
Creo que hay puede ser una manera de actualizar la flash bloqueada a través de bootloader, (algo que ver con una bandera de escritura interna y / o ISR tal vez??) Pero voy a tener que buscar en mis notas y tal vez tener que probarlo. No podré hacerlo hasta dentro de unas 20 horas; por lo que recomiendo encarecidamente hacer una nueva pregunta centrado sólo en esto y para el procesador que has mencionado. Es una muy buena pregunta ¡!