We are celebrating today as we've reached 200,000 lines of code! A big thank you to all the friends and contributors who made this possible! 🤗

https://github.com/HyperDbg/HyperDbg

🎉

[discord] <ohault> Could a tiny hypervisor emulate PopCnt and SSE4.2 on top of a legacy CPU without these instructions ?

Why not using QEMU?

can u reproduce it? it works if we set the segment selector. I have sent a pr to dev.

[discord] <ohault> [reply]: The idea behind « tiny » would be a very slim and transparent layer at boot time as Type1 hypervisor to just add to your existing hardware some additional capabilities emulated

How old is the target CPU? What model is it?

[discord] <ohault> [reply]: I can think of earlier generations of Intel i7, but this concept could also add some system ram to the host from some fast local NVMEs (Western Digital had a product in the past leveraging this concept)

While it would be possible to create a hypervisor, pre-popcnt CPUs have the old VTx (pre-EPT). You would need to trap #UD and emulate the needed instruction. But I'm afraid you'll be disappointed by the performance of this method, it will be very slow. The better idea would be to instrument target binaries directly.
As for the RAM from NVME - I'm afraid it doesn't work this way, maximum you can can get is a an analog of a page file, which is already implemented in the OS. DRAM traffic can not be magically turned into PCIe traffic, and also it's has a completely different inner workings.

[discord] <ohault> [reply]: About CPU extensions, VT would be a required. About RAM extensions, I guess it is this very special product - https://www.westerndigital.com/en-ap/products/internal-drives/data-center-drives/ultrastar-dc-me200-nvme-ssd?sku=0TS1741 and I guess a special type 1 hypervisor should be used somewhere ?

[discord] <ohault> [reply]: Very very interesting - https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/data-center-drives/ultrastar-dc-me200/product-manual-ultrastar-dc-me200.pdf

This product doesn't mention it is a RAM replacement, it is still a storage device with "near DRAM speeds". So they use a hypervisor for memory "bubbling". Don't expect this method to be any near DRAM-like performance.

Theres only one technology with flash memory that works as RAM - Intel Optane DC

And it was designed to be a DRAM controller with optane memory on dram sticks. Even then, optane is a cache for RAM.

[discord] <ohault> But this concept of a tiny and transparent type-1 hypervisor for software hardware extensions, is the point I would like to underline

I mean sure, you can try that

[discord] <ohault> I don’t know yet any open source project leveraging this concept

I guess I've explained why :)

Too much effort for questionable results

[discord] <ohault> [reply]: It’s a broader concept, but and I guess we can see introspection also as such a « hardware extensions » to provide capabilities for inspecting, monitoring, debugging, …

[discord] <ohault> Almost all startups in this space have been acquired by big cloud players - https://www.nextplatform.com/2022/09/12/why-arent-there-software-defined-numa-servers-everywhere/amp/

I tested the patch you made, and it works as expected. It makes sense that the crash occurred because we weren't properly restoring the SS, DS, FS, and other segments for a 32-bit program. Your patch (PR) seems to have resolved the issue. 👍

if I use "i" for tracing and get to the instruction causing the exception... where will I be directed by the next step? in the exception handler?

If you use the 'i' command, then in the interrupt/exception/fault handler from IDT.

But if you use the 't' command, then you just go to the next instruction (just like windbg, x64dbg).

can I put a read/execute hook(!epthook) on a section of code (for example, the text ntoskrnl section)

Yes. That's what the '!monitor' command is designed for.

https://docs.hyperdbg.org/commands/extension-commands/monitor

But just keep in mind that putting a !monitor hook on a long range of memory is only possible if all of those pages are available at RAM (not paged-out).

So, if you put a !monitor hook on a range in which one or some of pages are not residing in RAM, then HyperDbg shows you error. In that case, you need to use the '.pagein' command to force Windows to bring those pages into the RAM.

https://docs.hyperdbg.org/commands/meta-commands/.pagein

HyperDbg v0.10.2 is released!

This release comes with lots of bugfixes and improved stability, check it out here:

https://github.com/HyperDbg/HyperDbg/releases/tag/v0.10.2

Guys, we need to have a discussion in the group about whether fixing or not fixing the issue mentioned here:

https://github.com/HyperDbg/HyperDbg/issues/468

I wrote the patch for this bug which is context-switching (saving and restoring) XMM registers in VM-exits and VM-entries. Though, I'm still unsure whether to apply it or not, since it might have an overall negative influence on the performance of the HyperDbg as we need to save and restore all XMM registers each time a VM-exit happens.

What do you guys think/suggest?

I know it wouldn't work for you, but my approach was to ditch any sse in the hypervisor, so no xmm context save and restore needed

The problem for HyperDbg is that, as we used RtlZeroMemory in almost all of the VM-exit handling routines, this function (and probably other functions) use XMM registers to zero the memory (to speed up). I couldn't find a way of forcing MSVC not to use XMM registers for this purpose. So, I think this approach as you mentioned, won't work for HyperDbg.

Then you might find this article curious :)
https://pulsedbg.com/codequal.html

I tried a nested VM and that work doesn’t work well (at all really).

Running Linux on my host system machine and I might need to change that.

Not sure if I understand it correctly. 🤔
Did you run HyperDbg on a KVM machine with nested virtualization?

I have my host OS running Linux and I have a guest OS running windows (called Upper). Within that guest OS, I have a nested VM (Called Lower).

I have HyperBg running in Upper and I’m trying to debug Lower but Lower could barely boot.

Sorry for the late response. Actually, we have never tested HyperDbg on a Linux (host) based system. I can imagine that even though it theoretically shouldn't have any issues (since HyperDbg runs perfectly on bare-metal), the nested virtualization implementation might behave differently. So, I suggest booting into Windows (dual boot) and using HyperDbg that way.

No worries. I might do just that.

[discord] <192.168.1.1.> does anybody know why when I load vmm it says vmx operation is not supported by your processor even though I did enable VMX/VT-X

Did you enable it from the BIOS?

Or maybe there is a top-level hypervisor (like Hyper-V), that is preventing HyperDbg from running (manipulating CPUID bits, or not letting hyperdbg to change control registers).

Did you follow all the steps mentioned in this video?
https://www.youtube.com/watch?v=MDZ9zYfqo50&ab_channel=OpenSecurityTraining2

[discord] <192.168.1.1.> [reply]: I didn't the follow steps within the videos I followed them in the Doc

[discord] <192.168.1.1.> But yeah I enabled VMX from the bios which is the same as VT-X

[discord] <192.168.1.1.> since my bios has no option to enable VT-X

[matrix] <mallory> Hi,

I'm new to HyperDbg and am looking into automating more of the debugging process.
There seem to be several options, however I am not sure which path I should take or whether HyperDbg is even the right choice.

Some of the things I would like to do and the considerations I've come up with so far:

- I would like to automate things like the creation of a process, enabling/disabling events (from other events) etc. However, it appears that from the **scripting engine**, many of the features that can be performed interactively are not really scriptable. For example, it appears difficult to obtain the pid after starting a process (after running `.start`, a breakpoint is triggered so I could save the pid there, but there sometimes appear to be several breaks, so how often to issue `g` afterwards in the script?), and also I can not see a way to obtain the event ID after creating an event, so I'm not sure how to obtain the event ID for `event_enable()` (there is `$event_id` but according to docs it's only available when an event is called). It seems this restriction applies to several interactive commands in that they are not easily accessible from the scripting language. For example, it might be useful to print/save the call stack when an event is triggered without dropping back to the interactive console.
- I have seen the [event forwarding](https://docs.hyperdbg.org/tips-and-tricks/misc/event-forwarding) interface which uni-directionally sends event results, but I cannot react from these.
- There's the ["SDK"](https://github.com/HyperDbg/HyperDbg/tree/master/hyperdbg/include/SDK), however I couldn't find much docs about it, in particular I'm unsure what its targeted use case is. In the [hyperdbg_app](https://github.com/HyperDbg/HyperDbg/blob/master/examples/user/hyperdbg_app/code/hyperdbg-app.cpp) example, it seems that one kind of needs to emulate the interactive input, in particular `g` commands (`hyperdbg_u_continue_debuggee()`), which seems quite unreliable; in fact, the provided example did not work for me as-is and I needed to patch it for it not to get stuck. For a more reliable interface, I guess there would either need to be callbacks for events, or alternatively an event loop (not sure if that's already possible right now)? I think so far, the SDK seems nearest to what I'm looking for, since I can use it with a normal programming language and presumably perform introspection as well as modify guest state.
- In the HTML docs, there are references to the ioctl interface, though I'm not quite sure how to use it, or if the SDK is supposed to abstract away the ioctl interface?
- Examples of what I would like to achieve:
- Log execution transitions between PE sections. This may require dynamically setting up and disabling `!monitor` events as well as obtaining section addresses, which may be a bit much to do with just the scripting language.
- Better logging facilities such as printing syscall names (for which a bit more programming flexibility than just the scripting language would be useful); this can be solved using just event forwarding, but I suppose I would prefer a central place to control the VM from rather than using different kinds of applications for scripting/parsing/VM control etc.
- Maybe I'm also trying to (mis?)use HyperDbg as a hypervisor SDK (rather than (just) a debugger), but I'm not sure if it was ever meant to do that.
- If you're familiar with the qemu-based [PyPANDA](https://docs.panda.re/#pypanda), this is the kind of interface I may be looking for (except in a Hypervisor setting rather than dynamic binary translation). Within a single script, it allows all sorts of hooking, such as setting up callbacks for memory accesses, as well as controlling the execution of the VM, performing analysis/introspection, modifying guest state etc.

In the end, I'm not really sure what exactly I'm looking for, but maybe you have some ideas :)
Btw, I really like the ideas behind the project and the documentation is really well written!

Hi and welcome to the HyperDbg community!

I'll start by explaining why we designed the script engine in HyperDbg the way we did, and how it differs from traditional debuggers like WinDbg. This will help clarify what tasks it can and cannot do.

The script engine in HyperDbg works entirely in kernel mode (VMX-root mode), without needing to switch between kernel and user-mode like WinDbg does. This makes it incredibly fast—up to 1000 to 2500 times faster than WinDbg, based on our tests (published in the HyperDbg's main academic paper). In this design, each core can run scripts independently without pausing, unlike in WinDbg where cores might wait for each other.

However, while this gives us great speed, it comes at a cost. The script engine loses some flexibility. For example, you can’t start a process immediately from VMX-root mode without letting Windows run for a bit first. Some commands that need other execution modes won't work in VMX-root mode, which is why there's a distinction between commands and event scripts.

Now, let's address your questions:

> I would like to automate things like the creation of a process, enabling/disabling events (from other events) etc. However, it appears that from the scripting engine, many of the features that can be performed interactively are not really scriptable.

That’s correct, based on what I explained earlier.

> For example, it appears difficult to obtain the pid after starting a process (after running .start, a breakpoint is triggered so I could save the pid there, but there sometimes appear to be several breaks, so how often to issue g afterwards in the script?)

There are generally two breaks. One when the process is created (before the main module loads) and one when the first instruction of the main module runs (similar to other debuggers like x64dbg and ollydbg).

> and also I can not see a way to obtain the event ID after creating an event, so I'm not sure how to obtain the event ID for event_enable() (there is $event_id but according to docs it's only available when an event is called).

Event IDs increase by one each time you create an event. You can keep track by writing a simple script to increment a variable with each event. Even if you remove an event, the sequence continues.

> It seems this restriction applies to several interactive commands in that they are not easily accessible from the scripting language. For example, it might be useful to print/save the call stack when an event is triggered without dropping back to the interactive console.

The script engine has functions that can help you do this. I’ll find an example for you.

Here are the examples:

? n = 5;
? m = 50;
? for (j = 0; j != m; j++) {
temp = @rsp + (j * 8);

printf("%llx", temp);

for (i = 0; i != n; i++) {

is_valid = check_address(temp);

if (is_valid == 1) {

temptemp = temp;
temp = poi(temp);

is_valid2 = check_address(temp);

if (is_valid2 == 1) {

printf("-> %llx", temp);
} else {
test1 = db(temptemp);
test2 = db(temptemp + 1);
if (test1 > 1f && test1 < 7f) {
if (test2 == 0x0) {
printf(" (%ws)", temptemp);
} else {
printf(" (%s)", temptemp);
}
}
}

} else {
break;
}
}
printf("\n");
}

Yes, you basically need something like the above script.

> I have seen the [event forwarding](https://docs.hyperdbg.org/tips-and-tricks/misc/event-forwarding) interface which uni-directionally sends event results, but I cannot react from these.

Event forwarding sends results, like printf messages, to a file, network, or DLL. I’m not sure what you mean by "react," but it’s mostly for redirection.

> There's the ["SDK"](https://github.com/HyperDbg/HyperDbg/tree/master/hyperdbg/include/SDK), however I couldn't find much docs about it, in particular I'm unsure what its targeted use case is. In the [hyperdbg_app](https://github.com/HyperDbg/HyperDbg/blob/master/examples/user/hyperdbg_app/code/hyperdbg-app.cpp) example, it seems that one kind of needs to emulate the interactive input, in particular g commands (hyperdbg_u_continue_debuggee()), which seems quite unreliable;

Yes, the SDK isn’t fully developed yet, but you can use hyperdbg_u_run_command to run any HyperDbg command through a string. The SDK is currently under development.

> in fact, the provided example did not work for me as-is and I needed to patch it for it not to get stuck. For a more reliable interface, I guess there would either need to be callbacks for events, or alternatively an event loop (not sure if that's already possible right now)? I think so far, the SDK seems nearest to what I'm looking for, since I can use it with a normal programming language and presumably perform introspection as well as modify guest state.

We are working on a callback interface, but since HyperDbg is open-source, you can add your own code to the kernel-mode drivers or user-mode where needed. Let us know what you need to do like what you need to patch (registers, memory, etc.), and we can help you find the right function to add your C codes there.

> In the HTML docs, there are references to the ioctl interface, though I'm not quite sure how to use it, or if the SDK is supposed to abstract away the ioctl interface?

Actually, yes, when HyperDbg was first designed, we assumed that the user might want to talk directly with the driver using IOCTL. But once HyperDbg also supported the 'Debugger Mode', we came to the conclusion that just letting users run IOCTLs is meaningless since the communication protocol is changed to serial ports, for example. So, once the SDK is done, these IOCTLs will be replaced with SDK functions.

> Log execution transitions between PE sections. This may require dynamically setting up and disabling !monitor events as well as obtaining section addresses, which may be a bit much to do with just the scripting language.

Yes, for these ones, you probably need to get help from some codes other than the script engine (remember, the script engine runs in the kernel of the target debuggee from the VMX-root mode where everything (even interrupts) is disabled). This way of thinking about the script engine will give you a better idea of what you could and could not do with it.

On the other hand, setting a '!monitor' hook for an entire section is a little bit more challenging for HyperDbg to handle and might need some user-mode interactions. For example, EPT hooks for '!monitor' apply on physical pages. But once you load the process, the operating system might not (and will not) bring the entire module into RAM and won't allocate physical memory for that. So, sometimes you need to tell HyperDbg to emulate a memory read (inject page faults #PF) to force Windows to bring that page into the memory for you (e.g., by using the '.pagein' command).

> Better logging facilities such as printing syscall names (for which a bit more programming flexibility than just the scripting language would be useful); this can be solved using just event forwarding, but I suppose I would prefer a central place to control the VM from rather than using different kinds of applications for scripting/parsing/VM control etc.

Again, this is not possible since the script engine is not a normal script engine that is running in user mode like Python to do these things but for this case, the event forwarding mechanism has an option of introducing a DLL. So, you can forward your system-call numbers to the DLL, and your user-mode DLL will take of care of converting them to system-call names.

> Maybe I'm also trying to (mis?)use HyperDbg as a hypervisor SDK (rather than (just) a debugger), but I'm not sure if it was ever meant to do that.

Actually, HyperDbg is designed for these tasks, but since it’s not super perfect yet, you may run into bugs or not find suitable SDK APIs. I’m not aware of other tools that match its capabilities in this area.

> If you're familiar with the qemu-based [PyPANDA](https://docs.panda.re/#pypanda), this is the kind of interface I may be looking for (except in a Hypervisor setting rather than dynamic binary translation). Within a single script, it allows all sorts of hooking, such as setting up callbacks for memory accesses, as well as controlling the execution of the VM, performing analysis/introspection, modifying guest state etc.

Yes, I'm familiar with it. I could imagine that the ultimate goal of HyperDbg is reaching this level of capabilities with no errors, but you know, handling these events from a hypervisor side is where you deal with lots of OS paging and OS events and different processes is so challenging compared to using a user-mode application like the way they implement panda.re using QEMU. So, of course, it would be so challenging to event transfer a simple buffer from the VMX-root mode which is even higher privileged than the OS to the user-mode and properly handle it, so you could expect less stability compared to oanda.re from HyperDbg but of course a tremendously faster implementation at the end it's your choice what would be beneficial for your scenario.

I suggest, seeing some OpenSecurityTranings videos of HyperDbg, that'll give you an idea of how HyperDbg is supposed to work and how you can deal with that, especially from the 5th season afterward.

I recommend checking out some OpenSecurityTraining videos on HyperDbg, especially after season 5, to see how it works in more detail.

> In the end, I'm not really sure what exactly I'm looking for, but maybe you have some ideas :)
Btw, I really like the ideas behind the project and the documentation is really well written!

I think HyperDbg could be a great choice for you, especially if you combine the script engine with custom patches. Other options could be LibVMI or modifying KVM, but they don’t offer the same reverse-engineering capabilities as HyperDbg since KVM is not designed for RE (unlike HyperDbg which is designed for reverse engineering), it's designed for full system virtualization.

[matrix] <Sinaei> [reply]:
Not sure if this bot replies to your mesaage correctly from the element. But in the above messages you could find the answers. Let me know, if you have anymore questions.

[discord] <rayanfam> [reply]: You can check it from CPU-Z. If it contains 'VMX', it means hypervisor is supported. Otherwise, something is blocking it, maybe core isolation is enabled which might influence the presence of hypervisor (not sure if it could be related).

[discord] <rayanfam> [reply]: But in any case, you need to follow the steps from the video. Let me know, if it didn't work.

Did you know? You can monitor (or even ignore) SMI# executions to port 0xB2 with a simple script using the '!ioout' command in HyperDbg!

Read more:
https://docs.hyperdbg.org/commands/extension-commands/ioout

#HyperDbg_Tips

[discord] <ohault> In VMI Mode, why breaking to the debugger and step instructions in kernel-mode is not supported ? It's theoretically impossible or not yet implemented ?

It's not supported in both user-mode and kernel-mode (not just kernel mode). But it's supported in both kernel mode and user mode in the debugger mode.

It's possible to implement such a stepping for the user mode applications but it's not possible (or if possible, may cause lots of implementation problems for kernel mode).

Similar to WinDbg, it's not possible to breakpoint or step through instructions in local kernel debugging.

Another option is making a softICE like interface, which is offered by other debuggers like BugChecker, but we currently don't have such a infrastructure. Mainly because we use some libraries that need user-mode interactions. The script engine of HyperDbg is VMX-root mode compatible but the command line interpreter of HyperDbg needs user-mode codes for now.

https://github.com/vitoplantamura/BugChecker

Maybe in the future we add support to this SoftICE like interfaces, but right now the priority is to support kdnet like connection, port HyperDbg to Linux, and make UEFI applications to run HyperDbg from the boot-time.

[discord] <ohault> [reply]: Thank you, it bring some perspectives for upcoming developments. I wonder about all the modes if it could not be worth to make a summary table about modes/features to insert into the documentation

hey hey, any progress on inline asm inside scripts ?

Certainly, that sounds like a good idea! I'll add it to the to-do list. In the meantime, feel free to create a PR and add it to the docs repo if you'd like. I believe GitBook syncs automatically with the docs repo.

I'm currently collaborating with a friend to design firmware commands for HyperDbg (mainly for debugging PCIe peripherals, ACPI, DMA regions, and similar tasks). Other developers typically handle script engine.