Hallo

Für ein Projekt muss ich bestimmte Teile von bestimmten Dateien über das Netzwerk lesen. Da jeder Zugriff mit einem Netzwerkzugriff verbunden ist, wollte ich das optimieren, in dem ich einen lokalen Zwischenspeicher dazwischen schalte. Bereits gelesene Teile würde ich dann auf der lokalen Festplatte speichern. Beim erneuten Lesen wäre dann kein Netzwerkzugriff mehr nötig.

Nur ist es leider so, dass der Lesevorgang extern über eine ActiveX Komponente passiert (z.B. third party codec), d.h. ich kann den Code dort nicht umschreiben.

Ich suche nach einer Möglichkeit eine "virtuelle Datei" auf irgend eine Art und Weise zu erzeugen, bei der ich jeden Lese-/Schreibbefehl selbst implementieren kann.

Gibt's hier irgend welche Möglichkeiten, ausser die WinAPI zu hooken? Vielleicht so was wie eine Named Pipe, jedoch sollte man auch Seeken (Lese/Schreibeposition ändern) können. Eine andere Möglichkeit wäre wohl ein Wechsellaufwerk zu simulieren, das klingt für mich aber nach sehr viel Aufwand (es sei denn es gibt da fertige Komponenten). Oder vielleicht kann man eine eigene URL z.B. myprotocol:// definieren und die Leseoperation selbst implementieren?

Hat jemand eine Idee was es da für Möglichkeiten gibt?

Im Grunde hast Du eigentlich schon alle praktikablen Möglichkeiten abgedeckt.

Man könnte unter Umständen aber auch in dem ActiveX-Control bestimmte Operationen hooken, das wäre aber gegenüber dem API-Hook doch um einiges aufwändiger.

Da der Hook bei Dir u.U. sogar im gleichen Prozess abläuft, brauchst Du dazu noch nicht mal eine DLL, wodurch das ganze noch mal einfacher wird.

Bliebe also die Frage, warum Hooks hier vermieden werden sollten, gegenüber anderen, teilweise wesentlich umfangreicheren und unzuverlässigeren Methoden.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Es sollte eigentlich alles im gleichen Prozess laufen inkl. die ActiveX Komponente, wenn die nicht etwas Exotisches macht. Dann werde ich mal einen Hook schreiben. Da das Programm sich selbst hookt (zwar für eine DLL) sollte es ja auch keine Schwierigkeiten mit Vista und Virenscanner geben (?).

Die meisten Virenscanner schlagen nur bei CreateRemoteProcess bzw. anderen Remote-Injections an. das eigentliche Hooken wüsste ich jetzt aus'm Kopf nicht, wird aber meist nicht explizit behandelt, da man für wirksame Inter-Prozess-Hooks meist noch andere Dinge tun muss, die einfacher zu finden sind.

Worauf du achten müsstest, ist die Vergabe von entsprechenden Schreibrechten auf das Code-Segment der zu hookenden DLL (also da, wo die gehookte Funktion umgeleitet wird).

Würde hier einen IAT (Import Address Table) Hook empfehlen, die sind einfach realisierbar und relativ fehlerunanfällig. Benötigte Funktionen für File-IO sind CreateFileW (A ruft intern einfach nur W auf), FileSeek, Read, Write und CloseHandle). Ggf. weitere, sollten aber glaube alle sein.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Wenn ich mich kurz einmischen dürfte... das sieht mir nach einem guten Tutorial-Thema aus

Anders gesagt: die Lösung würde mich interessieren... hatte ich auch mal gesucht sowas.

Hab's probiert geht grundsätzlich, aber in meinem Fall (ActiveX) scheint es nicht zu klappen. Komischerweise sehe ich relativ viele DLLs die geladen werden, also wird die Datei ziemlich sicher im gleichen Prozess geöffnet. Wenn ich die aber Hooke, wird weder CreateFileA nocht CreateFileW jemals aufgerufen.

hook mal NtCreateFile von der ntdll

Das geht mit Delphi normalerweise nicht...

Was heißt "normalerweise"?

Ich habe mal direkt SetFilePointer gehookt. Die wird zum File-Seeken verwendet, egal wie die Datei geöffnet wird. Leider geht da auch nichts.

Das gleiche Phänomen zeigt sich übrigens beim Abspielen von Dateien über den Delphi TMediaPlayer. Der funktioniert zwar über mci und nicht ActiveX aber es werden beim Abspielen ungefähr die gleichen DLLs (DSOUND.DLL, MSACM32.dll, Codecs) geladen.

j.klugmann hat folgendes geschrieben:

Was heißt "normalerweise"?

Man braucht für native-API-Hooks irgendson speziellen Krams, glaube ich...

Man kann nicht mal so eben im User-Mode Kernel-Funktionen hooken. Das ist keine Beschränkung der Delphi Language/Object Pascal, sondern liegt ganz einfach daran, dass man Delphi-Programme nicht im Ring 0 laufen lassen kann (gut, es gibt das DDDK, damit kann man Treiber schreiben, aber das ist mehr als experimentell).

EDIT: Ich sehe gerade, das stammt von uall@ogc. Dann irre ich mich.

Timosch hat folgendes geschrieben:

Man kann nicht mal so eben im User-Mode Kernel-Funktionen hooken. Das ist keine Beschränkung der Delphi Language/Object Pascal, sondern liegt ganz einfach daran, dass man Delphi-Programme nicht im Ring 0 laufen lassen kann (gut, es gibt das DDDK, damit kann man Treiber schreiben, aber das ist mehr als experimentell). EDIT: Ich sehe gerade, das stammt von uall@ogc. Dann irre ich mich.

Naja, der Meinung war ich bisher auch, aber das Hooken von Setwindowshookex klappt zumindest...

Man kann die Funktion zum Hooken hooken? Wow.

Ist das ActiveX wirklich ein InProc-Server, oder bringt der eventuell seinen eigenen Prozess mit? (eventuell wird die DLL auch später rübergemappt/relocated (nicht sicher welches von beiden, hoffe du verstehst worauf ich hinaus will...)

Anscheinend ist die Tatsache dass kein neuer Process z.b. im Process Explorer erscheint hier nicht maßgeblich.
Irgendwo hab ich sowas auch mal interessenhalber gemacht (bzw. Samples aus einem Buch implementiert). Wenn ich mich recht erinnere, hat der OutOfProc-Server so gar nicht das gemacht was ich erwartet hätte.

Nun ja, ich hab die Idee jetzt vorerst fallen gelassen.

Wie gesagt verhält sich der TMediaPlayer etwa ähnlich. Man kann damit Dateien abspielen, obwohl die Datei scheinbar nicht vom Prozess geöffnet wird. Die DLLs für eventuelle Codecs werden trotzdem im Prozess geladen und brauchen CPU und Memory Ressourcen.