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

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-dbgview

Nice catch. You can send your patch to the blog using this repo:
https://github.com/rayanfam/rayanfam.github.io/tree/main/_posts

[discord] <jamlee7879> @HyperDbgBridge https://github.com/rayanfam/rayanfam.github.io/pull/2 Do you have time to review it?

[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.

[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