locked
How to use the debugger reg key to create a launcher ? RRS feed

  • Question

  • Hello,

    I am trying to find a way to run a launcher script (batch or vbs) that would run instead of the called program, would perform some actions, and then launch the said program. I plan on doing this through the use of the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\currentversion\image file execution options\ManagedExe.exe, with the Debugger value defined as the launcher script.

    The problem is that when the script calls the program, the script is run again because the key is still there saying to call the script. That would start an endless loop.

    I found 2 ways to get around this, but I dislike them both :

    1. At the start of the script, remove the debugger key, perform the actions, call the program, then reset the key. But that means the user could run the program directly during that time.

    2. Copy and rename the program to %temp% and run it from there. But this is not very clean.

    I think there is yet another way, through the use of WMI CreateProcess with the DEBUG_PROCESS option. But I don't quite understand how this works. It is mentioned here with not many details.

    Could some one help me with this please ?

    Thanks

    Monday, December 23, 2013 4:38 PM

Answers

  • The reason I need to go through this process is that I have to "catch" the execution of some programs and run some commands before letting them run. And the reasons why I need to do this are out of the scope of a simple forum post, the global solution being far too complicated to explain.

    The XY problem means that you have problem X, and you think a solution might be Y, but instead of asking about X you keep asking about Y.

    In this case, you're declining to provide the necessary context for the real question (X), and you want to know how to solve X by using Y (debugger registry value). However since we don't anything about X, it is not possible to tell you how to solve it since you only want to know about Y.

    From the little bit of information you have provided, it is likely that Y wasn't designed to solve X anyway, and attempting to force-fit the solution will probably not work very well.

    In the long run it is probably better to define X more specifically and then architect an appropriate solution for it, but that's not really the purpose of this forum.

    Bill


    • Edited by Bill_Stewart Tuesday, December 24, 2013 7:54 PM Rewrite/clarification
    • Marked as answer by Bill_Stewart Monday, February 10, 2014 10:37 PM
    Tuesday, December 24, 2013 4:40 PM

All replies

  • What is the purpose? Tell what you need to accomplish, not how you think you need to do it. (Beware of the XY problem.)

    Bill

    • Proposed as answer by jrv Tuesday, December 24, 2013 3:14 PM
    Monday, December 23, 2013 5:03 PM
  • Well, I said so, even if not clearly enough... ;)

    I need the script that is defined in the registry in the debugger value to be able to run the ManagedEXE defined the the registry key.

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\currentversion\image file execution options\ManagedExe.exe\Debugger = MyScript.vbs

    But if MyScript.vbs runs ManagedExe.exe, the key is read again, and MyScript.vbs is run a second time, then a third, etc.

    If I understand well, there is a way to bypass this system when running a process, and that's what I'd need to help with. Though if someone finds some other way to get around this, I'd be happy to read about it.

    The reason I need to go through this process is that I have to "catch" the execution of some programs and run some commands before letting them run. And the reasons why I need to do this are out of the scope of a simple forum post, the global solution being far too complicated to explain.

    Tuesday, December 24, 2013 8:00 AM
  • This is a chicken and egg question. It has no answer.

    You need to contact the inventor of the program you are trying to manage.  They will help you.

    http://msdn.microsoft.com/en-us/library/a329t4ed(vs.71).aspx

    The key you are trying to use was designed to launch a debugger wich would check to see the process that launched it.  THe debugger can run at a system level and "hook" the API for the program so it can be debugged.  While the key will try and launch any program or association it is up to the program to understand that it is being launched in advance of the real program.  It cannot re-launch the debugee.  It must hook the launched program and run or terminate.

    You script needs to know that if it cannot hook the process it is running under then it must terminate.  It may actually work the other way but the effect would be the same.  If you take control of the program you must run it as a debugee.  You cannot just launch it.

    Chicken/Egg.  Egg/Chicken.  As Bill noted, it is an X<=>Y problem.  No solution possible.


    ¯\_(ツ)_/¯

    Tuesday, December 24, 2013 3:14 PM
  • Note that this thread has an X<=>Y answer.  This is because the XY issue that Bill referenced is a byproduct of the effect of the solution you are trying to design.  Your solution leads you to asking the wrong question.  Your question is a solution stated as a question and the issue is left unresolvable.

    Try going back to what caused you to seek a solution in the first place.  What happened before you decided to register a script on the debug key for managed code?

    If you are just trying to figure out how to bypass managed code then forget it.  It cannot be done with script.   It can only be done with a debugger registered to the system and only by a user with Admin/Debug permissions. (SeDebug Permission).

    The key was not designed to be used to launch unmanaged code.  VBScript/WScript is unmanaged code.


    ¯\_(ツ)_/¯


    • Edited by jrv Tuesday, December 24, 2013 3:22 PM
    Tuesday, December 24, 2013 3:15 PM
  • if WScripts.Arguments(0) = "managedexe.exe" Then
        ' script was lunched from key
    Else
        ' script was launched directly
    End If


    ¯\_(ツ)_/¯

    Tuesday, December 24, 2013 4:00 PM
  • The reason I need to go through this process is that I have to "catch" the execution of some programs and run some commands before letting them run. And the reasons why I need to do this are out of the scope of a simple forum post, the global solution being far too complicated to explain.

    The XY problem means that you have problem X, and you think a solution might be Y, but instead of asking about X you keep asking about Y.

    In this case, you're declining to provide the necessary context for the real question (X), and you want to know how to solve X by using Y (debugger registry value). However since we don't anything about X, it is not possible to tell you how to solve it since you only want to know about Y.

    From the little bit of information you have provided, it is likely that Y wasn't designed to solve X anyway, and attempting to force-fit the solution will probably not work very well.

    In the long run it is probably better to define X more specifically and then architect an appropriate solution for it, but that's not really the purpose of this forum.

    Bill


    • Edited by Bill_Stewart Tuesday, December 24, 2013 7:54 PM Rewrite/clarification
    • Marked as answer by Bill_Stewart Monday, February 10, 2014 10:37 PM
    Tuesday, December 24, 2013 4:40 PM