Virtuelles Laufwerk über DefineDosDevice und Hooks!

[FlorianK]

Hallo,
ich möchte ein virtuelles Laufwerk erzeugen. Ich habe hier auch schon gelesen, dass man dafür einen Treiber braucht. Meine Idee war jetzt, ich mache einen Ordner per DefineDosDevice zu einem Laufwerk. Dann hook ich alle Dateisystem Functions und überwache ob auf das Laufwerk zu gegriffen wird. Wenn das der Fall ist, kann ich anderen Programmen vorgauckeln, da wären Dateien/Verzeichnisse/usw. drauf. Zum Hooken wollte ich madCodeHook verwenden.

So meine 1. Frage: Macht das überhaupt Sinn? Oder gibt es einen besseren Weg? Oder wird das garnicht funktionieren?

Meine 2. Frage: Muss man dann eigentlich z.B. nur CreateFileEx oder auch CreateFile hooken? Und muss einen API-Hook oder einen Function-Hook machen?

Meine 3. Frage: Gibt es irgendwo eine Beschreibung, wie die API-Functions in Delphi "übersetzt" deklariert werden? (Ich komme nämlich mit LPSECURITY_ATTRIBUTES oder sowas nicht zurecht... )


Für alle Anregungen schon mal Danke

Florian K.

[w3seek]

Zitat von FlorianK:

So meine 1. Frage: Macht das überhaupt Sinn? Oder gibt es einen besseren Weg? Oder wird das garnicht funktionieren?

Ich gebe dir eine sehr sehr sehr sehr geringe Chance (eher gegen 0) dass es auch nur halbwegs funktionieren koennte.

Zitat von FlorianK:

Meine 2. Frage: Muss man dann eigentlich z.B. nur CreateFileEx oder auch CreateFile hooken? Und muss einen API-Hook oder einen Function-Hook machen?

Theoretisch muesstest du ausnahmslos alle Funktionen die das File-System hat hooken, allerdings inklusive der native apis (Nt*) die die ntdll.dll exportiert und natuerlich auch im kernel mode die der ntoskrnl.exe

Zitat von FlorianK:

Meine 3. Frage: Gibt es irgendwo eine Beschreibung, wie die API-Functions in Delphi "übersetzt" deklariert werden? (Ich komme nämlich mit LPSECURITY_ATTRIBUTES oder sowas nicht zurecht... )

Platform SDK

Du kommst um einen Treiber nicht herum - alles andere ist aeusserst unzuverlaessig und dringendst abzuraten da es das System aeusserst instabil machen kann (mal ganz abgesehen von den geschwindigkeitseinbussen). Ausserdem ist der Aufwand ein vielfaches hoeher als wenn man gleich schnell einen kleinen (virtuellen) device driver schreibt.

[FlorianK]

Zitat von w3seek:

Ich gebe dir eine sehr sehr sehr sehr geringe Chance (eher gegen 0) dass es auch nur halbwegs funktionieren koennte.

OK, Schade, aber wenn sich nichts machen lässt...

Zitat von w3seek:

Theoretisch muesstest du ausnahmslos alle Funktionen die das File-System hat hooken, allerdings inklusive der native apis (Nt*) die die ntdll.dll exportiert und natuerlich auch im kernel mode die der ntoskrnl.exe

Das hört sich SEHR VIEL an...

Zitat von w3seek:

Platform SDK

Danke so etwas habe ich schon gesucht.

Zitat von w3seek:

Du kommst um einen Treiber nicht herum - alles andere ist aeusserst unzuverlaessig und dringendst abzuraten da es das System aeusserst instabil machen kann (mal ganz abgesehen von den geschwindigkeitseinbussen). Ausserdem ist der Aufwand ein vielfaches hoeher als wenn man gleich schnell einen kleinen (virtuellen) device driver schreibt.

Wenn sonst nichts ist... Und was ist mit dem DDK? Das ist teuer!!!

Oder wie willst du sonst 'nen Treiber schreiben?


Florian K.

[c113plpbr]

Die SecurityAttributes sind doch schon nach delphi übersetzt worden, oder? Bei mir zumindest ...

Also, ich hatte diese Idee auch schonmal, aber hab das dann nicht weiter ausgeführt, da es sau viel arbeit ist, hinterher nicht unbedingt funktioniert, und dazu noch sehr langsam ist. Das sind meiner ansicht nach die hauptgründe davon die finger zu lassen.

Desweiteren wirst du mit der MadCodeHook-Lib da probleme bekommen. Da viele Rootkits dateien verstecken indem sie z.B. die NtQuerySystemInformation Funktion hooken (was du auch tun müsstest), hat madshi das hooken dieser funktion (und das nicht nur dieser funktion) in seiner lib untersagt. Wenn du es versuchst wirst du eine fehlermeldung bekommen.

Dann musst du dich warscheinlich noch mit nem riesigen haufen von funktionen rumschlagen, die sogut wie überhaupt nicht dokumentiert sind. Wenn du da mal einen fehler rein machst kommt es schnell zum Absturz.

Daher lege ich dir sehr die Treiber-Version davon nahe ... und das ddk kann man sich bestimmt irgendwo billig ersteigern (wenns auch etwas älter is, sollte das nicht allzuviel machen)
Dazu kommt noch, dass es da sogar beispiele dazu gibt: FileDisk
Ich persönlich kenne mich mit treibern aber überhaupt nicht aus, und kann daher nicht allzuviel über die schwierigkeit eines solchen treibers sagen, aber es ist garantiert interessant!

ciao, Philipp

[w3seek]

Das DDK kann man auch online kostenlos auf www.osr.com einsehen - zumindest die Dokumentation (ohne IFS wenn ich mich richtig erinnere) - zudem noch einige andere interessanten Informationen zur kernel mode bzw treiber programmierung.

[Mephistopheles]

1. Die Frage ist noch als offen markiert! Warum?
2. Das DDK gibt es gegen Versandkosten kostenlos bei MS, im Gegensatz zum IFSKIT ($900 oder so).

Bei OSR konnte man es mal einsehen. Ich glaube das geht nicht mehr.

[Olli]

Um meine Bemerkung fortzufuehren. Seit dem WDK ist das IFSK ja nun endlich integriert und damit quasi frei verfuegbar.