Assambler (externe Funktionen in Windows)
-
Hi
Also ich habe ein paar eher allgemeine Fragen zum aufbau und zu den Standardbibliotheken von Windows.
1)Also wenn ich in Assambler eine Windows Funktion aufrufe z.b.: call MessageBoxA dann wird die beim Kompilieren ja in eine Adresse umgewandelt.
Also muss der Assambler nicht eigentlich zuerst mit LoadLibrary die Adresse der DLL herauskriegen um die Funktion zu addressieren?Wenn er das macht wieso krieg ich dann davon nichts mit? Ich schreib ja den Befehl nirgends rein.
2)Gibt es Dissassambler die das wiederherstellen koennen?
Also das dann call XY statt call 0xF83... steht?3)Was ist eigentlich der Unterschied zwischen einer Win32 Anwendung und einer WinConsolen Anwendung?
Bzw. Wie wird dass gemacht, dass eine Konsole aufgeht?4)Wenn ich eine Exe mit Texteditor oder Hexeditor oeffne dann kommen am Ende woerter vor, die spintf printf etc. die ganzen C Standardfunktionen wieso ist das so? Bzw. bei Debugging exes waere mir das klar aber bei normalen release exes von VC++ kommt mir das schon komisch vor
5)Assambler ist doch im Grunde eine OS unabhaengige Sprache oder?
(Also so unabhaengig wie C/C++ halt die API calls sind je nach OS natuerlich verschieden)6)Wenn ich eine exe Dissambiliere und dann wieder Assambiliere/kompiliere sollte genau das selbe wieder rauskommen oder?
Buh ganz schoen viele Fragen was...
danke
Lukas
-
einKI schrieb:
2)Gibt es Dissassambler die das wiederherstellen koennen?
Also das dann call XY statt call 0xF83... steht?Dazu müssten die Debug-Informationen in der Datei mit abgespeichert sein.
einKI schrieb:
3)Was ist eigentlich der Unterschied zwischen einer Win32 Anwendung und einer WinConsolen Anwendung?
Bzw. Wie wird dass gemacht, dass eine Konsole aufgeht?Ähm, das einmal GUI-Elemente verwendet werden und einmal eine Textkonsole? Oder was meinst du?
einKI schrieb:
5)Assambler ist doch im Grunde eine OS unabhaengige Sprache oder?
(Also so unabhaengig wie C/C++ halt die API calls sind je nach OS natuerlich verschieden)Im Grunde sind alle Sprachen systemunabhängig.
einKI schrieb:
6)Wenn ich eine exe Dissambiliere und dann wieder Assambiliere/kompiliere sollte genau das selbe wieder rauskommen oder?
Ich wage es zu bezweifeln, dass du es schaffst, ein Disassemblat einfach wieder zu assemblieren.
-
einKI schrieb:
1)Also wenn ich in Assambler eine Windows Funktion aufrufe z.b.: call MessageBoxA dann wird die beim Kompilieren ja in eine Adresse umgewandelt.
Also muss der Assambler nicht eigentlich zuerst mit LoadLibrary die Adresse der DLL herauskriegen um die Funktion zu addressieren?Jein. Das DLL-Konzept arbeitet so: In einer Tabelle in der EXE steht, welche DLL-Aufrufe man hat, und zwar meist mit Namen. Dort steht auch, wohin das ergebnis (die Adresse der geladenen Funktion) soll. Ein Aufruf sieht dann so aus:
; Hier wird in dnem code die API aufgerufen: call 12345678 ... ... ... 12345678: jmp XXXXXXXX
An dem XXXXXXXX setzt der Windows-PE-Lader die Adresse der Funktion ein. So braucht sich dein Programm dann nicht merh darum kümmern, passiert alles beim laden der EXE.
Wenn er das macht wieso krieg ich dann davon nichts mit? Ich schreib ja den Befehl nirgends rein.
Weils halt alles vor ausführung des Codes passiert
2)Gibt es Dissassambler die das wiederherstellen koennen?
Also das dann call XY statt call 0xF83... steht?Ja, der IDA macht das mit WinAPI z.B. und auch mit einigen anderen DLLs. Der kann ja sehen, wohin die calls in der Sprungtabelle sehen, und was dort eingefügt werden muss.
3)Was ist eigentlich der Unterschied zwischen einer Win32 Anwendung und einer WinConsolen Anwendung?
Bzw. Wie wird dass gemacht, dass eine Konsole aufgeht?Ich glaube das ist nur ein kleines Bit im Dateiheader.
4)Wenn ich eine Exe mit Texteditor oder Hexeditor oeffne dann kommen am Ende woerter vor, die spintf printf etc. die ganzen C Standardfunktionen wieso ist das so? Bzw. bei Debugging exes waere mir das klar aber bei normalen release exes von VC++ kommt mir das schon komisch vor
Weil die bei dynamisch gelinkter standardbibliothek wohl auch als DLL-Importe auftauchen, also deren Code ebenso wie die WinAPI erst eingesetzt werden. Ich glaube bei M$-Visual C war das z.B. die MSVCRT.DLL
5)Assambler ist doch im Grunde eine OS unabhaengige Sprache oder?
(Also so unabhaengig wie C/C++ halt die API calls sind je nach OS natuerlich verschieden)Das wurde schon gut beantwortet
6)Wenn ich eine exe Dissambiliere und dann wieder Assambiliere/kompiliere sollte genau das selbe wieder rauskommen oder?
Angenommen du findest einen Disassembler, der die Daten so disassembliert, dass ein Assembelr das wieder frisst, ja.
-
Angenommen du findest einen Disassembler, der die Daten so disassembliert, dass ein Assembelr das wieder frisst, ja.
Aber das ist nicht sehr realistisch oder?
Und wieso eigentlich sollte der Dissassambler nicht genau das wieder rueckgaengig machen was der Assambler gemacht hat?Und steht eigentlich nirgends in der exe welche Dll's verwendet werden?
danke fuer die langen Antworten
by
-
einKI schrieb:
Angenommen du findest einen Disassembler, der die Daten so disassembliert, dass ein Assembelr das wieder frisst, ja.
Aber das ist nicht sehr realistisch oder?
Jup, so siehts aus
Und wieso eigentlich sollte der Dissassambler nicht genau das wieder rueckgaengig machen was der Assambler gemacht hat?
Weil die meisten Disassembler dazu da sind, Code zu betrachten und nicht zu ändern. Und beim betrachten sind halt viele Zusatzinfos im Ausgabeformat besser.
Und steht eigentlich nirgends in der exe welche Dll's verwendet werden?
Klar steht das da, wie soll denn sonst der PE-Lader von Windows wissen, woher er die Importierten Funktionen nehmen soll.