Benutzer-Werkzeuge

Webseiten-Werkzeuge


Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung
Nächste Überarbeitung
Vorherige Überarbeitung
Nächste Überarbeitung Beide Seiten, nächste Überarbeitung
skripten:engineforschung [2018/09/09 17:04]
mud-freak [Strings-Fenster]
skripten:engineforschung [2018/09/09 17:12]
mud-freak [Register]
Zeile 90: Zeile 90:
  
 ==== ESP ==== ==== ESP ====
 +
 +{{  :​skripten:​engineforschung:​stack.png?​400| Maschinenstack und ESP }}
 +
 ESP zeigt auf den derzeitigen [[#​Maschinenstack|Stackanfang]]. Den brauchen wir also um an auf dem Stack abgelegte Daten heran zu kommen. Deshalb finden wir in Hookfunktionen in Daedalus-Skripten ESP recht häufig. So kann die Hookfunktion Daten auslesen, die zum Zeitpunkt des Hooks auf dem Stack liegen sind. //"​Derzeitigen Stackanfang"//​ deshalb, weil beim Ablegen (push) auf den Stack der Stackpointer um die abgelegte Anzahl an Bytes verringert wird (der Maschinenstack wächst nach unten) und beim Herunternehmen (pop) wieder entsprechend erhöht wird. In IDA finden wir häufig ''​ESP+X''​. Das ''​X''​ steht dabei für den [[#​Stackoffset|Stackoffset]],​ den wir auch in IDA in der zweiten Spalte der Zeile einsehen können. Jedes mal wenn etwas auf den Stack gelegt wird (mit der Instruktion ''​push''​),​ wird ESP entsprechend verringert und der Stackoffset erhöht. Nach beliebig vielen neuen Werten auf dem Stack können wir später trotzdem immer (solange unserer Wert nicht gepoppt ist) mit Hilfe des Stackoffsets ''​X''​ an die Daten kommen: ''​ESP+X''​. ESP zeigt auf den derzeitigen [[#​Maschinenstack|Stackanfang]]. Den brauchen wir also um an auf dem Stack abgelegte Daten heran zu kommen. Deshalb finden wir in Hookfunktionen in Daedalus-Skripten ESP recht häufig. So kann die Hookfunktion Daten auslesen, die zum Zeitpunkt des Hooks auf dem Stack liegen sind. //"​Derzeitigen Stackanfang"//​ deshalb, weil beim Ablegen (push) auf den Stack der Stackpointer um die abgelegte Anzahl an Bytes verringert wird (der Maschinenstack wächst nach unten) und beim Herunternehmen (pop) wieder entsprechend erhöht wird. In IDA finden wir häufig ''​ESP+X''​. Das ''​X''​ steht dabei für den [[#​Stackoffset|Stackoffset]],​ den wir auch in IDA in der zweiten Spalte der Zeile einsehen können. Jedes mal wenn etwas auf den Stack gelegt wird (mit der Instruktion ''​push''​),​ wird ESP entsprechend verringert und der Stackoffset erhöht. Nach beliebig vielen neuen Werten auf dem Stack können wir später trotzdem immer (solange unserer Wert nicht gepoppt ist) mit Hilfe des Stackoffsets ''​X''​ an die Daten kommen: ''​ESP+X''​.
 ==== ECX ==== ==== ECX ====
 ECX ist zwar ein Zählerregister für Schleifen, ist aber hier aus anderem Grund für uns interessant. Die //Calling Conventions//,​ die man evtl. aus C und C++ kennt, sind verschiedene Arten wie eine Funktion aufgerufen wird (z.B. wird der Stack von der Funktion selbst aufgeräumt oder muss das der Aufrufer machen?, usw.). Eine dieser //Calling Conventions//​ ist %%__%%thiscall. Während normale Argumente immer auf den Stack (siehe [[#​ESP|ESP]]) gelegt und so der aufgerufenen Funktion bereitgestellt werden, wird ''​this''​ für eine solche Funktion in ECX abgelegt. ECX ist zwar ein Zählerregister für Schleifen, ist aber hier aus anderem Grund für uns interessant. Die //Calling Conventions//,​ die man evtl. aus C und C++ kennt, sind verschiedene Arten wie eine Funktion aufgerufen wird (z.B. wird der Stack von der Funktion selbst aufgeräumt oder muss das der Aufrufer machen?, usw.). Eine dieser //Calling Conventions//​ ist %%__%%thiscall. Während normale Argumente immer auf den Stack (siehe [[#​ESP|ESP]]) gelegt und so der aufgerufenen Funktion bereitgestellt werden, wird ''​this''​ für eine solche Funktion in ECX abgelegt.
 +
 +{{:​skripten:​engineforschung:​getname.png?​400 | oCNpc::​GetName }}
  
 Speziell bedeutet das, dass in der Funktion ''​oCNpc::​GetName''​ der NPC in Frage in ECX zur Verfügung steht. ECX ist in diesem Falle also ein Zeiger auf ein oCNpc-Objekt. Schauen wir in die Funktion sehen wir, dass an Adresse ''​0x72F825''​ auf ''​ecx+124h''​ Bezug genommen wird. 124h ist hexadezimal für 292. In der Klasse oCNpc (dokumentiert in Ikarus) finden wir an Offset 292 die Klassenvariable ''​name''​. Die Funktion tut also was sie verspricht: Sie holt den Namen eines des NPC. Würden wir ''​oCNpc::​GetName''​ hooken (aus welchem irrsinnigen Grund auch immer) könnten wir in Daedalus über ECX an den NPC herankommen. Speziell bedeutet das, dass in der Funktion ''​oCNpc::​GetName''​ der NPC in Frage in ECX zur Verfügung steht. ECX ist in diesem Falle also ein Zeiger auf ein oCNpc-Objekt. Schauen wir in die Funktion sehen wir, dass an Adresse ''​0x72F825''​ auf ''​ecx+124h''​ Bezug genommen wird. 124h ist hexadezimal für 292. In der Klasse oCNpc (dokumentiert in Ikarus) finden wir an Offset 292 die Klassenvariable ''​name''​. Die Funktion tut also was sie verspricht: Sie holt den Namen eines des NPC. Würden wir ''​oCNpc::​GetName''​ hooken (aus welchem irrsinnigen Grund auch immer) könnten wir in Daedalus über ECX an den NPC herankommen.
skripten/engineforschung.txt · Zuletzt geändert: 2018/09/09 17:38 von mud-freak