Salve,

Ziel : Hooks abfangen - Prozess der den Hook geladen hat, anzeigen.

Also die Funktion 'SetWindowsHookEx' vom Typ zum Beispiel.

Funktionieren tut es, da ZoneAlarm meinen Wireless Tastatur Hook auch als Hook erkennt. (siehe Screenshot)



Überlegung: Um nach Hooks im System Ausschau halten zu können, muss ich wissen wie sich Hooks im System "anmelden". Sie sich also registrieren.
Edit: Tun Sie hier über SetWindowsHookEx


Ansatz: eigener globaler Hook . Status OK!
der vom Typ WH_GETMESSAGE Hook ist Status OK!

Zitat:

Überlegung: Um nach Hooks im System Ausschau halten zu können, muss ich wissen wie sich Hooks im System "anmelden". Sie sich also registrieren. Vielleicht kann man da (im schlimmstenfall mit einem eigenen Hook) ansetzen. Mir fehlt also das Erkennungsmerkmal eines Hooks.

Du kannst die Pointer der gehookten Funktionen mit den Originalen vergleichen, schwirieger wirds wenn du zwischen "Global" und "Local" unterscheiden willst, wüsste jetzt nicht wie!

MfG

Hab mal ein bisschen ZoneAlarm auf die Finger geschaut.
Das Programm erkennt den Hook, wenn die function



aufgerufen wird.

Also schon mal one step into the right way!

Mal schaun was meine anderen Infotools aufzeichnen, wenn ich meinen Hook lade...

Ja gut, aber du kannst nicht sagen, dass dieser API- Befehl abgefangen wird, oder dass er einfach einen aktiven Hook per Timer abfragt. Denn ab dem oben genannten Befehl existiert ja der Hook.

Zum Verständnis meiner Herangehensweise.

Die Datei ist lokalisiert. (meine eigene Hook.dll)

Jetzt habe ich die einzelnen Funktionen meiner DLL ausgeklammert.

Und zum Schluss diese Funktion isoliert.

Der Aufruf dieser Funktion bewirkt also, dass ZoneAlarm aufmerksam wird.



Dann wird Folgendes aufgerufen:



Selbst wenn ich die function ShellProc ausklammer - wird SetWindowsHookEx ans System gesendet.

Ergo, SetWindowsHookEx wird vermutlich von einem Systemweiten Hook von ZoneAlarm selbst, abgefangen.

[highlight]WH_DEBUG Hook

The system calls a WH_DEBUG hook procedure before calling hook procedures associated with any other hook in the system. You can use this hook to determine whether to allow the system to call hook procedures associated with other types of hooks. [/highlight]

Das könnte ein Hinweis darauf sein, wie ZoneAlarm arbeitet und andere Hooks "aufklärt".

Nachtrag: Ich habe das Gefühl mir bleibt gar keine Wahl, anscheinend MUSS ich auch einen WH_DEBUG Hook setzten, um andere Hooks aufzuklären.

Interessant ist auch, dass ZoneAlarm nur Hooks findet, die NACH seinem eigenen Hook starten.

Bsp: Erst meinen Hook installieren - dann ZoneAlarm öffnen.

grübel, grübel

Könnte auch ein Hinweis darauf sein, dass ZoneAlaram einfach einen Shell-Hook installiert und so die Aufrufe von SetWindowsHookEx mitbekommt.

Luckie hat folgendes geschrieben:

Könnte auch ein Hinweis darauf sein, dass ZoneAlaram einfach einen Shell-Hook installiert und so die Aufrufe von SetWindowsHookEx mitbekommt.

Hallo,

ihr schreibt hier immer über DEN Hook. Das muss keineswegs so sein, normalerweise gibt es eine Kette von Hooks: der, den Windows aufruft, ist der zuletzt installierte, der hat sich bei der Installation den vorherigen gemerkt und ist verpflichtet, den immer aufzurufen, so dass die ganze Kette von Hooks rückwärts abgearbeitet wird.

Die meisten Probleme mit Hooks werden dadurch verursacht, dass sich jemand nicht dran hält. Da sowieso nicht bekannt ist, wie sich ein Hook seinen Vorgänger merkt, wenn überhaupt, lässt sich die Kette praktisch nicht zurückverfolgen. Die einzige Möglichkeit für ein vollständiges Mapping ist wohl tatsächlich das Abfangen aller Funktionen, die einen Hook setzen.

Gruss Reinhard

Ferner schreibt ihr immer über Hooks allgemein, bezeichnet aber trotzdem nur die Shell-Hooks ... Solche Hooks wie API\IAT \ Overwrite \ GuardPage-Hook und viele weitere werden hier völlig außer Acht gelassen (mal Abgesehen davon, dass diese sowieso nicht standardisiert sind und daher nur sehr kompliziert zu erkennen sind). Dass Erkennen dieser ist nämlich noch um einiges schwieriger, da man für diese ein gemapptes Speicherabbild einer Datei mit dem tatsächlichen Speicherinhalt des Prozesses vergleichen muss.

Da's schon mal angesprochen wurde: Nichts anderes macht ZoneAlarm, wenn OpenProcess aufgerufen wird und man die Erweiterte Prozessprüfung aktiviert hat: ZA fängt diesen Aufruf ab, kontrolliert diesen und führt dann diesen Befehl auf der Original-Funktion aus, wenn der Prozess dazu berechtigt ist ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Wenn ich das Bisherige einmal zusammen fasse, ergibt sich folgendes:

globale Hooks können nur im System identifiziert werden, wenn Sie sich mit einer "bekannten" Hookfunktion im System anmelden.

Desweiteren lassen sich schon geladene Hooks extrem schwer bis gar nicht auffinden.

Ergo ist ein Tool, was man zwischendurch für kurze Zeit startet, um im System nach etwaigen gesetzten Hooks zu suchen, eine schwierige Aufgabe.

Das 1,4285714285714285714285714285714e-10 Menschen auf der Welt in einer angemessenen Zeit schreiben könnten.

Dann vertage ich das Projekt bis ich mal mehr Zeit habe.

Weitere Anregungen und Hintergrundinformationen sind trotzdem weiter erwünscht.

uall.overclock.ch/IceSword.exe (das macht das mit shellhooks)
uall.overclock.ch/FireShield.exe (mein Programm,a ber nicht was du genau suchst)

reicht dir der rootkitrevealer von sysinternals nicht?

Danke erstmal für die Links:

1) zu: rootkitrevealer : kenn ich, hat aber eine andere Aufgabe als alle möglichen Hooks anzuzeigen.


@uall@ogc

2) zu: FireShield.exe: Wenn dein Proggi 2.0a ist, gibts dann ach schon eine 1.x die (mit Erklärung) vollständig funzt? Hab gesehen, dass dein Programm den physischen Speicher ausliest. Aber was bedeutet das (OK) in den Klammern. Was willst du mit deinem Programm können?


3) zu: IceSword.exe: Das Programm kommt der Sache doch schon näher. Die Reiterseite Hooks macht eigentlich genau das, was ich auch vorhatte. Schön, jetzt interessiert mich das Hook-Auflisten nochmehr....


Fazit: Der weitere WEG zum Ziel ist wohl, sich näher mit WH_CBT und WH_GETMESSAGE zu befassen. Somit kommt man an die Messagehooks WH_Mouse, Shell etc heran.

Die alte Fireshield Version konnte viel mehr, hatte aber neu programmiert weil ich viele sachen geändert habe. Den Link den du hast war nur so ne Bug Version zum testen.
Muss mal schaun ob ich die Alte Version wiederfinde.

IceSword ist schon eins der besten Programme dafür (nicht so crap we RookKitRevealer oder Fireshield ^^)

Folgende Überlegung stelle ich an:

Um die MessageHooks abzufangen (aufzudecken) muss ich

1) selbst einen globalen Hook installieren (WH_GetMessage) - machbar
2) nach den Hook-Typen Ausschau halten (WH_Mouse, WH_CBT...) - Wie?
3) und deren Handle isolieren - Wie?
4) dieProzessID/ThreadID herausbekommen - machbar
5) um zu sehen welcher Prozess da am Werk ist - machbar

Punkt 2 und 3 werde ich mir demnächst mal anschauen.
Um mal zu zeigen, wie die Hooks aufgelistet werden sollen, ein Screenshot von IceSword.

In meinem vorherigen Beitrag habe ich geschrieben:

Zitat:

1) selbst einen globalen Hook installieren (WH_GetMessage) - machbar

-> Bin mir nicht mehr sicher ob der vom Typ WH_Getmessage sein muss

Zitat:

enables an application to monitor messages

oder doch vom Typ WH_MSGFILTER.

Ein Teil meiner Hook.dll sieht so aus:




Was will ich finden?

Wenn das System die Funktion (oder auch jede andere) SetWindowsHookEx aus der USER32.DLL aufruft, will ich informiert werden.

WIE kann ich nun die Funktion [b]'SetWindowsHookEx' [/b]abfangen?

Installier in jedem Prozess einen Import Table Hook auf diese API-Funktion.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Ok, der Thread ist uralt,
aber wo gibt es ein tutorial zum sezten von Import-Table-Hooks?
Denn das will bei mir nicht klappen...