-
@@ -18387,7 +18406,7 @@
- - 21 June 2024 (4 messages) + 21 June 2024 (35 messages) + + + + + + +
-
+ + ++ +
+
+ + +++ + I believe we should wait for the 'phnt' authors to fix the issue. Modifying the submodules ourselves can lead to problems when updating them in the future. Even though we had forced to do it once before, it's usually not a good idea. Let's give the phnt authors some time to address the issue, then we can update accordingly. ++ + +
+
I've created an issue for them here: https://github.com/winsiderss/phnt/issues/34 +
+
If they are slow in fixing the issue, we will inevitably have to update our forked submodule. + ++ + Build issue with newest SDK/WDK (redefinition of structures) · Issue #34 · winsiderss/phnt + ++ +Hi, I would like to report an issue regarding the compilation of HyperDbg against the newest SDK/WDK. It seems that the new SDK has the definition of _FILE_STAT_LX_INFORMATION and other functions m...
+ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + I think in the meanwhile you can switch to this version of phnt https://github.com/oberrich/phnt_nightly as the fix for this issue was already merged there ++ + +
+
This one is basically the same phnt but it automatically obtains it from the systeminformer repository so as soon as they push any updates to the systeminformer's phnt(they're first merging new stuff to the systeminformer and then after some time merging to the phnt repo) they'll end up in that repo too. + ++ + GitHub - oberrich/phnt_nightly: Native API header files for the Process Hacker project (nightly). + ++ +Native API header files for the Process Hacker project (nightly). - oberrich/phnt_nightly
+ + +
+
+
+
+
+
+
+
+ -
+ + ++ +
+
+ + +++ + As long as I remember, I didn't implement a timing function. 🤔 ++ + +
Though not sure 😄 +
Because I remember at some point we had a discussion about the time with someone else but I don't know whether we ended up implementing anything or not. +
+
Anyway, go and modify this function, add a LogInfo("message") above this function and LogInfo is a function we use for debugging HyperDbg itself. It shows the current time. + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + And if you're interested in adding this as a separate function to HyperDbg, create an issue in the GitHub and I'll add it (hopefully) to the next version. + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Can you send just the code files? Like the main trick assembly codes. + ++ + +
+
+
+
+
+
+
+
+
+
2024
-
+
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2021-01.html b/2021-01.html index 2b31a9e..5d62eeb 100644 --- a/2021-01.html +++ b/2021-01.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2021-02.html b/2021-02.html index 267dddd..9085990 100644 --- a/2021-02.html +++ b/2021-02.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2021-06.html b/2021-06.html index 37d74ae..7d881ef 100644 --- a/2021-06.html +++ b/2021-06.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2021-10.html b/2021-10.html index 48bee4a..4c5d064 100644 --- a/2021-10.html +++ b/2021-10.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2021-12.html b/2021-12.html index 4857cc8..f0cc2ef 100644 --- a/2021-12.html +++ b/2021-12.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2022-05.html b/2022-05.html index 4bbba14..3fbfdad 100644 --- a/2022-05.html +++ b/2022-05.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2022-06.html b/2022-06.html index 34d6cbd..4940c86 100644 --- a/2022-06.html +++ b/2022-06.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2022-07.html b/2022-07.html index d771904..c8da999 100644 --- a/2022-07.html +++ b/2022-07.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2022-08.html b/2022-08.html index 5e91c67..c78d7e6 100644 --- a/2022-08.html +++ b/2022-08.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2022-09.html b/2022-09.html index ca4e26d..ec2ad0b 100644 --- a/2022-09.html +++ b/2022-09.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2022-10.html b/2022-10.html index 3411666..b464da4 100644 --- a/2022-10.html +++ b/2022-10.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2022-11.html b/2022-11.html index 7a67b38..2b5f7a9 100644 --- a/2022-11.html +++ b/2022-11.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-01.html b/2023-01.html index 503f5a4..211b932 100644 --- a/2023-01.html +++ b/2023-01.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-02.html b/2023-02.html index a022ff4..9c83288 100644 --- a/2023-02.html +++ b/2023-02.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-04.html b/2023-04.html index d37586e..dd6e3d5 100644 --- a/2023-04.html +++ b/2023-04.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-05.html b/2023-05.html index a2588fb..7bf011d 100644 --- a/2023-05.html +++ b/2023-05.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-06.html b/2023-06.html index 623a5b0..3d6e680 100644 --- a/2023-06.html +++ b/2023-06.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-06_2.html b/2023-06_2.html index 8e47bce..d417ab6 100644 --- a/2023-06_2.html +++ b/2023-06_2.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-07.html b/2023-07.html index 2f1cadb..24b01e0 100644 --- a/2023-07.html +++ b/2023-07.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-07_2.html b/2023-07_2.html index 3378f14..7bf34d3 100644 --- a/2023-07_2.html +++ b/2023-07_2.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-07_3.html b/2023-07_3.html index 77db7f6..9e7f105 100644 --- a/2023-07_3.html +++ b/2023-07_3.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-07_4.html b/2023-07_4.html index 7714730..d280230 100644 --- a/2023-07_4.html +++ b/2023-07_4.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-07_5.html b/2023-07_5.html index 5c279e5..662d2ae 100644 --- a/2023-07_5.html +++ b/2023-07_5.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-08.html b/2023-08.html index 2fa2fa6..2e4aa66 100644 --- a/2023-08.html +++ b/2023-08.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-08_2.html b/2023-08_2.html index 170d449..829a70a 100644 --- a/2023-08_2.html +++ b/2023-08_2.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-09.html b/2023-09.html index 2a6a26e..56208e5 100644 --- a/2023-09.html +++ b/2023-09.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-10.html b/2023-10.html index c4a36e5..ebb9a14 100644 --- a/2023-10.html +++ b/2023-10.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-11.html b/2023-11.html index 41f8638..7d6ebb6 100644 --- a/2023-11.html +++ b/2023-11.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2023-12.html b/2023-12.html index 6983eda..6524f25 100644 --- a/2023-12.html +++ b/2023-12.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2024-01.html b/2024-01.html index 52436c6..a5bb55f 100644 --- a/2024-01.html +++ b/2024-01.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2024-02.html b/2024-02.html index d502008..9b8a046 100644 --- a/2024-02.html +++ b/2024-02.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2024-03.html b/2024-03.html index 9c9db3d..032981c 100644 --- a/2024-03.html +++ b/2024-03.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2024-04.html b/2024-04.html index 7ab2b8b..6feec6c 100644 --- a/2024-04.html +++ b/2024-04.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2024-05.html b/2024-05.html index a426d17..06c4e58 100644 --- a/2024-05.html +++ b/2024-05.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) diff --git a/2024-06.html b/2024-06.html index 25ef46f..680c26b 100644 --- a/2024-06.html +++ b/2024-06.html @@ -51,10 +51,17 @@
- + + Jul 2024 + (131) + + +
- Jun 2024 - (489) + (570) @@ -311,6 +318,18 @@
- - 21 Jun 2024 (4) + 21 Jun 2024 (35) + + + +
- + + 22 Jun 2024 (3) + + + +
- + + 23 Jun 2024 (4) + + + +
- + + 24 Jun 2024 (3) + + + +
- + + 26 Jun 2024 (4) + + + +
- + + 27 Jun 2024 (2) + + + +
- + + 28 Jun 2024 (4) + + + +
- + + 29 Jun 2024 (10) + + + +
- + + 30 Jun 2024 (20) diff --git a/2024-06_2.html b/2024-06_2.html new file mode 100644 index 0000000..d9b1c7b --- /dev/null +++ b/2024-06_2.html @@ -0,0 +1,3172 @@ + + + + + +
-
+
2024
+-
+
+
- + + Jul 2024 + (131) + + + +
- + + Jun 2024 + (570) + + + +
- + + May 2024 + (245) + + + +
- + + Apr 2024 + (156) + + + +
- + + Mar 2024 + (90) + + + +
- + + Feb 2024 + (134) + + + +
- + + Jan 2024 + (309) + + + +
+
+ -
+
2023
+-
+
+
- + + Dec 2023 + (62) + + + +
- + + Nov 2023 + (326) + + + +
- + + Oct 2023 + (76) + + + +
- + + Sep 2023 + (315) + + + +
- + + Aug 2023 + (757) + + + +
- + + Jul 2023 + (2215) + + + +
- + + Jun 2023 + (778) + + + +
- + + May 2023 + (300) + + + +
- + + Apr 2023 + (1) + + + +
- + + Feb 2023 + (5) + + + +
- + + Jan 2023 + (1) + + + +
+
+ -
+
2022
+-
+
+
- + + Nov 2022 + (1) + + + +
- + + Oct 2022 + (2) + + + +
- + + Sep 2022 + (1) + + + +
- + + Aug 2022 + (1) + + + +
- + + Jul 2022 + (39) + + + +
- + + Jun 2022 + (23) + + + +
- + + May 2022 + (256) + + + +
+
+ -
+
2021
+-
+
+
- + + Dec 2021 + (1) + + + +
- + + Oct 2021 + (82) + + + +
- + + Jun 2021 + (1) + + + +
- + + Feb 2021 + (1) + + + +
- + + Jan 2021 + (2) + + + +
+
+ -
+
2020
+-
+
+
- + + Dec 2020 + (1) + + + +
- + + Nov 2020 + (2) + + + +
+
+ - + 21 June 2024 (35 messages) + + +
-
+ + ++ +
+
+ + +++ + Thank you, I'll removed those files since it will make problem in group archive. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + I'll try to test and investigate it this week. + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Whenever you run this code while HyperDbg is loaded it prints 'Debugger is present'? And once HyperDbg is unloaded it says it's not present? Am I right? + ++ + +
+
+
+
+
-
+ + ++ ++ +++ + the system freezes + ++ + + + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + When the above application is running in HyperDbg system freezes? Is it the same for master branch too? + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ ++ +++ + with disabled windbg + ++ + + + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ ++ +++ + + ++ + + + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Hello, what software is the memory icon on the desktop? + ++ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Hello guys, ++ + +
Hope you're doing well. +
+
I would like to ask about some Idea in my head to see if it's easy to apply or not. +
+
I want to build a hypervisor to virtualize my own system (an already running system), to monitor any target process for it's API calling, and send that as like a log to a user-mode engine to analyze the calling sequence and the parameters to decide whether it's a malicious process or not. +
+
I want to build it as a PoC, it's doesn't need to be a real world project. +
+
and I'm on my part 6 of Hypervisor from scratch series. so it's like would be easy to me after I finish the series to understand how to build this hypervisor (then I will decide to build a new one from scratch or use the HyperDbg to make this API call hooking for me). or I would need further reading to understand what I need to do. + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + and sorry another Q. ++ + +
when I virtualized a single core, I put the code to do so (set the affinity and configure the vmcs and do the vmclear ..etc) in the IRP_MJ_CREATE dispatch routine, I always faced a BSOD with error that it accessed a paged memory, while when I put the code in the driver entry the problem solved. +
+
and When I analyzed the crash dump I saw that the crash happens when the user-mode app calls the CreateFile api to open a handle to the Driver. so I think the problem is that the DriverCreate dispatch routine is paged out. so how to make sure that's it's not paged ? + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + should I use the ++ + +
#pragme alloc_text() +
or what + +
+
+
+
+ - + 22 June 2024 (3 messages) + + +
-
+ + ++ +
+
+ + +++ + Hi, ++ + +
+
I think the best approach is to use HyperDbg as a library, since handling tasks like sending buffers from VMX root mode to user mode can be quite challenging. You'll read more about it in part 8. + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + I don't have any idea about it, you are probably accessing an invalid memory address since paging is in effect when user to kernel switch happens, so I think being paged out doesn't make sense here. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + But I didn't change anything when I tried to move the code to make it run in the Driver entry instead of the IRP_MJ_CREATE dispatch routine. I'm going to analyze the crush dump again to understand what happened. Thanks sina 😁❤️ + ++ + +
+
+
+
+
- + 23 June 2024 (4 messages) + + +
-
+ + ++ +
+
+ + +++ + sorry sina but another question. ++ + +
+
Are there any examples of projects that use the HyperDbg SDK, or have you explained it in your tutorial? +
I want other resources besides the documentation. + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + + Joined. + + ++ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + There is no official tutorial of how to use SDK but it's pretty straightforward. Take a look at how we used in hyperdbg-cli project and you'll understand how it works + plus you can modify the controller (hprdbgctrl) if it's needed. ++ + +
+
https://github.com/HyperDbg/HyperDbg/blob/master/hyperdbg/hyperdbg-cli/hyperdbg-cli.cpp + ++ + HyperDbg/hyperdbg/hyperdbg-cli/hyperdbg-cli.cpp at master · HyperDbg/HyperDbg + ++ +State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
+ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Great + ++ + +
+
+
+
+
- + 24 June 2024 (3 messages) + + +
-
+ + ++ +
+
+ + +++ + I updated the 'dev' branch to fix phnt error. ++ + +
Please clone HyperDbg again (either update submodules) or clone it like this: +
+
git clone -b dev --recursive https://github.com/HyperDbg/HyperDbg.git +
+
And confirm if it builds successfully in the latest SDK? + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Eduard + ++ + +
+
+
+
+
+
+
+
+
- + 26 June 2024 (4 messages) + + + + + + +
-
+ + ++ ++ +++ + + ++ + + + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + No, the physical serial connection is reported that it's not working as expected. You can search for the discussions in this group. + ++ + +
+
+
+
+
- + 27 June 2024 (2 messages) + + +
-
+ + ++ +
+
+ + +++ + + Joined. + + ++ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + + Joined. + + ++ + +
+
+
+
+ - + 28 June 2024 (4 messages) + + + + + + +
-
+ + ++ +
+
+ + +++ + Not sure if I understand what you mean. 🤨 ++ + +
What do you expect to happen when using the 't' command and the !epthook? + +
+
+
+
+
+
+
+
+
+
+
+
+ - + 29 June 2024 (10 messages) + + + + + + +
-
+ + ++ +
+
+ + +++ + You can use !epthook as a breakpoint but it's not good for doing single step. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Do want to make transparent stepping without trap flag? Am I right? + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + If yes, then you need to use the instrumentation step in the 'i' command). + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + The difference is in its implementation. This document explains the differences in the implementation: ++ + +
https://research.hyperdbg.org/debugger/kernel-debugger-design.html +
+
But in short, the 't' command is exactly implemented the same way that WinDbg or other debuggers implement their stepping mechanism. But the 'i' command is unique to HyperDbg as it guarantees that no core/process/thread got a chance to run except the target process. It's also transparent to the guest debuggee as it uses Monitor Tranp Flag (MTF) in the VMCS instead of Trap Flag, so the target application won't notice it since it wouldn't change anything within RFLAGs. Other than that, this stepping command is capable of stepping instructions from user-mode <> kernel-mode. For example, you can single step the SYSCALL instruction and go directly to the kernel syscall handler from user-mode. + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - + 30 June 2024 (20 messages) + + +
-
+ + ++ +
+
+ + +++ + Yes. In the VMI Mode, you could use all of HyperDbg features except pausing and stepping the debuggee. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Isn't it the expected behavior? 🤨 + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + You mean if the 'p' is pressed and meanwhile the process is terminated, it waits forever for the step to return? Am I understand it correctly? + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Yes, please create an issue in GitHub and describe it so I can fix it later. ++ + +
Also, if you find a way to fix it, you can create a PR too. + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Also, FYI this one is added. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + + ++ + + + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Please check it and let me know if it works as expected or not. It's on the 'dev' branch (not 'master' yet). + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + thanks + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + HyperDbg v0.9.1 is released. 🎉 ++ + +
+
This release comes with bug fixes and introduces new pseudo-registers for timing. Other than that, our hardware debugger chip generator (hwdbg) is now able to run conditional statements and modify signals! +
+
Check it out: +
https://github.com/HyperDbg/HyperDbg/releases/tag/v0.9.1 +
+
Changelog: +
+
### Added +
- Regular port/pin value read and modification in hwdbg +
- Conditional statement evaluation in hwdbg +
- Added automatic script buffer packet generator for hwdbg +
- Added support for @hw_pinX and @hw_portX registers +
- Added hwdbg instance information interpreter +
- Added stack buffer in vmx-root +
- Exporting functions to support loading drivers with different names +
- Exporting function to connect and load HyperDbg drivers +
- Exporting function to connect and load HyperDbg drivers +
- $date and $time pseudo-registers are added +
+
### Changed +
- Fix using constant WSTRINGs in the wcsncmp function +
- Fix phnt build error with 24H2 SDK +
- hprdbgctrl.dll changed to libhyperdbg.dll +
- hprdbgkd.sys changed to hyperkd.sys +
- hprdbghv.dll changed to hyperhv.dll +
- Dividing user/kernel exported headers in the SDK + ++ + Release v0.9.1 · HyperDbg/HyperDbg + ++ +HyperDbg v0.9.1 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 ...
+ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + And this is the conditional statements in hwdbg: + ++ + + + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Hello, ++ + +
When I hook an API, is it possible for me to know which process called that API when it was called and hooked? + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + The '$pid' pseudo-register shows you the process id, '$pname' for process name and '$proc' for nt!_EPROCESS of the target process that triggered the hook. ++ + +
+
You can see the videos of session 5 of the OpenSecurityTrainings's HyperDbg tutorial which describes how to use EPT Hooks + session 4 which explains basic principles of the script engine: +
https://youtu.be/tjsFRBFGis4?si=y1onPj-tzGXKUTVU + ++ + Dbg3301: HyperDbg 05 01 Intro and Classic Hidden Hooks + ++ +View 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.
+ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Great thanks + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
- + + 01 Jun 2024 (1) + + + +
- + + 03 Jun 2024 (3) + + + +
- + + 04 Jun 2024 (75) + + + +
- + + 05 Jun 2024 (2) + + + +
- + + 06 Jun 2024 (3) + + + +
- + + 08 Jun 2024 (3) + + + +
- + + 09 Jun 2024 (5) + + + +
- + + 10 Jun 2024 (2) + + + +
- + + 12 Jun 2024 (1) + + + +
- + + 13 Jun 2024 (98) + + + +
- + + 14 Jun 2024 (26) + + + +
- + + 15 Jun 2024 (31) + + + +
- + + 16 Jun 2024 (43) + + + +
- + + 17 Jun 2024 (93) + + + +
- + + 18 Jun 2024 (8) + + + +
- + + 19 Jun 2024 (25) + + + +
- + + 20 Jun 2024 (66) + + + +
- + + 21 Jun 2024 (35) + + + +
- + + 22 Jun 2024 (3) + + + +
- + + 23 Jun 2024 (4) + + + +
- + + 24 Jun 2024 (3) + + + +
- + + 26 Jun 2024 (4) + + + +
- + + 27 Jun 2024 (2) + + + +
- + + 28 Jun 2024 (4) + + + +
- + + 29 Jun 2024 (10) + + + +
- + + 30 Jun 2024 (20) + + + +
-
+
2024
+-
+
+
- + + Jul 2024 + (131) + + + +
- + + Jun 2024 + (570) + + + +
- + + May 2024 + (245) + + + +
- + + Apr 2024 + (156) + + + +
- + + Mar 2024 + (90) + + + +
- + + Feb 2024 + (134) + + + +
- + + Jan 2024 + (309) + + + +
+
+ -
+
2023
+-
+
+
- + + Dec 2023 + (62) + + + +
- + + Nov 2023 + (326) + + + +
- + + Oct 2023 + (76) + + + +
- + + Sep 2023 + (315) + + + +
- + + Aug 2023 + (757) + + + +
- + + Jul 2023 + (2215) + + + +
- + + Jun 2023 + (778) + + + +
- + + May 2023 + (300) + + + +
- + + Apr 2023 + (1) + + + +
- + + Feb 2023 + (5) + + + +
- + + Jan 2023 + (1) + + + +
+
+ -
+
2022
+-
+
+
- + + Nov 2022 + (1) + + + +
- + + Oct 2022 + (2) + + + +
- + + Sep 2022 + (1) + + + +
- + + Aug 2022 + (1) + + + +
- + + Jul 2022 + (39) + + + +
- + + Jun 2022 + (23) + + + +
- + + May 2022 + (256) + + + +
+
+ -
+
2021
+-
+
+
- + + Dec 2021 + (1) + + + +
- + + Oct 2021 + (82) + + + +
- + + Jun 2021 + (1) + + + +
- + + Feb 2021 + (1) + + + +
- + + Jan 2021 + (2) + + + +
+
+ -
+
2020
+-
+
+
- + + Dec 2020 + (1) + + + +
- + + Nov 2020 + (2) + + + +
+
+ - + 01 July 2024 (9 messages) + + +
-
+ + ++ +
+
+ + +++ + + Joined. + + ++ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + No. Unfortunately, the stepping mechanism only works in the Debugger Mode (not VMI Mode). + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Not sure if I understand. Can you elaborate on what to be addressed in ntoskrnl? 🤔 + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + You can use the 'lm' command to get the base address of different modules. ++ + +
+
https://docs.hyperdbg.org/commands/debugging-commands/lm + ++ + lm (view loaded modules) | HyperDbg Documentation + ++ +Description of the 'lm' command in HyperDbg.
+ + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - + 02 July 2024 (11 messages) + + +
-
+ + ++ +
+
+ + +++ + + Joined. + + ++ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Hi, ++ + +
+
sorry for the late reply +
+
Actually there is a design issue with HyperDbg that whenever you clear an event, it cannot be removed immediately. Instead HyperDbg first disables the event and when you continue the debuggee (using the 'g' command) it removes it from the EPT page tables. So, you need to continue debuggee before applying next EPT hook. This design issue will be solved in the future but if you cannot continue the debuggee for any reason or you need to apply your new event immediately, then you can simply disable it (event d all) and HyperDbg won't trigger it for you anymore. + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + But if you removed it and you continue debuggee and pause it again, if the error happens again (while the hook is removed) it's potentially a bug that needs to be investigated. + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + So, it still shows this error? 🤨 + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Ah, got it. Could you create a GitHub issue for this? I'll try to investigate it hopefully tomorrow. + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + 👍 + ++ + +
+
+
+
+
+
+
+
+
- + 03 July 2024 (60 messages) + + +
-
+ + ++ +
+
+ + +++ + The '!monitor' command just changes the attributes of EPT page tables but the '!epthook' changes both EPT page table attributes and puts 0xcc (int3) breakpoints, but I think your target anti-hack method tries to read/write from the page table and compute the time it takes (probably by using RDTSC/RDTSCP) instructions which is performed normally if you just use '!monitor x' but if you use '!monitor rwx' then probably it detects !monitor too. Please take a look at these documentation explanations: ++ + +
+
Design of !epthook: +
https://docs.hyperdbg.org/design/features/vmm-module/design-of-epthook +
+
Design of !monitor: +
https://docs.hyperdbg.org/design/features/vmm-module/design-of-monitor + ++ + Design of !epthook | HyperDbg Documentation + ++ +Design of !epthook command
+ + +
+
+
+
+
+
+
+
+ -
+ + ++ +
+
+ + +++ + Int3 is hidden, if it's a user-mode process check, it shouldn't notice it 🤨 + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + No difference, it shouldn't notice it from the kernel mode too. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + It probably checks for the time it takes to respond to a memory read which will reveal that HyperDbg is monitoring that special page. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Otherwise, I can't think of a method to check the memory alteration for !epthook. 🤔 + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + It's actually possible in the VMM module to apply events immediately, but it's not exported to the user this way. Because the script engine IR generator is in the user-mode. If you want to do it, you can directly modify the source code and apply the event using a custom function. But, it's a really cool feature I think. 🤔 ++ + +
I'll add it to the future to-do list but it probably won't be ready soon since it needs fundamental design changes. +
+
One way around it is by using: +
+
event (with a pause() function) + g + new event +
+
So, once your script is running, it continues the debuggee immediately after applying the first event and when your event executes the pause() function, the debugger is paused and the second event will be created. (If you didn't understand what I mean by this, please let me know, I could elaborate it more). + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Exit script? What do you mean? Like disabling the event? 🤨 + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + There are a couple of functions for disabling/enabling and removing or short-circuiting events here: ++ + +
https://docs.hyperdbg.org/commands/scripting-language/functions/events + ++ + events | HyperDbg Documentation + ++ +Functions related to events
+ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + You can use them along with the $event_id pseudo-register. + ++ + + + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Like a function return? 🤨 + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + @xmaple555 implemented the functions logic, you can use it like a function. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + + + + +++ + Constants & Functions | HyperDbg Documentation + ++ +
Description of constants and functions
+ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + No, pause will pause the debugger immediately. Context is preserved. + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + You need to ask @xmaple555 to fix it, I don't know that much about the script engine parser. 🙂🙃 + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + What do you mean by dynamic calls calculation? 🤨 + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Wait, you cannot put two !monitors in one page? + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + I thought it's possible. 🤔 + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Not sure if I understand what you mean but !monitor receives (to/from) parameters from the script expressions: ++ + +
+
https://github.com/HyperDbg/HyperDbg/blob/a691c1df3be48660907fcf93840302a8c4650ff4/hyperdbg/libhyperdbg/code/debugger/commands/extension-commands/monitor.cpp#L204 + ++ + HyperDbg/hyperdbg/libhyperdbg/code/debugger/commands/extension-commands/monitor.cpp at a691c1df3be48660907fcf93840302a8c4650ff4 · HyperDbg/HyperDbg + ++ +State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
+ + +
+
+
+
+
+
+
+
+ -
+ + ++ +
+
+ + +++ + Which means you can calculate your addresses in global variables and use them as parameters to the !monitor. + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + E.g., !monitor .FromGlobalVar .FromGlobalVar+0x85 script { ... } + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Wait couldn't you put multiple !monitor hooks in one page? As long as I remember it was possible. 🤔🤔🤔 ++ + +
+
Not a big deal BTW, you can handle it through the script. +
+
E.g., check for your ranges within if conditions. $context pseudo-register contains the address of accessed memory address. However, I'm pretty sure we support multiple !monitor(s) on same page at some point. 🤔 + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ -
+ + ++ +
+
+ + +++ + Why don't you check ranges within if conditions? + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Like put a !monitor on an entire page, and check for the $context. + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + This one again could be handled from the by the method I told you earlier (pause()) + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + You can use global variables to check your $context with dynamic ranges. + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Maybe a combination of loops could help. + ++ + +
+
+
+
+
-
+ + ++ ++ +++ + if i was allowed to use monitors on same page, it would help a lot :) + ++ + + + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
- + 04 July 2024 (7 messages) + + + + + + +
-
+ + ++ +
+
+ + +++ + It's just the matter of handling complex logic of hooks in different pages. I'm so lazy to think about it since the algorithm of handling multiple hooks and events could become complex. 😅 + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + But sure, I'll add it to the future todo list. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Thanks for reporting it, I'll check it. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + I think it's shared between all drivers. I see caaes where it's not shared but if I remember it correctly, it's generally shared between different processes (but not sure). 🤔 + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Sure + ++ + +
+
+
+
+
- + 05 July 2024 (24 messages) + + +
-
+ + ++ +
+
+ + +++ + I was able to reproduce this error. ++ + + + +
+
https://github.com/HyperDbg/HyperDbg/issues/409 + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + It seems that it's because HyperDbg doesn't remove the !monitor hooks correctly when the address is not available in HyperDbg's address space. 🤔 + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Since this address is only valid in the target process memory, not HyperDbg's view of memory (cr3). + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Eduard Please switch to this branch and test it again: ++ + +
https://github.com/HyperDbg/HyperDbg/tree/fix-monitor-remove + ++ + GitHub - HyperDbg/HyperDbg at fix-monitor-remove + ++ +State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
+ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Test this one and ... + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + this one. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Both of them should be fixed. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + I changed the logic of clearing !monitor events. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Also please try to test it with different conditions and different ways if you can. At the moment it passed all of my tests but since the logic of clearing these kinds of events is changed, I might break it in some other ways, so performing a complete test would help a lot. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Once you've done testing it, please let me know so I'll merge it to the 'dev' branch. + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + That's great. I merged it to the 'dev' branch now. + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + Yep, this is what I told here: + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + . + ++ + +
+
+
+
+
+
+
+
+
-
+ + ++ +
+
+ + +++ + But generally you have tons of options, you could disable/enable events instead of clearing them. Or use a nop+jmp infinite loop at the @RIP register. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + This one is really hard to solve. 😅 ++ + +
+
In HyperDbg we use NMIs for halting cores. This mechanism should be changed to IPIs instead of NMIs. +
The reason why it doesn't support immediately clearing of events is because we might halt the core in the middle of handling an event and conclude to remove them. In that case, the event will trigger BSOD since its structures are freed. But, using IPIs will make sure that handling one event will be finished, and then another VM-exit happens which will halt the core. + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Using IPIs by itself is okay but since HyperDbg is highly dependent on NMIs, changing it to IPIs will probably break lots of its functionalities. That's why I didn't dare to change it to IPIs yet. 😅 + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
- + 06 July 2024 (8 messages) + + +
-
+ + ++ +
+
+ + +++ + Anyone tried hyperdbg gui? + ++ + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + It's not ready yet. These days I'm working on it together with another team member. I'll let you guys know once it's finished. + ++ + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
- + 07 July 2024 (12 messages) + + +
-
+ + ++ +
+
+ + +++ + Didn't get it 🤔 ++ + +
It doesn't work with 1 in the '!monitor'? + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Could you please make a GitHub issue with the sequence of commands I could reproduce the error? ++ + +
If there are multiple ways of reproducing error (e.g., it crashes with both 1 and 3 length) make sure to include all sequences separately so all of them will be fixed. + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + Hello guys, I need some help here ++ + + + +
+
I'm trying to install EfiGaurd to disable PatchGaurd in my local machine, +
But I cannot find the option to add a boot option, or enter the boot setup. +
+
I disabled the secure boot and make it legacy, but the problem still the same. + +
+
+
+
+ -
+ + ++ +
+
+ + +++ + My laptop is Lenovo IdeaPad + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + @Mattiwatti The original author is in the group but not sure if he still checks his Telegram since he rarely uses this app. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Yeah, the last seen is long time ago + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Is there's any other option to disable the PatchGaurd in my local machine + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + As long as I remember, you could boot EfiGuard from a USB. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + BTW, why do you need to disable PatchGuard? The only command that is not PatchGuard compatible in HyperDbg is the '!syscall'. Are you going to intercepts system-calls? + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + Other commands are perfectly fine with PatchGuard. + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + No actually I'm going to use the !epthook command, but I faced a problem that the command cannot identify the system call function that I passed to it, so I thought it's a problem related to PatchGaurd + ++ + +
+
+
+
+
-
+ + ++ +
+
+ + +++ + I'm using it in the VMI, with script of course + ++ + +
+
+
- + + 01 Jul 2024 (9) + + + +
- + + 02 Jul 2024 (11) + + + +
- + + 03 Jul 2024 (60) + + + +
- + + 04 Jul 2024 (7) + + + +
- + + 05 Jul 2024 (24) + + + +
- + + 06 Jul 2024 (8) + + + +
- + + 07 Jul 2024 (12) + + + +
- + + Jul 2024 + (131) + + + +
- Jun 2024 - (489) + (570) @@ -316,36 +323,38 @@
- - 01 June 2024 (1 messages) +
- + 01 July 2024 (9 messages) -
-
-
+
- OK,thank you + + Joined. +@@ -355,36 +364,34 @@2020
-- - 03 June 2024 (3 messages) -
- -+
+
- - Joined. - + No. Unfortunately, the stepping mechanism only works in the Debugger Mode (not VMI Mode).@@ -394,32 +401,34 @@2020
-+
+
- - Joined. - + Not sure if I understand. Can you elaborate on what to be addressed in ntoskrnl? 🤔@@ -429,32 +438,32 @@2020
-- - Joined. - + is there a kernel base address variable?(example @rax)@@ -464,76 +473,80 @@2020
-- - 04 June 2024 (75 messages) -
- -
+
- - Joined. - + You can use the 'lm' command to get the base address of different modules. ++
+
https://docs.hyperdbg.org/commands/debugging-commands/lm+ + lm (view loaded modules) | HyperDbg Documentation + ++Description of the 'lm' command in HyperDbg.
+ + +-
-
- Guys, -@@ -543,34 +556,41 @@
Has anyone previously seen any sample of setting up a TSS (Task State Segment) for a hypervisor? -
-
https://github.com/HyperDbg/HyperDbg/blob/834b43ece965c75bd65761386384a539bd1a3973/hyperdbg/hprdbghv/code/memory/Segmentation.c#L123C5-L123C6 + + Joined. +2020
--
-
- Been working on setting a separate TSS (instead of Windows TSS) for HyperDbg, but not sure if I correctly implemented it since the interrupt stack is not within the range. 🤔 + @HughEverett +@@ -580,34 +600,30 @@
1: kHyperDbg> !monitor x 017CA56B l 10 script { +
> printf("%s %s DYN CALL TO %x\n",$date, $time, dd(eax+8)); +
> } +
err, the page modification is not applied, make sure that you don't put multiple EPT Hooks or Monitors on a single page (c0000026) +
+
1: kHyperDbg> g +
debuggee is running... +
fffff801`17de1282 0F 01 C1 vmcall +
+
0: kHyperDbg> events +
no active/disabled events2020
--
-
- It still perfectly works but if we're unsure about the correctness of the implementation, it probably causes weird problems in the future. + shall i remove monitor different way than event c all ?@@ -617,40 +633,30 @@2020
--
-
- (05:19:52.472 - core : 0 - vmx-root? no) [+] Information (SegmentPrepareHostGdt:123) | Host Interrupt Stack, from: ffffe58189199000, to: ffffe5818919cff0 -@@ -660,51 +666,48 @@
(05:19:52.472 - core : 1 - vmx-root? no) [+] Information (SegmentPrepareHostGdt:123) | Host Interrupt Stack, from: ffffe581891ab000, to: ffffe581891aeff0 -
(05:19:52.472 - core : 3 - vmx-root? no) [+] Information (SegmentPrepareHostGdt:123) | Host Interrupt Stack, from: ffffe581891cf000, to: ffffe581891d2ff0 -
(05:19:52.472 - core : 2 - vmx-root? no) [+] Information (SegmentPrepareHostGdt:123) | Host Interrupt Stack, from: ffffe581891bd000, to: ffffe581891c0ff0 -
-
(05:24:27.278 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:177) | Host exception, RIP=fffff804383f5a8e, RSP=ffffe58189192ed0, Vector=3 -
(05:24:27.333 - core : 1 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:177) | Host exception, RIP=fffff804383f5a8e, RSP=ffffe581891a4ed0, Vector=3 -
(05:24:27.259 - core : 2 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:177) | Host exception, RIP=fffff804383f5a8e, RSP=ffffe581891b6ed0, Vector=3 -
(05:24:27.278 - core : 3 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:177) | Host exception, RIP=fffff804383f5a8e, RSP=ffffe581891c8ed0, Vector=3 + (i applied different script before on same addr)2020
-- + 02 July 2024 (11 messages) +
+ +2020
- ↶ Reply to #6420 + ↶ Reply to #7001 - #6425 + #7006 - 01:03 PM, 04 Jun 2024 + 05:47 PM, 02 Jul 2024- @honorary_bot do have any idea about this? + Hi, +@@ -741,7 +748,7 @@
+
sorry for the late reply +
+
Actually there is a design issue with HyperDbg that whenever you clear an event, it cannot be removed immediately. Instead HyperDbg first disables the event and when you continue the debuggee (using the 'g' command) it removes it from the EPT page tables. So, you need to continue debuggee before applying next EPT hook. This design issue will be solved in the future but if you cannot continue the debuggee for any reason or you need to apply your new event immediately, then you can simply disable it (event d all) and HyperDbg won't trigger it for you anymore.2020
-
@@ -757,18 +764,18 @@ 2020
- ↶ Reply to #6424 + ↶ Reply to #7001 - #6426 + #7007 - 01:08 PM, 04 Jun 2024 + 05:48 PM, 02 Jul 2024- The problem here is that the exception stack is not within the core's allocated range. + But if you removed it and you continue debuggee and pause it again, if the error happens again (while the hook is removed) it's potentially a bug that needs to be investigated.@@ -778,32 +785,30 @@2020
--
-
- I don’t remember from top of my head, gonna have to recheck in the evening. So you’ve set up tss stack pointers, but the exception stack is switched to something different in exception? + yea.. i ran debugger again after clearing@@ -813,7 +818,7 @@2020
-
@@ -829,18 +834,18 @@ 2020
- ↶ Reply to #6427 + ↶ Reply to #7008 - #6428 + #7009 - 01:08 PM, 04 Jun 2024 + 06:00 PM, 02 Jul 2024- Yes, exactly + So, it still shows this error? 🤨@@ -850,32 +855,30 @@2020
--
-
- As stack grows downward, probably I should put the latest (aligned byte address) of the stack. But it seems that Intel didn't mention it. So, not sure whether I should put the base address or the end of the stack. + lemme try again@@ -885,67 +888,128 @@2020
-
hook 1 +
1: kHyperDbg> !monitor x 760858a0 l 4 script { +
> printf("WS2SEND TRIGGERED\n"); +
> } +
+
1: kHyperDbg> g +
debuggee is running... +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
WS2SEND TRIGGERED +
fffff804`33ca1282 0F 01 C1 vmcall +
+
0: kHyperDbg> event c all +
+
0: kHyperDbg> g +
debuggee is running... +
fffff804`33ca1282 0F 01 C1 vmcall +
events empty +
1: kHyperDbg> events +
no active/disabled events +
here i forgot to switch process +
1: kHyperDbg> !monitor x 760858a0 l 4 script { +
> printf("WS2SEND TRIGGERED AGAIN\n"); +
> } +
err, invalid address (c0000005) +
address may be paged-out or unavailable on the page table due to 'demand paging' +
please refer to https://docs.hyperdbg.org/tips-and-tricks/considerations/accessing-invalid-address for further information +
+
1: kHyperDbg> process pid 22e0 +
press 'g' to continue the debuggee, if the pid or the process object address is valid then the debuggee will be automatically paused when it attached to the target process +
+
1: kHyperDbg> g +
debuggee is running... +
switched to the specified process +
ntkrnlmp!KiSwapThread+0x81b: +
fffff804`36c4164b 45 33 C0 xor r8d, r8d +
hook2 +
0: kHyperDbg> !monitor x 760858a0 l 4 script { +
> printf("WS2SEND TRIGGERED AGAIN\n"); +
> } +
err, the page modification is not applied, make sure that you don't put multiple EPT Hooks or Monitors on a single page (c0000026) +
+
0: kHyperDbg>+ + Accessing Invalid Address | HyperDbg Documentation + ++Considerations for accessing memory in different modes
+ + +-
+
- Do you index cores by apic id? + Ah, got it. Could you create a GitHub issue for this? I'll try to investigate it hopefully tomorrow.@@ -955,42 +1019,49 @@2020
-hook 1 1: kHyperDbg> !monitor x 760858a0 l 4 script { printf("WS2SEND TRIGGERED\n"); } 1: kHyperDbg> g debuggee is running... WS2SEND TRIGGERED WS2SEND TRIGGERED WS2SEND TRIGGERED W...
+ + +
@@ -1006,18 +1077,18 @@ 2020
- ↶ Reply to #6431 + ↶ Reply to #7013 - #6433 + #7014 - 01:11 PM, 04 Jun 2024 + 06:19 PM, 02 Jul 2024- By KeGetCurrentProcessorNumberEx, not sure if it's based on APIC ID or not. + 👍@@ -1027,32 +1098,30 @@2020
-2020
-- + 03 July 2024 (60 messages) +
+ +
@@ -1078,53 +1151,66 @@ 2020
- ↶ Reply to #6434 + ↶ Reply to #7015 - #6435 + #7016 - 01:18 PM, 04 Jun 2024 + 05:25 AM, 03 Jul 2024- But both VMCS HOST IDT exception handler and the code that I wrote use the same core number, so does it make any difference? 🤔 + The '!monitor' command just changes the attributes of EPT page tables but the '!epthook' changes both EPT page table attributes and puts 0xcc (int3) breakpoints, but I think your target anti-hack method tries to read/write from the page table and compute the time it takes (probably by using RDTSC/RDTSCP) instructions which is performed normally if you just use '!monitor x' but if you use '!monitor rwx' then probably it detects !monitor too. Please take a look at these documentation explanations: ++
+
Design of !epthook: +
https://docs.hyperdbg.org/design/features/vmm-module/design-of-epthook +
+
Design of !monitor: +
https://docs.hyperdbg.org/design/features/vmm-module/design-of-monitor+ + Design of !epthook | HyperDbg Documentation + ++Design of !epthook command
+ + +-
-
- You're right, just wanted to make sure + I see. Im pretty sure, that antihack finds int3, it even tells you that process was altered, probably some md5 calculations or smth like that.@@ -1134,32 +1220,34 @@2020
--
+
- Wait a sec, you were asking about TSS first, but then you're talking about IDT and exceptions + Int3 is hidden, if it's a user-mode process check, it shouldn't notice it 🤨@@ -1169,32 +1257,30 @@2020
--
-
- Also, which exception are you testing? + Antihack sits on ring0@@ -1204,34 +1290,30 @@2020
--
-
- Vector number 3 (#BP) + If I put either BP or !epthook after some time it pops up telling that process or antihack was altered and shuts down everything. The only thing - it's not instant, I can manage to catch some bps/hooks until that thing finds out them.@@ -1241,7 +1323,7 @@2020
-
@@ -1257,18 +1339,18 @@ 2020
- ↶ Reply to #6439 + ↶ Reply to #7019 - #6440 + #7021 - 01:25 PM, 04 Jun 2024 + 07:36 AM, 03 Jul 2024- A breakpoint within VMX-root mode. + No difference, it shouldn't notice it from the kernel mode too.@@ -1278,57 +1360,32 @@2020
--
+
- PULSE_STATUS VmUtilAllocateStack(uint64_t aStackSize, uint64_t *aStackBase) -@@ -1338,32 +1395,32 @@
{ -
if (aStackBase == NULL) -
return PULSE_STATUS_INVALID_PARAMETER; -
-
if ((aStackSize < PAGE_4K_SIZE) || (aStackSize > g_vmm.LoaderParams.CoreRegionSize)) -
return PULSE_STATUS_INVALID_PARAMETER; -
-
*aStackBase = PoolAllocPages(aStackSize / PAGE_4K_SIZE); -
if (*aStackBase == NULL) -
return PULSE_STATUS_INSUFFICIENT_RESOURCES; -
-
return PULSE_STATUS_SUCCESS; -
} -
-
PULSE_STATUS VmUtilAllocateInitStack(uint64_t aStackSize, uint64_t *aStackBase) -
{ -
PULSE_STATUS status = PULSE_STATUS_SUCCESS; -
status = VmUtilAllocateStack(aStackSize, aStackBase); -
if (status != PULSE_STATUS_SUCCESS) -
return status; -
-
*aStackBase = *aStackBase + (aStackSize - 8); -
-
return PULSE_STATUS_SUCCESS; -
} + It probably checks for the time it takes to respond to a memory read which will reveal that HyperDbg is monitoring that special page.2020
--
+
- If it helps + Otherwise, I can't think of a method to check the memory alteration for !epthook. 🤔@@ -1373,41 +1430,30 @@2020
--
-
- pTss->Rsp0 = pHostCpu->Stack; -@@ -1417,34 +1463,30 @@
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST1)); -
if (status != PULSE_STATUS_SUCCESS) -
return status; -
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST2)); -
if (status != PULSE_STATUS_SUCCESS) -
return status; -
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST3)); -
if (status != PULSE_STATUS_SUCCESS) -
return status; + Could be... well, anyway I'm fine with monitor, just takes longer time do debug2020
--
-
- Can you also share what you configured for HOST_GDT_BASE and how you configured other fields of pTss? + Ah, wanted to ask, is it possible to set monitor from script(i mean its possible with current architecture)? I have dynamic calls, which I can calculate only in runtime.@@ -1454,32 +1496,30 @@2020
-2020
-
@@ -1505,18 +1545,25 @@ 2020
- ↶ Reply to #6443 + ↶ Reply to #7025 - #6446 + #7027 - 01:32 PM, 04 Jun 2024 + 05:24 PM, 03 Jul 2024- Just wanna re-check it with my configuration since I did the exact same config but it seems the stack RSP of exception is not within range for some other reasons. + It's actually possible in the VMM module to apply events immediately, but it's not exported to the user this way. Because the script engine IR generator is in the user-mode. If you want to do it, you can directly modify the source code and apply the event using a custom function. But, it's a really cool feature I think. 🤔 +@@ -1526,7 +1573,7 @@
I'll add it to the future to-do list but it probably won't be ready soon since it needs fundamental design changes. +
+
One way around it is by using: +
+
event (with a pause() function) + g + new event +
+
So, once your script is running, it continues the debuggee immediately after applying the first event and when your event executes the pause() function, the debugger is paused and the second event will be created. (If you didn't understand what I mean by this, please let me know, I could elaborate it more).2020
-
@@ -1542,18 +1589,18 @@ 2020
- ↶ Reply to #6445 + ↶ Reply to #7026 - #6447 + #7028 - 01:32 PM, 04 Jun 2024 + 05:24 PM, 03 Jul 2024- No, just the value of HOST_GDTR_BASE + Exit script? What do you mean? Like disabling the event? 🤨@@ -1563,44 +1610,54 @@2020
-
https://docs.hyperdbg.org/commands/scripting-language/functions/events+ + events | HyperDbg Documentation + ++Functions related to events
+ + +
@@ -1616,53 +1673,73 @@ 2020
+ ↶ Reply to #7029 + - #6449 + #7030 - 01:33 PM, 04 Jun 2024 + 05:30 PM, 03 Jul 2024- Since we previously use Windows GDT and IDT as Host GDT and IDT, right now I changed the implementation to configure our own GDT, IDT. + You can use them along with the $event_id pseudo-register.+ +-
-
- Yeah, but what structy is it in? + no.. sample from my script: +@@ -1672,32 +1749,30 @@
+
n = check_address(edx+c); +
k = 0; +
if (n == 1){ +
printf("%s %s DYN CALL TO %x\n",$date, $time, dd(edx+c)); +
k = 1; +
} else { +
printf("%s %s DYN CALL, BUT FAILED TO DECODE %x\n",$date, $time, edx+c); +
return here as memory is invalid, so no longer processing needed +
} +
if (k == 1){....2020
--
-
- or is it gdtr reg? + it would improve scripting a lot i think, no additional if branches@@ -1707,7 +1782,7 @@2020
-
@@ -1723,18 +1798,18 @@ 2020
- ↶ Reply to #6451 + ↶ Reply to #7031 - #6452 + #7033 - 01:34 PM, 04 Jun 2024 + 05:39 PM, 03 Jul 2024- GDTR reg (for host) needs to have some entries (and the TSS should be here). + Like a function return? 🤨@@ -1744,32 +1819,30 @@2020
--
-
- The TSS itself has other bits (in its entry on GDT, like LowSegmentLimit etc. ) I'm not sure if I correctly configured that. + yup@@ -1779,34 +1852,32 @@2020
--
-
- Since basically I did the same in HyperDbg but still the stack is not within the expected range, I think it might be an issue with the actual TSS entry configuration in GDT. + i understand, but pause will loose context in this case..@@ -1816,32 +1887,34 @@2020
--
+
- Let me step back a bit. It is still not clear to me what you're trying to achieve. + @xmaple555 implemented the functions logic, you can use it like a function.@@ -1851,13359 +1924,7 @@2020
-- -
- - - -- -- -
-
- - --- - Sp you set up a dedicated gdtr for vmx root mode, right? - -- - -- -
- - - -- -- -
-
- - --- - Yes - -- - -- -
- - - -- -- -
-
- - --- - Then the OS runs in a vmx non root (guest) mode, right? - -- - -- -
- - - -- -- -
-
- - --- - Yes - -- - -- -
- - - -- -- -
-
- - --- - So, you want to trap a breakpoint, but does it occur in vmx root on vmx non root mode? - -- - -- -
- - - -- -- -
-
- - --- - And I wanted to build a dedicated gdt for Host. - -- - -- -
- - - -- -- -
-
- - --- - It occurs in vmx root mode. - -- - -- -
- - - -- -- -
-
- - --- - You have also filled vmcs like this? -- - -
if (__vmx_vmwrite(VMCE_HOST_GDTR_BASE, g_vmm.pCpu[CpuSlot].HostCpu.DescTables) != 0) -
return PULSE_STATUS_VMWRITE_FAILED; -
if (__vmx_vmwrite(VMCE_HOST_IDTR_BASE, g_vmm.pCpu[CpuSlot].HostCpu.InterruptDesc) != 0) -
return PULSE_STATUS_VMWRITE_FAILED; -
if (__vmx_vmwrite(VMCE_HOST_TSS_BASE, g_vmm.pCpu[CpuSlot].HostCpu.Tss) != 0) -
return PULSE_STATUS_VMWRITE_FAILED; - -- -
- - - -- -- -
-
- - --- - Since we configured TSS stack for IST3, the breakpoint should be handled with host ID (the one dedicated to HyperDbg) but the rsp of the arrived breakpoint is not within the expected range. - -- - -- -
- - - -- -- -
-
- - --- - Is your root mode operating in Rind0 mode? - -- - -- -
- - - -- -- -
-
- - --- - Ignore the structs, the just should be some address - -- - -- -
- - - -- -- -
-
- - --- - Yes exactly. And what I need is how you filled/configureed g_vmm.pCpu[CpuSlot].HostCpu.Tss and g_vmm.pCpu[CpuSlot].HostCpu.DescTable. - -- - -- -
- - - -- -- -
-
- - --- - ? - -- - -- -
- - - -- -- -
-
- - --- - // Task entries -- - -
uint64_t tssAddr = &(pIdtEntry[256]); -
PCPU_TSS_DESCRIPTOR64 pTssEntry = (PCPU_TSS_DESCRIPTOR64)(&(pGdtEntry[VMM_HOST_TASK_SEG_DESC_NUM])); -
pTssEntry->P = 1; -
pTssEntry->S = 0; -
pTssEntry->Type = SYS_SEG_TYPE_AVAIL_TSS64; -
pTssEntry->LimitLow = sizeof(CPU_TSS64); -
pTssEntry->LimitHigh = 0; -
pTssEntry->BaseLow = tssAddr & 0xFFFF; -
pTssEntry->BaseMid = (tssAddr >> 16) & 0xFF; -
pTssEntry->BaseHigh = (tssAddr >> 24) & 0xFF; -
pTssEntry->BaseAddrHigh64 = (tssAddr >> 32) & 0xFFFFFFFF; -
pTssEntry->AVL = 0; -
pTssEntry->G = 0; -
pTssEntry->DPL = 0; -
pTssEntry->DB = 0; -
pTssEntry->L = 0; -
-
// TSS -
pHostCpu->Tss = tssAddr; -
PCPU_TSS64 pTss = (PCPU_TSS64)(tssAddr); -
pTss->IoMapBaseAddress = 100; // 104 ? -
pTss->Rsp0 = pHostCpu->Stack; -
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST1)); -
if (status != PULSE_STATUS_SUCCESS) -
return status; -
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST2)); -
if (status != PULSE_STATUS_SUCCESS) -
return status; -
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST3)); -
if (status != PULSE_STATUS_SUCCESS) -
return status; - -- -
- - - -- -- -
-
- - --- - Rind0 mode? - -- - -- -
- - - -- -- -
-
- - --- - ring 0 - -- - -- -
- - - -- -- -
-
- - --- - Yes, but curious to know, could run in any different modes? 🤨 - -- - -- -
- - - -- -- -
-
- - --- - Well that's why it's working like that - -- - -- -
- - - -- -- -
-
- - --- - You have no ring transition - -- - -- -
- - - -- -- -
-
- - --- - You're already in ring 0 - -- - -- -
- - - -- -- -
-
- - --- - So no stack switch for you - -- - -- -
- - - -- -- -
-
- - --- - Of course you could run VMX root ring 3 - -- - -- -
- - - -- -- -
-
- - --- - But it's a breakpoint (so shouldn't it use Tss.IST3?) - -- - -- -
- - - -- -- -
-
- - --- - Didn't knew that 😳 - -- - -- -
- - - -- -- -
-
- - --- - Like a user-mode application running in VMX root mode? - -- - -- -
- - - -- -- -
-
- - --- - From top of my head - only NMIs, double faults and smth else would have a separate stack - -- - -- -
- - - -- -- -
-
- - --- - Don't really remember about int3, but it makes sense not to switch the stack for it - -- - -- -
- - - -- -- -
-
- - --- - You can create an operating system running in VMX root, right? It would have both kernel and user mode - -- - -- -
- - - -- -- -
-
- - --- - Ah, if it's the way you say, then that's why the stack is not within the range. - -- - -- -
- - - -- -- -
-
- - --- - yes, it just uses your current rsp - -- - -- -
- - - -- -- -
-
- - --- - So, basically the implementation is correct. - -- - -- -
- - - -- -- -
-
- - --- - So stack switch is for NMI, DebugOrTrap (int1 though, not 3), double fault, machine check - -- - -- -
- - - -- -- -
-
- - --- - It makes sense to swap stack for int1, because you can trap task switcch with debug registers - -- - -- -
- - - -- -- -
-
- - --- - but int3 is just a code breakpoint - -- - -- -
- - - -- -- -
-
- - --- - Makes sense. - -- - -- -
- - - -- -- -
-
- - --- - Anyway, thank you for always being helpful. You saved me a lot of time for this. - -- - -- -
- - - -- -- -
-
- - --- - No problem! - -- - -- -
- - - -- -- -
-
- - --- - - -- - -- - sticker.webp - -- -- - 05 June 2024 (2 messages) -
- -- -
- - - -- -- -
-
- - --- - Hello everyone, -- - -
-
I've made a somehow big update in the HyperDbg. Now, it utilizes a dedicated HOST IDT and HOST GDT, different than the Windows IDT/GDT. This update will address a specific category of bypasses for HyperDbg, although there are still many bypasses to address. This change influences the handling of interrupts, especially NMIs for halting cores in VMX root-mode. lt may introduce instability issues in various systems, potentially leading to crashes. If you're using HyperDbg, please switch to the 'dev' branch and re-build and test it to help us identify any problems. Currently, it works well on my 12th Gen machine, but I'm uncertain if it's universally stable. If you encounter any crashes or BSODs, please notify me before the release of v0.9 (the next version). The best way to test it is using events (EPT hooks) with a high rate of execution (e.g., using !epthook on nt!ExAllocatePoolWithTag and meanwhile pause the debuggee). -
-
The 'dev' branch: -
https://github.com/HyperDbg/HyperDbg/tree/dev -
-
GitHub built artifact for those who can't build: -
https://github.com/HyperDbg/HyperDbg/actions/runs/9384856535 - -- - GitHub - HyperDbg/HyperDbg at dev - -- -State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
- - -- -
- - - -- -- -
-
- - --- - None - -- - -- - 06 June 2024 (3 messages) -
- - - - - -- -
- - - -- -- -
-
- - --- - One more thing to mention, if you guys encounter "invalid address error", this new instruction is for fixing it: -- - -
-
https://docs.hyperdbg.org/tips-and-tricks/considerations/accessing-invalid-address - -- - Accessing Invalid Address | HyperDbg Documentation - -- -Considerations for accessing memory in different modes
- - -- -
- - - -- -- -
-
- - --- - The primary difference is that previously (before v0.9), the '.pagein' command doesn't guarantee locking all the cores and immediately after the '.pagein' command, you couldn't apply any events (e.g., !epthook or !monitor) but since HyperDbg uses a dedicated Host IDT at its newest version, it is guaranteed to lock all the cores after running the '.pagein' command. Hence, you shouldn't have any problem applying events after forcing OS to bring the pages into the page-table or make them present in the current process's memory. - -- - -- - 08 June 2024 (3 messages) -
- - - - - -- -
- - - -- -- -
-
- - --- - Hi guys! -- - - - -
-
As a new feature, starting from v0.9 HyperDbg will support monitoring EPT hooks on physical addresses (previously it only supported virtual addresses), mainly through the 'MemoryType' parameter. You can now use it from the 'dev' branch. -
-
https://docs.hyperdbg.org/commands/extension-commands/monitor - -- -
- - - -- -- -
-
- - --- - This is mainly useful for those who want to monitor PCIe buffers. - -- - -- - 09 June 2024 (5 messages) -
- - - - - -- -
- - - - - - - -- -- -
-
- - --- - HyperDbg v0.9 is released! ✨ -- - -
-
It features monitoring physical addresses for tracking read/write to PCI-e and IOMMU buffers. Plus, HyperDbg now uses a dedicated Host IDT/GDT. -
-
🔗 Check it out: https://github.com/HyperDbg/HyperDbg/releases/tag/v0.9.0 -
-
📖 Read more: -
https://docs.hyperdbg.org/commands/extension-commands/monitor -
-
# Added -
- The !monitor command now physical address hooking -
- hwdbg is merged to HyperDbg codebase -
- strncmp(Str1, Str2, Num), and wcsncmp(WStr1, WStr2, Num) functions in script engine -
-
# Changed -
- Using a separate HOST IDT in VMCS (not OS IDT) -
- Using a dedicated HOST GDT and TSS Stack -
- Checking for race-condition of not locked cores before applying instant-events and switching cores -
- The error message for invalid address is changed (more information) -
- Fix the problem of not locking all cores after running the '.pagein' command - -- - Release v0.9.0 · HyperDbg/HyperDbg - -- -HyperDbg v0.9.0 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 ...
- - -- -
- - - - - - - -- -- -
-
- - --- - - Joined. - - -- - -- - 10 June 2024 (2 messages) -
- - - - - - - - - -- - 12 June 2024 (1 messages) -
- - - - - -- - 13 June 2024 (98 messages) -
- -- -
- - - -- -- -
-
- - --- - HyperDbg supports debugging 32-bits apps. You just need to use special commands (e.g., 'u32' instead of 'u' for disassembling codes), but in case if you use the wrong command ('u32' on a 64-bit app or 'u' on a 32-bit app, it will show a message and notify you. Other than everything is similar to debugging a 64 bit app. - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - About kernel modules, is there any 32 bit driver on a 64 bit machine? If I remember correctly that's not possible in Windows. 🤔 - -- - -- -
- - - -- -- -- --- - here is screen from process monitor, i dont see those modules neither in user or kernel mode - -- - - - -- -
- - - -- -- -
-
- - --- - @HughEverett hey man! I don’t know why I recalled it now, but remember you were asking about vmx root ring3 mode? The obvious example is when you’re running VMware workstation on windows. When you launch a VM, your Windows becomes a vmx root, right? That basically means it keeps working in vmx root, while still having kernel and user modes ;) - -- - -- -
- - - -- -- -
-
- - --- - Not sure if I understand it correctly, what is this screen? - -- - -- -
- - - -- -- -
-
- - --- - HyperDbg doesn't support 32 bit operating systems but it fully supports 32 bit applications in 64 bit operating systems. - -- - -- -
- - - -- -- -
-
- - --- - Oh, that's interesting. Initially I thought that they virtualize the entire system and handle these things from Host Kernel-mode, but this kind of design (using Host User-mode) is really cool. 👌 - -- - -- -
- - - -- -- -- --- - here is full screen. guest is w10 x64. process monitor shows all loaded modules by particular process (like WSOCK32.dll in which im interested), but i cant find any reference to it in hpyerdbg - -- - - - -- -
- - - - - - - - - - - -- -- -
-
- - --- - Did you try the 'lm' command in HyperDbg? Isn't it what you need? -- - -
-
https://docs.hyperdbg.org/commands/debugging-commands/lm - -- - lm (view loaded modules) | HyperDbg Documentation - -- -Description of the 'lm' command in HyperDbg.
- - -- -
- - - -- -- -
-
- - --- - The 'lm' command has a 'pid' argument, did you try that? -- - -
-
By default if you're in the context of hyperdbg-cli.exe then it shows the modules of the hyperdbg process. You can check it by using the '.process' command. - -- -
- - - - - - - -- -- -
-
- - --- - HyperDbg> lm um m kernel pid 1240 -- - -
user mode -
start entrypoint path -
-
00007ffd88860000 00007ffd888770d0 C:\Windows\System32\KERNEL32.DLL -
00007ffd865f0000 00007ffd865f92c0 C:\Windows\System32\KERNELBASE.dll - -- -
- - - - - - - -- -- -
-
- - --- - Use it like: lm m sock pid 1cb0 - -- - -- -
- - - - - - - - - - - - - - - -- -- -
-
- - --- - You mean the process uses some kind of anti-debugging techniques? - -- - -- -
- - - -- -- -
-
- - --- - HyperDbg simply reads the user mode modules list from PEB but it's highly probable that due to an anti-debugging technique the process hides it's PEB. - -- - -- -
- - - - - - - -- -- -
-
- - --- - WSOCK32.dll is user module, so you can simply read it's address from any other processes. - -- - -- -
- - - -- -- -
-
- - --- - The addresses remain constant in Windows (before you restart), which is in contrast to Linux (which creates new ASLR addresses each time you run a new process). - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - Yep, that's interesting. I don't have any idea where they gather their user-mode modules list. 🤔 - -- - -- -
- - - - - - - - - - - - - - - -- -- -
-
- - --- - Also, if you have problem loading symbol files for your target process, try to run a similar 32-bit process (that loads WSOCK32.dll) and then HyperDbg even if you switch to other processes, still uses the old symbol table. Which will be useful for your case. - -- - -- -
- - - - - - - - - - - - - - - - - - - - - - - -- -- -
-
- - --- - Does it work? Is your process corrupting symbol hashes? - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - Are you sure the address is valid? - -- - -- -
- - - - - - - - - - - - - - - - - - - - - - - -- -- -
-
- - --- - Did you check this? https://docs.hyperdbg.org/tips-and-tricks/considerations/accessing-invalid-address - -- - -- - Accessing Invalid Address | HyperDbg Documentation - -- -Considerations for accessing memory in different modes
- - -- -
- - - - - - - -- -- -
-
- - --- - Are you sure that you're using the latest version v0.9? - -- - -- -
- - - -- -- -
-
- - --- - I'm pretty sure I changed the error message for invalid access - -- - -- -
- - - - - - - -- -- -
-
- - --- - Once you run HyperDbg it shows the version + build. - -- - -- -
- - - - - - - - - - - - - - - -- -- -
-
- - --- - Could you test the same command (which restarts your computer immediately) with v0.9? - -- - -- -
- - - - - - - -- -- -
-
- - --- - Crashed? - -- - -- -
- - - - - - - -- -- -
-
- - --- - No BSOD? Just restart? - -- - -- -
- - - -- -- -
-
- - --- - 🤔 - -- - -- -
- - - -- -- -
-
- - --- - Could you change the flag of the '.pagein'? -- - -
-
Use it like: -
.pagein u Address -
-
And if it crashed again: -
.pagein pf Address -
-
https://docs.hyperdbg.org/commands/meta-commands/.pagein - -- - .pagein (bring the page into the RAM) | HyperDbg Documentation - -- -Description of the '.pagein' command in HyperDbg.
- - -- -
- - - -- -- -
-
- - --- - I'm gonna see whether it's a #PF misconfiguration or a VMware error. Because generally, we're just injecting page-fault, it shouldn't crash the vCpu. 🤔 - -- - -- -
- - - -- -- -
-
- - --- - And one more thing, are you sure that you're using the '.pagein' in a valid process? - -- - -- -
- - - -- -- -
-
- - --- - I mean you might accidentally inject the page-fault while HyperDbg is in its own process (hyperdbg-cli.exe), in this case, a crash is inevitable. - -- - -- -
- - - -- -- -
-
- - --- - Since the address is not valid/assigned in hyperdbg-cli.exe's CR3. - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - You could check the current process by using the '.process' command. - -- - -- -
- - - - - - - -- -- -
-
- - --- - And it also crashes without 'u' in the '.pagein'? - -- - -- -
- - - -- -- -
-
- - --- - I think I understand the problem. This crash happens probably because you halted the process in the kernel-mode right before switching to another process. - -- - -- -
- - - - - - - -- -- -
-
- - --- - @HughEverett seems like you have a symbol engine. Do you use MS DIA? - -- - -- -
- - - -- -- -
-
- - --- - You need to grab the execution in other ways (other than using .process). - -- - -- -
- - - - - - - -- -- -
-
- - --- - Do you start the process using the '.start' command? - -- - -- -
- - - -- -- -
-
- - --- - Could you try to start it with the '.start' command? and once HyperDbg halted your process, reaching to the entry point, use the '.pagein'. - -- - -- -
- - - -- -- -
-
- - --- - Yes, HyperDbg uses DIA SDK. - -- - -- -
- - - -- -- -
-
- - - - - --- - .start (start a new process) | HyperDbg Documentation - -- -Description of the '.start' command in HyperDbg.
- - -- -
- - - -- -- -
-
- - --- - Or if you can halt the process any other ways, like putting breakpoint somewhere or any other methods, then use the '.pagein'. I think the problem is with the state we intercept the execution using the '.process' command. 🤔 - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - One option is using the '!monitor' command with 'x' attribute on the memory range of the main module of the target process. In this case, if you're main module fetches instructions, then HyperDbg halts debuggee for you. -- - -
-
https://docs.hyperdbg.org/commands/extension-commands/monitor - -- - !monitor (monitor read/write/execute to a range of memory) | HyperDbg Documentation - -- -Description of the '!monitor' command in HyperDbg.
- - -- -
- - - - - - - -- -- -
-
- - --- - Are you sure? The way that we start process is not same as other debuggers. - -- - -- -
- - - -- -- -
-
- - --- - HyperDbg doesn't use the DEBUG flag for the CreateProcess win32 API. - -- - -- -
- - - - - - - - - - - - - - - - - - - - - - - -- -- -
-
- - --- - If you couldn't fix the issue, I'll come with more options/solutions tomorrow. I'm gonna go sleep now. 😴💤 -- - -
Will continue tomorrow ✋ - -- -
- - - -- -- -
-
- - --- - - Joined. - - -- - -- -
- - - -- -- -
-
- - --- - - -- - -- - sticker.webp - -- -- -
- - - -- -- -
-
- - --- - Good morning everyone. Have a nice day. - -- - -- -
- - - -- -- -
-
- - --- - - -- - -- - document_2024-06-13_22-10-29.mp4 - -- -- - 14 June 2024 (26 messages) -
- -- -
- - - -- -- -
-
- - --- - No, neither the 'x' command nor an invalid command switch to another process, all of them stick to the current running process without continuing debuggee. - -- - -- -
- - - - - - - - - - - - - - - -- -- -
-
- - --- - Didn't get it, does it fix the problem? 🤨 - -- - -- -
- - - -- -- -
-
- - --- - .sym reload will continue the debuggee the debuggee but .sym load doesn't continue it. -- - - - -
-
https://docs.hyperdbg.org/commands/meta-commands/.sym - -- -
- - - -- -- -
-
- - --- - You just need to run '.sym reload' one time and after that the symbol table remains constant until next '.sym reload'. - -- - -- -
- - - - - - - -- -- -
-
- - --- - Yes, this is expected behavior since by default once you load HyperDbg it transfers only 64-bit symbols. - -- - -- -
- - - - - - - -- -- -
-
- - --- - .sym load load symbol files based on the current symbol table that is available in the debugger (host) not debuggee. If you need a specific process (e.g., a 32-bit process in your case) you need to use the '.sym reload' since the details of the symbols are not available at the debugger (host). - -- - -- -
- - - - - - - -- -- -
-
- - --- - No still it needs to '.sym reload' to build a symbol table. You can add symbols manually if you want. - -- - - - -- -
- - - - - - - -- -- -
-
- - --- - But still I think the best way is to '.sym reload' one time (e.g., start the process and then .sym reload pid xxx), then use the symbol table for the rest of your debugging commands. - -- - -- -
- - - - - - - -- -- -- --- - - -- - - - -- -
- - - -- -- -
-
- - --- - (Strong IMHO) I'd rather have full understanding and control over my code. Especially given the fact that windows kernel programming environment has a lot of extra limitations of what you can do. - -- - -- -
- - - - - - - -- -- -
-
- - --- - Agree. I'm using it for almost one month, although it's helpful in some cases but doesn't make good suggestions most of the times. - -- - -- -
- - - - - - - -- -- -
-
- - --- - It's not about the money :) - -- - -- -
- - - - - - - - - - - - - - - -- -- -
-
- - --- - HyperDbg is currently stable, with most of its functionalities now available in Debugger Mode rather than VMI Mode. -- - -
-
I recommend starting with OST2 videos, as HyperDbg is little bit different than classic Windows debuggers and requires users to be familiar with some specific concepts and considerations before using it. -
-
https://www.youtube.com/playlist?list=PLUFkSN0XLZ-kF1f143wlw8ujlH2A45nZY - -- - 15 June 2024 (31 messages) -
- - - - - - - - - -- -
- - - - - - - -- -- -
-
- - --- - Hi there! Kind of yes, but not just that. I'd say it's a software that manages some sort of virtualization overall. If we're talking about Intel specifically, it's a software for managing VMX mode execution of CPU (put aside platform and external devices for now). EPT is a feature of VMX. There are many other features as well. - -- - -- -
- - - -- -- -
-
- - --- - If you're familiar with a concept of page faults, then it's the same thing, it's just not an exception but rather a "VMX event" - -- - -- -
- - - - - - - -- -- -
-
- - --- - I mean yes, you could say so - -- - -- -
- - - - - - - -- -- -
-
- - --- - Yes - -- - -- -
- - - -- -- -
-
- - --- - You have to fill out the VMCS properly and completely and set handlers for vmx exits first. - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - Unfortunately, partial implementation of the hypervisor is not feasible - -- - -- -
- - - -- -- -
-
- - --- - So you have a concept of host mode and a guest mode - -- - -- -
- - - -- -- -
-
- - --- - Host mode is where hypervisor is executed, guest is where a guest OS is executing - -- - -- -
- - - -- -- -
-
- - --- - whenever you execute vmlaunch instruction, you enter vmx guest mode - -- - -- -
- - - -- -- -
-
- - --- - for that you need to initialize vmcs guest fields - -- - -- -
- - - -- -- -
-
- - --- - then, in order to return to host mode, some sort of vmexit event is needed in guest mode - -- - -- -
- - - -- -- -
-
- - --- - and surely you need properly configured vmx host vmcs fields - -- - -- -
- - - -- -- -
-
- - --- - hopefully this clarifies how vmx works - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - As an additional resource, you might also find the "Hypervisor from Scratch" tutorial helpful in understanding how VMX works. You can access it here: -- - -
-
https://rayanfam.com/tutorials/ - -- - Tutorials - -- -We write about Windows Internals, Hypervisors, Linux, and Networks.
- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - It depends on the type of the VMX event, like sometimes you need to readjust RIP value or something, but in general you don't need to reconfigure much between vmresumes - -- - -- -
- - - -- -- -
-
- - --- - EPT describes guest physical memory to host physical memory mapping - -- - -- -
- - - -- -- -
-
- - --- - What mode do you want to run your code in? - -- - -- -
- - - -- -- -
-
- - --- - - -- - -- - sticker.webp - -- -- -
- - - -- -- -
-
- - --- - Good morning everyone. Have a nice day. - -- - -- -
- - - -- -- -
-
- - --- - Good Moring Ting Zhang Qi - -- - -- - 16 June 2024 (43 messages) -
- - - - - - - - - - - - - -- -
- - - -- -- -
-
- - --- - Hi! Still not sure what you mean by "virtualize" - -- - -- -
- - - -- -- -
-
- - --- - You have a CPU, right. When VMX is enabled, you can execute either in VMX root or VMX non-root (guest) mode. - -- - -- -
- - - -- -- -
-
- - --- - If you have a shell code, you may just execute it as either VMX root or VMX guest - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - Do you imply physical memory virtualization? - -- - -- -
- - - - - - - -- -- -
-
- - --- - Yes, I've mentioned it here - -- - -- -
- - - -- -- -
-
- - --- - By virtualizing the current system, do you mean entering to VMX guest mode with a custom EPT? - -- - -- -
- - - - - - - -- -- -
-
- - --- - Sorry to choke you on that one, but it's much easier to understand each other when you use common technical terms, which come from Intels Software Developers Manual in this case - -- - -- -
- - - -- -- -
-
- - --- - There are many vmexit conditions available in VMX. Like cpuid instruction for instance. I'd recommend skimming through vol 3 chapter 28 of Intel's SDM. - -- - -- -
- - - -- -- -
-
- - --- - You cannot use the 'k' command within a !epthook script since it's a command not a script function, but you can write the functionality of the printing callstack by using a simple script. - -- - -- -
- - - - - - - -- -- -
-
- - --- - I think I wrote something similar for one of my projects years ago, lemme check. - -- - -- -
- - - -- -- -
-
- - --- - ? n = 5; -- - -
? m = 50; -
? for (j = 0; j != m; j++) { -
temp = @rsp + (j * 8); -
-
printf("%llx", temp); -
-
for (i = 0; i != n; i++) { -
-
is_valid = check_address(temp); -
-
if (is_valid == 1) { -
-
temptemp = temp; -
temp = poi(temp); -
-
is_valid2 = check_address(temp); -
-
if (is_valid2 == 1) { -
-
printf("-> %llx", temp); -
} else { -
test1 = db(temptemp); -
test2 = db(temptemp + 1); -
if (test1 > 1f && test1 < 7f) { -
if (test2 == 0x0) { -
printf(" (%ws)", temptemp); -
} else { -
printf(" (%s)", temptemp); -
} -
} -
} -
-
} else { -
break; -
} -
} -
printf("\n"); -
} - -- -
- - - -- -- -
-
- - --- - - -- - - - -- -
- - - -- -- -
-
- - --- - - -- - - - -- -
- - - -- -- -
-
- - --- - Yes, you basically need something like the above script. - -- - -- -
- - - -- -- -
-
- - --- - hey there, is it possible to discard handling of cpuid instruction in the hypervisor and leave it to the cpu? - -- - -- -
- - - -- -- -- --- - - -- - - - -- -
- - - -- -- -
-
- - --- - Unfortunately not, it is an unconditional vm exit - -- - -- -
- - - -- -- -
-
- - --- - As @honorary_bot mentioned it's an unconditional VM-exit but generally HyperDbg won't touch the results of CPU's CPUID registers. So, the problem here is just VM-exit timing, other than that HyperDbg won't modify the CPUID results (we just set the hypervisor bit, and Hypervisor signature which can be ignored by a simple script). - -- - -- -
- - - -- -- -
-
- - --- - then is there any way to prevent the guest from spamming cpuid instruction, it absolutely kills performance - -- - -- -
- - - -- -- -
-
- - --- - I have a specific program which does that - -- - -- -
- - - -- -- -
-
- - --- - if ran without hypervisor, performance is okay - -- - -- -
- - - -- -- -
-
- - --- - Why don't you nop those CPUID instruction? - -- - -- -
- - - -- -- -
-
- - --- - I believe it uses cpuid to get information from it plus time measurements - -- - -- -
- - - -- -- -
-
- - --- - You can write a HyperDbg script to nop all occurrence of CPUIDs. Something like this: -- - -
-
!cpuid pid XX { -
// CPUID = 0F A2 -
eb(@rip, 90); -
eb(@rip + 1, 90); -
} - -- -
- - - -- -- -
-
- - --- - You can also find the execution of RDTSC/RDTSCP instructions for timing by using the !tsc command and nop it similar to the above script. Also, manual investigation might be needed to avoid breaking the process's semantics. -- - -
-
https://docs.hyperdbg.org/commands/extension-commands/tsc - -- - !tsc (hook RDTSC/RDTSCP instruction execution) | HyperDbg Documentation - -- -Description of the '!tsc' command in HyperDbg.
- - -- -
- - - -- -- -
-
- - --- - Man, btw, there is a tiny case where you should still adjust cpuid result for the guest. You need to readjust cr4.osxsave and cr4.pke to reflect not the host mode, but the guest mode when returning data to the guest. Those cpuid bits depend on cr4: leaf 1 and leaf 7 respectively - -- - -- -
- - - -- -- -
-
- - --- - I think its not possible if the function which executes cpuid is virtualized - -- - -- -
- - - -- -- -
-
- - --- - like what kind of virtualization? you mean obfuscated? - -- - -- -
- - - -- -- -
-
- - --- - yes, these proprietary software protectors bruh - -- - -- -
- - - -- -- -
-
- - --- - Maybe we should introduce techincal terms in this chat in order us to understand each other better? :) - -- - -- -
- - - - - - - -- -- -
-
- - --- - 😅 - -- - -- -
- - - -- -- -
-
- - --- - yes - -- - -- -
- - - - - - - -- -- -
-
- - --- - not instruction length actually, memory size is the correct term - -- - -- - 17 June 2024 (93 messages) -
- - - - - -- -
- - - -- -- -
-
- - --- - Yes, you need to disable exceptions/faults/traps (not exactly interrupts in HyperDbg terms). Anyway, both of them are possible in HyperDbg by using the !exception and !interrupt commands along with short-circuiting. -- - -
-
Please check: -
https://docs.hyperdbg.org/commands/extension-commands/exception -
https://docs.hyperdbg.org/tips-and-tricks/misc/event-short-circuiting - -- - !exception (hook first 32 entries of IDT) | HyperDbg Documentation - -- -Description of the '!exception' command in HyperDbg.
- - -- -
- - - - - - - -- -- -
-
- - --- - You need something like this: -- - -
-
!exception 1 pid XX { -
event_sc(1); -
} - -- -
- - - -- -- -
-
- - --- - Other than, if you're dealing with the Debugger Mode, you can also tell HyperDbg not to intercept Traps or Breakpoints and later short-circuit it by the !exception command. Something like : -- - -
-
test breakpoint off -
test trap off - -- -
- - - - - - - - - - - -- -- -
-
- - --- - No difference, works the same in both user-mode and kernel-mode. - -- - -- -
- - - - - - - -- -- -
-
- - --- - Use the '!dr' command along with short-circuiting mechanism: -- - -
-
https://docs.hyperdbg.org/commands/extension-commands/dr - -- - !dr (hook access to debug registers) | HyperDbg Documentation - -- -Description of the '!dr' command in HyperDbg.
- - -- -
- - - -- -- -
-
- - --- - @instw0 check these videos: -- - -
https://www.youtube.com/watch?v=OBcTwRkCE68&list=PLUFkSN0XLZ-kF1f143wlw8ujlH2A45nZY&index=50 -
https://www.youtube.com/watch?v=Z6HAO4btkCM&list=PLUFkSN0XLZ-kF1f143wlw8ujlH2A45nZY&index=60 - -- - Dbg3301: HyperDbg 08 06 Debug Register Monitoring - -- -View 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.
- - -- -
- - - -- -- -
-
- - --- - exactly - -- - -- -
- - - -- -- -
-
- - --- - Just make sure to use a printf to make sure it works as expected since I never test short-circuiting with the '!dr' events. - -- - -- -
- - - - - - - -- -- -
-
- - --- - But it should work - -- - -- -
- - - - - - - -- -- -
-
- - --- - add semicolon - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - event_sc - -- - -- -
- - - -- -- -
-
- - --- - reconnect to HyperDbg? This error is not related to this event. - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - Another unrelated error happened there. - -- - -- -
- - - -- -- -
-
- - --- - use it like : -- - -
-
!dr script { -
event_sc(1); -
printf("ignoring debug reg modification from %s, pid: %x\n", $pname, $pid); -
} - -- -
- - - -- -- -
-
- - --- - It's okay, you just need to tell HyperDbg not to intercept breakpoints/traps if you want to use Windbg. - -- - -- -
- - - - - - - -- -- -
-
- - --- - this one - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - What do you mean? - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - You mean HyperDbg didn't intercept hardware breakpoint accesses? or it ignore them successfully as expected? - -- - -- -
- - - - - - - -- -- -
-
- - --- - you mean once you try to access them (view the list of debug breakpoints) windbg won't show them? - -- - -- -
- - - -- -- -
-
- - --- - I don't understand what you're trying to do. 🙂 -- - -
-
If you want to ignore them using the '!dr' command, then why do you expect them to be triggered? - -- -
- - - - - - - -- -- -
-
- - --- - HyperDbg can also manually inject #DBs which is how debug breakpoint registers notify about their trigger events. -- - -
-
https://docs.hyperdbg.org/commands/scripting-language/functions/events/event_inject - -- - event_inject | HyperDbg Documentation - -- -Description of the 'event_inject' function in HyperDbg Scripts
- - -- -
- - - -- -- -
-
- - --- - Why? HyperDbg's 't' command has problem? 🤨 - -- - -- -
- - - - - - - - - - - - - - - -- -- -
-
- - --- - Is it also the same for the instrumentation step-in (the 'i' command)? - -- - -- -
- - - - - - - -- -- -
-
- - --- - Ah, got it. - -- - -- -
- - - -- -- -
-
- - --- - When you run (test trap off) HyperDbg won't handle traps anymore. Everything is passed to the OS (Windbg). - -- - -- -
- - - - - - - -- -- -
-
- - --- - No the problem is that cpuid will cause VM-exit before trap flag by default in Intel processors. - -- - -- -
- - - -- -- -
-
- - --- - CPUID unconditionally cause a VM-exit and in HyperDbg a trap flag (#DB) will also cause a VM-exit but in Intel processors, CPUID has precedence over #DB (or more accurately RFLAGs.TF), that's why HyperDbg first receives and handles CPUIDs then processor triggers trap flag. - -- - -- -
- - - - - - - - - - - - - - - -- -- -
-
- - --- - I'm thinking of a fast patch to this. Are you currently stepping through these instructions? I mean how do you test it? - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - I think this can be handled by a combination of the '!exception' command and the '!cpuid' command, but not sure. 🧐 - -- - -- -
- - - -- -- -
-
- - --- - Wait a moment, I'll make a patch, and will let you know. - -- - -- -
- - - -- -- -
-
- - --- - @instw0 pls checkout to this branch and recompile HyperDbg: -- - -
https://github.com/HyperDbg/HyperDbg/tree/trap-cpuid - -- - GitHub - HyperDbg/HyperDbg at trap-cpuid - -- -State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
- - -- -
- - - - - - - -- -- -
-
- - --- - Let me know if it fixes the issue, I added this check to this branch (but not test it): -- - -
https://github.com/HyperDbg/HyperDbg/commit/ddbf929aa2043d0a65887e4fd428bfe6afddd43f - -- - detect and handle CPUIDs with TRAP flag · HyperDbg/HyperDbg@ddbf929 - -- -State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
- - -- -
- - - - - - - -- -- -
-
- - --- - Don't use the '!tsc' for now, just try to see if HyperDbg shows this message or not? -- - - - -
-
Does it show this message? - -- -
- - - - - - - - - - - - - - - - - - - - - - - -- -- -
-
- - --- - So, the way that VMProtect detects hyperviosr (HyperDbg) is not based on this trick. - -- - -- -
- - - -- -- -
-
- - --- - It depends, CPUID is an unconditional VM-exit but RDTSC/RDTSCP only cause VM-exit when you use the !tsc command in HyperDbg. - -- - -- -
- - - - - - - -- -- -
-
- - --- - Hi, -- - -
Scala is used as a part of porting HyperDbg into the hardware (Chip & FPGA) debugging (hwdbg). It is mainly written based on the Chisel language: https://www.chisel-lang.org -
-
If you want to test and use hardware debugging, then you need an FPGA. Basically, this Scala code that I wrote for hwdbg generates Verilog and SystemVerilog (HDL) codes that are synthesizable into FPGAs. -
-
For the issue I posted on GitHub early today, I didn't mean to modify the Scala code, I just meant to show you how I implemented the evaluation engine in hardware, so basically a simple modification on the INC++ and DEC++ operands in the C code is needed. -
-
I wrote the evaluation engine in Scala (https://github.com/HyperDbg/HyperDbg/blob/45b88f652d071e0f3c11b1f84b8a2a2d6556972a/hwdbg/src/main/scala/hwdbg/script/eval.scala#L97). -
-
The concept is the same, HyperDbg makes a script buffer using C/C++ codes and once the script buffer is ready, we'll send it to the hwdbg (through either Serial port or shared BlockRAM). The generated hardware part (the Scala code) is responsible for running those script buffers that we generated in the script engine. - -- - Chisel | Chisel - -- -Software-defined hardware
- - -- -
- - - -- -- -
-
- - --- - HyperDbg has a dump command (previously requested by @ricnar) and documented: -- - -
-
https://docs.hyperdbg.org/commands/extension-commands/dump - -- - !dump (save the physical memory into a file) | HyperDbg Documentation - -- -Description of '!dump' command in HyperDbg.
- - -- -
- - - - - - - - - - - - - - - -- -- -
-
- - --- - But it transfer buffer over serial. - -- - -- -
- - - -- -- -
-
- - --- - If you need any other kind of implementation, I think you can easily implement it by creating a new command based on this dump command. - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - and of course, create a PR so everyone can use it. 🙂 - -- - -- -
- - - -- -- -- --- - - -- - - - -- -
- - - - - - - -- -- -- --- - - -- - - - -- -
- - - - - - - - - - - -- -- -
-
- - --- - just do -- - -
git clone https://github.com/HyperDbg/HyperDbg.git -
cd HyperDbg -
git checkout trap-cpuid - -- -
- - - -- -- -
-
- - --- - Could you share disassembly of instructions after popfq? - -- - -- -
- - - - - - - -- -- -
-
- - --- - No, none of them are related to EPT hooks. - -- - -- -
- - - -- -- -
-
- - --- - Let me send you a link about its design. - -- - -- -
- - - -- -- -
-
- - --- - Please check this doc: -- - -
https://research.hyperdbg.org/assets/documents/kernel-debugger-design-1st-edition.pdf - -- - None - -- -- -
- - - -- -- -
-
- - --- - It explains how these commands (specially the instrumentation step-in) is implemented. - -- - -- - 18 June 2024 (8 messages) -
- - - - - - - - - - - - - -- -
- - - -- -- -
-
- - --- - Only the 'i' command (instrumentation step-in) uses MTF (Monitor Trap Flag). Other stepping command like 't' is implemented same as WinDbg by using RFLAGS's TF. - -- - -- -
- - - -- -- -
-
- - --- - NMI is not realted to step-in or step-over, HyperDbg just uses NMI to halt (pause) all cores in the Debugger Mode. - -- - -- -
- - - - - - - - - - - -- -- -
-
- - --- - Not sure if I correctly understand what you mean. 🤔 -- - -
What is event(!cpu)? - -- - 19 June 2024 (25 messages) -
- -- -
- - - -- -- -
-
- - --- - For !tsc Yes, for !cpuid No. CPUID is unconditional VM-exit. Here is a list of instructions with unconditional VM-exit. - -- - - - -- -
- - - - - - - - - - - -- -- -
-
- - --- - We process it as VM-exit, not interrupt. - -- - -
@@ -15219,29 +1940,27 @@ 2020
- ↶ Reply to #6815 + ↶ Reply to #7036 - #6817 + #7037 - 04:43 AM, 19 Jun 2024 + 05:46 PM, 03 Jul 2024- RDTSC is configured from VMCS, VMCALL is unconditional VM-exit and !msrread !msrwrite use MSR Bitmaps. Take a look at Hypervisor From Scratch, I think it gives you an idea how HyperDbg works internally: -
-
https://rayanfam.com/tutorials/ + https://docs.hyperdbg.org/commands/scripting-language/constants-and-functions- Tutorials + Constants & Functions | HyperDbg Documentation -@@ -15251,30 +1970,34 @@We write about Windows Internals, Hypervisors, Linux, and Networks.
+Description of constants and functions
2020
-+
+
- win10 bluescreen， + No, pause will pause the debugger immediately. Context is preserved.@@ -15284,30 +2007,30 @@2020
-- How to fix + hm. in main script it told me there is error when i put return;@@ -15317,7 +2040,7 @@2020
-
@@ -15333,18 +2056,18 @@ 2020
- ↶ Reply to #6818 + ↶ Reply to #7039 - #6820 + #7040 - 06:09 AM, 19 Jun 2024 + 05:49 PM, 03 Jul 2024- You need to provide more details. What is the generation of your processor? which version of Windows? and how to reproduce it? + You need to ask @xmaple555 to fix it, I don't know that much about the script engine parser. 🙂🙃@@ -15354,32 +2077,32 @@2020
-- yes, I've read it, I just wanted to clarify that the debugger is at the event !cpuid, !rdtsc set conditions in the vmxsc structure? then vmm receives a notification(or vmexit)? + this is good to know.. bad thing those dynamic calls are calculated within one page :(@@ -15389,30 +2112,32 @@2020
-- it's just that cpuid causes an unconditional vmexit anyway, and in the case of !rdtsc? + ok, i will create issue@@ -15422,34 +2147,34 @@2020
--
+
- Not related to hyperdbg, but vmprotect does not care if you break at cpuid or at the nop. https://github.com/jmpoep/vmprotect-3.5.1/blob/d8fcb7c0ffd4fb45a8cfbd770c8b117d7dbe52b5/runtime/core.cc#L771 + What do you mean by dynamic calls calculation? 🤨@@ -15459,32 +2184,36 @@2020
-- RDTSC? + something like +@@ -15494,34 +2223,30 @@
+
main:017C9D0E call dword ptr [edx+0Ch] +
and +
main:017C9BEE call dword ptr [edx+0Ch] +
+
those are different subs, but stays within one page, so i cant put !monitors on both calls2020
--
-
- Ah yes, my bad. It actually cares 😀 https://github.com/jmpoep/vmprotect-3.5.1/blob/d8fcb7c0ffd4fb45a8cfbd770c8b117d7dbe52b5/runtime/core.cc#L306 + edx will point to different offsets@@ -15531,34 +2256,30 @@2020
--
-
- Conditions checks for each extension command is basically software-side implemented. RDTSC/RDTSCP cause conditional VM-exits (not remember, either on primary or secondary proc-based VMCS controls). + so the chain actually is : call dword ptr [eax+8] -> ( main:017C9D0E call dword ptr [edx+0Ch] OR main:017C9BEE call dword ptr [edx+0Ch])@@ -15568,97 +2289,73 @@2020
-
-
https://github.com/HyperDbg/HyperDbg/tree/dev/hwdbg + so i need to calculate the target function at the very end of this2020
- ↶ Reply to #6828 + ↶ Reply to #7044 - #6830 + #7049 - 11:40 AM, 19 Jun 2024 + 06:01 PM, 03 Jul 2024- @xmaple555 we need to think of the best way to parse scripts of the hwdbg debugger. The registers and pseudo-registers of the hwdbg is different from x64 registers. 🤔 + Wait, you cannot put two !monitors in one page?@@ -15695,7 +2392,7 @@2020
-
@@ -15711,18 +2408,16 @@ 2020
- ↶ Reply to #6830 - - #6831 + #7050 - 11:43 AM, 19 Jun 2024 + 06:02 PM, 03 Jul 2024- Basically, hwdbg registers are like @hw_pin0, @hw_pin1, @hw_pin2, ..., @hw_pinX and @hw_port0, @hw_port1, @hw_port2, ..., @hw_portX. We need to find the best way of adding these registers (and new pseudo-registers) to the parser. + I thought it's possible. 🤔@@ -15732,32 +2427,30 @@2020
-2020
-
@@ -15783,27 +2476,27 @@ 2020
- ↶ Reply to #6832 + ↶ Reply to #7046 - #6833 + #7052 - 03:34 PM, 19 Jun 2024 + 06:04 PM, 03 Jul 2024- VMCALL is unconditional, !dr needs configuration. Pls check this file as it's the file responsible for configuring events: + Not sure if I understand what you mean but !monitor receives (to/from) parameters from the script expressions:
-
https://github.com/HyperDbg/HyperDbg/blob/master/hyperdbg/hprdbgkd/code/debugger/events/ApplyEvents.c +
https://github.com/HyperDbg/HyperDbg/blob/a691c1df3be48660907fcf93840302a8c4650ff4/hyperdbg/libhyperdbg/code/debugger/commands/extension-commands/monitor.cpp#L204- HyperDbg/hyperdbg/hprdbgkd/code/debugger/events/ApplyEvents.c at master · HyperDbg/HyperDbg + HyperDbg/hyperdbg/libhyperdbg/code/debugger/commands/extension-commands/monitor.cpp at a691c1df3be48660907fcf93840302a8c4650ff4 · HyperDbg/HyperDbgState-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
@@ -15815,7 +2508,7 @@2020
-- hey there, im trying to build solution and getting: + if i put monitor on whole page, it will flood with calls...- -- -
+
- i commented out definitions in ntioapi.h, but i dont know if it is valid solution + Which means you can calculate your addresses in global variables and use them as parameters to the !monitor.@@ -15923,7 +2578,7 @@2020
-- it conflicted with winnt.h + ok, let me explain a bit@@ -15956,30 +2611,34 @@2020
-+
+
- another question, im trying to use firstchance exception handling, im executing !epthook <hidden> code {31 c0 f7 f0} <- division by zero. but debugger console stays in infinite loop + E.g., !monitor .FromGlobalVar .FromGlobalVar+0x85 script { ... }@@ -15989,36 +2648,38 @@2020
-- - 20 June 2024 (66 messages) -
- --
+
- 有没有自己人？😁 + Wait couldn't you put multiple !monitor hooks in one page? As long as I remember it was possible. 🤔🤔🤔 +@@ -16028,32 +2689,30 @@
+
Not a big deal BTW, you can handle it through the script. +
+
E.g., check for your ranges within if conditions. $context pseudo-register contains the address of accessed memory address. However, I'm pretty sure we support multiple !monitor(s) on same page at some point. 🤔2020
-- 没有 + first i put monitor here main:017CA56B call dword ptr [eax+8] ; then inside script i want to do something like put monitor x eax+8 l 4 so it will follow function call, for example main:017C9D00, i know offest where dword ptr [edx+0Ch] will be called, let say 017C9D00+58, so i will put new monitor again on 017C9D00+58 and then, when im in desired function - print disasembly@@ -16063,33 +2722,41 @@2020
-- thank you, did I understand correctly(in general): -@@ -16099,32 +2766,30 @@
configuring vmxcs to be notified when an event occurs -> processing in vmm? + 0: kHyperDbg> !monitor x 760658a0 l 4 script { +
> +
> printf("monitor"); +
> } +
+
0: kHyperDbg> !monitor x 760658f0 l 4 script { +
> +
> printf("monitor"); +
> } +
err, the page modification is not applied, make sure that you don't put multiple EPT Hooks or Monitors on a single page (c0000026) +
+
0: kHyperDbg>2020
-- i add a check rflags.tf in !tsc, and: + i will try to play with from/to params, but im afraid it will spam me with events though :(@@ -16134,69 +2799,67 @@2020
-2020
-
@@ -16222,18 +2885,18 @@ 2020
- ↶ Reply to #6835 + ↶ Reply to #7061 - #6845 + #7063 - 02:56 PM, 20 Jun 2024 + 06:16 PM, 03 Jul 2024- Ah, this one is also mentioned by another person in issues. This one should be updated in the phnt repo that we used it as a submodule. We could also update HyperDbg's fork and comment it. I'll fix it. + Like put a !monitor on an entire page, and check for the $context.@@ -16243,34 +2906,30 @@2020
--
-
- Not sure what you trying to do? The division by zero error you're trying produce is handled in VMX root-mode because all of the events (except !epthook2, not !epthook) execute assembly in VMX root-mode, so it's not handled by guest (Windows) IDT and it's passed to HyperDbg's HOST IDT exception handler. + yup, thats my idea for now :)@@ -16280,34 +2939,30 @@2020
--
-
- Yes + thanks for advice@@ -16317,7 +2972,7 @@2020
-
@@ -16333,18 +2988,18 @@ 2020
- ↶ Reply to #6842 + ↶ Reply to #7058 - #6848 + #7066 - 03:01 PM, 20 Jun 2024 + 06:17 PM, 03 Jul 2024- Just added a check? Any modification to the TF Flag? + This one again could be handled from the by the method I told you earlier (pause())@@ -16354,30 +3009,30 @@2020
-- debugger is frozen + i want to do it automatically (e.g. all possible "end" calls)@@ -16387,69 +3042,67 @@2020
-2020
-- I'm trying to do remote debugging with 2 physical machines over COM but the connection never seems to complete, the debugger stays on -@@ -16504,32 +3145,34 @@
-
HyperDbg> .debug remote serial 115200 com1 -
Waiting for debuggee to connect... -
-
And the debugee: -
-
HyperDbg> .debug prepare serial 115200 com3 -
current processor vendor is : GenuineIntel -
virtualization technology is vt-x -
vmx operation is supported by your processor -
-
I've tested the COM connection with PuTTY and all appears to be working fine there, any suggestions on what I can do to debug/fix the issue? + yes, will see how it helps2020
-+
+
- im trying to stop app in particular state by modifying code to raise division exception, now app stops with unhandled exception and windows popup appears. i can take dump, state is intact, however, in traces i can see windows exception handler mechanism, so real trace is not accessible. actually i wanted to cause BSOD, but it seems its not so easy for usermode + Maybe a combination of loops could help.@@ -16539,69 +3182,72 @@2020
-2020
--
-
- If I were in your shoes, I tried to make a simple application with your target technique (popfq TF), and I try to trigger the behavior in HyperDbg like showing a message using (LogInfo) without modifying anything. Once I was sure that this technique can be correctly detected (by seeing the message), then I try to modify the guest state. I think this is the best approach to handle this VMProtect technique. + as you see those subs are pretty close to each other, so probably global variables might do the trick@@ -16648,32 +3290,30 @@2020
-- I'm trying + @HughEverett one more bug about monitors - when i remove monitors and .debug close, vm restarts, i think its related to that bug where cant set monitor on same adderss@@ -16683,34 +3323,34 @@2020
-- + 04 July 2024 (7 messages) +
+ +-
-
- Yes, but it depends on when CPU gives us this #Db, the reason such a technique exists is because CPUID has precedence over #Db's exception bitmap vm-exit. + each kernel driver has its own stack and heap or is shared with the kernel?@@ -16720,30 +3360,34 @@2020
-+
+
- Are we processing the trap inside now? + It's just the matter of handling complex logic of hooks in different pages. I'm so lazy to think about it since the algorithm of handling multiple hooks and events could become complex. 😅@@ -16753,7 +3397,7 @@2020
-
@@ -16769,18 +3413,16 @@ 2020
- ↶ Reply to #6852 - - #6861 + #7078 - 04:19 PM, 20 Jun 2024 + 04:04 PM, 04 Jul 2024- Ah, unfortunately this feature is not working as expected. We previously had a discussion in this group and conclude that this feature is not working. You need to use a virtual serial device. + But sure, I'll add it to the future todo list.@@ -16790,30 +3432,34 @@2020
-+
+
- that is, the exception should be triggered immediately after the cpuid instruction? + Thanks for reporting it, I'll check it.@@ -16823,30 +3469,34 @@2020
-+
+
- just processing rflags.tf should take place inside the try catch block, not in the debugger + I think it's shared between all drivers. I see caaes where it's not shared but if I remember it correctly, it's generally shared between different processes (but not sure). 🤔@@ -16856,34 +3506,32 @@2020
--
-
- . + ok, no worries, but pls try to solve that monitor mystery :) actually after putting one monitor i shall restart vm (it restarts itself) and then put another one@@ -16893,7 +3541,7 @@2020
-
@@ -16909,18 +3557,18 @@ 2020
- ↶ Reply to #6864 + ↶ Reply to #7081 - #6865 + #7082 - 04:22 PM, 20 Jun 2024 + 05:18 PM, 04 Jul 2024- Larry you can follow this discussion, it's probably the problem with verifying packets. + Sure@@ -16930,7 +3578,11 @@2020
-- + 05 July 2024 (24 messages) +
+ +
@@ -16946,36 +3598,30 @@ 2020
- ↶ Reply to #6853 + ↶ Reply to #7059 - #6866 + #7083 - 04:26 PM, 20 Jun 2024 + 05:50 AM, 05 Jul 2024- Still don't understand what you're trying to do but if you want to trigger an exception in your target user-mode app, you need to inject an event in HyperDbg by using these functions: + I was able to reproduce this error.
-
https://docs.hyperdbg.org/commands/scripting-language/functions/events/event_inject -
-
And: -
-
https://docs.hyperdbg.org/commands/scripting-language/functions/events/event_inject_error_code -
-
These are the functions that deliver exception to the guest debuggee application. The assembly code you used in your event will cause division by zero in HyperDbg's VMM which is simply handled in VMX root-mode and it's ignored by HyperDbg's division by zero exception handler. +
https://github.com/HyperDbg/HyperDbg/issues/409- event_inject | HyperDbg Documentation - -@@ -16984,7 +3630,7 @@Description of the 'event_inject' function in HyperDbg Scripts
- + +
+ photo_2024-07-05_05-50-37.jpg +2020
-
@@ -17000,18 +3646,16 @@ 2020
- ↶ Reply to #6862 - - #6867 + #7084 - 04:28 PM, 20 Jun 2024 + 05:51 AM, 05 Jul 2024- Depends on how CPU behaves in this case. If it triggers immediately then you need to inject a #DB. + It seems that it's because HyperDbg doesn't remove the !monitor hooks correctly when the address is not available in HyperDbg's address space. 🤔@@ -17021,7 +3665,7 @@2020
-
@@ -17037,18 +3681,16 @@ 2020
- ↶ Reply to #6863 - - #6868 + #7085 - 04:28 PM, 20 Jun 2024 + 05:52 AM, 05 Jul 2024- User-mode try/catch? + Since this address is only valid in the target process memory, not HyperDbg's view of memory (cr3).@@ -17058,40 +3700,52 @@2020
-
https://github.com/HyperDbg/HyperDbg/tree/fix-monitor-remove+ + GitHub - HyperDbg/HyperDbg at fix-monitor-remove + ++State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
+ + +
@@ -17107,18 +3761,18 @@ 2020
- ↶ Reply to #6869 + ↶ Reply to #7059 - #6870 + #7087 - 04:29 PM, 20 Jun 2024 + 08:32 AM, 05 Jul 2024- Are you analyzing a driver? + Test this one and ...@@ -17128,30 +3782,34 @@2020
-+
+
- yes + this one.@@ -17161,30 +3819,32 @@2020
-+
+
- driver obfuckate vmprotect + Both of them should be fixed.@@ -17194,7 +3854,7 @@2020
-- I think you need to create a user-mode application with the same technique. + I changed the logic of clearing !monitor events.@@ -17229,7 +3889,7 @@2020
-- It's easier to modify a user-mode application and introspect it's behavior. Try to make a similar check function check in user-mode. + Also please try to test it with different conditions and different ways if you can. At the moment it passed all of my tests but since the logic of clearing these kinds of events is changed, I might break it in some other ways, so performing a complete test would help a lot.@@ -17264,7 +3924,7 @@2020
-- And also post your function here if it's possible. I'm gonna check it too. + Once you've done testing it, please let me know so I'll merge it to the 'dev' branch.@@ -17299,30 +3959,30 @@2020
-- and trap and breakpoint are not disabled in the hypervisor.... does windows think that the debugger is connected? + Ok, will test today@@ -17332,34 +3992,30 @@2020
--
-
- No, it's the case for HyperDbg. Windows (OS) doesn't have any details about the presence of a top-level (ring -1) debugger. + good! i can set monitor on same address again :)@@ -17369,34 +4025,30 @@2020
--
-
- In VMI mode, traps/breakpoints are not intercepted by default. + VM also does not restart on .debug close when monitor removed@@ -17406,7 +4058,7 @@2020
-
@@ -17422,16 +4074,18 @@ 2020
+ ↶ Reply to #7094 + - #6879 + #7096 - 04:35 PM, 20 Jun 2024 + 12:36 PM, 05 Jul 2024- In the Debugger Mode, traps/bps are intercepted. + That's great. I merged it to the 'dev' branch now.@@ -17441,7 +4095,7 @@2020
-- !monitor w 001995A4 l 4 pid 01cc script { -@@ -17480,34 +4128,30 @@
if (db(001995A4) == c3){ -
pause(); -
} -
} -
-
why this script is slow as hell? it freezes debugee process. if i remove if condition its more less ok + thanks2020
-2020
-+
+
- i think so.. there is buffer prepared for network sending + Yep, this is what I told here:@@ -17550,7 +4198,7 @@2020
-
@@ -17566,18 +4214,18 @@ 2020
- ↶ Reply to #6882 + ↶ Reply to #7006 - #6883 + #7100 - 06:30 PM, 20 Jun 2024 + 06:22 PM, 05 Jul 2024- So, that's the reason. HyperDbg puts hook on entire 4 kb granularity of the page boundary. Not just 4 bytes. Because it's how EPT works. + .@@ -17587,7 +4235,7 @@2020
-- mmm -@@ -17632,7 +4268,7 @@
!monitor w 001995A4 l 4 script { -
-
printf("BUF ACCESSED BY %s stack:%x\n",$pname,@esp); -
printf("BUF CONTENT \n"); -
for (i = 0; i < 10; i++){ -
printf("%x ",db(001995A4+i)); -
} -
printf("\n"); -
-
} -
-
this script works perfect + ah.. i see, but its minor thing anyway :)2020
-
@@ -17648,18 +4284,18 @@ 2020
- ↶ Reply to #6883 + ↶ Reply to #7098 - #6885 + #7102 - 06:30 PM, 20 Jun 2024 + 06:24 PM, 05 Jul 2024- So, each access to this 4kb cause a VM-exit, but HyperDbg filters it and only show you the accesses on your target address range. + But generally you have tons of options, you could disable/enable events instead of clearing them. Or use a nop+jmp infinite loop at the @RIP register.@@ -17669,7 +4305,7 @@2020
-
@@ -17685,18 +4321,21 @@ 2020
- ↶ Reply to #6884 + ↶ Reply to #7101 - #6886 + #7103 - 06:31 PM, 20 Jun 2024 + 06:28 PM, 05 Jul 2024- Why? 🤔 + This one is really hard to solve. 😅 +@@ -17706,30 +4345,34 @@
+
In HyperDbg we use NMIs for halting cores. This mechanism should be changed to IPIs instead of NMIs. +
The reason why it doesn't support immediately clearing of events is because we might halt the core in the middle of handling an event and conclude to remove them. In that case, the event will trigger BSOD since its structures are freed. But, using IPIs will make sure that handling one event will be finished, and then another VM-exit happens which will halt the core.2020
-+
+
- i also wonder :D + Using IPIs by itself is okay but since HyperDbg is highly dependent on NMIs, changing it to IPIs will probably break lots of its functionalities. That's why I didn't dare to change it to IPIs yet. 😅@@ -17739,34 +4382,30 @@2020
--
-
- Can you check the entire page boundary? + ah.. i know only in general what are those interrupts :D not details, so i have to believe You :D@@ -17776,7 +4415,7 @@2020
-- all 4kb ? + one more issue in github :)@@ -17809,34 +4448,36 @@2020
-- + 06 July 2024 (8 messages) +
+ +2020
-
@@ -17862,39 +4503,28 @@ 2020
- ↶ Reply to #6884 + ↶ Reply to #7107 - #6891 + #7108 - 06:35 PM, 20 Jun 2024 + 04:28 PM, 06 Jul 2024- And also not sure if you already knew it or not but the $context pseudo-register shows you the address of the memory accessed by the instruction that triggered the hook. --
-
https://docs.hyperdbg.org/commands/extension-commands/monitor#context + It's not ready yet. These days I'm working on it together with another team member. I'll let you guys know once it's finished.- - !monitor (monitor read/write/execute to a range of memory) | HyperDbg Documentation - --Description of the '!monitor' command in HyperDbg.
- - -- what i need to do to achieve it ? + @HughEverett ++
0: kHyperDbg> !monitor x 8ef7b0 l 1 script { +
> printf("trigger\n"); +
> } +
err, invalid address (c0000005) +
address may be paged-out or unavailable on the page table due to 'demand paging' +
please refer to https://docs.hyperdbg.org/tips-and-tricks/considerations/accessing-invalid-address for further information +
+
0: kHyperDbg> +
+
0: kHyperDbg> u2 8ef7b0 +
00000000`008ef7b0 83 EC 18 sub esp, 0x18 +
00000000`008ef7b3 8B 44 24 1C mov eax, dword ptr ss:[esp+0x1C] +
00000000`008ef7b7 53 push ebx +
00000000`008ef7b8 55 push ebp +
00000000`008ef7b9 56 push esi +
00000000`008ef7ba 8B 30 mov esi, dword ptr ds:[eax] +
... +
+
0: kHyperDbg> bp 8ef7b0 +
what im doing wrong ?+ + Accessing Invalid Address | HyperDbg Documentation + ++Considerations for accessing memory in different modes
+ + +- i need to montor 001995A4+4kb ? + (switched to process before)@@ -17962,36 +4619,30 @@2020
--
-
- No, the page boundary start from PAGE_ALIGN(001995A4) which means you need sth like: -@@ -18001,34 +4652,44 @@
-
00199000 l fff + ok.. looks like its working with l 42020
--
-
- Or from 199000 to 199fff + ah... so: +@@ -18038,7 +4699,7 @@
if i put monitor on !monitor x 017CA56B l 3 script {.... +
and then run for some while and put monitor +
!monitor x 8ef7b0 l 1 script { +
results to: +
+
trigger +
(22:36:23.619 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:182) | Page-fault received, CR2: 8ef7b0 +
(22:36:23.619 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:182) | Page-fault received, CR2: 8ef7b0 +
(22:36:23.619 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:182) | Page-fault received, CR2: 8ef7b0 +
(22:36:23.619 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:182) | Page-fault rece +
+
loop. +
+
any ideas ?2020
-- aha... -@@ -18075,32 +4732,30 @@
!monitor w 199000 l fff pid 1a00 script { -
printf("Buffer accessed\n"); -
} -
i get a ton of accesses, but at least it shows something + !monitor x 017CA56B l 3 script { is just reading some registers2020
--
-
- Ah, so that's the reason + so i need to remove 017CA56B monitor first. i definetly know that 017CA56B is calling 8ef7b0@@ -18110,7 +4765,11 @@2020
-- + 07 July 2024 (12 messages) +
+ +
@@ -18126,16 +4785,19 @@ 2020
+ ↶ Reply to #7111 + - #6898 + #7115 - 06:43 PM, 20 Jun 2024 + 05:57 AM, 07 Jul 2024- The rate of access is too high + Didn't get it 🤔 +@@ -18145,30 +4807,35 @@
It doesn't work with 1 in the '!monitor'?2020
-+
+
- will try to add if condition now + Could you please make a GitHub issue with the sequence of commands I could reproduce the error? +@@ -18178,67 +4845,81 @@
If there are multiple ways of reproducing error (e.g., it crashes with both 1 and 3 length) make sure to include all sequences separately so all of them will be fixed.2020
-
+
I'm trying to install EfiGaurd to disable PatchGaurd in my local machine, +
But I cannot find the option to add a boot option, or enter the boot setup. +
+
I disabled the secure boot and make it legacy, but the problem still the same.-
+
- It does not make that much difference. + My laptop is Lenovo IdeaPad@@ -18248,7 +4929,7 @@2020
-
@@ -18264,16 +4945,18 @@ 2020
+ ↶ Reply to #7117 + - #6902 + #7119 - 06:45 PM, 20 Jun 2024 + 06:28 AM, 07 Jul 2024- Once you try to hook 001995a4, HyperDbg will automatically hook the entire page boundary (00199000 to 00199fff) for you. + @Mattiwatti The original author is in the group but not sure if he still checks his Telegram since he rarely uses this app.@@ -18283,30 +4966,32 @@2020
-+
+
- i see.. + Yeah, the last seen is long time ago@@ -18316,34 +5001,32 @@2020
--
+
- It just doesn't show you once it's not within the range but not showing you doesn't mean it didn't happen. + Is there's any other option to disable the PatchGaurd in my local machine@@ -18353,30 +5036,34 @@2020
-+
+
- yes, understood + As long as I remember, you could boot EfiGuard from a USB.@@ -18386,36 +5073,34 @@2020
-- - 21 June 2024 (4 messages) -
- --
+
- 群里天天都在聊啥 + BTW, why do you need to disable PatchGuard? The only command that is not PatchGuard compatible in HyperDbg is the '!syscall'. Are you going to intercepts system-calls?@@ -18425,32 +5110,32 @@2020
--
+
- 看不懂英语 + Other commands are perfectly fine with PatchGuard.@@ -18460,32 +5145,32 @@2020
--
+
- 有没有自己人讲讲😊 + No actually I'm going to use the !epthook command, but I faced a problem that the command cannot identify the system call function that I passed to it, so I thought it's a problem related to PatchGaurd@@ -18495,37 +5180,32 @@2020
--
+
- 祁 同伟 -@@ -18542,111 +5222,45 @@
This is an English-speaking group. Please send your messages in English only. You may use an online translator if needed. -
___ -
这是一个英语群组。请仅以英语发送您的消息。如有需要，您可以使用在线翻译。 + I'm using it in the VMI, with script of course2020
-
-
- - - 01 Jun 2024 (1) - - - -
- - - 03 Jun 2024 (3) - - - -
- - - 04 Jun 2024 (75) - - - -
- - - 05 Jun 2024 (2) - - - -
- - - 06 Jun 2024 (3) - - - -
- - - 08 Jun 2024 (3) - - - -
- - - 09 Jun 2024 (5) - - - -
- - - 10 Jun 2024 (2) - - - -
- - - 12 Jun 2024 (1) - - - -
- - - 13 Jun 2024 (98) - - - -
- - - 14 Jun 2024 (26) - - - -
-
-
- 15 Jun 2024 (31)
+
- + + 01 Jul 2024 (9)
-- - - 16 Jun 2024 (43) +
- + + 02 Jul 2024 (11)
-- - - 17 Jun 2024 (93) +
- + + 03 Jul 2024 (60)
-- - - 18 Jun 2024 (8) +
- + + 04 Jul 2024 (7)
-- - - 19 Jun 2024 (25) +
- + + 05 Jul 2024 (24)
-- - - 20 Jun 2024 (66) +
- + + 06 Jul 2024 (8)
-- - - 21 Jun 2024 (4) +
- + + 07 Jul 2024 (12)
diff --git a/index.xml b/index.xml index cef095d..ff30f40 100644 --- a/index.xml +++ b/index.xml @@ -6,773 +6,805 @@Public archive of HyperDbg Telegram messages. http://www.rssboard.org/rss-specification tg-archive 1.1.3 -Fri, 21 Jun 2024 04:17:12 +0000 +Sun, 07 Jul 2024 08:38:56 +0000 - -
@HughEverett on 2024-06-21 02:45:39+00:00 (#6909) - https://tg-archive.hyperdbg.org/2024-06.html#6909 -祁 同伟 -This is an English-speaking group. Please send your messages in English only. You may use an online translator if needed. -___ -这是一个英语群组。请仅以英语发送您的消息。如有需要，您可以使用在线翻译。 -https://tg-archive.hyperdbg.org/2024-06.html#6909 -Fri, 21 Jun 2024 02:45:39 +0000 +@Some00ne on 2024-07-07 08:36:41+00:00 (#7126) + https://tg-archive.hyperdbg.org/2024-07.html#7126 +I'm using it in the VMI, with script of course +https://tg-archive.hyperdbg.org/2024-07.html#7126 +Sun, 07 Jul 2024 08:36:41 +0000 - -
@6190448061 on 2024-06-21 02:05:57+00:00 (#6908) - https://tg-archive.hyperdbg.org/2024-06.html#6908 -有没有自己人讲讲😊 -https://tg-archive.hyperdbg.org/2024-06.html#6908 -Fri, 21 Jun 2024 02:05:57 +0000 +@Some00ne on 2024-07-07 08:36:13+00:00 (#7125) + https://tg-archive.hyperdbg.org/2024-07.html#7125 +No actually I'm going to use the !epthook command, but I faced a problem that the command cannot identify the system call function that I passed to it, so I thought it's a problem related to PatchGaurd +https://tg-archive.hyperdbg.org/2024-07.html#7125 +Sun, 07 Jul 2024 08:36:13 +0000 - -
@6190448061 on 2024-06-21 02:05:48+00:00 (#6907) - https://tg-archive.hyperdbg.org/2024-06.html#6907 -看不懂英语 -https://tg-archive.hyperdbg.org/2024-06.html#6907 -Fri, 21 Jun 2024 02:05:48 +0000 +@HughEverett on 2024-07-07 08:34:27+00:00 (#7124) + https://tg-archive.hyperdbg.org/2024-07.html#7124 +Other commands are perfectly fine with PatchGuard. +https://tg-archive.hyperdbg.org/2024-07.html#7124 +Sun, 07 Jul 2024 08:34:27 +0000 - -
@6190448061 on 2024-06-21 02:05:41+00:00 (#6906) - https://tg-archive.hyperdbg.org/2024-06.html#6906 -群里天天都在聊啥 -https://tg-archive.hyperdbg.org/2024-06.html#6906 -Fri, 21 Jun 2024 02:05:41 +0000 +@HughEverett on 2024-07-07 08:34:10+00:00 (#7123) + https://tg-archive.hyperdbg.org/2024-07.html#7123 +BTW, why do you need to disable PatchGuard? The only command that is not PatchGuard compatible in HyperDbg is the '!syscall'. Are you going to intercepts system-calls? +https://tg-archive.hyperdbg.org/2024-07.html#7123 +Sun, 07 Jul 2024 08:34:10 +0000 - -
@395437265 on 2024-06-20 18:46:44+00:00 (#6905) - https://tg-archive.hyperdbg.org/2024-06.html#6905 -yes, understood -https://tg-archive.hyperdbg.org/2024-06.html#6905 -Thu, 20 Jun 2024 18:46:44 +0000 +@HughEverett on 2024-07-07 08:33:21+00:00 (#7122) + https://tg-archive.hyperdbg.org/2024-07.html#7122 +As long as I remember, you could boot EfiGuard from a USB. +https://tg-archive.hyperdbg.org/2024-07.html#7122 +Sun, 07 Jul 2024 08:33:21 +0000 - -
@HughEverett on 2024-06-20 18:46:23+00:00 (#6904) - https://tg-archive.hyperdbg.org/2024-06.html#6904 -It just doesn't show you once it's not within the range but not showing you doesn't mean it didn't happen. -https://tg-archive.hyperdbg.org/2024-06.html#6904 -Thu, 20 Jun 2024 18:46:23 +0000 +@Some00ne on 2024-07-07 06:36:08+00:00 (#7121) + https://tg-archive.hyperdbg.org/2024-07.html#7121 +Is there's any other option to disable the PatchGaurd in my local machine +https://tg-archive.hyperdbg.org/2024-07.html#7121 +Sun, 07 Jul 2024 06:36:08 +0000 - -
@395437265 on 2024-06-20 18:45:26+00:00 (#6903) - https://tg-archive.hyperdbg.org/2024-06.html#6903 -i see.. -https://tg-archive.hyperdbg.org/2024-06.html#6903 -Thu, 20 Jun 2024 18:45:26 +0000 +@Some00ne on 2024-07-07 06:35:48+00:00 (#7120) + https://tg-archive.hyperdbg.org/2024-07.html#7120 +Yeah, the last seen is long time ago +https://tg-archive.hyperdbg.org/2024-07.html#7120 +Sun, 07 Jul 2024 06:35:48 +0000 - -
@HughEverett on 2024-06-20 18:45:16+00:00 (#6902) - https://tg-archive.hyperdbg.org/2024-06.html#6902 -Once you try to hook 001995a4, HyperDbg will automatically hook the entire page boundary (00199000 to 00199fff) for you. -https://tg-archive.hyperdbg.org/2024-06.html#6902 -Thu, 20 Jun 2024 18:45:16 +0000 +@HughEverett on 2024-07-07 06:28:02+00:00 (#7119) + https://tg-archive.hyperdbg.org/2024-07.html#7119 +@Mattiwatti The original author is in the group but not sure if he still checks his Telegram since he rarely uses this app. +https://tg-archive.hyperdbg.org/2024-07.html#7119 +Sun, 07 Jul 2024 06:28:02 +0000 - -
@HughEverett on 2024-06-20 18:44:10+00:00 (#6901) - https://tg-archive.hyperdbg.org/2024-06.html#6901 -It does not make that much difference. -https://tg-archive.hyperdbg.org/2024-06.html#6901 -Thu, 20 Jun 2024 18:44:10 +0000 +@Some00ne on 2024-07-07 06:22:21+00:00 (#7118) + https://tg-archive.hyperdbg.org/2024-07.html#7118 +My laptop is Lenovo IdeaPad +https://tg-archive.hyperdbg.org/2024-07.html#7118 +Sun, 07 Jul 2024 06:22:21 +0000 - -
-@395437265 on 2024-06-20 18:43:42+00:00 (#6900) - https://tg-archive.hyperdbg.org/2024-06.html#6900 -or will it fail ? -https://tg-archive.hyperdbg.org/2024-06.html#6900 -Thu, 20 Jun 2024 18:43:42 +0000 -- -
@395437265 on 2024-06-20 18:43:34+00:00 (#6899) - https://tg-archive.hyperdbg.org/2024-06.html#6899 -will try to add if condition now -https://tg-archive.hyperdbg.org/2024-06.html#6899 -Thu, 20 Jun 2024 18:43:34 +0000 +@Some00ne on 2024-07-07 06:21:58+00:00 (#7117) + https://tg-archive.hyperdbg.org/2024-07.html#7117 +Hello guys, I need some help here + +I'm trying to install EfiGaurd to disable PatchGaurd in my local machine, +But I cannot find the option to add a boot option, or enter the boot setup. + +I disabled the secure boot and make it legacy, but the problem still the same. +https://tg-archive.hyperdbg.org/2024-07.html#7117 ++ Sun, 07 Jul 2024 06:21:58 +0000 - -
@HughEverett on 2024-06-20 18:43:33+00:00 (#6898) - https://tg-archive.hyperdbg.org/2024-06.html#6898 -The rate of access is too high -https://tg-archive.hyperdbg.org/2024-06.html#6898 -Thu, 20 Jun 2024 18:43:33 +0000 +@HughEverett on 2024-07-07 06:01:20+00:00 (#7116) + https://tg-archive.hyperdbg.org/2024-07.html#7116 +Could you please make a GitHub issue with the sequence of commands I could reproduce the error? +If there are multiple ways of reproducing error (e.g., it crashes with both 1 and 3 length) make sure to include all sequences separately so all of them will be fixed. +https://tg-archive.hyperdbg.org/2024-07.html#7116 +Sun, 07 Jul 2024 06:01:20 +0000 - -
@HughEverett on 2024-06-20 18:43:24+00:00 (#6897) - https://tg-archive.hyperdbg.org/2024-06.html#6897 -Ah, so that's the reason -https://tg-archive.hyperdbg.org/2024-06.html#6897 -Thu, 20 Jun 2024 18:43:24 +0000 +@HughEverett on 2024-07-07 05:57:31+00:00 (#7115) + https://tg-archive.hyperdbg.org/2024-07.html#7115 +Didn't get it 🤔 +It doesn't work with 1 in the '!monitor'? +https://tg-archive.hyperdbg.org/2024-07.html#7115 +Sun, 07 Jul 2024 05:57:31 +0000 - -
@395437265 on 2024-06-20 18:42:36+00:00 (#6896) - https://tg-archive.hyperdbg.org/2024-06.html#6896 -aha... -!monitor w 199000 l fff pid 1a00 script { - printf("Buffer accessed\n"); -} -i get a ton of accesses, but at least it shows something -https://tg-archive.hyperdbg.org/2024-06.html#6896 -Thu, 20 Jun 2024 18:42:36 +0000 +@395437265 on 2024-07-06 19:38:32+00:00 (#7114) + https://tg-archive.hyperdbg.org/2024-07.html#7114 +so i need to remove 017CA56B monitor first. i definetly know that 017CA56B is calling 8ef7b0 +https://tg-archive.hyperdbg.org/2024-07.html#7114 +Sat, 06 Jul 2024 19:38:32 +0000 - -
@HughEverett on 2024-06-20 18:40:07+00:00 (#6895) - https://tg-archive.hyperdbg.org/2024-06.html#6895 -Or from 199000 to 199fff -https://tg-archive.hyperdbg.org/2024-06.html#6895 -Thu, 20 Jun 2024 18:40:07 +0000 +@395437265 on 2024-07-06 19:37:22+00:00 (#7113) + https://tg-archive.hyperdbg.org/2024-07.html#7113 +!monitor x 017CA56B l 3 script { is just reading some registers +https://tg-archive.hyperdbg.org/2024-07.html#7113 +Sat, 06 Jul 2024 19:37:22 +0000 - -
-@HughEverett on 2024-06-20 18:39:39+00:00 (#6894) - https://tg-archive.hyperdbg.org/2024-06.html#6894 -No, the page boundary start from PAGE_ALIGN(001995A4) which means you need sth like: + @395437265 on 2024-07-06 19:36:50+00:00 (#7112) + https://tg-archive.hyperdbg.org/2024-07.html#7112 +ah... so: +if i put monitor on !monitor x 017CA56B l 3 script {.... +and then run for some while and put monitor + !monitor x 8ef7b0 l 1 script { +results to: -00199000 l fff -https://tg-archive.hyperdbg.org/2024-06.html#6894 -Thu, 20 Jun 2024 18:39:39 +0000 -- -
-@395437265 on 2024-06-20 18:38:27+00:00 (#6893) - https://tg-archive.hyperdbg.org/2024-06.html#6893 -i need to montor 001995A4+4kb ? -https://tg-archive.hyperdbg.org/2024-06.html#6893 -Thu, 20 Jun 2024 18:38:27 +0000 -- -
-@395437265 on 2024-06-20 18:37:10+00:00 (#6892) - https://tg-archive.hyperdbg.org/2024-06.html#6892 -what i need to do to achieve it ? -https://tg-archive.hyperdbg.org/2024-06.html#6892 -Thu, 20 Jun 2024 18:37:10 +0000 -- -
-@HughEverett on 2024-06-20 18:35:13+00:00 (#6891) - https://tg-archive.hyperdbg.org/2024-06.html#6891 -And also not sure if you already knew it or not but the $context pseudo-register shows you the address of the memory accessed by the instruction that triggered the hook. +trigger +(22:36:23.619 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:182) | Page-fault received, CR2: 8ef7b0 +(22:36:23.619 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:182) | Page-fault received, CR2: 8ef7b0 +(22:36:23.619 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:182) | Page-fault received, CR2: 8ef7b0 +(22:36:23.619 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:182) | Page-fault rece -https://docs.hyperdbg.org/commands/extension-commands/monitor#context -https://tg-archive.hyperdbg.org/2024-06.html#6891 -- Thu, 20 Jun 2024 18:35:13 +0000 -- -
+@HughEverett on 2024-06-20 18:32:25+00:00 (#6890) - https://tg-archive.hyperdbg.org/2024-06.html#6890 -Yes. Get a printf from it -https://tg-archive.hyperdbg.org/2024-06.html#6890 -Thu, 20 Jun 2024 18:32:25 +0000 +loop. + +any ideas ? +https://tg-archive.hyperdbg.org/2024-07.html#7112 +Sat, 06 Jul 2024 19:36:50 +0000 +- +
+@395437265 on 2024-07-06 19:32:11+00:00 (#7111) + https://tg-archive.hyperdbg.org/2024-07.html#7111 +ok.. looks like its working with l 4 +https://tg-archive.hyperdbg.org/2024-07.html#7111 +Sat, 06 Jul 2024 19:32:11 +0000 +- +
+@395437265 on 2024-07-06 19:30:37+00:00 (#7110) + https://tg-archive.hyperdbg.org/2024-07.html#7110 +(switched to process before) +https://tg-archive.hyperdbg.org/2024-07.html#7110 +Sat, 06 Jul 2024 19:30:37 +0000 +- +
@395437265 on 2024-07-06 19:29:23+00:00 (#7109) + https://tg-archive.hyperdbg.org/2024-07.html#7109 +@HughEverett +0: kHyperDbg> !monitor x 8ef7b0 l 1 script { +> printf("trigger\n"); +> } +err, invalid address (c0000005) +address may be paged-out or unavailable on the page table due to 'demand paging' +please refer to https://docs.hyperdbg.org/tips-and-tricks/considerations/accessing-invalid-address for further information + +0: kHyperDbg> + + +0: kHyperDbg> u2 8ef7b0 +00000000`008ef7b0 83 EC 18 sub esp, 0x18 +00000000`008ef7b3 8B 44 24 1C mov eax, dword ptr ss:[esp+0x1C] +00000000`008ef7b7 53 push ebx +00000000`008ef7b8 55 push ebp +00000000`008ef7b9 56 push esi +00000000`008ef7ba 8B 30 mov esi, dword ptr ds:[eax] +... + +0: kHyperDbg> bp 8ef7b0 +what im doing wrong ? +https://tg-archive.hyperdbg.org/2024-07.html#7109 ++ Sat, 06 Jul 2024 19:29:23 +0000 - -
@395437265 on 2024-06-20 18:32:11+00:00 (#6889) - https://tg-archive.hyperdbg.org/2024-06.html#6889 -all 4kb ? -https://tg-archive.hyperdbg.org/2024-06.html#6889 -Thu, 20 Jun 2024 18:32:11 +0000 +@HughEverett on 2024-07-06 16:28:28+00:00 (#7108) + https://tg-archive.hyperdbg.org/2024-07.html#7108 +It's not ready yet. These days I'm working on it together with another team member. I'll let you guys know once it's finished. +https://tg-archive.hyperdbg.org/2024-07.html#7108 +Sat, 06 Jul 2024 16:28:28 +0000 - -
@HughEverett on 2024-06-20 18:32:01+00:00 (#6888) - https://tg-archive.hyperdbg.org/2024-06.html#6888 -Can you check the entire page boundary? -https://tg-archive.hyperdbg.org/2024-06.html#6888 -Thu, 20 Jun 2024 18:32:01 +0000 +@Reverser69 on 2024-07-06 14:56:54+00:00 (#7107) + https://tg-archive.hyperdbg.org/2024-07.html#7107 +Anyone tried hyperdbg gui? +https://tg-archive.hyperdbg.org/2024-07.html#7107 +Sat, 06 Jul 2024 14:56:54 +0000 - -
@395437265 on 2024-06-20 18:31:42+00:00 (#6887) - https://tg-archive.hyperdbg.org/2024-06.html#6887 -i also wonder :D -https://tg-archive.hyperdbg.org/2024-06.html#6887 -Thu, 20 Jun 2024 18:31:42 +0000 +@395437265 on 2024-07-05 19:43:37+00:00 (#7106) + https://tg-archive.hyperdbg.org/2024-07.html#7106 +one more issue in github :) +https://tg-archive.hyperdbg.org/2024-07.html#7106 +Fri, 05 Jul 2024 19:43:37 +0000 - -
@HughEverett on 2024-06-20 18:31:32+00:00 (#6886) - https://tg-archive.hyperdbg.org/2024-06.html#6886 -Why? 🤔 -https://tg-archive.hyperdbg.org/2024-06.html#6886 -Thu, 20 Jun 2024 18:31:32 +0000 +@395437265 on 2024-07-05 18:32:10+00:00 (#7105) + https://tg-archive.hyperdbg.org/2024-07.html#7105 +ah.. i know only in general what are those interrupts :D not details, so i have to believe You :D +https://tg-archive.hyperdbg.org/2024-07.html#7105 +Fri, 05 Jul 2024 18:32:10 +0000 - -
@HughEverett on 2024-06-20 18:30:58+00:00 (#6885) - https://tg-archive.hyperdbg.org/2024-06.html#6885 -So, each access to this 4kb cause a VM-exit, but HyperDbg filters it and only show you the accesses on your target address range. -https://tg-archive.hyperdbg.org/2024-06.html#6885 -Thu, 20 Jun 2024 18:30:58 +0000 +@HughEverett on 2024-07-05 18:30:40+00:00 (#7104) + https://tg-archive.hyperdbg.org/2024-07.html#7104 +Using IPIs by itself is okay but since HyperDbg is highly dependent on NMIs, changing it to IPIs will probably break lots of its functionalities. That's why I didn't dare to change it to IPIs yet. 😅 +https://tg-archive.hyperdbg.org/2024-07.html#7104 +Fri, 05 Jul 2024 18:30:40 +0000 - -
@395437265 on 2024-06-20 18:30:47+00:00 (#6884) - https://tg-archive.hyperdbg.org/2024-06.html#6884 -mmm -!monitor w 001995A4 l 4 script { - - printf("BUF ACCESSED BY %s stack:%x\n",$pname,@esp); - printf("BUF CONTENT \n"); - for (i = 0; i < 10; i++){ - printf("%x ",db(001995A4+i)); - } - printf("\n"); - -} + +@HughEverett on 2024-07-05 18:28:54+00:00 (#7103) + https://tg-archive.hyperdbg.org/2024-07.html#7103 +This one is really hard to solve. 😅 -this script works perfect -https://tg-archive.hyperdbg.org/2024-06.html#6884 -Thu, 20 Jun 2024 18:30:47 +0000 +In HyperDbg we use NMIs for halting cores. This mechanism should be changed to IPIs instead of NMIs. +The reason why it doesn't support immediately clearing of events is because we might halt the core in the middle of handling an event and conclude to remove them. In that case, the event will trigger BSOD since its structures are freed. But, using IPIs will make sure that handling one event will be finished, and then another VM-exit happens which will halt the core.https://tg-archive.hyperdbg.org/2024-07.html#7103 +Fri, 05 Jul 2024 18:28:54 +0000 - -
@HughEverett on 2024-06-20 18:30:00+00:00 (#6883) - https://tg-archive.hyperdbg.org/2024-06.html#6883 -So, that's the reason. HyperDbg puts hook on entire 4 kb granularity of the page boundary. Not just 4 bytes. Because it's how EPT works. -https://tg-archive.hyperdbg.org/2024-06.html#6883 -Thu, 20 Jun 2024 18:30:00 +0000 +@HughEverett on 2024-07-05 18:24:03+00:00 (#7102) + https://tg-archive.hyperdbg.org/2024-07.html#7102 +But generally you have tons of options, you could disable/enable events instead of clearing them. Or use a nop+jmp infinite loop at the @RIP register. +https://tg-archive.hyperdbg.org/2024-07.html#7102 +Fri, 05 Jul 2024 18:24:03 +0000 - -
@395437265 on 2024-06-20 18:28:27+00:00 (#6882) - https://tg-archive.hyperdbg.org/2024-06.html#6882 -i think so.. there is buffer prepared for network sending -https://tg-archive.hyperdbg.org/2024-06.html#6882 -Thu, 20 Jun 2024 18:28:27 +0000 +@395437265 on 2024-07-05 18:22:52+00:00 (#7101) + https://tg-archive.hyperdbg.org/2024-07.html#7101 +ah.. i see, but its minor thing anyway :) +https://tg-archive.hyperdbg.org/2024-07.html#7101 +Fri, 05 Jul 2024 18:22:52 +0000 - -
@HughEverett on 2024-06-20 18:27:49+00:00 (#6881) - https://tg-archive.hyperdbg.org/2024-06.html#6881 -Is it (the entire 4kb of the target page) located on a page with high rate of memory access? -https://tg-archive.hyperdbg.org/2024-06.html#6881 -Thu, 20 Jun 2024 18:27:49 +0000 +@HughEverett on 2024-07-05 18:22:19+00:00 (#7100) + https://tg-archive.hyperdbg.org/2024-07.html#7100 +. +https://tg-archive.hyperdbg.org/2024-07.html#7100 +Fri, 05 Jul 2024 18:22:19 +0000 - -
@395437265 on 2024-06-20 18:22:19+00:00 (#6880) - https://tg-archive.hyperdbg.org/2024-06.html#6880 -!monitor w 001995A4 l 4 pid 01cc script { - if (db(001995A4) == c3){ - pause(); - } -} - -why this script is slow as hell? it freezes debugee process. if i remove if condition its more less ok -https://tg-archive.hyperdbg.org/2024-06.html#6880 -Thu, 20 Jun 2024 18:22:19 +0000 +@HughEverett on 2024-07-05 18:20:59+00:00 (#7099) + https://tg-archive.hyperdbg.org/2024-07.html#7099 +Yep, this is what I told here: +https://tg-archive.hyperdbg.org/2024-07.html#7099 +Fri, 05 Jul 2024 18:20:59 +0000 - -
@HughEverett on 2024-06-20 16:35:26+00:00 (#6879) - https://tg-archive.hyperdbg.org/2024-06.html#6879 -In the Debugger Mode, traps/bps are intercepted. -https://tg-archive.hyperdbg.org/2024-06.html#6879 -Thu, 20 Jun 2024 16:35:26 +0000 +@395437265 on 2024-07-05 18:00:52+00:00 (#7098) + https://tg-archive.hyperdbg.org/2024-07.html#7098 +one thing, i have to run process for some while to get monitor completely removed, i cant remove and set new within one break +https://tg-archive.hyperdbg.org/2024-07.html#7098 +Fri, 05 Jul 2024 18:00:52 +0000 - -
@HughEverett on 2024-06-20 16:35:02+00:00 (#6878) - https://tg-archive.hyperdbg.org/2024-06.html#6878 -In VMI mode, traps/breakpoints are not intercepted by default. -https://tg-archive.hyperdbg.org/2024-06.html#6878 -Thu, 20 Jun 2024 16:35:02 +0000 +@395437265 on 2024-07-05 12:54:50+00:00 (#7097) + https://tg-archive.hyperdbg.org/2024-07.html#7097 +thanks +https://tg-archive.hyperdbg.org/2024-07.html#7097 +Fri, 05 Jul 2024 12:54:50 +0000 - -
@HughEverett on 2024-06-20 16:34:30+00:00 (#6877) - https://tg-archive.hyperdbg.org/2024-06.html#6877 -No, it's the case for HyperDbg. Windows (OS) doesn't have any details about the presence of a top-level (ring -1) debugger. -https://tg-archive.hyperdbg.org/2024-06.html#6877 -Thu, 20 Jun 2024 16:34:30 +0000 +@HughEverett on 2024-07-05 12:36:54+00:00 (#7096) + https://tg-archive.hyperdbg.org/2024-07.html#7096 +That's great. I merged it to the 'dev' branch now. +https://tg-archive.hyperdbg.org/2024-07.html#7096 +Fri, 05 Jul 2024 12:36:54 +0000 - -
@instw0 on 2024-06-20 16:32:44+00:00 (#6876) - https://tg-archive.hyperdbg.org/2024-06.html#6876 -and trap and breakpoint are not disabled in the hypervisor.... does windows think that the debugger is connected? -https://tg-archive.hyperdbg.org/2024-06.html#6876 -Thu, 20 Jun 2024 16:32:44 +0000 +@395437265 on 2024-07-05 11:50:41+00:00 (#7095) + https://tg-archive.hyperdbg.org/2024-07.html#7095 +VM also does not restart on .debug close when monitor removed +https://tg-archive.hyperdbg.org/2024-07.html#7095 +Fri, 05 Jul 2024 11:50:41 +0000 - -
@HughEverett on 2024-06-20 16:31:31+00:00 (#6875) - https://tg-archive.hyperdbg.org/2024-06.html#6875 -And also post your function here if it's possible. I'm gonna check it too. -https://tg-archive.hyperdbg.org/2024-06.html#6875 -Thu, 20 Jun 2024 16:31:31 +0000 +@395437265 on 2024-07-05 11:48:07+00:00 (#7094) + https://tg-archive.hyperdbg.org/2024-07.html#7094 +good! i can set monitor on same address again :) +https://tg-archive.hyperdbg.org/2024-07.html#7094 +Fri, 05 Jul 2024 11:48:07 +0000 - -
@HughEverett on 2024-06-20 16:31:09+00:00 (#6874) - https://tg-archive.hyperdbg.org/2024-06.html#6874 -It's easier to modify a user-mode application and introspect it's behavior. Try to make a similar check function check in user-mode. -https://tg-archive.hyperdbg.org/2024-06.html#6874 -Thu, 20 Jun 2024 16:31:09 +0000 +@395437265 on 2024-07-05 09:27:41+00:00 (#7093) + https://tg-archive.hyperdbg.org/2024-07.html#7093 +Ok, will test today +https://tg-archive.hyperdbg.org/2024-07.html#7093 +Fri, 05 Jul 2024 09:27:41 +0000 - -
@HughEverett on 2024-06-20 16:29:50+00:00 (#6873) - https://tg-archive.hyperdbg.org/2024-06.html#6873 -I think you need to create a user-mode application with the same technique. -https://tg-archive.hyperdbg.org/2024-06.html#6873 -Thu, 20 Jun 2024 16:29:50 +0000 +@HughEverett on 2024-07-05 08:35:14+00:00 (#7092) + https://tg-archive.hyperdbg.org/2024-07.html#7092 +Once you've done testing it, please let me know so I'll merge it to the 'dev' branch. +https://tg-archive.hyperdbg.org/2024-07.html#7092 +Fri, 05 Jul 2024 08:35:14 +0000 - -
@instw0 on 2024-06-20 16:29:47+00:00 (#6872) - https://tg-archive.hyperdbg.org/2024-06.html#6872 -driver obfuckate vmprotect -https://tg-archive.hyperdbg.org/2024-06.html#6872 -Thu, 20 Jun 2024 16:29:47 +0000 +@HughEverett on 2024-07-05 08:34:48+00:00 (#7091) + https://tg-archive.hyperdbg.org/2024-07.html#7091 +Also please try to test it with different conditions and different ways if you can. At the moment it passed all of my tests but since the logic of clearing these kinds of events is changed, I might break it in some other ways, so performing a complete test would help a lot. +https://tg-archive.hyperdbg.org/2024-07.html#7091 +Fri, 05 Jul 2024 08:34:48 +0000 - -
@instw0 on 2024-06-20 16:29:28+00:00 (#6871) - https://tg-archive.hyperdbg.org/2024-06.html#6871 -yes -https://tg-archive.hyperdbg.org/2024-06.html#6871 -Thu, 20 Jun 2024 16:29:28 +0000 +@HughEverett on 2024-07-05 08:33:00+00:00 (#7090) + https://tg-archive.hyperdbg.org/2024-07.html#7090 +I changed the logic of clearing !monitor events. +https://tg-archive.hyperdbg.org/2024-07.html#7090 +Fri, 05 Jul 2024 08:33:00 +0000 - -
@HughEverett on 2024-06-20 16:29:21+00:00 (#6870) - https://tg-archive.hyperdbg.org/2024-06.html#6870 -Are you analyzing a driver? -https://tg-archive.hyperdbg.org/2024-06.html#6870 -Thu, 20 Jun 2024 16:29:21 +0000 +@HughEverett on 2024-07-05 08:32:45+00:00 (#7089) + https://tg-archive.hyperdbg.org/2024-07.html#7089 +Both of them should be fixed. +https://tg-archive.hyperdbg.org/2024-07.html#7089 +Fri, 05 Jul 2024 08:32:45 +0000 - -
@instw0 on 2024-06-20 16:28:51+00:00 (#6869) - https://tg-archive.hyperdbg.org/2024-06.html#6869 -kernel -https://tg-archive.hyperdbg.org/2024-06.html#6869 -Thu, 20 Jun 2024 16:28:51 +0000 +@HughEverett on 2024-07-05 08:32:38+00:00 (#7088) + https://tg-archive.hyperdbg.org/2024-07.html#7088 +this one. +https://tg-archive.hyperdbg.org/2024-07.html#7088 +Fri, 05 Jul 2024 08:32:38 +0000 - -
@HughEverett on 2024-06-20 16:28:44+00:00 (#6868) - https://tg-archive.hyperdbg.org/2024-06.html#6868 -User-mode try/catch? -https://tg-archive.hyperdbg.org/2024-06.html#6868 -Thu, 20 Jun 2024 16:28:44 +0000 +@HughEverett on 2024-07-05 08:32:22+00:00 (#7087) + https://tg-archive.hyperdbg.org/2024-07.html#7087 +Test this one and ... +https://tg-archive.hyperdbg.org/2024-07.html#7087 +Fri, 05 Jul 2024 08:32:22 +0000 - -
@HughEverett on 2024-06-20 16:28:13+00:00 (#6867) - https://tg-archive.hyperdbg.org/2024-06.html#6867 -Depends on how CPU behaves in this case. If it triggers immediately then you need to inject a #DB. -https://tg-archive.hyperdbg.org/2024-06.html#6867 -Thu, 20 Jun 2024 16:28:13 +0000 +@HughEverett on 2024-07-05 08:31:50+00:00 (#7086) + https://tg-archive.hyperdbg.org/2024-07.html#7086 +Eduard Please switch to this branch and test it again: +https://github.com/HyperDbg/HyperDbg/tree/fix-monitor-remove +https://tg-archive.hyperdbg.org/2024-07.html#7086 ++ Fri, 05 Jul 2024 08:31:50 +0000 - -
@HughEverett on 2024-06-20 16:26:58+00:00 (#6866) - https://tg-archive.hyperdbg.org/2024-06.html#6866 -Still don't understand what you're trying to do but if you want to trigger an exception in your target user-mode app, you need to inject an event in HyperDbg by using these functions: - -https://docs.hyperdbg.org/commands/scripting-language/functions/events/event_inject - -And: - -https://docs.hyperdbg.org/commands/scripting-language/functions/events/event_inject_error_code - -These are the functions that deliver exception to the guest debuggee application. The assembly code you used in your event will cause division by zero in HyperDbg's VMM which is simply handled in VMX root-mode and it's ignored by HyperDbg's division by zero exception handler. -https://tg-archive.hyperdbg.org/2024-06.html#6866 -- Thu, 20 Jun 2024 16:26:58 +0000 +@HughEverett on 2024-07-05 05:52:16+00:00 (#7085) + https://tg-archive.hyperdbg.org/2024-07.html#7085 +Since this address is only valid in the target process memory, not HyperDbg's view of memory (cr3). +https://tg-archive.hyperdbg.org/2024-07.html#7085 +Fri, 05 Jul 2024 05:52:16 +0000 - -
@HughEverett on 2024-06-20 16:22:37+00:00 (#6865) - https://tg-archive.hyperdbg.org/2024-06.html#6865 -Larry you can follow this discussion, it's probably the problem with verifying packets. -https://tg-archive.hyperdbg.org/2024-06.html#6865 -Thu, 20 Jun 2024 16:22:37 +0000 +@HughEverett on 2024-07-05 05:51:40+00:00 (#7084) + https://tg-archive.hyperdbg.org/2024-07.html#7084 +It seems that it's because HyperDbg doesn't remove the !monitor hooks correctly when the address is not available in HyperDbg's address space. 🤔 +https://tg-archive.hyperdbg.org/2024-07.html#7084 +Fri, 05 Jul 2024 05:51:40 +0000 - -
-@HughEverett on 2024-06-20 16:21:52+00:00 (#6864) - https://tg-archive.hyperdbg.org/2024-06.html#6864 -. -https://tg-archive.hyperdbg.org/2024-06.html#6864 -Thu, 20 Jun 2024 16:21:52 +0000 -- -
-@instw0 on 2024-06-20 16:21:39+00:00 (#6863) - https://tg-archive.hyperdbg.org/2024-06.html#6863 -just processing rflags.tf should take place inside the try catch block, not in the debugger -https://tg-archive.hyperdbg.org/2024-06.html#6863 -Thu, 20 Jun 2024 16:21:39 +0000 -- -
@instw0 on 2024-06-20 16:19:22+00:00 (#6862) - https://tg-archive.hyperdbg.org/2024-06.html#6862 -that is, the exception should be triggered immediately after the cpuid instruction? -https://tg-archive.hyperdbg.org/2024-06.html#6862 -Thu, 20 Jun 2024 16:19:22 +0000 +@HughEverett on 2024-07-05 05:50:37+00:00 (#7083) + https://tg-archive.hyperdbg.org/2024-07.html#7083 +I was able to reproduce this error. + +https://github.com/HyperDbg/HyperDbg/issues/409 +https://tg-archive.hyperdbg.org/2024-07.html#7083 ++ Fri, 05 Jul 2024 05:50:37 +0000 - -
@HughEverett on 2024-06-20 16:19:04+00:00 (#6861) - https://tg-archive.hyperdbg.org/2024-06.html#6861 -Ah, unfortunately this feature is not working as expected. We previously had a discussion in this group and conclude that this feature is not working. You need to use a virtual serial device. -https://tg-archive.hyperdbg.org/2024-06.html#6861 -Thu, 20 Jun 2024 16:19:04 +0000 +@HughEverett on 2024-07-04 17:18:38+00:00 (#7082) + https://tg-archive.hyperdbg.org/2024-07.html#7082 +Sure +https://tg-archive.hyperdbg.org/2024-07.html#7082 +Thu, 04 Jul 2024 17:18:38 +0000 - -
@instw0 on 2024-06-20 16:18:42+00:00 (#6860) - https://tg-archive.hyperdbg.org/2024-06.html#6860 -Are we processing the trap inside now? -https://tg-archive.hyperdbg.org/2024-06.html#6860 -Thu, 20 Jun 2024 16:18:42 +0000 +@395437265 on 2024-07-04 17:05:38+00:00 (#7081) + https://tg-archive.hyperdbg.org/2024-07.html#7081 +ok, no worries, but pls try to solve that monitor mystery :) actually after putting one monitor i shall restart vm (it restarts itself) and then put another one +https://tg-archive.hyperdbg.org/2024-07.html#7081 +Thu, 04 Jul 2024 17:05:38 +0000 - -
@HughEverett on 2024-06-20 16:17:04+00:00 (#6858) - https://tg-archive.hyperdbg.org/2024-06.html#6858 -Yes, but it depends on when CPU gives us this #Db, the reason such a technique exists is because CPUID has precedence over #Db's exception bitmap vm-exit. -https://tg-archive.hyperdbg.org/2024-06.html#6858 -Thu, 20 Jun 2024 16:17:04 +0000 +@HughEverett on 2024-07-04 16:07:07+00:00 (#7080) + https://tg-archive.hyperdbg.org/2024-07.html#7080 +I think it's shared between all drivers. I see caaes where it's not shared but if I remember it correctly, it's generally shared between different processes (but not sure). 🤔 +https://tg-archive.hyperdbg.org/2024-07.html#7080 +Thu, 04 Jul 2024 16:07:07 +0000 - -
@instw0 on 2024-06-20 16:16:34+00:00 (#6857) - https://tg-archive.hyperdbg.org/2024-06.html#6857 -I'm trying -https://tg-archive.hyperdbg.org/2024-06.html#6857 -Thu, 20 Jun 2024 16:16:34 +0000 +@HughEverett on 2024-07-04 16:05:21+00:00 (#7079) + https://tg-archive.hyperdbg.org/2024-07.html#7079 +Thanks for reporting it, I'll check it. +https://tg-archive.hyperdbg.org/2024-07.html#7079 +Thu, 04 Jul 2024 16:05:21 +0000 - -
@HughEverett on 2024-06-20 16:15:41+00:00 (#6856) - https://tg-archive.hyperdbg.org/2024-06.html#6856 -If I were in your shoes, I tried to make a simple application with your target technique (popfq TF), and I try to trigger the behavior in HyperDbg like showing a message using (LogInfo) without modifying anything. Once I was sure that this technique can be correctly detected (by seeing the message), then I try to modify the guest state. I think this is the best approach to handle this VMProtect technique. -https://tg-archive.hyperdbg.org/2024-06.html#6856 -Thu, 20 Jun 2024 16:15:41 +0000 +@HughEverett on 2024-07-04 16:04:11+00:00 (#7078) + https://tg-archive.hyperdbg.org/2024-07.html#7078 +But sure, I'll add it to the future todo list. +https://tg-archive.hyperdbg.org/2024-07.html#7078 +Thu, 04 Jul 2024 16:04:11 +0000 - -
@instw0 on 2024-06-20 16:13:05+00:00 (#6855) - https://tg-archive.hyperdbg.org/2024-06.html#6855 -and is it being processed? -https://tg-archive.hyperdbg.org/2024-06.html#6855 -Thu, 20 Jun 2024 16:13:05 +0000 +@HughEverett on 2024-07-04 16:03:53+00:00 (#7077) + https://tg-archive.hyperdbg.org/2024-07.html#7077 +It's just the matter of handling complex logic of hooks in different pages. I'm so lazy to think about it since the algorithm of handling multiple hooks and events could become complex. 😅 +https://tg-archive.hyperdbg.org/2024-07.html#7077 +Thu, 04 Jul 2024 16:03:53 +0000 - -
@HughEverett on 2024-06-20 16:12:11+00:00 (#6854) - https://tg-archive.hyperdbg.org/2024-06.html#6854 -Yes a trap flag generates a #Db. -https://tg-archive.hyperdbg.org/2024-06.html#6854 -Thu, 20 Jun 2024 16:12:11 +0000 +@instw0 on 2024-07-04 05:48:39+00:00 (#7076) + https://tg-archive.hyperdbg.org/2024-07.html#7076 +each kernel driver has its own stack and heap or is shared with the kernel? +https://tg-archive.hyperdbg.org/2024-07.html#7076 +Thu, 04 Jul 2024 05:48:39 +0000 - -
@395437265 on 2024-06-20 15:44:38+00:00 (#6853) - https://tg-archive.hyperdbg.org/2024-06.html#6853 -im trying to stop app in particular state by modifying code to raise division exception, now app stops with unhandled exception and windows popup appears. i can take dump, state is intact, however, in traces i can see windows exception handler mechanism, so real trace is not accessible. actually i wanted to cause BSOD, but it seems its not so easy for usermode -https://tg-archive.hyperdbg.org/2024-06.html#6853 -Thu, 20 Jun 2024 15:44:38 +0000 +@395437265 on 2024-07-03 20:06:42+00:00 (#7075) + https://tg-archive.hyperdbg.org/2024-07.html#7075 +@HughEverett one more bug about monitors - when i remove monitors and .debug close, vm restarts, i think its related to that bug where cant set monitor on same adderss +https://tg-archive.hyperdbg.org/2024-07.html#7075 +Wed, 03 Jul 2024 20:06:42 +0000 - -
@6306026391 on 2024-06-20 15:18:33+00:00 (#6852) - https://tg-archive.hyperdbg.org/2024-06.html#6852 -I'm trying to do remote debugging with 2 physical machines over COM but the connection never seems to complete, the debugger stays on - -HyperDbg> .debug remote serial 115200 com1 -Waiting for debuggee to connect... - -And the debugee: - -HyperDbg> .debug prepare serial 115200 com3 -current processor vendor is : GenuineIntel -virtualization technology is vt-x -vmx operation is supported by your processor - -I've tested the COM connection with PuTTY and all appears to be working fine there, any suggestions on what I can do to debug/fix the issue? -https://tg-archive.hyperdbg.org/2024-06.html#6852 -Thu, 20 Jun 2024 15:18:33 +0000 +@395437265 on 2024-07-03 18:21:55+00:00 (#7074) + https://tg-archive.hyperdbg.org/2024-07.html#7074 +as you see those subs are pretty close to each other, so probably global variables might do the trick +https://tg-archive.hyperdbg.org/2024-07.html#7074 +Wed, 03 Jul 2024 18:21:55 +0000 - -
@instw0 on 2024-06-20 15:03:55+00:00 (#6851) - https://tg-archive.hyperdbg.org/2024-06.html#6851 -EventinjectDebugBreakpoint is tf processing? -https://tg-archive.hyperdbg.org/2024-06.html#6851 -Thu, 20 Jun 2024 15:03:55 +0000 +@395437265 on 2024-07-03 18:20:33+00:00 (#7073) + https://tg-archive.hyperdbg.org/2024-07.html#7073 +and a bit more below +https://tg-archive.hyperdbg.org/2024-07.html#7073 +Wed, 03 Jul 2024 18:20:33 +0000 - -
@instw0 on 2024-06-20 15:02:58+00:00 (#6850) - https://tg-archive.hyperdbg.org/2024-06.html#6850 -Снимок экрана 2024-06-20 180238.png -https://tg-archive.hyperdbg.org/2024-06.html#6850 -- Thu, 20 Jun 2024 15:02:58 +0000 +@395437265 on 2024-07-03 18:20:26+00:00 (#7072) + https://tg-archive.hyperdbg.org/2024-07.html#7072 +if i was allowed to use monitors on same page, it would help a lot :) +https://tg-archive.hyperdbg.org/2024-07.html#7072 ++ Wed, 03 Jul 2024 18:20:26 +0000 - -
@instw0 on 2024-06-20 15:02:00+00:00 (#6849) - https://tg-archive.hyperdbg.org/2024-06.html#6849 -debugger is frozen -https://tg-archive.hyperdbg.org/2024-06.html#6849 -Thu, 20 Jun 2024 15:02:00 +0000 +@HughEverett on 2024-07-03 18:19:25+00:00 (#7071) + https://tg-archive.hyperdbg.org/2024-07.html#7071 +Maybe a combination of loops could help. +https://tg-archive.hyperdbg.org/2024-07.html#7071 +Wed, 03 Jul 2024 18:19:25 +0000 - -
@HughEverett on 2024-06-20 15:01:24+00:00 (#6848) - https://tg-archive.hyperdbg.org/2024-06.html#6848 -Just added a check? Any modification to the TF Flag? -https://tg-archive.hyperdbg.org/2024-06.html#6848 -Thu, 20 Jun 2024 15:01:24 +0000 +@395437265 on 2024-07-03 18:18:42+00:00 (#7070) + https://tg-archive.hyperdbg.org/2024-07.html#7070 +yes, will see how it helps +https://tg-archive.hyperdbg.org/2024-07.html#7070 +Wed, 03 Jul 2024 18:18:42 +0000 - -
@HughEverett on 2024-06-20 15:00:35+00:00 (#6847) - https://tg-archive.hyperdbg.org/2024-06.html#6847 -Yes -https://tg-archive.hyperdbg.org/2024-06.html#6847 -Thu, 20 Jun 2024 15:00:35 +0000 +@395437265 on 2024-07-03 18:18:17+00:00 (#7069) + https://tg-archive.hyperdbg.org/2024-07.html#7069 +there are bunch of them, like 30 +https://tg-archive.hyperdbg.org/2024-07.html#7069 +Wed, 03 Jul 2024 18:18:17 +0000 - -
@HughEverett on 2024-06-20 15:00:11+00:00 (#6846) - https://tg-archive.hyperdbg.org/2024-06.html#6846 -Not sure what you trying to do? The division by zero error you're trying produce is handled in VMX root-mode because all of the events (except !epthook2, not !epthook) execute assembly in VMX root-mode, so it's not handled by guest (Windows) IDT and it's passed to HyperDbg's HOST IDT exception handler. -https://tg-archive.hyperdbg.org/2024-06.html#6846 -Thu, 20 Jun 2024 15:00:11 +0000 +@HughEverett on 2024-07-03 18:18:05+00:00 (#7068) + https://tg-archive.hyperdbg.org/2024-07.html#7068 +You can use global variables to check your $context with dynamic ranges. +https://tg-archive.hyperdbg.org/2024-07.html#7068 +Wed, 03 Jul 2024 18:18:05 +0000 - -
@HughEverett on 2024-06-20 14:56:03+00:00 (#6845) - https://tg-archive.hyperdbg.org/2024-06.html#6845 -Ah, this one is also mentioned by another person in issues. This one should be updated in the phnt repo that we used it as a submodule. We could also update HyperDbg's fork and comment it. I'll fix it. -https://tg-archive.hyperdbg.org/2024-06.html#6845 -Thu, 20 Jun 2024 14:56:03 +0000 +@395437265 on 2024-07-03 18:17:58+00:00 (#7067) + https://tg-archive.hyperdbg.org/2024-07.html#7067 +i want to do it automatically (e.g. all possible "end" calls) +https://tg-archive.hyperdbg.org/2024-07.html#7067 +Wed, 03 Jul 2024 18:17:58 +0000 - -
@instw0 on 2024-06-20 03:53:47+00:00 (#6844) - https://tg-archive.hyperdbg.org/2024-06.html#6844 -the debugger is frozen... -https://tg-archive.hyperdbg.org/2024-06.html#6844 -Thu, 20 Jun 2024 03:53:47 +0000 +@HughEverett on 2024-07-03 18:17:25+00:00 (#7066) + https://tg-archive.hyperdbg.org/2024-07.html#7066 +This one again could be handled from the by the method I told you earlier (pause()) +https://tg-archive.hyperdbg.org/2024-07.html#7066 +Wed, 03 Jul 2024 18:17:25 +0000 - -
@instw0 on 2024-06-20 03:41:59+00:00 (#6843) - https://tg-archive.hyperdbg.org/2024-06.html#6843 -Снимок экрана 2024-06-20 063305.png -https://tg-archive.hyperdbg.org/2024-06.html#6843 -- Thu, 20 Jun 2024 03:41:59 +0000 +@395437265 on 2024-07-03 18:16:39+00:00 (#7065) + https://tg-archive.hyperdbg.org/2024-07.html#7065 +thanks for advice +https://tg-archive.hyperdbg.org/2024-07.html#7065 +Wed, 03 Jul 2024 18:16:39 +0000 - -
@instw0 on 2024-06-20 03:41:45+00:00 (#6842) - https://tg-archive.hyperdbg.org/2024-06.html#6842 -i add a check rflags.tf in !tsc, and: -https://tg-archive.hyperdbg.org/2024-06.html#6842 -Thu, 20 Jun 2024 03:41:45 +0000 +@395437265 on 2024-07-03 18:16:33+00:00 (#7064) + https://tg-archive.hyperdbg.org/2024-07.html#7064 +yup, thats my idea for now :) +https://tg-archive.hyperdbg.org/2024-07.html#7064 +Wed, 03 Jul 2024 18:16:33 +0000 - -
@instw0 on 2024-06-20 03:39:39+00:00 (#6841) - https://tg-archive.hyperdbg.org/2024-06.html#6841 -thank you, did I understand correctly(in general): -configuring vmxcs to be notified when an event occurs -> processing in vmm? -https://tg-archive.hyperdbg.org/2024-06.html#6841 -Thu, 20 Jun 2024 03:39:39 +0000 +@HughEverett on 2024-07-03 18:16:22+00:00 (#7063) + https://tg-archive.hyperdbg.org/2024-07.html#7063 +Like put a !monitor on an entire page, and check for the $context. +https://tg-archive.hyperdbg.org/2024-07.html#7063 +Wed, 03 Jul 2024 18:16:22 +0000 - -
@chadgpt on 2024-06-20 02:33:06+00:00 (#6840) - https://tg-archive.hyperdbg.org/2024-06.html#6840 -没有 -https://tg-archive.hyperdbg.org/2024-06.html#6840 -Thu, 20 Jun 2024 02:33:06 +0000 +@395437265 on 2024-07-03 18:16:08+00:00 (#7062) + https://tg-archive.hyperdbg.org/2024-07.html#7062 +yea, going to do that +https://tg-archive.hyperdbg.org/2024-07.html#7062 +Wed, 03 Jul 2024 18:16:08 +0000 - -
@6190448061 on 2024-06-20 01:58:26+00:00 (#6839) - https://tg-archive.hyperdbg.org/2024-06.html#6839 -有没有自己人？😁 -https://tg-archive.hyperdbg.org/2024-06.html#6839 -Thu, 20 Jun 2024 01:58:26 +0000 +@HughEverett on 2024-07-03 18:15:50+00:00 (#7061) + https://tg-archive.hyperdbg.org/2024-07.html#7061 +Why don't you check ranges within if conditions? +https://tg-archive.hyperdbg.org/2024-07.html#7061 +Wed, 03 Jul 2024 18:15:50 +0000 - -
@395437265 on 2024-06-19 22:45:18+00:00 (#6838) - https://tg-archive.hyperdbg.org/2024-06.html#6838 -another question, im trying to use firstchance exception handling, im executing !epthook <hidden> code {31 c0 f7 f0} <- division by zero. but debugger console stays in infinite loop -https://tg-archive.hyperdbg.org/2024-06.html#6838 -Wed, 19 Jun 2024 22:45:18 +0000 +@395437265 on 2024-07-03 18:15:10+00:00 (#7060) + https://tg-archive.hyperdbg.org/2024-07.html#7060 +i will try to play with from/to params, but im afraid it will spam me with events though :( +https://tg-archive.hyperdbg.org/2024-07.html#7060 +Wed, 03 Jul 2024 18:15:10 +0000 - -
@395437265 on 2024-06-19 20:46:54+00:00 (#6837) - https://tg-archive.hyperdbg.org/2024-06.html#6837 -it conflicted with winnt.h -https://tg-archive.hyperdbg.org/2024-06.html#6837 -Wed, 19 Jun 2024 20:46:54 +0000 +@395437265 on 2024-07-03 18:14:25+00:00 (#7059) + https://tg-archive.hyperdbg.org/2024-07.html#7059 +0: kHyperDbg> !monitor x 760658a0 l 4 script { +> +> printf("monitor"); +> } + +0: kHyperDbg> !monitor x 760658f0 l 4 script { +> +> printf("monitor"); +> } +err, the page modification is not applied, make sure that you don't put multiple EPT Hooks or Monitors on a single page (c0000026) + +0: kHyperDbg> +https://tg-archive.hyperdbg.org/2024-07.html#7059 +Wed, 03 Jul 2024 18:14:25 +0000 - -
@395437265 on 2024-06-19 20:44:19+00:00 (#6836) - https://tg-archive.hyperdbg.org/2024-06.html#6836 -i commented out definitions in ntioapi.h, but i dont know if it is valid solution -https://tg-archive.hyperdbg.org/2024-06.html#6836 -Wed, 19 Jun 2024 20:44:19 +0000 +@395437265 on 2024-07-03 18:12:47+00:00 (#7058) + https://tg-archive.hyperdbg.org/2024-07.html#7058 +first i put monitor here main:017CA56B call dword ptr [eax+8] ; then inside script i want to do something like put monitor x eax+8 l 4 so it will follow function call, for example main:017C9D00, i know offest where dword ptr [edx+0Ch] will be called, let say 017C9D00+58, so i will put new monitor again on 017C9D00+58 and then, when im in desired function - print disasembly +https://tg-archive.hyperdbg.org/2024-07.html#7058 +Wed, 03 Jul 2024 18:12:47 +0000 - -
@395437265 on 2024-06-19 20:30:31+00:00 (#6835) - https://tg-archive.hyperdbg.org/2024-06.html#6835 -have latest VS SDK and WDK -https://tg-archive.hyperdbg.org/2024-06.html#6835 -Wed, 19 Jun 2024 20:30:31 +0000 +@HughEverett on 2024-07-03 18:10:58+00:00 (#7057) + https://tg-archive.hyperdbg.org/2024-07.html#7057 +Wait couldn't you put multiple !monitor hooks in one page? As long as I remember it was possible. 🤔🤔🤔 + +Not a big deal BTW, you can handle it through the script. + +E.g., check for your ranges within if conditions. $context pseudo-register contains the address of accessed memory address. However, I'm pretty sure we support multiple !monitor(s) on same page at some point. 🤔 +https://tg-archive.hyperdbg.org/2024-07.html#7057 +Wed, 03 Jul 2024 18:10:58 +0000 - -
@395437265 on 2024-06-19 20:30:16+00:00 (#6834) - https://tg-archive.hyperdbg.org/2024-06.html#6834 -hey there, im trying to build solution and getting: -https://tg-archive.hyperdbg.org/2024-06.html#6834 -- Wed, 19 Jun 2024 20:30:16 +0000 +@HughEverett on 2024-07-03 18:07:23+00:00 (#7056) + https://tg-archive.hyperdbg.org/2024-07.html#7056 +E.g., !monitor .FromGlobalVar .FromGlobalVar+0x85 script { ... } +https://tg-archive.hyperdbg.org/2024-07.html#7056 +Wed, 03 Jul 2024 18:07:23 +0000 - -
@HughEverett on 2024-06-19 15:34:48+00:00 (#6833) - https://tg-archive.hyperdbg.org/2024-06.html#6833 -VMCALL is unconditional, !dr needs configuration. Pls check this file as it's the file responsible for configuring events: - -https://github.com/HyperDbg/HyperDbg/blob/master/hyperdbg/hprdbgkd/code/debugger/events/ApplyEvents.c -https://tg-archive.hyperdbg.org/2024-06.html#6833 -- Wed, 19 Jun 2024 15:34:48 +0000 +@395437265 on 2024-07-03 18:06:27+00:00 (#7055) + https://tg-archive.hyperdbg.org/2024-07.html#7055 +ok, let me explain a bit +https://tg-archive.hyperdbg.org/2024-07.html#7055 +Wed, 03 Jul 2024 18:06:27 +0000 - -
@instw0 on 2024-06-19 12:47:42+00:00 (#6832) - https://tg-archive.hyperdbg.org/2024-06.html#6832 -accordingly !vmcall, !dr... they also cause the exit from the virtual machine (vmexit) -https://tg-archive.hyperdbg.org/2024-06.html#6832 -Wed, 19 Jun 2024 12:47:42 +0000 +@HughEverett on 2024-07-03 18:05:43+00:00 (#7054) + https://tg-archive.hyperdbg.org/2024-07.html#7054 +Which means you can calculate your addresses in global variables and use them as parameters to the !monitor. +https://tg-archive.hyperdbg.org/2024-07.html#7054 +Wed, 03 Jul 2024 18:05:43 +0000 - -
@HughEverett on 2024-06-19 11:43:59+00:00 (#6831) - https://tg-archive.hyperdbg.org/2024-06.html#6831 -Basically, hwdbg registers are like @hw_pin0, @hw_pin1, @hw_pin2, ..., @hw_pinX and @hw_port0, @hw_port1, @hw_port2, ..., @hw_portX. We need to find the best way of adding these registers (and new pseudo-registers) to the parser. -https://tg-archive.hyperdbg.org/2024-06.html#6831 -Wed, 19 Jun 2024 11:43:59 +0000 +@395437265 on 2024-07-03 18:05:40+00:00 (#7053) + https://tg-archive.hyperdbg.org/2024-07.html#7053 +if i put monitor on whole page, it will flood with calls... +https://tg-archive.hyperdbg.org/2024-07.html#7053 +Wed, 03 Jul 2024 18:05:40 +0000 - -
@HughEverett on 2024-06-19 11:40:26+00:00 (#6830) - https://tg-archive.hyperdbg.org/2024-06.html#6830 -@xmaple555 we need to think of the best way to parse scripts of the hwdbg debugger. The registers and pseudo-registers of the hwdbg is different from x64 registers. 🤔 -https://tg-archive.hyperdbg.org/2024-06.html#6830 -Wed, 19 Jun 2024 11:40:26 +0000 +@HughEverett on 2024-07-03 18:04:47+00:00 (#7052) + https://tg-archive.hyperdbg.org/2024-07.html#7052 +Not sure if I understand what you mean but !monitor receives (to/from) parameters from the script expressions: + +https://github.com/HyperDbg/HyperDbg/blob/a691c1df3be48660907fcf93840302a8c4650ff4/hyperdbg/libhyperdbg/code/debugger/commands/extension-commands/monitor.cpp#L204 +https://tg-archive.hyperdbg.org/2024-07.html#7052 ++ Wed, 03 Jul 2024 18:04:47 +0000 - -
@HughEverett on 2024-06-19 11:33:34+00:00 (#6829) - https://tg-archive.hyperdbg.org/2024-06.html#6829 -photo_2024-06-19_11-33-34.jpg -https://tg-archive.hyperdbg.org/2024-06.html#6829 -- Wed, 19 Jun 2024 11:33:34 +0000 +@395437265 on 2024-07-03 18:03:45+00:00 (#7051) + https://tg-archive.hyperdbg.org/2024-07.html#7051 +lemme prepare sample +https://tg-archive.hyperdbg.org/2024-07.html#7051 +Wed, 03 Jul 2024 18:03:45 +0000 - -
@HughEverett on 2024-06-19 11:33:34+00:00 (#6828) - https://tg-archive.hyperdbg.org/2024-06.html#6828 -Development progress update: hwdbg has reached the point where it can run HyperDbg scripts (dslang) for chip/FPGA debugging. Still under development! - -https://github.com/HyperDbg/HyperDbg/tree/dev/hwdbg -https://tg-archive.hyperdbg.org/2024-06.html#6828 -- Wed, 19 Jun 2024 11:33:34 +0000 +@HughEverett on 2024-07-03 18:02:09+00:00 (#7050) + https://tg-archive.hyperdbg.org/2024-07.html#7050 +I thought it's possible. 🤔 +https://tg-archive.hyperdbg.org/2024-07.html#7050 +Wed, 03 Jul 2024 18:02:09 +0000 - -
@HughEverett on 2024-06-19 11:27:39+00:00 (#6826) - https://tg-archive.hyperdbg.org/2024-06.html#6826 -Conditions checks for each extension command is basically software-side implemented. RDTSC/RDTSCP cause conditional VM-exits (not remember, either on primary or secondary proc-based VMCS controls). -https://tg-archive.hyperdbg.org/2024-06.html#6826 -Wed, 19 Jun 2024 11:27:39 +0000 +@HughEverett on 2024-07-03 18:01:56+00:00 (#7049) + https://tg-archive.hyperdbg.org/2024-07.html#7049 +Wait, you cannot put two !monitors in one page? +https://tg-archive.hyperdbg.org/2024-07.html#7049 +Wed, 03 Jul 2024 18:01:56 +0000 - -
@archercreat on 2024-06-19 08:14:41+00:00 (#6825) - https://tg-archive.hyperdbg.org/2024-06.html#6825 -Ah yes, my bad. It actually cares 😀 https://github.com/jmpoep/vmprotect-3.5.1/blob/d8fcb7c0ffd4fb45a8cfbd770c8b117d7dbe52b5/runtime/core.cc#L306 -https://tg-archive.hyperdbg.org/2024-06.html#6825 -Wed, 19 Jun 2024 08:14:41 +0000 +@395437265 on 2024-07-03 17:56:05+00:00 (#7048) + https://tg-archive.hyperdbg.org/2024-07.html#7048 +so far i know call dword ptr [eax+8] location, that is executed always +https://tg-archive.hyperdbg.org/2024-07.html#7048 +Wed, 03 Jul 2024 17:56:05 +0000 - -
@instw0 on 2024-06-19 08:09:03+00:00 (#6824) - https://tg-archive.hyperdbg.org/2024-06.html#6824 -RDTSC? -https://tg-archive.hyperdbg.org/2024-06.html#6824 -Wed, 19 Jun 2024 08:09:03 +0000 +@395437265 on 2024-07-03 17:55:03+00:00 (#7047) + https://tg-archive.hyperdbg.org/2024-07.html#7047 +so i need to calculate the target function at the very end of this +https://tg-archive.hyperdbg.org/2024-07.html#7047 +Wed, 03 Jul 2024 17:55:03 +0000 - -
@archercreat on 2024-06-19 07:56:52+00:00 (#6823) - https://tg-archive.hyperdbg.org/2024-06.html#6823 -Not related to hyperdbg, but vmprotect does not care if you break at cpuid or at the nop. https://github.com/jmpoep/vmprotect-3.5.1/blob/d8fcb7c0ffd4fb45a8cfbd770c8b117d7dbe52b5/runtime/core.cc#L771 -https://tg-archive.hyperdbg.org/2024-06.html#6823 -Wed, 19 Jun 2024 07:56:52 +0000 +@395437265 on 2024-07-03 17:54:25+00:00 (#7046) + https://tg-archive.hyperdbg.org/2024-07.html#7046 +so the chain actually is : call dword ptr [eax+8] -> ( main:017C9D0E call dword ptr [edx+0Ch] OR main:017C9BEE call dword ptr [edx+0Ch]) +https://tg-archive.hyperdbg.org/2024-07.html#7046 +Wed, 03 Jul 2024 17:54:25 +0000 - -
@instw0 on 2024-06-19 07:36:56+00:00 (#6822) - https://tg-archive.hyperdbg.org/2024-06.html#6822 -it's just that cpuid causes an unconditional vmexit anyway, and in the case of !rdtsc? -https://tg-archive.hyperdbg.org/2024-06.html#6822 -Wed, 19 Jun 2024 07:36:56 +0000 +@395437265 on 2024-07-03 17:53:36+00:00 (#7045) + https://tg-archive.hyperdbg.org/2024-07.html#7045 +edx will point to different offsets +https://tg-archive.hyperdbg.org/2024-07.html#7045 +Wed, 03 Jul 2024 17:53:36 +0000 - -
@instw0 on 2024-06-19 07:34:27+00:00 (#6821) - https://tg-archive.hyperdbg.org/2024-06.html#6821 -yes, I've read it, I just wanted to clarify that the debugger is at the event !cpuid, !rdtsc set conditions in the vmxsc structure? then vmm receives a notification(or vmexit)? -https://tg-archive.hyperdbg.org/2024-06.html#6821 -Wed, 19 Jun 2024 07:34:27 +0000 +@395437265 on 2024-07-03 17:53:08+00:00 (#7044) + https://tg-archive.hyperdbg.org/2024-07.html#7044 +something like + + main:017C9D0E call dword ptr [edx+0Ch] +and +main:017C9BEE call dword ptr [edx+0Ch] + +those are different subs, but stays within one page, so i cant put !monitors on both calls +https://tg-archive.hyperdbg.org/2024-07.html#7044 +Wed, 03 Jul 2024 17:53:08 +0000 - -
@HughEverett on 2024-06-19 06:09:16+00:00 (#6820) - https://tg-archive.hyperdbg.org/2024-06.html#6820 -You need to provide more details. What is the generation of your processor? which version of Windows? and how to reproduce it? -https://tg-archive.hyperdbg.org/2024-06.html#6820 -Wed, 19 Jun 2024 06:09:16 +0000 +@HughEverett on 2024-07-03 17:50:23+00:00 (#7043) + https://tg-archive.hyperdbg.org/2024-07.html#7043 +What do you mean by dynamic calls calculation? 🤨 +https://tg-archive.hyperdbg.org/2024-07.html#7043 +Wed, 03 Jul 2024 17:50:23 +0000 - -
@zhang_derek on 2024-06-19 05:57:16+00:00 (#6819) - https://tg-archive.hyperdbg.org/2024-06.html#6819 -How to fix -https://tg-archive.hyperdbg.org/2024-06.html#6819 -Wed, 19 Jun 2024 05:57:16 +0000 +@395437265 on 2024-07-03 17:50:07+00:00 (#7042) + https://tg-archive.hyperdbg.org/2024-07.html#7042 +ok, i will create issue +https://tg-archive.hyperdbg.org/2024-07.html#7042 +Wed, 03 Jul 2024 17:50:07 +0000 - -
@zhang_derek on 2024-06-19 05:56:57+00:00 (#6818) - https://tg-archive.hyperdbg.org/2024-06.html#6818 -win10 bluescreen， -https://tg-archive.hyperdbg.org/2024-06.html#6818 -Wed, 19 Jun 2024 05:56:57 +0000 +@395437265 on 2024-07-03 17:49:16+00:00 (#7041) + https://tg-archive.hyperdbg.org/2024-07.html#7041 +this is good to know.. bad thing those dynamic calls are calculated within one page :( +https://tg-archive.hyperdbg.org/2024-07.html#7041 +Wed, 03 Jul 2024 17:49:16 +0000 - -
@HughEverett on 2024-06-19 04:43:13+00:00 (#6817) - https://tg-archive.hyperdbg.org/2024-06.html#6817 -RDTSC is configured from VMCS, VMCALL is unconditional VM-exit and !msrread !msrwrite use MSR Bitmaps. Take a look at Hypervisor From Scratch, I think it gives you an idea how HyperDbg works internally: - -https://rayanfam.com/tutorials/ -https://tg-archive.hyperdbg.org/2024-06.html#6817 -- Wed, 19 Jun 2024 04:43:13 +0000 +@HughEverett on 2024-07-03 17:49:12+00:00 (#7040) + https://tg-archive.hyperdbg.org/2024-07.html#7040 +You need to ask @xmaple555 to fix it, I don't know that much about the script engine parser. 🙂🙃 +https://tg-archive.hyperdbg.org/2024-07.html#7040 +Wed, 03 Jul 2024 17:49:12 +0000 - -
@instw0 on 2024-06-19 04:36:17+00:00 (#6816) - https://tg-archive.hyperdbg.org/2024-06.html#6816 -read msr in vmxcs? -https://tg-archive.hyperdbg.org/2024-06.html#6816 -Wed, 19 Jun 2024 04:36:17 +0000 +@395437265 on 2024-07-03 17:47:37+00:00 (#7039) + https://tg-archive.hyperdbg.org/2024-07.html#7039 +hm. in main script it told me there is error when i put return; +https://tg-archive.hyperdbg.org/2024-07.html#7039 +Wed, 03 Jul 2024 17:47:37 +0000 - -
@instw0 on 2024-06-19 04:35:33+00:00 (#6815) - https://tg-archive.hyperdbg.org/2024-06.html#6815 -how do you keep track of instructions that don't cause the VM to exit? example RDTCS, vmcall... -https://tg-archive.hyperdbg.org/2024-06.html#6815 -Wed, 19 Jun 2024 04:35:33 +0000 +@HughEverett on 2024-07-03 17:47:34+00:00 (#7038) + https://tg-archive.hyperdbg.org/2024-07.html#7038 +No, pause will pause the debugger immediately. Context is preserved. +https://tg-archive.hyperdbg.org/2024-07.html#7038 +Wed, 03 Jul 2024 17:47:34 +0000 - -
@HughEverett on 2024-06-19 04:32:31+00:00 (#6814) - https://tg-archive.hyperdbg.org/2024-06.html#6814 -We process it as VM-exit, not interrupt. -https://tg-archive.hyperdbg.org/2024-06.html#6814 -Wed, 19 Jun 2024 04:32:31 +0000 +@HughEverett on 2024-07-03 17:46:56+00:00 (#7037) + https://tg-archive.hyperdbg.org/2024-07.html#7037 +https://docs.hyperdbg.org/commands/scripting-language/constants-and-functions +https://tg-archive.hyperdbg.org/2024-07.html#7037 ++ Wed, 03 Jul 2024 17:46:56 +0000 - -
@HughEverett on 2024-06-19 04:32:15+00:00 (#6813) - https://tg-archive.hyperdbg.org/2024-06.html#6813 -For !tsc Yes, for !cpuid No. CPUID is unconditional VM-exit. Here is a list of instructions with unconditional VM-exit. -https://tg-archive.hyperdbg.org/2024-06.html#6813 -- Wed, 19 Jun 2024 04:32:15 +0000 +@HughEverett on 2024-07-03 17:46:39+00:00 (#7036) + https://tg-archive.hyperdbg.org/2024-07.html#7036 +@xmaple555 implemented the functions logic, you can use it like a function. +https://tg-archive.hyperdbg.org/2024-07.html#7036 +Wed, 03 Jul 2024 17:46:39 +0000 - -
@instw0 on 2024-06-18 13:32:00+00:00 (#6812) - https://tg-archive.hyperdbg.org/2024-06.html#6812 -then we process it in vmm as a debugger interrupt? -https://tg-archive.hyperdbg.org/2024-06.html#6812 -Tue, 18 Jun 2024 13:32:00 +0000 +@395437265 on 2024-07-03 17:46:35+00:00 (#7035) + https://tg-archive.hyperdbg.org/2024-07.html#7035 +i understand, but pause will loose context in this case.. +https://tg-archive.hyperdbg.org/2024-07.html#7035 +Wed, 03 Jul 2024 17:46:35 +0000 - -
@instw0 on 2024-06-18 13:30:09+00:00 (#6811) - https://tg-archive.hyperdbg.org/2024-06.html#6811 -when we use events !cpuid, !rdtsc do we configure the vmxcs structure to vm-exit when an event occurs? -https://tg-archive.hyperdbg.org/2024-06.html#6811 -Tue, 18 Jun 2024 13:30:09 +0000 +@395437265 on 2024-07-03 17:43:39+00:00 (#7034) + https://tg-archive.hyperdbg.org/2024-07.html#7034 +yup +https://tg-archive.hyperdbg.org/2024-07.html#7034 +Wed, 03 Jul 2024 17:43:39 +0000 - -
@HughEverett on 2024-06-18 12:57:08+00:00 (#6810) - https://tg-archive.hyperdbg.org/2024-06.html#6810 -Not sure if I correctly understand what you mean. 🤔 -What is event(!cpu)? -https://tg-archive.hyperdbg.org/2024-06.html#6810 -Tue, 18 Jun 2024 12:57:08 +0000 +@HughEverett on 2024-07-03 17:39:15+00:00 (#7033) + https://tg-archive.hyperdbg.org/2024-07.html#7033 +Like a function return? 🤨 +https://tg-archive.hyperdbg.org/2024-07.html#7033 +Wed, 03 Jul 2024 17:39:15 +0000 - -
@HughEverett on 2024-06-18 12:56:06+00:00 (#6809) - https://tg-archive.hyperdbg.org/2024-06.html#6809 -NMI is not realted to step-in or step-over, HyperDbg just uses NMI to halt (pause) all cores in the Debugger Mode. -https://tg-archive.hyperdbg.org/2024-06.html#6809 -Tue, 18 Jun 2024 12:56:06 +0000 +@395437265 on 2024-07-03 17:35:25+00:00 (#7032) + https://tg-archive.hyperdbg.org/2024-07.html#7032 +it would improve scripting a lot i think, no additional if branches +https://tg-archive.hyperdbg.org/2024-07.html#7032 +Wed, 03 Jul 2024 17:35:25 +0000 - -
+@HughEverett on 2024-06-18 12:54:33+00:00 (#6808) - https://tg-archive.hyperdbg.org/2024-06.html#6808 -Only the 'i' command (instrumentation step-in) uses MTF (Monitor Trap Flag). Other stepping command like 't' is implemented same as WinDbg by using RFLAGS's TF. -https://tg-archive.hyperdbg.org/2024-06.html#6808 -Tue, 18 Jun 2024 12:54:33 +0000 +@395437265 on 2024-07-03 17:34:58+00:00 (#7031) + https://tg-archive.hyperdbg.org/2024-07.html#7031 +no.. sample from my script: + + n = check_address(edx+c); + k = 0; + if (n == 1){ + printf("%s %s DYN CALL TO %x\n",$date, $time, dd(edx+c)); + k = 1; + } else { + printf("%s %s DYN CALL, BUT FAILED TO DECODE %x\n",$date, $time, edx+c); +return here as memory is invalid, so no longer processing needed + } + if (k == 1){.... +https://tg-archive.hyperdbg.org/2024-07.html#7031 +Wed, 03 Jul 2024 17:34:58 +0000 +- +
+@HughEverett on 2024-07-03 17:30:04+00:00 (#7030) + https://tg-archive.hyperdbg.org/2024-07.html#7030 +You can use them along with the $event_id pseudo-register. +https://tg-archive.hyperdbg.org/2024-07.html#7030 ++ Wed, 03 Jul 2024 17:30:04 +0000 +- +
+@HughEverett on 2024-07-03 17:27:46+00:00 (#7029) + https://tg-archive.hyperdbg.org/2024-07.html#7029 +There are a couple of functions for disabling/enabling and removing or short-circuiting events here: +https://docs.hyperdbg.org/commands/scripting-language/functions/events +https://tg-archive.hyperdbg.org/2024-07.html#7029 ++ Wed, 03 Jul 2024 17:27:46 +0000 +- +
+@HughEverett on 2024-07-03 17:24:37+00:00 (#7028) + https://tg-archive.hyperdbg.org/2024-07.html#7028 +Exit script? What do you mean? Like disabling the event? 🤨 +https://tg-archive.hyperdbg.org/2024-07.html#7028 +Wed, 03 Jul 2024 17:24:37 +0000 +- +
diff --git a/media/6927.jpg b/media/6927.jpg new file mode 100644 index 0000000..2f2200a Binary files /dev/null and b/media/6927.jpg differ diff --git a/media/6932.jpg b/media/6932.jpg new file mode 100644 index 0000000..af104c6 Binary files /dev/null and b/media/6932.jpg differ diff --git a/media/6936.jpg b/media/6936.jpg new file mode 100644 index 0000000..6946d0e Binary files /dev/null and b/media/6936.jpg differ diff --git a/media/6955.jpg b/media/6955.jpg new file mode 100644 index 0000000..6dcd232 Binary files /dev/null and b/media/6955.jpg differ diff --git a/media/6981.jpg b/media/6981.jpg new file mode 100644 index 0000000..914af0a Binary files /dev/null and b/media/6981.jpg differ diff --git a/media/6987.jpg b/media/6987.jpg new file mode 100644 index 0000000..5990412 Binary files /dev/null and b/media/6987.jpg differ diff --git a/media/7030.jpg b/media/7030.jpg new file mode 100644 index 0000000..2246dce Binary files /dev/null and b/media/7030.jpg differ diff --git a/media/7072.jpg b/media/7072.jpg new file mode 100644 index 0000000..c0127e9 Binary files /dev/null and b/media/7072.jpg differ diff --git a/media/7083.jpg b/media/7083.jpg new file mode 100644 index 0000000..11d39b4 Binary files /dev/null and b/media/7083.jpg differ diff --git a/media/7117.jpg b/media/7117.jpg new file mode 100644 index 0000000..de6c804 Binary files /dev/null and b/media/7117.jpg differ diff --git a/media/avatar_1460445967.jpg b/media/avatar_1460445967.jpg new file mode 100644 index 0000000..24c5585 Binary files /dev/null and b/media/avatar_1460445967.jpg differ diff --git a/media/avatar_474368680.jpg b/media/avatar_474368680.jpg new file mode 100644 index 0000000..58a7c23 Binary files /dev/null and b/media/avatar_474368680.jpg differ diff --git a/media/avatar_6335528779.jpg b/media/avatar_6335528779.jpg new file mode 100644 index 0000000..7969a55 Binary files /dev/null and b/media/avatar_6335528779.jpg differ diff --git a/media/avatar_6950792244.jpg b/media/avatar_6950792244.jpg new file mode 100644 index 0000000..9fa1671 Binary files /dev/null and b/media/avatar_6950792244.jpg differ diff --git a/media/avatar_809141759.jpg b/media/avatar_809141759.jpg new file mode 100644 index 0000000..e2efa0c Binary files /dev/null and b/media/avatar_809141759.jpg differ diff --git a/media/thumb_6927.jpg b/media/thumb_6927.jpg new file mode 100644 index 0000000..fa0c0a9 Binary files /dev/null and b/media/thumb_6927.jpg differ diff --git a/media/thumb_6932.jpg b/media/thumb_6932.jpg new file mode 100644 index 0000000..123e67f Binary files /dev/null and b/media/thumb_6932.jpg differ diff --git a/media/thumb_6936.jpg b/media/thumb_6936.jpg new file mode 100644 index 0000000..f3544d2 Binary files /dev/null and b/media/thumb_6936.jpg differ diff --git a/media/thumb_6955.jpg b/media/thumb_6955.jpg new file mode 100644 index 0000000..20fc5f0 Binary files /dev/null and b/media/thumb_6955.jpg differ diff --git a/media/thumb_6981.jpg b/media/thumb_6981.jpg new file mode 100644 index 0000000..7dc94d8 Binary files /dev/null and b/media/thumb_6981.jpg differ diff --git a/media/thumb_6987.jpg b/media/thumb_6987.jpg new file mode 100644 index 0000000..b1c63b2 Binary files /dev/null and b/media/thumb_6987.jpg differ diff --git a/media/thumb_7030.jpg b/media/thumb_7030.jpg new file mode 100644 index 0000000..4f45d01 Binary files /dev/null and b/media/thumb_7030.jpg differ diff --git a/media/thumb_7072.jpg b/media/thumb_7072.jpg new file mode 100644 index 0000000..6d486c8 Binary files /dev/null and b/media/thumb_7072.jpg differ diff --git a/media/thumb_7083.jpg b/media/thumb_7083.jpg new file mode 100644 index 0000000..a064127 Binary files /dev/null and b/media/thumb_7083.jpg differ diff --git a/media/thumb_7117.jpg b/media/thumb_7117.jpg new file mode 100644 index 0000000..824cdb0 Binary files /dev/null and b/media/thumb_7117.jpg differ@HughEverett on 2024-07-03 17:24:07+00:00 (#7027) + https://tg-archive.hyperdbg.org/2024-07.html#7027 +It's actually possible in the VMM module to apply events immediately, but it's not exported to the user this way. Because the script engine IR generator is in the user-mode. If you want to do it, you can directly modify the source code and apply the event using a custom function. But, it's a really cool feature I think. 🤔 +I'll add it to the future to-do list but it probably won't be ready soon since it needs fundamental design changes. + +One way around it is by using: + +event (with a pause() function) + g + new event + +So, once your script is running, it continues the debuggee immediately after applying the first event and when your event executes the pause() function, the debugger is paused and the second event will be created. (If you didn't understand what I mean by this, please let me know, I could elaborate it more). +https://tg-archive.hyperdbg.org/2024-07.html#7027 +Wed, 03 Jul 2024 17:24:07 +0000
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2024
-
+
2020
2020
+
+
+
+
\ No newline at end of file
diff --git a/2024-07.html b/2024-07.html
new file mode 100644
index 0000000..6bd5a0d
--- /dev/null
+++ b/2024-07.html
@@ -0,0 +1,5274 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+
+ + @hyperdbg / + Public archive of HyperDbg Telegram messages. +
+-
+
+
-
+
+
+
+
-
+
+
+
+
+
+
\ No newline at end of file
diff --git a/index.atom b/index.atom
index 4a11a81..4a46c5d 100644
--- a/index.atom
+++ b/index.atom
@@ -2,875 +2,907 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ + @hyperdbg / + Public archive of HyperDbg Telegram messages. +
+-
+
+
-
+
+
+
+
-
+
+
