"Quellcode" aus *.exe lesen

[phaaaz]

Hallo,

mich würde interessieren, wie man herrausbekommen kann, was ein bestimmtes Programm macht, wenn man es ausführt.

Nehmen wir als Beispiel mal einen FOV Changer für Call of Duty.

Wenn ich diesen ausführe, passiert etwas, aber ich weiß nicht was und am Ende ist meine FOV geändert.

Ich würde gerne wissen, in welche Datei er was schreibt bzw. was er verändert.

Wie kann ich das herrausfinden?

 

[bu1137]

Wenn's eine .exe ist, dann musst du wohl Assembler lernen, um das Programm zu verstehen.

Um einfach zu sehen, welche Datei(en) geöffnet/verändert werden, kannst du zb. Process Monitor verwenden.

Und um zu sehen, was genau geändert wurde: Eine Kopie (original) mit der veränderten Datei vergleichen.

 

[FreddyMercury]

LOL du bist lustig. Du kannst kompilierten code nicht auslesen, mit wenigen Ausnahmen wie Java und C#. Allerdings kannst du http://ollydbg.de/ dahin gehen und dir den disassembler runterladen. Damit kannst du den code disassemblieren und im Assembly code rumgucken.

 

[phaaaz]

Also gibt's kein Programm, womit man schauen kann, was ein bestimmtes Programm alles macht?

 

[bu1137]

Sagte ich doch bereits: Process Monitor

Das zeigt dir allerdings nur bedingt, was genau passiert. Aber viel mehr wird dir selber auch nicht viel nützen.

 

[twilight]

Wenn dich sowas wirklich interessiert, solltest du dich mal über Reverse Engineering informieren, aber ums kurz zu machen: nein es gibt keinen einfachen Weg aus einer .exe etwas über deren Verhalten zu erfahren.

 

[phaaaz]

Und wie ist es, wenn ich eine *.DLL mit z.B. Winject injecte?

Kann ich bei der *.DLL schauen, was die macht?

 

[QDOS]

rofl nein, wenn es kein .NET assembly ist, ist eine DLL ebenso reiner Assembler Code wie eine EXE...

 

[kaderekusen]

das versucht man doch seit etlichen Jahren mit Windows auch. und Microsoft weigert sich den Quellcode zugänglich zu machen.

 

[schamsen]

warum sollten sie auch den code rausrücken ? bei ms gibts kein geistiges eigentum ?

 

[Kanibal]

Nein, das funktioniert nicht wirklich sinnvoll.

 

[ice-breaker]

Du kannst nur wirklich sinnvoll Zustand deines Systems vor und nach diesem Tool vergleichen, dann solltest du wissen was und wie es geändert wurde, warum es gemacht wurde, weisst du aber nicht.
Tools mit denen du Snapshots eines Systems vergleichen kannst, müsstest du selbst suchen, da habe ich gerade nichts parat.

 

[Hancock]

Also der FOV Changer wird zwei Möglichkeiten ausnutzen, um das FOV zu ändern.
1. Die Spiel Konfiguration dahin ändern, mittels Reverse Engineering an die Speicherpositionen kommen und umschreiben.
2. Den Shader disassemblieren, beispielsweise mit PIXWin (in der DirectX SDK) um zu ermitteln, welche Matrix im Vertexshader die Perspektivkorrektur enthält, dann über einen function-Hook die DX-Calls unterbrechen und die Matrix ensprechend umschreiben.

Was der FOV-Cahnger wirklich macht: Debugger anschmeißen und den mal ausführen, die Breakpoints dann halt an taktisch günstige Stellen setzten.

Fazit: Nix für Noobs da muss man schon ordentlich Experte sein, um so was zu programmieren und dann noch mehr Experte um sowas wieder zu verstehen, v.a. ohne Quellcode.

 

[dcobra]

Ich würde gerne wissen, in welche Datei er was schreibt bzw. was er verändert.

Wie kann ich das herrausfinden?

Naja, Dateien kann man automatisch überwachen lassen, da musst du nichts über die .exe wissen. Vielleicht mal hier ansetzen.

edit: nach Hancoks Post zu urteilen passiert da mit Dateien aber wohl nicht viel.

 

[Hancock]

Mit Dateien wäre es wegen Cheatschutz etwas gefährlich, die prüfen ja gerne mal die Dateiintegrität. Aber in der DX-Lib rumzufuhrwerken ist schwer zu erkennen/unterbinden (v.a. machts Fraps bspw. so und würde so zu vielen False-Positives beim Cheaten führen).

Was eine exe insgesamt "macht", ist nicht so schwer zu erraten oder gar nicht zu erraten
Viele Programme sind sehr transparent geschrieben, calc.exe hat vielleicht als einziges Geheimnis, wie man die Fakultät aus Kommazahlen berechnet...
Aber so was wie winlogon.exe oder dwm.exe sind trotz ein paar Debuginfos von MS immer noch kaum zu verstehen. Dabei machen die mit Dateien gar nix.

Solltest du wirklich mal rausfinden wollen, was ein (wirklich kleines) Programm macht, dann nichts wie ran an den Debugger und los gehts, plan mal ein paar Tage ein und du findest es mit viel Googlen raus.