Necesito bloquear la lectura de mi mega328 flash pero poder escribir en la eeprom

Necesito poder evitar que otros copien mi programa colocado en la memoria flash, pero aún quiero poder escribir en la EEPROM.

Probé los bits de bloqueo configurándolos en Modo 3 (0x3C). Pero eso me impedirá escribir en la EEPROM.

¿Hay alguna forma de evitar leer el flash mientras se continúa escribiendo en la EEPROM?

¿Por qué querrías bloquear el flash pero seguir manipulando la EEPROM con un programador después? Este es un flujo de "producción" poco común.
Haga que el código arranque en un modo de programador eeprom configurando un pin alto (o bajo).
¿Puede dar más detalles sobre el "modo de programador eeprom" que acaba de mencionar? Traté de googlearlo pero no pude encontrar mucho. Explique cómo puede ayudar en mi situación. Gracias.
Creo que la idea sería poner funcionalidad en su firmware para habilitar la "autoprogramación" de la EEPROM en respuesta a solicitudes externas. Incluso podría hacer que esto duplique una interfaz de programador en serie común, como lo hacen a menudo los cargadores de arranque para este chip, aunque para los detalles de su aplicación que se detallan a continuación, darle una interfaz más adaptada a "agregar tarjeta #" o "quitar tarjeta #" podría hacer más sentido.

Respuestas (3)

REF: https://electronics.stackexchange.com/a/53293

y especialmente: http://web.engr.oregonstate.edu/~traylor/ece473/lectures/fuses.pdf

Es posible establecer un "Modo no 2", también conocido como "Modo 1 xor 2", con LB1 como 1 y LB2 como 0.

implicación: una persona emprendedora debería poder usar la capacidad de programación implícita en el estado habilitado de LB1 para restablecer LB2 a 1

independientemente, al "sujetar" (escuchar cables) el flujo de datos parpadeantes (presumiblemente a través de un cable USB) los datos cargados se pueden ver (trivial y literalmente con un osciloscopio: una persona "podría leer" datos RS232 de esta manera para bajo (< <75) velocidades de transmisión y es el análogo visual de la capacidad auditiva para usar el código Morse, donde los remitentes podrían incluso identificarse por su "puño")

si, por lo tanto, estos datos cargados NO se descifran antes de flashear, entonces el cargador de arranque interno debe modificarse para descifrarlos, ... y si partes del cargador de arranque deben descifrarse mediante una clave cifrada en los datos de carga flash...

una clave externa secreta, contraseña, inicia el proceso anterior, por lo que un chip "frío" es inútil de lo contrario

esta técnica no evita la copia pero inhibe la usabilidad de la copia

si nada más, la ofuscación presenta un desafío no solo para el intruso sino también para el autor auténtico

No no hay. Considere agregar un I 2 C o SPI EEPROM/flash externo si necesita espacio de escritura externa mientras que el programa integrado no se puede leer. Esto no solo resolverá su problema inmediato, sino que también puede brindarle mucho más espacio para almacenar sus datos, ya sean proporcionados o generados.

"si necesita espacio de escritura mientras que el flash del programa integrado es ilegible": esto solo tiene sentido si se refiere a escribir EEPROM desde el código. Y eso es (obviamente) independiente de los bits de bloqueo. Sin embargo, es poco común querer bloquear el flash en primer lugar y seguir manipulando solo la EEPROM con un programador después.
Es muy común encontrarse con escenarios poco comunes :)
Tengo un programa que especificará qué tarjetas están autorizadas para acceder a una instalación. Los ID de la tarjeta se almacenan en la EEPROM, mientras que mi programa se almacena en la memoria flash. Proporcioné a mis usuarios una aplicación de escritorio para conectarse al IC y agregar/quitar tarjetas (por lo tanto, me gustaría poder escribir en la EEPROM), por otro lado, quiero proteger mi programa en el flash de copiar y replicarlo por los competidores. La idea de Ignacio tiene sentido, aunque esperaba una solución en la que no tenga que agregar nuevos componentes. Gracias
Es completamente posible satisfacer esta necesidad solo con almacenamiento interno, tratándolos como "datos" almacenados/escritos exclusivamente por el firmware en lugar de una operación de programador externo; no se necesita un chip externo a menos que se necesite espacio adicional.

Así es como lo resolví. Puede que no funcione para todos en mi situación, pero eso fue lo suficientemente bueno para mi necesidad. Como estoy restringido por el modo 3, decidí usar el modo 3 (evitar la lectura y escritura para flash y eeprom). Por lo tanto, proporcionaré mi programa + los datos a los clientes en un archivo cifrado que solo puede abrir mi aplicación de escritorio, que lo descifrará e implementará tanto el programa como los datos y los bloqueará nuevamente en el chip. El único inconveniente con esta solución es el tiempo que tomará cargar a flash y EEPROM (~40-45 segundos) mientras que cargar solo a EEPORM toma alrededor de 10 a 15 segundos. Por otro lado, esta solución tiene la ventaja adicional de permitir el envío de cualquier actualización de mi programa dentro de la misma operación.

Gracias por la sugerencia de todos. Puedo probarlos en el futuro cuando tenga tiempo para experimentar.

Solo tenga en cuenta que, a menos que su clave secreta esté almacenada en el microcontrolador en una ubicación segura e ilegible, es trivial obtener el firmware y los datos descifrados. ¡Espero que esto funcione bien para ti!
Esta no es una buena solución, es demasiado complicada y trivialmente derrotada.
Estoy de acuerdo, pero mi solución apunta principalmente a disuadir a otros de intentar copiar mi código en lugar de tener una seguridad muy estricta. Además, no estoy almacenando ninguna clave en mi MCU, estoy enviando a los clientes un archivo encriptado y mi aplicación de escritorio (que también está protegida por una conocida herramienta de protección de códigos) decodificará el archivo encriptado y lo cargará en la memoria flash. y EEPROM, luego vuelva a bloquear el chip. Nuevamente, solo quiero desalentar a los fisgones y no quiero que el programa del microcontrolador esté disponible fácilmente descargándolo de mi chip y copiándolo a otros chips para replicar mi esfuerzo. Gracias
Consideraría arrojar un montón de basura o código engañoso antes y después del descifrado al menos, y codificar el contenido de la RAM decodificada lo más rápido posible (nuevamente con código basura). Tan pronto como ocurra el descifrado, un hacker talentoso puede pausar la CPU, volcar la RAM y elegir la pepita de oro con bastante facilidad en estos días. Incluso he desarrollado cifrado/descifrado de hardware, pero eso también se frustró fácilmente por la misma razón. En pocas palabras, el hacker siempre está más decidido que el desarrollador.
Necesito bloquear la lectura de mi mega328 flash pero poder escribir en la eeprom
RespuestasAquíPolítica de privacidad1y, 1v