CreateProcess - "Global" Hook - Log

Abend,

wie kann ich einen Hook installieren, sodass ich "bescheid gesagt" bekomme, wenn ein neuer Prozess startet?

Gibt es eine bessere Möglichkeit als in einer Schleife eine Dll in jeden laufenden Prozess zu laden, welche die Funktion "CreateProcess" (etc.) hookt?

Gruß und danke.

floorball

wenn du ein bisschen was hier durchliest wirst du was finden
http://www.c-plusplus.net/forum/312122

Ich denke du redest von SetWindowsHookEx, aber welchen Hook meinst du genau?
WH_CBT scheint mir da noch am besten zu passen, aber meinen Zweck erfüllt es nicht, da es nicht über neue Prozesse informiert, oder übersehe ich etwas?

Oder habe ich komplett an dem vorbei gelesen, was du eigentlich meintest?

Jochen Kalmbach

Wenn ein neuer Prozess gestartet wird, wird jede DLL mittels DLL_PROCESS_ATTACH
informiert...

Hä? DLL_PROCESS_ATTACH bekommt eine DLL doch, wenn sie selbst in einen Prozess geladen wird?!

Jochen Kalmbach

Genau... und wenn Du einen globalen Hook installierst, was glaubst Du dann was mit Deiner DLL passiert???

-lowbyte- 0

Die mit SetWindowsHookEx installierten Hooks kannst Du nur für Win32/64 Programme brauchen, aber nicht für Consolen Programme, denn in die wird mit SetWindowsHookEx keine DLL in den Adressraum gemappt.

Jochen Kalmbach

Man kann einen Hook auch mittels "KnownDlls" machen...
http://www.codeproject.com/Articles/325603/Injection-into-a-Process-Using-KnownDlls

-lowbyte- 0

Jochen Kalmbach schrieb:

Man kann einen Hook auch mittels "KnownDlls" machen...
http://www.codeproject.com/Articles/325603/Injection-into-a-Process-Using-KnownDlls

Ja das ist eine möglichkeit...
Wenn er nur eine Benachrichtigung möchte ist das sicher eine akzeptable Lösung. Doch für mich stellt sich eher die Frage was er danach machen möchte. Wenn er den Prozess kontrollieren möchte ist das sicher die falsche Methode. Denn dann kommt er nicht um ein globalen CreateProcessW Hook herum. Noch tiefer ist natürlich besser.

Injection der Dll über CreateRemoteThread() ,"KnownDLLs" ,SetWindowsHookEx() ,Proxy Dll.

Bei der "KnownDLLs" Methode muss die DLL ab Win7 signiert sein, was sich allerdings wieder über die reg. deaktivieren lässt. Oder man bringt das Cert auch gleich selber mit.
Das andere ist das viele Malwarescanner diesen Weg ("KnownDLLs") als Sünde ansehen. Sollte nur erwähnt sein...

floorball

Sicher dass du den gesamten Beitrag auf den ich verlinkt habe gelesen hast
Auf der zweiten seite wirds interressant.

[quote="-lowbyte-"]Der Windows Explorer zum Bsp. braucht aber intern NtCreateProcessEx das aber praktisch nirgendwo Dokumentiert ist. Die Funktion müsstest Du hooken um denn Prozessstart vom Explorer.exe zu überwachen um den Processstart ganz früh zu erkennen![/quote]

Aber obem sind wahrscheinlich die besseren möglichkeiten

Wieso funktioniert bei mir eigentlich keins der tags??
Man kann sich dafür doch nicht etwa zu blöd anstellen oder ich etwa schon?

Jochen Kalmbach schrieb:

Wenn ein neuer Prozess gestartet wird, wird jede DLL mittels DLL_PROCESS_ATTACH
informiert...

Ach stimmt, soweit habe ich nicht gedacht

-lowbyte- schrieb:

Die mit SetWindowsHookEx installierten Hooks kannst Du nur für Win32/64 Programme brauchen, aber nicht für Consolen Programme, denn in die wird mit SetWindowsHookEx keine DLL in den Adressraum gemappt.

Was wäre da eine ähnliche Alternative, oder gibt es überhaupt eine?

-lowbyte- schrieb:

Denn dann kommt er nicht um ein globalen CreateProcessW Hook herum. Noch tiefer ist natürlich besser.

Daran habe ich eben zu erst gedacht. Mit SetWindowsHookEx lässt sich das natürlich realisieren (nur nicht bei den blöden Konsolen :()...
Desweiteren habe ich mich ein wenig informiert und bin dann auf "NtCreateSection" gestoßen, was wohl die beste Methode ist, um neue Prozesse "abzufangen".

Soweit ich das nun sehe, ist SetWindowsHookEx mit einem "NtCreateSection"-Hook die beste Methode, um mein Ziel zu realisieren, damit könnte ich ja auch die Erstellung neuer Prozesse unterbinden, wenn ich das richtig sehe.
Nur was mache ich mit den Konsolen, die davon nicht betroffen sind?
Vielleicht noch einen zusätzlichen Hook?

Gruß und danke jetzt schonmal

-lowbyte- 0

Jochen und meine Wenigkeit haben Dir bereits 2 Methoden genannt mit denen man auch in ein Win32-Consolen-Subsystem injecten kann.

Allerdings, das habe ich auch erfreut zur Kenntnis genommen, wollte jetzt nur wissen, ob es noch eine Art SetWindowsHook für Konsolen gibt...

hustbaer

Jochen Kalmbach schrieb:

Man kann einen Hook auch mittels "KnownDlls" machen...
http://www.codeproject.com/Articles/325603/Injection-into-a-Process-Using-KnownDlls

Danke für den Link
Hab' mir gleich mal ne Bookmark gemacht, falls ich sowas mal brauchen sollte...

Hallo, ich muss den Thread noch einmal wiederbeleben...
Habe nun

Jochen Kalmbach schrieb:

Man kann einen Hook auch mittels "KnownDlls" machen...
http://www.codeproject.com/Articles/325603/Injection-into-a-Process-Using-KnownDlls

mal ausprobiert, da es doch sehr interessant klingt und ich noch nichts in der Richtung gemacht habe...
Nunja, der Code ist ja größtenteils auf der Seite vermerkt, trotzdem hier mal mein Versuch...
Nicht über die fehlenden Fehlerabfragen wundern, die kontrolliere ich momentan einfach mit dem Debugger.
Die DLL habe ich, meiner Meinung nach, erfolgreich erstellt, nur der Loader macht mir Probleme. Habe auf einen Service verzichtet, da zum Testen eine einfache Anwendung genügt.
Um Fehler vorzubeugen, weil es ws2_32.dll in KnownDlls32 schon gibt, habe ich die Dll dem Reg-Schlüssel "ExcludeFromKnownDlls" gegeben...

NTSTATUS stat;

	NtCreateSection = (T_NtCreateSection)GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtCreateSection");
	NtOpenDirectoryObject = (T_NtOpenDirectoryObject)GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtOpenDirectoryObject");
	NtMakePermanentObject = (T_NtMakePermanentObject)GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtMakePermanentObject");

	UNICODE_STRING normalize_dll_path;
	WCHAR dll_path[] = L"\\DosDevices\\L:\\PLATZHALTER\\ws2_32.dll"; // meine erstellte Dll
	RtlInitUnicodeString(&normalize_dll_path, dll_path);
	OBJECT_ATTRIBUTES fileattributes;
	InitializeObjectAttributes(&fileattributes, &normalize_dll_path, OBJ_CASE_INSENSITIVE, NULL, NULL);
	IO_STATUS_BLOCK iosb;
	HANDLE hfile;
	stat = NtOpenFile(&hfile, FILE_GENERIC_READ | FILE_GENERIC_WRITE | FILE_GENERIC_EXECUTE, &fileattributes, &iosb, FILE_SHARE_READ | FILE_SHARE_WRITE, 0);

	UNICODE_STRING      dir_string;
	RtlInitUnicodeString(&dir_string, L"\\KnownDlls32");
	OBJECT_ATTRIBUTES   dir_attr;
	InitializeObjectAttributes(&dir_attr, &dir_string, OBJ_CASE_INSENSITIVE, NULL, NULL);			
	HANDLE hdir;
	stat = NtOpenDirectoryObject(&hdir, DIRECTORY_ALL_ACCESS, &dir_attr); // #define DIRECTORY_ALL_ACCESS (STANDARD_RIGHTS_REQUIRED | 0xF)

	DWORD bytes;
	SECURITY_DESCRIPTOR tmp;
    GetKernelObjectSecurity(hdir, DACL_SECURITY_INFORMATION, &tmp, sizeof(tmp), &bytes);	
	SECURITY_DESCRIPTOR *sd = (SECURITY_DESCRIPTOR*)malloc(bytes + zusätzlichen_speicherplatz_nur_zur_sicherheit);
	GetKernelObjectSecurity(hdir, DACL_SECURITY_INFORMATION, &sd, bytes + zusätzlichen_speicherplatz_nur_zur_sicherheit, &bytes);		

    UNICODE_STRING normalize_section_name;
    RtlInitUnicodeString(&normalize_section_name, L"\\KnownDlls32\\ws2_32.dll");
	OBJECT_ATTRIBUTES sectionAttr;
    InitializeObjectAttributes( &sectionAttr, &normalize_section_name, 0, NULL, NULL);		
	HANDLE hsec;
	stat = NtCreateSection(&hsec, SECTION_ALL_ACCESS, &sectionAttr, NULL, PAGE_EXECUTE_READWRITE, SEC_IMAGE, hfile);

	stat = NtMakePermanentObject(hsec); // Rückgabewert: 0xC0000061

	return 0;

Bis NtMakePermanentObject gibt´s keine Fehler und das Objekt wird auch (laut WinObj) erstellt. Aber NtMakePermanentObject schlägt dann eben fehl (0xC0000061, wo finde ich die Erklärung für diesen Fehler?), wodurch sich das erreichte sozusagen in Luft auflöst...
Kann mir da jemand helfen?

Vielen Dank nochmals!

Jochen Kalmbach

NtMakePermanentObject ist keine Funktion der WinAPI...

Das heißt?
Ist doch in der ntdll.dll enthalten und wird auch in deinem Link verwendet... wo liegt das Problem?

Gruß

Jochen Kalmbach

ntdll ist nicht die WinAPI...

Die WinAPI ist ein SubSystem von Windows... und nur die WinAPI (und jetzt auch WinRT) ist dokumentiert...

-lowbyte- 0

Wie bereits schon erwähnt wurde, existiert neben den Bibliotheken der Windows API in Windowsversionen ab Windows NT/2000 noch eine weitere Bibliothek, der ebenfalls eine zentrale Bedeutung zukommt. Die Bibliothek ntdll.dll enthält Funktionen einer zweiten Schnitt-stelle, welche Native API genannt wird. Viele Funktionen der Windows API sind lediglich Wrapper um Funktionen der tiefer liegenden Native API, d.h. dass bei einem Aufruf einer Windows API-Funktion, diese wiederum eine Funktion der Native API aufruft. Der Grund für dieses Zwei-Schichten-System besteht in einer erhöhten Portabilität von Windowsprogrammen. Die Implementierung der Native API unterscheidet sich bei den verschiedenen Windowsversionen, aber die Windows API bleibt weitestgehend gleich. Dadurch ist es möglich, dass eine Anwendung auf verschiedenen Windowsversionen ausführbar ist, wenn sie mithilfe der Windows API implementiert ist. Anwendungen können zwar auch direkt auf Funktionen der Native API zurückgreifen, jedoch ist dann die Portabilität nicht mehr gewährleistet. Da es von Microsoft nicht beabsichtigt war, dass Anwenderprogramme Funktionen der Native API direkt benutzen, ist diese Schnittstelle sehr schlecht dokumentiert. Auch findet sich im Vergleich zur Windows API recht wenig Literatur zu dieser Schnittstelle. Kurzgesagt ist ntdll die letzte Stelle bevor mit SYSENTER in den Kernelmode geschaltet wird.

http://undocumented.ntinternals.net/

http://technet.microsoft.com/de-de/sysinternals

Ja, das ist mir ja bekannt, aber was bedeutet das jetzt für mein Problem? Kann ich NtMakePermanentObject nun (anscheinend unter Win7) vergessen?

Gruß

CreateProcess - &quot;Global&quot; Hook - Log

CreateProcess - "Global" Hook - Log