Image File Execution Options: Good, Evil, Fun.

I like the Image File Execution Options section of the registry. Many developers I've encountered aren't familiar with it, though. It's under-used, and that's a shame. (For some background on IFEO, check out http://blogs.msdn.com/junfeng/archive/2004/04/28/121871.aspx and http://blogs.msdn.com/greggm/archive/2005/02/21/377663.aspx.) So far, I've been able to use it for many things, including perhaps some things that it wasn't intended for. The most common value to set for a particular application is the "Debugger" REG_SZ value. This sets up another program to run as a debugger for the desired program. So, for example, if you set a "Debugger" value in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\calc.exe to something like "devenv /debugexe", VS.NET would open up (provided DevEnv.exe is in the path), ready for you to begin a debugging session for Windows' Calculator program.

Now, depending on how you look at it, this can be good or it can be bad. Windows doesn't verify that the "debugger" is truly a debugger - it just spawns the application in the debugger value. This means that you can put "notepad.exe" in the debugger value under calc.exe, and every time you try to run "calculator", notepad will run instead. Mark Russinovich and Bryce Cogswell use this technique to implement the "Replace Task Manager" feature of their AWESOME Process Explorer utility (check out http://www.sysinternals.com/ for a LOAD of Really Useful utilities as well as other great info). Get Process Explorer, enable the option in the "Options" menu, and check HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe - the debugger value points to procexp.exe.

I've used IFEO to halt multi-part viruses and malware that continuously spawn multiple programs, where each component is responsible for, among other things, keeping other components alive. If the executables are predictably named, you can set a debugger entry for that exectable to run a "singleton" application (like regedit.exe, which allows only one instance of itself to be run under most conditions). Then you can kill the process and watch regedit open up. Do the same thing for the other bad program, and you can go about cleaning the system. Of course, this doesn't help in cases where the malware is fully contained in DLLs, but that's beyond the scope of this.

The other side of the above is that before too long, if it's not happening already, the malware authors will use IFEO to run their own junk. They could set a debugger value in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Explorer.exe, and that process would launch and then spawn Explorer. Or it could spawn BadProgram2.exe, then Explorer.exe, and then exit. This would be difficult to trace for a few reasons, one of which is how unknown the IFEO section of the registry is. I see that the most recent version of Sysinternals' AutoRuns (also by Mark Russinovich and Bryce Cogswell) - version 8.11 as I write this - adds detection of "image file hijacks", which I take to mean the very idea presented above. This is a good thing, but I hope it was added to be PROactive rather than REactive.

Another way I've used the "debugger" value for an executable in IFEO is to debug processes that run on other desktops. Inetinfo.exe (IIS), DLLHOST.EXE (COM+ apps), W3Wp.exe (IIS 6 World Wide Web Worker Process), and a slew of other programs can be "debugged" this way, even on production systems. Let's face it - how many times does the customer let you install a debugger on their system? :) . Even if you could install a debugger on a customer's system, if you set the debugger value in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\W3Wp.exe to "devenv.exe /debugexe" and did something to kick off an instance of the World Wide Web Worker Process, VS.NET would start, but you probably wouldn't see it - the devenv.exe process would be running, but there would be no way to interact with it. Sometimes, you don't need to interactively debug the application to determine what the problem is. Enter Dependency Walker from http://www.dependencywalker.com/ . If you're able to get this relatively small (compared to debugger packages!) program on the system, just set up the debugger value of the desired process to something like:

"c:\path to\depends.exe" /c /pb /od:c:\temp\whatever.dwi

(run depends /? for a full description of available command line options)

This will cause Dependency Walker to be invoked when the desired process is to be started. "/c" tells Dependency Walker to run in "console mode", "/pb" tells it to profile the target application automatically, and "/od:" specifies that Dependency Walker should create a "DWI" (the native file format for Dependency Walker) file at c:\temp after the target application terminates. This is key - you need to wait for the application to terminate. So, for W3Wp.exe, you could unload the application from IIS Manager. At that point, the specified DWI file will be created, and it can be loaded into Dependency Walker (just run the program) via drag & drop, or File Open. You can control some of the information captured by using the other "/p?" options, or you can run Dependency Walker, profile a dummy app (like calc.exe) and select all of the options you want for the next round - the help for Dependency Walker's "/p?" options states that "If this option is not specified, then the setting from the last time you ran Dependency Walker will be used". At any rate, you can do this if you need more info. I've used this technique to launch Dependency Walker to profile an app to determine what DLLs were missing or unreachable (path-wise) by the target process, or if the wrong version of the DLL was being picked up by the target process, or why a process was crashing.

Anyone else use these (or similar) tools/utilities? Anyone else use Image File Execution Options? Anyone know specifically how to interpret the ApplicationGoo REG_BINARY value of an entry in Image File Execution Options? It's related to "Application Compatibility", but...