Hallo,
kann ich mein Programm davor schützen, das eine DLL injectet wird? Wenn ja wie?

Einfach eine selbstgeschriebene DLL laden und in der DllMain "DLL_THREAD_ATTACH" auswerten.

-> Wird schließlich immer dann durchlaufen wenn im Prozess ein Thread oder ein Remotethread gestartet wird. <-

Wird schließlich immer dann durchlaufen wenn im Prozess ein Thread oder ein Remotethread gestartet wird. <-

Es ist ja nicht so, daß man für das Injizieren von Fremdcode einen Thread erstellen müßte.

Es ist ja nicht so, daß man für das Injizieren von Fremdcode einen Thread erstellen müßte.

Das hat der OT auch nicht gefragt. Und komm jetzt wieder nicht damit, daß eh alles zwecklos ist.

audacia schrieb:

Es ist ja nicht so, daß man für das Injizieren von Fremdcode einen Thread erstellen müßte.

Das hat der OT auch nicht gefragt.

Es ging, wenn ich das recht verstanden habe, um das Injizieren von DLLs. Und sobald man Code in einen fremden Prozeß injizieren kann, kann man auch DLLs laden.

desinjector schrieb:

Und komm jetzt wieder nicht damit, daß eh alles zwecklos ist.

Ich kann mich nicht erinnern, mich hier zuvor als überzeugter Nihilist geäußert zu haben

Ich kann mich nicht erinnern, mich hier zuvor als überzeugter Nihilist geäußert zu haben

Bitte vielmals um Entschuldigung. Beim "Antwort schreiben" ist mir die Kaffetasse umgekippt. Das hat meine Antwort negativ beeinflußt.

audacia schrieb:

Und sobald man Code in einen fremden Prozeß injizieren kann, kann man auch DLLs laden.

OK. Aber der Code muß auch ausgeführt werden. Via Remotethread wäre schlecht (-> eigene DLL).
Also irgendwo in die EXE injizieren an einer Stelle, wo früher oder später der Thread "von selbst" vorbeikommt.
Aber sämtliche geeigneten Stellen in der EXE sind dem Programmierer bekannt.
Und eventuell gehookte Funktionen in "Standard-DLLs" lassen sich auch erkennen.

Also irgendwo in die EXE injizieren an einer Stelle, wo früher oder später der Thread "von selbst" vorbeikommt.

Gar nicht nötig. Man könnte einen laufenden Thread direkt entführen.

Man könnte einen laufenden Thread direkt entführen.

Keine der besseren Ideen falls das Programm eh nur einen Thread hat.
Und Get/SetThreadContext verursacht nur heftigste Synchronisierungsschwierigkeiten und sorgt letztendlich dafür, daß zwar eine DLL injectet wird, sie aber ohne Funktionalität ist. In etwa liegt sie dann nur im Speicher und "tut" nichts.

Und Get/SetThreadContext verursacht nur heftigste Synchronisierungsschwierigkeiten und sorgt letztendlich dafür, daß zwar eine DLL injectet wird, sie aber ohne Funktionalität ist. In etwa liegt sie dann nur im Speicher und "tut" nichts.

Das reicht aber vollauf, um etwa WinAPI-Aufrufe zu hooken.

desinjector schrieb:

Eine gut programmierte Multithread-Anwendung bemerkt immer wenn ein selbsterzeugter Thread irgendwie "verschwindet".

Du meinst, sie stürzt ab oder bleibt hängen?

Nein, um das Verschwindenlassen eines Threads geht es ja auch nicht, eher um das kurzfristige Entführen zwecks Aufrufs von LoadLibrary(). Oben vorgeschlagenem Thread-Detektionsansatz könnte man dann begegnen, indem man vor der Erstellung eines Threads DisableThreadLibraryCalls() aufruft, dann mittels IPC die injizierende Anwendung dazu bringt, mit CreateRemoteThread() einen Thread zu erstellen, so daß es der attackierten Anwendung nicht hilft, CreateThread() zu hooken.

indem man vor der Erstellung eines Threads DisableThreadLibraryCalls() aufruft, dann mittels IPC die injizierende Anwendung dazu bringt, mit CreateRemoteThread() einen Thread zu erstellen, so daß es der attackierten Anwendung nicht hilft, CreateThread() zu hooken

Ach nein, dann hätte die attackierte Anwendung auch gleich DisableThreadLibraryCalls() abfangen können

Bleibt also das Hooken von WinAPI-Aufrufen als Anwendungsmöglichkeit.

Aber nicht wenn ich den Thread, der das überwacht, auffresse

Der Witz ist ja grade, daß das alles ohne "Guard-Thread" funktioniert. :p

audacia|off schrieb:

Oben vorgeschlagenem Thread-Detektionsansatz könnte man dann begegnen, indem man vor der Erstellung eines Threads DisableThreadLibraryCalls() aufruft, dann mittels IPC die injizierende Anwendung dazu bringt, mit CreateRemoteThread() einen Thread zu erstellen, so daß es der attackierten Anwendung nicht hilft, CreateThread() zu hooken.

Mal abgesehen davon, wann und wo das aufgerufen werden soll, kennt eine Anwendung zu jeder Zeit die Anzahl ihrer Threads.

audacia|off schrieb:

Bleibt also das Hooken von WinAPI-Aufrufen als Anwendungsmöglichkeit.

Dann greift alles vorhin schon gesagte. Gehookte WinAPI-Aufrufe zu erkennen gehört bereits zum Standardrepertoire.

Gehookte WinAPI-Aufrufe zu erkennen gehört bereits zum Standardrepertoire.

Und wie geht das konkret?

-> Brauche ich CreateFile und Co. um an eine Datei auf der Festplatte heranzukommen?

Konsequenterweise müßte der Hook dann sämtliche Sprungadressen entsprechend anpassen.

Btw. sollen etwa (zur Sicherheit) sämtliche NTDLL-Funktionen gehookt werden?
Und soll auch noch so ein fetter Hook nicht auffallen?

ich sagte doch CreateFile und ggf. 2,3 andere reichen vollkommen.

Vorausgesetzt der Programmierer hält sich auch dran.

MisterX schrieb:

und am besten macht man das mit nem kleinen treiber der einfach die einträge in der KeServiceDescriptorTable ändert.

Ist ja unter WIN64 auch kein Problem.