Fremdes programm hookt CreateWindowEx

[Gruber_Hans_12345]

Hallo

Ich habe eine Frage, ich habe den Verdacht das ein fremdes Programm die user32.dll/CreateWindowEx hookt

Denn wenn das programm gestartet ist, und ich mein Programm starte, dann habe ich extremste Verzögerungen drinnen (Und ich sehe das die Kernel Zeiten extrem hochgehen)

Habe das ganze nun auch bis aufs CreateWindowEx runtergebrochen, die braucht normalerweise nicht mal eine ms, aber wenn das fremde Programm gestartet ist, dann 55ms

Da es hauptsächlich in meinem Programm auffällt (ich brauche eine unmenge an CreateWindowEx) und andere Programme nicht so, möchte ich nun nachschauen wer/was das hookt und ob ich das umgehen kann ...

für alle infos mal
Besten dank

[sx2008]

Kann nicht schaden das System mit GMER zu untersuchen...
http://www.gmer.net/

[Gruber_Hans_12345]

Danke werde ich gleich mal testen ...

Allerdings weiss ich das es sich bei dem Programm um kein Illegales, oder RootKit oder co handelt, das ist ein teures CAD Programm
eventuell das es sich dabei um irgendeinen Kopierschutz oder so handelt ... oder oder oder ...

[Gruber_Hans_12345]

nein, leider habe ich mit GMER nichts gefunden was auf irgendwas von diesem Programm hindeutet ...

Hat sonst noch wer eine Idee?

[Luckie]

Und das ist nur bei deinem Programm so? Was macht dein Programm?

[Gruber_Hans_12345]

Nein auch bei anderen Programmen auch, aber bei meinem eben extrem (anscheinend verwendet mein Programm sehr sehr viele solche CreateWindowEx)
im Taskmanager sehe ich es dann ja bei den BENUTZER_OBJEKTEN
und alle Programme die da eine hohe zahl haben, bei denen dauerts dann länger
Aber leider wie gesagt bei meinem Programm am schlimmsten (statt 3 Sekunden 30 Sekunden)

[QuickAndDirty]

Gehen wir mal davon aus, deine Vermutung wäre korrekt.
Brauchst du nur den Beweis um dem Kunden zu zeigen, dass er sich an den anderen Hersteller wenden soll?
Oder willst du wirklich die Funktionsfähigkeit des anderen Programms zu Gunsten deines Programmes verhindern ,
denn das ist so der typische Verschlimmbesserungsansatz.

[Gruber_Hans_12345]

Ja es wurde schon an das andere Programm weitergeleitet, nur das ist eben ein riesen großer Hersteller, wo ich vermute das es keine Lösung geben wird.

Daher habe ich auch noch im Hintergedanken, ob ich diesen Hook irgendwie dann auch aufheben kann, oder nur für mein Programm oder oder ...
man könnte dann ja schauen, ob es ein Problem für das andere Programm ist.

Den mein Programm ist dadurch eigentlich unbrauchbar ...

[Namenloser]

Es gibt ja verschiedene Arten unter Windows etwas zu hooken. Einmal der „saubere“ Weg über SetWindowsHookEx und einmal indem man die ersten paar Bytes der Routine patcht und auf eigenen Code umleitet. WinAPI-Funktionen haben dafür extra ein paar Dummy-Operationen am Anfang.

Erstmal müsstest du rausfinden, um welche Art von Hook es sich handelt. Mit SetWindowsHookEx lässt sich CreateWindowEx zwar nicht direkt hooken, aber es kann durchaus sein, dass CreateWindowEx noch irgendeine Message an das neuerstellte Fenster schickt, die gehookt sein könnte.

Ich würde als erstes mal mit dem Debugger zur Adresse von SetWindowsHookEx springen und dort gucken, ob direkt am Anfang vielleicht irgendein Sprung-Befehl steht, der auf Patching hindeutet. In dem Fall sollte es relativ einfach sein, den Hook zu umgehen, indem du einfach die Dummy-Operationen an die Stelle zurückkopierst.

Kann dir aber natürlich nicht garantieren, wie das externe Programm auf solche Modifikationen reagiert... falls es sich wirklich um einen Kopierschutz handelt, wer weiß, ob dieser so eine Aktion nicht als „Angriff“ wertet (auch wenn es unberechtigt ist).

[Gruber_Hans_12345]

ahso nein ich möchte nicht das andere Programm modifizieren

Ich dachte ob es eventuell gehen würde, das ich nachdem das andere Programm geladen ist, den Hook wieder lösche.
Oder sozusagen mein Programm vor diesen Hook "schütze"
sowas in der Art
eine Änderung oder Patch am fremden Programm will ich auf keinen Fall vornehmen

[Namenloser]

Nein, ich meinte ja auch in deinem eigenen Adressraum. Denn falls deine Theorie stimmt, dann müsste das fremde Programm ja irgendwie Code in dein Programm injiziert haben. Trotzdem weiß man nicht, wie das fremde Programm darauf reagiert... wäre ja möglich, dass der Kopierschutz, so er denn dafür verantwortlich ist, auch regelmäßig überprüft, ob die Hooks noch da sind.

[Aphton]

Nun, hooks funktionieren nach folgendem Schema:
- es wird entweder rein auf korrektem Wege per SetWindowsHookEx() global (Dll) gehookt -- hier können aber nur vorgegebene Sachen abgefangen werden
- oder, die vorige Methode wird verwendet, um eine Dll in den Adressraum aller anderen Prozesse zu laden (SetWindowHookEx() macht das) damit
anschließend folgende Art von (dirty) Hook gesetzt werden kann:
-- IAT/EAT Hook (Address Table Hook)
-- Code Patching (wie der Namenlozer bereits geschrieben hat)

Was du nun machen kannst, als Hotfix, ist, zunächst einmal rausfinden, um was für Art von Hook es sich handelt - es ist entweder
IAT oder Code Patching (das sind die gängigsten)
Wenn IAT:
- die Adresse, die in der Import Table steht, ist "modifiziert" - deine Aufgabe ist es, iwie rauszufinden, wo sie sich wirklich befindet
dafür kannst du mal die hookende Anwendung terminieren, deine App normal starten und per GetProcessAddress() die korrekte Adresse ermitteln (sie liefert die modifizierte beim IAT Hook)

Wenn Code Patching:
- kann schnell erkannt werden, da die Stackframe Generierung überschrieben wurde (meisten mit einem absoluten jmp)
Siehst du soetwas, einfach zurückpatchen -- 0815 Stackframegenerirung reinschreiben

Also im Grunde müsstest du dann für deine Anwendung vom dirty Hook säubern!

Achja, noch etwas damit du nicht verzweifelst -- wenn die Hookende Anwendung beim Terminieren nicht ordentlich aufräumt bzw nicht den globalen Hook löscht, wird Windows weiterhin bei jedem Prozess den Hook laden (was ja nur ne Dll ist) - auch wenn die Anwendung geschlossen ist! Das kann verwirrend sein

[Bernhard Geyer]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1214691)

Oder sozusagen mein Programm vor diesen Hook "schütze"

Was passiert eigentlich wenn du dein Programm mit Adminrechten startest. Hier dürften eigene einfachen Hooks nicht aktiv sein/funktionieren.

[Gruber_Hans_12345]

Das ist mal mein Testcode

wenn fremdes programm gestartet ist, dann 8000 ms wenn nicht gestartet dann 60ms

GetProcAddress liefert in beiden Fällen die selbe Adresse zurück

Wenn ich das fremde Programm schließe, dann funktionieren die Aufrufe sofort wieder schnell

Ein Starten im Adminmode, oder mit Kompatiblitäts .... bringt auch nichts.

Delphi-Quellcode:

procedure TForm8.Button1Click(Sender: TObject);
var
    c       : cardinal;
    i       : integer;
begin
    c       := GetTickCount;
    //    CreateWindowEx

    for i:=0 to 100 do begin
        with TTimer.Create(nil) do
            Free;
    end;

    Memo1.Lines.Add(IntToStr(GetTickCount-c));
end;

procedure TForm8.Button2Click(Sender: TObject);
var
    LModule : HMODULE;
    temp    : Pointer;
begin
    LModule := GetModuleHandle(User32);
    if LModule <> 0 then
    begin
        temp    := GetProcAddress(LModule, 'CreateWindowExA');
        Memo1.Lines.Add('CreateWindowEx : '+IntToHex(integer(temp), 8));
    end;
end;

[Aphton]

Ok, hast du bei der Adresse im Speicher (per Delphi-Debugger z.B. -- damit kannste auch schön Assembler Code sehen)
nachgeschaut? Ist dort die Standardstackframegenerierung drinnen?

Edit
Also das hier:

Code:

user32.CreateWindowExA:
7536D22E 8BFF             mov edi,edi
7536D230 55               push ebp
7536D231 8BEC             mov ebp,esp
7536D233 6801000040       push $40000001
7536D238 FF7534           push dword ptr [ebp+$34]
7536D23B FF7530           push dword ptr [ebp+$30]
/*snip*/

user32.CreateWindowExW:
75368A29 8BFF             mov edi,edi
75368A2B 55               push ebp
75368A2C 8BEC             mov ebp,esp
75368A2E 6800000040       push $40000000
75368A33 FF7534           push dword ptr [ebp+$34]
75368A36 FF7530           push dword ptr [ebp+$30]
/*snip*/

(Das mov edi, edi -- push ebp -- mov ebp, esp)

Achja, du müsstest übrigens für beide überprüfen, ob die Adresse anders ist (für die ..A und ..W)

[Gruber_Hans_12345]

hmmmmmmmmmmm nun bin ich mir nicht mehr so sicher ob es wirklich ein Hook ist

das dauert lange

Delphi-Quellcode:

aHWND       := CreateWindowEx(WS_EX_TOOLWINDOW, UtilWindowClass.lpszClassName, '', WS_POPUP {+ 0}, 0, 0, 0, 0, 0, 0, HInstance, nil);

das nicht!

Delphi-Quellcode:

aHWND       := CreateWindowEx(WS_EX_TOOLWINDOW, UtilWindowClass.lpszClassName, '', WS_CHILD {+ 0}, 0, 0, 0, 0, 0, 0, HInstance, nil);

@Aphton: Ich habe leider auf dem System wo dieses Programm läuft kein Delphi drauf ...