Hallo,
ich weiss nicht, ob meine Frage bei "Programmieren allgemein richtig ist, aber ich versuche es trotzdem eimal.
Wenn man in einem Hexeditor arbeitet, dann kann man ja bestimmte Strings nur insofern verändern, wie der alte String an Zeichen Lang ist.
Wenn man einen neueren kürzeren haben will, dann kann man 00 im Hexcode hinzufügen.
Doch wie macht man es wenn der neue String länger sein soll, ohne das beim Ausführen ein Fehler auftritt.
P.S: Ich will eine .exe verändern
mfg Daniel
Wenn man einen neueren kürzeren haben will, dann kann man 00
im Hexcode hinzufügen.
Doch wie macht man es wenn der neue String länger sein soll,
ohne das beim Ausführen ein Fehler auftritt.
Ganz einfach, man ändert den String und compiliert das Programm neu.
P.S: Ich will eine .exe verändern
Mit einem Hexeditor kannst du das schlicht vergessen.
Irgendwo Im Programm, manchmal auch an mehreren Stellen, ist ein Zeiger welcher auf den Anfang des Strings zeigt. Irgendwo zeigt ein anderer Zeiger auf den String, welcher hinter dem Ersten liegt. Je nach Compiler und Linker können zwischen diesen Strings noch andere Werte abgelegt sein…
Ganz lustig wird es, wenn die Strings in einem Array abgelegt sind, dann ist nur die Basis-Adresse des Array im Programm abgelegt und der Rest wird, anhand der dem Compiler bekannten Länge der Strings, zur Laufzeit berechnet.
MfG Peter(TOO)
Deassemblieren
Du kannst die EXE in eine Assemblercode umwandeln und dann den String bearbeiten. Danach assemblierst du und die EXE sollte funktionieren (sofern keine gegenmaßnahmen im Code vorhanden sind)
Hallo Fragewurm,
Du kannst die EXE in eine Assemblercode umwandeln und dann den
String bearbeiten. Danach assemblierst du und die EXE sollte
funktionieren (sofern keine gegenmaßnahmen im Code vorhanden
sind)
Hast du das schon einmal praktisch gemacht ?
MfG Peter(TOO)
Selbst gemacht hab ich es noch nicht. Ich hab allerdings schon ein paar Assemblerprogramme für MIPS Prozessoren geschrieben und bin mit dem Thema und der Funktionsweise von (dis/)assemblieren vertraut.
Aber wenn man nur einen String manipulieren will, ist das ganz simpel.
Hier mal ein Beispiel:
.MODEL Small
.STACK 100h
.DATA
HW DB 'Hello World!$'
.CODE
start:
MOV AX,@data
MOV DS,AX
MOV DX, OFFSET HW
MOV AH, 09H
INT 21H
MOV AH, 4Ch
INT 21H
end start
Ein Assemblerprogramm wird 1 zu 1 in Binärcode gewandelt. Dh. es gibt nur eine gültigen Binäre kombination der Bits. Genau so kann man es 1 zu 1 zurück wandeln.
Das einzige was verlohren geht sind die Namen der Sprung- und Speichermarken.
Diese werden dann meist (je nach verwendeten Programm) einfach durchnummeriert.
So wird HW DB ‚Hello World!$‘ zu D1 DB ‚Hello World!$‘ und start: zu l1:. Da aber die Strings, die manipuliert werden sollen, bekannt sind, ist es kein Problem diese zu finden und zu ändern.
Hallo Fragewurm,
Selbst gemacht hab ich es noch nicht.
Genau das merkt man 
Ein Assemblerprogramm wird 1 zu 1 in Binärcode gewandelt. Dh.
es gibt nur eine gültigen Binäre kombination der Bits. Genau
so kann man es 1 zu 1 zurück wandeln.
Kann man eben nicht so einfach.
Das Problem ist, dass man einer Bitkombination nicht ansieht ob es ein Opcode oder Daten sind.
Bei CISC-Prozessoren sind netterweise die Opcodes unterschiedlich lang. Bei der X86 Architektur gibt aus noch Prefixe.
Die Programme werden meist in einer Hochsprache geschrieben und Compiler machen dann auf Codeebene recht lustige Konstrukte.
Merfachverzeigunen werden oft mit Hilfe von Spungtabellen realisiert.
Du erhältst also Opcodes, dann folgen Adressen und dahinter liegt wieder Code. Hier synchronisiert der Disassembler nicht richtig, weil er schon die Adressen als Code decodiert.
Du erhälst also nur wirres Zeugs.
Beim 6503 oder 8080 gab es auch noch einen faulen Trick:
Es gab einen Spungbefehl „Branch Never“ mit einer 16 Bit Zieladresse. Als Zieladresse hat man dann eine 8-Bit immediate Ladebefehl rein gepackt, welcher 16 Bit lang war.
Also
LBL1: LDA #0
LBL2: BRA LDA #01
LBL3: BRA LDA #02
LBL4: BRA LDA #03
Springt man LBL1: an befindet sich in A = 0
Springt man LBL2:+1 an befindet sich in A = 1
Springt man LBL3:+1 an befindet sich in A = 2
Dein Disassembler bekommt so etwas nie gebacken.
Lustiges entsteht oft auch durch den Linker.
Je nach der Einstellung des Alignements, werden Module z.B. immer an eine restlos durch 4 Teilbare Adresse gepackt. Es müssen also 1-3 Bytes zum Füllen eingefügt werden. Da diese normalerweise NIE von der CPU verarbeitet werden, können diese Zufallswerte haben. Das weiss dein Disassembler aber nicht und er erzeugt was unsinniges.
MfG Peter(TOO)
Hallo,
schade das es nicht machbar ist.
Trotzdem danke für eure Hilfe.
mfg Daniel