Windows Messages sniffen.

[Arnulf]

Ein api hook.
Ich hab versuch dazu etwas zu lesen - aber irgendwie ist mir das nicht ganz klar.

Was würde ein api hook bedeuten? - ich glaube nicht, daß ich die kernel32.dll hooken kann - und ich hab extra ich geschreiben, weil es sicher leute gibt die das können .

Sprechen wir dann davon setwindowshookex zu verwenden um einen globalen oder localen hook zu installieren ????

Trotz vielem herumlesen sind mir die Begriffe einfach ein Rätzel.
Hooks werden viele dinge genannt nicht nur das was microsoft als als hook erklärt.

Wenn wir von der setwindowshookex funktion sprechen, welchen hook soll ich dann installieren?
Einen Globalen? - das wäre dafür, daß ich nur ein bestimmtes programm überprüfen will wohl zu viel des guten.
Einen Localen? - ein localer hook ist soweit ich weiß nur im eigenen programm zu realisieren.
Die Qual der Wahl wäre natürlich das in eine .dll auszulagern und die in den prozess einzufügen.
Mit madcodehook wäre das ja relativ einfach zu machen.

Trotzdem bleibt dann auch noch die frage welchen hook man installieren soll um eben genau diese debug functionen zu sniffen.
also readprocessmemory oder writeprocessmemory - usw....

Ich les jetzte schon ein weilchen beiträge über hooks, aber meißtens werden globale keyboard hooks ausführlich erklärt.
Nur brauch ich keinen globalen hook und keyboard schon garnicht.

Naja ich hoffe ich komme mit der Frage in diesem Forum einen schritt weiter

Danke
Arnulf

[ReDoX]

Hi,
Api-hooks und "normale hooks" sind was ganz unteschiedliches.
Ein "normaler Hook" wird (fast immer) in eine Dll ausgelagert und aus deinem Programm aufgerufen.
Dieser hook wird benutzt um Messages auszulesen.
Ein Api-Hook kommt auch in eine Dll diese Dll wird dann in einen Process injeziert.
In det dll wird eine Funcion aus den Prozess gehook ,z.B. MessageBoxA usw, und mit deiner function ersetzt.
Mfg ReDoX

[perle]

Oo wenn du doch schon weisst, welche API du hooken möchtest, und auch madCodeHook kennst, dann ist das doch wirklich kein Problem mehr oder?

dll code

Code:

[...]

var NextWriteProcessMemory : function (hProcess : Cardinal,lpBaseAddress : Pointer,lpBuffer : Pointer,nSize : Cardinal,var lpNumberOfBytesWritten : Cardinal) : Longbool; stdcall;

function myWriteProcessMemory(hProcess : Cardinal,lpBaseAddress : Pointer,lpBuffer : Pointer,nSize : Cardinal,var lpNumberOfBytesWritten : Cardinal) : Longbool; stdcall;
begin
  IF hProcess = DasProzesshandleDesProzessesDenDuÜberwachenWillst THEN
    //   DasWasPassierenSoll
  else 
    result := NextWriteProcessMemory(hProcess,lpBaseAddress,lpBuffer,nSize,lpNumberOfBytesWritten);
end;

begin
  HookApi(kernel32,'WriteProcessMemory',@myWriteProcessMemory,@NextWriteProcessMemory);
end;

wenn du oben beim Kommentar nun einfach result := FALSE machen würdest, wäre der WriteProcessMemory Zugriff auf dein Programm einfach geblockt worden.

Du solltest aber aufpassen, dass du nicht jeglichen Zugriff blockst, da madCodeHook selber WriteProcessMemory benötigt.

[Arnulf]

also bedeutet api hook immer eine funktion einer system .dll zu hooken.
Das war mir bisher nicht klar - die begriffe schwirren noch zu viel in meinem kopf herum

Danke jedenfalls für das beispiel, weil es wirklich schwer ist in delphi die richtigen typen definitionen zu bekommen.
msdn hilft einem da ja nicht wirklich weiter.

Zitat:

Du solltest aber aufpassen, dass du nicht jeglichen Zugriff blockst, da madCodeHook selber WriteProcessMemory benötigt.

wie soll ich das verstehen? - in dem sinn darf ich ja nur meine eigene eingefügte .dll nicht blockieren.
ansonstent kann ich ja alles blockieren oder?

nein ich glaub ich habs immer noch nicht ganz - aber ich bin fast dabei es zu kapieren versprochen lol...

Mit mad code hook oder womit auch immer füge ich eine .dll nach deinem code beispiel in den prozess ein.
Danach sitzt die dort und hook die funktion writeprocessmemory.
Wenn ich jetzt alles blocke hab ich natürlich ein problem, weil ich ja selbst aus meiner .dll die funktion writeprocessmemory aufrufe.
Soweit verteh ich das (glaub ich) oder eben noch nicht ganz.
Ich dachte wenn die .dll einmal eingefügt ist und der hook besteht braucht man writeprocessmemory nicht mehr oder wird die ganze zeit im prozess herumgeschreiben wenn die funktion aufgerufen wird? - dann hätte ich sowieso eine endlosschleife!

Und bevor die .dll drin ist hab ich ja noch keinen hook der das überprüft - also sollte es mit madcodehook auch keine probleme geben.

Sicher ich kann die .dll dann nicht mehr deinstallieren (glaub ich) - aber wenn man das sowieso nicht will dann ists ja egal.

Ok ich habs noch nicht kapiert
Warum muß ich mir auch grad das schwerste beispiel raussuchen lol...

Arnulf

[Arnulf]

Also ich hab ein bisschen herumexperementiert - allerdings kommt nichts dabei raus .

Eine .dll in eine prozess einfügen ist ja mit mad code hook kein problem

Aber der api hook scheint nicht zu funktionieren.
Ich hab probiert einfach mal etwas in ein file zu speichern wenn writeprocessmemory aufgerufen wird.
Irgendwie muß man ja mal mitbekommen, daß das passiert ist - interprozesskommunikation ist wohl der nächste schritt.

Aber hier mal der versuchs code:

Delphi-Quellcode:

function myWriteProcessMemory(hProcess : Cardinal;lpBaseAddress : Pointer;lpBuffer : Pointer;nSize : Cardinal;var lpNumberOfBytesWritten : Cardinal) : Longbool; stdcall;
var FH : TextFile;
begin
     inc(a);
     result := NextWriteProcessMemory(hProcess,lpBaseAddress,lpBuffer,nSize,lpNumberOfBytesWritten);
     AssignFile (FH, ExtractFileDir (paramstr(0)) + '\meins.txt');
     Append (FH);
     WriteLn (FH, inttostr(a));
     CloseFile (FH);
end;

Es passiert rein garnichts.
Wenn ich eine weitere .dll in den prozess einfüge sollte ja zumindestens dann die routine aufgerufen werden ...
Aber leider kein file im verzeichnis .

Arnulf

[brechi]

WriteProcessMemory in dem Prozess aufgerufen der in einen anderen Process etwas schreiben will.

Zitat:

Wenn ich eine weitere .dll in den prozess einfüge sollte ja zumindestens dann die routine aufgerufen werden ...

ja sie wird in in deinem prozess aufgerufen nicht aber in dem prozess wo du die dll injezierst


wenn du wissen willst ob ein prozess in DEINEN prozess etwas schreibt dann musst du in JEDEM anderen prozess die API hooken und dann schaun ob writeprocessememory mit deiner prozessID aufgerufen wird

[Arnulf]

naja ... - damit sieht man, daß ich von windows system programmierung keine ahnung hab

Aber man lernt ja dazu.
Das bedetet aber auch ich hab fast keine chance festzustellen ob auf meinen prozess zugegriffen wird.
In jeden prozess im system eine .dll zu hooken und dann auch noch per inter prozess com. an ein controll programm daten zu schicken schein mir doch extrem aufwendig - möglich vielleicht - vielleich bleibt mir eh nichts anderes übrig .

Als letzte chance das ohne massiven .dll hooking zu machen - rechne ich mir vielleich mit debug events aus.

WaitForDebugEvent - wäre vielleicht noch eine möglichkeit, aber ich schätze mal das das eher den debuger betrifft und wieder nicht den debug prozess.

IsDebuggerPresent - wäre zwar vom prozess aus, aber 1. weiß ich ned ob writeprocessmemory ein debug event ist - vermutlich nicht. und 2. kann ich das ja nicht jede millisekunde ausführen.

Trotzdem Debug events sind ja glaub ich wenn ein anderes programm den process handle für das zu debugende programm erhält.
Hier wäre vielleich schon ein ansatz, weil es dann nicht um einen einzelnen aufruf geht sondern solange der handle nicht wieder geschlossen wurde ich trotzdem rausbekomme ob das programm debuged wird.

hat jemand erfahrung damit?.
und vor allem stimmen meine annahmen lol
oder gibt es noch irgend eine idee wie man sowas hinbekommt ohne alle prozesse mit .dlls zu fluten

Arnulf

[brechi]

ich weiß ja nicht was du genau vor hast aber warum machste nicht einfach ne checksumme auf den deinen speicher? ändert dann ein anderes programm mit WriteProcessMemory etwas kannste dein prog ja schließen.

[perle]

die dll in alle anderen Prozesse zu injezieren ist doch garnicht schwer. Musst einfach nur als ersten Parameter die entsprechende Konstante eintragen (bei Injectlibrary jetzt)

"ALL_SESSIONS or SYSTEM_WIDE " z.b.

die dll wird dann automatisch in jeden neuen sich öffnenden Prozess injected....das wars dann auch schon...eigentlich also garnicht so schwer....wenn du nähere Hilfe brauchst, meld dich einfach mal per icq bei mir

[Arnulf]

Zitat:

"ALL_SESSIONS or SYSTEM_WIDE "

Ja stimmt schon - ich hab hald createprocessex verwendet.

Natürlich kann ich euch sagen worum es geht.
Das soll ein Anticheat werden.

Checksum vom speicher machen klingt interessant - allerdings ist das schon wieder etwas komplett neues.
Aber ich denke mal der speicher in einem programm ist ja nur dort konstant wo die funktionsaufrufe stehen also der prozess selber geladen ist.
Dafür müsste ich erstmal den teil rausbekommen - dafür kenn ich mich einfach zu wenig aus - bin schon fast am aufgeben.
Ausser ich finde tatsächlich noch eine möglichkeit für eine gute Lösung.

Der Anticheat hat super funktioniert so wie ich den hatte bis ein cheat aufgetaucht ist, der im prinzip opengl32.dll dirrekt im speicher des spiels patcht.

Ich schätze er verschafft sich einen speicherbereich und ändert die einsprungadresse für ein paar funktionen (glbegin usw.).
Hier hatte ich einfach den ansatz grundsätzlich soetwas für den zu schützenden prozess zu verhindern.
also isdebuggerpresent - is sinnlos - hab ich schon ausprobiert.
Jetzt wäre vermutlich system_wide eine lösung aber irgendwie wieß ich nicht recht ob das nicht gepfuscht wäre .
checksum des speichers wäre sehr interessant! Vielleich sollte ich in der richtung mal forschen - wie macht man sowas?

mit createprocessex bekomm ich eh schon einen haufen infos mit die ich vermutlich verwursten kann - ausserdem ist das dann ein child process vom anticheat.

Danke jedenfalls für die großartige hilfe

Zitat:

warum machste nicht einfach ne checksumme auf den deinen speicher?

wie würde man sowas machen?

Arnulf