www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie sicher ist der Code im ATmega?


Autor: AnGe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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é

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Mueller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: AnGe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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è

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

...

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: bootloader (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und wegen dem Pfusch, einfach einen Timer laufen lassen und alle 10ms
>'nen Reset :-P

Dafür gibt's doch extra den Watchdog...

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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?

Autor: Stefan Helmert (Firma: dm2sh) (stefan_helmert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tobias Korrmann (kurzschluss81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nehmt doch einen MSP430.

Nööö, der verträgt keine 5V.

...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tobias Korrmann (kurzschluss81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.