Atmega8-16PU und Co Fremdcode kopieren decompilieren?

[D a v i d K. (oekel)]

Hi,

ich stelle mir gerade aus der Not heraus die obige Frage.

Aber zuerst etwas zur "Not", damit ich mir nicht unnötig viel Arbeit 
mache, da ich Mal wieder den Wald vor lauter Bäumen übersehe.

Habe hier eine Platine der Eigenmarke Thomans (Stariville) liegen. (zu 
99% Made in China dennoch gesockelter IC)

Geschichte (nebensächlich):
Vor einiger Zeit wollte ich die "schlechte" Firmware selber neu 
schreiben, um die EXTREM günstige Hardware um einen Master-Dimmer 
softwareseitig zu erweitern.

Das Problem:
Kurz um, der Atmega liegt sammt zwei weiterer baugleicher Chips neben 
der Platine und ich weiß nun nicht mehr, welcher der originale war. 
(Möchte auch ungern einfach einstecken und ausprobieren)

Lösungsansatz:
Alle Atmegas in den Prgrammer und die Fusebits sowie den Hexcode 
ausgelsen.
LOW Fuse: 11111111
High Fuse: 11001111
Lockbits: 11111111
Bei einem ist die HEX in etwa 10kb bei den anderen überaschenderweise 
12kb.
Ich hatte eigentlich erwartet, dass alle bis auf einen Chip leer 
(Auslieferungsstand) sind.

Die eigentliche Frage(n):
1. Wenn ich mir die Bedeutung der Fuses so anschaue (und mich nicht 
täusche?) dann kann ich doch beliebige Kopien von diesem erzeugen, oder 
nicht?
1.1 Wenn mämlich keiner der hier rumfliegenden ICs der original sein 
solle, wollte ich mir einen weiteren Satz Hardware kaufen und davon die 
Firmware übernehmen/überschreiben.
2. Gibt es anständige C-Decompiler (Stichwort: "reverse engineering") so 
dass ich mit etwas Glück erkennen kann welches der originale IC/Code 
war? (und dann später auch optimaler neuschreiben kann?)
2.1 Dass dabei Kommentarzeilen nicht mehr auftauchen, ist mir schon klar 
;)
Jedoch sollte man bei 10kb doch noch durchsteigen können?

Was meint ihr? Zu 2. wären mir Links sowie PMs jeglicher Art recht..

Grüße Oekel

[Peter R. (peterfido)]

Wozu decompilieren?

Wenn ich es richtig verstanden habe, dann hast Du 3 gleiche uC mit 
unterschiedlichen Programmen, welche sich aber auslesen lassen.

Nun willst Du einen 4. kaufen, um die Originalsoftware auszulesen, da Du 
Angst hast, dass irgendwas Schaden nehmen könnte, wenn Du einfach die 
Software der vorhandenen an der Hardware ausprobierst.

Also 4. kaufen und dann die Software auslesen. Entweder anschließend 
binär vergleichen (Macht normal die Programmer Soft auch) oder gleich 
die Version von Chip Nr. 4 auf die anderen 3 kopieren. Setzt aber die 
gleiche Hardware voraus. Evtl. gibt es unterschiedliche Revisionen der 
Platine.

Decompilieren geht normal nicht. AVR Studio sollte Dir aber den ASM Code 
anzeigen können.

Wurde auch in ASM programmiert, ist die Wahrscheinlichkeit durch den 
Code durchzusteigen größer. War es eine Hochsprache werden Dich die 
tausenden Sprünge nahe der Verzweiflung bringen.

Hast Du die Hardware verstanden, kannst Du da schneller komplett neu 
programmieren.

[D a v i d K. (oekel)]

Peter R. schrieb:
> Wozu decompilieren?
...
> Decompilieren geht normal nicht. AVR Studio sollte Dir aber den ASM Code
> anzeigen können.
ok
...
> Hast Du die Hardware verstanden, kannst Du da schneller komplett neu
> programmieren.

Das war der Einzige Ansatz. Ich wollte zumindest die IOs "erkennen", was 
ja bei ASM Code möglich sein sollte. (Damit ich beim Neuschreiben auch 
sicher keinen in irgendeiner mittleren Leiterbahn vergesse; "unsichtig")

Ansonsten habe ich mir das fast gedacht, obwohl man ja viel von Leuten 
hört, die das ständig zu machen scheinen. Allerdings wohl eher nicht bei 
uC sonden bei x86 Architekturen.

Eine letzte Frage zu diesem Thema. Ist das Lockbit (ISP deaktivieren) 
die einzige Möglichkeit einen AVR bzw. dessen Code zu schützen?
Und was passiert genau, wenn man ihn dennoch ausließt? (Habt bei eigenen 
Chips nie getestet und möchte dies eigentlich auch nicht ;)

Grüße Oekel

[Karl H. (kbuchegg)]

D a v i d K. schrieb:

> Das war der Einzige Ansatz. Ich wollte zumindest die IOs "erkennen", was
> ja bei ASM Code möglich sein sollte. (Damit ich beim Neuschreiben auch
> sicher keinen in irgendeiner mittleren Leiterbahn vergesse; "unsichtig")

Das wird auch möglich sein. Der Aufwand ist trotzdem nicht zu 
unterschätzen.

> Ansonsten habe ich mir das fast gedacht, obwohl man ja viel von Leuten
> hört, die das ständig zu machen scheinen.

Das es gar nicht geht, wird wohl keiner behaupten. Nur ist das schon 
fast sowas wie 'die Königsklasse'. Um ein fremdes Programm aus dem 
Hex-Code zu rekonstruieren muss man schon ziemlich gut sein. Man könnte 
es so ausdrücken: Wenn du danach fragen musst, bist du nicht gut genug 
:-)

Klar: Denen wurde das auch nicht in die Wiege gelegt, sondern sie haben 
gelernt. Im Regelfall aber von der umgekehrten Seite. Erst mal Assembler 
Programmieren gelernt. Dann einen Haufen Tricks und Finten. Irgendwann 
wurden dann schon mal kleinere Abschntte aus dem Hex-Code rückübersetzt. 
Am Anfang mal die die man vorher selbst assembliert hat. etc. etc. Kurz 
und gut: die Leute sind da reingewachsen.

Allerdings: Wie gesagt. Wie reden hier von der Königsklasse. Wenn du in 
absehbarer Zeit ein brauchbares Eregbnis haben willst, dann vergiss es. 
Das lernt sich nicht von heute auf morgen.

> Eine letzte Frage zu diesem Thema. Ist das Lockbit (ISP deaktivieren)
> die einzige Möglichkeit einen AVR bzw. dessen Code zu schützen?

reicht doch.

> Und was passiert genau, wenn man ihn dennoch ausließt? (Habt bei eigenen
> Chips nie getestet und möchte dies eigentlich auch nicht ;)

was denkst du, was passieren könnte?
(Ne. Im Ernst. Überleg dir mal welche Möglichkeiten es gibt und welche 
die Wahrscheinlichste ist. Was ist das Ziel? Das Ziel ist es, den Code 
nicht aus dem AVR rauszurücken. Das Ziel ist es nicht, dabei den µC zu 
beschädigen)

[Peter D. (peda)]

Vermutlich wird der original-Chip gelockt sein. Das kann der Programmaer 
aber nicht erkennen, er liest dann einfach Mumpitz aus dem MC aus.
In der Regel sind das aufsteigende Bytes (= low-Adresse). Kann man im 
Hex-File leicht erkennen.

[Peter D. (peda)]

D a v i d K. schrieb:
> Ist das Lockbit (ISP deaktivieren)

Das sind 2 völlig verschiedenen Sachen.

[Michael M. (technikus)]

D a v i d K. schrieb:
> Eine letzte Frage zu diesem Thema. Ist das Lockbit (ISP deaktivieren)
> die einzige Möglichkeit einen AVR bzw. dessen Code zu schützen?
> Und was passiert genau, wenn man ihn dennoch ausließt? (Habt bei eigenen
> Chips nie getestet und möchte dies eigentlich auch nicht ;)

Die Lockbits deaktivieren ISP nicht, sie verhindern lediglich gewisse 
ISP-Aktionen. Auch mit gesetzten Lockbits kannst Du trotzdem das Flash 
auslesen, allerdings kommt dabei nur Unsinn raus. Ein AVR wird durch 
Setzen der Lockbits nicht endgültig gesperrt. Ein kompletter Chiperase 
und schon ist er wieder in jungfräulichem Zustand. Der ursprünglich 
geschützte Flash-Inhalt ist dabei natürlich weg.
Thema ISP deaktivieren:
Mit SPIEN = Bit 5 der Hi-Fuse kann man die serielle Programmierung über 
den SPI sperren. Das ist aber kein Schutz, weil die parallele 
High-Voltage Programmierung immer noch geht.

Ach ja:
Einen C-Decompiler gibt es nicht, wo sollte der auch seine Informationen 
hernehmen? Einen ASM-Quelltext bekommt man, der kann allerdings ziemlich 
mühsam zu lesen sein.

Servus
Michael