@HughEverett Are there any known problems with hyperdbg for hyper-v.

The system blue screens upon startup, how can I resolve this?

win11 home

hyperv is not supported yet

Hi, nope. I spent a lot of time working on it but it's still problematic. Some of my previous works on supporting hyper-v is available at this branch:
https://github.com/HyperDbg/HyperDbg/tree/hypev-support

I believe the problem is because of EPT invalidation in case of hypercalls.

More information why hyper-v is so hard to deal with:
https://twitter.com/Intel80x86/status/1523033338407235585?t=DDg63jr2eZvWzDubqL_W_A&s=19

Hi, are you running hyperdbg on VMI Mode? Can you provide more information?

If I remember correctly, the last time I test it, it worked for ~1 min and then it crashed. Yet, I couldn't quite understand what was the cause of it.

Okay, thanks for the tip.

This tool can be used on AMD-V or its available only for INTEL VT-X ?

Hi,
At the moment, it only supports Intel processors (VT-x). But, there is another work in progress which is called RedDbg (It's a work in progress and not yet done).
https://github.com/HyperDbg/RedDbg

Is reddbg support hook?

It's a work in progress, and not yet in a working state. You can ask the main developer of RedDbg @Nitr0_G about it.

What do u guys use this for mainly?

Usually to bypass anti debug tricks

Completely off topic but are you guys using amd or intel for your virtualization-based tasks?

Only Intel for all the hypervisor related tasks

HyperDbg v0.7.2 is released.

You can find it on GitHub at:
https://github.com/HyperDbg/HyperDbg/releases/tag/v0.7.2

This is basically a minor fix of MTRRs which causes stability problems (and sometimes crashes at the beginning of HyperDbg load):

https://github.com/HyperDbg/HyperDbg/pull/329

Who is the maintainer of the GUI?
Can you accept this pull request?

https://github.com/HyperDbg/gui/pull/47

Hmm, it still crashes for me upon loading driver
.connect local
load vmm

It hangs and everything becomes unresponsive, I have to force shutdown

I'm not the maintainer of the GUI. The guy who works on GUI was in the Telegram group but it seems his account is deleted (probably due to the connection problem). But don't worry he will merge your PR once he sees it.

Can you please tell me about your system configuration? I mean what OS, and Intel processor generation do you use? Are you using it on a physical system or VMware Nested Virtualization machine?

Sorry for the late reply, here is the details you have requested:

Issue: HyperDbg causes entire system to become unresponsive after running the commands ".connect local"
"load vmm"

This issue was observed on a Physical System, below are the specifications of said system.

=========================================== msinfo32 System Summary ===========================================
OS Name Microsoft Windows 11 Home Single Language
Version 10.0.22621 Build 22621
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Name MSI
System Manufacturer Micro-Star International Co., Ltd.
System Model Katana 15 B13VGK
System Type x64-based PC
System SKU 1585.1
Processor 13th Gen Intel(R) Core(TM) i9-13900H, 2600 Mhz, 14 Core(s), 20 Logical Processor(s)
BIOS Version/Date American Megatrends International, LLC. E1585IMS.113, 26/10/2023
SMBIOS Version 3.5
Embedded Controller Version 255.255
BIOS Mode UEFI
BaseBoard Manufacturer Micro-Star International Co., Ltd.
BaseBoard Product MS-1585
BaseBoard Version REV:1.0
Platform Role Mobile
Secure Boot State Off
PCR7 Configuration Elevation Required to View
Windows Directory C:\Windows
System Directory C:\Windows\system32
Boot Device \Device\HarddiskVolume1
Locale United States
Hardware Abstraction Layer Version = "10.0.22621.2506"
User Name MSI\luist
Time Zone Malay Peninsula Standard Time
Installed Physical Memory (RAM) 32.0 GB
Total Physical Memory 31.7 GB
Available Physical Memory 27.4 GB
Total Virtual Memory 63.7 GB
Available Virtual Memory 58.2 GB
Page File Space 32.0 GB
Page File C:\pagefile.sys
Kernel DMA Protection On
Virtualization-based security Not enabled
Device Encryption Support Elevation Required to View
Hyper-V - VM Monitor Mode Extensions Yes
Hyper-V - Second Level Address Translation Extensions Yes
Hyper-V - Virtualization Enabled in Firmware Yes
Hyper-V - Data Execution Protection Yes

=========================================== GPU ===========================================
Name NVIDIA GeForce RTX 4070 Laptop GPU

Thank you. I provided the details to the GitHub issue to see if anyone could help us finding the problem. I don't have a 13th gen Intel processor right now, but will test it soon. This problem is reported several times for 13th gen processors.

https://github.com/HyperDbg/HyperDbg/issues/323#issuecomment-1907459487

Also, if you can find any other information, maybe a BSOD log crash. That would be super helpful.

Aite I ll try

I ll just kernel debug my laptop with another one and generate a dump

Hello, I wanted to ask if there's any plans to support physical addresses for the monitor command? I'd like to monitor bar reads (memory bars) or is there another way to do it?

PCIe base address registers, there's two types of them memory bars and I/O bars

Basically I'd like to do the same thing as mmiotrace in linux

This is probably where you need to modify.

https://github.com/HyperDbg/HyperDbg/blob/429f2786af72e33ea5c4920a7ba7615a913a523b/hyperdbg/hprdbghv/code/hooks/ept-hook/EptHook.c#L182

Search for :

PhysicalBaseAddress = (SIZE_T)VirtualAddressToPhysicalAddressByProcessCr3(VirtualTarget, ProcessCr3);

Thanks I will take a look at it tomorrow (about to sleep)

It's applied starting from this function:

https://github.com/HyperDbg/HyperDbg/blob/429f2786af72e33ea5c4920a7ba7615a913a523b/hyperdbg/hprdbgkd/code/debugger/events/DebuggerEvents.c#L72

@HughEverett

Is this written incorrectly? This "j" doesn't serve any purpose

I see others writing like this

Yeah, you're right. I didn't notice that. Since it's not written by me, let's inform Mattiwatti on GitHub.

This is probably the reason why many systems explode

Probably 🤔

What other parts do you see? I can only find this one.

This one

Please keep sending me if you find other variants of these bugs.

Alright

this,is ok

this,is not ok

why?

Hi,
This is due to a problem with initializing MTRRs which mainly affects 13 gen processors. (Please read the previous 20 messages of the group, we discussed about that).

Once it's fixed (hopefully tomorrow), I will let you (and others) know to test it to see whether the patch was effective or not.

thank you,very much

Is there a solution?

Yes, but it's not yet applied.

I made a new small commit to the 'dev' branch. Can you please re-check it on your 13th gen machines and tell me whether the problem is fixed or not?

@dkwow666 @Fall_0004

If you can't build HyperDbg, you can also use github built artifacts :
https://github.com/HyperDbg/HyperDbg/actions/runs/7677365725

Additionally, there's a recently introduced event command in HyperDbg that hasn't been tested or documented yet, so it's a potential new feature.

Please Feel free to explore this event command in the latest 'dev' branch, and share your feedback here:

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

hiya, I believe I've finally managed to join telegram after trying five different phones...

I saw your commit but it actually still contains a mistake when incorporating the loop index variables

I've been working on a (private, messy....) branch to log the MTRR map in a way that is as similar to windbg's !mtrr as possible

and it still shows differences in 16 fixed MTRRs between your new commit and windbg on my 13th gen machine (it works fine though - no hang)

the proper loop logic should be
Descriptor->MemoryType = K16Types.s.Types[j];
Descriptor->PhysicalBaseAddress = (K16Base + (i * K16Size * 8)) + (K16Size * j);
Descriptor->PhysicalEndAddress = (K16Base + (i * K16Size * 8)) + (K16Size * j) + (K16Size - 1);
- at least on my machine the MTRRs logged now match windbg's output

I haven't been able to reproduce any more hangs after my original PR though, so unfortunately I can't say if this is enough to fix hangs others were seeing

I'm almost certain the way the SMRR ('SMRAM range MTRR') is being treated is also incorrect, because this is a variable MTRR that pretends to be of type write-back, but actually it is of course not possible to access SMRAM outside SMM

the documented behaviour is that writes will #GP, and reads will actually have type UC and return garbage

so it certainly seems like a mistake to me to treat it as actual write-back cacheable memory the way hyperdbg is doing it now (windbg agrees - it does not show the SMRR as MTRR)
but I'm less certain of what the best way to deal with this would be

Well um… I dont just hang now, I straight up BSOD

Huh wait nvm

It works now

Wow, that's great. Welcome!

heh, thank you

I'm mostly around on discord rather than telegram usually

but it seems to work fine now after getting past the activation hurdle

Can you send a PR for it?

Is it the second loop?

sure

give me a few

it's the same loop you changed in your commit

both i and j need to be taken into account when calculating the base and end addresses

So, no change is needed ?

no, your fix commit is incorrect

or incomplete, rather

ah, so please fix it in a PR

done

I'm still considering what to do about the SMRR 'MTRR'...

to be perfectly honest, I think if the entire block of code that queries the SMRR and stores it as a memory range as (if it's from an MTRR) was simply deleted
that this would fix more than it could hurt

but I'm also wondering what the worst case scenario could be (if any) where someone needs to call EptGetMemoryType() on an address that's in SMRAM for some reason

SMRAM is not accessible outside of SMM cpu mode, so no need to worry about this region at all

as far as I can tell this is something that wouldn't normally ever happen in hyperdbg - neither memory allocations nor physical addresses converted from elsewhere should have any reason to be SMM data/code

yeah, exactly

There are plenty of regions inaccessible for CPU, just forget about them

alright, well if you want I can make a PR for this too (or add it to the one I just made).... I'll need a bit more time though to actually make the change and verify it's working/correct

the other fix I had already made :D

One thing that I encounter recently (like after 10 times of reloading HyperDbg) was this

Dude, just farm these as 0days, don't post em here ))

I'm just suspect whether it relates to MTRR stuff or not? 🤔

It's vmware core issue

I've got tens of these issue each day, just don't know how to reproduce them deterministically 😅

Oh :)

good question, I can try some more spam loading in vmware as well if you want - I've mainly been focused on making physical machines not hang since that was the original issue

Ah, yes, that would be great. I try to test it on my physical machine as well.

but that still hasn't reoccurred for me, so I suspect there must be some hardware configuration difference between me and the person who still saw a hang after the original PR

Are you testing it on VMware?

Or physical machine?

physical

the hang never occurred for me in vmware, even before I made any changes

(although I only discovered that later... not a huge vmware fan)

It happens to me in like each 5 or 10 tests. I will try the physical machine now.

Do you guys collect machine check info? It's likely to happen in such scenarios

Machine check for VMware?

For physical machines

no, I do collect crash dumps (or use windbg if attached), but not sure where I'd find the machine check info

the event log?

I didn't see any errors on physical yet. Still didn't perform a lot of tests.

so I'm gonna make some tests now

A set of registers

and hopefully release v0.8 tonight along with this new !mode command.

Wait, sorry to ask, but do you set up MTRRs on the machine on your own? I missed that part

oh yeah... I do vaguely recall their existence but no, as you can tell I don't check these heh

Do you actually touch host mtrrs?

you mean whether I change or add any MTRRs apart from the default configuration when booted into windows?

no

Oh, ok, cool

You should not ever do that )

Is there any way to change MTRRs?

🤨

Sure, a set of msrs

yes, from what I saw in the SDM it's very painful

As long as I know those registers are not modifiable

unless you're on 1 CPU

But don’t do that

They are, why not

Don’t recall any lock bits

Interesting, didn't know that.

They’re set up in firmware and then mirrored on each ap startup, also in firmware

So the firmware knows better

yeah, I also noticed NT does not touch them

There’s just no need, sure

You’ve got PATs if you need

or tries not to.... I expect there are probably some obscure hacks for broken hardware.... but in the normal case

PATs are set up in page tables

yeah - I don't touch those either, FWIW

One of my biggest flaws in pulsedbg architecture is exactly caching. Don’t even know if I’m going to fix them

the only reason I ran into this bug was because I was helping someone in the reverse engineering discord who was (based on someone else's suggestion there) trying to set up hyperdbg to monitor port I/O

I'd never used hyperdbg before that actually

but his machine was hanging in such a bizarre way that I decided to dust off an intel CPU to try to reproduce it

Initially I would just set EPT caching according to MTRRs, but then there are cases when ordinary dram needs to be accessed as WC or even UC when shared with GPU

and it did, but it turns out that was simple 'luck' due to both being 13th gens...? at least, that's where the issues seem to be so far

Now what do you think of it? I mean will you use it again? Any feedback or suggestion? Or improvements?

it seems to work fine, other than some odd issues I sometimes run into when connecting (again to a physical machine) via serial that I haven't yet investigated

so, I'll use it again, as soon as there's AMD support ;)

Yes, it's discussed several times. The physical connection should be changed into a kdnet style connection.

rather than slow serial

😅😅

oh hi @Mattiwatti (It's suic from discord)

I haven't looked into the scripting extensively, but the possibilities for these when using monitor/epthook/!io[in|out] seem really neat

hey hey!

Yes, HyperDbg also has a short-circuiting capability that makes it even better.
https://docs.hyperdbg.org/tips-and-tricks/misc/event-short-circuiting

and event calling stages:
https://docs.hyperdbg.org/tips-and-tricks/misc/event-calling-stage

yep - I've read most of the docs by now, just haven't had time to try everything yet

I know this sounds cheeky by the way, but I have to be honest - I simply don't really have a use for a debugger that only works on intels

given that I tend to buy AMDs for my workstations

I saw there was a separate repo in the works with AMD support, but I haven't looked at it yet

There is also another project 'RedDbg' which is mainly designed for AMD that @Nitr0_G is working on it, but agree. The support for AMD is also necessary.

is there a reason it's a separate repository and not e.g. a branch that can occasionally be used to merge shared features when they are finished?

I never had an AMD laptop but it seems that at some point I have to buy and test it too.

It's not yet finished.

It's a work in progress.

no, I understand that
but neither is hyperdbg itself, right?

the branch would not need to be released necessarily

The work is going on. I'm redoing the architecture a bit now.

it would only be to avoid having very divergent code bases eventually when one or the other is 'done'

Yeah, we kind of discussed it. But it seems that we decided to solve this problem when RedDbg is relatively ready and if something is, then I can rewrite something.

Exactly

OK, I see

what steps are you following exactly when you are doing this?
just to make sure I'm actually attempting the same thing that generates this error for you

I did get a crash on the very first .debug close just now, but that was a user mode crash in hyperdbg-cli.exe, not a VMware crash

I'm just loading HyperDbg :

On the host:

.debug remote namedpipe \\.\pipe\HyperDbgPipe

On the guest:
.debug prepare serial 115200 com2

but probably, the same error happens on

.connect local
load vmm

without any need to host interaction.

my UM crash by the way - a stack overflow due to recursion in ShowMessages?

OK, this is what I did

This is probably some other issues! ^_^

yeah

I just try to restore the VM

and test it again and again

I mean snapshot

the only difference I see is that my VM's serial port is just COM1 - any particular reason why yours is COM2? is there another port already at this address in your VM?

or did you assign it yourself - that's possible too of course

Yes, but that's probably unrelated to the issue 🤔

I think so too,, but just wondering

since I saw the same 'com2' example in the documentation

and I'm hardly a vmware expert, so...

I just suspect maybe my VMware version is older than the latest release

So, maybe it's just me that encounter this issue

oh, yeah we are using quite different versions

mine is 17.5.0

Ah, and can you create an snapshot from your VM and then try to load HyperDbg multiple times?

I'm just gonna see whether it crashes on your machine or not.

a live snapshot you mean? with the host already waiting for the debugger to connect?

and then retry that

I mean a simple snapshot that restores the system to a state where HyperDbg is not loaded

The crash happens immediately after you load HyperDbg.

yes, but a live snapshot right? (I mean I guess it has to be, if the machine isn't on hyperdbg can hardly be loaded heh)

yes

just clarifying the purpose, I guess

roger

4 attempts in so far - this does not seem to happen for me

i.e. loading the vmm works

the user mode crash after .debug close does reproduce every time though

that has to be something simple/silly though

It doesn't crash for me, but yes it should be something silly

there's no issue with loading the VMM itself

So, we're probably good to release v0.8

to fix 13th gen loading problem as well as the !mode command.

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

well, if you mean literally right now, - I still need to make a commit to remove the 'SMRR is an MTRR' logic 😅

I was testing for issues in vmware thus far

Ah, that's okay

as long as it doesn't cause loading issue.

yes, exactly

I do need to actually test that heh

We could fix it on next versions

right now, we need to make sure that HyperDbg loads on 13th gen machine, which it seems to be fine

I also made a couple of tests on my 12 gen machine and it seems to be fine

well, I've removed the SMRR logic before and had no issues on 13th gen

so I'm pretty confident it will be fine

but I still need to make the correct change on top of the current dev branch, without any unrelated stuff in it, and then test it to verify

So, please create PR once everything was fine with that. I'll go for v0.8 now and later once the next PR is ready we could release v0.8.1

OK, well that's up to you of course - but this should take me less than half an hour

but either is fine by me

If it's less than an hour then it's pretty fine

go for it

we'll release it once you finished it

🫡😎

OK, I've tested the change and load vmm works on my 13th gen, both physically and in vmware

Great

question - what do you want me to put in the PR? I saw that you made a revert commit in dev

that also reverts the indexing PR I made earlier

I can make a new PR that includes both commits?

yes, go for it

alright

on it

PR made

👍

HyperDbg v0.8 is released!

# [0.8.0.0] - 2024-01-28
New release of the HyperDbg Debugger thanks to @Mattiwatti.

# Changed
- Fix miscalculating MTRRs in 13th gen processors

# Added
- The !mode event command is added to detect kernel-to-user and user-to-kernel transitions
https://docs.hyperdbg.org/commands/extension-commands/mode

- The 'preactivate' command is added to support initializing special functionalities in the Debugger Mode
https://docs.hyperdbg.org/commands/debugging-commands/preactivate

If the overlapping regions (UC, MT, and MB) are correctly handled during the MTRR initialization, and regions of the same type are merged, it would enhance the speed of the GetMemoryType function and also prevent unnecessary large page splits in certain scenarios. Of course, this is a suggestion related to optimization and is optional.

yes, very true

I'm not at all familiar with memory caching related stuff really, I was mainly focusing on getting my machine to no longer hang and even that was quite enough work

and I don't think we've heard back re: the latest changes from the person who still saw this issue on their machine, even though it was fixed on mine/ours?

would be nice to know if there was a difference at all

nice work

@Mattiwatti Are you sure you want to delete this code? My product has been running on many machines without any issues

Well the code you quoted does two things, so I'll answer in two parts:

1. It queries the SMRR if we know one has been configured. This part is totally fine by me (though I do question its value in HyperDbg somewhat). Only one comment: at the very least this query should be using the appropriate SMRR types (IA32_SMRR_PHYSBASE_REGISTER/IA32_SMRR_PHYSMASK_REGISTER) instead of repurposing MTRR types used throughout the rest of the function. The SMRR is not an MTRR.

2. It stores the result of the SMRR query in MemoryRanges of the global EPT state. This part I believe is absolutely wrong, again for the reason that the SMRR is not actually a variable range MTRR at all. (Unfortunately the SDM does a good job of making it look like one, by describing it in the same section and giving it identical structures).

The SMRR can only be treated as an MTRR by SMM code, since that is the only code that can access this region. For non-SMM code like HyperDbg, the main purpose of the SMRR might be the ability to query the SMRAM base and size, since this region cannot be read from or written to, let alone cached. The memory type in particular is problematic: the entire region is treated as uncacheable outside of SMM, which is very different from the value of 'write-back' the MSR reports on my machine.

What problems does (2) cause? Well in short, EptGetMemoryType() will return an incorrect memory type for any address that happens to be inside the SMRAM range. How bad is this really? Honestly I have no idea. I doubt it is really problematic, since HyperDbg itself has no way or need (even by acccident) to ever try to use a physical address from SMRAM for e.g. allocations or hooks. *But*, I did place a debug log statement in the function to verify this, and (on my machine) there were definitely 20 or so calls to EptGetMemoryType() for PAs in the SMRAM range. I don't know who was querying these or why, but the memory type returned simply must have been incorrect in these cases.

So in short: yes, I'm sure. I believe this code was not doing anything useful in the best case scenario, and subtly causing HyperDbg to assume the wrong caching type in other places in the worst case scenario.

With the above said, I'm not quite as sure that simply ignoring the SMRR is the best way to deal with it, but I do think it probably is. I tried for quite some time to come up with a reason for HyperDbg to need to know this information, but failed.

But if there exists some scenario I didn't think of where it would be useful or necessary for HyperDbg to know the SMRAM range, then by all means bring back the query! I won't oppose. However, the result should not be stored in MemoryRanges as if it were an MTRR. Rather, it should be given a separate variable with its name and type indicating that it describes the SMRR and not an MTRR. Secondly, if this variable is used in EptGetMemoryType(), it should be to return a value of uncacheable immediately (even if there are overlapping MTRRs for the address), and not whatever value was reported by the MSR as the memory type to be used by SMM code.

Omg, leave SMM related stuff alone. It is not needed and not used. Do you have dual monitor treatment? No.

I guess that is a more succinct and to the point version of what I was more or less trying to say 😅

:)

Question:

For the '!monitor' command in HyperDbg, let's consider monitoring addresses within the range where the start address is 0x12345000 and the end address is 0x12346000.

Do you prefer the last address (0x12346000) to be hooked, or do you expect HyperDbg to hook only from 0x12345000 to 0x12345fff but not 0x12346000?

✅ I anticipate the last byte to be hooked or in other words: [start address, end address].

✅ I do not expect the last address to be hooked or in other words: [start address, end address).

Do you prefer the last address (0x12346000) to be hooked, or do you expect HyperDbg to hook only from 0x12345000 to 0x12345fff but not 0x12346000?
anonymous poll

I anticipate the last byte to be hooked or in other words: [start address, end address]. – 5
👍👍👍👍👍👍👍 83%

I do not expect the last address to be hooked or in other words: [start address, end address). – 1
👍 17%

👥 6 people voted so far.

Would it be more accurate to name them as follows?🧐
[Base, Limit]
[Base, End)

Yes, exactly. I added the same terms [start address, end address] and [start address, end address).

@HughEverett

This position cannot be used to determine whether VT is enabled. I tested it on a computer with VT enabled

The value of this one is 0

The original method is more accurate

What do you mean by the original method? 🤔

This lock bit, which indicates whether VMX is locked or not. Honestly, get what you mean. How is it related to check whether VT is enabled or not?

Of course, if it's locked, then VT is not enabled but this bit doesn't necessarily mean that VT is enabled if it's not locked.