DLL Injection verhindern



  • LoadLibraryEx mit LOAD_LIBRARY_AS_DATAFILE ?

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



  • LoadLibrary ruft doch auch nur NtCreateFile auf 😉



  • Bei mir aber NTDLL.LdrLoadDll.

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



  • wieso soll der auffallen? und wieso sämtliche funktionen?ich sagte doch CreateFile und ggf. 2,3 andere reichen vollkommen. und am besten macht man das mit nem kleinen treiber der einfach die einträge in der KeServiceDescriptorTable ändert. was is daran fett? 🙂



  • MisterX schrieb:

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


  • Mod

    ... selbst unter 32bit auf Vista oder Windows 7 wirst Du etwas Probleme haben, diesen Treiber in Betrieb zu nehmen!



  • desinjector schrieb:

    MisterX schrieb:

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

    Vorausgesetzt der Programmierer hält sich auch dran.

    wie? alles geht über NtCreateFile, da kommt er nicht drum herum 😕



  • Hatten wir vorhin schon :
    Vorausgesetzt wird einfach, daß CreateFile die einzige Möglichkeit ist, um an eine Datei auf der Festplatte heranzukommen.



  • ist es auch weil alle anderen apis über diesen system call gehen. verstehst du dies denn nicht? 😕



  • MisterX schrieb:

    ist es auch

    Greift ein Betriebssystem allen Ernstes bei jedem Dateizugriff immer auf die Festplatte zu?



  • nö wieso sollt es? dafür gibs doch den cache manager.



  • Folglich muß CreateFile oder NtCreateFile nicht der einzig mögliche Weg sein. 🙂



  • was hat das denn damit tun? ob ein ReadFile von der festplatte oder ausm cache befriedigt wird ist doch vollkommen egal 😕



  • desinjector schrieb:

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

    Er. NEIN!
    Eine paranoid programmierte Anwendung bemerkt sowas.

    Da könntest du gleich behaupten "eine gut programmierte Anwendung bemerkt wenn man ihr ein File-Handle zumacht". Oder einfach irgendeins der milliarden Dinge tut die man gefälligst nicht zu tun hat, und auf die sich eine Anwendung ruhig verlassen darf (verlassen darauf dass sie nicht passieren).

    Threads sterben nicht einfach so. Code zu bauen der überprüft ob Threads "einfach so" sterben ist total paranoid und plem. Und eine zusätzliche Fehlerquelle, da man ja bei der (oft vielleicht nicht trivialen) Überprüfung Fehler machen könnte...

    Oh Mann die Kids... 🙄



  • hustbaer schrieb:

    Er. NEIN!
    Eine paranoid programmierte Anwendung bemerkt sowas.

    Für eine etwas genauere Definition wäre ich sehr dankbar.

    hustbaer schrieb:

    Da könntest du gleich behaupten "eine gut programmierte Anwendung bemerkt wenn man ihr ein File-Handle zumacht".

    Prüft Du etwa nie ein Handle auf Gültigkeit bevor Du es einsetzt? (Oder lernt man sowas heute nicht mehr?)

    hustbaer schrieb:

    Code zu bauen der überprüft ob Threads "einfach so" sterben ist total paranoid und plem.

    Läßt Du Deine Threads etwa "einfach so" loslaufen? 😮 Aber um Multithread-Anwendungen geht es hier eigentlich nicht.

    hustbaer schrieb:

    Oh Mann die Kids... 🙄

    Oh Mann die Programmierer die immer unter Zeitdruck arbeiten müßen ... 🙂



  • desinjector schrieb:

    hustbaer schrieb:

    Er. NEIN!
    Eine paranoid programmierte Anwendung bemerkt sowas.

    Für eine etwas genauere Definition wäre ich sehr dankbar.

    Die steht ein paar Zeilen weiter unten:

    ich schrieb:

    Threads sterben nicht einfach so. Code zu bauen der überprüft ob Threads "einfach so" sterben ist total paranoid und plem.

    Zu Deutsch: wenn ein Thread erstmal läuft, dann läuft er, solange er nicht beendet wird. Wenn ich weiss unter welchen Umständen der Thread beendet werden kann, wieso sollte ich dann überprüfen ob er anders beendet wurde? Oder "ge-hijackt"? Wenn es in meinem Code nicht vorkommt, dann prüfe ich es nicht.

    Beispiel: Object X "hat" seinen eigenen Thread, der periodisch irgendwas macht. Der Thread soll laufen solange es X gibt. Ich starte ihn also im ctor und beende ihn (kontrolliert) im dtor. Wenn nun böser injizierter Code Y dahergelaufen kommt und diesen Thread übernimmt, und dann abschiesst, wie zum Geier, und wieso zum Geier, sollte mein Programm das bemerken? Der User wird bloss bemerken dass es nichtmehr richtig funktioniert, weil ihm (dem Programm) jemand einen Thread geklaut hat. Programme darauf auszulegen noch zu funktionieren (oder auch nur es mitzubekommen*), wenn sie über Code-Injection brutalst vergewaltigt werden, ist plem. Warum? Weil es a) nicht wirklich möglich ist und b) es keine Anforderung sein sollte/kann/darf. Ein Programm hat zu funktionieren solange man ihm nicht "den Bauch aufschneidet"; darf aber ruhig anfangen Unfug zu treiben WENN man in seinen Eingeweiden rumwühlt.

    Was die Handle-Sache angeht: ein Handle prüft man nach dem Öffnen, oder wenn man es von einem "fremden" Programmteil übergeben bekommt. Wenn ich ein Handle bereits geöffnet und geprüft habe, wieso sollte ich es dann nochmal prüfen? Bloss weil es Tools wie Unlocker gibt die es mir "unterm Hintern weg" zumachen? Sicher nicht. Wenn der User will dass mein Programm tut was es tun soll, dann soll er gefälligst die Finger von Unlocker/... lassen. Das meinte ich.

    Genauso: wenn der User will das mein Programm funktioniert, dann soll er gefälligst nicht Code injecten der irgendwelche Threads übernimmt und/oder abschiesst.

    ----

    (*): was das mitbekommen angeht... das kann manchmal Sinn machen. Für diverse Security-Tools (Firewalls, ...), Online-Spiele, oder Tools wie PunkBuster. Für "normale" Programme allerdings nicht.



  • Dein Beitrag strotzt nur so vor "Famous Last Words". 👍

    Zumindest stehen diverse Techniken auch "normalen" Programmen zur Verfügung. Nur eben eingesetzt werden müssen sie.

    Ein Anwender kann auch unbeabsichtigt "böses" wollen (bzw. von wollen kann da keine Rede sein).

    Deshalb kann ich beim besten Willen (und Unwillen) nichts paranoides erkennen.



  • desinjector schrieb:

    Dein Beitrag strotzt nur so vor "Famous Last Words". 👍

    Zumindest stehen diverse Techniken auch "normalen" Programmen zur Verfügung. Nur eben eingesetzt werden müssen sie.

    Ein Anwender kann auch unbeabsichtigt "böses" wollen (bzw. von wollen kann da keine Rede sein).

    Deshalb kann ich beim besten Willen (und Unwillen) nichts paranoides erkennen.

    Und dein Beitrag ist nicht mehr als Blablubb.
    Kannst du mal irgendwas konkretes sagen? Irgendwas? Auch wenns vermutlich vollkommener Unsinn ist?



  • Auf Dein "Object X" greifen im ctor zwei Threads gleichzeitig zu. Dazu gibt es nichts konkretes zu sagen.



  • desinjector schrieb:

    Auf Dein "Object X" greifen im ctor zwei Threads gleichzeitig zu. Dazu gibt es nichts konkretes zu sagen.

    Nein, tun sie nicht.
    Du laberst nur Unsinn und unterstellst mir hinten herum unfähig zu sein.
    WTF?


Anmelden zum Antworten