Zur laufzeit Bytecode disassemblen?

[Memnarch]

Tag allerseits,
Ich beschäftige mich gerade mit dem lustigen Thema des Laufzeitpatches von Routinen in Delphi.
Vorneweg: Das mach ich nur aus interresse, und wird in keinem Produkt aktiv genutzt. Egal wie schmutzig, alles ist also erlaubt ;).

Ich gehe dabei wie folgt vor:
Ich kopiere die komplette zu patchende Routine in einen ByteArray und setze dann an den Anfang der ursprünglichen Routine einen jump in meine. SO kann ich dann in meiner routine was machen und schlussendlich die originale aufrufen.

An sich kein Problem. Der "Fehler" liegt im Detail. Nämlich die relativen CALLs in der kopierten Routine(Opcode $E8). Diese müssen neu berechnet werden. Momentan nutze ich die Disassembly-View von Delphi, um die stellen im Bytearray zu suchen, die auch tatsächlich CAlls sind, und keine zufälligen $E8(Wobei ein naiver ansatz überraschend oft funktioniert^^). Dies teil ich beim patchen mit und dann werden die routinen angepasst. Klappt einwandfrei.

Viel interressanter wäre es, wenn ich den Bytearray disassemblen könnte, um die CALLs selbst rauszufiltern und das ganze zu automatisieren.

Gibts einen einfachen X86 Disassembler den ich zur laufzeit in Delphi nutzen kann?

Andersrum würde es theoretisch schon helfen herauszufinden, wie groß ein Opcode ist und wieviel Bytes die angehängten Daten belegen um im Bytearray von opcode zu Opcode zu springen.

MFG
Memnarch

[CCRDude]

Wie wäre es mit madDisAsm? Dürfte Dir schon einen Teil der Infos liefern - auswerten, etwa nach CALLs, dürfte dann ja nicht mehr so schwer sein.

[Aviator]

Oder bringt dir vielleicht OllyDbg etwas?

[Memnarch]

Sehr Geil. Danke für die Antworten. Gerade MadShi scheint da perfect zu sein, um den Source Opcode für Opcode zu iterrieren o.O

[Bernhard Geyer]

Zitat:

Zitat von Memnarch (Beitrag 1209940)

Ich beschäftige mich gerade mit dem lustigen Thema des Laufzeitpatches von Routinen in Delphi.

Schau dir mal an was hierzu in den TNTWare-Controls implementiert ist.

[Memnarch]

@Bernhard Geyer werde ich später mal nen Blick reinwerfen.

Aktuel funktioniert mein Vorhaben blendend. Bisher konnte auch jede API funktion(und Non-Virtual Method) ohne probleme automatisch gehooked werden.

MFG
Memnarch

[Aphton]

Wenn du nur APIs hookst und diese eine Standard Strackframe-Generierung durchführen, brauchst du nicht einmal die API kopieren, sondern einfach die ersten paar Bytes (Stackframe-Generierung) mit einem Jmp zu deinem Code patchen und bei deinem Code am Schluss den Stackframe generieren.

[Memnarch]

@Aphton: Eben nicht nur API calls. Generell procedures/functions etc deren aufrufkonvention bekannt ist.

Meine Methodik klappt unabhängig vom Stackframe, dank MadShi sehr einfach, und universeller.
DU kannst auch jederzeit(sagen wir mal ich hook was von dir) deine implementation ändern und mein Hook geht immernoch(Bis du parameter/aufrufkonvention) änderst.

[Aphton]

Jo klar ist deine Variante universeller, jedoch wollte ich dir die Arbeit nur vereinfachen. Dachte mir es geht eventuell um etwas spezifisches.

[Memnarch]

Nope, es geht lediglich um meine experimentierwüterei^^