Sichern von Code auf einem AVR/Arduino und Bereitstellen von Updates

  1. Was ist der beste Weg, Code, der auf ein AVR-basiertes Gerät geflasht wird, vor Reverse Engineering zu schützen?
  2. Was ist eine einfache Möglichkeit, Endbenutzern Aktualisierungen bereitzustellen, damit sie selbst flashen können, ohne den Code offenzulegen? (Ist es mit einem Bootloader, der ein verschlüsseltes Image entschlüsselt?)

Beschuldigen Sie mich nicht, weil ich DRM befürworte, ich bin für offene Plattformen – ich bin nur neugierig, wie das funktionieren würde.

Nicht. Es gibt KEINE MÖGLICHKEIT , die Möglichkeit eines Reverse Engineering Ihrer Hardware/Software durch eine böswillige Person vollständig zu verhindern. Alles, was Anti-RE-Maßnahmen bewirken, ist, dass die Umkehrung länger dauert.

Antworten (3)

Erste:

Auf dem Chip befinden sich Sicherungen, die eingestellt werden können, um zu verhindern, dass externe Tools den Code vom Chip lesen. Suchen Sie in Ihrem Datenblatt und/oder der Programmiererdokumentation nach den Schutzsicherungen.

Es ist nicht perfekt, aber es schützt Sie vor einfachen Angriffen.

Zweite:

Sie können die Firmware nicht sicher herunterladen. Der AVR kann geschützte Bereiche nicht selbst programmieren:

http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf

Das Beste, was Sie tun können, ist, eine verschlüsselte Token-Sprache (wie Basic oder Forth) zu verwenden und den Interpreter auf dem Chip mit einem Bootloader zu schützen, der die verschlüsselten Token in einen offenen Bereich programmieren kann. Beim Ausführen würde der Chip die Anweisungen im laufenden Betrieb entschlüsseln und ausführen.

Wenn Sicherungen nicht perfekt sind, welche Art von Angriff kann sie umgehen?
@Anonym - Chemisches Wegätzen der Abdeckung des Chips und Verwenden von Elektronenmikroskopen, Lasern und Mikrosonden zum Anzeigen, Verbinden und Bearbeiten des Siliziums. Kostet mindestens 500 US-Dollar, kann aber billiger sein als die Arbeit, die stbra in das Gerät investiert.
@KevinVermeer Meinten Sie 500 Dollar? Es scheint mir, dass es viel teurer sein würde.
Adam, es ist ein Fehler aufgetreten, also habe ich meinen Kommentar gelöscht

Wenn es so wichtig ist und Sie sich besonders Sorgen darüber machen, dass Konkurrenten Ihren Code stehlen könnten, nehmen Sie IP-Schutz für Ihre Codesegmente vor. Sie sollten sich damit befassen, wenn Sie sowieso versuchen, mit einem Projekt Geld zu verdienen.

Bestimmte Codeelemente können entweder patentiert (für bestimmte Verarbeitungsmethoden und neuartige Algorithmen) oder als Industriedesigns (das Aussehen, Layout und die Anwendung Ihres Codes auf einem Gerät) registriert werden. Vielleicht möchten Sie diesbezüglich einen IP-Anwalt konsultieren.

Wenn Sie Ihren eigenen Bootloader geschrieben haben, der verschlüsselte Daten über die serielle Schnittstelle akzeptiert, entschlüsselt und im Codespeicherbereich gespeichert hat, könnten Sie ein sicheres Code-Firmware-Update haben. Jedes Gerät könnte sogar seinen eigenen eindeutigen Entschlüsselungsschlüssel in Ihrem benutzerdefinierten Bootloader haben.

Ich denke, was @Adam Davis sagt, ist, dass Sie, wenn Sie einen Bootloader verwenden (sogar einen, den Sie geschrieben haben), keine Sperrbit-geschützten Bereiche programmieren können. Wenn Sie also Ihren eigenen verschlüsselten Bootloader geschrieben haben, konnten Sie nicht verhindern, dass der Chip gelesen wird (Problem 1). Das scheint jedenfalls das zu sein, was ich aus dem Link und dem Datenblatt bekomme.
Wenn der Bootloader und der Code verschlüsselt sind, würde es das zweite Problem lösen, das erste Problem ist fast gelöst, wenn er eine ausreichend sichere Verschlüsselung verwendet. (Die Geschwindigkeit von uC kann ein Flaschenhals sein).
WAHR. @Adam Davis hat oben eine verschlüsselte Token-Sprache vorgeschlagen.
Sichern von Code auf einem AVR/Arduino und Bereitstellen von Updates
AntwortenHierDatenschutz-Bestimmungen1y, 0v