Wie sicher ist der Code im ATmega?

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...

...

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?

> Nehmt doch einen MSP430.

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

...

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?

> 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.