Windows Messages sniffen.

[dde]

Was wisst ihr drüber. Ein paar Explorer-Messages sollen nämlich auch mein Prog erreichen, damit der unabhängig vom User die System-Info aktualisiert. Z.b. die geöffneten Fenster..

[fylo]

Hi

kannst du dein Problem einwenig genauer beschreiben? Welche Messages meinst du und was möchtest du sniffen?

[dde]

Ich prog gerad ein Systemtool. Das kann z.B. die versteckten Fenster herausbekommen und bei Bedarf anzeigen. Nun können jedoch mit der Zeit neue Fenster entstehen. Damit der user nicht immer auf ein Refresh-Btn drücken muss, will ich das automatisieren. Wenn ein neues Fenster in der Zwischenzeit existiert, dann soll das Programm dies per Msg mitbekommen und anschließend in die Liste einfügen...

[fylo]

Hi

ich glaub mit einem Hook sollte sich das machen lassen. Benutze mal die Forumsuche nach Hook

[dde]

Das war mir schon klar. Welche Messages?

[fylo]

Hi

in der WinAPI-Help ist folgendes zum SetWindowsHookEx und zum WH_CBT lesen:

Zitat:

HCBT_ACTIVATE
The system is about to activate a window.

HCBT_CLICKSKIPPED
The system has removed a mouse message from the system message queue. Upon receiving this hook code, a CBT application must install a WH_JOURNALPLAYBACK hook procedure in response to the mouse message.

HCBT_CREATEWND
A window is about to be created. The system calls the hook procedure before sending the WM_CREATE or WM_NCCREATE message to the window. If the hook procedure returns a nonzero value, the system destroys the window; the CreateWindow function returns NULL, but the WM_DESTROY message is not sent to the window. If the hook procedure returns zero, the window is created normally.
At the time of the HCBT_CREATEWND notification, the window has been created, but its final size and position may not have been determined and its parent window may not have been established. It is possible to send messages to the newly created window, although it has not yet received WM_NCCREATE or WM_CREATE messages. It is also possible to change the position in the Z order of the newly created window by modifying the hwndInsertAfter member of the CBT_CREATEWND structure.

HCBT_DESTROYWND
A window is about to be destroyed.

HCBT_KEYSKIPPED
The system has removed a keyboard message from the system message queue. Upon receiving this hook code, a CBT application must install a WH_JOURNALPLAYBACK_hook hook procedure in response to the keyboard message.

HCBT_MINMAX
A window is about to be minimized or maximized.

HCBT_MOVESIZE
A window is about to be moved or sized.

HCBT_QS
The system has retrieved a WM_QUEUESYNC message from the system message queue.

HCBT_SETFOCUS
A window is about to receive the keyboard focus.

HCBT_SYSCOMMAND
A system command is about to be carried out. This allows a CBT application to prevent task switching by means of hot keys.

[dde]

So, ich hab jetzt mal die Messages oben getestet.

HCBT_ACTIVATE wird auch gesendet, wenn die Maus sich bewegt...

HCBT_CREATEWND wird ständig gesendet.

Die bringen mich also nicht weiter, da sie ja irgendwie immer gesendet werden und ich das ja auch mit nem timer bezwecken könnte, was nicht beabsichtigt ist.

Kann man nicht direkt die Messages an den Explorer sniffen?

[dde]

So ich habs jetzt gelöst. Ich hooke WH_SHELL und filtere nach nCode = HSHELL_WINDOWCREATED und HSHELL_WINDOWDESTROYED.

[Arnulf]

Hi
kann man soetwas wie WriteProcessMemory auch sniffen?

allerdings von einem anderen programm aus.
in dem sinn so etwas wie CheckRemoteDebuggerPresent ab service pack1 macht.

vielleicht mit wm_debug?

In dem sinn also eine meldung bekommen wenn ein fremdes programm auf ein zu schützendes programm zugreift?

Arnulf

[ReDoX]

Hi,
WriteProcessMemory kannst du z.B. durch einen API-Hook hooken und immer wenn, WriteProcessMemory aufgerufen wird wird deine Funktion ausgefuehrt.
Mfg ReDoX

[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

[brechi]

ich könnte es dir sagen aber da ich cheatprogger bin tu ichs nicht ;)
da ich merke das du nicht ganz so viel ahnung von cheats hast, rate ich dir auch ab es weiter zu versuchen alleine schon weils eine methode gibt die zu fast 99% nicht richtig erkannt werden kann

selbst Cheatings Death hatte damit probleme und es funktioniert immer noch nicht wirklich, ausserdem wirste einen Treiber path wie beim OGCi auch nicht wirklich erkennen können.

wenn der direkt die imports bzw per jmp patched kannste eine dll in den speicher laden und dann mit meiner funktion "IsHooked" von der uallCollection schaun obs gehookt wurde, da aber die admins nicht wollen das ich auf die seite verlinke mussu halt mal bei google suchen

[Arnulf]

du meinst in der uallprotect.pas?

hm... - naja ich probiers gerne mal.

Es ist einfach so, daß ich als project einen anticheat angefangen hab.
Und jetzt kann ich nicht mehr aufhören.
Ich hab vor 4 Monaten Delphi gelernt und hab dafür eigentlich extrem viel geschafft.
Allerdings komm ich gegen profis hald ned wirklich an :).
Aber ich lerne dadurch einfach so extrem viel.

Deshalb bin ich über uall collection auch extrem froh, weil man daraus sehr sehr viel lernen kann.
Aber einfach die unit einbinden und die funktion verwenden passt mir hald nicht.
Nicht daß die nicht super wäre, sonder ich verstehs hald nicht und das gefällt mir nicht so richtig :).

naja ich teste das mal mit der collection - aber ich glaub ich werd trotzdem noch selbst ein bisschen im speicher rumpfuschen müssen :).

Werds hald in einem neuen thread machen wenn ich speziellere fragen hab.

Danke für alles
Arnulf

Edit: eigentlich wollte ich noch schreiben, daß man bei uall collection die findprocess function verbessern könnte, indem man extractfilepath verwendet - aber das dürfte in der neuen version schon verbessert worden sein. - Ist auch nur für win98 relevant......

[brechi]

ähm weiß net hab gestern auf der inet seite von mir ne neue version geupped weil die andere 2 blöde bugs hatte und hab da auch beispiele hinzugefügt wie man das benutzt. die uallUtils ist auch nur da um kleine exe dateuen zu erstellen bzw für dll die injected werden

[DGL-luke]

es herrscht also krieg! na, auf welche seite stelle ich mich? auf die des unterlegenen!

das ganze is ja eigentlich einfach - denn es existiert ja bestimmt auf dem system eine original-opengl32.dll, die das spiel auch, bevor der cheat aktiv wird, lädt. wenn du dir diese holst und mit dem code im speicher des spiels vergleichst, müssen dir manipulationen ja auffallen.
ich weiss nicht genau, wieviele opengl32.dll es gibt, die in verwendung sind, aber so viele können das ja nicht sein - man sollte sich also einige merkmale, die a)in allen gleich sind(verschebungen wohl leider nicht ausgeschlossen) und b)vom cheat geändert werden(müssen) vornehmen. leider kenne ich mich mit dll-programmierung nicht so aus, aber die einsprungspunkte (mnemonic: call / jr, wenn ich das ganze richtig verstanden habe ?!) sollte ein guter ansatzpunkt sein. wenn du weisst, dass bei spielstart der speicher noch korrekt ist, ganz du diesen auch backen und dann alle 10 sekunden vergleichen.

linkt dieses spiel die dll statsich oder dynamisch? ein jammer, dass ich mich so schlecht auskenne....

deswegen einige annahmen von mir, auf denen obiges basiert:

-opengl32.dll nimmt die opengl-befehle und leitet sie an die graka weiter.
-wenn keine extensions eingeführt werden, ist diese datei für alle grakas gleich - denn wieso sollte man unterschiedliche befehlssätze benutzen?
-du kannst mit dem speicher des spieles machen was du wilst.

wenn diese annahmen richtig sind, sollte mein vorschlag funktionieren.....

[perle]

so macht es die IsHooked-Funktion in der UallCollection ja auch.

[Arnulf]

Das stimmt die isHooked function von uall hab ich mir angeschaut.
im prinzip macht die das auch nur leider gibt mir die funktion immer true zurück :(.

Delphi-Quellcode:

begin
while true do
begin
if uallprotect.IsHooked('opengl32.dll','moh_spearhead.exe') then
begin
MessageBox(0, 'hook found !', 'bla bla', 0);
end
else sleep (50);
end;
end.

ich hab mich noch nicht weit genug reingelesen um zu sehen warum.

aber er ließt glaub ich nur die ersten 7 bytes ein oder so und vergleicht die - aber wie gesagt in der beziehung bin ich ein absoluter noob :).

Arnulf

[brechi]

wenn du IsHooked benutzen willst musst du ne dll in das spiel injezieren und dann dort
IsHooked('opengl32.dll','glBegin') aufrufen

hab mir mal den source von dem progger geben lassen, eigentlich reicht es aus mit ReadProcessMemory die ersten 5 byte von der Glbegin in dem spiel zu lesen und mit der originalen glBegin zu vergleichen


wenn ich zeit habe progge ich vielleicht mal schnell ne detection für den hack

[Arnulf]

Hi
Ja in die .dll hab ich den code schon gegeben und natürlich auch vom prozess laden lassen.

Aber ich hab wohl den prozessnamen angegeben und nicht die funktion die ich überprüfen wollte :)
Hab ich hald falsch verstanden :)
Jedenfall will ich mich echt bedanken bei allen beteiligten, ich hab noch nie ein so gutes forum gesehen, wo sich die mitglieder so viel mühe machen anderen zu helfen!

Sollte das jetzt funktionieren hab ich mal vorab eine Lösung, allerdings will ich hier noch mehr in die materie eintauchen und versuchen selbst aus dem speicher zu lesen und zu überprüfen.
Klar mit readprocessmemory ... aber ich will erstmal die theorie verstehen, also wie windows überhaupt prozesse und dynamische dateien lädt und wo variablen abgelegt werden.

Dafür mach ich aber einen eigenen thread auf um den hier mal ruhen zu lassen - sonst wirds noch komplett off topic.

Ich hoffe das klappt mal mit der ishooked funktion dann hab ich mal einen ansatz :).

Alles Gute
Arnulf