Hallole, ich habe hier einen PIC-Assembler-Quellcode, den ich ändern/weiterentwickeln möchte und darf. Sehr hilfreich bei dessen Verständnis wäre, wenn ein Tool daraus ein Programmablaufdiagramm destillieren würde, an dem ich mich entlanghangeln und die Struktur und das Funktionieren und den Code nachvollziehen könnte. Zwar sind hier und da Kommentare vorhanden, aber wie es mit Kommentaren halt so ist sagen sie vorwiegend dem Kommentator etwas, aber die helfen nur bei Details, nicht aber beim Verständnis der Programmstruktur. Gibt es solche Tools? Mark
Mark K. schrieb: > Gibt es solche Tools? Ich würde mal sagen: Vermutlich nicht. Die Analyse-Software müßte so intelligent sein wie ein erfahrener Assemblerprogrammierer. Ich wage mich so weit aus dem Fenster zu lehnen, dass ich sagen würde: sowas gibt es derzeit nicht und wird es auch in absehbarer Zukunft nicht geben. Nichtmal die Compiler-Bauer (konkret: die Bauer der Backends für die jeweilige Zielarchitektur, also den Code-Generatoren) schaffen es, dem Compiler alle Tricks einzuhauchen, die sie kennen. Und das sind typisch Leute, die sich verdammt gut in der jeweiligen Zielarchitektur auskennen und eigentlich alle dort möglichen Tricks beherrschen. Und der umgekehrte Weg, aus einem bestehenden Maschinencode die dahinter stehende Logik zu extrahieren, ist noch einmal ein um ein Vielfaches komplexeres Problem. Kurzfassung: Vergiß' es. Entweder du kannst Assembler und verstehst das Problem, welches das Programm löst, oder du hast nicht den Hauch einer Chance.
Mark K. schrieb: > ich habe hier einen PIC-Assembler-Quellcode, den ich > ändern/weiterentwickeln möchte und darf > "und darf" lässt darauf schliessen, dass es nichts privates ist sondern für deinen Arbeitgeber. Ansonsten gäbe es hier im Forum sicher etliche die dir mit dem Assembler-Code weiterhelfen könnten.
Mark K. schrieb: > ich habe hier einen PIC-Assembler-Quellcode, den ich > ändern/weiterentwickeln möchte und darf. Sehr hilfreich bei dessen > Verständnis wäre, wenn ein Tool daraus ein Programmablaufdiagramm > destillieren würde, an dem ich mich entlanghangeln und die Struktur und > das Funktionieren und den Code nachvollziehen könnte. Wenn du die Funktionsweise des Codes nicht selber nachvollziehen kannst (wofür du im Fall von PIC16/18 mein vollstes Verständnis und Beileid hättest) - wie wäre es dann mit einem Simulator/Emulator? Oder nimm einen realen PIC, steck den Debugger dran und laß das Programm im Einzelschrittbetrieb laufen. Auch wenn die 8-Bit PIC Architektur komplett verkorkst ist, so muß man Microchip zumindest zugute halten, daß es mit dem PICkit ein kosten- günstiges Tool und wenn auch nicht freie, so doch zumindest kostenlos verfügbare Software zum Debuggen gibt.
Mark K. schrieb: > ich habe hier einen PIC-Assembler-Quellcode, Welcher Controller und wie umfangreich? Kannst ja mal das hier ausprobieren: https://www.youtube.com/watch?v=SEWWqaZNWec Für C Programme finde ich das Call Graph Feature ganz nett: https://www.youtube.com/watch?v=x3IlHhgdg3w Zeigt natürlich nicht unbedingt den Programmablauf UND ist leider auch für Assembler nicht verfügbar :-(
Stoer p. schrieb: > Mark K. schrieb: >> ich habe hier einen PIC-Assembler-Quellcode, den ich >> ändern/weiterentwickeln möchte und darf > >> "und darf" > > lässt darauf schliessen, dass es nichts privates ist sondern für deinen > Arbeitgeber. Nein. Das läßt darauf schließen, daß ich es "darf", also die Erlaubnis des Urhebers habe, es also völlig legal ist. Es ist überdies rein privat. Ich bin beruflich weder Software- noch Hardwareentwickler, habe es auch nicht gelernt/studiert, auch wenn ich es privat sei "Ewigkeiten" betreibe. > Ansonsten gäbe es hier im Forum sicher etliche die dir mit dem > Assembler-Code weiterhelfen könnten. Das bezweifele ich. Warum sollte sich jemand die Mühe machen und mir die Arbeit abnehmen, den Quellcode zu verstehen und zu ändern? Das sind alles Leute, die im Beruf oder Ausbildung stehen und mehr als genug damit und den eigenen Basteleien zu tun haben.
Axel S. schrieb: > Wenn du die Funktionsweise des Codes nicht selber nachvollziehen kannst > (wofür du im Fall von PIC16/18 mein vollstes Verständnis und Beileid > hättest) - wie wäre es dann mit einem Simulator/Emulator? Oder nimm > einen realen PIC, steck den Debugger dran und laß das Programm im > Einzelschrittbetrieb laufen. Vielleicht habe ich mich falsch ausgedrückt. Ich weiß natürlich, was das Programm bzw. derprogrammierte PIC im Ergebnis macht, ich habe und benutze die das Programm/PIC/Schaltung ja selbst. Ich will das Programm aber in einigen Dingen ändern, verbessern, und dazu muß ich den Quellcode verstehen und als erstes die Struktur, den Aufbau erfassen. Dann, mit dem Aufbau, der Struktur vor Augen (das meine ich wörtlich), kann ich daran gehen, die einzelnen Abschnitte, Routinen, die konkrete Programmierung nachzuvollziehen und meine Änderungen versuchen einzubauen. Also der umgekehrte Weg der "sauberen" Programmentwicklung, bei der eben das PAD - oder wie immer man es bezeichnen möchte - am Anfang steht oder zumindest der Rahmen ist, innerhalb dessen im Detail programmiert wird. Natürlich kann man das auch selbst machen, im ersten bis x-ten Durchgang erst mal die Struktur und den Aufbau des Quellcodes erfassen und zu Papier bringen, aber das ist doch eine Arbeit, die aufgrund der Verwendung von Labels, Sprungmarken, Sprungbefehlen usw. doch wenigstens überwiegend von einer Software erledigt werden können sollte. Soweit ich weiß - bzw. gehört habe - soll es so etwas doch sogar für "richtiges" Reverse Engineering, Deassemblierung, auf Grundlage der bloßen Maschinenprogramme möglich sein. Erst recht muß es doch mit einem "ordentlichen" Quellcode möglich sein. Hier kommt hinzu, daß mich wahrscheinlich nur ein geringer Teil des Programms interessiert und ich eigentlich nur wissen muß, wie dieser Teil im Gesamtkontext steht und wirkt; dazu ist es wohl nicht erforderlich, das ganze Programm zu verstehen und zu erfassen - andernfalls wäre es vermutlich nicht ganz verschwendete Zeit, sich die Struktur selbst zu erarbeiten. Ich habe von früher her noch einige Quellcodes (Clipper, 8088-Assembler) die ich noch immer benutze und irgendwann sicher auch ändern muß, bei denen ich leider "unsauber" entwickelt habe. Natürlich kenne ich heute deren Aufbau nur noch grob, wenn überhaupt, aber da könnte ich mich dank meiner Kommentierungen relativ schnell wieder reinfuchsen. Mit einem fremden Quellcode, dessen Kommentierungen für mich überdies nicht so ohne weiteres verständlich und nachvollziehbar sind wie meine eigenen Kommentierungen (die ich bewußt in Hinblick auf spätere Änderungen ohne konkrete Erinnerung entsprechend ausführlich gestaltet habe), ist das aber alles andere als einfach.
:
Bearbeitet durch User
Volker S. schrieb: > Mark K. schrieb: >> ich habe hier einen PIC-Assembler-Quellcode, > > Welcher Controller und wie umfangreich? Ursprgl. für den 16F84, dann über weitere Stufen der 16F684 und zuletzt der 16F1824, wobei ich wegen des größeren Progammspeichers auf den 16F1825 wechsele (das habe ich schon getan, die von MPLAB beanstandeten "Inkompatibilitäten" sind schon erledigt und mit Ausnahme eines merkwürdigen, in bestimmten Konstellationn auftretenden Aufhängens, dasirgendwie mit dem ADC zusammenhängt, läuft es auch wie es soll). > Kannst ja mal das hier ausprobieren: > https://www.youtube.com/watch?v=SEWWqaZNWec Danke, gerade angeschaut. So in etwa stelle ich mir es vor. Aber fast 70 Dollar für diese eine private Benutzung... naja. > > Für C Programme finde ich das Call Graph Feature ganz nett: > https://www.youtube.com/watch?v=x3IlHhgdg3w > Zeigt natürlich nicht unbedingt den Programmablauf > UND ist leider auch für Assembler nicht verfügbar :-( Ist aber in Assembler geschrieben, da alles sehr hardwarenah und auch zeitkritisch ist (es geht um einen Lokdekoder für Märklin-Digital, MM (NICHT mfx)).
:
Bearbeitet durch User
Mark K. schrieb: > Axel S. schrieb: >> Wenn du die Funktionsweise des Codes nicht selber nachvollziehen kannst >> (wofür du im Fall von PIC16/18 mein vollstes Verständnis und Beileid >> hättest) - wie wäre es dann mit einem Simulator/Emulator? Oder nimm >> einen realen PIC, steck den Debugger dran und laß das Programm im >> Einzelschrittbetrieb laufen. > > Vielleicht habe ich mich falsch ausgedrückt. Ich weiß natürlich, was das > Programm bzw. derprogrammierte PIC im Ergebnis macht, ich habe und > benutze die das Programm/PIC/Schaltung ja selbst. Ich will das Programm > aber in einigen Dingen ändern, verbessern, und dazu muß ich den > Quellcode verstehen und als erstes die Struktur, den Aufbau erfassen. Ja. Dann mach. Es gibt hier keine Abkürzungen. Immerhin hast du den originalen Quellcode. Mit Labeln und Kommentaren, die hoffentlich mehr aussagen als nur die Adressen alleine. > Dann, mit dem Aufbau, der Struktur vor Augen (das meine ich wörtlich), > kann ich daran gehen, die einzelnen Abschnitte, Routinen, die konkrete > Programmierung nachzuvollziehen und meine Änderungen versuchen > einzubauen. Viel Struktur gibt es in einem µC Programm nicht. Nach dem Reset gibt es etwas Intitialisierung und dann eine Endlosschleife. Daneben dann meist noch Interrupt-Serviceroutinen (ISR). Und jetzt wird es haarig. Die Endlosschleife und die ISR schieben sich gegenseitig Daten zu. Die wechselseitigen Abhängigkeiten können sehr komplex sein. Aber beim Verständnis helfen könnte dir nur der Original- Autor der Software. Aus dem Quellcode allein kann das keine Software ableiten. > Hier kommt hinzu, daß mich wahrscheinlich nur ein geringer Teil des > Programms interessiert und ich eigentlich nur wissen muß, wie dieser > Teil im Gesamtkontext steht und wirkt; dazu ist es wohl nicht > erforderlich, das ganze Programm zu verstehen und zu erfassen Ganz recht. Leider bleibst du sehr nebulös, was deine Änderungen betrifft. Zur Lokalisierung der "interessanten" Stellen im Programm können dir die namen von Funktionen, Labels, Variablen diesen. Oder Zugriffe auf bestimmte Peripherie.
c-hater schrieb: > Ich würde mal sagen: Vermutlich nicht. Die Analyse-Software müßte so > intelligent sein wie ein erfahrener Assemblerprogrammierer. Ich wage > mich so weit aus dem Fenster zu lehnen, dass ich sagen würde: sowas gibt > es derzeit nicht und wird es auch in absehbarer Zukunft nicht geben. Um allein ein PAD, ein Flowchart, zu erzeugen? Naja. Vor bleibt denn die vielgerühmte "KI" - obwoh man dafür nicht wirklich "I" braucht. Ich meine jetzt nicht, daß ein bestimmte Abfolge von Assembler-Befehlen sozusagen "übersetzt", erklärt, wird. Sondern nur die Darstellung der Struktur, des Aufbaus des Codes. Nicht alles was hinkt ist ein Vegleich, aber im Prinzip ist es das Extrahieren einer Gliederung aus einem Text, der in einer normierten Weise strukturiert ist. Jedes aktuelle Textverarbeitungsprogramm erstellt doch eine Gliederung, wenn man seinen Text entsprechend strukturiert. > Nichtmal die Compiler-Bauer (konkret: die Bauer der Backends für die > jeweilige Zielarchitektur, also den Code-Generatoren) schaffen es, dem > Compiler alle Tricks einzuhauchen, die sie kennen. Und das sind typisch > Leute, die sich verdammt gut in der jeweiligen Zielarchitektur auskennen > und eigentlich alle dort möglichen Tricks beherrschen. Das ist doch etwas anderes. > > Und der umgekehrte Weg, aus einem bestehenden Maschinencode die dahinter > stehende Logik zu extrahieren, ist noch einmal ein um ein Vielfaches > komplexeres Problem. Ich rede nicht vom Maschinenprogramm, obwohl es doch auch dafür bereits entsprechende tools geben soll, sondern um den Assemblercode. Wenn MPLAB den Code als fehlerfrei und den Konventionen entsprechend akzeptiert, dann sollte man eigentlich erwarten können, daß MPLAB auf Knopfdruck ein ensprechendes DAP, Flowchart, wie immer man es nennen willen, anzeigt. > Kurzfassung: Vergiß' es. Entweder du kannst Assembler und verstehst das > Problem, welches das Programm löst, oder du hast nicht den Hauch einer > Chance. Ich glaube, Du hast nicht verstanden, worum es mir geht. Ich weiß natürlich, was das Programm im Ergebnis macht, welches Problem es löst, aber nicht, wie es aufgebaut, strukturiert ist, und allein darum geht es mir zunächst.
Mark K. schrieb: > Volker S. schrieb: >> Kannst ja mal das hier ausprobieren: >> Youtube-Video "Assembly Flowchart Creator" > > Danke, gerade angeschaut. So in etwa stelle ich mir es vor. Aber fast 70 > Dollar für diese eine private Benutzung... naja. Hm, ja habe gerade auch mal die DEMO Version installiert. Die Beschränkung der Zeilenanzahl in der Demoversion ist bisschen arg. -> kann man vergessen...
:
Bearbeitet durch User
Mark K. schrieb: > es geht um einen Lokdekoder für Märklin-Digital, MM Aber nicht etwa von MERG?! Gruss Chregu
@ Mark > [...] hilfreich [...] wäre, [...] die Struktur und > das Funktionieren und den Code nachvollziehen könnte. Das ist so unscharf wie es weitläufig ist. Und das ist das Problem, wenn man Dir was empfehlen wollte. Ich habe mir mal die Internetseite von "Assembly Flowchart Creator" angesehen und meine, dass dessen Funktion, von ein paar Zeilen Perl und gnuplot erledigt werden könnte. Das wäre zumindest mal ein Anfang. Was hältst Du davon, das mal zu versuchen?
Mark K. schrieb: > Wenn MPLAB > den Code als fehlerfrei und den Konventionen entsprechend akzeptiert, > dann sollte man eigentlich erwarten können, daß MPLAB auf Knopfdruck ein > ensprechendes DAP, Flowchart, wie immer man es nennen willen, anzeigt. Nope. Ein solches Program kann immer noch wild zu, während der Laufzeit berechneten, Adressen springen oder dynamisch generierten Code im RAM ausführen. Beides sind (waren) ausgesprochen handliche Techniken bei Asm. Letzteres wird auch langsam wieder bei anderen Sprachen "modern". Automatisch zu erkennen zu welchen Adressen tatsächlich gesprungen wird kann aber z.B. extrem schwer werden. /regards
Hilft so ein Generator wirklich? Auch der kann nicht die Absicht des Programmierers hinter einer Zeile Code verstehen. Bestenfalls kann er gängige Idiome erkennen und in einem Schritt zusammenfassen. Kann er das nicht, dann erhält man für jede Zeile Assembler ein Symbol im Chart, also nichts anderes als den Assemblercode, nur schön dekoriert. Ob ich dann einem Flowchart oder einem Listing mit Papier, Bleistift und Gehirnschmalz zu Leibe rücke macht keinen großen Unterschied. Listing mit breitem linken Rand ausdrucken. Den Verlauf von allen Sprüngen (bedingt und unbedingt) am Rand einzeichnen. Returns aus Subroutinen markieren, den Beginn von Subroutinen markieren. Viel mehr an Struktur kann ein Flowchart-Generator auch nicht aus einem Assemblerlisting herauslesen.
Mark K. schrieb: > Wenn MPLAB > den Code als fehlerfrei und den Konventionen entsprechend akzeptiert, > dann sollte man eigentlich erwarten können, daß MPLAB auf Knopfdruck ein > ensprechendes DAP, Flowchart, wie immer man es nennen willen, anzeigt. Wie viele Leute brauchen solch ein Programm? Der übliche Weg der Software Entwicklung ist anders herum, vom Flowchart zum Code. Dafür gab es (gibt es?) Programme. Wer schreibt ein Programm (für andere Leute), wenn kein größerer Bedarf besteht? Du bist eine Ausnahme. Zeig uns doch bitte mal eine Seite des Quelltextes, damit wir einen Eindruck von der Komplexität bekommen. Wie viel Zeilen umfasst dein gesamtes Programm?
Marten Morten schrieb: > Hilft so ein Generator wirklich? Ich denke schon. > Auch der kann nicht die Absicht des > Programmierers hinter einer Zeile Code verstehen. Natürlich nicht. Aber die Struktur und den Aufbau des Programms/Quellcodes aufzeigen. > Ob ich dann einem Flowchart oder einem Listing mit Papier, Bleistift und > Gehirnschmalz zu Leibe rücke macht keinen großen Unterschied. Du hast nicht verstanden. Ich will erst mal dieses Flowchart haben. Und dafür wenn möglich ein tool verwenden, das mir diese Arbeit abnimmt. > > Listing mit breitem linken Rand ausdrucken. Den Verlauf von allen > Sprüngen (bedingt und unbedingt) am Rand einzeichnen. Returns aus > Subroutinen markieren, den Beginn von Subroutinen markieren. Viel mehr > an Struktur kann ein Flowchart-Generator auch nicht aus einem > Assemblerlisting herauslesen. Genau. Und diese Arbeit möchte ich mir ersparen. Es ist ja nicht so, daß ich Langeweile, zu viel Zeit hätte. Jede Arbeitserleichterung ist willkommen.
Georg G. schrieb: > Mark K. schrieb: >> Wenn MPLAB >> den Code als fehlerfrei und den Konventionen entsprechend akzeptiert, >> dann sollte man eigentlich erwarten können, daß MPLAB auf Knopfdruck ein >> ensprechendes DAP, Flowchart, wie immer man es nennen willen, anzeigt. > Wie viele Leute brauchen solch ein Programm? Der übliche Weg der > Software Entwicklung ist anders herum, vom Flowchart zum Code. Dafür gab > es (gibt es?) Programme. Nun, ich weiß sehr wohl, daß viele wild drauf los programmieren und sich nicht erst ewig mit meinem PDS aufhalten, zumal sich vieles, viele Notwendigkeiten ja erst im Laufe des programmierens ergeben. Und für die eigene Dokumentation, für spätere Wartungszwecke, für´s spätere Verständnis, wäre sicherlich hilfreich, aus seinem Herumcodiere letztlich auch ein PDS extrahieren zu können. Klar, ein 20Zeiler, den man im Gedächtnis behalten kann, braucht das nicht. > > Wer schreibt ein Programm (für andere Leute), wenn kein größerer Bedarf > besteht? Du bist eine Ausnahme. Welche Ausnahme? Ich bin zweifellos nicht der einzige, der einen fremden Quellcode weiterverwenden und weiterverarbeiten und nicht das Rad neu erfinden will. > > Zeig uns doch bitte mal eine Seite des Quelltextes, damit wir einen > Eindruck von der Komplexität bekommen. Wie viel Zeilen umfasst dein > gesamtes Programm? Ich habe den Quellcode unter dem Siegel der Verschwiegenheit erhalten. Das nehme ich schon ernst. Davon abgesehen ist doch völlig unerheblich, wie komplex Dir eine Seite des Listings erscheint. Darum, um die Komplexität einzelner Module, Lösungen, Prozeduren geht es doch überhaupt nicht. Soweit, daß ich einzelne, konkrete Sequenzen nicht verstehe und Hilfe brauche bin ich noch lange nicht. In MPLAB sind es rund 3.000 Zeilen.
Theor schrieb: > Ich habe mir mal die Internetseite von "Assembly Flowchart Creator" > angesehen und meine, dass dessen Funktion, von ein paar Zeilen Perl und > gnuplot erledigt werden könnte. > Das wäre zumindest mal ein Anfang. Was hältst Du davon, das mal zu > versuchen? Du meinst, daß ich Perl etc. erlerne um in den nächsten Monaten ein tool zu programmieren, das mir hilft, aus dem ASM-Quellcode ein Flowchart zu extrahieren - und wozu ich natürlich erst mal das Flowchart haben muß, damit ich dieses tool erstellen und seine einwandfreie Funktionsweise sicherstellen kann? Irgendwie sinnlos. Nee, dann drucke ich das listing lieber aus und mache es händisch. Das ist für mich alles kein Selbstzweck, auch das Programmieren mache ich nicht, weil ich es gerne möchte, sondern weil ich das fertige Ergebnis haben möchte. Die Zeiten, so etwas aus Selbstzweck zu machen, sind seit bald 40 Jahren vorüber.
Christian M. schrieb: > Mark K. schrieb: >> es geht um einen Lokdekoder für Märklin-Digital, MM > Aber nicht etwa von MERG?! Nein. Der Merg-Dekoder ist DCC, bei mir geht es um MM. Speziell um den Aspekt der Regelung der Motoren. Aber das führt hier zu weit.
Mark K. schrieb: > Natürlich nicht. Aber die Struktur und den Aufbau des > Programms/Quellcodes aufzeigen. Stark optimierte Assemblerprogramme besitzen kaum noch eine erkennbare Struktur. Das ist das Problem. Wenn du Strukturen automatisch ermitteln kannst, dann sind das typischerweise unwichtige Sachen, die nur selten durchlaufen werden und die deswegen nicht weiter optimiert wurden. Der Kern der Funktionalität, da wo wirklich die Post abgeht, das ist nicht automatisch analysierbar.
Volker S. schrieb: > Mark K. schrieb: >> Volker S. schrieb: >>> Kannst ja mal das hier ausprobieren: >>> Youtube-Video "Assembly Flowchart Creator" > Hm, ja habe gerade auch mal die DEMO Version installiert. > Die Beschränkung der Zeilenanzahl in der Demoversion ist bisschen arg. > -> kann man vergessen... Meinst Du die Software als solche, also deren Funktionieren/Ergebnis, oder nur die Demo zum Ausprobieren aufgrund der Zeilenbegrenzung?
> ist nicht automatisch analysierbar.
Wenn sich ein Assemblerprogrammierer nicht an die Regeln der
strukturierten Programmierung hält, kann ein Autmatismus halt nur ein
Flussdiagramm mit chaotischen Pfeilen erstellen.
Ist aber immer noch übersichtlicher als Jump-Befehle und Labels.
Vielleicht hat Mark ja Glück und das Flussdiagramm zeigt Schleifen und
saubere Module.
Einfach mal die Demo runter laden und schauen, ob ein Diagramm besser
ist, als der Quelltext.
Da du die Originalquellen hast, ist doch die grobe Struktur schon "dekodiert" (Hauptschleife, benamte Unterprogramme, sinnvolle Variablennamen, etc) - viel mehr, als jedes automatisierte Tools erzeugen könnte. Den Rest wirst du dir, wenn der Author für Rückfragen nicht zur Verfügung steht, selbst erarbeiten müssen ...
Mark K. schrieb: > Meinst Du die Software als solche, also deren Funktionieren/Ergebnis, > oder nur die Demo zum Ausprobieren aufgrund der Zeilenbegrenzung? Aufgrund der DEMO Zeilenbegrenzung wage ich nicht über die Software als Ganzes zu urteilen ;-)
Hast Du Dir schonmal den Binärcode mit Radare2 angeschaut? Das kann Dir zumindest schon mal Branches und Schleifen visualisieren. Wenn Du den orginalen Quelltext daneben legst hilft das vielleicht.
c-hater schrieb: > Stark optimierte Assemblerprogramme besitzen kaum noch eine erkennbare > Struktur. Das ist das Problem. Man kann auch in Assembler Daten strukturieren und Aufgaben in Unterfunktionen kapseln. Und oftmals kann man dann auch besser optimieren, da man den Flaschenhals besser erkennen kann. Der Call/Return Overhead ist in der Regel unbedeutend. Allerdings sind Assemblerprogrammierer zum Großteil Anfänger und kennen diese Prinzipien noch nicht. Und besonders beim PIC mit seinem limitierten Hardwarestack und Unterteilung in Codepages wurde nur äußerst sparsam gecallt. Das fehlende Push/Pop erschwert es auch sehr, lokale Variablen anzulegen.
Na gut bzw. schlecht, anscheinend ist euch keine derartige Software bekannt, so daß ich um diese Arbeit nicht herumkomme. Damit ist meine Frage beendet, danke.
Mark K. schrieb: > so daß ich um diese Arbeit nicht herumkomme. Ich würds dann aber gleich in C schreiben.
Yusuf schrieb: > Ida Pro von HexRay Oder eben radare2 wenn er keine Unsummen von Geld investieren will.
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.