Ist es möglich, den vollständigen Pfad zu einer ausführbaren Datei in "Image Execution Options \ * \ Debugger" anzugeben?

1514
0xC0000022L

Image Execution Options( HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options) mit einem Schlüssel, der nach der ausführbaren Datei benannt ist, und einem string ( REG_SZ) - Wert ist bekanntlich eine gute Route, wenn Sie das Verhalten einer zu startenden Anwendung ändern müssen.

Wenn ich jedoch einen sehr gebräuchlichen Namen für eine ausführbare Datei habe launcher.exe, wie kann ich etwas genauer sein? Kann ich überhaupt

Ich möchte sicherstellen, dass nur die Binärdateien, die ich mir vorstelle, betroffen sein werden, obwohl dies in meinem speziellen Anwendungsfall nur eine moderate Auswirkung ist, wenn ich es nicht auf die exakte ausführbare Datei beschränken kann.

Ich möchte mir ein kleines Wrapper-Programm schreiben, das, ähnlich wie Process Explorer von Sysinternals, das Standardverhalten für mein spezifisches ersetzt, launcher.exeindem es die Umgebungsvariable ähnlich wie set __COMPAT_LAYER=RUNASINVOKERin einer Shell setzt.

Jetzt weiß ich, wie man den Wrapper schreibt, und alles ist die Hauptfrage, ob es in der Registry einen Weg gibt, etwas Magie darunter zu verwenden Image Execution Options, um den Umfang des DebuggerWertes "Hack" einzuschränken, oder müsste ich dies filtern mein Wrapper?


Bezieht sich auf:

1

2 Antworten auf die Frage

3
E. Grechnikov

Ab Windows 7 gibt es eine Möglichkeit, die Image File-Ausführungsoptionen auf den genauen Pfad zu beschränken.

  1. Erstellen Sie ein Dword mit dem Namen "UseFilter" und einem Wert ungleich Null unter ... \ Image File Execution Options \ Dateiname.exe.
  2. Erstellen Sie einen Unterschlüssel mit einem beliebigen Namen, z. B. ... \ Image File Execution Options \ Dateiname.exe \ MyFilter.
  3. Erstellen Sie unter diesem Unterschlüssel eine Zeichenfolge mit dem Namen "FilterFullPath" und dem vollständigen Pfad als Wert, z. B. "C: \ meinPfad \ Dateiname.exe". Erstellen Sie dort auch die gewünschten Optionen, "Debugger" in Ihrem Fall.

Wenn das System jetzt "filename.exe" startet, wird geprüft, ob der vollständige Pfad mit "FilterFullPath" in einem beliebigen Unterschlüssel übereinstimmt. (Es können mehrere Unterschlüssel für verschiedene Pfade vorhanden sein.) Wenn es eine Übereinstimmung gibt, werden die Optionen des übereinstimmenden Unterschlüssels verwendet. Andernfalls werden wie üblich Optionen des Basisschlüssels IFEO \ filename.exe verwendet.

0
David Marshall

Es scheint möglich zu sein, es so zu machen

Der Screenshot zeigt, wie Sie Unterschlüssel erstellen, die dem vollständigen Pfad einer darunter liegenden Binärdatei entsprechen HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options, z. B .:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\C:\Program Files\Adobe\Reader 11.0\Reader\AcroRd32.exe 

unter denen dann ein DebuggerStringwert erstellt und gesetzt werden kann.

Haben Sie dies getestet oder gehen Sie nur davon aus, dass es funktioniert? Ich meine, ich weiß, auf diese Weise können Sie den Schlüssel und den Wert * erstellen *, aber es scheint, dass der Lader dies überhaupt nicht * ehrt. Welches System haben Sie dieses probiert? Wenn Sie den "obersten" Schlüssel "AcroRd32.exe" (direkt unter "Bildausführungsoptionen") in "AcroRd32.exe__" ("F2") umbenennen und den vollständigen Pfad mit einem Debugger belassen wie `procexp.exe`, funktioniert das? 0xC0000022L vor 10 Jahren 0
Selbst wenn der Schlüssel mit einer `.reg`-Datei erstellt wurde, anstatt manuell zu erstellen, um sicherzustellen, dass der Pfad keinen Tippfehler enthält, funktioniert er leider nicht. Ich weiß das, weil, wenn ich den Namen "launcher.exe" anstelle des vollständigen Pfads verwende, das Verhalten wie erwartet ist und das gestartete Programm keine Erhöhung mehr erfordert. Es tut mir leid, wenn dies aus der Frage nicht klar wurde, aber ich habe nicht nur gefragt, ob es theoretisch möglich ist, den Schlüssel zu erstellen, sondern den Schlüssel zu erstellen und das erwartete Verhalten zu erhalten. 0xC0000022L vor 10 Jahren 0
@ 0xC0000022L Entschuldigung für die Verzögerung. Ich ging nach dem Posten ins Bett. Ich habe dies nicht mit dem Debugger-Schlüssel getestet. Ich habe es gerade bemerkt, als ich diesen Bereich der Registry betrachtete. Ich vermute, es wurde von EMET erstellt, das es möglicherweise für seine eigenen Zwecke verwendet und es funktioniert nicht, wenn ein Debugger angehängt wird. David Marshall vor 10 Jahren 0
guter Punkt. Ich habe bemerkt, dass Sie dort auch ein paar EMET-Einträge hatten. 0xC0000022L vor 10 Jahren 0
@ 0xC0000022L Ich habe ein anderes System ohne EMET geprüft. Diese Einträge existieren nicht. Ich fand auch, dass es eine 32-Bit-Version des Schlüssels in "HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ Windows NT \ CurrentVersion \ Image File-Ausführungsoptionen \ gibt."auf 64-Bit-Systemen. Wird verwendet, wenn der Prozess, der CreateProcess aufruft, 32-Bit ist. http://blogs.msdn.com/b/mithuns/archive/2010/03/24/image-file-execution-options-ifeo.aspx David Marshall vor 10 Jahren 0
das ist eigentlich derselbe Schlüssel. Die Registry erlaubt Verknüpfungen zwischen Schlüsseln, und so scheint es. Kein Win32-Tool oder keine API verarbeitet Registrierungsverknüpfungen IIRC. Sie können es sehen, indem Sie zur angeblichen "nativen" (64-Bit) -Version gehen und etwas Einzigartiges erstellen, beispielsweise einen Wert von "64-Bit", und dann zu der unter "Wow6432Node" navigieren und sie dort finden. Dies gilt zumindest für Windows 7 SP1, x64. 0xC0000022L vor 10 Jahren 0