Keine schrecklich gute Frage, sorry.

Ich habe ein Programm, das benachrichtigt werden muss, wenn eine Datei über den Explorer geöffnet wird (d. H. ShellExecute (A / W) wird aufgerufen).

Leider hat Microsoft die COM-Schnittstelle (IShellExecuteHook) entfernt, mit der Sie diese Ereignisse in Vista und höher verknüpfen können, angeblich, weil älterer Code aufgrund von Änderungen einen Absturz verursachen kann. Es gab eine Problemumgehung, um diese Funktion wieder zu aktivieren, aber sie funktioniert nicht mehr.

Ich habe einige Nachforschungen angestellt und es sieht so aus, als ob die einzige Möglichkeit, Anrufe an ShellExecute abzufangen, darin besteht, den Anruf an shell32.dll umzuleiten. Momentan möchte ich meine eigene DLL in den Explorer-Prozess einbinden, dann den IAT-Eintrag für ShellExecute in eine Adresszuordnung in meiner DLL kopieren und schließlich den IAT-Eintrag für ShellExecute so ändern, dass er auf meine Funktion verweist, die benachrichtigt Das Programm, mit dem eine Datei geöffnet wurde, und der Sprung zur ursprünglichen ShellExecute-Funktion, deren Adresse wir zuvor gespeichert haben.

Mein größtes Anliegen sind hier Virenschutzprogramme. Interessiert es sie, dass ich in den Explorer spritze? Interessiert es sie, dass ich den IAT ändere?

Eine weitere Sorge ist, ob dies sicher ist. Ist es möglich (oder eher wahrscheinlich), dass die Sicherheitsrechte des Explorers keine Injektion über CreateRemoteThread zulassen? Wenn ja, gibt es eine bessere Möglichkeit, diese Injektion durchzuführen?

Gibt es einen besseren Weg, dies im Allgemeinen zu tun?

BEARBEITEN: Für alle, die dies in Zukunft bemerken, hat explorer.exe keine IAT für shell32.dll. Es hat einen Header, aber der Thunk ist voll mit Junk-Werten, so dass es (soweit ich das beurteilen kann) nicht möglich ist, den Eintrag für importierte Funktionen abzurufen.
Sieht aus wie Code-Tunneling ist die einzige Möglichkeit, dies zu verknüpfen.