4. CreateProcess - "Global" Hook - Log

CreateProcess - "Global" Hook - Log


  • 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...

    0
  • ?

    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!

    0
  • J

    NtMakePermanentObject ist keine Funktion der WinAPI...

    0
  • ?

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

    Gruß

    0
  • J

    ntdll ist nicht die WinAPI...

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

    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

    0
  • ?

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

    Gruß

    0
  • -

    CreateProcess_log schrieb:

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

    Gruß

    Dies soll nur bedeuten dass sich etwas ändern kann, aber nicht muss!

    0
  • ?

    Okay... ist es jemanden bekannt, dass sich etwas geändert hat?
    Wobei ich mir eigentlich garnicht vorstellen kann, dass es im Usermode möglich sein soll, eine Handle-Referenz zu erhöhen, aber ich lasse mich gerne belehren 😉

    0
  • -

    CreateProcess_log schrieb:

    Okay... ist es jemanden bekannt, dass sich etwas geändert hat?
    Wobei ich mir eigentlich garnicht vorstellen kann, dass es im Usermode möglich sein soll, eine Handle-Referenz zu erhöhen, aber ich lasse mich gerne belehren 😉

    Bei NtMakePermanentObject() hat sich nichts geändert... soweit ich weis.

    CreateProcess_log schrieb:

    dass es im Usermode möglich sein soll, eine Handle-Referenz zu erhöhen...

    Probiere es doch einfach aus. Also etwas kannst Du ja auch beisteuern... Es wird Dir hier glaube ich niemand alle Infos über solche Undokumentierten Kram verzapfen.. da dies zum Teil mit relative hohem Zeitaufwand verbunden ist, und niemand einfach so seine Tricks verrät... im Netz findest Du genügend Info...wenn Du nur wüsstest nach was Du suchen sollst...aber auch das kommt mit der Zeit.
    Für mich ist hier Schluss.

    0
Anmelden zum Antworten