[discord] <t0int> Where can i join the telegram group

https://t.me/HyperDbg

Thanks!

the user-mode debugger in VMI Mode is still in the beta version and not stable. we decided to exclude it from this release and release it in future versions. if you want to test the user-mode debugger in VMI Mode, you should build HyperDbg with special instructions. But starting processes is fully supported in the Debugger Mode.
(it's not recommended to use it in VMI Mode yet!)

the user-mode debugger in VMI Mode is still in the beta version and not stable. we decided to exclude it from this release and release it in future versions. if you want to test the user-mode debugger in VMI Mode, you should build HyperDbg with special instructions. But starting processes is fully supported in the Debugger Mode.
(it's not recommended to use it in VMI Mode yet!)

this why？

Doesn't it support using ivm mode in local machine?

@HughEverett

Do you know why?

I can't use the local computer.

If you want to debug a process (step through its instructions or start it from entry point or put breakpoints), you need to use HyperDbg in the debugger mode, not VMI mode.

Vmi mode can't even start a process?

No matter what command I type, it always appears this prompt.

Or did I not enter the correct instructions? Do you have any examples?

HyperDbg doesn't use DEBUG FLAGs to start a process (to further enhance its transparency) instead it uses hypervisor tricks to intercept the execution of the first instruction. That's why it's not that easy to implement the similar approach in the VMI mode. Right now, it fully support process creation in the debugger mode.

You need to see open security training course on HyperDbg. Plenty of examples for starting the process are there:

https://ost2.fyi/Dbg3301

Or in YouTube:
https://www.youtube.com/watch?v=RDlp0PCFgxI&list=PLUFkSN0XLZ-kF1f143wlw8ujlH2A45nZY

I don't understand, what are the special instructions?

You must compile the sources in Visual Studio 2022.

Before compilation you must change /**
* @brief Activates the user-mode debugger
*/
#define ActivateUserModeDebugger FALSE
on #define ActivateUserModeDebugger TRUE

But anyway it's useless...

Yes, I'm doing it, thank you.

After running the debugger you will get a BSOD. The current version of the debugger simply does not work in local mode at all.....

So that means it doesn't work?

I want to make it my own epthook.

But you said it doesn't support local mode?

Is that right? It doesn't support local mode?

Moreover - I tried to connect two VMWare. The server "sees" the client, but after connection the server does not respond to keystrokes.

It just freezes and that's it.

It has so many problems. So what is its meaning?

😂

Although I read the documentation and watched the video and did everything as it is written and shown there. Maybe you can do it...

I think it should work if it is in a virtual machine.

I will try to compile the code again,

If you succeed, please tell me how you did it.

OK

This might be bug with HyperDbg. Did you also have the same problem with running it from host?

Because I see sometimes VMWare doesn't properly handle serial connections over two VMs. But, Guest to host is perfectly fine.

If you want to use HyperDbg in a full-featured mode, you need to run it in the Debugger Mode.

VMI Mode contains all the features of the Debugger mode except you cannot put breakpoints, break to debugger in case of triggering an event, and step through the instructions. All of these capabilities are available in the Debugger Mode (not local VMI mode).

Other than that, everything is the same (e.g. you can scripts and trigger custom scripts in case of events) in the VMI Mode.

@HughEverett I use vmi mode on my local machine, and it can't even use the startup command.

@t0r0_ru Did you find an alternative?

I tried the emulator https://www.serial-over-ethernet.com/downloads.
This emulator can create a virtual port.
Without success...

By the way, both VMware virtual machines communicate perfectly via Serial ports, thanks to this program.

HyperDbg "sees" these ports, but works exactly the same. That is, it does not work :)

Yes. I told you earlier, the '.start' command only works in Debugger mode (not in VMI mode).

HyperDbg communicates with IO ports for serial debugging. I'm not sure if the interface of these serial emulators are the same.

For example, if you have a PCIe card to serial, it doesn't work with HyperDbg because the interface of communication is over PCIe BARs or custom PCIe IO ports which HyperDbg is not aware of.

I’m sorry.
The debugger seems to work. In the bundle the host computer - VmWare.

👍

hi everyone, how to build the hyperdbg-cli support --debugger args. I want to attach a process in VMI Mode.

The support for attaching in the VMI mode is not stable yet. You should use HyperDbg in the Debugger mode for switching into processes.

thank your for your reply. How to operate it?

My application run in windows10. How to switching to Debugger mode?

You need to follow steps mentioned in this page:

https://docs.hyperdbg.org/getting-started/build-and-install

If you prefer to see these steps in a video, you should check:

https://youtu.be/MDZ9zYfqo50

And here for attaching to HyperDbg over the Debugger Mode:
https://docs.hyperdbg.org/getting-started/attach-to-hyperdbg/debug

I got this error when i use debugger model.

The equivalent to attaching to a process in the debugger mode is the '.process' or the '.thread' command:

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

got it.thank your very much

[discord] <unrustled.jimmies> I disable hyperv/hvci, boot using efiguard, disable dse and then load hyperdbg but i get exception on invalid stack. Anything im missing (will look into the logs later but just wanted to check if anyone has any ideas of what i could be doing dumb or if there are any logs generated i can look at)

[discord] <unrustled.jimmies> Got the stack trace by opening up the minidump in windbg

```
ffffc181`e70a55e8 fffff803`e9e73a3d : 00000000`000001aa ffffae8f`989aee60 00000000`00000003 ffffc181`e70a58d0 : nt!KeBugCheckEx
ffffc181`e70a55f0 fffff803`e9c98e83 : 00000000`00000000 ffffae8f`989aecd0 00000000`00000000 00000000`00000001 : nt!RtlpGetStackLimitsEx+0x5d
ffffc181`e70a5640 fffff803`e9ddd501 : ffffae8f`989aeaf0 ffffc181`e70a5dd0 ffffae8f`989aeaf0 fffff780`00000708 : nt!RtlDispatchException+0xe3
ffffc181`e70a58a0 fffff803`ea0a52b2 : cccccccc`ccccffff 6c894808`245c8948 57182474`89481024 57415641`55415441 : nt!KiDispatchException+0xac1
ffffc181`e70a5fb0 fffff803`ea0a5280 : fffff803`ea0b913e 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxExceptionDispatchOnExceptionStack+0x12
ffffae8f`989aeae8 fffff803`ea0b913e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiExceptionDispatchOnExceptionStackContinue
ffffae8f`989aeaf0 fffff803`ea0b139b : ffffae8f`98836000 00000000`00000003 ffffae8f`989aee88 fffff803`a5d71607 : nt!KiExceptionDispatch+0x13e
ffffae8f`989aecd0 fffff803`a4470343 : ffffae8f`00000003 00000000`00000d01 00000080`00203001 00000000`00000001 : nt!KiBreakpointTrap+0x35b
```

[discord] <unrustled.jimmies> ```
ffffae8f`989aee60 ffffae8f`00000003 : 00000000`00000d01 00000080`00203001 00000000`00000001 fffff803`a4482a30 : hyperhv+0x10343
ffffae8f`989aee68 00000000`00000d01 : 00000080`00203001 00000000`00000001 fffff803`a4482a30 fffff803`a4482a10 : 0xffffae8f`00000003
ffffae8f`989aee70 00000080`00203001 : 00000000`00000001 fffff803`a4482a30 fffff803`a4482a10 00000000`00000407 : 0xd01
ffffae8f`989aee78 00000000`00000001 : fffff803`a4482a30 fffff803`a4482a10 00000000`00000407 fffff803`9c2b630f : 0x00000080`00203001
ffffae8f`989aee80 fffff803`a4482a30 : fffff803`a4482a10 00000000`00000407 fffff803`9c2b630f 00000000`00000d82 : 0x1
ffffae8f`989aee88 fffff803`a4482a10 : 00000000`00000407 fffff803`9c2b630f 00000000`00000d82 00000080`0020301c : hyperhv+0x22a30
ffffae8f`989aee90 00000000`00000407 : fffff803`9c2b630f 00000000`00000d82 00000080`0020301c 00000000`00000000 : hyperhv+0x22a10
ffffae8f`989aee98 fffff803`9c2b630f : 00000000`00000d82 00000080`0020301c 00000000`00000000 fffff803`a44761c3 : 0x407
ffffae8f`989aeea0 00000000`00000000 : 00000000`00001c20 00000000`00000001 00000000`00000002 00000000`00000000 : USBXHCI!Bulk_Stage_MapIntoRing+0x6df
```

[discord] <unrustled.jimmies> hyperhv+0x10343 is this, not sure why this would trigger an exception

```
180010343 32c0 xor al, al {0x0}
```

Actually looks like this is the problem, since this is the stack trace 10343 is the next addr to go to so i looked at 10342 and saw

```
1800102e7 if (!(uint32_t)sub_180009a40(*(uint32_t*)((char*)arg1 + 0x30), var_18, temp0))
1800102ec {
1800102fb int64_t var_20 = *(uint64_t*)((char*)arg1 + 0x40);
180010300 int32_t var_28 = 0x407;
18001030f void* const var_30 = "EptHandleEptViolation";
180010336 sub_180009780(3, 1, 1, 1, "[!] Error (%s:%d) | Err, unexpec…");
180010342 breakpoint();
```

Hi regarding spinlock_lock() functionality:
Even though I locked global variable on core 2 using spinlock_lock() , core 3 was able to print its value without it being unlocked using spinlock_unlock(). Why?

What is the running environment? Is it a baremetal machine or VMware workstation?

It seems that it's because of an unexpected EPT violation. But why EPT violation? Did you run any command like !monitor or !epthook?

I don't understand the logic behind this code. Adding _lock to a variable name doesn't have to do anything with locking it from modification by another core.

[discord] <unrustled.jimmies> [reply]: It could be my drivers, i use Logi with default windows usb drivers since i saw `USBXHCI!Bulk_Stage_MapIntoRing+0x6df` in the stack trace, then installed Logi+ Native drivers then the stack trace changed to `igdkmdn64+0x4447e1` then i updated intel drivers then it changed to `nvlddmkm+0xd710a3` kicking off the EPT violation. Unfortunately im on the latest nvidia drivers so.

Not sure why its kicking off ept violations since i didnt set anything up, i just did `.connect local` and `load vmm` and thats when it BSOD's. Computer is new as well.

[discord] <unrustled.jimmies> Running env is baremetal windows 11

@HughEverett do you build EPT pages for the whole physical address space? My random guess would be that those dirvers use MMIO which is remapped above the top of addressable dram memory and possible that area is not covered by your EPT

Can you try setting up bios settings to "Use above 4g decode - no and/or remap 4g - no" just to test this theory?

This is a bad advice for setting up your bios params, this is just for testing

[discord] <unrustled.jimmies> Yep, i can try that now.

Well, we build everything based on available MTRRs for the entire address space of MTRRs. Does the remapping change it at some point?

I mean, is it like that remapping causes to create something out of the range of MTRRs?

MTRRs don’t cover the whole physical address space, there is a def one, right? The regions that are not described on MTRRs just default to MTRR def MSR.

def one?

Default one

Something something DEF MSR, don’t remember the name now

You can point your MMIO BAR to almost anywhere on the physical address space. If there is no dram, it will just go to DMI decode

The only thing that limits it is a width of a physical address

Yes, you're right.

This is the entire MTRR logic of HyperDbg: https://github.com/HyperDbg/HyperDbg/blob/6a1da349effc8879770eadd14e928964d1257d81/hyperdbg/hyperhv/code/vmm/ept/Ept.c#L156

And since physical address space is sort of huge, you can save some memory for EPT tables using large or even huge EPT

Here is a very basic example of using a spinlock in a C code. The same concept applies to HyperDbg's script engine spinlock function (you need to use it like this.).

So, it's like you put a spinlock and lock it, another thread (or core) also needs to lock the spinlock and because it's already locked, the new thread couldn't lock it and it prevent the modification by two (or more) threads or cores.

https://rayanfam.com/topics/hypervisor-from-scratch-part-8/#whats-a-spinlock