Guybrush Threepwood Geschrieben 27. Februar 2006 Geschrieben 27. Februar 2006 Gibt es eine Möglichkeit (einen entsprechenden Hook hab ich nicht gefunden) mitzubekommen wenn irgendeine beliebige Datei erstellt oder geöffnet wird? Außerdem würde mich (sofern das erste das nicht erschlägt) noch interessieren wenn etwas in der Registry oder anderen Systemeinstellungen geändert wird.
TDM Geschrieben 27. Februar 2006 Geschrieben 27. Februar 2006 Also ne Art FileWatcher ? C# geht das auf jedenfall, C++ ka ob das dann noch für die Registry geht, weis ich aber nicht Edit: Windows Service als Stichwort oder halt anderes
Guybrush Threepwood Geschrieben 27. Februar 2006 Autor Geschrieben 27. Februar 2006 Naja hab mittlerweile diesen interessanten Artikel gefunden, aber den muss ich erstmal zu Ende lesen
Bubble Geschrieben 27. Februar 2006 Geschrieben 27. Februar 2006 Gibt es eine Möglichkeit (einen entsprechenden Hook hab ich nicht gefunden) mitzubekommen wenn irgendeine beliebige Datei erstellt oder geöffnet wird? Ja, das geht. Für .NET basierte Anwendungen gibt es die FileSystemWatcher Klasse. Ohne .NET ist es aufwendiger, geht aber mittels Event Tracing (siehe Platform SDK). Eine zu vermeidene Alternative währe das regelmässige Abfragen der Dateiattribute in einem extra Thread mittels Timer.
Guybrush Threepwood Geschrieben 27. Februar 2006 Autor Geschrieben 27. Februar 2006 Eine zu vermeidene Alternative währe das regelmässige Abfragen der Dateiattribute in einem extra Thread mittels Timer. Ja sowas in der Art wollte ich eher vermeiden, aber das andere schau ich mir mal an
Klotzkopp Geschrieben 27. Februar 2006 Geschrieben 27. Februar 2006 Für Dateiüberwachung kann man ReadDirectoryChangesW benutzen. Für die Registry bleibt wohl wirklich nur API-Hooking. Also ne Art FileWatcher ? Äh, das ist IMHO nur ein Beispiel für die Anwendung von COM.
Guybrush Threepwood Geschrieben 27. Februar 2006 Autor Geschrieben 27. Februar 2006 Also das mit dem Event Tracing sieht auf den ersten Blick vielversprechend aus. Eine Änderung in der Registry müsste theoretisch ja auch auf eine Dateioperation zurücklaufen. Beim API-Hooking scheint keine der User Level Hooking Möglichkeiten wirklich toll zu sein und beim Kernel Level Hooking weiß ich nicht ob das nicht etwas zu überdimensioniert für mich ist Ziel des ganzen ist es übrigens eine Übersicht zu bekommen was so alles im System genau passiert ist, um bei evtl. Trojanerbefall (den ich in den letzten 3 Wochen 2 mal hatte >( ) genau zurückzuverfolgen was der verstellt und wo er sich eingenistet hat...
Klotzkopp Geschrieben 27. Februar 2006 Geschrieben 27. Februar 2006 Dann empfehle ich Filemon und Regmon von Sysinternals. Kein Grund, das selbst nochmal zu schreiben, außer vielleicht als Übung.
Guybrush Threepwood Geschrieben 27. Februar 2006 Autor Geschrieben 27. Februar 2006 ...außer vielleicht als Übung. Genau Aber die Tools sehen ganz vernünftig aus. Danke
Guybrush Threepwood Geschrieben 27. Februar 2006 Autor Geschrieben 27. Februar 2006 Ohje hab die beiden Tools mal ausprobiert und hab auch viele Operationen erwartet, aber nicht das ich binnen 2 Minuten 100.000 Registry und 50.000 Datei Operationen habe :eek
Guybrush Threepwood Geschrieben 2. März 2006 Autor Geschrieben 2. März 2006 Hab da mal ne Frage zum APIHooking bzw. zu dem Artikel den ich weiter oben verlinkt habe. Soweit ich das verstanden habe geht es bei den verschiedenen Möglichkeiten des API Hooking nur darum wie man andere Programme dazu bekommt seine DLL zu laden. Danach passiert immer das Selbe, nämlich das man in seiner DLL eigene Methoden der entsprechenden APIs exportiert und diese dem fremden Programm unterjubelt wenn es diese Mit LoadLibraray bzw. GetProcAdress lädt. Aber was ist denn mit den Programm die die APIs nicht dynamisch über GetProcAdress laden, sondern diese statisch verlinken? Die dürften davon doch dann alle nicht betroffen sein und das müssten ja der Großteil der Programme sein die es so machen (Zumindest bei den C Programmen)...
Klotzkopp Geschrieben 2. März 2006 Geschrieben 2. März 2006 Ich glaube, du verwechselst da static linking mit load-time dynamic linking. Wenn du dein Programm z.B. mit user32.lib verlinkst, bist du damit nicht unabhängig von user32.dll. Kann ja schon gar nicht sein, weil user32.lib signifikant kleiner als user32.dll ist. Das, was du da statisch linkst, sind Importbibliotheken. Die sorgen dafür, dass die entsprechenden DLLs beim Start des Programms geladen werden. Wirklich statisch linken kannst du nur gegen die Bibliotheken, die auch als komplette statische Bibliotheken ausgeliefert werden, z.B. die C-Runtime und die MFC.
Guybrush Threepwood Geschrieben 2. März 2006 Autor Geschrieben 2. März 2006 Achso d.h. es findet trotzdem ein aufruf von LoadLibrary und GetProcAdress statt, nur das es automatisch beim Starten des Programms passiert?
Klotzkopp Geschrieben 2. März 2006 Geschrieben 2. März 2006 Es findet etwas statt, was sich wie LoadLibrary/GetProcAddress auswirkt. Diese Funktionen selbst können dazu nicht benutzt werden, denn sie liegen in Kernel32.dll - ein Henne-Ei-Problem
Guybrush Threepwood Geschrieben 2. März 2006 Autor Geschrieben 2. März 2006 Dann wäre aber doch wieder das Problem wenn ich LoadLibary bzw GetProcAdress überlade um stattdessen einen Zeiger auf meine Funktion zu liefern, diese Programme GetProcAdress gar nicht aufrufen...
Guybrush Threepwood Geschrieben 2. März 2006 Autor Geschrieben 2. März 2006 Kommt drauf an was man vorhat und es ist ein interessantes Thema Ich könnte so ja zum Beispiel RegSetValueEx überladen um zu protokolieren was geschrieben wird und dann das ganz normale RegSetValueEx aufrufen...
Bubble Geschrieben 2. März 2006 Geschrieben 2. März 2006 Und Du könntest noch viele andere Dinge tun... Und Du solltest damit rechnen, dass gute Virenscanner Dein Programm entsprechend behandeln...
Guybrush Threepwood Geschrieben 3. März 2006 Autor Geschrieben 3. März 2006 Und Du könntest noch viele andere Dinge tun... Das könnte ich mit nem normalen Hook auch oder mit strcpy usw Mit dem Virenscanner wäre ja auch kein Problem, aber darum geht es ja auch gar nicht.
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde Dich hier an.
Jetzt anmelden