Hallo Leute, ich hab eine CPU (ATTiny13) die mit einem Programm bespielt wird. Dieses File, also das Programm was die CPU bekommt, ist ein Hex File. Ich muss in dieses Hex File reinschauen, damit ich den Komunikationsweg dahinter nachvollziehen kann, um den Test zu konzipieren. Ist es möglich dieses HexFile zu konvertieren, sodass dort Codezeilen stehen? Ich hab das mit Notepad++ probiert, aber wenn ich den Konverter einschalte, stehen da lauter Binärzahlen. Wenn das so sein soll, dann bitte ich um eine Beschreibung, wie ich von da aus weiter machen kann. Ich kann euch das Programm leider nicht hier anhängen, da dies Kundeneigentum ist. ICh danke für die Hilfe und wünsche eine angenehme Restwoche. LG
Moin, in dem Hex-File stehen die s.g. Opcodes, Adressen und Werte. Mit dem Datenblatt der CPU kannst du die nachvollziehen. Zumindest in der Theorie. Nimm einen Disassembler, der macht dir aus dem HEX ein List File und du hast Assembler Code. Aber keine Labels... Das ganze ist aber mehr als ein abendfüllendes Projekt.
Beitrag "Re: Anfängerfrage Atmel ausgelesenes .hex in .asm umwandeln" oder das hex-File ins Atmel Studio laden. Deine Frage lässt aber vermuten, daß das dein Problem nicht löst. Oliver
"Aus einem Hex-File wieder Sourcecode zu machen, ist so, als wolle man aus einem Burger wieder eine Kuh basteln" C-Code bekommst du so leicht da nicht wieder raus. Das einzige, was geht, ist ein Disassembly, mit dem du am Ende Assembler erhälst. Wenn der Code nicht soo komplex ist oder die Funktion sehr gut bekannt ist, dann kann man damit arbeiten. Aber z.B. Labels haben keine Namen, wodurch Funktionen von "Funktionen" nicht unbedingt immer klar sein können.
Tobias A. schrieb: > Ist es möglich dieses HexFile zu konvertieren, sodass dort Codezeilen > stehen? In welcher Programmiersprache? > Ist es möglich dieses HexFile zu konvertieren, sodass dort Codezeilen > stehen? Kannst du aus einem Kuchen wieder Eier und Mehl machen? Siehe z.B. dort: https://www.mikrocontroller.net/search?query=kuchen+eier+mehl&forums%5B%5D=1 > Ich hab das mit Notepad++ probiert, aber wenn ich den Konverter > einschalte, stehen da lauter Binärzahlen. Ein Hex-File ist normalerweise ein Textfile, da muss man nichts konvertieren, das kann man "einfach" lesen, wenn man den Assemblerdialekt des µC "beherrscht". > Wenn das so sein soll, dann bitte ich um eine Beschreibung, > wie ich von da aus weiter machen kann. Mit deinem Wissensstand musst du dich zuallererst in den Maschinencode des entsprechenden µC einarbeiten und kannst dann das Hex-File in einem Disassembler geben und erhältst einen Assemblercode mit nichtssagenden Sprungmarken und magischen Zahlen. Und dann gehts nur mit richtigem Expertenwissen weiter. Aber das ist beim Reverse-Engineering immer so...
:
Bearbeitet durch Moderator
Tobias A. schrieb: > Ist es möglich dieses HexFile zu konvertieren, sodass dort Codezeilen > stehen? > Ich hab das mit Notepad++ probiert, aber wenn ich den Konverter > einschalte, stehen da lauter Binärzahlen. Wenn das so sein soll, dann > bitte ich um eine Beschreibung, wie ich von da aus weiter machen kann. > > Ich kann euch das Programm leider nicht hier anhängen, da dies > Kundeneigentum ist. Wer würde DICH für sowas bezahlen? Du hast offensichtlich keine Ahnung vom Disassemblieren. Das ist was für Leute die sich auskennen. Und wie kann es sein dass du für ein aktives Kundenprojekt keinen Quellcode hast?
:
Bearbeitet durch User
Welchen Test? Wenn ich Testabläfe generieren muss, schau ich auf der Schnittstelle, wo die Kommunikation stattfindet. Frag doch mal deinen Kunden, ob der Dir die Kommunikation aufzeigt... Ich hab hier auch n paar schwieirge Fälle, wo ich auch "von hinten durch die Brust ins Auge". Manchmal ists Doof, geb ich Dir ja Recht. Aber im Hex-File nach Kommunikationsprotokollen zu suchen, um daraus Testabläufe generieren zu wollen? Wenn Du das können könntest, würdest du an einer anderen Stelle im Unternehmen arbeiten. Ich auch. Kannst Du dich, wenn der Kunde dazu nicht weiter sagen kann oder will ,nicht direkt auf die Schnittstelle 'schalten' und dort mitschreiben? Tiny13 klingt ja nun nicht nach "übelst-mega-kompliziert". edit: "an einer ANDEREN Stelle" ergänzt
:
Bearbeitet durch User
Cyblord -. schrieb: > Tobias A. schrieb: >> Ist es möglich dieses HexFile zu konvertieren, sodass dort Codezeilen >> stehen? >> Ich hab das mit Notepad++ probiert, aber wenn ich den Konverter >> einschalte, stehen da lauter Binärzahlen. Wenn das so sein soll, dann >> bitte ich um eine Beschreibung, wie ich von da aus weiter machen kann. >> >> Ich kann euch das Programm leider nicht hier anhängen, da dies >> Kundeneigentum ist. > > Wer würde DICH für sowas bezahlen? Du hast offensichtlich keine Ahnung > vom Disassemblieren. Das ist was für Leute die sich auskennen. > > Und wie kann es sein dass du für ein aktives Kundenprojekt keinen > Quellcode hast? Pass mal auf wie du mit Leuten hier im Forum sprichst. Wenn ich Ahnung von HexFiles hätte, dann hätte ich wohl auch keinen Forumsbeitrag geöffnet. Wenn du keine konstruktiven Hinweise hast, bitte ich dich aus diesem Beitrag zurück zu halten. Danke schön.
Tobias A. schrieb: > Ich hab das mit Notepad++ probiert, aber wenn ich den Konverter > einschalte, stehen da lauter Binärzahlen. Wenn das so sein soll, dann > bitte ich um eine Beschreibung, wie ich von da aus weiter machen kann. Lerne alle Maschinenbefehle und hoffe, dass Du dann mehr lesen kannst oder horche die Schnittstelle ab. 8-) https://www.elektronik-labor.de/AVR/KursAssembler/T13asm13.html
Tobias A. schrieb: > Ich hab das mit Notepad++ probiert D.h. Du hast von AVR-Assembler auch nicht die allerkleinste Ahnung, dann wird das nix. Du mußt mindestens mal ein "Hallo Welt" in Assembler geschrieben und simuliert haben. Der ATtiny13 faßt nur max 512 Assemblerzeilen, ist also für einen Wissenden zu schaffen, aber eben nicht für Dich.
Tobias A. schrieb: > Pass mal auf wie du mit Leuten hier im Forum sprichst. Man soll reden was wahr ist, Bübli. Und das tue ich. > Wenn ich Ahnung > von HexFiles hätte, dann hätte ich wohl auch keinen Forumsbeitrag > geöffnet. Richtig. Aber warum sollte dich jemand für so was bezahlen wenn du keine Ahnung hast? Es geht ja nicht um das Wissen um Hexfiles. Wie ein Hexfile aufgebaut ist, kannst du dir in 10 Minuten auf Wikipedia durchlesen. Für das Disassemblieren brauchst du ohnehin das binary. Aber das kannst du lustig hin- und her konvertieren. Aber dann fängt der Spaß halt erst an. Du kannst als Vorübung mal aus Hackfleisch versuchen eine Kuh zu bauen. Allerdings, allein dein Versuch, direkt im Hexfile was ändern zu wollen, mit Notepad, und dein ständiges rumreiten auf dem Hexfile, bestärkt mich darin dass du wirklich so gar keine Sonne bei dem Thema siehst. Zappenduster. > Wenn du keine konstruktiven Hinweise hast, bitte ich dich aus diesem > Beitrag zurück zu halten. Habe konstruktive Hinweise. Lass es. Lass das jemand machen der sich auskennt. > Danke schön. Sehr gerne. Ich helfe wo ich kann.
:
Bearbeitet durch User
Ok Leute, danke für die Hinweise. Ich werde das mal mit einem Dissambler probieren. Assembler Code hatte ich im Studium, daher werde ich mal schauen, was ich da hinbekomme. Für diejenigen, die das mit dem Kommunikationsweg nicht ganz nachvollziehen: Die Baugruppe kommuniziert über Manchestercode. Und die Daten, die mittels diesem Code übertragen werden sind nicht 1 zu 1 Binär codiert, sondern über eine Norm. Nur weiß der Kunde nicht genau, was da unter der Haube abläuft, weil der Kunde die Entwicklung extern durchführen lassen hat und das Entwicklungsbüro gibt es nun nicht mehr. Also muss ich mittels Reverseengineering deren Auswertehard- und -software nach bauen. Und dazu muss ich unter die Haube schauen. Ich danke allen die kosnturktive Hinweise gegeben haben und wünsche einen angenhemen Tag. MFG
Tobias A. schrieb: > damit ich den Komunikationsweg > dahinter nachvollziehen kann, um den Test zu konzipieren. > > Ich kann euch das Programm leider nicht hier anhängen, da dies > Kundeneigentum ist. Wenn euer Kunde will, dass ihr das testet, warum gibt er euch dann keine Spec für diese Kommunikation? Schreib doch in die Auftragsbestätigung, dass du mangels spezifischer Vorgaben einfach die statischen Pegel an der Schnittstelle misst und protokollierst. Tobias A. schrieb: > Nur weiß der Kunde nicht genau, was da unter der Haube abläuft, weil der > Kunde die Entwicklung extern durchführen lassen hat Du hast keine Spec zur Kommunikation, weil der, der sich hat das Zeug entwicklen lassen seinerseits keine Spec vom Entwickler bekommen hat? Sachen gibts... Tobias A. schrieb: > dann hätte ich wohl auch keinen Forumsbeitrag geöffnet. Naja, du hättest auch mal im Forum suchen können... https://cse.google.de/cse?cx=partner-pub-1202612203358489%3Ajaffbdxotov&ie=UTF-8&q=aus+hexfile+c+code+machen&sa=Suche > Pass mal auf wie du mit Leuten hier im Forum sprichst. Ja, das passiert halt, wenn man unbedarft und unvorbereitet in der Öffentlichkeit eine Frage stellt. Das sollte man dann aber auch abkönnen...
:
Bearbeitet durch Moderator
> Wie ein Hexfile aufgebaut > ist, kannst du dir in 10 Minuten auf Wikipedia durchlesen. Nachdem er weiss ob es Intel-Hex oder Motorola-S-Record ist. :-D > Wenn du keine konstruktiven Hinweise hast, bitte ich dich aus diesem > Beitrag zurück zu halten. YMMD Glaub uns einfach, das was du willst ist nicht moeglich, und das du es nicht einsiehst zeigt einen erschreckenden Mangel an wissen. Olaf
Cyblord -. schrieb: > Tobias A. schrieb: > >> Pass mal auf wie du mit Leuten hier im Forum sprichst. > > Man soll reden was wahr ist, Bübli. Und das tue ich. > >> Wenn ich Ahnung >> von HexFiles hätte, dann hätte ich wohl auch keinen Forumsbeitrag >> geöffnet. > > Richtig. Aber warum sollte dich jemand für so was bezahlen wenn du keine > Ahnung hast? > Es geht ja nicht um das Wissen um Hexfiles. Wie ein Hexfile aufgebaut > ist, kannst du dir in 10 Minuten auf Wikipedia durchlesen. > Für das Disassemblieren brauchst du ohnehin das binary. Aber das kannst > du lustig hin- und her konvertieren. > Aber dann fängt der Spaß halt erst an. Du kannst als Vorübung mal aus > Hackfleisch versuchen eine Kuh zu bauen. > > Allerdings, allein dein Versuch, direkt im Hexfile was ändern zu wollen, > mit Notepad, und dein ständiges rumreiten auf dem Hexfile, bestärkt mich > darin dass du wirklich so gar keine Sonne bei dem Thema siehst. > Zappenduster. > >> Wenn du keine konstruktiven Hinweise hast, bitte ich dich aus diesem >> Beitrag zurück zu halten. > > Habe konstruktive Hinweise. Lass es. Lass das jemand machen der sich > auskennt. > >> Danke schön. > Sehr gerne. Ich helfe wo ich kann. Du hast keine Ahnung vom Projekt und welcher Rattenschwanz da hinter hängt. Also komm mal von deinem hohen Ross runter. Wenn es jmd geben würde, der sich damit auskennt hätte ich nicht euch gefragt sondern den. Also spar dir deine Klugscheissersprüche. Verdammter Schwa******
Tobias A. schrieb: > Ich werde das mal mit einem Dissambler probieren. > Assembler Code hatte ich im Studium, daher werde ich mal schauen, was > ich da hinbekomme. Bist du irgendwo angestellt? Als angestellter Entwickler wäre es spätestens jetzt deine Aufgabe, dem Chef zu erklären wie umfangreich das ganze wird. Spoiler: Sehr umfangreich. Der Chef muss ja die Kosten kalkulieren und entscheiden ob er den Auftrag überhaupt annimmt. Und hat er selbst kein Fachwissen, müsstest du (jetzt wär es gut du hättest das Fachwissen gell) hier einspringen. Es kann teuer und unangenehm werden, wenn man den Umfang eines solchen Projekts von Anfang an dramatisch falsch einschätzt und evt. lustig Zusagen macht. Oder machst du das privat nebenbei? Oder bist du gar selbständig?
:
Bearbeitet durch User
Peter D. schrieb: > Der ATtiny13 faßt nur max 512 Assemblerzeilen, ist also für einen > Wissenden zu schaffen, aber eben nicht für Dich. Falsch. Wie kommst du auf Zeilen? Hat 1KB Flash. Das ist aber machbar.
Cyblord -. schrieb: > Tobias A. schrieb: >> Ich werde das mal mit einem Dissambler probieren. >> Assembler Code hatte ich im Studium, daher werde ich mal schauen, was >> ich da hinbekomme. > > Bist du irgendwo angestellt? Als angestellter Entwickler wäre es > spätestens jetzt deine Aufgabe, dem Chef zu erklären wie umfangreich das > ganze wird. Spoiler: Sehr umfangreich. Der Chef muss ja die Kosten > kalkulieren und entscheiden ob er den Auftrag überhaupt annimmt. Und hat > er selbst kein Fachwissen, müsstest du (jetzt wär es gut du hättest das > Fachwissen gell) hier einspringen. > Es kann teuer und unangenehm werden, wenn man den Umfang eines solchen > Projekts von Anfang an dramatisch falsch einschätzt und evt. lustig > Zusagen macht. > > Oder machst du das privat nebenbei? Oder bist du gar selbständig? Angestellt. Das Projekt liegt schon seit Jahren bei uns. Nur kam erst jetzt der Rest bei uns an (darunter auch das Progrmm vom Kunden). Angebote und KOsten sind schon durch. Dh ich muss das hinbekommen. Nen anderen Weg gibts nicht.
Peter D. schrieb: > Der ATtiny13 faßt nur max 512 Assemblerzeilen, ist also für einen > Wissenden zu schaffen, aber eben nicht für Dich. Zumindest wird der direkt in Assembler programmiert worden sein, nicht in C. Das macht es dann wieder etwas einfacher. Oliver
Tobias A. schrieb: > spar dir deine Klugscheissersprüche. Hui, arg kurze Zündschnur? Tobias A. schrieb: > Du hast keine Ahnung vom Projekt und welcher Rattenschwanz da hinter hängt. Eigentlich klar. Du hast ja auch noch nichts dazu erzählt. Aber wenn das so ein riesen Projekt ist, dann weißt du jetzt, dass da ein Spezi ran muss, wenn das in absehbarer Zeit fertig werden muss. Tobias A. schrieb: > Angebote und KOsten sind schon durch. Dh ich muss das hinbekommen. > Nen anderen Weg gibts nicht. Dann musst du uns mehr erzählen oder noch einiges lernen.
:
Bearbeitet durch Moderator
Tobias A. schrieb: > Angestellt. Das Projekt liegt schon seit Jahren bei uns. Nur kam erst > jetzt der Rest bei uns an (darunter auch das Progrmm vom Kunden). > Angebote und KOsten sind schon durch. Dh ich muss das hinbekommen. > Nen anderen Weg gibts nicht. Dann ist das Kind ja schon in den Brunnen gefallen. Da du die Aufgabe nicht lösen wirst, solltest du Zeit jetzt aufwenden um dich abzusichern. Ich hoffe du hast bei der Angebotserstellung nicht mitgewirkt und dem Chef sowas gesagt wie: "Ach das haben wir in 2 Stunden erledigt"!? Jetzt würde ich anfangen, E-Mails zu löschen und Dokumente kreativ zu verändern um meinen Hintern da rauszuhalten. Viel Glück!
Tobias A. schrieb: > Und dazu muss ich unter die Haube schauen. Zeig doch einfach mal ein Oszibild mit einem Kommunikationspaket/Telegramm und sag, was da drin übertragen worden sein sollte. Vielleicht erkennt hier wer, was das für eine "Norm" ist...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Tobias A. schrieb: >> Und dazu muss ich unter die Haube schauen. > Dann zeig doch einfach mal ein Telegramm und sag, was da drin übertragen > worden sein sollte. In der Tat, bei allem was wir hier wissen, scheint es einfacher die Kommunikation zu analysieren, als den Code. > Hui, arg kurze Zündschnur? Da scheint mächtig Druck auf dem Kessel zu sein. Alt wird man so auch nicht.
:
Bearbeitet durch User
Tobias A. schrieb: > Angebote und KOsten sind schon durch. Dh ich muss das hinbekommen. Verlass die Firma so schnell wie möglich. An so einem anspruchsvollen Reengeneering zu arbeiten ohne jede Qualifikation kann nur übel enden, nicht nur für die Firma sondern auch für dich persönlich. Ein Berufswechsel wäre auch nicht schlecht. Georg
Tobias A. schrieb: > Ok Leute, danke für die Hinweise. > > Ich werde das mal mit einem Dissambler probieren. > Assembler Code hatte ich im Studium, daher werde ich mal schauen, was > ich da hinbekomme. > Jemand hat studiert .. und dann solche Fragen? Ein Studierter sollte wissen, wie er Wikipedia zu Hex-Files befragt, und sich nicht solche Blößen hier geben. Ist eigentlich schon Freitag heute?
Tobias A. schrieb: > Also spar dir deine Klugscheissersprüche. > > Verdammter Schwa****** Klingt irgendwie als hätte da jemand viel Stress und steht mit dem Rücken zur Wand. Kleiner Tipp, mit solchen Äusserungen kommst du hier nicht weit. Du willst was vom Forum, nicht umgekehrt. Also versuche sachlich und kooperativ und nicht dünnhäutig zu sein. Der Ton hier ist manchmal rauh aber es gilt fast immer: "Wie man in den Wald hineinruft ..." Und je mehr Infos du bringst, desto eher kann man dir helfen. Viel Erfolg
Tobias A. schrieb: > Nur weiß der Kunde nicht genau, was da unter der Haube abläuft, weil der > Kunde die Entwicklung extern durchführen lassen hat und das > Entwicklungsbüro gibt es nun nicht mehr. Der Kunde hat sich also über den Tisch ziehen lassen und vergessen, daß zu einer Entwicklung auch eine vollständige Dokumentation gehört. Kann jedem mal passieren, ist uns auch einmal passiert. Dann heißt es Lehrgeld zahlen, d.h. die Fremdentwicklung wurde komplett in die Tonne gekloppt und neu im Haus gestartet, diesmal mit allen notwendigen Dokumentationen. Hat dann letztendlich sogar Geld gespart, da über die Jahre viele Erweiterungen notwendig wurden, die dann ohne hohe externe Kosten direkt implementiert werden konnten.
Und der Attiny13 hat immer noch nur 1kB Flash. Wer sagt, daß da drin überhaupt irgend eine großartige Auswertung oder Umwandlung der Daten stattfindet? Vielleicht steckt der für das Problem entscheidende Code ganz woanders. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Zumindest wird der direkt in Assembler programmiert worden sein, nicht > in C. Das macht es dann wieder etwas einfacher. Ich hab keine Hemmungen, auch einen ATtiny13 in C zu programmieren. C ist auch nicht schwerer zu disassemblieren, im Gegenteil. Assemblerprogrammierer machen gerne Schweinereien, die nur schwer zu durchschauen sind, Compiler gehen dagegen sehr systematisch vor.
Tobias A. schrieb: > Angebote und KOsten sind schon durch. Dh ich muss das hinbekommen. > Nen anderen Weg gibts nicht. Tobias, es gibt leider auch Sachen, wo mit dem Wissen der Zweifel wächst! Es gab aber auch schon pfiffige Studenten, die hatten nur Zettel, Bleistift und eine Befehlstabelle und haben 14 Tagen 8k Betriebssystem auseinandergenommen. Wenn ich heute diese Aufgabe hätte würde ich sie an Profis verweisen oder mindestens einige ähnliche Lösungen ansehen um hinter das Funktionsprinzip zu kommen.
Das Hexfile zu disassemblieren und einen ordentlich formatierten Assemblercode erzeugen ist bei 1 KB max ja überschaubar. Sowas ist in 1h erledigt inc Tests ob ein erzeugtes Binary dem Original entspricht. Das ist aber erst der Anfang. Das Problem fängt dann aber erst an. Wenn du nicht sattelfest in AVR Assembler bist, bist du mit der Analyse des Quellcodes überfordert. Sowas ist übrigens eine nette Übung um sich in Assembler einzuarbeiten. Das braucht dann aber Zeit. Noch komplizierter wird es wenn du ein Protokoll rauslesen willst.
:
Bearbeitet durch User
> Das Problem fängt dann aber erst an. Wenn du nicht sattelfest in AVR > Assembler bist, bist du mit der Analyse des Quellcodes überfordert. Erinnert ihr euch? Früher hatten wir da ja immer eine DIN-A4 Seite mit allen Memnoncs drauf da man ja nie mehr als die wichtigsten Befehle auswendig weiss. Leider hab ich sowas nur fuer MCS48, 51 und 68k, hat nicht jemand sowas fuer AVR? Muss es doch da garantiert auch gegeben haben. Olaf
Olaf schrieb: > hat nicht jemand sowas fuer AVR? Muss es doch da garantiert auch gegeben > haben. Datenblatt, dazu doc0856.pdf. Oliver
Sebastian R. schrieb: > Das einzige, was geht, ist ein Disassembly, mit dem du am Ende Assembler > erhälst. Schön wär´s. Da ist vorher noch ein bisschen Handarbeit angesagt. Dem Disassembler wird man erstmal sagen müssen, an welchen Datentabellen er sich vergeblich die Zähne ausbeißt.
Vielleicht hilft ja ein triviales Beispiel weiter was man mit einem Tool wie IDA Pro oder Ghidra bekommt. Das C-Code Beispiel stammt von einem anderem Post im Forum und läßt eine LED blinken. Die HEX Datei ist angehängt.
1 | #include <avr/io.h> // AVR Register und Konstantendefinitionen |
2 | #define F_CPU 1000000 // Taktfrequenz des µC |
3 | #include <util/delay.h> // Bibliothek mit Warteroutinen |
4 | |
5 | |
6 | int main(void) |
7 | {
|
8 | DDRB = 0b0000001; // Pin PB0 wird als Ausgang definiert, alle anderen Pins von PortB sind Eingänge |
9 | while (1) |
10 | {
|
11 | PORTB = 0b00000001; // PB0 = High |
12 | _delay_ms(500); |
13 | PORTB = 0b00000000; // PB5 = Low |
14 | _delay_ms(500); |
15 | } |
16 | } |
Mit IDA Pro bekommt man das hier, "main()" wurde von mir bereits mit Namen versehen. Außerdem sind die automatischen Kommentare aktiviert um einen kurzen Hinweis auf den Assemblerbefehl zu bekommen.
1 | ; Processor : AVR [ATmega168P] |
2 | ; Target assembler: AVR Assembler |
3 | |
4 | ; =========================================================================== |
5 | |
6 | ; Segment type: Pure code |
7 | .CSEG ; ROM |
8 | .org 0 |
9 | |
10 | ; =============== S U B R O U T I N E ======================================= |
11 | |
12 | ; Attributes: thunk |
13 | |
14 | sub_0: ; CODE XREF: sub_3Ej |
15 | jmp reset ; Jump |
16 | ; End of function sub_0 |
17 | |
18 | ; --------------------------------------------------------------------------- |
19 | .org 2 |
20 | jmp sub_3E ; Jump |
21 | ; --------------------------------------------------------------------------- |
22 | .org 4 |
23 | jmp sub_3E ; Jump |
24 | ; --------------------------------------------------------------------------- |
25 | .org 6 |
26 | jmp sub_3E ; Jump |
27 | ; --------------------------------------------------------------------------- |
28 | .org 8 |
29 | jmp sub_3E ; Jump |
30 | ; --------------------------------------------------------------------------- |
31 | .org 0xA |
32 | jmp sub_3E ; Jump |
33 | ; --------------------------------------------------------------------------- |
34 | .org 0xC |
35 | jmp sub_3E ; Jump |
36 | ; --------------------------------------------------------------------------- |
37 | .org 0xE |
38 | jmp sub_3E ; Jump |
39 | ; --------------------------------------------------------------------------- |
40 | .org 0x10 |
41 | jmp sub_3E ; Jump |
42 | ; --------------------------------------------------------------------------- |
43 | .org 0x12 |
44 | jmp sub_3E ; Jump |
45 | ; --------------------------------------------------------------------------- |
46 | .org 0x14 |
47 | jmp sub_3E ; Jump |
48 | ; --------------------------------------------------------------------------- |
49 | .org 0x16 |
50 | jmp sub_3E ; Jump |
51 | ; --------------------------------------------------------------------------- |
52 | .org 0x18 |
53 | jmp sub_3E ; Jump |
54 | ; --------------------------------------------------------------------------- |
55 | .org 0x1A |
56 | jmp sub_3E ; Jump |
57 | ; --------------------------------------------------------------------------- |
58 | .org 0x1C |
59 | jmp sub_3E ; Jump |
60 | ; --------------------------------------------------------------------------- |
61 | .org 0x1E |
62 | jmp sub_3E ; Jump |
63 | ; --------------------------------------------------------------------------- |
64 | .org 0x20 |
65 | jmp sub_3E ; Jump |
66 | ; --------------------------------------------------------------------------- |
67 | .org 0x22 |
68 | jmp sub_3E ; Jump |
69 | ; --------------------------------------------------------------------------- |
70 | .org 0x24 |
71 | jmp sub_3E ; Jump |
72 | ; --------------------------------------------------------------------------- |
73 | .org 0x26 |
74 | jmp sub_3E ; Jump |
75 | ; --------------------------------------------------------------------------- |
76 | .org 0x28 |
77 | jmp sub_3E ; Jump |
78 | ; --------------------------------------------------------------------------- |
79 | .org 0x2A |
80 | jmp sub_3E ; Jump |
81 | ; --------------------------------------------------------------------------- |
82 | .org 0x2C |
83 | jmp sub_3E ; Jump |
84 | ; --------------------------------------------------------------------------- |
85 | jmp sub_3E ; Jump |
86 | ; --------------------------------------------------------------------------- |
87 | jmp sub_3E ; Jump |
88 | ; --------------------------------------------------------------------------- |
89 | jmp sub_3E ; Jump |
90 | |
91 | ; =============== S U B R O U T I N E ======================================= |
92 | |
93 | |
94 | ; public reset |
95 | reset: ; CODE XREF: sub_0j |
96 | clr r1 ; Clear Register |
97 | out SREG, r1 ; Out Port |
98 | ser r28 ; Set Register |
99 | ldi r29, 4 ; Load Immediate |
100 | out SPH, r29 ; Out Port |
101 | out SPL, r28 ; Out Port |
102 | call _main ; Call Subroutine |
103 | jmp sub_57 ; Jump |
104 | ; End of function reset |
105 | |
106 | |
107 | ; =============== S U B R O U T I N E ======================================= |
108 | |
109 | ; Attributes: thunk |
110 | |
111 | ; public sub_3E |
112 | sub_3E: ; CODE XREF: ROM:0002j ROM:0004j ... |
113 | jmp sub_0 ; Jump |
114 | ; End of function sub_3E |
115 | |
116 | |
117 | ; =============== S U B R O U T I N E ======================================= |
118 | |
119 | |
120 | _main: ; CODE XREF: reset+6p |
121 | ldi r24, 1 ; Load Immediate |
122 | out DDRB, r24 ; Out Port |
123 | |
124 | loc_42: ; CODE XREF: _main+16j |
125 | out PORTB, r24 ; Out Port |
126 | ldi r18, 0x9F ; 'Ÿ' ; Load Immediate |
127 | ldi r19, 0x86 ; '†' ; Load Immediate |
128 | ldi r25, 1 ; Load Immediate |
129 | |
130 | loc_46: ; CODE XREF: _main+9j |
131 | subi r18, 1 ; Subtract Immediate |
132 | sbci r19, 0 ; Subtract Immediate with Carry |
133 | sbci r25, 0 ; Subtract Immediate with Carry |
134 | brne loc_46 ; Branch if Not Equal |
135 | rjmp loc_4B ; Relative Jump |
136 | ; --------------------------------------------------------------------------- |
137 | |
138 | loc_4B: ; CODE XREF: _main+Aj |
139 | nop ; No Operation |
140 | out PORTB, r1 ; Out Port |
141 | ldi r18, 0x9F ; 'Ÿ' ; Load Immediate |
142 | ldi r19, 0x86 ; '†' ; Load Immediate |
143 | ldi r25, 1 ; Load Immediate |
144 | |
145 | loc_50: ; CODE XREF: _main+13j |
146 | subi r18, 1 ; Subtract Immediate |
147 | sbci r19, 0 ; Subtract Immediate with Carry |
148 | sbci r25, 0 ; Subtract Immediate with Carry |
149 | brne loc_50 ; Branch if Not Equal |
150 | rjmp loc_55 ; Relative Jump |
151 | ; --------------------------------------------------------------------------- |
152 | |
153 | loc_55: ; CODE XREF: _main+14j |
154 | nop ; No Operation |
155 | rjmp loc_42 ; Relative Jump |
156 | ; End of function _main |
157 | |
158 | |
159 | ; =============== S U B R O U T I N E ======================================= |
160 | |
161 | |
162 | sub_57: ; CODE XREF: reset+8j |
163 | cli ; Global Interrupt Disable |
164 | |
165 | loc_58: ; CODE XREF: sub_57:loc_58j |
166 | rjmp loc_58 ; Relative Jump |
167 | ; End of function sub_57 |
168 | |
169 | |
170 | ; --------------------------------------------------------------------------- |
171 | .exit ; |
Das ist wirklich ein trivales Beispiel, aber man sieht worauf es hinausläuft. Bei Ghidra ist es ähnlich.
Tobias A. schrieb: > Die Baugruppe kommuniziert über Manchestercode. Und die > Daten, die mittels diesem Code übertragen werden sind nicht 1 zu 1 Binär > codiert, sondern über eine Norm. Manchester ist eine EXOR-Verknüpfung und Normen kann man kaufen und einsehen. Wenn die Fusebits stimmen und das Verify o.k. meldet, dann muß das Progamm auch laufen. Blöd ist natürlich, wenn der Entwickler das Programm noch nie mit der richtigen Hardware getestet hat.
Tobias A. schrieb: > Pass mal auf wie du mit Leuten hier im Forum sprichst. Wenn ich Ahnung > von HexFiles hätte, dann hätte ich wohl auch keinen Forumsbeitrag > geöffnet. Ich bin mit dem Clybord durchaus nicht immer einer Meinung, abe hier hat er nun mal recht und trifft den Nagel auf Kopf. Zudem war er doch recht freundlich, erkann durchaus auch anders.
Tobias A. schrieb: > Nur weiß der Kunde nicht genau, was da unter der Haube abläuft, weil der > Kunde die Entwicklung extern durchführen lassen hat und das > Entwicklungsbüro gibt es nun nicht mehr. Tja dumm gelaufen, wie sagt man da so schön: PGH - Pech gehabt.
Tobias A. schrieb: > Wenn es jmd geben würde, der sich damit auskennt hätte ich nicht euch > gefragt sondern den. Es gibt schon Leute die sich damit auskennen - sogar sehr gut. Aber die machen das halt nicht für Umme. Die wissen eben auch das es nicht viele Leute gibt die das effizient können, dementsprechend sind auch die Stundensätze.
Zeno schrieb: > Ich bin mit dem Clybord durchaus nicht immer einer Meinung, abe hier hat > er nun mal recht und trifft den Nagel auf Kopf. Mit Nagel und Kopf mag das was zu tun haben... Cyblord -. schrieb: > Dann ist das Kind ja schon in den Brunnen gefallen. Da du die Aufgabe > nicht lösen wirst, solltest du Zeit jetzt aufwenden um dich abzusichern. > Ich hoffe du hast bei der Angebotserstellung nicht mitgewirkt und dem > Chef sowas gesagt wie: "Ach das haben wir in 2 Stunden erledigt"!? > Jetzt würde ich anfangen, E-Mails zu löschen und Dokumente kreativ zu > verändern um meinen Hintern da rauszuhalten. Viel Glück! Wer solche Leute im Betrieb hat, braucht keine weiteren Feinde mehr. Kann den Laden bald zu machen
Tobias A. schrieb: > Wenn es jmd geben würde, der sich damit auskennt hätte ich nicht euch > gefragt sondern den. Das heisst also, daß es in euren ganzen Laden überhaupt niemanden gibt, der jemals einen Mikrocontroller programmiert hat. Na Mahlzeit... Oliver
Hi, mit Programm REAVR geht's evtl. oder auch mit: https://community.atmel.com/projects/simple-avr-disassembler Die Registertrivialnamen muss man dann zum Beispiel aus dem Datenblatt raussuchen und Angaben entsprechend umbenennen. Und bei den Sprüngen Adressen abzählen, wo die Einsprungadresse dann ist. Dazu brauchst Du einen Hex-Dezimalwandler noch. Und, wenn da noch zum Beispiel ein "STD EEPROM+1, R24 Store indirect with displacement" auf EEPROM drin ist, wird es echt haarig. Jedenfalls kriegte ich ein so reversierte Prog nicht zum Laufen. ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > Und, wenn da noch zum Beispiel ein "STD EEPROM+1, R24 Store indirect > with displacement" auf EEPROM drin ist, wird es echt haarig. Die Gefahr ist bei einem Attiny13 allerdings sehr gering, und wenn doch, wäre das ein Zeichen für einen kaputten Disassembler. Karl B. schrieb: > Jedenfalls kriegte ich ein so reversierte Prog nicht zum Laufen. Mag sein. Oliver
Tobias A. schrieb: > Ist es möglich dieses HexFile zu konvertieren, sodass dort Codezeilen > stehen? > Ich hab das mit Notepad++ probiert, aber wenn ich den Konverter > einschalte, stehen da lauter Binärzahlen. Ach wo, da stehen keine Binärzahlen, sondern einfacher Text. Und wenn du nicht weißt, was du mit sowas anfangen kannst, dann wäre das Lesen von einer Erklärung, was Intel-Hex oder Motorola-Hex ist und wie das jeweils aufgebaut ist, erstmal nötig. Und: Was meinst du, wozu ein Assembler und Linker und ein Compiler nütze ist? Erwarte also NICHT, in einem Hexfile irgend etwas von deiner Quellcode-Datei zu finden. W.S.
Oliver S. schrieb: > wäre das ein Zeichen für einen kaputten Disassembler. Hi, besagtes Prog. verlangt ein separates Hex-File für das EEPROM (oder noch ein *.eep) also 2 Hex files. Eines reichte da nicht. Und wenn ich nicht beide habe, geht's nicht. ciao gustav
:
Bearbeitet durch User
Tobias A. schrieb: > Ich muss in dieses Hex File reinschauen, damit ich den Komunikationsweg > dahinter nachvollziehen kann, um den Test zu konzipieren. Tests werden nicht nach Quellcode (bzw. in diesem Fall Maschinencode) konzipiert/erstellt, sondern nach der Spezifikation. Dein "Test" würde nur prüfen, ob der Microcontroller den Code richtig abarbeitet, aber nicht, ob der Code selbst richtig ist. Üblicherweise will man ja letzteres prüfen.
Hab die Posts Teils überflogen, Teils gelesen - hast du denn irgenwelche Informationen bekommen, was das Teil grundsätzlich machen und sich verhalten soll? Also, ist es z.B. einfach nur eine Datenquelle die laufend ungefragt "irgendwelche" Messwerte über den Kommunikationsweg schickt, oder ist die Kommunikation "Request-Response" - orientiert? Für eine bestimmte Aufgabe muss das Teil ja vorgesehen gewesen sein. > Die Baugruppe kommuniziert über Manchestercode. Und die > Daten, die mittels diesem Code übertragen werden sind nicht 1 zu 1 Binär > codiert, sondern über eine Norm. Der Teil ergibt nicht viel Sinn. Manchaster ist binär, eine gleichanteilsfreie binäre Kodierung. Was meinst du mit Norm? Etwas bestimmtes wie ein konkretes Protokoll? > ... > Also muss ich mittels Reverseengineering deren Auswertehard- und > -software nach bauen. Und dazu muss ich unter die Haube schauen. Was meinst du mit "Auswertehard- und -software" ? Die Hardwarebaugruppe in die der Tiny eingebaut wird, oder eine andere Baugruppe, welche die vom Tiny geschickten Daten erhält und auswertet? Hast du einen Tiny, den du mit dem Hex-File flashen kannst? Wenn ja, könntest du das machen und den µC zumindest mal an eine Versorgung anschließen und schauen, ob aus irgendeinem der Pins irgendwas raus kommt. Als erster Griff nach dem Strohhalm.
Moin, - bei 1k Code (es sind hat auch Vektoren dabei) sehe ich das nicht so kritisch, wenn man den Assembler vom ATTiny einigermassen verstanden hat. Ob der TO ob die Problematik ueberhaupt versteht: Keine Ahnung. Ob der TO dann eine Loesung finden kann (gegeben den Zeit/Geldrahmen [der TO hat leider wenig Kenntnisse bei uControllern, ob er jemanden fuer das Disassembling bezahlen kann/darf: Keine Ahnung]) So wahnsinnig schwierig ist das nicht (muehsam ist es aber), aber wenn jemand sich mit AVR-Assembler auskennt (guck mal, was die Schwarmintelligenz bei Beitrag "Hilfe bei Z80 Opcodes" hingekommen hat). Das hat ca. 1 Woche Analyse gedauert. Aber mal so eben Hack wieder in die Kuh-Form transformieren das geht nicht. Gruesse Th.
Dieter schrieb: > Vielleicht hilft ja ein triviales Beispiel weiter was > man mit einem Tool wie IDA Pro oder Ghidra bekommt. Ghidra macht daraus folgendes:
1 | void RESET(void) |
2 | |
3 | {
|
4 | SREG = 0; |
5 | DAT_mem_04ff = 0x3c; |
6 | DAT_mem_04fe = 0; |
7 | DAT_mem_04fd = 0; |
8 | _main(); |
9 | do { |
10 | /* WARNING: Do nothing block with infinite loop */
|
11 | } while( true ); |
12 | }
|
13 | |
14 | void _main(void) |
15 | |
16 | {
|
17 | char cVar1; |
18 | byte bVar2; |
19 | |
20 | write_volatile_1(DDRB,1); |
21 | do { |
22 | write_volatile_1(PORTB,1); |
23 | R18 = -0x61; |
24 | R19 = 0x86; |
25 | Whi = '\x01'; |
26 | do { |
27 | cVar1 = R18 + -1; |
28 | bVar2 = R19 - (R18 == '\0'); |
29 | Whi = Whi - (R19 < (R18 == '\0')); |
30 | R18 = cVar1; |
31 | R19 = bVar2; |
32 | } while ((cVar1 != '\0' || bVar2 != 0) || Whi != '\0'); |
33 | write_volatile_1(PORTB,R1); |
34 | R18 = -0x61; |
35 | R19 = 0x86; |
36 | Whi = '\x01'; |
37 | do { |
38 | cVar1 = R18 + -1; |
39 | bVar2 = R19 - (R18 == '\0'); |
40 | Whi = Whi - (R19 < (R18 == '\0')); |
41 | R18 = cVar1; |
42 | R19 = bVar2; |
43 | } while ((cVar1 != '\0' || bVar2 != 0) || Whi != '\0'); |
44 | } while( true ); |
45 | }
|
_main hab ich auch manuell benannt. Der Decompiler hilft Assembler Noobs wie mir schon sehr viel. Klar ist das immernoch nicht trivial zu verstehen, aber schon deutlich besser. Wenn er den Prozessor denn kennt... Hier habe ich das als atmega256 decompilieren lassen. Ging aber gut genug würde ich sagen. Ist natürlich für dieses triviale Beispiel dennoch schwer zu verstehen. Wenn das Programm komplexer wird, wirds schwierig. Dennoch: Danke NSA für dieses tolle tool.
:
Bearbeitet durch User
mm schrieb: > Tobias A. schrieb: >> Ich muss in dieses Hex File reinschauen, damit ich den Komunikationsweg >> dahinter nachvollziehen kann, um den Test zu konzipieren. > > Tests werden nicht nach Quellcode (bzw. in diesem Fall Maschinencode) > konzipiert/erstellt, sondern nach der Spezifikation. > > Dein "Test" würde nur prüfen, ob der Microcontroller den Code richtig > abarbeitet, aber nicht, ob der Code selbst richtig ist. Üblicherweise > will man ja letzteres prüfen. Das ist die einzig richtige Antwort. Ein Test wird anhand einer Spezifikation erstellt und nicht anhand des zu testenden Objektes. Folglich: keine Spezifikation keine Testspezifikation kein Test. NB - dafür gibt es Normen.
Cyblord -. schrieb: > Alt wird man so auch nicht. Aber durch deinen Vorschlag, schleunigst Dokumente zu fälschen, auch nicht.
Hoolga schrieb: > Cyblord -. schrieb: >> Alt wird man so auch nicht. > > Aber durch deinen Vorschlag, schleunigst Dokumente zu fälschen, auch > nicht. Nur FALLS er da irgendwas in der Richtung versprochen hat. Mehr kann er dann nicht mehr tun. Wenn das nicht der Fall ist muss er auch nichts fälschen. Aber eigentlich wird der Entwickler vorher mal gefragt wie er das zeitlich abschätzt. Und wir wissen wie diese Schätzung ausgefallen wäre. Die Leute auf höheren Posten arbeiten quasi nur so. Absichern in alle Richtungen. Das versteht der kleine Entwickler nur manchmal nicht.
:
Bearbeitet durch User
Karl B. schrieb: > besagtes Prog. verlangt ein separates Hex-File für das EEPROM (oder noch > ein *.eep) > also 2 Hex files. Eines reichte da nicht. Und wenn ich nicht beide habe, > geht's nicht. Das kann gut sein. Allerdings stehen bei einem AVR im EEPROM fast immer nur Daten. Direkt aus dem EEPROM kann nämlich überhaupt kein Code ausgeführt werden... D.h.: das EEPROM-Hex braucht überhaupt nicht dissassembliert werden. Es kann schon mit einem Editor, der Ersetzung mit regulären Ausdrücken beherrscht, in die vom Assembler benötigte Darstellung überführt werden.
Mathias M. schrieb: > > _main hab ich auch manuell benannt. Der Decompiler hilft Assembler Noobs > wie mir schon sehr viel. Klar ist das immernoch nicht trivial zu > verstehen, aber schon deutlich besser. Wenn er den Prozessor denn > kennt... Hier habe ich das als atmega256 decompilieren lassen. Ging aber > gut genug würde ich sagen. Ich denke es hängt davon ab wie gut man Assembler lesen kann. Ich selber sehe im Assembler Code recht schnell den Delay-Loop, im dekompilierten Code brauche ich länger weil ich es so nicht in C programmieren würde. > Ist natürlich für dieses triviale Beispiel dennoch schwer zu verstehen. > Wenn das Programm komplexer wird, wirds schwierig. Tools wie IDA Pro oder Ghidra machen es deutlich leichter als ein einfacher Disassembler. Aber um im Ergebnis dann zu sehen was passiert braucht man viel Erfahrung um schnell voran zu kommen. Hat man diese Erfahrung kann man unter Umständen viel erreichen, auch wenn man nur ein Binary hat ;-)
Tobias A. schrieb: > Das Projekt liegt schon seit Jahren bei uns. Nur kam erst > jetzt der Rest bei uns an (darunter auch das Progrmm vom > Kunden). Dann kann das ganze ja für Euren Kunden nicht allzu dringlich sein, sonst hätte er kaum Jahre vertrödelt um Euch die nötigen Daten bzw. Infos zu liefern. > Angebote und KOsten sind schon durch. Dh ich muss das > hinbekommen. Dann nimm Dir die nötige Zeit, AVR-Assembler in Ruhe von Grund auf zu lernen. Falls Du wirklich (erfolgreich) irgendwas technisches studiert hast, solltes das in durchaus in einem Jahr zu schaffen sein. > Nen anderen Weg gibts nicht. Aber sicher doch; Du könntest Dir einen neuen Arbeitgeber suchen und/oder Deine Firma sucht sich jemanden, der die nötigen Kenntnisse (z.B. AVR-Assembler) bereits hat.
Oliver S. schrieb: > Karl B. schrieb: >> Und, wenn da noch zum Beispiel ein "STD EEPROM+1, R24 Store >> indirect with displacement" auf EEPROM drin ist, wird es >> echt haarig. > > Die Gefahr ist bei einem Attiny13 allerdings sehr gering, und > wenn doch, wäre das ein Zeichen für einen kaputten > Disassembler. Versteh ich das richtig, daß man beim ATtiny13 nicht so einfach mit STD aufs EEPROM zugreifen kann?
michael_ schrieb: > Peter D. schrieb: >> Der ATtiny13 faßt nur max 512 Assemblerzeilen, ist also für einen >> Wissenden zu schaffen, aber eben nicht für Dich. > > Falsch. Nein: RICHTIG! > Wie kommst du auf Zeilen? > Hat 1KB Flash. > Das ist aber machbar. Achherrje, echt jetzt? 1kB Flash bedeutet bei 16-Bit Kommandos 512 Assemblerzeilen (max) ... Gruß Jobst
Du hast von Assembler keinen Schimmer. Schon gar nicht von AVR-Assembler. Du spielst in der gleichen Liga wie der TO.
Hallo, michael_ schrieb: > Du hast von Assembler keinen Schimmer. Doch, hat er. Schau dir mal das Ausgabelisting nach einem Assemblerlauf an. Da kann man sehen das ein AVR-Prozessorbefehl nahezu immer aus 1-Wort-Befehlen bestehen, wobei ein Wort 2 Bytes entsprechen. Und da in einer "Assemblerzeile" immer nur ein Befehl aufgeführt ist, sind nach spätestens 512 AVR-Befehlen (b.z.w. Befehlszeilen) die 1kb des ATTiny gefüllt. rhf
Es gibt noch eine Sache ueber die zu laestern wir ganz vergessen haben. :-D Wenn man irgendwann mal irgendwas in Assembler programmiert hat, also zumindest mal ein paar Basics drauf hat, dann wird man mit einer Befehlsliste relativ leicht das binary zurueckuebersetzen koennen, selbst ohne Disassembler ist das bei so wenig Code noch gut machbar. Und natuerlich muss man dann auch den Assembler lesen koennen, schon wieder etwas schwieriger. Aber dann wird man sehen das der Code einfach irgendwelche Lustigen Zahlen an irgendwelche Speicheradressen schreibt. Und im Zeitalter wo die Leute keine Datenblaetter mehr lesen, also garnicht mehr wissen wie man die Hardware in einem Controller direkt programmiert wird das Verstaendnis an dieser Stelle nochmal schwieriger. Alles nicht unmoeglich! Man kann die Aermel hochkraempeln und loslegen. Aber es ist garantiert nicht mal eben so, erst recht nicht wenn man bei 0 anfaengt und hier lieber rumjammert anstatt einfach zu machen. Olaf
mIstA schrieb: > Versteh ich das richtig, daß man beim ATtiny13 nicht so einfach mit STD > aufs EEPROM zugreifen kann? Man braucht afaik die Schreib/Leseroutine, da ja auch die Zugriffszeiten "länger" sind, deswegen "Busy"-Latenzzeit per Flag abgefragt wird. c-hater schrieb: > Das kann gut sein. Allerdings stehen bei einem AVR im EEPROM fast immer > nur Daten. Direkt aus dem EEPROM kann nämlich überhaupt kein Code > ausgeführt werden... Yep, aber die auszuführenden Befehle werden aus dem EEPROM geholt, nachdem das Flag zum Aufrufen der EEPROM Leseroutine gesetzt wurde. Reichlich tricky. Kleiner Codeschnipsel angehängt. ciao gustav
Karl B. schrieb: > aber die auszuführenden Befehle werden aus dem EEPROM geholt Nein. Es werden einfach nur Daten aus dem EEPROM in den SRAM kopiert. Das steht sogar im Kommentar. in temp,EEDR ; copy EEPROM data to temp st X+,temp ; store temp to dseg Nun muss man bloß noch wissen, dass das DSEG eben der SRAM ist (naja, auch Registerfile und MMIO) und alles ist klar. Denn weder aus SRAM, noch aus MCU- oder MMIO-Registern kann Code ausgeführt werden. Code ausführen geht ausschließlich aus dem Flash. Sprich: hier hat irgendwer sinnloserweise den EEPROM-Inhalt dissassembliert. Und dabei ergab sich mehr oder weniger zufällig was, was wie sinnvoller Code aussieht, in Wirklichkeit sind das aber nur Daten. Übrigens ist es beim AVR recht wahrscheinlich, das beliebige Daten auch mal wie sinnvoller Code aussehen. Das liegt an der hohe Codedichte. Die überwiegende Mehrheit der möglichen Datenworte sind auch gültige Opcodes und sehr viele Befehle bestehen aus nur einem Datenwort.
Tobias A. schrieb: > Also muss ich mittels Reverseengineering deren Auswertehard- und > -software nach bauen. Und dazu muss ich unter die Haube schauen. Wenn Du nachbauen sollst, wozu mußt Du dann den Code entschlüsseln? Einfach die Hardware nachbauen, und dann den Code in den µC reinfüttern. Sollte ja dann tun ... mIstA schrieb: > Dann nimm Dir die nötige Zeit, AVR-Assembler in Ruhe von Grund auf zu > lernen. Falls Du wirklich (erfolgreich) irgendwas technisches studiert > hast, solltes das in durchaus in einem Jahr zu schaffen sein. Du brauchst ein Jahr, um Assembler zu lernen/verstehen? Man muß ja nicht jeden Code auswendig lernen wollen ...
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.