Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi Überwachen welche Dateien ein Programm öffnet? (https://www.delphipraxis.net/142130-ueberwachen-welche-dateien-ein-programm-oeffnet.html)

Hedge 22. Okt 2009 13:17


Überwachen welche Dateien ein Programm öffnet?
 
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 22. Okt 2009 13:34

Re: Überwachen welche Dateien ein Programm öffnet?
 
Warum fängst du dazu jetzt einen neuen Thread an?

himitsu 22. Okt 2009 13:39

Re: Überwachen welche Dateien ein Programm öffnet?
 
in diesem Programm einfach "alle" Dateifunktionen (APIs) hooken, womit man Dateien öffnen kann

Bernhard Geyer 22. Okt 2009 13:53

Re: Überwachen welche Dateien ein Programm öffnet?
 
Schau dir doch mal den Process Monitor an.

Hedge 22. Okt 2009 14:21

Re: Überwachen welche Dateien ein Programm öffnet?
 
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 22. Okt 2009 18:14

Re: Überwachen welche Dateien ein Programm öffnet?
 
Zitat:

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 22. Okt 2009 20:50

Re: Überwachen welche Dateien ein Programm öffnet?
 
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. :angel2:

Fridolin Walther 22. Okt 2009 21:24

Re: Überwachen welche Dateien ein Programm öffnet?
 
Zitat:

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:

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. :angel2:

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 22. Okt 2009 22:16

Re: Überwachen welche Dateien ein Programm öffnet?
 
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 22. Okt 2009 22:24

Re: Überwachen welche Dateien ein Programm öffnet?
 
@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? :angel:

Hedge 22. Okt 2009 22:31

Re: Überwachen welche Dateien ein Programm öffnet?
 
Es handelt sich um Musikprogramme.
Da ist es wirklich unwahrscheinlich, dass die was gegen Hooks unternehmen.

Danke für eure großartige Hilfe.

Leider, musste ich feststellen, dass man das geplante Projekt auf diese Art (wahrscheinlich) nicht zuverlässig umsetzen kann.

Fridolin Walther 22. Okt 2009 22:42

Re: Überwachen welche Dateien ein Programm öffnet?
 
Zitat:

Zitat von himitsu
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.

In den meisten Fällen wollen Leute so eine Monitoring API haben um damit ihnen unbekannte Programme (meistens Malware) zu "beobachten". Unbekannte Programme können dabei durchaus zu den 1% der Anwendungen gehören, die versuchen API Hooks zu umgehen. Sehr viele kommerzielle Kopierschutzsysteme, die oft von Shareware Programmierern genutzt werden, bieten z.B. die Möglichkeit API Hooks automatisiert zu entfernen. Malware ist ein anderes Feld in denen solche Techniken oft genutzt werden. Die Anti-Rootkit Industrie wäre sogar ein ganzer Zweig innerhalb der IT Security, die sich großteils mit dem Aufspüren und Umgehen von Hooks beschäftigt ;).

Alles was ich letztlich sagen will ist, daß wenn die Lösung mit beliebigen Anwendungen und nicht mit nur mit "einigen" oder den "meisten" laufen soll, Usermode Hooks eher eine schlechte Wahl sind. Wenn ich dagegen eine spezifische Anwendung überwachen möchte, bei der ich sicher stellen kann, daß meine Usermode Hooks alles erfassen, ist dagegen nichts einzuwenden. Wobei es dann natürlich fraglich ist, ob ich die Hooks dann überhaupt noch brauche ;).

Zitat:

Zitat von himitsu
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? :angel:

Schlechte Usermode Hooks beeinträchtigen ebenfalls die Stabilität. Zwar nicht des kompletten Systems, wohl aber der Anwendung. Und ja, ich ziehe eine außerordentlich gut dokumentierte Methode etwas zu implementieren wie z.B. den File System Mini Filtern einer gänzlich undokumentierten und selbstgestrickten Lösung (aka 99% aller im Umlauf befindlichen "Hooking Engines") vor.


Alle Zeitangaben in WEZ +1. Es ist jetzt 19:25 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz