|
wrapper vs. function hook - theorie
Hi
Ich versuch gerade ein paar dinge zu verstehen und ich hoffe hier kann mir jemand helfen. Also wie man eine function in einem Programm hookt hab ich verstanden - sowohl theorie als auch praxis. Aber ich würde jetzt gerne den unterschied zu einem wrapper verstehen. Ein wrapper spiegelt ja praktisch alle funktionen einer library wieder. Also es werden alle funktionen und proceduren exportiert und die jenigen auf die man zugreifen möchte werden darin verwendet. Was mir hier fehlt ist, wie das denn implementiert wird. Also was mach ich mit einer library die ein wrapper ist? und was passiert wenn die geladen wurde. Beim function hook ist klar, daß von der Einsprungadresse der function auf die neue funktion umgeleitet wird und dann wieder zurück um die original auszuführen. Was passiert hier aber bei einem Wrapper bzw. warum führt der prozess den wrapper aus? Ich weiß, daß die wrapper .dll die originale ladet und dann praktisch die funktionen und proceduren der originalen übergiebt. Aber wie mach ich dem prozess in dem fall klar den wrapper auszuführen und nicht die originale .dll?. Danke Arnulf |
Re: wrapper vs. function hook - theorie
Hallo Arnulf,
ich habe den Eindruck, dass du auf zwei Hochzeiten tanzt. Du sprichst von einem "function hook" und einer "wrapper library". Besser wäre eine gemeinsame Betrachtungsebene - bleiben wir bei der Funktion. Was du "hook" nennst, kannst du in fast jeder Komponenten-Klasse beobachten: Viele Methoden erledigen nur das house keeping im framework, der Anwendungs-Code wird von dir über die Event-Properties quasi injiziert. Eine solche Methode prüft, ob du eigenen Code für ein bestimmtes Event angemeldet hast und führt diesen Code zum richtigen Zeitpunkt aus. Einen Wrapper verwendest du immer dann, wenn du mit der Aufrufschnittstelle einer Funktion unzufrieden bist. Durch einen Wrapper (auch Adapter genannt) stellst du eine dir genehme Schnittstelle zur Verfügung und rufst intern die ursprüngliche Funktion auf. Daneben kann dein Code noch anderes erledigen. Im Prinzip ist das die Umkehrung des "hook" Prinzips. Mal ist dein eigener Code innen, mal ist er außen. Grüße vom marabu |
Re: wrapper vs. function hook - theorie
Also, ein DLL Wrapper ist im grunde eine DLL ("fake" dll) die die selben Funktionen exportiert, wie eine andere DLL (original dll), nur dass diese Funktionen die die fake dll exportiert wiederum die original-funktionen aufrufen, aus der originaldll. Somit kann man natürlich auch in manchen Funktionen noch zusätzlichen Code unterbringen.
Das laden ist ganz einfach: Entweder man ersetzt die original dll durch die fake dll, oder man setzt die fake dll einfach an eine "frühere" stelle im suchpfad, was z.B. einfach das Programmverzeichnis sein kann, in dem das Programm liegt. Somit findet das Programm bei der "suche" nach der dll im normalfall zuerst die fake dll, welche dann im normalfall auch geladen wird. Die Fake DLL sollte allerdings nicht "sich selbst" finden, wenn sie nach der original dll sucht ... Allerdings rate ich von DLL-Wrappern ab, da sie (theoretisch) Betriebssystemspezifisch sein müssen, genauso wie jedes "original-dll-update" eine neue, veränderte "fake-DLL" mit sich ziehen kann. Dazu ist das ganze meist sau viel arbeit, vorallem bei größeren dlls ... ciao, Philipp |
Re: wrapper vs. function hook - theorie
hm... - was soll ich jetzt sagen :)
also ich hab vor 10 jahren aufgehört zu programmieren und da hatte man nur 2 register :) und von multithreading gabs nur theorie - und zeitscheiben schon garnicht :) Ich versuch mit meinem Projekt da einiges aufzuholen - egal. Ich hab bisher 3 methoden kennen gelernt wie man eigenen code in einen laufenden prozess bekommt. 1. api hook auf loadlibrarya in der kernel32.dll - damit kann man eine .dll laden lassen und dann eben funktionen im programm hooken - vom prozess aus hat man ja zugriff auf alle handles. 2. man verschafft sich speicher im prozess (virtualallocex) und schreibt seine eigene funktion. hier verschafft man sich die einsprungadresse der original funktion und springt auf seine eigene injizierte und dann wieder zurück. 3. ein wrapper - im prinzip wird dem prozess vorgegaukelt es handelt sich um die original .dll. methode 1 hab ich soziemlich verstanden - mit beiden anderen hab ich probleme. für 2. hab ich noch keine sourcen gesehen nur funktionierende programme und deshalb hab ich da nur theoretische ahnung. Ich versuch einfach mal wrapper zu verstehen und dann kümmere ich mich um 2 tens :). c113plpbr hat jetzt 2 methoden genannt. 1. suchpfad - ja klar im prozessverzeichnis - ist ja immer die erste adresse :) 2. komplett ersetzten - naja einen wrapper zu schreiben der nur funktionen exportiert geht ja, aber in dem fall müsste man ja die original .dll umbenennen und dann von der wrapper .dll laden lassen. Das würde aber auch vorraussetzen, daß der prozess noch garnicht läuft. In beiden fällen kann ein wrapper also nur verwendet werden, wenn der prozess erst nacher gestartet wird?? Zitat:
Ich hoffe ihr helft mir auf einfache weise meinen horizont zu erweitern :) Danke Arnulf |
Re: wrapper vs. function hook - theorie
Zitat:
Zitat:
Methode 1 und (eine etwas abgewandelte) methode 2 haben einiges gemeinsam, denn den LoadLibrary-Befehl muss ja ebenfalls der "fremde" Prozess aufrufen. Und das geht mit "methode 2": Per VirtualAllocEx Speicher reservieren, per WriteProcessMemory den LoadLibrary Code "injezieren", und schliesslich per CreateRemoteThread aufrufen. D.h. "methode 1" ist also nur eine art "Erweiterung" von "methode 2". Und wenn du für das quelltext haben willst, schau mal hier rein:  Meine DLL-Injection Lib (allerdings ist da noch ein kleiner, aber besch*** fehler drin, den ich demnächst mal ausbessern muss)Zitat:
Zitat:
ciao, Philipp |
Re: wrapper vs. function hook - theorie
herzlichen dank damit versteh ich wenigstens einmal ungefähr worum es hier geht.
Ich hab mir ja grad ein extrem kompliziertes pojekt ausgesucht und deshalb weiß ich meißtens auch nicht genau wonach ich fragen soll. Liegt an der mir fehlenden basis und erfahrung :). Jedenfalls möchte ich etwas bestimmtes erreichen. Und zwar will ich spieleinstellungen kontrollieren. In dem sinn sind das variablen die gesetzt werden können über eine konsole in dem spiel. Also der anticheat funktioniert ja schon nur die methoden möchte ich eben verbessern und dabei sehr viel lernen :). Ich mach es jetzt so, daß ich mit postmessage einfach die variable in der konsole abfrage und mit wm_gettext mir das ergebnis hole. Jetzt würde ich das aber gerne dirrekt im speicher machen. erstens deshalb, weil meine methode die konsole des spiels zuspammt (ist kein performance problem sonder es stört das arbeiten mit der konsole). und zweitens weil mir das nicht elegant vorkommt :). Jetzt hab ich versucht mit programmen die speicheradresse herauszubekommen. Das geht grundsätzlich, allerdings hat das nur Gültigkeit solange der prozess nicht neu gestartet wird. Grundsätzlich weiß ich nicht ob das spiel mit dma arbeitet, aber selbst wenn nicht, hätte das dann vermutlich nur mit meiner version und mit meinem computer gültigkeit - und das ist nicht der sinn. Kann mir hier jemand helfen und mir sagen ob ich eine chance hab die variablen oder einstellungen zu kontrollieren? Es gibt einfach so viele dinge die man kontrollieren bzw. überprüfen muß wenn man sowas machen will wie ich :) - aber man lernt extrem viel ..... naja hoffe ich bekomm antwort auf meine sehr unspezifischen fragen. Arnulf |
Re: wrapper vs. function hook - theorie
meine units haste ja:
http://www.delphipraxis.net/internal...ct.php?t=53957hier mal nen opengl wrapper: www.arschvoll.net/wrapper.txtwrapper sind einfach scheisse :> meiner meinung nach |
Re: wrapper vs. function hook - theorie
Zitat:
Wenn die Werte bei jedem neustart des Spieles an einer anderen Stelle im Speicher stehen, woher weis dann das Spiel wo sie sich befinden? Ganz einfach, es speichert sich auch irgendwo einen Pointer, auf diesen Wert, und dieser hat oft eine feste Adresse. Wenn nicht, kann es natürlich sein, dass sich dieser Pointer auch irgendwo in einer struktur befindet, auf welche wiederrum ein anderer Pointer zeigt, usw. Aber irgendwo muss es in allen Fällen einen Pointer geben, der fest ist. Wenn du glück hast, findest du diesen schnell, wenn nicht ... Zitat:
ciao, Philipp |
Re: wrapper vs. function hook - theorie
@brechi
hi :) - immer langsam mit den jungen pferden. ja die collection hab ich danke und das versteh ich dank den sourcen so halbwegs. Auch wrapper versteh ich wie die funktionieren, mir war nur nicht ganz klar wie die implementiert werden. Mir fehlt einfach viel theorie - zur praxis komm ich noch. Zitat:
Ich hab ein praktisches programm, das sich tsearch_16 nennt. damit kann ich die mometanen speicheradressen der variablen bekommen. Für den Pointer müsste ich aber vermutlich einen debugger benutzen. tja ich hab mal den dos debugger benutzt, aber pentium prozessoren haben doch schon einen etwas erweiterten befehlsschatz - naja mov erkenn ich noch... Ok sollte ich den pointer bekommen wie soll ich den dann von aussen benutzen? da hab ich noch keine richtige vorstellung. Mit meinen eigenen pointern in meinem programm kann ich ja umgehen aber bei einem fremden prozess? Zitat:
Im gamefenster gibts eine art console die man öffnen kann, das wird so eine art remote für die richtige console sein. Aber warum sollte das game windows messages bentutzen um hier game settings oder einstellungen zu übertragen? Fals doch welche windows messages sollten das sein? - das game wird doch wohl einfach nur funktionsaufrufe haben oder eben pointer - aber windows messages - wär ja nett :) Das console window hat ja einige child windows - wie 2 edit felder und 3 buttons - die ich ja benutze um die daten aufzurufen und auszulesen. Vielleicht kann ich hier auch eine art peekmessagebuffer machen, dann würde ich einfach nur alles neue von meinem programm bearbeiten lassen und müsste das nicht immer in die console schreiben und dann wieder auslesen - aber wenns da eine noch dirrektere methode gibt immer her damit..... Wie ihr sehts hab ich noch nicht so ganz die idee von dem ganzen :) Arnulf |
Re: wrapper vs. function hook - theorie
Zitat:
Zitat:
Zitat:
Zitat:
Nur mal so nebenbei: Was is das überhaupt für ein Spiel? Die Worte "konsole", "opengl" & "fenster" erinnern mich so an HalfLife & Steam ... ciao, Philipp |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 21:52 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz