"Größe einer Funktion"
-
Wie sehen denn nun deine aktuellen Ergebnisse aus? Nutzt du die (nicht ganz saubere) Subtraktionsmethode oder probierst du dich doch an der Ablaufverfolgung des Funktioncodes?
-
Die Code Injection würde wohl auch kaum funktionieren. Du kannst nicht einfach eine Funktion für sich allein nehmen und woanders hinkopieren, da sind ja in der Regel haufenweise Absolutadressen hardcoded drin.
Wenn du es dir leisten kannst, einen Compiler aufzurufen, kannst du ja auch mal mit einem leeren Rumpf compilieren und dann die Größe des .text-Segments mit der vollständigen Version vergleichen.
-
Ringding schrieb:
Die Code Injection würde wohl auch kaum funktionieren. Du kannst nicht einfach eine Funktion für sich allein nehmen und woanders hinkopieren, da sind ja in der Regel haufenweise Absolutadressen hardcoded drin.
Wenn du es dir leisten kannst, einen Compiler aufzurufen, kannst du ja auch mal mit einem leeren Rumpf compilieren und dann die Größe des .text-Segments mit der vollständigen Version vergleichen.
Das mit der Code-Injection funktioniert sehr wohl. Du musst nur selbstverständlich Funktionsaufrufe und Stringliterale,etc vermeiden. Zum Beispiel kannst du dir Funktionspointer zu LoadLibrary, GetProcAddress und FreeLibrary übergeben und dann mit CreateRemoteThread deine Funktion ausführen, die du injected hast. Von dort aus könntest du eine weitere DLL im fremden Prozess laden und von dort aus hast du ja wieder die möglichkeit "normal" weiterzuprogrammieren
-
Ja klar geht es. Aber nur wenn man sich sehr genau überlegt, was man macht bzw. den erzeugten Code kontrolliert. In dem Fall kann man's aber eigentlich auch gleich in Assembler schreiben.
-
Ringding schrieb:
In dem Fall kann man's aber eigentlich auch gleich in Assembler schreiben.
immer gibt's was zu meckern
-
Ich will zum Beispiel einen Systemaufruf abfangen. Das Tutorial dazu verlangt im Beispiel die Größe der Funktion... :p
-
Wie meinen?
-
Ich hab einen Artikel gelesen, in dem steht wie man System-Calls (wie z.B. RegCreateKey) abfangen kann. Mit dem überschreiben bin ich schon fertig d.h. anstatt RegCreateKey wird meine Funktion aufgerufen. Und jede Anwendung denkt sie hätte da eben einen Schlüssel in der Registrierung erstellt. Sinnlos auf den ersten Blick... doch das Beispiel des Artikels bracht die Größe der Funktion um die überschriebene Funktion wieder aufzurufen (frag mich nicht warum). Also bin ich auf ins Forum und siehe da, schon ein Anderer hat meine Frage gestellt die dort erst als sinnlos abgestempelt wird. Wenn das Projekt fertig ist, kann ich besser kontrollieren, was mir in der Systemregistrierung rumgekritzelt wird. Oder noch interessanter (glaub ich) die Aufrufe in der CryptAPI...
-
Es wird doch wohl verdammt nochmal möglich sein, die Größe einer Funktion zu ermittlen!? Irgendwo muss doch der "Aussprungspunkt" im Speicher stehen?!
Wäre es vielleicht möglich, den Einsprungspunkt der folgenden Funktion zu nehmen -1?
-
Such (Google) mal nach API-Hooking. Glaub kaum das man dafür die Grösse der
Funktion wissen muss.
Ich könnte mir vorstellen das "Shade of Mine" mit seinem "Sinn-Beispiel" bei
dir genau richtig liegt, jetzt wo wir was was du willst, kann man dir
vielleicht etwas besser helfen.
-
Mit der Registry waren andere schon schneller
Wenn du nur mal einen Überblick brauchst, lass den Linker ein map-file generieren, und subtrahier die Adressen (funktioniert im Prinzip wie das subtrahieren von Funktzionszeigern - auch nicht immer)
Es wird doch wohl verdammt nochmal möglich sein, die Größe einer Funktion zu ermittlen!?
Was ist "die Größe einer Funktion" ?
-
Ich bin nicht icy.
Ich habe das gleiche Problem und habe euch deshalb ein Beispiel gegeben, wofür man sowas brauchen kann!
Größe der Funktion ist eigentlich der Offset, der Platz den die Maschinencodebefehle im Speicher verbrauchen.
Vielleicht kann man einen OpCode Header von Intel nehmen und die Prozedur analysieren...
-
Ich hab doch "die" Lösung schon gepostet, damit gibt's keinen Grund zu Beanstandungen. Ich konnte das mit VS 6.0 und 7.1 kompilieren und es lief auch auf jedem System ohne Probleme. Und wenn dir diese Methode zu unsicher ist, musst du eben deine Opcodes analysieren, aber das wurde hier auch schon erwähnt und ist weitaus aufwändiger.
-
Damit sich niemand beirren lässt:
Das subtrahieren funktioniert auf keinen Fall, da zwischen den Funktionen oft leerräume im Speicher sind!
Und drum bekomme ich nicht meine 74 zurück sondern 96!!!
Debuggerauszug:
... 100: { 101: return true; 10001521 B0 01 mov al,1 10001523 EB 02 jmp ValidCompilation+37h (10001527) 102: } 103: return false; 10001525 32 C0 xor al,al 104: } 10001527 5F pop edi 10001528 5E pop esi 10001529 5B pop ebx 1000152A 8B E5 mov esp,ebp 1000152C 5D pop ebp 1000152D C3 ret --- No source file -------------------------------------------------------------------------------- 1000152E CC int 3 1000152F CC int 3 10001530 CC int 3 10001531 CC int 3 10001532 CC int 3 10001533 CC int 3 10001534 CC int 3 10001535 CC int 3 10001536 CC int 3 10001537 CC int 3 10001538 CC int 3 10001539 CC int 3 1000153A CC int 3 1000153B CC int 3 1000153C CC int 3 1000153D CC int 3 1000153E CC int 3 1000153F CC int 3 --- C:\Dokumente und Einstellungen\Uli Hecht\Eigene Dateien\Projekte\Sonstiges\testelmechtel mit C++\WMP@ï „ÜsŒí 105: 106: //Prüft ob TrampolineProc() größer als 10 Byte ist 107: bool ValidTrampolineProc() 108: { 10001540 55 push ebp...