Überwachen welche Dateien ein Programm öffnet?

[Hedge]

Ich möchte überwachen welche Dateien ein einzelnes Programm öffnet ohne große Performance-Einbußen beklagen zu müssen.

Luckie hat bereits einen Dateisystemtreiber vorgeschlagen, aber ich kann nicht davon ausgehen, dass es beim Anwender möglich ist einen zu installieren, weswegen es ohne gehen muss.

Hat Jemand eine Idee wie man das machen kann?

[Luckie]

Warum fängst du dazu jetzt einen neuen Thread an?

[himitsu]

in diesem Programm einfach "alle" Dateifunktionen (APIs) hooken, womit man Dateien öffnen kann

[Bernhard Geyer]

Schau dir doch mal den Process Monitor an.

[Hedge]

Danke Bernhard,
Der Process-Monitor hilft mir sehr weiter. Damit kann ich schonmal schauen wie ich Filtern muss und nach welchen Regeln die Daten die ich brauche ermittelt werden sollen.
Super Tipp. Hab schon lange mal so ein Programm gebraucht.

@himitsu: Alle = ntcreatefile, ntopenfile, ntreadfile oder fällt dir noch was Spannendes ein?

@Luckie: Sorry, eine meiner Zwangsneurosen, wenn ich nen Thread erstelle, sich aber kurz darauf die eigentliche Frage ändert (erst wollte ich wissen wie es global gemacht wird, jetzt aber nur noch lokal auf 1 Prozess bezogen).

[Fridolin Walther]

Zitat von Hedge:

Luckie hat bereits einen Dateisystemtreiber vorgeschlagen, aber ich kann nicht davon ausgehen, dass es beim Anwender möglich ist einen zu installieren, weswegen es ohne gehen muss.

File System Mini Filter ist der einzig wirklich saubere und verlässliche Weg. Es bestünde zwar die Möglichkeit mit Hilfe von Usermode Hooks einen Teil der Zugriffe zu überwachen (eigentlich alle APIs zum Zugriff auf Dateien enden in NtCreateFile oder NtOpenFile), allerdings wirst Du je nach Situation auch für die Usermode Hooks Admin Rechte benötigen. Entsprechend ist die Aussage, daß Du nicht davon ausgehen kannst einen Treiber installieren zu können hinfällig.

Außerdem ist es trivial die entsprechenden System Services an Deinen Hooks vorbei direkt anzusprechen ohne, daß Deine Hooks überhaupt eine Chance hätten dies zu bemerken.

[himitsu]

Aber wenn er nur überwachen möchte was EIN BESTIMMTES Programm macht, dann könnten die Hooks ausreichen.
Und um zu schauen welche APIs dieses Programm nutzt, die Liste der statisch gelinkten APIs kann man aus der EXE und den DLLs auslesen und ein Hook auf GetProcAdress liefert notfalls den Rest.

OK, hier gibt es ja irgendwo einen Code, welcher sowas ohne GetProcAdress macht, aber das sollte ja nicht der Normalfall sein und ist demnach zuerst mal zu ignorieren.

[Fridolin Walther]

Zitat von himitsu:

Aber wenn er nur überwachen möchte was EIN BESTIMMTES Programm macht, dann könnten die Hooks ausreichen.

Ein Bestimmtes könnte reichen. Ein Beliebiges nicht. Ein Bestimmtes könnte man reversen und so sicher gehen, daß garantiert niemals System Services direkt aufgerufen oder Hooks zurück gebogen werden. Bei einem Beliebigen ist das nicht möglich. Allerdings würde ich fast ausschließen, daß es um ein bestimmtes Programm geht. Denn wenn er das bestimmte Programm eh schon reversed um heraus zu finden welche APIs genau genutzt werden um seine Hooks wasserdicht zu machen, kann er auch selbst nachschauen welche Dateien die Anwendung öffnet. Da brauch er dann keine Hooks für .

Zitat von himitsu:

Und um zu schauen welche APIs dieses Programm nutzt, die Liste der statisch gelinkten APIs kann man aus der EXE und den DLLs auslesen und ein Hook auf GetProcAdress liefert notfalls den Rest.

OK, hier gibt es ja irgendwo einen Code, welcher sowas ohne GetProcAdress macht, aber das sollte ja nicht der Normalfall sein und ist demnach zuerst mal zu ignorieren.

Du irrst. Ich empfehle Dir Dir mal die ntdll.dll in nem Disassembler anzuschauen. Dort wirst Du nämlich sehen, daß die ganzen APIs nur Stubs sind:
http://img514.imageshack.us/img514/1...filedisasm.png

Wie Du siehst wird in EAX eine Nummer gepackt (service id). Diese Nummer wird vom System Service Dispatcher genutzt um innerhalb der System Service Dispatching Table die zur ID passende Kernel Mode Funktion zu finden. In EDX wird die Adresse der Parameter auf dem Stack aufbewahrt. Danach wird in den Kernel Mode gesprungen (an der Adresse zu der gesprungen wird befindet sich je nach Plattform ein anderer Opcode um im Kernel Mode zu landen, bei Intel SYSENTER, bei AMD SYSCALL etc.). Prinzipiell funktioniert übrigens auch weiterhin noch int 2Eh (wurde bis Windows 2000 oder irgend ein XP SP benutzt um in den Kernel Mode zu springen, da die spezifischen Opcodes damals noch nicht vorhanden waren).

Das Problem ist jetzt, daß mich kein Usermode Hook der Welt davon abhalten kann, diese 3 simplen Schritte selbst durchzuführen ohne eine Funktion aufzurufen. Wo kein Funktionsaufruf da ist, gibts halt letztlich auch keinen Funktionsaufruf der hookbar wäre. Natürlich könnte man wieder reversen, die eigene NtCreateFile Implementation im Code ausmachen und die Adresse gezielt hooken, aber da wären wir wieder am Beispiel oben. Wenn ich eh schon alles Reversen muss, kann ich die für mich interessanten Informationen auch direkt entnehmen ohne Hooks .

Mehr Informationen dazu gibts hier:
http://web.archive.org/web/200603152...NativeApi.html

[Dezipaitor]

Soweit ich weiß benutzt PM einen Treiber, um an mehr Infos zu kommen. Im Kernelmodus gibt es auch eine FilterAPI, um Funktionen zu filtern.

[himitsu]

@Fridolin Walther:
Klar ist sowas nicht bei jedem beliebigen Programm möglich, aber ich gehe einfach mal davon aus, daß bestimmt 99% aller Programme nur ganz stinknormale API-Aufrufe nutzen und keine Anstalten machen etwas gegen Hooking zu unternehmen.

(OK, abgesehn "größerer" Spiele, welche das Cheaten unterbinden wollen und einiger Programmierer, welche glauben ihr Programm sei soooooo gut, daß es extrem schüzenzwert wäre)

Und demnach muß masn nicht unbedingt jeden kleinen Fall beachten und gleich mit Treibern drauf losgehn.
Willst du wirklich unmassen fremder Treiber in deinem System, welche auch noch die Stabilität beeinträchtigen können, oder denkst du nicht, daß bei "einfachen" Programmen auch mal nur "einfache" Wege reichen?