Running debugger with a path containing spaces supplied as a command line argument

[mxtsdev]

Hello,

I'm attempting to run the debugger (IN-VM dbgeng) on a target with an input file supplied in the command line arguments. The file path contains spaces, and I can't seem to find any working method to escape it.

Does Ghidra not support this?

[mxtsdev]

I'm also unable to get Ghidra to start the target with a different working directory, which is required for the application to run.

The potential solution I found on this link to launch Ghidra from the desired working directory is not working.
#4732 (comment)

[d-millar]

@mxtsdev There are probably a number of ways to approach each of your issues. For instance, if you don't need to debug the target from start-up, you can start the target as you normally would with the appropriate arguments and starting directory, and then attach to the running process. Assuming that doesn't work for you, try the following:

(1) In the Target window, start dbgeng.
(2) In Objects, use the Launch (x) button to open a command line dialog.
(3) From that dialog, you should be able to specify a complete path (including spaces). For example, I just tried C:\Program Files\Putty\putty.exe and that worked.
(4) You should also be able to enter arguments there. For example, C:\Windows\notepad.exe junk.txt starts notepad with junk.txt as an argument.
(5) Combining (3) and (4) should also work. For example, C:\Program Files\Putty\putty.exe -h launches putty but spawns an "Unknown option -h" warning.
(6) All of the above examples use the default launch connector. To set the initial directory, open the Connectors node in the Objects tree. Select the Launch connector and the hit the Launch (X) button. You should see more options, one of which is "dir". I have had mixed success with this, however, as it depends a lot on the target. For example, you'd think specifying "dir" for notepad.exe would dictate where it started the File browser when you hit "Open", but that, for better or worse, is not how notepad works.

WIll caveat all this with a note that some of these things have only recently been fixed. I tested them in our main branch and am pretty sure all of the above works in 10.3.2, but for older versions your mileage may vary.

[mxtsdev]

Thank you for your prompt response. Unfortunately, although I was unaware of the initial directory setting of the Connectors node in the Objects tree, I am still unable to get both the current working directory and the command line argument with spaces to function correctly.

I'm using the latest precompiled Ghidra release (10.3.3).

3. Works.
4. Works only if the path provided as a command line argument does not contain spaces, as shown in the provided example C:\Windows\notepad.exe junk.txt. If the path in the command line argument is an absolute path with spaces in it, all double-quotes are stripped, and the target application will see it as multiple arguments rather than one path.

For example "C:\Program Files\Application 1\application1.exe" "c:\Project 1\junk.txt" -h shows up in Process Monitor as "C:\Program Files\Application 1\application 1.exe" c:Project 1junk.txt -h.

Below is a small subset of all the different paths that I have tried. None of them work:

C:\Program Files\Application 1\application1.exe "c:\Project 1\junk.txt" -h
"C:\Program Files\Application 1\application1.exe" "c:\Project 1\junk.txt" -h
"C:\Program Files\Application 1\application1.exe" \"c:\\Project 1\\junk.txt\" -h
"C:\Program Files\Application 1\application1.exe" \\"c:\\Project 1\\junk.txt\\" -h
"C:\Program Files\Application 1\application1.exe" \\"c:\\Project 1\\junk.txt\\" -h
"C:\Program Files\Application 1\application1.exe" "/c:/Project 1/junk.txt" -h
"/C:/Program Files/Application 1/application1.exe" "c:/Project 1/junk.txt" -h
"/C:/Program Files/Application 1/application1.exe" "/c:/Project 1/junk.txt" -h
"/C:/Program Files/Application 1/application1.exe" \"c:/Project 1/junk.txt\" -h
"/C:/Program Files/Application 1/application1.exe" \\"c:/Project 1/junk.txt\\" -h

5. Same as (4), it only works if the path provided as a command line argument to the target does not contain spaces.

6. The initial directory setting of the Connectors node in the Objects tree does not appear to set current working directory (CWD). If I set it to a different directory (for example c:\Temp) and inspect the launched target process with a tool like tlist from Windows Debugging Tools the output is as follows:

(base) PS C:\Temp> & 'tlist.exe' 53280
53280 application1.exe
   CWD:     C:\Dev\ghidra_10.3.3_PUBLIC\
   CmdLine: "C:\Program Files\Application 1\application1.exe" c:\Project 1\junk.txt -log
   PackageFamily:
   VirtualSize:    20116 KB   PeakVirtualSize:    20116 KB
   WorkingSetSize:  2124 KB   PeakWorkingSetSize:  2124 KB
   NumberOfThreads: 1
   57636 Win32StartAddr:0x00000000 LastErr:0x00000000 State:Waiting

As seen above, the current working directory (CWD) remains set to C:\Dev\ghidra_10.3.3_PUBLIC\, which is the root directory of my Ghidra installation. Additionally, the dir setting on the Connectors node is reset to an empty path with each run, and I am unable to inspect the value before running. This is because setting it is part of the Launch (X) action, and as a result, I can't tell if it applies or not.

[d-millar]

I will spend a bit more time on this later today, but one quick note: I forgot when I comment in GitHub that double backslashes are converted to single slashes. The same is true in Java, i.e. my example should be C:\\Program Files, etc.

[mxtsdev]

Thank you! I appreciate the help. Please note that the issue with command line arguments containing spaces is primarily just an inconvenience and not as crucial as the other issue with the current working directory (CWD). The application will not execute correctly with the wrong CWD set (and I imagine it is important for many applications). Meanwhile, input files can always be moved if I had known it wasn't going to work as expected.

[d-millar]

OK, verified what I should have remembered - 10.3.3 is broken with regard to the Launch Process connector. There may be a workaround - am looking into that - but the bug was pointed out recently and the fix did not make 10.3.3. The bug has been fixed in the main branch. Not sure how ambitious you're feeling, but can definitely help walk you through the build process if you're interested and/or need help.

In the main build (and, I believe, the next release), setting the working directory using "dir" works. For example, if I run "C:\\Windows\\System32\\cmd.exe with dir: C:\\Tmp, the cmd shell opens at C:\Tmp and tlist.exe gives the correct version for CWD. That said, am pretty sure there is another use case where the working directory is not the relevant variable and you have to do something like env: cd=C:\\Tmp or similar. Again, you'll probably have to verify this for your specific use case.

That may also provide a workaround for the path for the arguments as, given a relative (and possibly dotted) path, I believe it will prepend the working directory, which can have spaces in it. Interestingly, having gone through the code again, it appears the problem with spaces in the arguments is actually a limitation of the Windows dbgeng API. Specifically, the command line gets passed pretty much as is by Ghidra into IDebugClient::CreateProcessAndAttach2's CommandLine parameter. So not sure what to do about that....

[mxtsdev]

Thanks! I will build the main branch if the issue is resolved there :)

I could successfully run the same arguments that I am trying to use in Ghidra when I tested the dbgeng API just now. I cloned Microsoft.Diagnostics.Runtime and changed some of the sample code for a quick test. As far as I can tell it uses IDebugClient5 and CreateProcessAndAttach2Wide (see IDebugClientWrapper.cs#L20 and DbgEngWrapper.cs#L13).

This was my test:
Create a new .NET 6 console project in Microsoft.Diagnostics.Runtime.sln, copy clrmd-main\src\TestTasks\src\Debugger.cs into the project and add the code below:

using Microsoft.Diagnostics.Runtime.Tests.Tasks;
using Microsoft.Diagnostics.Runtime.Utilities.DbgEng;

internal class Program
{
    private static void Main(string[] args)
    {
        var info = new DebuggerStartInfo();

        using Debugger debugger = info.LaunchProcess(@"""C:\Program Files\Application 1\application1.exe"" ""c:\Project 1\junk.txt"" -log", @"C:\Temp");
        DEBUG_STATUS status;
        do
        {
            status = debugger.ProcessEvents(TimeSpan.MaxValue);
        } while (status != DEBUG_STATUS.NO_DEBUGGEE);
    }
}

Code was pulled from Dump.cs#L37.

[d-millar]

I stand corrected - and, thanks, that example was extremely helpful. The issue (as you actually suggested early on) was that the logic leading to the dbgeng API call was stripping quotes, which are definitely necessary for the call to operate correctly. Will let you know when it makes its way into master. You'll still have to build master, as it'll be a while before it hits the release, but should solve both of your issues, not to mention other folks'. Much appreciated!