Ich muss das Lesen meines Mega328-Flash sperren, aber in der Lage sein, auf das Eeprom zu schreiben

Ich muss in der Lage sein zu verhindern, dass andere mein im Flash abgelegtes Programm kopieren, möchte aber trotzdem in der Lage sein, in das EEPROM zu schreiben.

Ich habe die Sperrbits ausprobiert, indem ich sie auf Modus 3 (0x3C) gesetzt habe. Aber das hindert mich daran, in das EEPROM zu schreiben.

Gibt es eine Möglichkeit, das Lesen des Flashs zu verhindern, während das Schreiben in das EEPROM weiterhin zulässig ist?

Warum sollten Sie den Flash sperren, aber danach das EEPROM mit einem Programmierer weiter manipulieren? Dies ist ein ungewöhnlicher "Produktionsfluss".
Lassen Sie den Code in einem Eeprom-Programmiermodus booten, indem Sie einen Pin hoch (oder niedrig) setzen.
Können Sie bitte näher auf den gerade erwähnten "EEPROM-Programmiermodus" eingehen? Ich habe versucht, es zu googlen, konnte aber nicht viel finden. Bitte erklären Sie, wie es in meiner Situation helfen kann. Danke
Ich glaube, die Idee wäre, Funktionalität in Ihre Firmware zu integrieren, um das EEPROM als Reaktion auf externe Anforderungen "selbst" zu programmieren. Sie könnten sogar eine gemeinsame serielle Programmierschnittstelle duplizieren, ähnlich wie Bootloader für diesen Chip dies häufig tun - obwohl für Ihre unten angegebenen Anwendungsdetails eine besser auf "Karte # hinzufügen" oder "Karte # entfernen" zugeschnittene Schnittstelle mehr bewirken könnte Sinn.

Antworten (3)

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

und insbesondere: http://web.engr.oregonstate.edu/~traylor/ece473/lectures/fuses.pdf

Es kann möglich sein, einen "Mode not 2" alias "Mode 1 xor 2" mit LB1 als 1 und LB2 als 0 einzustellen.

Implikation: Eine unternehmungslustige Person sollte in der Lage sein, die durch den aktivierten Status von LB1 implizierte Programmierfähigkeit zu verwenden, um LB2 auf 1 zurückzusetzen

Unabhängig davon, durch "Klemmen" (Abgreifen) des blinkenden Datenstroms (vermutlich über ein USB-Kabel) können die hochgeladenen Daten gesehen werden (trivial und buchstäblich mit einem Oszilloskop - eine Person könnte auf diese Weise RS232-Daten für niedrige (< <75) Baudraten und ist das visuelle Analogon zur akustischen Fähigkeit, Morsezeichen zu verwenden, bei denen Absender sogar an ihrer "Faust" identifiziert werden konnten)

wenn diese hochgeladenen Daten also vor dem Flashen NICHT entschlüsselt werden, dann muss der interne Bootloader modifiziert werden, um sie zu entschlüsseln, ... und wenn Teile des Bootloaders durch einen in den Flash-Upload-Daten verschlüsselten Schlüssel entschlüsselt werden müssen ...

Ein geheimer externer Schlüssel, ein Passwort, startet den obigen Prozess, sodass ein "kalter" Chip ansonsten nutzlos ist

diese Technik verhindert nicht das Kopieren, aber sie verhindert die Verwendbarkeit der Kopie

Nicht zuletzt stellt die Verschleierung nicht nur den Eindringling, sondern auch den authentischen Autor vor eine Herausforderung

Nein, da ist kein. Erwägen Sie das Hinzufügen eines externen I 2 C- oder SPI-EEPROM/Flash, wenn Sie extern beschreibbaren Speicherplatz benötigen, während der integrierte Programm-Flash nicht lesbar ist. Dies löst nicht nur Ihr unmittelbares Problem, sondern bietet Ihnen auch viel mehr Platz zum Speichern Ihrer gelieferten oder generierten Daten.

"Wenn Sie beschreibbaren Speicherplatz benötigen, während der Flash des integrierten Programms nicht lesbar ist": Dies ist nur sinnvoll, wenn Sie sich auf das Schreiben von EEPROM aus Code beziehen. Und das ist (offensichtlich) unabhängig von den Lockbits. Allerdings ist es eher unüblich, den Flash erst einmal sperren zu wollen und danach immer nur das EEPROM mit einem Programmierer zu manipulieren.
Es ist sehr üblich, auf ungewöhnliche Szenarien zu stoßen :)
Ich habe ein Programm, das angibt, welche Karten berechtigt sind, auf eine Einrichtung zuzugreifen. Die Karten-IDs werden im EEPROM gespeichert, während mein Programm im Flash gespeichert wird. Ich habe meinen Benutzern eine Desktop-Anwendung zur Verfügung gestellt, um eine Verbindung zum IC herzustellen und Karten hinzuzufügen / zu entfernen (daher möchte ich in das EEPROM schreiben können), andererseits möchte ich mein Programm auf dem Flash vor dem Kopieren schützen und Nachahmung durch Wettbewerber. Ignacios Idee macht Sinn, obwohl ich auf eine Lösung gehofft hatte, bei der ich keine neuen Komponenten hinzufügen muss. Danke
Es ist durchaus möglich, diesen Bedarf nur mit internem Speicher zu decken, indem er als „Daten“ behandelt wird, die ausschließlich von der Firmware gespeichert/geschrieben werden und nicht von einem externen Programmiervorgang – es ist kein externer Chip erforderlich, es sei denn, es wird zusätzlicher Speicherplatz benötigt.

Hier ist, wie ich es gelöst habe. Es funktioniert vielleicht nicht für jeden in meiner Situation, aber das war gut genug für meine Bedürfnisse. Da ich durch Modus 3 eingeschränkt bin, habe ich mich für Modus 3 entschieden (Lesen und Schreiben für Flash und Eeprom verhindern). Daher werde ich den Kunden mein Programm + die Daten in einer verschlüsselten Datei zur Verfügung stellen, die nur von meiner Desktop-Anwendung geöffnet werden kann, die sie entschlüsselt und sowohl das Programm als auch die Daten bereitstellt und sie wieder auf dem Chip sperrt. Der einzige Nachteil bei dieser Lösung ist die Zeit, die zum Hochladen auf Flash und EEPROM benötigt wird (~40-45 Sekunden), während das Hochladen auf das EEPORM allein etwa 10 bis 15 Sekunden dauert. Andererseits hat diese Lösung den zusätzlichen Vorteil, dass sie die Übermittlung von Aktualisierungen an mein Programm innerhalb derselben Operation ermöglicht.

Danke für jeden Vorschlag. Ich werde sie vielleicht in Zukunft ausprobieren, wenn ich Zeit zum Experimentieren habe.

Denken Sie nur daran, dass es trivial ist, die entschlüsselte Firmware und Daten zu erhalten, es sei denn, Ihr geheimer Schlüssel ist auf dem Mikrocontroller an einem sicheren, nicht lesbaren Ort gespeichert. Ich hoffe, das funktioniert gut für Sie!
Dies ist einfach keine gute Lösung - es ist zu kompliziert und trivial besiegt.
Ich stimme zu, aber meine Lösung zielt hauptsächlich darauf ab, andere davon abzuhalten, meinen Code zu kopieren, anstatt eine sehr strenge Sicherheit zu haben. Außerdem speichere ich keinen Schlüssel auf meiner MCU, ich sende den Kunden eine verschlüsselte Datei und meine Desktop-Anwendung (die auch durch ein bekanntes Codeschutztool geschützt ist) entschlüsselt die verschlüsselte Datei und lädt sie in den Flash hoch und EEPROM, dann verriegeln Sie den Chip erneut. Auch hier möchte ich Schnüffler nur entmutigen und ich möchte nicht, dass das Mikrocontroller-Programm leicht verfügbar ist, indem ich es einfach von meinem Chip herunterlade und es auf andere Chips kopiere, um meine Bemühungen zu replizieren. Danke
Ich würde in Betracht ziehen, zumindest vor und nach der Entschlüsselung einen Haufen Müll oder irreführenden Code einzuwerfen und den Inhalt des dekodierten RAM so schnell wie möglich zu verschlüsseln (wieder mit Müllcode). Sobald die Entschlüsselung erfolgt, ein talentierter Hacker kann die CPU anhalten, den Arbeitsspeicher leeren und das Goldnugget heutzutage ziemlich einfach heraussuchen. Ich habe sogar eine Hardware-Verschlüsselung/-Entschlüsselung entwickelt, aber das wurde aus dem gleichen Grund auch leicht vereitelt. Unterm Strich ist der Hacker immer entschlossener als der Entwickler.
Ich muss das Lesen meines Mega328-Flash sperren, aber in der Lage sein, auf das Eeprom zu schreiben
AntwortenHierDatenschutz-Bestimmungen1y, 0v