Nun, ich bin vor Kurzem auf ein seltsames Problem gestoßen.
Immer wenn ich versuche, ProcessMonitor zu starten, wird stattdessen ein anderes irrelevantes Programm (tatsächlich eine IM-Software) gestartet.
Letztendlich kann ich ProcessMonitor nur starten, indem ich diese IM-Software deinstalliere. Ich habe ProcessMonitor auf den Computern meiner Kollegen ausprobiert, aber keiner von ihnen sieht die gleichen Dinge.
Habt ihr also eine Idee, wie man das lösen kann? Vielen Dank im Voraus.
Antwort1
Überprüfen Sie den folgenden Registrierungsschlüssel:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Der einfachste Weg, eine Programmausführung zu kapern, besteht darin, einen Unterschlüssel mit dem Namen exe zu erstellen.
\notepad.exe
und einer Zeichenfolge „Debugger“, die den EXE-Pfad als Wert verwendet, möchte der Hijacker Folgendes ausführen:
"debugger"="c:\windows\system32\cmd.exe"
Jetzt wird anstelle von Notepad cmd ausgeführt. Wahrscheinlich hat die gefälschte IM einen solchen Registrierungsschlüssel erstellt.
Übrigens, wenn der Hijacker einen gefälschten Debugger wie svchost verwendet, verbirgt Autoruns die Hijacking-Option standardmäßig, da es sich um eine von MS signierte EXE handelt.
Antwort2
Hatte das gleiche Problem mit einem Business-IM-Programm von Tencent RTX.
Gelöst durch Löschen einiger Reg-Einträge in der Typbibliothek. Versuchen Sie also einfach, einige verdächtige Reg-Einträge zu entfernen, die mit dem IM-Programm verknüpft sind.
@Mxx: Ich war überhaupt nicht vage. Der Schlüssel ist, die Typelibs/APIs, die auf die IM-Programm-Executives verweisen, aus dem Weg zu räumen. Aber er hätte jedes andere IM-Programm als meines verwenden können, und die Einträge sind möglicherweise nicht konsistent. Daher dachte ich, es hätte keinen Sinn, meine Einträge anzugeben. Der wesentliche Punkt hier ist, die Typelibs/APIs-Einträge zu finden, die auf die IM-Programm-Executives verweisen, und sie zu entfernen.
Da es sich, wie ich bereits erwähnte, um Typelib/Interface-Einträge handelt, befinden sie sich in ROOT/Typelib und ROOT/Interface. Die spezifischen Namen könnten IM-programmspezifisch sein. In meinem Fall befanden sie sich in Typelib unter {1512291F-F2F2-4E52-9F6A-5F0756F3B9CB} in ROOT/TypeLib, worauf durch die Typschnittstelle „IClientApi“ unter {561A4CFD-9878-4022-AD1E-499FDBB0D72F} in ROOT/Interface verwiesen wurde.
Es gibt jedoch keine Garantie dafür, dass er dasselbe IM-Programm wie ich verwendet hat (das ist RTX) oder dass sein IM-Programm dieselbe Typbibliothek/Schnittstelle verwendet hat, da es mir nicht gelungen ist, das Problem mit einem anderen IM-Programm zu reproduzieren. Übrigens kann das einfache Löschen dieser Einträge das Problem möglicherweise nur vorübergehend lösen, da das IM-Programm sie später wiederherstellen könnte, aber das liegt außerhalb des Rahmens dieser Frage.
Meine Antwort soll daher einen Zeiger auf die spezifische Lösung für das spezifische IM-Programm enthalten, das das Problem verursacht – damit er mit der Suche nach Einträgen in ROOT/TypeLib und/oder ROOT/Interface beginnen kann, die Verweise auf die Executives des spezifischen IM-Programms enthalten, das das Problem verursacht.