Firmware-Schutz für AVR- und PIC-Controller


23

Kann jemand die HEX-Datei extrahieren, die ich in einem von mir bereitgestellten Mikrocontroller brenne?

Wenn dies möglich ist, wie kann jemand sicherstellen, dass sein Code in eingebetteten Systemen gesichert ist? Wie kann man bei PIC- und AVR-Mikrocontrollern die Firmware vor Vervielfältigung schützen?



1
In Fall 1 scheinen Sie vorzuschlagen, dass Sie Ihren Clients die Hex-Datei zur Verfügung stellen. In diesem Fall können sie sie einfach auf mehrere Klon-Geräte schreiben, ohne dass der Code dekompiliert werden muss, obwohl dies möglich ist. Bei einem gesperrten Gerät (# 2) hängt es normalerweise davon ab, wie entschlossen sie sind, den Code zu erhalten (mit anderen Worten, wie viel sie bereit sind, auszugeben), aber es ist normalerweise möglich.
alexan_e

1
Früher waren es zwei Jahre, aber der Schutz ist heutzutage bei gängigen Geräten im Durchschnitt in ein oder zwei Tagen gescheitert. Im Grunde genommen, wenn jemand entschieden hat, dass es sich lohnt, dies zu tun. Wenn Sie wirklich Sicherheit wollen, die Sie brauchen, um in das Chip-Geschäft einzusteigen, werden Sie keine kommerziellen Teile von der Stange bekommen.
old_timer

Antworten:


33

Die meisten Mikrocontroller verfügen heutzutage über teil- oder herstellerspezifische Methoden zum Schutz des eingebetteten Firmware-Codes. Dies erfolgt im Allgemeinen durch Sperren der Schaltkreise, die normalerweise das Auslesen des Codespeichers ermöglichen. (Sie müssen nach teilespezifischen Details im Datenblatt oder auf der Website des Herstellers in den entsprechenden Anwendungshinweisen suchen.)

Einmal gesperrt ist es nicht möglich, den Codespeicher mit normalen Techniken auszulesen. Dies bietet einen angemessenen Schutz, um die meisten Hacker davon abzuhalten, den Computercode für Ihre eingebettete Anwendung anzuzeigen.

Viele MCU-Geräte verfügen heutzutage über einen integrierten FLASH-Speicher zum Speichern des Programmcodes. Ein zuvor in FLASH gespeichertes und geschütztes Programm kann normalerweise durch neuen Code ersetzt werden. Zum Entsperren des Schutzmechanismus ist jedoch ein vollständiger FLASH-Löschvorgang erforderlich. Nach dem Löschen funktioniert das Teil wie vor dem ursprünglichen Schutzschloss. Wenn ein neues Programm geladen wird, ist es im Allgemeinen möglich, das Teil erneut zu sperren, um den neu geladenen Maschinencode zu schützen.

Eine Diskussion des Codeschutzes in Mikrocontrollern wäre nicht vollständig, ohne zu erwähnen, dass es normalerweise keine Garantie dafür gibt, dass ein vom Teilehersteller angebotenes Schutzschema narrensicher ist. Die Hersteller werden sogar angeben, dass die Schutzsysteme nicht 100% narrensicher sind. Einer der Gründe dafür ist, dass es eine ganze Schwarzmarktbranche gibt, in der fleißige Hacker gegen eine Gebühr Code aus einem geschützten Teil vorlesen, damit jeder bezahlen kann. Sie haben verschiedene Schemata entwickelt, mit denen der Code auf geschützten Mikrocontrollern aus den ROMs oder FLASHs gelesen werden kann. Einige dieser Programme sind unglaublich clever, erzielen jedoch in einigen Teilfamilien einen besseren Erfolg als in anderen. Seien Sie sich dieser Tatsache bewusst, dann versuchen Sie, Ihr Programm vor neugierigen Blicken zu schützen.

Hat jemand das Binärbild des Maschinencodes, der aus einem Mikrocontroller ausgelesen wurde, in der Hand, unabhängig davon, ob es sich um einen geschützten Mikrocontroller handelt, kann er den Maschinencode mit einem Tool namens Disassembler verarbeiten. Dadurch werden die Binärdaten wieder in Assembler-Code umgewandelt, der untersucht werden kann, um zu erfahren, wie die Algorithmen Ihres Programms funktionieren. Das genaue Zerlegen von Maschinencode ist eine mühsame Aufgabe, die sehr viel Arbeit kosten kann. Am Ende kann der Prozess zu dem Assembler-Code führen, den ich beschrieben habe. Wenn Ihr Programm in einer höheren Programmiersprache wie C, C ++ oder Basic geschrieben wurde, stellt der Assembler-Code nur das kompilierte und verknüpfte Ergebnis Ihres Programms dar. Es ist im Allgemeinen nicht möglich, gestohlenen Code vollständig auf das höhere Sprachniveau zurückzuentwickeln.

Dies bedeutet, dass es tatsächlich von Vorteil ist, die Firmware Ihrer eingebetteten Anwendung in einer höheren Sprache zu schreiben. Es bietet eine weitere Ebene, die die vollständige Rückentwicklung Ihres Programms erschwert. Ein noch größerer Vorteil ist die Verwendung des neuesten Standes der Technik bei der Optimierung von Compilern für die Kompilierung der eingebetteten Anwendung, da die leistungsstärksten Optimierer das Programm buchstäblich in eine riesige Spaghetti-Schüssel verwandeln können, die Dutzende von Aufrufen für kurze, sehr schwierige Subroutinen enthält in einem Disassembler entschlüsseln.

Die meisten erfahrenen Embedded-Entwickler werden Sie auffordern, alle in Ihrer Anwendung auf der MCU angebotenen Schutzschemata zu verwenden, ohne sich bis zum Ende des Produktlebens davon abhängig zu machen. Sie werden Ihnen sagen, dass der beste Weg, um der Konkurrenz einen Schritt voraus zu sein, darin besteht, Ihr Produkt ständig zu aktualisieren, damit die alten Versionen veraltet und uninteressant sind, wenn Hacker Ihren Code geklont haben. Ändern Sie den Code, fügen Sie neue Funktionen hinzu, drehen Sie Ihre PC-Karten von Zeit zu Zeit, um alle Ihre E / As und alle anderen Dinge, die Ihnen in den Sinn kommen, zu tauschen. Auf diese Weise können Sie das Rennen jedes Mal gewinnen.


Vielen Dank @Michael Karas Das war eine vollständige Antwort
Rookie91

12

Ich denke, Michaels Antwort ist genug für diese Frage, aber ich füge diese beiden Links hinzu: Hacking the PIC 18F1320 und alles, was sie machen, können wir brechen! Diese beiden waren für mich sehr interessant.


Der sorgfältige EE sollte diesen letzten Link untersuchen und nach Geräten suchen / vergleichen / suchen, die in der Liste fehlen . Komplexität ist immer abschreckender - wie das Hinzufügen eines DS3641 oder ATSHA204 . Obwohl keine zusätzliche Sicherheit jemals zu 100% unzerbrechlich sein wird, könnte die zusätzliche Komplexität dazu führen, dass sich dies nicht lohnt.
Rdtsc
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.