- 03 February 2025 (3 messages)
-
It's applid to the VM-exit handler, so it's for all instructions and in your case, both of them. - 05 February 2025 (3 messages)
-
- 06 February 2025 (19 messages)
-
[discord] <rol0807_03449> Hi. It's not possible to do such - using $pid ?
`!epthook ntdll!NtCreateUserProcess pid $pid` -
[discord] <rol0807_03449> After .process, $pid should be set?
-
[discord] <rol0807_03449> [reply]: I to have this issue sometime. Dont know why. Usually restart hyperdbg-client.exe and it stops.
-
Hi,
This error means that there is an error happened in VMX-root mode. -
In order to debug that, you should comment this line:
https://github.com/HyperDbg/HyperDbg/blob/136ba94c293558410cce8994f24460d3760d50b8/hyperdbg/hyperhv/code/vmm/vmx/IdtEmulation.c#L171
and then recompile HyperDbg.HyperDbg/hyperdbg/hyperhv/code/vmm/vmx/IdtEmulation.c at 136ba94c293558410cce8994f24460d3760d50b8 · HyperDbg/HyperDbgState-of-the-art native debugging tools. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
Once you run your new recompiled version of HyperDbg, if you can reproduce the error again, windbg will give you a crash analysis (!analyze -v).
-
And then we could further investigate the error.
-
It's a valid script but does not make sense in VMI mode (and most of the time in the debugger mode). You're putting a hidden breakpoint on HyperDbg's calls on this function which might break the ability of hyperdbg to run a process. Maybe you're trying to do sth else? Can you explain what you're trying to do with this?
-
No, these kinds of errors are usually easy to debug.
-
You could also send steps we could reproduce the error, this way we could also reproduce and fix it.
-
[discord] <10g1c.> [reply]: no i belive its still over serial
- 07 February 2025 (9 messages)
-
heyy.. anyone tried to run debugger on linux ? i mean Debugger-PC(Linux) -> VMWare(Windows) ? -
The error is not from hyperhv.dll or hyperkd.sys. It's from NTOSKRNL.
-
So, it seems that HyperDbg changes the system state in a way that causes problem for NTOSKRNL.
-
Did you change anything in the !monitor script? Like accessing anything in the memory?
-
No, not yet. I recently went through it but it seems that we need to re-write the drivers for Intel E1000 NICs, so it's kinda challenging.
-
I think as long as you could forward the serial connection over two VMs, it should be fine. Though I never test it this way.
-
Ok, that's was my idea :) will try soon
- 08 February 2025 (13 messages)
-
So, you didn't use the !monitor command and call the API functions directly?
-
The same behavior also applies to HyperDbg when you use the '!monitor' command? Or only the API is problematic?
-
Can you try to use the !monitor command on this address and see if it works of not?
I just tested the !monitor on the whole _EPROCESS (including token) and it works. I couldn't reproduce the error. -
Like how many !monitor(s)?
- 09 February 2025 (9 messages)
-
That is weird. Can you share your PoC? I mean the code in which automatically puts monitor on 50 EPROCESS tokens.
-
Great. Thanks. I'll test it hopefully this week.
-
Yes, it should be compatible with this processor.
- 10 February 2025 (8 messages)
-
[discord] <rol0807_03449> how to load symbols for usermode without debugee run away? setting !epthook on kernel32 not possible because symbol not loaded. ok for nt! and ntdll! but nothing else?
-
[discord] <rol0807_03449> even for bp in process context the function address returns error
-
[discord] <rol0807_03449> if for kernel32
-
[discord] <rol0807_03449> maybe this is problem from wow64...
-
Joined. -
You need to load the symbols for the process once it's loaded. After that, you could close the process and open it again (and the symbols are still available from the previous run).
-
If you're debugging in the debugger mode, there is a bunch of solutions for bypassing the 'demand paging' if the page is not available in the memory.
https://docs.hyperdbg.org/tips-and-tricks/considerations/accessing-invalid-addressAccessing Invalid Address | HyperDbg DocumentationConsiderations for accessing memory in different modes
-
Ah, for kernel32 for some reasons (that I didn't understand), kernelbase and kernel32 does not return anything (from Microsoft DIA SDK). That's kinda weird, but it's fine with other DLLs and SYS files.
- 11 February 2025 (1 messages)
- 13 February 2025 (1 messages)
- 14 February 2025 (3 messages)
-
I went through this code today. At first, it causes BSOD with the same reason (page-fault) in my system. But then I commented the #PF interception in VMX-root mode and I couldn't reproduce the same error (in ~2 hours).
-
You can go through this branch, if you want to test it, but I'm not sure if it will fix your problem since you also commented the #PF at some points. But, might be worth a try.
https://github.com/HyperDbg/HyperDbg/tree/fix-24h2-issuesGitHub - HyperDbg/HyperDbg at fix-24h2-issuesState-of-the-art native debugging tools. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
I used a 14 gen Meteor Lake processor along with Win 11 24h2.
- 15 February 2025 (34 messages)
-
[discord] <rayanfam> @.wxg I went through fixing the memory access of MMIO regions (physical mem read) and now it's merged to the 'dev' branch. In case, if you want to use it, you could switch to the 'dev'.
-
[discord] <rayanfam> The patch will be available from the next version (v0.13). Sorry, it took a bit, I did wrote the patch but for some reasons that I don't remember, I didn't merge it. Now, it's merged and it's tested on both the debugger and VMI mode in a physical machine as well as a nested virtualization machine.
-
@instw0 did you find time to test the new patch (anti-debugging) method for the technique you mentioned earlier? was that effective and bypassed that anti-debugging method?
-
With regards to paged out addresses and hypervisors I used to use the following trick.
In order to improve load times, windows uses a global tracking for image loaded bases, including ASLR. It is used for COW and image code reuse among processes. You don’t want this code to be relocated in every process, because you would need to recalculate relocations every time and spend more memory for that. If you try to explicitly load a DLL to an occupied address for example, you’ll get a new module instance in the kernel.
Anyway, the trick is to write a simple application that would load all the DLLs of interest and then run a thread that would probe every page of those loaded DLLs periodically. Once a second should be enough to keep those pages paged in and with fixed PFNs, because you won’t give a chance for a memory deduplication and compression to steal it from you. From there you can safely assume that even if your process has them paged out (pages are paged in when probed), those are the same pages as in your “warming up” process. -
That's a super cool trick, but it's like a so much Windows-based trick that only applies to Windows. I mean we do have a lot of code that actually works only for Windows but generally, we try to avoid OS-specific tricks as much as we can. Non of the HyperDbg events are OS-dependent. Though some features are Windows-dependent for sure.
-
Do you support Linux targets?
-
There is an api called LockMemory, you could use that instead -
That requires privileges
-
I didn’t have those
-
Privilege to lock your own memory? Didn’t know that
-
SeLockMemoryPrivilege
-
It's not really your in this case, PFN is OS's
-
Not yet, but we're currently doing a massive code refactoring to remove or create several platform-specific functions. The goal is to support Linux hopefully in 1 or 2 years.
-
So you're kind of stealing a PFN from the memory manager
-
Anyways, just sharing my tips. Use at your discression.
-
I actually saw that Petr in the vmi-rs project offers this functionality:
https://github.com/vmi-rs/vmi?tab=readme-ov-file#utilitiesGitHub - vmi-rs/vmi: Modular and extensible library for Virtual Machine IntrospectionModular and extensible library for Virtual Machine Introspection - vmi-rs/vmi
-
I didn't see the code but I assume he uses EPT hooks on page-table addresses, not sure how it's exactly implemented (or maybe Xen offers the same functionality).
-
This is the main description of this feature:
https://docs.rs/vmi/latest/vmi/utils/ptm/enum.PageTableMonitorEvent.html#variant.PageInPageTableMonitorEvent in vmi::utils::ptm - RustPage Table Monitor Event.
-
If it's possible to monitor page-tables, I think we could also offer the same functionality.
-
Did they monitor page tables using EPT?
-
Can you send the research paper here?
-
Thanks
- 16 February 2025 (3 messages)
-
Oh, that's great.
And of course thanks to the contributor who implements that functionality in HyperDbg (if he is in this group). 👌 -
Joined. - 17 February 2025 (22 messages)
-
Joined. -
[discord] <dexus1337> Hello! I got a question regarding the "!monitor" command. Is there a way to get the data that is being read/written without performing a manual read to the address $context gives? I want to debug mmio access between a kernel driver and pcie device, where reading a mmio address after the kernel performed a write will not necessarily give me the value the kernel has written, since it may be to a address the pcie device uses as a control register.
-
[discord] <dexus1337> Also, when the trigger flag is rw, how do i know if its a read or a write in my event script?
-
Hi,
That's a really good point. I’ve never thought about it, but yeah, I think we need this as a feature to read values that will be written into MMIO addresses.
Generally, for memory reads/writes in the RAM, we have pre- and post-events, which means you can read the data before and after it is modified, as described here:
https://docs.hyperdbg.org/tips-and-tricks/misc/event-calling-stage
However, for MMIO device addresses, this mechanism doesn't work. From what I know, there is no VMCS field that tells us the value that is about to be written to the target address once a VM-exit (EPT violation) happens. In that case, I don't know how we could get the value for the MMIO addresses.
One solution that comes to mind is interpreting the instruction operands (e.g., registers) to determine the values that are supposed to be written to the MMIO memory, but that would be a slow approach. I’m not sure if there are any other solutions for reading what is trying to be written once an EPT violation occurs. -
The solution to this, would be using two different events, one of them with 'r' and one of them with 'w' with different scripts.
-
Pinging @honorary_bot or anyone else who can think of any solution for this problem.
-
🤔
-
There is literally no good solution. You'd need a simple disasm for that. Sorry.
-
I've been complaining about this for years
-
AMD has last instruction bytes in its vmcb, Intel does not
-
Which is a bummer, because those bytes and disasm IS available in the ucode
-
👍
-
PulseDbg design requires trapping APIC access in order to track INIT requests to different cores. It is fine when the guest uses x2apic and you only have to trap ICR MSR, and the value is always in rcx. Sadly, xapic is often used and from there you need to trap the access with virtual apic page or EPT, read the guest code, disasm it and then resume with MTF
-
Ah, in this case, the only solution is writing a disasm parser.
-
It is an MMIO case btw
-
MMIO has side effects, even for reading
-
i.e. you could read a MMIO register multiple times and get a different result, altering it finite state machine
-
So the only way to track it is to track what is about to be written there
-
OR realistically it might be easier to log a breakpoint on a driver function that read or writes mmio
-
Often it is a separate function
-
[discord] <dexus1337> Thank you all for your replies! My knowledge regarding hypervisors is limited, but arent there shadow pages that could be used for this? So if the driver tries to write to an mmio address (which is backed by a shadow Page), the hv breaks, reads what the driver wrote to the Shadow page and mimics the write to the actual physical page. Overhead could be an issue but the general approach may work, no?
-
Depends on the MMIO actually. That might work for a PCI device MMIO, can't see why not. In other cases like trapping APIC access it might not work. Imagine a scenario - you've trapped a write to xAPIC, the trap happens BEFORE any data was written, so you need to single step to get the data on your "shadow" page (which is just a different EPT). But now you would need to emulate that write to a real MMIO. In case of local APIC it would influence your hypervisor execution instead of a guest one that would otherwise give you another vm exit. So.. it depends..
- 18 February 2025 (10 messages)
-
[discord] <dexus1337> [reply]: Perfect, debugging pcie decives was what i was trying to do anyways. I might give it a shot then
-
[discord] <dexus1337> Another question. Inside the event script for monitor, i cannot use dd to read the memory accessed. i get the following error message:
HyperDbg> (10:33:58.161 - core : 0 - vmx-root? yes) [+] Information (DebuggerPerformRunScript:1651) | err, ScriptEngineExecute, function = FUNC_DD
this is my script:
!monitor r 81ff0000 81ffffff pa imm no stage post script {
printf("reading: %llx -> %x\n", $context, dd($context) );
}
It works fine without the dd part, printing out the valid physical addresses accessed.
Am i doing something wrong here? -
Joined. -
Joined. -
[discord] <rayanfam> [reply]: Hi. Do you have the same problem with 'poi' or 'dq' or 'db'?
-
[discord] <rayanfam> [reply]: Ah, I see! You're using the physical address. I'm not sure if I use the '$context' as a physical address or a virtual address. Is the $context a physical address?
-
[discord] <rayanfam> [reply]: If it's a physical address, the 'dd' and all of its variants (dq, db, poi) are only compatible with the virtual address, not physical address.
-
[discord] <dexus1337> [reply]: Ahh i see the issue. I thought dd reads physical mem, similar to the HyperDbg Function. But within the script it means something different. Since "physical_to_virtual" script function is labeled with "This function is not working. PLEASE DO NOT USE IT FOR NOW. It will be fixed in future versions." there is no way (currently) to read physical memory in events, right?
-
[discord] <rayanfam> [reply]: Converting physical to virtual address have technical problems, like we don't have a solution for it. But, adding support for reading physical memory should be easy since we have plenty of functions for reading physical memory in the VMX-root mode. It just needs to be exported. I'll add these functions in the coming version (v0.13).
-
[discord] <dexus1337> [reply]: Perfect, thanks a lot! In general, i really like the HyperDbg Project. Very clean code aswell! Good job!
- 19 February 2025 (21 messages)
-
Not sure if I understand correctly, but yeah, this function might not work correctly in many cases.
-
If you're in a driver, just try MmMapIoSpace. Though not 100% if the OS allows that for page tables
-
HyperDbg has a equivalent command for that, but same as WinDbg it might not work in all situations with the same reason:
https://docs.hyperdbg.org/commands/extension-commands/pa2va!pa2va (convert physical address to virtual address) | HyperDbg DocumentationDescription of '!pa2va' command in HyperDbg.
-
But generally, I think you could use the '!mode' command (using its API) to achieve your goal (if I didn't mistakenly understand your description).
https://docs.hyperdbg.org/commands/extension-commands/mode!mode (detect kernel-to-user and user-to-kernel transitions) | HyperDbg DocumentationDescription of the '!mode' command in HyperDbg.
-
Hyperspace is a working set area but yeah, I would not allow to do that if I were Windows hehe
-
Nice trick is to go and manipulate page tables directly. But that's a bad advice and you should not listen to me
-
For remapping physical pages to your predefined virtual address I mean
-
It literally just builds a page table entry for a given physical address and maps it somewhere in kernel space. So it's totally reproducible, just because it is the way CPU works
- 21 February 2025 (1 messages)
-
Joined. - 22 February 2025 (31 messages)
-
These are automated scamming bots
-
Btw you mentioned you bought an MTL machine. Which one?
-
*meteor lake
-
I do have a Core Ultra 7 155h but I mainly work on my raptor lake laptop at the moment.
-
I mean is it a NUC? Which model/oem?
-
No it's not. It's a System76 laptop.
-
I see, cool
-
Clevo is the odm.
-
I got atomman x7 and its firmware sucks
-
Is there anything wrong with meteor lake laptops right now?
-
No, they are fine and a good case for HV testing
-
MTL has three! different types of cores
-
LNL is much better though, but it's almost impssible to buy a NUC with it at the moment
-
*lunar lake
-
Sorry, I am too used to intel abbreviations
-
Honestly, I really don't understand the new naming scheme of Intel anymore. It's so complicated, you see different code names with different generations, different family name of architecture and now the model of processor no longer shows its generation. It's so complicated.
-
😵💫😵💫
-
I've also asked ChatGPT.
ChatGPT does not know either. 🤦♂ -
The concept of generations was somewhat clear with performance cores. Since CPUs are hybrid now, they have a mix of different core types and generations, so you can't really name a specific gen for a CPU
-
You mean p-core and e-core?
-
And generation itself does not reflect features as well, it's more about uarch
-
Even in the past atom cores had more features than bit cores
-
Yeah
-
MTL even has three types of core, p core and two different e core types
-
It is also possible for one package to have different VMCS revision, so watch out :)
-
The '!hide' command is changed (in the 'dev' branch). You might wanted to test it from 'dev' branch.
- 23 February 2025 (4 messages)
-
[discord] <rayanfam> @dexus1337 I added the functions for reading and writing to physical memory. To use these new functions (and keywords), you need to switch to the 'dev' branch and recompile.
Please check:
https://docs.hyperdbg.org/commands/scripting-language/assumptions-and-evaluations#keywords
https://docs.hyperdbg.org/commands/scripting-language/functions/memory/eb_pa-ed_pa-eq_pa
https://docs.hyperdbg.org/commands/scripting-language/functions/memory/memcpy_paAssumptions & Evaluations | HyperDbg DocumentationDescription of keywords, operators, pseudo-registers, number prefixes, and pre-defined functions
-
[discord] <rayanfam> You can use: poi_pa, hi_pa, low_pa, dw_pa, and dq_pa keywords as well as eq_pa also a separate function (memcpy_pa) is added.
-
[discord] <rayanfam> Please don't use db_pa, dd_pa and eb_pa, ed_pa for now as it has a small problem which will be fixed, other than that, all of the above functions are tested and in a working state.
-
[discord] <dexus1337> [reply]: Thanks a lot!
- 24 February 2025 (1 messages)
- 25 February 2025 (3 messages)
-
HyperDbg v0.13 is out! 🎉
This version comes with a new command '!pcicam' for dumping and interpreting PCIe CAM, new anti-anti-hypervisor methods, improved MMIO scripting, plus lots of bug fixes & improvements.
Big thanks to @0Xiphorus & @AbbasMasoumiG.
https://github.com/HyperDbg/HyperDbg/releases/tag/v0.13
More details are available here:
https://docs.hyperdbg.org/commands/extension-commands/pcicamRelease v0.13 · HyperDbg/HyperDbgHyperDbg v0.13 is released! If you’re enjoying HyperDbg, don’t forget to give a star 🌟 on GitHub! Please visit Build & Install to configure the environment for running HyperDbg. Check out the Q...
-
Thanks to @Reverser69 who is in this group for finalizing the command parser.
- 26 February 2025 (1 messages)
- 27 February 2025 (18 messages)
-
Yes, I think we added a tag for the monitor in v0.9 or v0.10. This is the best implementation of the !monitor hook so far, and we haven't received any reports (GitHub issues) indicating that it fails. The tag used in this structure is the same as the Event Tag.
-
In previous versions, we didn't use a tag because we directly saved the physical address of the memory we wanted to monitor and checked the EPT violation with that. After some time, we received a GitHub issue reporting that HyperDbg's !monitor command failed to detect certain memory writes at specific locations (which we couldn't reproduce), and the issue remained unsolved for a year.
-
Later, one of the users provided us with access to a VMware snapshot where we could reproduce the error. Based on our investigations, we discovered that Windows sometimes does not allocate two (or more) contiguous virtual memory regions continuously in physical memory. For example, 0xfffff801deadb000 might be allocated at the physical address 0xc1b000, but 0xfffff801deadc000 could be allocated at 0xa15000, causing HyperDbg to miss triggering or not triggering an event.
-
With the new tag-based approach, these scenarios are handled correctly. As far as I know, we haven't received any complaints or bug reports about the latest implementation in almost a year. So, this is more or less the best implementation of !monitor so far.
-
👍
-
yes, exactly. If you don't provide a unique tag for each !monitor hook, it won't trigger anything.
@hyperdbg / Public archive of HyperDbg Telegram messages.
- 03 Feb 2025 (3)
- 05 Feb 2025 (3)
- 06 Feb 2025 (19)
- 07 Feb 2025 (9)
- 08 Feb 2025 (13)
- 09 Feb 2025 (9)
- 10 Feb 2025 (8)
- 11 Feb 2025 (1)
- 13 Feb 2025 (1)
- 14 Feb 2025 (3)
- 15 Feb 2025 (34)
- 16 Feb 2025 (3)
- 17 Feb 2025 (22)
- 18 Feb 2025 (10)
- 19 Feb 2025 (21)
- 21 Feb 2025 (1)
- 22 Feb 2025 (31)
- 23 Feb 2025 (4)
- 24 Feb 2025 (1)
- 25 Feb 2025 (3)
- 26 Feb 2025 (1)
- 27 Feb 2025 (18)