Debugging over serial port

[astrelsky]

Just looking to find out if it is possible to do this with the Ghidra debugger. I remember looking into it in the past and was never able to figure out how to configure it on Ghidra's end. The use case here would be wanting to keep the Ghidra project on my workstation but safely run the program in a vm where I can restore state.

https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-DC282380-272B-426A-962D-D116E1B11F94.html

[d-millar]

@astrelsky Yes, this is entirely possible. Bear in mind, the Ghidra debugger is really a set of wrappers around native APIs for other debugging suites, such as windbg/dbgeng, gdb, lldb, etc., so most things that are possible with the native debugger are possible from Ghidra.

In your case, I wouldn't bother with setting up the pipes or serial debugging - I'm assuming you're primarily interested in user-mode vs kernel-mode debugging. The easiest way to implement this is install windbg in the VM, start or attach to your target, and then issue the .server command, e.g. .server tcp:port=54321.

In Ghidra, from the Targets View, launch dbgeng (or dbgmodel if you're using Windbg Preview in the VM) adding the arguments you would normally supply windbg's "-remote" option on the "DebugConnect options (.server)" line, e.g. "tcp:port=54321,server=ip.of.target.vm". This should connect to the VM, much as it would any remote target, with the current process being the one launched by the server windbg instance.

There are more complicated scenarios possible for kernel debugging, but they have some rough edges, so yell if that's what you're interested in.

[astrelsky]

I wouldn't bother with setting up the pipes or serial debugging

This is what I want to use though. The network adapters for my VMs are setup to use a virtual network and are "not connected" to the host workstation.

I'm assuming you're primarily interested in user-mode vs kernel-mode debugging.

This is the correct assumption. I have no interest in kernel-mode debugging.

[d-millar]

OK, I'm confused. Is your VM disconnected/isolated or is it "using a virtual network"? If it's using a virtual network, it's available using the virtual network IP for the VM. That said, if you're keen on using the pipe, that's fine. The params for using the pipe are "com:port=\.\pipe\namedpipe,pipe", as in the link you sent. Is that not working?

[astrelsky]

OK, I'm confused. Is your VM disconnected/isolated or is it "using a virtual network"? If it's using a virtual network, it's available using the virtual network IP for the VM. That said, if you're keen on using the pipe, that's fine. The params for using the pipe are "com:port=\.\pipe\namedpipe,pipe", as in the link you sent. Is that not working?

The reason for your confusion is probably my confusion (happens a lot). To try to put it as simply as possible (since I don't know what I'm talking about) the vm is configured in such a way that it can ping another vm but it cannot ping my workstation.

It was several months ago since I tried this. It might have just been operator error. I will try again tomorrow morning and see if I can get it working.

[astrelsky]

Trying to use "com:port=.\pipe\namedpipe,pipe" results in 'the remote command was not given the correct parameters." It doesn't work if I try to directly connect windbg to the named pipe either. Note that it doesn't work directly in windbg so it's definitely not a problem with Ghidra.

I can use putty and connect to the named pipe on the host and com port on the vm and it works fine.

When attempting the connection in Ghidra it continues to wait for a connection even though it has already failed. (DbgEngRuntimeException from DbgEngUtil.java:67)

Unfortunately I've spent way too much time trying and have to get back to work for now.

[d-millar]

LOL re bots. :) Am in the office till later this aft, where unfortunately I have no way to test this, but may be able to take a shot when I get home. Am interested in what's failing, so will try to reproduce your issue and, fingers crossed, pass on a solution. Definitely, a use case we're interested in.

[d-millar]

No problem - been there. I would try the IP approach first, just because the pipe setup is easy-to-break and not as performant. If it doesn't work right away, go with the pipe.

[astrelsky]

Bots are getting kind of scary 😂

[astrelsky]

Ha ha. Last time I heard of a runaway malware, it was the I-Love-You Virus back in the 1990s. Or early 2000s. So far, I think most of those bots are still controlled by an actor, whether bad or seemingly bad. Most of the system commands that are issued by those bots have to drill down to the machine level, and exact a payload within certain interrupts. So, for the most times, a person still needs to have access to a system. Like the lock and key analogy in another discussion thread.

Who is the actor controlling you?

[graps01]

For me, personally, it's the Lord. All others pay cash ;)

[d-millar]

@astrelsky OK, the more I think about this, the more I think this is the wrong approach....

Admittedly, it's been a long time since I've used the COM<->named pipe feature, but my recollection is that I always used it in the context of kernel debugging. Kernel debugging of windows over the serial port is the most basic and oldest flavor of kernel connection, and the whole point of the COM<->named port thing is to export the COM interface to clients outside the VM. The link you supplied, for instance, is clearly describing a kernel-debugging setup.

The COM is really not available (if I remember correctly) inside windbg for user-mode debugging. There's really no use case for that. Named pipe debugging is supported, but using npipe:pipe=\.\pipe\whatever makes that pipe available locally, i.e. I can connect from another windbg on the same box, but connecting from another box requires that pipe to be available on the remote client. The COM interface on VMware is not doing that.

Which brings me back to the TCP interface. Even in host-only mode, where you've enabled VM-to-VM comms w/o access to the host machine external interfaces, the host is acting as the router and has access to the host-only interface. That's really the interface you want to use, whether from windbg or ghidra. If your host is Windows, you can do this directly. If not, you can use another VM to host the Ghidra agent or run the Ghidra agent in the target VM.

I think...again, it's been a while.

[astrelsky]

@astrelsky OK, the more I think about this, the more I think this is the wrong approach....

Admittedly, it's been a long time since I've used the COM<->named pipe feature, but my recollection is that I always used it in the context of kernel debugging. Kernel debugging of windows over the serial port is the most basic and oldest flavor of kernel connection, and the whole point of the COM<->named port thing is to export the COM interface to clients outside the VM. The link you supplied, for instance, is clearly describing a kernel-debugging setup.

The COM is really not available (if I remember correctly) inside windbg for user-mode debugging. There's really no use case for that. Named pipe debugging is supported, but using npipe:pipe=\.\pipe\whatever makes that pipe available locally, i.e. I can connect from another windbg on the same box, but connecting from another box requires that pipe to be available on the remote client. The COM interface on VMware is not doing that.

Which brings me back to the TCP interface. Even in host-only mode, where you've enabled VM-to-VM comms w/o access to the host machine external interfaces, the host is acting as the router and has access to the host-only interface. That's really the interface you want to use, whether from windbg or ghidra. If your host is Windows, you can do this directly. If not, you can use another VM to host the Ghidra agent or run the Ghidra agent in the target VM.

I think...again, it's been a while.

I put together a small python script this morning and used asyncio to try and forward the named pipe opened by windbg via .server npipe:pipe=pipename to the com port and then use it in windbg from the named pipe connected to the vm com port and that still didn't work.

I don't understand why there isn't a way to do remote user-mode debugging without exposing the host (and everything else connected to it) to the vm. I could just be over paranoid here but the reason I don't want to use tcp is because I don't want anything running in it to be able to access my workstation through the network. If I run a wiper or ransomware on the vm and it decides to to access files on the network, that's going to be a fun day.

I'll see if I can setup a network adapter on the vm that only has one port open. I'm not actually sure what level of control I can get. (Edit: doesn't look like I can do that)

[d-millar]

Yeah, I understand the motivation, but at some level the VM is either isolated or it's not. You can run Ghidra in the VM, but, if you need to run Ghidra outside the VM, by definition the VM is not isolated. Real question is what level of non-isolation are you willing to tolerate. Technically, exposing the COM interface or a named pipe or a file share still makes you vulnerable at some level.

I guess my main point is, unless you disconnect your network adapter (which is it sounds like you have NOT done), that TCP/IP interface is open, and it makes little to no difference that you are or are not running a debugger over it.

[d-millar]

Following up: there was a time when we used the com0com and com2tcp projects as redirectors. These might allow you to close the network adapter and forward the tcp/ip traffic over the com interface. I haven't completely thought this through, but I'm pretty sure I did this at one point.

[astrelsky]

I guess my main point is, unless you disconnect your network adapter (which is it sounds like you have NOT done), that TCP/IP interface is open, and it makes little to no difference that you are or are not running a debugger over it.

The virtual network adapter is configured as vm to vm. It cannot communicate with the host over the virtual network or vise versa.

Following up: there was a time when we used the com0com and com2tcp projects as redirectors. These might allow you to close the network adapter and forward the tcp/ip traffic over the com interface. I haven't completely thought this through, but I'm pretty sure I did this at one point.

That might work, I'll have to look into it. That's basically what I was trying to do with the python script. I initially wanted to try to hack up a windows driver sample to just forward one to the other, but the windows api is completely unusable.

I wish vmware would have an option to just pass a named pipe directly through like it does internally for whatever it uses them for.

Anyway I appreciate the help, I've been wracking my brain again this for a while and have set it aside and come back several times.

[d-millar]

The virtual network adapter is configured as vm to vm. It cannot communicate with the host over the virtual network or vise
versa.

What version of VMware are you running? I have Workstation 17 Player running on Windows, VMware Fusion 12.2.4 on an Intel Mac, VMware Fusion e.x.p. running on an M1, and an older version on Ubuntu 22, and none of them have an option descibed as "vm to vm".

Agreed re pipes.

[d-millar]

nvd - I see it. Interesting option, custom w/o the host adapter. I had not seen that before.

[astrelsky]

nvd - I see it. Interesting option, custom w/o the host adapter. I had not seen that before.

I think so. I won't be able to check until Monday.

[astrelsky]

The option is "Custom: Specific virtual network"