Hallo ReAVR-Freunde, es freut mich zu lesen, dass mein AVR-Dis- oder vielmehr Reassembler (weil er direkt wiederverwertbaren Assemblercode erzeugt) auch in den 2020ern noch immer wieder einmal Thema ist. Vielleicht freut es Euch dann auch, dass ich ihn Ende des letzten Jahres noch einmal angepackt habe, um ihm nun auch den Umgang mit den vielen neuen AVRs seit den XMegas beizubringen. Das hat sich zwar als ein etwas umfangreicheres Unterfangen herausgestellt, aber ich bin dabei und hoffe, in den nächsten Monaten eine erste Testversion auf meine Website stellen zu können. Über den Namen bin ich mir noch nicht klar - "ReAVR_II" oder "ReAVRplus" - doch einen neuen Namen wird die neue Version auf jeden Fall erhalten. Außerdem wird es ein Companion-Tool geben, das die avrasm-*def.inc-Dateien aus den Studio-7- oder MPLAB-Repositories liest und in die ReAVR-internen Listen mit MCU-Spezifikationen und IORegister-Adressen umwandelt. Nicht zu vergessen die Möglichkeit, eigene Kommentare einzufügen, wahlweise am Ende einer Zeile oder als neue Zeile, wegen derer ich die ganzen Änderei überhaupt angefangen hatte... ;) Ich werde die neue Version ASAP veröffentlichen. Also "stay tuned." Beste Grüße Johannes
Ich wüßte nicht, wozu man so etwas gebrauchen könnte. Interessante Geräte sind gelockt, da kommt man also an den Code nicht ran. Und größere Projekte sind in Hochsprachen geschrieben, da sieht der Assembler wie Kraut und Rüben aus. Bei komplexen Projekten ist neu programmieren oftmals einfacher als reassemblieren.
Peter D. schrieb: > Ich wüßte nicht, wozu man so etwas gebrauchen könnte. In dem Moment, in dem du das Ding brauchst, weißt du, wofür du das brauchst. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > In dem Moment, in dem du das Ding brauchst, weißt du, wofür du das > brauchst. Hä?
Ich bin gespannt! Wie schaut es mit der Unterstützung der ATTiny4/5/9/10 aus? Da hätte ich das ein oder andere Projekt, bei dem das super nützlich wäre!
Oliver S. schrieb: >> Ich wüßte nicht, wozu man so etwas gebrauchen könnte. > > In dem Moment, in dem du das Ding brauchst, weißt du, wofür du das > brauchst. Und Apfelmus ist Mus aus Äpfeln!
Ghidra … auch wenn es ausgerechnet von der NSA kommt, es ist Opensource, und es zimmert gleich noch ein C-Code-Gerippe zurecht. Hab's gerade mal auf einem aktuellen AVR-Projekt (mit ATtiny204) probiert. Gut, die Vektortabelle, die sie benutzen, hat nicht die korrekten Namen (und Länge), muss man halt korrigieren. Aber ansonsten schon durchaus beeindruckend, was sie da aus dem Stand heraus erkennen. Das das nicht ohne Interaktionen geht, ist natürlich klar. J. A. schrieb: > weil er direkt wiederverwertbaren Assemblercode erzeugt Geht auch mit dem ganz normalen Disassembler aus den Binutils. Man muss nur die Headerzeilen und die Spalten mit Adressen und Opcodes wegwerfen. Gerade probiert:
1 | avr-objdump -d myfile.hex --disassemble-zeroes -b ihex -m avr5 -j .sec1 | sed -e '1,7d' -e 's/^..................//'> foo.s |
2 | avr-as -mavr5 -o foo.o foo.s |
3 | avr-ld -o foo.elf foo.o |
4 | avr-objcopy -O ihex foo.elf foo.hex |
5 | diff -u myfile.hex foo.hex |
6 | # -> keine Unterschiede gefunden |
:
Bearbeitet durch Moderator
Ey, @Folks, macht doch bitte J.A. nicht nieder. Das Programm ist kostenlos benutzbar, hat ne freie Lizenz und ist unter anderem in Delphi geschrieben. Als Hacker oder reverse engineer ist man bei seinem Hobby auf jeden "Strohhalm" angewiesen, der einem gereicht wird, da ist das Proggy dann doch gut! @J.A., wie willst Du das Millitär von Deinem Proggy fernhalten? Hast Du da ne besondere Strategie? ;-O ;-))) mfg
J. A. schrieb: > Über den Namen bin ich mir noch nicht klar - "ReAVR_II" oder "ReAVRplus" Üblich ist die Vergabe von Versionsnummern: An erster Stelle für Mayor-Releases (hochgezählt bei wesentlichen Änderungen, Inkompatibilitäten) und danach Minor (Bugfixes, Tippos in der Doku, etc.). Ansonsten wird's irgendwann komisch Tool ToolII ToolPlus ToolBesser ToolNochBesser ToolSuperGutUndNochViiielBesser ToolSuperHypeMegaUnglaublichHyperGutBestEverII
Lotta . schrieb: > und ist unter anderem in Delphi geschrieben. Macht das irgendwas besser, außer daß es mancher Leute religiöse Gefühle bedient?
Harald K. schrieb: > Lotta . schrieb: >> und ist unter anderem in Delphi geschrieben. > > Macht das irgendwas besser, außer daß es mancher Leute religiöse Gefühle > bedient? Hey, Du hast es genau erfasst: Philippe Kahn hat damals in der Wende den "Raubkopier-Ossis" nicht juristisch nachgestellt, sondern Ihnen ne kostenlose Lizenz gegeben, also ihre Raubkopien legalisiert. Das hat natürlich Auswirkungen auf die Loyalität der Leuts zu Borland bis heute, auch wenn Borland ja inzwischen leider zigmal umfirmiert wurde. Hatte bestimmt auch mit guten Beziehungen des Ostblocks mit Frankreich zu tun, (der osten hat zb. das Secam Fensehsystem übernommen) Philippe war ja Franzose. mfg
Harald K. schrieb: > Muss man nicht verstehen. Es war einfach ne geile, interessante Zeit damals. Philippe hat damals einfach den "Ossis" geholfen, die mit 100 DM Begrüßngsgeld in ne neue Gesellschaftsordnung mit "keiner Ahnung von Tuten und Blasen" gestoßen wurden. Heut machen die Superreichen und Politiker lieber Bombenangriffe auf Krankenhäuser und Kindergärten. das macht ja auch mehr Spass. :-((((((( mfg
:
Bearbeitet durch User
Echt fantastisch, was ich so alles zu lesen bekomme. Na dann stelle ich mal in den Raum, dass ich von Geburt Niedersachse bin und mein ganzes bisheriges Leben dort verbracht habe, von gelegentlichen Ausflügen in andere Gegenden Deutschlands und Europas abgesehen. Dass ich etliche Programme in 8080- und Z80-Hex-Code geschrieben und meinen HD64180-CP/M-Computer erst aufgegeben habe, als ich mich, von außen gedrängt, in die AT-kompatible Welt begab. Da waren dann schon alle 8088-, 8086-, 80186- und 80286-Maschinen an mir vorbei gegangen, und das damals noch übliche MS-DOS hatte schon die Version 5 erreicht. Von Windows war in der Zeit noch allenfalls gerüchteweise zu hören, bis Windows 3.0 herauskam, und als soweit erschwingliche höhere Programmierumgebung gab es nur TurboPascal. Linux und Open-Source waren damals noch überhaupt kein Thema. Ich war damals und bin es bis heute in einem Betrieb der produktiven Industrie beschäftigt und hatte/habe daher einige Möglichkeiten, stellte aber irgendwann fest, dass ich beim Programmieren durcheinander kam, als ich versuchte, alle meine Aufgaben in C zu erledigen. Weshalb ich mich entschloss, C nur für meine AVR-Projekte zu verwenden, und für meine PC-Anwendungen Pascal, im weiteren dann Delphi. Diese Entscheidung war rein pragmatisch und hat nichts mit religiösen Gefühlen zu tun. Wenn derlei je im Spiel gewesen wäre, hätte ich mich auch wohl kaum darauf eingelassen, für den c't68000 Anwendungen in Pearl zu schreiben, oder die Testprogramme für ein Transputer-Projekt in Occam. Im Übrigen bin ich am Überlegen, den neuen ReAVR, wenn er erstmal alles so tut wie gewünscht, in ein Lazarus-Projekt umzuwandeln und ihn anschließend dem Open-Source-Verfechter aus der Runde zur weiteren Betreuung zu übergeben. Dann wären seine Mäkeleien mit einem Schlag aus der Welt. Und ich hätte nichts mehr damit zu tun. Ein paar Anmerkungen zu speziellen Kommentaren noch: Die erste zum Namen. Klar ist die übliche Methode, einfach die Version hochzuzählen, und das habe ich in der Vergangenheit auch immer so gehalten. Nur gehen diesmal die Änderungen so weit, dass ich mir einfach solche Fragen ersparen möchte wie "Warum geht dies und das auf einmal nicht mehr?" Die zweite dazu, wozu ReAVR gut ist. Lieber Kommentator, es wird Dich wahrscheinlich überraschen, wie viele AVRs für professionelle embedded Anwendungen ungelockt sind. Tatsächlich sind mir bei meinen Untersuchungen zu meiner eigenen Überraschung nur wenige gelockte untergekommen. Ansonsten kann man sich, wenn man mit Assembler so weit vertraut ist, problemlos in den Hex-Code eines Compilers einlesen. Ok, bei größeren Codes ab 8 oder 16KB wird das zeitaufwändig, und man muss entscheiden, ob man es wirklich vertreten kann. Und zu den binutils: Klar bekommt man damit mit etwas Editor-Gefummle auch ein wieder assemblierbares Disassembly hin. Aber auch nur das, mit allen kryptischen Labels, wie sie sind. Und wenn man dann zum Beispiel bei den in/out-Instruction die richtigen IO-Namen haben will, muss man für jeden einzeln ein Suchen/Ersetzen anstoßen. Genau das macht aber ein Reassembler wie ReAVR von sich aus automatisch - und interaktiv.
J. A. schrieb: > Genau das macht aber ein Reassembler wie ReAVR von sich aus automatisch > - und interaktiv. Wie geschrieben, Ghidra letztlich auch, und das erzeugt auch gleich noch ein C-Code-Gerippe. Man könnte den Aufwand also eigentlich auch da reinstecken, dass Ghidra von Haus aus noch möglichst viele AVRs mit all ihren Register-Details kennt, damit man diese automatisiert konvertieren kann. > Nur gehen diesmal die Änderungen so weit, ReAVR NG :-) Aber auch das hätte natürlich das Problem, was Johann beschreibt: wenn die übernächste Version wieder alles über den Haufen wirft, suchst du wieder einen neuen Namen. Daher die übliche Konvention, dass man bei inkompatiblen Änderungen die major number hochzählt. Aber seit Feuerfüchse und dergleichen alle nasenlang die Nummern komplett hochzählen, ist das natürlich auch irgendwie Vergangenheit.
J. A. schrieb: > Ok, > bei größeren Codes ab 8 oder 16KB wird das zeitaufwändig, und man muss > entscheiden, ob man es wirklich vertreten kann. Ja, bei Anwendungen über das Anfängerniveau hinaus wird das schnell unhandlich. Ich habe schon lange keine Hemmungen mehr, float, printf, scanf zu verwenden, um bequem programmieren zu können. Auch Structs und Arrays sehen in Assembler extrem kryptisch aus, erhöhen aber in C erheblich die Lesbarkeit und Flexibilität. Den typischen Spaghetticode möchte man eigentlich nicht mehr haben. Und um Fehler zu suchen oder Abläufe zu verstehen, ist es oftmals einfacher, das Programm im Debugger laufen zu lassen.
Jörg W. schrieb: > Wie geschrieben, Ghidra letztlich auch, und das erzeugt auch gleich noch > ein C-Code-Gerippe. Und was ist mit den Kommentaren und selbsterklärenden Namen?
Noch ein paar Anmerkungen, bevor ich mich verabschiede, bis der neue ReAVR fertig ist: @Jörg: Ich habe kurz bei Ghidra vorbei gesehen und festgestellt, dass da im Prinzip dasselbe Schema verfolgt wird wie bei Microchips MPLAB - der Code ist Java-basiert und damit recht einfach auf alle drei "großen" OSse anzupassen (Linux, MacOS und Windows). Was die includes angeht, habe ich noch nicht weiter geforscht und kann deshalb nicht sagen, ob die geradeaus oder vielleicht etwas skurril sind. Vielleicht magst Du mir einmal ein Beispiel zukommen lassen, gerne auch als PN? Die "NG"-Idee ist übrigens nicht schlecht ;) Und keine Sorge. Es wird danach keine weitere so tiefgreifende Änderung von ReAVR mehr geben. @Peter: Wie kommst Du eigentlich darauf, dass 8 bis 16KB AVR-Code Anfängerniveau sind? Aber vielleicht hast Du bisher einfach nie eine kostenkritische embedded Anwendung programmieren müssen, bei der die gehobenen Funktionen uninteressant waren, weil es dort weder floats noch Schnittstellen gab, auf die printf oder scanf angewendet werden konnten. Ansonsten finde ich C-Code im Disassembly keineswegs kryptisch. Ich brauche mich nur etwas einzulesen und dabei vielleicht ein Dutzend Aufruf-Labels global zu ändern. Was mit ReAVR ganz einfach geht... Nach meiner Erfahrung gibt es nur einen Compiler, der wirklich kryptischen Assemblercode erzeugt, und das ist Bascom. @Georg: Genau. Dazu hat bisher keiner etwas beigetragen. Beste Grüße Johannes
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.