HyperDbg v0.11 is released! ✨
This version comes with bug fixes, improvements, and two new commands for viewing Local APIC (XAPIC/X2APIC) and IO APIC.
Big shoutout to Björn Ruytenberg for joining the team for bringing PCIe support to HyperDbg!
https://github.com/HyperDbg/HyperDbg/releases/tag/v0.11.0
Check it out:
https://docs.hyperdbg.org/commands/extension-commands/apic
https://docs.hyperdbg.org/commands/extension-commands/ioapic
- 03 December 2024 (2 messages)
-
-
- 06 December 2024 (3 messages)
-
Joined. - 07 December 2024 (1 messages)
-
Joined. - 08 December 2024 (1 messages)
-
- 11 December 2024 (5 messages)
-
Starting from the next version (v0.12), HyperDbg will support the '!pcitree' command. You can use it from the 'dev' branch now.
https://docs.hyperdbg.org/commands/extension-commands/pcitree -
-
[discord] <jamlee7879> @HyperDbgBridge
Is Rayanfam in the group? Things aren't working properly here. The registry entries for DbgView aren't working properly either. It took me about an hour to figure out the correct way to do it. Here's what you should do:
Save the following content as dgbview.reg.
Double-click on dgbview.reg.
```
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter]
"DEFAULT"=dword:0000000f
```
https://cdn.discordapp.com/attachments/962350355839066130/1316449218633928724/image.png?ex=675b1660&is=6759c4e0&hm=828c61954ef4c4123a50b78220337f9999819a81292ad551763e8655a98fcedb& -
[discord] <jamlee7879> it works for me. my win version is 10.0.16299
https://cdn.discordapp.com/attachments/962350355839066130/1316450184007385099/image.png?ex=675b1746&is=6759c5c6&hm=519cbc2fcbf829fa164e17084e0366b7e0c0e5074fb3be8a911d086e4e590392& -
[discord] <jamlee7879> you could consider patching the article. 😄
https://rayanfam.com/topics/hypervisor-from-scratch-part-2/#viewing-debugging-messages-in-dbgviewHypervisor From Scratch – Part 2: Entering VMX OperationWe write about Windows Internals, Hypervisors, Linux, and Networks.
- 12 December 2024 (2 messages)
-
Joined. -
Nice catch. You can send your patch to the blog using this repo:
https://github.com/rayanfam/rayanfam.github.io/tree/main/_postsrayanfam.github.io/_posts at main · rayanfam/rayanfam.github.ioYou can visit the website at: https://rayanfam.com - rayanfam/rayanfam.github.io
- 13 December 2024 (4 messages)
-
[discord] <jamlee7879> @HyperDbgBridge https://github.com/rayanfam/rayanfam.github.io/pull/2 Do you have time to review it?fix: set Debug Print Filter to dword:0000000f by Jamlee · Pull Request #2 · rayanfam/rayanfam.github.io
my windows is 10.0.16299, the registry entries for DbgView aren't working. It took me about an hour to figure out the correct way to do it. Save the following content as dgbview.reg. Doub...
-
[discord] <jamlee7879> Checked in successfully for 'hypervisor-from-scratch-part-2'
https://cdn.discordapp.com/attachments/962350355839066130/1317182006190280714/image.png?ex=675dc0d6&is=675c6f56&hm=91e6ccffd96bea431c7a7874768e590b9379d3dcdb86319ac7097608203ae61b& -
Merged! 👍
-
Great. Thanks for fixing it.
- 14 December 2024 (1 messages)
- 15 December 2024 (8 messages)
-
[discord] <jamlee7879> In Linux, each process has its own page table. However, according to the concept of shadow page tables, it seems that there is only one page table for the guest. This seems very strange.
https://cdn.discordapp.com/attachments/962350355839066130/1317912800395399219/shadow-page-tables-1.png?ex=67606971&is=675f17f1&hm=1a24bfdbcdcae67675e731575ebe01ef151b97f61fd90ba7a7f6eb7c27301627& -
[discord] <jamlee7879> Many diagrams are drawn in this way, but I don't understand why only one page table is drawn for the guest. Clearly, there should be multiple page tables (one for each process).
https://cdn.discordapp.com/attachments/962350355839066130/1317913591650713721/703cb802dfdf67ea4295e3fdd8d6d9fe.png?ex=67606a2d&is=675f18ad&hm=eca03a1625753c826ceccd0c301c338ab31ceb44e9db6e09fac291f1a87e4e46& -
I don't know which material you're researching, but it looks like a description of a hypervisor for a pre-EPT era. Hypervisor would trap page faults and mask CR3 register, so that it would replace needed pages for the guest OS on the fly. Indeed, you would have to mask all related page tables (for every related process). However, it's more like an implementation detail, that's why it's probably out of scope for your material. -
[discord] <jamlee7879> I'm currently reading "hypervisor-from-scratch-part-4". The architecture diagram of the shadow page table in it doesn't quite match the Linux memory management logic that I knew before, so I'm a bit confused.
My understanding is the same as that shown in this diagram.
https://www.ryanstan.com/mmu-virtualization-shadow-page-tables.html
https://cdn.discordapp.com/attachments/962350355839066130/1317916799718785165/shadow-page-tables-diagram.png?ex=67606d2a&is=675f1baa&hm=2465f1cf56627b2a46e465caf83e28c81d27045ecfaa3609840c7d26023dabf0& -
Oh, that's a question for the author then, hehe
-
But my take is hypervisor doesn't know anything about the guest, whether it is linux, dos or etc. Hypervisor's purpose is to virtualize the execution environment.
-
There are indeed separate page tables on Linux and Windows, and that's the reason you trap CR3 writes in the hypervisor as well
- 16 December 2024 (1 messages)
- 17 December 2024 (2 messages)
- 18 December 2024 (5 messages)
-
Hi,
I actually respond it in the github (https://github.com/HyperDbg/HyperDbg/issues/488) but will send it here for further discussion:
There might be two issues in this scenario.
First, the address might be actually invalid. Are you 100% sure that the address is valid?
If the address is invalid in the OS, HyperDbg will just inject a #PF and it will crash the system since Windows assumes it as a not-expected error.
Second, it's kinda weird that you used .pagein w which means injecting a 'write'. Change it to the default behavior (without 'w') might fix the issue, so the command should be:
.pagein 00007ffb6bee0000
Let me know whether the above command fixes the problem or not.Use .pagein will 100% trigger windows blue screen. · Issue #488 · HyperDbg/HyperDbgDescribe the bug I use debugger mode to debug process. And i want to debug dll running condition. i use "!monitor rw 00007ffb6bee0000 l 500" command to monitor memory. but kHyperDbg show ...
- 20 December 2024 (6 messages)
-
-
Are you sure that you're delivering the #PF to the correct process layout? You can check it by using the '.process' command.
-
Running the 'lm' command as mentioned in the documentation, runs the debuggee for some times, thus, you'll loose the context (memory, registers, and process). So, you might end up injecting page fault to a different process and as HyperDbg is operating at the kernel, the page fault injection will be delivered to the Windows kernel and it's not a surprise to see BSOD.
-
When do you execute this command? I mean at what stage of a process and after which command?
Did you see this video for the reference?
https://youtu.be/MjDW2gS3lBg?si=jBLvS0C458Erw7A2Dbg3301: HyperDbg 10 09 Bringing Pages Into RAMView the full free MOOC at https://ost2.fyi/Dbg3301. This course is an introductory guide to HyperDbg debugger, guiding you through the initial steps of using HyperDbg, covering essential concepts, principles, debugging functionalities, along with practical examples and numerous reverse engineering methods that are unique to HyperDbg. Whether you have an interest in reverse engineering or seek to elevate your reverse engineering skills with hypervisor-assisted approaches, this course provides a solid foundation for starting your journey.
- 23 December 2024 (7 messages)
-
-
-
I see the issue now. Check the RIP address where you paused and examine the execution of the target process. It appears to be in the page-fault handler, which operates in the kernel rather than user mode. If you inject a page fault while the page-fault handler is already active, it can trigger multiple page faults (or a double fault, if I’m not mistaken), ultimately leading to a Blue Screen of Death (BSoD).
-
You need to intercept the process while it's in the user-mode (not kernel mode) and then inject the page-fault.
-
You should not use the '.pagein' after the '.process'. Since in the implementation, both of the use the same mechanism (even injection in VMCS). So, now that I'm thinking about it, it couldn't work since we're not buffering multiple interrupts/faults/exceptions.
-
You have plenty of other options, you can start the process using the '.start' command (which intercepts the first instruction of the entry point in the user mode) or you could put !epthook on known user-mode functions that you know it will called or maybe putting a !monitor on a buffer or piece of code, all of them work. Just make sure that your RIP register is in the user-mode and the process is your target process.
- 24 December 2024 (7 messages)
-
Did you test it? Is the problem solved? I see you also closed the GitHub issue.
-
Yeah, but there could be a lot of unexpected conditions we didn’t think of (which might cause new errors 🙂). Typically as HyperDbg runs at the hypervisor level, the user needs to consider a ton of factors plus have a solid understanding of CPU internals to figure out what’s going on and how to handle it.
-
BTW, if you encounter any further error, please don't hesitate to post them here and we would be glad to help.
- 25 December 2024 (7 messages)
-
Hi,
Merry Christmas. 🎄
Actually in HyperDbg, there is no difference between debugging a user mode application or a kernel mode code (by design) since it operates at the hypervisor-level. Though, there are plenty of command and functions that facilitate the user mode debugging like the '.start' command or the other commands for switching into a target process. -
So, it's basically about the process memory layout. You can do whatever you want as long as you're in the memory layout of your target process (CR3).
-
I recommend going through the OpenSecurityTrainings' course for HyperDbg, since there are plenty of examples where we used HyperDbg for debugging user mode applications:
https://p.ost2.fyi/courses/course-v1:OpenSecurityTraining2+Dbg3301_HyperDbg+2023_v1/aboutDebuggers 3301: HyperDbgThis class teaches you how to use HyperDbg, a virtualization-based debugger.
- 28 December 2024 (1 messages)
-
Joined. - 30 December 2024 (4 messages)
-
Starting from the next version (v0.12), the new command for dump IDT entries will be added to HyperDbg. You can test it on the 'dev' branch now.
https://docs.hyperdbg.org/commands/extension-commands/idt -
At this point, we have most of the commands related to handling interrupts, exceptions, and faults. These include !idt for dumping IDT entries, !apic and !ioapic for viewing the state of the Local APIC and I/O APIC in both XAPIC and X2APIC modes, and commands like !exception and !interrupt for intercepting (hooking) interrupts and exceptions.
-
There are also commands for interrupt redirection of Intel VT-d that will be added in the future versions.
-
Joined. - 31 December 2024 (5 messages)
-
Happy New Year, everyone! 🎉🎊
Wishing you an amazing 2025 ahead!
This year, we’re excited to work on adding new features to HyperDbg, including support for PCI Express, UEFI, and firmware debugging. As always, your contributions are greatly appreciated! -
None
-
Happy new year HyperDbg Family! 🤝
Hope we all learn more stuff👉, level up 🌡, and do amazing projects in 2025! 👍 -
Happy new year guys🎄🎄😘
