*exe decompilieren

MosKiller schrieb:
> Ich muss nicht jedes Detail ändern, aber es gäbe einige Punkte ich ich
> an einem Programm anpassen würde.

Nicht ernsthaft.

Microsoft hat das vor kurzem mal gemacht, weil sie in einer DLL aus den 
90gern noch ein paar Sicherheitslücken fixen mussten - und sie wohl 
selber den Source nicht mehr haben oder der nicht mehr compiliert.

Das ist aber übelst aufwändig. Denn man muss den Programmfluss aus den 
Instruktionen rekonstruieren - und der hat nach dem C-Optimizer nur noch 
vage Ähnlichkeit mit dem originalen Programm.

Versuche mal ein optimiertes Programm schrittweise zu debuggen - der 
springt wild zwischen den Source Zeilen hin- und her.

Stell Dir einen Klumpen Hackfleisch vor.
Und jetzt, wie man den wieder zur Kuh macht.


Das bringt es, leicht vereinfacht, auf den Punkt.

MosKiller schrieb:
> Ist sowas möglich? Ich habe Visual Studio Pro 2015.

Man nimmt dafür spezialisierte Tools wie IDA. Aber normalerweise ist den 
Source zu ändern etliche Größenordnungen einfacher.

Bei einer .exe für die DOS-Komandozeile ohne grafische Oberfläche konnte 
man sowas noch mit vertretbarem Aufwand machen.

Für eine Win-.exe - no Way.

eid.exe schrieb:
> Das kommt drauf an was es davor war. C# exen lassen sich zB sehr gut
> decompilieren. zB das Programm Reflector von Redgate decompiliert .Net
> Code


vs.

Max M. schrieb:
> Bei einer .exe für die DOS-Komandozeile ohne grafische Oberfläche konnte
> man sowas noch mit vertretbarem Aufwand machen.
>
> Für eine Win-.exe - no Way.

Es geht mit Reflector sehr einfach... Wars vorher C++ ist das eine 
andere Sache.

Wenn Du nicht ganz fit bist, bei allem was rund um die Assemblersprache 
passiert und was im System selber los ist: Vergiss es!
Es sei denn Du hast eine stark, masoschistische Ader.

@MosKiller,

lass Dich nicht entmutigen.
Abhängig von Deiner Problemstellung könnte
Dir das Tool radare2 (in github) helfen.
Ist ähnlich wie IDA nur frei, da Open Source.
Eine gewissen Lernaufwand musst Du aber natürlich
in Kauf nehmen und Zeit rein stecken.

Kleine Variationen im Programm mittels Patches
(binär) sind durchaus leicht machbar. Dazu gibt
es Tools die selbst Prüfsumengesicherten Code
modifizieren, sofern es sich um ein übliches
Format PE, ELF etc. handelt.

Wir hatten mal den Fall, daß in einer Software
aufgrund einer geänderten Struktur in den Daten
der Datenstrom, den das Programm zu verarbeiten
hatte, zum Absturz des Programms führte - wegen
Integer Überlauf.

Das Format der Daten hat sich zwar prinzipiell
nicht geändert aber es wurde eine Variable nun
mit UINT statt INT Werten belegt und das MSB
daß nun öfter vorkam brachte den Überlauf.
Es galt den INT Wert in einen UINT Wert
zu ändern.

Da die Typen von Variablen in Definitionen beim
Laden des Programms ins RAM vermerkt sind,
galt es nur diese Stelle zu finden und entsprechend
zu modifizieren. Das Programm war in C der 90ziger
Jahre geschrieben und weil von Externen auch ohne
Code-Dokummentation im Einsatz.

Es gibt heute ausgezeichnete Software, die zwar teuer ist,
zum Kaufen - siehe Firma Hexray - aber auch gute freie Software
die in github zu finden ist um Programme zu analysieren
oder gar zu decompilieren.

Siehe z.B.
https://www.hex-rays.com/products/decompiler/manual/index.shtml

Markus

Jim M. schrieb:
> Microsoft hat das vor kurzem mal gemacht, weil sie in einer DLL aus den
> 90gern noch ein paar Sicherheitslücken fixen mussten - und sie wohl
> selber den Source nicht mehr haben oder der nicht mehr compiliert.

Quellenangabe?

Bernd K. schrieb:
> Quellenangabe?

Hier: 
https://www.bleepingcomputer.com/news/microsoft/microsoft-appears-to-have-lost-the-source-code-of-an-office-component/

@Dr. Sommer

a) da hängt natürlich vom Compiler ab, was für
   Maschinencode er wo einsetzt (da hast Du natürlich recht)

b) von executable Format selbst, was mit Manipulationen mach-
   bar ist und was nicht.


Für PE Executables gibt es ein Beispiel unter

h t t p s:
//resources.infosecinstitute.com/applied-cracking-byte-patching-ida-pro/

Wir haben seinerzeit ein ELF Binary unter CentOS 4.x modifiziert und
sind an der von Dir genannte Problematik nicht gestolpert.
Ob das im Nachhinein nur ein Glücksfall war und der comilierte
Code nicht alle Optimierungsfinessen enabeld hatte kann ich jetzt
nicht mehr sagen.

Ich habe schon in meiner Studienzeit (vor 35 Jahren) Turbo-Pascal
Compilate binär gepatched um das Ende-Kriterium einer For-Schleife
zu erhöhen. War auch nicht weiter schwierig.

Es ist vom Fall zu Fall mehr oder minder schwierig und sollte nicht
von vornherein ausgeschlossen werden.

Markus