💪

The only thing I need to try is what happens if we write to the buffer after putting the monitor command

moving the memcpy after the pause

to look if it stops when write

You have to specify both 'x' and 'w' for this purpose.

!monitor xw AddrFrom AddrTo script { ... }

nop

i want to test if putting only x skip when writing

why this happen

the address is allocated

is no paged?

not paged

but was allocated two lines after

seems to be not paged

when you resolve the page in problem i will continue

ping me when you finish to test

it bypass all the w writes and it stops only by execution

perfect

its ok

You can check whether it's paged or not by using '!pte' or '!va2pa' command.

Sure.

Yes but I put two memcpys

👍

One after the break and another before

And the memory is paged when the first write happen

And skips the second write and stops only by execution

It's ok

So, the 'db' is still problematic?

It works as expected

Nop

👍

I bypass the page in problem repeating the memcpys

But when the page in is finished will be awesome

Even when I add the '.pagein' command, we still need another command to spin (halt) the target process.

I have some ideas for this as well.

Yes but I change the program code to circumvent this

This is a nasty trick

And this command is needed because of the fundamental design issue of not applying events immediately.

😅

Ping me to test when finish

Thanks for your hard work

Thanks for putting time testing it. 🙏

@HughEverett Hey, could I sponsor you a motherboard with a COM port? :D

I'm still completely lost on this issue

Issue is somewhere in ReadIrpBasedBuffer, that's the furthest I can get by checking the debugee process

since I can't attach a debugger to it

or whole system freezes

also confirmed not working on last dev branch commit

Regarding COM port issue:

- Fails at first packet:
Checksum mismatch

0x84 SENT FROM DEBUGEE
0x54 CALCULATED ON DEBUGGER

Aha, okay. That should be the problem. I'm not that much familiar with serial programming, but do we need to implement a handshaking mechanism for the packets? I mean is it common these days that some packets fail to be received due to the physical problems?

I have to order a PCIe serial card to test it.

helllo

i tried with

and it works too, there is not difference between the option the other end is an application or the other end is a VM

it works

Also, I worked on the '.pagein' today. But, I think I have to read Intel manual (SDM) to figure out some of the Error Codes that are valid for #PFs. So, I need more time to finish the '.pagein' command as it's a little bit tricky.

another thing

the x option in monitor

works too without the script

and stops in the first line executed

after it stops I disable the event

press G and it continues

another thing i detect

One thing that I realized is that if the target is waiting for a console entry in the same CMD of the hyperdbg, if you do ctrl -C and you want to change the context it doesn't work, you do .process pid xxx and G and it doesn't return because the CMD remains waiting for the entry of a key of that program

pressing a key in CMD it returns the control to hyperdbg and it switchs the context

but wait for a program target console input to complete the switch is not cool

maybe hyperdbg can force a new cmd not execute inside the same cmd

This is a really hard to fix issue. Because, how we can detect it's execution? Windows just won't context switch to the process that is waiting.

Can explain it more?

if the target is in a different cmd than hyperdbg is the same?

if the target process runs in a new CMD outside the hyperdbg CMD

oh, yes, I got what you mean.

You mean HyperDbg just creates the process inside HyperDbg-cli.exe

is the execution in the same CMD affecting or will be the same

Yes, I noticed it too.

No, the execution is different.

Let me see, if I can fix it right now.

maybe i can try executing with start path "cmd /c path"

No, need that. Wait a minute, I'll fix it now.

i'm annoying

No, of course not.

These things are easily solvable as all of them are Windows APIs

I have to figure out the flag that needs to be passed to the CreateProcess()

the thing is if will be different we'll see

but i think will be better in other new process outside hyperdbg cmd

Fixed! Please 'pull' the last commit from the 'dev' branch.

the fix is in the driver or in the rest of the files?

change the other files is easier

the driver is running

No, it's a Win API fix. I just added CREATE_NEW_CONSOLE to the CreateProcessW's dwCreationFlags .

in hyperdbg-cli.exe?

No, in hyperdbg/hprdbgctrl/code/debugger/user-level/ud.cpp

i smash the existing folder with the new folder and the affected file will be replaced

it's cleaner now

it works thanks

another thing

the * does not work in the name of the module

hehehe

if the module has a long name

sometimes is confortable to use * in the name too

yes, it's not supported yet 🫣

this is very strange

No, of course not. Keep sending me feedbacks. 😎😎😎

how the symbol can be found and i cannot put a bp in it

this does not happen in windbg never happen to me

What is the address?

u user32!MessageBoxA

isn't it available?

or

print user32!MessageBoxA

Is it paged out?

a api used by any process paged out?

no, that shouldn't happen.

Okay, maybe HyperDbg is loading the wrong base address?

can you verify whether the current process contains the user32 module? and get its address using 'lm um pid 1234'

its a bug

Maybe reloading symbols? .sym reload?

a messagebox is displaying at this moment

cannot be paged out

.sym download

.sym reload

When did you use this command? Immediately after running it?

Oops, something went wrong. Crashed. You need to restart that.

its blocked now

no probelm i have the snapshot of the host and target previous to connect all configured

Please make sure that once you access the 'user32!MessageBoxA', the address is loaded in the target module. Because I suspect (maybe) Windows didn't load that DLL into the process if you immediately access it.

But, if you run it and it showed 'Hello World!' then after that, it should be present.

in the entry point

i can redownload the symbols

and reload again

for avoid changes when switching

Let me check it with x64dbg.

Are you trying to access the user32!MessageBoxA at the entrypoint?

yes but now i will run till messagebox appears

i break

switch context

the messagebox is displaying now

i'm in the context of the process and messagebox are displaying now

So, is it still incorrect?

yes

albeit messagebox is displaying

cannot be put a bp in mesagebox

i'm in the context

Can you read the modules list?

lm um pid 1234

I check the x64dbg and it seems Windows didn't change this yet. All process's user32 are mapped in the same address.

Ops, did you get it?

It interprets it as x64 bit.

While it's 32 bit.

yes but i think bp is taking the 64 bits module

yes

Nice catch, thanks a lot for finding it.

This is a really hidden error, I've never think of it.

And it should be fixed immediately.

sometimes is useful to be annoying hehehe

You're always helpful.

So, we can conclude that HyperDbg interprets user32 as a x64-bit module in a 32-bit module.

yes

Let me create an issue for it in the GitHub.

in a wow64 process it needs take the symbols different

but redownloading the symbols does not fix it

Yes, that needs a fix from the code.

As I never reached to this error.

This was buried deep in the codes of HyperDbg,

maybe an x32 alternative to x

to catch the symbols in wow64 mode

no, we could easily manage that with the same x command.

The should not be a hard to solve problem.

it can be detected if a process is a wow64 make this

yes

for x and bp

and some other commands

exactly

some flag

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

👍

path is system32

this path only have 64 bits modules

it should be wow64. I'll add that to the issue too.

the imagebase and final address are correct

TypeOfThePacket DEBUGGER_REMOTE_PACKET_TYPE_DEBUGGEE_TO_DEBUGGER
RequestedActionOfThepacket DEBUGGER_REMOTE_PACKET_REQUESTED_ACTION_ON_USER_MODE_PAUSE

also, you need a motherboard with a com serial port

a virtual (pcie) serial port will not work

^ this is the first packet that debugger receives

No, why motherboard? Once I buy a PCI-e serial card, it should be fine.

that requires so much more work though

since you can't natively send to i/o ports

i asked about this already once

🤨🤨🤨

you'd need to write a efi dxe driver, replace/install acpi dbg and dbg2 tables, etc

to even somewhat make this work

and this hasn't been done publicly before

You mean, something like this, isn't enough?
https://www.aliexpress.com/item/1005005154188493.html

not for debugging purposes

I thought that I can use this PCIe device to connect it to PCI and then use the same HyperDbg functionalities to send data out.

why? 🤔

welp, theoretically you can until there's a bp :)

I can use the kdnet windbg to handle breakpoints in HyperDbg.

In HyperDbg we pass the breakpoint to the same HOST_IDT of the Windows for the debugging of it.

That's why it's possible to intercept breakpoints in VMX-root mode using WinDbg. But, intercepting breakpoints in VMX non-root mode, needs additional considerations in HyperDbg. (e.g., avoid intercepting #BPs in exception bitmap VMCS)

the point, if i understood it correctly, is that with a pcie device you won't be able to send i/o to the guest during a system bp

Why? you mean that IN/OUT instructions on COM ports won't lead to sending/receiving data?

Is it handled through Memory Mapped I/O (MMIO)?

I don't know, that's what I've been told by people who tried/looked into it.

I'll gladly sponsor you a motherboard though

No need. I try to buy one.

But let's ask people to make sure what happens to the serial card.

We could support PCIe serial cards too.

If these cards are supporting only MMIO (not PMIO).

I think going through the PCIe internals would be fun.

hello

Is the bug fix and the page in feature progressing?

Hi, yes, it's almsot done. I will finish it tomorrow. Here's the help of this command:

I intercepted all the page-fault exceptions on the system to find the valid error codes (page-fault code.). I believe the default behavior of this command (without parameter) should be injecting with the 'p' or present bit set, which indicates that some instructions try to read the target address and user can also change this behavior to 'w' (write) or 'f' (fetch) or 'u' (user access) or a combination of these page-fault codes.

However, one thing that is interesting for me and still unsolved is why sometimes the error code for the page-fault is zero? I couldn't find the reason what happens that lead to a page-fault with error code equal to zero. 🤔

The page in command is for the complete section of the address?

Or can be greater than 0x1000

Do you mean that we should add a range for it?

By example pagen 401000 408000

Maybe if a range can be added

Will be awesome for unpacking

If a complete section is not paged

And you need use the monitor command in the same range

First you can page in a range and next monitor the same range

So, I'll add a 'size' argument to this command.

But, we have to make sure that a range of memory will need several page-faults to be delivered.

And the bug of the 32 bits symbols?

No, I still didn't work on that. Once the page-fault injection command is finished, I will get to that.

@HughEverett For the time-based attack evasion, do you also account for instructions that might be between the rdtsc & cpuid instructions?

any special instruction? or regular instructions?

both

entering fpu, avx/sse context switches..

or just regular instructions

I don't remember it, let me see.

as long as I see it in the source code, I think it can also bypass regular instructions but not sure about fpu, avx/sse instructions. 🤔

I'll give it a quick check

I didn't test this mechanism for years. It might cause instabilities on your system.

But, feel free to add new features and possible new detections to the transparent-mode. It's still one of the places in HyperDbg that needs lots of contributions.

looks good, but cpuid in between catches it

left is without hide right is with

long long a = __rdtsc();
_mm_lfence();
for (size_t i = 0; i != 64; i++)
{
__asm
{
addps xmm1, xmm0
addps xmm2, xmm1
addps xmm3, xmm2
addps xmm0, xmm3
cpuid
addps xmm1, xmm0
addps xmm2, xmm1
addps xmm3, xmm2
addps xmm0, xmm3
}
}
long long b = __rdtsc();
_mm_lfence();

ran 1024 times, b - a stored

Is it working now?

The overall logic behind it is very simple. It can be manipulated here:
https://github.com/HyperDbg/HyperDbg/blob/a571781e8651998b982a9f53edf8f3d3501a6b2e/hyperdbg/hprdbghv/code/transparency/Transparency.c

@ricnar Do you have any idea how we can implement this '.pagein' command for the VMI mode?

The problem here is, we never context switched to a new process in the VMI Mode. I'm sure we have to manage it with something like APC but, I'm not sure if that's a good idea. Because APCs are in APC_LEVEL IRQL which might cause problem for delivering the page-faults. 🤔

my ideas are dirty jeje reading or writing to the address but storing the orginal content to restore

reading is easier storing the original value of the register where the value is readed

this will trigger the exception

and i think will be paged

is a little hack

dirty

Probably, we need to be in the context of the target process. Because otherwise, we might break the operating system semantics. Writing on the other process means that we forced the cr3 to change to the target process and meanwhile, injecting #PF is wrong. Because, once the OS wants to handle the page-fault, it realizes that the current process details don't match with cr3 and probably lead to a BSOD.

i didnt't try the user mode mode but in normal user mode debuggers non paged does not happen

i think hyperdbg is different than a normal user mode debugger

Yes, in user-mode debugger it's handled transparently by the operating system. But as we're in halt the operating system in the hypervisor-level, we have to consider paging.

I see

I don't know how to do

I'm gonna test attaching to the target process stack.

To see what happens.

When I use your start command in kernel debugging when I reach the entry point are in the same context

yes.

In this moment read or write is possibly

That's why !pte or !va2pa won't support the 'pid' argument.

Context is necessary

And telling the user is necessary switch context first?

And the command only can be used in the same context?

I'm thinking about intercepting the clock-interrupt in the target process, and once we're in the context of target process, we could inject it.

But, the thing about this method is, we're not sure whether the context of the process once we intercept it, is in the kernel-mode or the user-mode. So, it's like the user tries to inject a page-fault from the kernel-mode but the context of the process is in the user-mode. Thus, Windows interprets it as an attempt to read a kernel address from a user-mode process and delivers an exception to the SEH handler of the process which might lead to crashing the target process.

Ah

Very difficult

@ricnar would you please send your packed file again?

I'm gonna test the .pagein now.

And also, send the expected address to bring it in.

i don't remember if is this

i have a lot

💪💪👌

Do you have any idea about the expected address? I remember you told me you knew the section address which was an static address. 🧐

the second line from the entry point

has the finalization of the cod esection

code setion

it will change by aslr but you can grab from this line

So, you mean the address that is expected to be paged-in is 408000?

Oh, yes

no

I'll do that now.

this is the end of the section

it start 0x7000 before

the address will be the grabbed from this line -0x7000

minus 0x7000

-0x7000 from entrypoint?

without randomization is 0x401000 till 0x408000

this will be the code section without aslr

Okay, so I can run it until the entrypoint.

And fine the .text address with ASLR

you can grab the end from the second line

substract 0x7000

and you will have the start and end of the section

Subtract 0x7000 from what?

this is the second line with aslr when running

A28000 is the end of the code section

the start will be A28000-0x7000

So, HyperDbg is supposed to make A28000-0x7000 available?

yes

is the code section

Okay, let me test it now.

is not paged but is part of the sections of the excutable

the packer will write the unpacked code in this section

and jump to the OEP the real entry point of unpacked in this section

is monitor whit x option is enabled in this section, it should stop here

the first line executed

okay, it seems that it works in this case. Am I do it right @ricnar ?

yes

you can test if you can page in all the rangle

range

228000-7000 till 228000

page in all this range

and put a monitor command x

in all this range to look if stops in the same line i show you the real OEP

okay, it's a really good test-case. I didn't implement the range page-in yet.

perfect

but, just for one page, it works now.

yes

but you can appreciate here the value of the pagein in a range

the importance

The only thing that remain unsolved is :
1. Finding a way to run this command in VMI Mode
2. Implement the range page-in

perfect

Yes, I'll do that. But it needs some extra considerations. Like, some pages are allocated with 3-level of paging (big page) with 2 MB granularity. I have to make sure whether the target range is within a 4 KB page or a 2 MB page to avoid injecting page-faults to a single page multiple times. Which will cause a crash in the target process if we didn't truly respect the page granularity as one single page might receive page-faults multiple times.

I'll push the current version to the github and will continue working on it tomorrow.

i think jumping 0x1000 bytes ahead in a cycle and repeting the pagein can work

yes, but having a range is a better way of handling it 😌

yes ciclying inside the range adding 0x1000 to the original address if is located inside the range pagein and repeat if not exit and so on

exactly

@ricnar There is a technical difficulty here in supporting a range in the '.pagein' command that my previous assumption might not work for that. Generally, what we do now, is injecting a #PF in the target guest and set a trap flag in the target process. Then, we ask the user, to press the 'g' which will continue the debugger and once the target debgee continues, the page-fault is delivered to the process and Windows page-fault handler will manage it. Now, how we can halt the debuggee in the target process again? The answer is as we set the RFLAG's TRAP FLAG, the same process (and same thread) will throw a debug break (#DB) and we intercept the target thread again while one instruction is executed there. This approach is totally fine and works perfectly.

But the problem is once, we want to specify a range, we have to either start submitting our requests in a loop and each time run one instruction (because of the trap flag), and bring one page in. This is completely possible, but it's an ugly way of handling issues. Because, once the debuggee is halted again, the target program might be executed several instructions (as the result of the trap flag) and I think it's considered a weird behavior in a debugger.

Previously, my assumption was utilizing the interrupt window exiting in the VMCS, injecting several page faults all at once, and each of them is delivered to the debuggee once the interrupt window is open. This way, we could inject all of the page faults while only one instruction will be executed in the target. But, unfortunately, based on my current tests this approach is proved to be problematic in some cases.

For example, we might inject a #pf once the interrupt window is open but it's not guaranteed that the operating system won't context switch while it's handling an interrupt. So, once the #PF is handled in the OS, the interrupt window is open and we might land on a different process as the OS has already context-switched to another process.

Someone might think that is why we have to use trap flags. Because what other things to use? If for example, we use a breakpoint (0xcc) on the current instruction to avoid running a single instruction, then it's still not a good idea. Why? Because the user might (and will) inject a page-fault while it's operating at a shared Windows library. For instance, assume if the user is in the 'kernel32.dll' and wants to inject a page-fault. If we set a 0xcc on the current instruction of the thread. Other threads from other processes might trigger the breakpoint as the libraries are using the same physical address.

Thus, I believe it's better not to support the range for the '.pagein' command for now because this way the user understands that by injecting one page-fault, one instruction will be executed in the target debuggee. If you guys have any other ideas, please let me know so we can investigate the possible solutions.

I see

I'm done with testing it. The '.pagein' command is now ready to be used.

Btw, make sure to use the 'u2' command, instead of the 'u' because it's 32-bit target.

The 32 bits problem is solved?

not yet. I'm working on that right now.

I will try thanks

today i'm busy at work, tomorrow i will try

Here's the documentation page for the '.pagein' command:
https://docs.hyperdbg.org/commands/meta-commands/.pagein

👍

I have an idea

What would happen if, for example, you have to make a pagein of 5000 bytes and you make an allocation of that same size and then a reps movs to read the area to be paged and copy it there

Copying all the block in one only instruction

How the system resolves this case?

I didn't get the idea but generally there is no way to allocate memory while HyperDbg is operating at the VMX root-mode. Because, the API functions that we need to call have to be HIGH_IRQL compatible, which none of the memory functions of Windows are designed for this purpose.

That's why HyperDbg uses it's own pool manager for VMX root-mode.
https://github.com/HyperDbg/HyperDbg/blob/master/hyperdbg/hprdbghv/code/memory/PoolManager.c

But, it would be best if you can clarify it a little bit. 🤔

Using in a reps movs instruction with the non paged region as source and any temporal buffer as destination

Using all the region to be paged in one instruction

is only a non important idea

something extrange happen with the monitor command

this version of the packed program has the ASLR disabled to explain better

using IDA and putting a breakpoint on execution from 401000 to 408000 it stops in the OEP here

the first line executed in this section

but using hyperdbg

using page in in the block 0x401000 to 0x401fff

and using a monitor command in this range

it skips the ope in 40146e and stops later

in another function

can the page in command in the same block affect the monitor command?

Yes, I also thought about this, but the thing is which region? We have to allocate something in the target process. Am I right? So, it's not a good idea for the transparency. If the memory is allocated in the kernel. Still, we cannot move the context from user-mode to kernel-mode. We could forcibly do it but, this way, we'll break the OS semantic as a thread is supposed to spin user-mode while it's currently in kernel-mode. Which doesn't make sense.

no, of course not. you mean it passed the entrypoint but HyperDbg didn't notice it?

The !monitor command will continue the guest for some time. How did you prevent it from running? is there any other threads in the process?

But the oep instruction is in the Main thread and is the first instruction of the original executed

yes, but how did you run the !monitor command? I mean setting the !monitor itself runs the debuggee for some time. At this time, the thread will get a chance to be executed (and possibly run the OEP). Previously, I mentioned, even when I make the '.pagein' command, we still need another command to spin the current thread so, we can set the !monitor. But, I remember, you told me you used a dirty trick to halt the current thread. I am right? or is it the lack of the spinning command is problematic right now?

I will try

yes, no worries about these problems. whatever happens, I'm here to solve it. 👍

hi i have Q

What is this group and how can I benefit from what you are talking about

1. If you don't know what this group for , why you are here ? Just random joining from other groups?
2. HyperDbg is an open-source, user-mode, and kernel-mode debugger that relies on hardware features to debug the Windows Kernel and Applications.

did you know this debugger checking test

https://github.com/hfiref0x/WubbabooMark

hyperdbg remains tracing

and did not finish the test

Hi,
Yes, I saw it yesterday. For now, it seems that they only check for the object device name of HyperDbg, which can be easily bypassed by using a different name in the source code. However, for the test, it's just a matter of injecting or not injecting #DBs into the guest. Once, I have free time, I'll check that to see how we can bypass its mitigations.

Also, @ricnar FYI, I changed the behavior of symbol search, and now the module search is case-insensitive and I almost fixed the issue regarding the loading of SysWow64 modules. I'll let you know once it's finished (probably tonight).

great

The issue is now fixed. But, I have to test it with several other conditions (hopefully tomorrow) to make sure it works as expected.
https://github.com/HyperDbg/HyperDbg/issues/243
https://github.com/HyperDbg/HyperDbg/commit/249320d8c94086a840b7397d2227effb637ba535

One interesting thing that I didn't know was that symbols (PDB files) for Wow64 DLLs start with a 'w' prefix. For example, 'wntdll.pdb', 'wkernelbase.pdb', 'wuser32.pdb', etc.

I didn't know either

https://rayanfam.com/topics/hypervisor-from-scratch-part-1/

How does hyperdbg work to read MSRs ? does it connect to cpu directly?and use cpu instructions to bypass OS ?
is there any debugger to work like that? if no why dont they make like hyperdbg to debugg in user and kernel mode.

HyperDbg uses regular WRMSR and RDMSR instructions to read/write on MSR registers.
Please check:

https://docs.hyperdbg.org/commands/debugging-commands/rdmsr
https://docs.hyperdbg.org/commands/debugging-commands/wrmsr

Ollydbg and IDA are not like hyperdbg.
e.x.
I use rdmsr and wrmsr in Ollydbg but it does not work.it comment " privilaged command" . surely,Olly cant go beyond.

I check it bro👍.

IDA mmm no. I think cant work like hyperdbg,can it?!

But if you mean, how HyperDbg intercepts reads/writes to MSR registers, there is something called 'MSR Bitmap' in VMCS of Intel processor. Once you set one bit on this bitmap (memory), each of the read or write access to the corresponding MSR will cause a VM-exit, in which we form it as MSR events.

Please check:
https://docs.hyperdbg.org/commands/extension-commands/msrread
https://docs.hyperdbg.org/commands/extension-commands/msrwrite

IDA can use windbg plugin to debug kernel

wooowww 👍.so This is why hyperdbg catch very low events.I mean it works out of regular ring0,3 . below zero.right?

Reading and writing to MSRs needs kernel mode privilege.

Exactly

ye ye that is a plugin.this is not in its core of the app.

Yes, it works on ring -1. Lower than the operating system.

oo man.that is amazing. hyperdbg is better than othe debuggers by far. I am so womder how you though to make such a practical debugger which can catch high level viruses.
thnk bro👍☕

ye which Olly and IDA can not go beyond.not witough plugin.

Thanks. Personally, I don't think that HyperDbg is better than other debuggers, it's just with different capabilities and designed for different purposes. For example, for driver development, of course, WinDbg is better. Or if you want to debug a user-mode application, of course, the best option is x64dbg.

But, sometimes, you need extra information or you need hardware capabilities to assist you in your debugging journey. That's when you can use HyperDbg to ease your analysis or reverse engineering.

Ye ye I mean hyperdbg capabilities are more practical.You can not catch high level viruses with Olly or IDA(whiich iiss reaallly good)you know that the viruses are on devicedriver layer. is it possoble yo catch boot rootkits or I dont know DKOM attacks with other debuggers?!. in these situations, we need a debugger that works on rings below zero just like hyperdbg not x64dbg.
for normal works normal cracking ye olly , ida , x64 are enough. i know Ida is really good but ....

part two : ye ye I agree. I need a lot to know about hardware to do so well.

I haven't spoken to you. I'm talking to the owner

Guys, just take a deep breath and chill out.

Don't take anything seriously.

We're here to talk about HyperDbg debugger and have discussions of how we can make it a more suitable tool for our reverse engineering experiences.

Pls ask meaningfully questions, and no fights pls

@ricnar The problem with loading 32-bit modules is now completely solved and ready to test.

I test it with your example, "user32!messageboxa". Please note that, based on your previous feedback, it's no longer case-sensitive. 🙃

Just one more thing, based on my tests, once you start a process (run it by using the '.start' command), the user32 and probably other modules are not loaded into the memory.

So, in order to bring them into the memory, the '.pagein' command needs to be used.

I test it with this program.

Thanks I will test it

I try to release v0.4 now.

Perfect

I will try in the weekend

HyperDbg v0.4 is released.

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

Can HyperDbg debug Windows PatchGuard？

Yes. You have plenty of options to monitor PatchGuard.

https://github.com/tandasat/GuardMon/tree/master

Satoshi Tanda creates a hypervisor years ago to monitor PatchGuard. All of the capabilities that he used in his project are also available in HyperDbg.

For example,

for monitoring debug registers:
https://docs.hyperdbg.org/commands/extension-commands/dr

for monitoring memory:
https://docs.hyperdbg.org/commands/extension-commands/monitor

Hey, is memory introspection available in v0.4?

The project that I previously talked about it as memory introspection is not yet available. But, what else do you want better than '!monitor'?

Starting from version 0.4 it's able to intercept Read/Write/Execute from any address range both in the user-mode and the kernel-mode.

Does this allow me to monitor reads coming from a driver to unknown memory locations?

problem is- i'm dealing with a target with virtualized code, so it's much harder to determine from which routines these reads would be coming from

It's possible to implement such a scenario using !monitor but it's so tricky. Because you might end up blocking the CPU's memory manager from modifying the memory and setting page-table bits. You still need to wait for that memory introspection project.

But, you have some options here. You can block your target driver from executing in the target machine. Using '! monitor's short-circuiting event.

And after you can log from the instructions or step through the instructions.

And, you know, the memory introspection project wouldn't be that much better than this approach.

Please take a look at:
https://docs.hyperdbg.org/commands/extension-commands/monitor#short-circuiting

@prekvapko

thanks ❤️

Did you get the idea?

I'll read through it.

Just block the execution of your driver and step through its instructions.

will be fun on a 14mb sample :D