3

Image Execution Options (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options) with a key named after the executable and a string (REG_SZ) value is known to be a nice inroute if you need to modify the behavior of an application to be launched.

However, if I have a very common name for an executable, such as launcher.exe, how can I be a bit more specific? Can I at all?

I'd like to make sure that only the particular binary I have in mind will be affected, although in my particular use case it's only a moderate impact if I cannot limit it to the exact executable.

I would like to write myself a little wrapper program that, similar to Process Explorer from Sysinternals, replaces the standard behavior for my specific launcher.exe in that it sets the environment variable similar to set __COMPAT_LAYER=RUNASINVOKER in a shell.

Now I know how to write the wrapper and all, the main question is, whether there is a way to tell in the registry, using some magic underneath Image Execution Options, to limit the scope of the Debugger value "hack" or would I have to filter this in my wrapper?

Relates to:

Community
  • 1
0xC0000022L
  • 6,819
  • 10
  • 50
  • 82

2 Answers2

6

Starting with Windows 7, there is a way to limit Image File Execution Options to exact path.

  1. Create a dword with name "UseFilter" and nonzero value under ...\Image File Execution Options\filename.exe.
  2. Create a subkey with arbitrary name, e.g. ...\Image File Execution Options\filename.exe\MyFilter.
  3. Under that subkey, create a string with name "FilterFullPath" and full path as a value, e.g. "C:\mypath\filename.exe". Also, create whatever options you need, "Debugger" in your case, there.

Now, when the system starts any "filename.exe", it checks whether the full path matches "FilterFullPath" from any subkey. (There can be several subkeys for different paths.) If there is a match, options from the matched subkey are used. Otherwise, options from base key IFEO\filename.exe are used, as usual.

E. Grechnikov
  • 76
  • 1
  • 3
  • pay attention here, the full path to the exe in FilterFullPath should be equal to the exe path we want to filter, it should not have double quotes even when the path have spaces, this made me crazy for hours looking for why it does not work in win 7. – Badr Elmers May 30 '23 at 01:33
  • ex: `reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\name.exe" /v UseFilter /t "REG_DWORD" /d 1 /f` _____ `reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\name.exe\0" /v FilterFullPath /t "REG_SZ" /d "path with or without space\name.exe" /f` _____ `reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\name.exe\0" /v Debugger /t "REG_SZ" /d "calc" /f` – Badr Elmers May 30 '23 at 01:38
0

It seems to be possible to do it like this

enter image description here

The screenshot shows to create subkeys corresponding to the full path of a binary underneath HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options, e.g.:

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

under which then a Debugger string value could be created and set.

0xC0000022L
  • 6,819
  • 10
  • 50
  • 82
David Marshall
  • 7,200
  • 4
  • 28
  • 32
  • Did you test this or are you merely assuming it works? I mean I realize this is how you can *create* the key and value, but it appears that the loader doesn't actually honor this *at all*. What system have you tried this one? If you rename the "top-level" key `AcroRd32.exe` (directly under `Image Execution Options`) to `AcroRd32.exe__` (`F2`) and leave the one with the full path in place with a `Debugger` such as `procexp.exe`, does that work? – 0xC0000022L Jul 03 '14 at 00:18
  • Unfortunately, even after creating the key using a `.reg` file instead of manual creation to ensure that I have no typo in the path, it simply won't work. I know this because if I use the name `launcher.exe` instead of the full path, the behavior is as expected and the launched program doesn't require elevation anymore. I'm sorry if this wasn't clear from the question, but I was not merely asking whether it's theoretically possible to create the key, but to create the key and get the expected behavior. – 0xC0000022L Jul 03 '14 at 00:24
  • @0xC0000022L Sorry for the delay. I went to bed after posting. I've not tested this with the debugger key. I just noticed it when looking at that area of the Registry. I suspect it was created by EMET which may be using it for its own purposes and it doesn't work for attaching a debugger. – David Marshall Jul 03 '14 at 13:04
  • good point. I noticed you had a few EMET entries there as well. – 0xC0000022L Jul 03 '14 at 14:37
  • 1
    @0xC0000022L I checked another system without EMET. Those entries don't exist. I also found there is a 32bit version of the key in "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\" on 64bit systems. This is used if the process calling CreateProcess is 32bit. http://blogs.msdn.com/b/mithuns/archive/2010/03/24/image-file-execution-options-ifeo.aspx – David Marshall Jul 03 '14 at 16:13
  • 2
    that's the same key actually. The registry allows links between keys and that's what's going on there it seems. No Win32 tool or API handles registry links IIRC. You can see it by going to the alleged "native" (64bit) version and creating something unique, like a value `64bit`, and then navigating to the one under `Wow6432Node` and finding it there. This is at least true in Windows 7 SP1, x64. – 0xC0000022L Jul 03 '14 at 17:51