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:

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
2
  • 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, 2023 at 1: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, 2023 at 1: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.

Improve this answer
6
  • 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 3, 2014 at 0: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 3, 2014 at 0: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 3, 2014 at 13:04
  • 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\<executable>" on 64bit systems. This is used if the process calling CreateProcess is 32bit. blogs.msdn.com/b/mithuns/archive/2010/03/24/…
    – David Marshall
    Jul 3, 2014 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 3, 2014 at 17:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .