Hallo Leser, es gibt ja die Mögkichkeit im ATmega die Fuses so zu setzen das man ihn nicht mehr auslesen oder verifizieren kann. Nun habe ich eben die Seite hier gefunden: http://www.chip-explorer.de Da wird davon gesprochen das es doch möglich ist. Wie ernst ist das zu nehmen? Ist das bei denen nur erfolgreich wenn die Fuses falsch geschrieben wurden oder gibt es doch Hintertürchen? Das stellt den Schutz natürlich in Frage. Gruß André
Wenn jemand absolut und unbedingt an den Maschinencode ran will, ätzt er im Zweifelsfall das Gehäuse des Chips weg und ließt den Speicher unterm Elektronenmikroskop aus oder flickt die Fuses. Manche Chips haben aber auch Designfehler oder Bugs. Bei manchen PIC kann man durch geschicktes Rumwackeln an einigen Pins die Sperre auch umgehen.
Hallo, die Sicherheit ist für den "normalen" Benutzer gegeben, wenn allerdings das Programm interessant und/oder teuer genug ist ist das mit genug Aufwand durchaus möglich. Lohnt sich aber nur für wirklich hochpreisige Sachen da das benötigte Equipment teilweise sehr teuer ist... Stefan
Danke für die Antworten. Ja mein Programm wird sicher nicht so "wertvoll" sein, aber mich interessiert ob es wirklich einen Weg gibt an die Informationen heran zu kommen. Ich denke mal das man maximal den Maschinencode bekommen kann, denn dann wieder in ASM wandeln und dann noch zu verstehen dürfte nicht so einfach sein. Jeder Programmer "tickt" ja auch etwas anders. Aber übberascht bin ich denoch das sowas funktionieren soll... ;-) Gruß Andrè
> es gibt ja die Mögkichkeit im ATmega die Fuses so zu setzen das man ihn > nicht mehr auslesen oder verifizieren kann. Es sind nicht die Fusebits, sondern die Lockbits... Es gibt immer einen Weg, es ist nur eine Frage des Aufwandes und somit des Preises. Die meisten Controller werden nicht deshalb geschützt, weil das darin befindliche Programm sooooo genial ist, sondern damit keiner den Pfusch sehen kann. ;-) Ausnahmen bestätigen die Regel... ...
Hannes Lux wrote: > Die meisten Controller werden nicht deshalb geschützt, weil das darin > befindliche Programm sooooo genial ist, sondern damit keiner den Pfusch > sehen kann. ;-) > sehr gut :D
Wenn's wirklich "sicher" sein soll ist ein Bootloader mit AES o.ä. am sinnvollsten, dann müßte schon Hardware debuggt werden, um an die Funktionen zu kommen. Stellt sich halt die Frage, ob der Speicher reicht und auch die Geschwindigkeit. Und wegen dem Pfusch, einfach einen Timer laufen lassen und alle 10ms 'nen Reset :-P duckundwech
>Und wegen dem Pfusch, einfach einen Timer laufen lassen und alle 10ms >'nen Reset :-P Dafür gibt's doch extra den Watchdog...
>> Wenn's wirklich "sicher" sein soll ist ein Bootloader mit AES o.ä. am >> sinnvollsten, dann müßte schon Hardware debuggt werden, um an die >> Funktionen zu kommen. Ach? Und der BL schreibt den Code nicht in den Flash? Wohin denn dann?
Warum nicht einfach einen Selbstzerstörungsmechanismus in den Chip bauen (Gehäuse aus Plastiksprengstoff), wenn man einen Manipulationsversuch startet, explodiert das Ding und zerbricht die darunter montierte Ampulle mit Pest-Erregern?
Nehmt doch einen MSP430. Wenn bei dem die Fuse durchgebrannt wurde kann man nicht mehr per JTAG auf den Chip zu greifen also auch keinen Code mehr rauf laden. Das mit dem Durchbrennen der Fuse ist auch irreversible also nicht zu umgehen.
Tobias Korrmann wrote: > Nehmt doch einen MSP430. Wenn bei dem die Fuse durchgebrannt wurde kann > man nicht mehr per JTAG auf den Chip zu greifen also auch keinen Code > mehr rauf laden. Das mit dem Durchbrennen der Fuse ist auch irreversible > also nicht zu umgehen. Hat der kein Gehäuse aus Plastik, das man mit genug krimineller Energie spielend leicht wegätzen kann?
Hannes Lux wrote:
> Nööö, der verträgt keine 5V.
Meines Wissens hat die neue MSP430F5xx Familie einen LDO intern sodass
sie auch mir 5V klar kommen sollten zu mindestens was die
Versorgungsspannung angeht.
> Ja mein Programm wird sicher nicht so "wertvoll" sein, aber mich > interessiert ob es wirklich einen Weg gibt an die Informationen heran zu > kommen. Ich denke mal das man maximal den Maschinencode bekommen kann, > denn dann wieder in ASM wandeln und dann noch zu verstehen dürfte nicht > so einfach sein. Jeder Programmer "tickt" ja auch etwas anders. Disassemblieren einer Binärdatei ist nur eine Frage der richtigen Kommandozeilenoption für avr-objdump. Datenbereiche in der Binärdatei lassen sich leicht identifizieren, wenn man sich den Assemblercode anschaut. Das Umsetzen in Pseudocode ist eine leichte Übung für den erfahrenen Programmierer. So groß sind in der Regel µC-Programme ja nicht, als daß man da wochenlang dran sitzen würde. Das bietet dir ein versierter Schüler zu erstaunlich günstigen Stundensätzen an. Der wird dann nebenher noch die Bugs des Original-Programmierers rauskorrigieren. Inklusive Brief an den Originalprogrammierer, in welcher C-Quelltextzeile er den Buffer-Overflow prüfen soll :-) Vom Pseudocode wieder zu einem compilierbaren C-Quelltext zu kommen, naja... Für die Preise vom o.g. Dienstleister wird mit Sicherheit nicht Hand an die Hardware angelegt, wie Freilegen und Kontaktieren der Fuses. Da wird wahrscheinlich ein gut verschwiegener Bug ausgenutzt. Es gibt ja Berichte, daß mit genau definierter Unterspannung, Überspannung oder sonst im Grenzbereich der Betriebsbedingungen, manchmal auch durch eine geschickte Reset-Folge, die Fuses mitunter nicht funktionieren.
Na, es gibt auch richtige Disassembler (z.B. IDA Pro), die können anhand der angesprungenen Adressen sogar Unterroutinen ausmachen und den Codewurm als Flussdiagramm darstellen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.