HyperDBG integration

[Wenzel]

HyperDbg debugger is an open-source, hypervisor-assisted user-mode, and kernel-mode Windows debugger with a focus on using modern hardware technologies. It is a debugger designed for analyzing, fuzzing and reversing.

How does it listen for VM events such as EPT pagefaults ?
What hypervisors are supported ?

Could HyperDBG make use of libmicrovmi ?

cc @SinaKarvandi here :)

[SinaKarvandi]

Thanks for considering integration!
I have to see how libmicrovmi works and after that, I post here about some solutions that we can integrate together. At a glance, I think it's super easy to make this integration.
I'll ask you if I have any questions about libmicrovmi and ping you back soon.

[Wenzel]

Sure !

From what I understand, you virtualize a Windows system on-the-fly, blue pill style.
So you bring your own hypervisor and you are not based on an existing one.

I think this is close to what bareflank is doing right ?
Since LibVMI already has a driver for bareflank, It should be doable to have a "hyperdbg driver" for libmicrovmi.

I'm curious how you forward events though, because the libvmi bareflank driver has this restriction that i cannot listen on hardware, otherwise it would simply freeze the system 🙃

[SinaKarvandi]

Yeah, it's a blue-pill style hypervisor.

I think this is close to what bareflank is doing right ?

Yes, it is.

I'm curious how you forward events though, because the libvmi bareflank driver has this restriction that i cannot listen on hardware, otherwise, it would simply freeze the system 🙃

We have a mechanism to trigger events. whenever an event happens after a vm-exit occurs, HyperDbg executes a function called "DebuggerTriggerEvents". You can see its definition.
https://github.com/HyperDbg/HyperDbg/blob/1bc88303d90ab5982ad5a346e04e9d65a76b91f3/hyperdbg/hprdbghv/Debugger.c#L577

After that, this function executes all the related events for the debugger such as creating logs, running scripts, break to the debugger, etc.

I think we can provide you the details you need by adding codes on "DebuggerTriggerEvents". Do you think it works?

[Wenzel]

I think we can provide you the details you need by adding codes on "DebuggerTriggerEvents".

What do you mean by "adding codes ?"

To summarize, the goal of libmicrovmi, here, would be to reuse the higher-level parts of HhyperDBG, as the debugger UI, CLI, etc, on top of other hypervisors, think Xen, KVM

Do you think that's doable in terms of architecture, or HyperDBG will always be tied to its blue-pill style hypervisor ?

[Wenzel]

I'm updating this issue based on the discussions we had on Twitter.

First, HyperDBG has 2 modes:

• Debugger
• VMI

The Debugger mode is bit tricky in terms of connection, as Windows sockets cannot be used since they are not IRQL compatible.
So a serial connection has to be used.

So if we want libmicrovmi to work with both modes, it should provide a serial socket (this is the part where I'm a bit lost)

Regarding the VMI mode, the TCP connection is already implemented, using .listen and .connect commands.
But the problem here is that we can't call a function directly, but rather pass a string that would be interpreted by hyperdbgctrl.

Following this idea:

It's a possible solution to pilot HyperDBG from libmicrovmi, however this would be slow to deliver events, mostly difficult to implement, converting all commands into strings.

Instead, this is how i was envisioning an integration:

Here libmicrovmi only has to translate from an API to another one.

[SinaKarvandi]

Thank you for the illustration.
I didn't get the last picture so let's double-check as there are a few questions before we start.

1. What do you mean by "libmicovmi HyperDBG driver"? Is it a custom driver that wants to interact with HyperDbg driver and libmicrovmi?
2. What's the point of using TCP / NamedPipe version of HyperDbg? We can design a structure to get the command and interact with libmicrovmi and use the TCP interface, however, I'm not sure if you want to implement all the commands in libmicrovmi. Also, another option is using command strings directly.

[Wenzel]

1. What do you mean by "libmicovmi HyperDBG driver"? Is it a custom driver that wants to interact with HyperDbg driver and libmicrovmi?

I suppose I shouldn't have used the term "driver". It's not a driver in the Windows sense, living in kernel, but rather an adapter, in userland with the rest of libmicrovmi, to translate calls from the generic libmicrovmi interface to HyperDBG Windows driver.

2. What's the point of using TCP / NamedPipe version of HyperDbg?

The point here is to be able to use HyperDBG debugger on other hypervisors.
I could use HyperDBG interface to debug a guest in Xen for example, over TCP or a serial socket, leaving libmicrovmi to do the job.

We can design a structure to get the command and interact with libmicrovmi and use the TCP interface, however, I'm not sure if you want to implement all the commands in libmicrovmi. Also, another option is using command strings directly.

in the second picture, libmicrovmi doesn't have to handle any commands. A command is a too high-level construct.

The hyperdbgctrl TCP / Named pipe server is listening, receiving string commands, parsing them, and translating the calls into microvmi_xxxx() calls.
So the hyperdbgctrl executable will be dynamically linked with libmicrovmi, if it makes things clearer.

[SinaKarvandi]

Thanks for your answers.
It's still a little bit vogue for me.

Let's give an example,
First, the user enters a command like "eb 0xffff12345676 90" in CLI version of HyperDbg in a remote computer (debugger) then I send it to hyperdbgctrl in another computer (debuggee) using TCP and after parsing it, I see if libmicrovmi has an API for it like microvmi_write_virtual(), so I call this API and you will send it to (hprdbghv or HyperDbg driver) using ioctls?

Is it correct?

[Wenzel]

Hi Sina,
sorry for the lack of reply, i have been busy with other PRs.
first, i wish you a happy new year 2021 :)

Let's give an example,
First, the user enters a command like "eb 0xffff12345676 90" in CLI version of HyperDbg in a remote computer (debugger) then I send it to hyperdbgctrl in another computer (debuggee) using TCP and after parsing it, I see if libmicrovmi has an API for it like microvmi_write_virtual(), so I call this API and you will send it to (hprdbghv or HyperDbg driver) using ioctls?

yes, this is correct 👍

I see if libmicrovmi has an API for it like microvmi_write_virtual()

In the end, the goal is to mutualise the frameworks and tools you are building as part of HyperDBG to make them available for other hypervisors, and grow the ecosystem

[SinaKarvandi]

Hello, thank you for your reply. Happy new year to you too.
I get that.
I think the best time to start integrating with libmicrovmi is after the first release because we might change some of the functionalities. The first release is in late-march 2021.
Is that ok?

[Wenzel]

That's a good idea, there is no rush, and we still working on other integrations here, like a Volatility3 address space for example

[ohault]

Does it possible to get an update on this according to the latest HyperDbg release.

[SinaKarvandi]

Hi,
Sorry for the very late update.

Fortunately, we refactored the code of HyperDbg and now there are API functions available for almost all of the HyperDbg modules (including those that are available to be used in the kernel mode and user-mode).

https://github.com/HyperDbg/HyperDbg/tree/master/hyperdbg/include/SDK/imports

For the hypervisor part (kernel) all of the functionalities are exported as functions in DLL. But not all of the functionalities are available for the user mode (libhyperdbg). The problem is that the code base is now too big and it takes time to convert all commands into APIs but most of the critical commands are now available:

https://github.com/HyperDbg/HyperDbg/blob/master/hyperdbg/include/SDK/imports/user/HyperDbgLibImports.h

Other than that, there are a couple of examples of how these functions could be imported.
https://github.com/HyperDbg/HyperDbg/tree/master/examples

I'm working on exporting all of the critical functionalities as functions first, and then trying to export non-critical functionalities. It could be used now, but you could also wait longer to get a complete SDK.

I'll keep you updated once the SDK is finished (which could take time).