Ordner "sperren"?
-
jeanlucpicard schrieb:
Ich hatte noch nie etwas mit File-System-Filter-Drivers zu tun. Ist das sehr aufwendig? Ist das irgendwo gut bescgieben?
SOllte im aktuellen DDK beschrieben sein (heisst ja jetzt KMDF und nicht mehr DDK...)...
http://www.microsoft.com/whdc/driver/wdf/KMDF_pkg.mspx
-
Funktionieren File-System-Filter-Driver nur mit WinNT-basierten Windows-Versionen. Hat sich irgendwo so gelsesen, vielleicht hab ich das aber auch falsch verstanden.
Wenn das der Fall wäre, müsste ich wohl "CreateFile" hooken. Hab schon dafür gegooglet, aber nicht das gefunden was ich mir vorgestellt habe (mit anderen Worten: ich hab die ganze Sache bis jetzt noch nicht ganz verstanden ;)).
Kennt sich da jemand aus oder kennt eine Seite, auf der das beschrieben ist?
-
Über API-Hijacking findest auf codeproject.com tonnenweise Artikel und für dich ist ein CreateFile/OpenFile-Hook wohl der einfachste Weg.
-
Erstmal Danke für eure Antworten.
Mir ist es nun gelungen "CreateFileA", "CreateFileW", "OpenFile" und "_lopen" zu hooken. Habs getestet, die Funktionen werden korrekt blockiert.
Allerdings kann das Programm, für das ich das ganze geschrieben habe, immer noch auf die Plugin-Files zugreifen.
Gibt es denn unter Windows noch andere Möglichkeiten/Funktionen, eine Datei zu öffnen, die ich auch noch blockiren muss?
-
Unter Windows gibt es viele Arten auf Dateien zuzugreifen... Auf DLLs wird i.d.R. nicht per CreateFile zugegriffen, sondern per LoadLibrary... daneben gibt es dann noch File-Mappings usw....
-
Die Plugins sind keine DLLs, von daher kann mir LoadLibrary egal sein. CreateFileMapping hab ich jetzt auch blockiert, hat aber auch nichts gebracht.
Kann man auch Funktionen, wie beispielsweise fopen irgendwie blocken? Würde das mit einem File-System-Filter-Driver funktionieren? Funktionieren diese Drivers auch mit Win9x oder nur NT?
Gibt es sonst noch andere Möglichkeiten mein Problem zu lösen?
-
fopen verwendet CreateFile...
-
Jochen Kalmbach schrieb:
fopen verwendet CreateFile...
Das dachte ich auch. Ich hab dann ein Test-Programm geschrieben, dass einmal auf eine Datei mittels CreateFile und einmel mittels fopen zugreift.
Da CreateFile gehooket ist, funktioniert der Zugriff mit CreateFile nicht, fopen funktioniert jedoch anstandslos.
Alles etwas seltsam
Hat jemand noch Antworten auf meine anderen Fragen?
-
Das liegt an Deiner Art des Hooks... Du hookst vermutlich nur Funktionen Deiner EXE/DLL... damit kannst Du natürlich keine Funktionen von anderen DLLs abfangen...
-
Ich hooke die Exe und alle DLLs, die von der Exe statisch eingebunden werden. Zudem hooke ich noch die vier LoadLibrary(Ex)(A|W)-Funktionen und die dadurch eventuell noch dynamisch geladenen DLLs.
-
Du hast es doch selber nachgewiesen, dass es nicht funktioniert, oder?
Ein sehr guter Artikel über hooks ist hier zu finden:
http://www.codeproject.com/system/hooksys.asp
-
Erstmal danke für den Link, war wirklich sehr informativ.
Meinen Hook habe ich inzwischen so erweitert, dass nun auch fopen korrekt blockiert wird. Allerdings gibt es jetzt andere Probleme. Zum Teil werden andere Programme nicht mehr korrekt aufsgeführt. Da ist wohl irgendwo noch ein Fehler im Code, den ich nicht finde.
Deshalb habe ich mir mal den Source-Code aus dem Artikle angesehen.
Ziemlich kompliziert. Zudem unterstützt mein Compiler noch keine "Shared sections" in DLLs.
Und das Beispiel-Programm startete gar nicht erst auf einem getesteten XP-SP2-Rechner und auf einem mit ME brach es mit einer Fehlermeldung ab. Nur auf einem XP-SP1-Computer lief das ganze.
Ich denke ja nicht, dass das an der Windows-Version liegt (laut Artikel sollte es ja auf allen getesteten PCs laufen), aber wenn das ganze so instabil ist, frage ich mich, ob das überhaupt der Richtige Weg ist?
-
Welchen Compiler hast n da? Überleg vielleicht mal, ob du auf VC++2005 umsteigst (--> ExpressEdition). Obwohl die SharedSections glaub ich ab Win2k nicht mehr nötig sind (<- korrigiert mich, wenn s falsch ist).
Greetz

-
Ich benutze noch irgend eine alte Version des Borland C++ Builders. Auf was anderes wollte ich eigentlich nicht umsteigen (hab mich so an die VCL gewöhnt). Eine neuere Version wollte ich mir schon länger mal zulegen, aber es gab bis jetzt keinen konkreten Anlass...

-
Ich kram den Thread hier nochmal raus.

Ich habe mich in den letzten Wochen etwas intensiver mit dem Thema API-Hijacking auseinandergesetzt, aber ich bekomme keine Implementation hin, die fehlerfrei funktioniert.
Ich habe dann die Beispiele von http://www.codeproject.com/system/hooksys.asp und http://www.codeproject.com/system/Paladin.asp mit "VC++ 2005 (Express Edition)" kompiliert, aber die entstehenden Programme scheinen nicht auf allen Systemen zu laufen, auf denen ich getestet habe (insbesondere unter XP SP2 läuft das ganze sehr instabil - mit SP1 funktionierts besser).
1. Kennt jemand noch zufällig ein funktionierndes Beispiel eines systemweiten File-Functions-Hook (das ich hoffentlich noch nicht kenne
)?
2. Würde man über einen solchen Hook auch Filezugriffe von .Net-Programmen abfangen können?3. Es wurde hier bereits ein "File-System-Filter-Driver" angesprochen. Das klingt eigentlich nach einer guten Lösung. Aber bevor ich mir das KMDF downloade, würde es mich interessieren, ob diese Driver auch unter Win9x laufen?
4. Ich nehme an, ein solcher Driver würde Dateizufriffe jeglicher Programme (also sowohl native Win32- als auch .Net-Anwendungen) unterbinden können, oder ist dem nicht so?
-
Win95 wird schon lange nicht mehr von MS supported und der Support für Win98 läuft dieses Jahr aus.
Für Win9x gab es aber IFSs:
http://www.sysinternals.com/Utilities/NtfsWindows98.htmlFür einen Einstieg siehe:
http://www.microsoft.com/whdc/driver/filterdrv/default.mspxDas IFS-Kit ist bei dem KMDF dabei...
-
Okay, danke erstmal.
Mal schauen wie weit ich komme
-
Jochen Kalmbach schrieb:
Das IFS-Kit ist bei dem KMDF dabei...
Sicher? Ich habe jetzt KMDF installiert (dafür musst ich erst noch das DDK installieren). Vom IFS war keine Rede. Ich wüsste auch nicht wo das gelandet sein sollte?
Sollte es nicht auch Beispielcode für einen File System Filter geben? Ich kann keinen finden (weder im den Subdirectories des DDK oder KMDF noch im Netz).
-
Es kann sein, dass ich mich da doch getäuscht habe... ich muss zugeben ich habe es nicht selber probiert; hab es aber irgendwo gelesen... sorry!
Es scheint so also ob es doch bloss bestellbar wäre...
http://www.microsoft.com/whdc/devtools/ifskit/ServerIFSKitOrderinfo.mspx
-
Da das jetzt mit dem Filter Driver auch nicht so ganz funktioniert hat, hab ich mich noch ein bisschen umgesehen und mich dann entschlossen, die madCodeHook-Bibliothek zu benutzen.
Ich musste für NT-Useraccounts noch einen kleinen Service schreiben, aber das funktioniert alles soweit ganz gut.Einen Dateizugriff abzufangen und zu blockieren hab ich hinbekommen. Nun wollte ich versuchen, dem Programm die Dateien, auf die es nicht zugreifen können soll gar nicht erst anzubieten.
Dafür habe ich FindFirstFile(Ex)/FindNextFile gehookt.Jetzt meine Frage: Wie komme ich an den vollständigen Pfad+Namen der Datei WIN32_FIND_DATA.cFileName?
GetFullPathName funktioniert natürlich nicht, da über FindFile* ja nicht unbedingt nur im aktuellen Verzeichnis gesucht wird.