Wie mitbekommen das eine datei geöffnet wurde?

[Nash26]

Ich möchte mitbekommen wenn eine Datei geöffnet worden ist.
Also wenn z.B. Programm fopen aufruft etc.

Gibt es da ein event in der windows api, das eine Datei geöffnet worden ist?

Ich bin jetzt nicht ein einer bestimmten Datei interessiert, sondern sagen wir alle unter einem Verzeichnis XY. Das kann aber beliebig viele Unterverzeichnisse haben.

Oder soll ich einen hook für CreateFile installieren?

[Fake oder Echt]

Mir persönlich fällt keine bessere Lösung ein, da es sich ja nicht um eine bestimmte Datei sondern eben jede Menge handelt.

Wenn du eine Änderung mitbekommen wollen würdest, dann wäre FindFirstChangeNotification in Verbindung mit WaitForSingleObject unter Umständen passend, allerdings zählt das pure Öffnen nicht als Änderung.

Falls du dich für einen Hook entscheidest, dann versuche es aber doch lieber gleich mit NtCreateFile im User Mode bzw. mit ZwCreateFile im Kernel Mode. Ich denke, damit fängst du mehr ab, als über fopen (willst du ja eh nicht) und CreateFile, falls irgendein Treiber bzw. eine Anwendung CreateFile umgeht.

[Nash26]

Diese

ZwCreateFile

methode ist also die funktion die Aufgerufen wird bevor dann wirklich eine Datei geöffnet wird?

Wie installiert man da am Besten einen Hook, welche Bibliothek würdest du dafür empfehlen?

[Fake oder Echt]

It depends. Vereinfacht könnte man das so fast stehen lassen. Der tatsächliche Unterschied liegt im Kern unter anderem im Aufruf von InitializeObjectAttributes. Das ist aber bei weitem nicht alles, was es da zu beachten gibt. Ich empfehle diesen Artikel um die Unterschiede zumindest überblicken zu können: http://www.osronline.com/article.cfm?article=257.

Da ich nicht so ganz sicher bin, wofür du das aber genau brauchst, schaue hier: http://stackoverflow.com/questions/6066857/hook-createfilew. Vielleicht ist eine Abwandlung davon für dich ja bereits ausreichend. Weiterhin ist der in diesem Link verlinkte Artikel über Driver Development aus meiner Sicht empfehlenswert. Er schafft (wenn auch nur begrenzt) ein Grundverständnis für Treiberentwicklung, aber sensibilisiert vor allem.

[dot]

Ich bin kein Experte auf dem Gebiet, aber ich vermute wenn du das wirklich allumfassend lösen willst, wirst du einen File System Filter Driver schreiben müssen...

[gruml]

Wie macht es denn Process Monitor?
Da sieht man doch auch alle file activities inkl. open?!

[Fake oder Echt]

gruml schrieb:

Wie macht es denn Process Monitor?

dot schrieb:

File System Filter Driver

ProcessMonitor ist ja quasi der Nachfolger von FileMon. Dementsprechend hier der Quellcode von FileMon, da lässt sich das erkennen.

[trolololo]

WTF? Systemcalls hooken? FS-Driver? Hab zwar praktisch keine Ahnung von der Windows-API, bin mir aber ziemlich sicher, dass Windows ein Äquivalent zu inotify unter Linux oder kqueue unter BSD hat, sodass man nicht auf derartige Hacks zurückgreifen muss.

Und in der Tat gibt es das, gerade nochmal im Windows-Port einer Library hier nachgesehen. Nennt sich IO-Completion-Ports[1]. Das rekursive Betrachten eines Verzeichnisses ist dabei anscheinend sogar als Teil der System-API implementiert. Eine race-freie Implementierung im Userspace kann nämlich etwas tricky sein.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365198(v=vs.85).aspx

[Mechanics]

Nee, glaub ich nicht. Bin mir auch ziemlich sicher, dass Process Monitor dafür einen Treiber lädt. Wenns anders gehen würde, hätten die es auch anders gemacht. Jetzt seh jetzt auch nicht, wie dein Link hier weiterhelfen würde.

[DarkShadow44]

Ich sehe aber bei deinen " IO-Completion-Ports" keine Möglichkeit das bloße Öffnen einer Datei mitzubekommen...
Von OpenFile steht da nix...

[Fake oder Echt]

Completion Ports hatte ich auch kurz im Blick, kenne mich mit dieser Thematik allerdings nicht aus und bin damals nach kurzem Überfliegen zum Schluß gekommen, dass das hier nicht hilft. Denn die MSDN sagt zu dem File Handle, welches CreateIoCompletionPort übergeben werden soll:

An open file handle or INVALID_HANDLE_VALUE.

Demnach würde also auch hier nicht geprüft werden können, ob eine Datei geöffnet wird, da sie ja geöffnet werden muss, um überhaupt ein "open file handle" zu bekommen.

Falls dem nicht so ist, bitte ich um gern gesehene Korrektur!

EDIT: Mechanics und DarkShadow waren schneller ..

[hustbaer]

trolololo schrieb:

Hab zwar praktisch keine Ahnung von der Windows-API, bin mir aber ziemlich sicher

Fängt ja schonmal gut an...

Und in der Tat (...blaaaaaah...)

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365198(v=vs.85).aspx

IO Completion Ports haben mit dem was du machen willst Nash26 machen will so richtig gar nichts zu tun.

[secondsun]

Moin,

ich habe den Procmon mal in IDA geworfen und vielleicht geht das ja in die richtige Richtung?

[url]
http://pl.vc/5b89e
[/url]

[url]
http://msdn.microsoft.com/en-us/library/windows/hardware/ff549772(v=vs.85).aspx
[/url]

[trolololo]

hustbaer schrieb:

IO Completion Ports haben mit dem was du machen willst Nash26 machen will so richtig gar nichts zu tun.

Na, so kanns ja nun auch nicht sein. Eine unter Windows mithilfe von IO-Completion-Ports umgesetzte Implementierung eines FS-Notification-Systems mit grob inotify-ähnlicher API findest du u.a. hier (in Go):

http://code.google.com/p/go/source/browse/fsnotify/fsnotify_windows.go?repo=exp

Die Methoden AddWatch und readEvents sind wohl am relevantesten, ist aber sowieso nicht allzu viel Code.

Auch wenn ich jetzt ein wenig mehr über die Windows-IO-Completion-Ports lese, wirkt es vom Featureset immer noch in etwa vergleichbar zum BSD kqueue. Nur weil man damit auch massenweise andere Sachen machen kann (wie mit kqueue ja auch), heißt es ja noch lange nicht, dass es nicht zur Implementierung eines Filesystem-Notification-Systems taugt.

[trolololo]

trolololo schrieb:

Die Methoden AddWatch und readEvents sind wohl am relevantesten, ist aber sowieso nicht allzu viel Code.

Gemeint ist hier die package-interne Methode "addWatch" (mit kleinem a) und nicht die an API-Nutzer exportierte AddWatch.

[dot]

trolololo schrieb:

hustbaer schrieb:

IO Completion Ports haben mit dem was du machen willst Nash26 machen will so richtig gar nichts zu tun.

Na, so kanns ja nun auch nicht sein.

doch

trolololo schrieb:

Eine unter Windows mithilfe von IO-Completion-Ports umgesetzte Implementierung eines FS-Notification-Systems mit grob inotify-ähnlicher API findest du u.a. hier (in Go):

http://code.google.com/p/go/source/browse/fsnotify/fsnotify_windows.go?repo=exp

Diese Implementierung basiert auf ReadDirectoryChangesW(); I/O Completion Ports werden dort auch benutzt, nur eben für etwas völlig anderes, nämlich das Eventhandling...

Und es gibt afaik keinen sinnvollen und reliablen Weg, über ReadDirectoryChangesW() festzustellen, wann irgendwo irgendein Programm irgendwie irgendeine Datei öffnet...

[trolololo]

dot schrieb:

I/O Completion Ports werden dort auch benutzt, nur eben für etwas völlig anderes, nämlich das Eventhandling...

Ja, selbstverständlich. Das ist ja auch das eigentlich interessante bei FS-Notifications. Kann der Kernel mich über eine ablaufende Dateisysteoperation durch Auslösen eines Events (z.B. Filedeskriptor/-Handle wird 'ready') in Kenntnis setzen?

Und es gibt afaik keinen sinnvollen und reliablen Weg, über ReadDirectoryChangesW() festzustellen, wann irgendwo irgendein Programm irgendwie irgendeine Datei öffnet...

Ja, schade, Events für Open zu bekommen scheint mit dem Ansatz in der Windowsversion des genannten fsnotify-Packages tatsächlich nicht möglich zu sein. Ich hatte anfangs nicht realisiert, dass die Auswahl verfügbarer Events gegenüber den Unixvarianten.so stark eingeschränkt ist. Daher sorry fürs Führen in die Sackgasse.

[hustbaer]

@trolololo
Deine Behauptung dass man mit IO Completion Ports Files überwachen kann ist ca. so sinnvoll wie wenn ich behaupte dass man mit printf nen Sinus berechnen kann.

[0wn0r]

hustbaer schrieb:

@trolololo
Deine Behauptung dass man mit IO Completion Ports Files überwachen kann ist ca. so sinnvoll wie wenn ich behaupte dass man mit printf nen Sinus berechnen kann.

owned hard!