Hallo, gibt es eine Möglichkeit, eine *exe eines Programms nachträglich zu bearbeiten/decompilieren? Ich muss nicht jedes Detail ändern, aber es gäbe einige Punkte ich ich an einem Programm anpassen würde. Ist sowas möglich? Ich habe Visual Studio Pro 2015.
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.
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
Vielleicht hilft das hier, vielleicht auch nicht: https://www.youtube.com/watch?v=G0o2HaJwLQo Ist nur als "Einstieg" zu verstehen, um einen kleinen Überblick zu erhalten. Zumindest weißt du dann wonach du suchen kannst. Ich glaube aber nicht, dass man so ernsthafte Änderungen an Programmen vornehmen kann. Vielleicht Kleinigkeiten, aber mehr auch nicht.
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.
Max M. schrieb: > Für eine Win-.exe - no Way. Na na, natürlich, Du kannst es vielleicht nicht, und je grösser das Programm ist um so aufwändiger, aber möglich ist es schon. Zumindest das Disassemblieren ist mit IDA https://www.chip.de/downloads/IDA-Pro-Free-Letzte-Freeware-Version_29744270.html einfach, dann zum C-Code zu kommen kann mit Snowman klappen oder auch nicht https://derevenets.com/
Sebastian S. schrieb: > Es sei denn Du hast eine stark, masoschistische Ader Masochismus hilft da auch nicht weiter. Es gibt ja Leute, die so etwas machen, z.B. um in fremder Software Sicherheitslücken zu finden. Aber das sind die besten Spezialisten ihres Fachs, mit jahrelanger Erfahrung, und die beschäftigen sich Monate und Jahre mit einem bestimmten Problem. Melde dich so um das Jahr 2025 wieder, ob du was erreicht hast. Georg
@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?
Markus W. schrieb: > Da die Typen von Variablen in Definitionen beim > Laden des Programms ins RAM vermerkt sind, Wo das denn bitte? Und wo berücksichtigt der Maschinencode irgendwelche Variablendefinitionen? Wenn da ein "Signed Multiply" im Code ist, dann nimmt das immer an die Variable sei "signed", egal was wo im RAM steht...
Bernd K. schrieb: > Quellenangabe? Hier: https://www.bleepingcomputer.com/news/microsoft/microsoft-appears-to-have-lost-the-source-code-of-an-office-component/
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 Ist da ja auch kein Kunststück, weil die Compilierung zum lauffähigen Program erst zur Laufzeit erfolgt. @TO Es gibt Programme die aus der Exe zumindest Assembler erzeugen können, aber dann mußt Du in Assembler mehr als fit sein, um da was anpassen zu können. Problematisch wird es wenn Code einfügen mußt, dann stimmen oft die Sprungadressen nicht mehr. Es kommt halt darauf an was Du vor hast. Einfach ist aber anders.
@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
:
Bearbeitet durch User
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.