Herausfinden wenn ein Windows Prozess GetAsyncKeyState aufruft

HarteWare

Hallo,

ich möchte aus Spaß ein kleines Programm schreiben, bei dem ich z.B. einen Prozessname eingeben kann und das Programm untersucht wann und wie oft der Prozess die Win32 API Funktion GetAsyncKeyState aufruft (sozusagen als Keylogger-Detector). Ich weiß, dass es möglich ist, da manche Antivirus Programme es machen, aber ich möchte wissen wie.

[...] can easily be detected by looking for processes which query the keyboard with high frequency.

Muss man da irgendeinen Hook installieren? Ich habe auf der Doku zu SetWindowsHookEx keinen passenden Hook gesehen.

Kann mir jemand einen Tipp geben?

LG

HarteWare

Habe es letzten Endes geschafft, dass eine MessageBox auftaucht beim Aufruf: https://www.codeproject.com/articles/4118/api-monitoring-unleashed

Der Code ist nicht sehr gut für C++ etc., aber rein vom Prinzip kann ich damit arbeiten denke ich.

LG

hustbaer

Die meisten Antivirus Programme patchen sich übelst in das System rein. Wo es keine offizielle API vom OS gibt werden dann z.B. einfach DLLs im Speicher gepatched.

HarteWare

Mir ist jetzt gerade aufgefallen, dass meine dll nicht funktioniert, wenn das Programm mit MinGW kompiliert wurde. Und ich dachte fast ich hätte etwas "nützliches" programmieren können.

Ich nehme an die Leute von MinGW haben irgendwie ihre "eigene" WinAPI, und deshalb wird die User32.dll nicht geladen.

Aber ich denke vom Prinzip habe ichs schon verstanden, die hooken halt irgendwie die Funktionen, welche Malware missbrauchen könnten, und prüfen die Aufrufe dann.

rudi994

HarteWare schrieb:

Ich nehme an die Leute von MinGW haben irgendwie ihre "eigene" WinAPI

Stimmt wohl in gewisser Weise, hat vermutl. auch damit zu tun, daß das Original den Lizensierungs- und Nutzungbedingungen von µsoft unterliegt, während MinGW der GNU GPL unterliegt (wenn ich richtig informiert bin).

HarteWare schrieb:

deshalb wird die User32.dll nicht geladen.

Dazu müssen bei mir in CodeBlocks zuerst die nötigen Optionen gesetzt werden (Menu "Settings\Compiler", weiter im Dialog "Global Compiler Settings", Kartenreiter "Linker Settings", links im Feld "Link Libraries"). Da habe ich für meinen Bedarf z.B. folgendes: user32, kernel32, gdi32, comdlg32, comctl32

HarteWare schrieb:

meine dll nicht funktioniert, wenn das Programm mit MinGW kompiliert wurde ... MinGW ... "eigene" WinAPI

Na ja, das kann verschiedene Gründe haben. Z.B. bei Verwendung von neueren WINAPI-Features kann es sein, daß die MinGW-API veraltet ist bzw. die Makros WINVER und _WIN32_WINNT nicht auf dem neusten Stand sind (entsprechend der API der verwendeten Windows-Version). Um das zu ändern, kann/muß der Benutzer in seinem Quellkode die Makros WINVER und _WIN32_WINNT definieren, und zwar bevor irgendwelche WINAPI-Header wie <windows.h> inkludiert werden. Hier mal als Beispiel für Win7:

#ifndef WINVER
    #ifndef _WIN32_WINNT_WIN7
    // für Win7 hat _WIN32_WINNT_WIN7 den Wert 0x0601 
        #define WINVER 0x0601
    #else
        #define WINVER _WIN32_WINNT_WIN7
    #endif
#endif // WINVER

#ifndef _WIN32_WINNT
    #define _WIN32_WINNT WINVER
#endif // _WIN32_WINNT

Siehe dazu auch _WIN32_WINNT-Konstanten aus <SDKDDKVer.h> der MFC-Library. LG

hustbaer

rudi994 schrieb:

HarteWare schrieb:

Ich nehme an die Leute von MinGW haben irgendwie ihre "eigene" WinAPI

Stimmt wohl in gewisser Weise, hat vermutl. auch damit zu tun, daß das Original den Lizensierungs- und Nutzungbedingungen von µsoft unterliegt, während MinGW der GNU GPL unterliegt (wenn ich richtig informiert bin).

Sie haben (bzw. hatten zumindest) eigene Header Files und "import Libs" (die static Libs mit den DLLIMPORT direktiven/stubs drinnen). Eigene WinAPI würde ich das aber nicht nennen, da im Endeffekt dann die ganze normalen Windows DLLs verwendet werden.

rudi994 schrieb:

Na ja, das kann verschiedene Gründe haben. Z.B. bei Verwendung von neueren WINAPI-Features kann es sein, daß die MinGW-API veraltet ist bzw. die Makros WINVER und _WIN32_WINNT nicht auf dem neusten Stand sind (...)

Das sollte eigentlich alles Wurst sein. Wenn das Programm GetAsyncKeyState aufruft, dann ruft es GetAsyncKeyState auf. Und davon gibt's nur eine Variante soweit ich weiss.

Könnte mir höchstens noch vorstellen dass es an einem Bitness-Mismatch liegt. Also wenn die Injection für 64 Bit ist der Prozess aber 32 Bit. Hätte jetzt mit MinGW nix zu tun, aber wäre ein möglicher Grund warum es mit einem Programm geht mit einem anderen aber nicht.

HarteWare

hustbaer schrieb:

Könnte mir höchstens noch vorstellen dass es an einem Bitness-Mismatch liegt. Also wenn die Injection für 64 Bit ist der Prozess aber 32 Bit. Hätte jetzt mit MinGW nix zu tun, aber wäre ein möglicher Grund warum es mit einem Programm geht mit einem anderen aber nicht.

Hab grad nachgeschaut, mein MinGW in QtCreator ist 32bit und in VisualStudio hatte ich 64bit eingestellt (weiß ich noch). Ich erinnere mich jetzt, dass man bei der Dll Injection die beiden nicht mischen kann. Daran wirds gelegen haben. D.h. ich müsste wohl sowohl 32bit, als auch 64bit dlls kompilieren und laden, eine wird dann funktionieren bei jeder Software^^

Ich frage mich jetzt aber noch: Ich kann z.B. einfach eine MessageBox von der Dll aus anzeigen lassen, aber angenommen ich möchte die Anzahl der Aufrufe mitzählen, und dann z.B. bei mehr als 60/sec einem "antivirus" Programm mitteilen, dass da ein verdächtiges Programm läuft, wie kann ich von der Dll aus dem Programm Information "zuschicken"? Oder würde man alles von der dll aus machen?

Edit: nachdem ich das hier gelesen habe, bin ich wohl eh auf dem Holzweg:

However, on Pre-Vista systems, Antivirus companies used to use rootkit-like features to guard the doors (even if it was not recommended at all by Microsoft) and be able to protect your system. They used what we call “Hooks” (API detours for filtering purpose).

On Vista+, Microsoft provided APIs to insert our low level driver between userland calls and kernel APIs. That way, it’s easy to register an antivirus product into the kernel. More, that kind registration based system allows us to dispatch our system security into layers, where several products with different aims can cohabit. This was not the case for hooks, as the implementation was totally product dependant.

Quelle: https://www.adlice.com/making-an-antivirus-engine-the-guidelines/

hustbaer

Na da hatte ich heute wieder ne gute Glaskugel...

hustbaer

Gibt hundertundeins verschiedene IPC/RPC Mechanismen. Shared Memory, Mailslots, Sockets, Pipes, DCOM, Window Messages, Files...
Ich würde aber vermuten dass Virenscanner das etwas "direkter" über den Kernelmode machen. Dazu braucht man aber nen Treiber, und da fängt's sehr schnell an kompliziert/aufwendig zu werden.