- 06 July 2023 (295 messages)
-
I didn't test it yet. But, I'm gonna test it right now. -
But the thing is once this event is triggered, the page is still not valid.
-
In this case, you can put a breakpoint on the next instruction (@rip).
-
-
-
x? 🤨
-
No, the 'x' is not supported.
-
This is not supported by HyperDbg, but I think it can be easily added. 🤔
-
I'll check it tonight to see if I can add this feature with a trivial patch.
-
No, it clears (removes) the event. It won't disable it.
-
event d 1
-
is for disabling it.
-
you can also use this function in script engine: https://docs.hyperdbg.org/commands/scripting-language/functions/events/event_disableevent_disable
Description of 'event_disable' function in HyperDbg Scripts
-
The difference between clearing and disabling is that clearing continues the debuggee, but disabling won't continue the debuggee.
-
Disabling means the event is logically disabled but it's effects is still working (e.g., page-faults still cause vm-exit) and by disabling it, you just tell the HyperDbg, won't trigger actions of this event for me.
-
but by removing, you just tell HyperDbg to remove it's effects and terminate it. Like I don't want #pf vm-exits anymore.
-
-
Does it crash the target process? Or BSOD the system?
-
no, I'm here to help. Tell us whatever happened there.
-
the process? or the system?
-
did you change anything in the process?
-
Are you using the 'dev' branch ?
-
I made some changes in the page-fault handler recently, I suspect those modifications might be problematic. 🤔
-
because, otherwise, we just re-inject the #PF. It should work normally.
-
I'm currently working on the HyperDbg to add the 'x' feature to the !monitor.
-
The problem is I don't know what is happening there. The script is just a simple interceptor for page-fault. If the problem is with #pf re-injector, then you should see the crash immediately. I think something else is happening there, because we simply re-inject the page-fault.
-
But wait a minute, I want to double check one thing
-
Can you remove these lines from the master branch and re-test it?
https://github.com/HyperDbg/HyperDbg/blob/a571781e8651998b982a9f53edf8f3d3501a6b2e/hyperdbg/hprdbghv/code/vmm/vmx/IdtEmulation.c#L145 -
I suspect, maybe this callback is problematic. 🤔
-
sure, I'm gonna add the 'x' feature now.
-
-
-
Did you use '--recursive' in the git?
-
-
How it's possible 🫠
Something that works previously in the same system is no longer building? 😳😳😳 -
😕
-
Can you compile each of them separately? I mean, do not compile the solution, just compiling each project in VS.
-
And, are you using the same VS2022? Any Visual Studio update?
-
-
-
This seems to be a problem with WDK. 🤔
-
Driver samples give build errors - Microsoft Q&A
I have windows 10, vs2019, the latest WDK and SDK. I can't get the windows driver samples to build. The samples were downloaded today and are dated late March PLX9x5x gives the following Severity Code Description Project File Line Suppression State…
-
np
-
this is a good reason for never updating the visual studio.
-
Each time that I update this Visual Studio, something is changed that prevent me from compiling my previous projects 🫠
-
-
One thing that I'm worried about adding 'rwx' to the !monitor is that what we should do after the event is triggered. 🤔
-
Maybe we could force Windows to context switch to a new process, by injecting IPI or CLOCK_INTR. But, not sure if it breaks Windows or not.
-
-
-
No, keep the last function.
-
IdtEmulationHandlePageFaults should be called. Otherwise, HyperDbg ignores page-faults and BSOD you immediately. 😅
-
-
👍
-
If we couldn't solve the problem using page-fault, we could write a simple assembly code that reads the target section and patch the current RIP. That's a simple solution to the problem. But, I'm really curious to see why page-fault handler is not working in this special case. Because generally, it handles thousands of PFs each seconds. So, if it's not working then it should BSOD you immediately, because your system is not able to handle page-faults but this special case is interesting.
-
-
you mean the modification didn't work?
-
okay, this seems to be a complex problem to solve.
-
Oh, if the packer get the timestamp of the system, then it can detect the wait time here.
-
But, I'm currently working on finishing the !monitor's rwx, I'll let you know once it's ready to test.
-
.
-
My only concern is this.
-
what's the issue?
-
I didn't get it, what do you mean that is closes?
-
-
Is there any special script that failed?
-
You mean after disabling the !exception, the target process crashes?
-
-
This is the problem I mentioned about the '.start'.
-
We have to change our implementation.
-
All of them will be fixed for the next version.
-
👌👍
-
Joined. -
I added the initial codes for RWX support in the !monitor command (https://github.com/HyperDbg/HyperDbg/commit/1c08354453f44bc2a075250d808087e2aad49455).
But I didn't test it yet. So, please wait until I fully test it (hopefully tomorrow) and after that, I'll let you know so you can test it. @ricnarinitial support for monitor RWX · HyperDbg/HyperDbg@1c08354State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
- 07 July 2023 (141 messages)
-
Hi, I didn't finish it yet 😬
But, I'm gonna start working on that right now. -
We could implment it too, by manually injecting page-faults into the guest. But, the thing is, how we can detect it when the page is finished loading into the memory. Do you have any idea for that?
-
WinDbg functionalities are compiled by Windows source code, that's how they can put some hooks somewhere in the code and notify the debugger about the last step of page-fault handler. We don't have this option, so we have to find a CPU-based solution.
-
If I understand it correctly. The answer is no. The system handles page-fault transparently without throwing exceptions to the user-mode. The user-mode never knows that a page-fault happened during its execution.
-
The user-mode is not supposed to know about page-faults as long as I know.
-
-
-
Once a page-fault happens the IRQL is raised to higher IRQLs, so, there is no waiting here. The user-mode code is always at PASSIVE_LEVEL which means there is no wait. It should be handled immediately.
-
-
-
The problem is that the debugger continued the system for some time and while hyperdbg is processing the user command, the target module's page fault is arrived and handled.
-
-
After that, HyperDbg configure the !exception and we loose the target #PF.
-
The way that we currently manage events is sending the user configurations to the user-mode of the debuggee and from user-mode we start sending the buffer to the kernel and then to VMX-root. That's why the debugger continues the debuggee for some times. It's surely not a good design, and has to be changed in the future versions but it's not trivial bug fix. Some of the mechanisms should be changed so we can support setting the events immediately.
-
Yes, it probably works like this.
-
Make sure to access to the buffer at least one time, e.g., using assembly code to access the buffer, mov something from it.
-
After that the address is paged-in.
-
-
no
-
you didn't specify an argument for the !exception.
-
using the above function you grab ALL exceptions 😅
-
Starting from 0th entry of IDT to 32nd entry of IDT.
-
Just intercept page-faults using '!exception e'
-
this 'e' refers to page-faults.
-
so, it continues?
-
ah, okay.
-
now, what we can conclude here?
-
🤔
-
You suspended the thread? Am I right?
-
-
And after that, you were able to access the memory?
-
'!exception e' should be followed by a process ID. Otherwise, it gets all page-faults in the system which is not what we expect it.
-
This is a correct script:
!exception e pid 1234 script {
printf("Page-fault happened in process: %x, on address: %llx", $pid, @cr2);
} -
Make sure set the PID.
-
It's the same because, HyperDbg continues the debuggee. And all the page-faults happen in the target process and handled by the system. After that we set it to intercept them, that why we loose it.
-
We have to find another way, it's probably not a good idea to use page-faults here.
-
Give me some times, I'll try to run your target packet binary with some injected assembly codes.
-
Once I finished this !monitor's 'x' feature, I'll come to the packet.
-
-
yeah it's okay. I think we could use some injected assembly codes to force page-in in the target process. After that, we could formulate our approach as a command in HyperDbg.
-
I'll get back to you once the rwx is finished.
-
The very first results shows that it works (not yet ready available for test). 🧐
-
@ricnar Please switch to the 'dev' branch. It's now ready to test.
-
Please note that, I changed the '.start' command's mechanism in the 'dev' branch, so in this branch you cannot use the '.start' command for now. You have to wait until I fix the process starting.
-
And also, please test it on a simple example for now. Together we have to find a solution for the pages that are not paged-in yet. But for now, just test it on simple examples. For example, I test it with 32-bit shellcode.
-
-
This is the code that I test 'rwx' feature.
-
Please note that, event short-circuiting blocks the execution in the target address. For example, assume that you want to prevent the execution in your target page, in this cases, you should short-circuit the event. E.g.,
!monitor x 7e0000 7e0999 pid 3a4c script {
printf("target address is executed: %llx\n", $context);
event_sc(1);
} -
Adding event_sc(1); will tell HyperDbg to block the execution and don't let the target to run any codes in target page.
-
But if you don't use event_sc(1); then HyperDbg by default will let the target to be executed normally for only one instruction and after that, a vm-exit happens. Again, the event will be triggered for the next instruction and so on.
-
So, if you don't use event_sc(1); then it's like stepping through the instructions one by one (each instruction in the target address range that wants to be executed will trigger the event). But, if you specify event_sc(1); then it simply blocks the execution and won't let your target code in the target page to run.
-
-
this is a 32-bit shell code.
-
-
You missed the last }
-
}
-
-
-
Yes. It seems that it's working. Did you expecting the same?
-
So, why do you switch to the process? You can use pause(); in your script.
-
yes. I mean if you want to break in this case, instead of switching to the target process, you can use pause();
-
-
No, the repetition is because Windows tries to run instruction in that special page, but each time HyperDbg blocks it. So, it again attempts to context switch to the target process and execute the instruction, again blocked. That's why you see repeating lines.
-
You can remove the 'printf' and it won't show anything.
-
Great. Is exactly the thing you want?
-
-
I think we could now find solutions for two remained problems. First, fixing the '.start' command so we can start processes correctly, second, we should find a way to bring pages-in.
-
Yes. Let me ask from my folks in twitter to see if they have any idea of how we can intercept the execution after injecting #PFs.
-
Hey, cool project. I setup 2 vms (since I'm on linux) but upon connecting via serial, it just hangs. I'm using latest dev version.
I ran the following command on my host vm first: .debug remote serial 115200 com2
And when I try to connect from the guest vm, it just gets stuck (see image). Any ideas how to fix or debug that? -
Hi,
Thanks for using HyperDbg ^^
First of all, always make sure to test the latest source code from the 'master' branch. Don't use the 'dev' branch as it might not work as expected.
Another question, are you using VMware workstation?
The order of commands that you used it wrong. First, you should listen on the debugger, after that you can run the debuggee. I think you didn't do it in order. -
And something to check. What is the COM port on debuggee and debugger? Can you verify that it's working and connected correctly? For example, by using a serial program like Putty or XCTU. Just make sure that you can send data successfully.
-
I'm using Virt-manager with Qemu/KVM on Linux. That's why I have 2 virtual machines with Windows connected over a serial port. I got it working now, but I get another error that the checksum is invalid. I'm using v0.3.0
-
Double checked with Putty, I'm getting data.
-
We never test HyperDbg on such a virtual machine. So, it might not work. But, it might work and the fastest way to check it, is connecting in VMI mode. Instead of connecting to another VM, try to see if the hypervisor is successfully loading in local debugging or not.
-
Run these commands in your VM:
.connect local
load vmm -
And let me know, if these commands freeze or BSOD your system or if it's working.
-
yes, it's working. but i can't really do much in vmi mode. Most of the time I just get the warning that it's still in beta and not stable
-
-
Oh, that's a really good news that it's working there. 😅
-
Okay, now let's return to our case, what happens once you connect over serial? Is there any error? Do you see checksum errors?
-
Will it freeze the system? Or you can use your system after that?
-
Okay, so we can conclude that it's a user-mode bug and fortunately user-mode bugs are easy to investigate. Do you have the VS2022+WDK in your target machine to build HyperDbg?
-
I'm thinking of tracing HyperDbg using VS debugger to see where it stucked that leads to freezing its user-mode part.
-
Let me know if you find anything about it. This is a good news that HyperDbg works on KVM (at least on VMI mode). We have to make it stable and create a documentation entry about running it on KVM.
- 08 July 2023 (6 messages)
-
This is really weird. Because serial ports in virtual machine are supposed to transmit data without error. The same error was reported by @prekvapko on physical systems. So, I'm thinking of maybe a raise condition exists somewhere in transmission of data which won't reveal itself because of the way VMware workstation transmits the data. 🤔
-
By the way, I'm not familiar with virtualization in Linux at all. I only used virtualbox on Linux. But I'm gonna test this problem after I solved the problem with the '.start' and bringing the pages in. Is virt-manager the most popular way of using KVM in Linux? Is there any alternatives? What is the easiest and most used way of using KVM in the way that I can test HyperDbg on Windows?
-
Qemu? -
I don't know that much about Qemu but from what I know they used Qemu in KVM. For example, instead of handling continuous VM-exits for serving IOMMUs, they used Qemu to emulate MOV instructions, preventing unnecessary VM-exits (EPT violations). Other than that, I don't have any idea how Qemu is related to KVM. If anybody knows, I would be thankful to know.
- 09 July 2023 (1 messages)
-
yes, thanks
- 10 July 2023 (225 messages)
-
-
-
Hi,
Just for your information, the problem with the '.start' command is fixed and the code is now in a working state (in the 'dev' branch), and right now I'm working on adding the '.pagein' equivalent command to the HyperDbg, it will probably finished tomorrow. -
-
Of course, the namedpipe is not valid in the target guest. I've never connect it like this but I'm sure several users reported that they connect it like this.
-
🤨🤨
-
-
I think it's better to test it with other serial port applications like XCTU or PuTTY.
-
Because, generally, HyperDbg just needs a simple serial connection, and there is no need to load driver, etc. Maybe it's better to test the serial connection with simple serial listening applications and after that we can use it in HyperDbg.
-
Btw, if none of them worked, there are some applications that create virtual serial drives on the host. I think you can use them to create serveral virtual serial devices and then use VMware to connect them together. But, that's probably a very weird approach 😅
-
-
I think it's the same. I mean as long as there is a simple serial connection between 2 VMs, HyperDbg is able to work.
-
-
Are you sure that the named pipe version is valid? Can you run HyperDbg debugger (not debuggee)? Will it listen for the connection?
-
Do you mean that you connect guest to the host?
-
-
As it shows the named pipe is not valid. I think VMware won't connect named pipe to the guest VMs.
-
-
Are you sure that COM2 is connected to the correct VM? Can you verify it? You should use for example putty, or XCTU to send and receive something over serial.
-
This method will prove whether the serial connection is working or not.
-
So, it's a VMware misconfiguration. Am I right?
-
I'm pretty sure someone did the same thing. I think it was mentioned in OST2 discussions. Let me check it.
-
-
-
Oh, that's great. I have to add an explanation about how to connect two VMs to the docs.
-
Also, make sure to test new implemention of the '.start' command. Pull it from the git's dev branch. I'll add the .pagein command tomorrow.
-
Thanks 🙏
-
-
-
Thanks 👍
-
-
Is it reproducible?
-
-
-
-
-
Will not download? Are you sure the connection to the internet is okay?
-
-
So, did you configure the symbol path in target machine?
-
-
So, it isn't loaded?
-
-
No, you didn't pull the latest commit.
-
-
GitHub - HyperDbg/HyperDbg at dev
State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
There multiple commits after that. There is a problem with your fetch application. Can you use 'git pull' command?
-
And also make sure you have an internet connection as you're running between two isolated VMs.
-
-
It's the latest 👍
-
-
-
Works as expected?
-
-
-
-
-
-
Yes. The only thing that remain unsolved is the '.pagein' command which hopefully will be finished tomorrow.
-
We could hide it by EPT.
-
No, it's pretty fine we could easily mitigate this problem but employing EPT.
-
The idea is to inject #PF to the debuggee while setting the trap flag (RFLAGS.TF), so once the debuggee is continued, the page-fault is delivered to operating system and after running one instruction from the current context, a #DB is thrown which leads to a VM-exit and HyperDbg captures the debugee again.
@hyperdbg / Public archive of HyperDbg Telegram messages.
- 01 Jul 2023 (23)
- 02 Jul 2023 (9)
- 03 Jul 2023 (238)
- 04 Jul 2023 (6)
- 05 Jul 2023 (110)
- 06 Jul 2023 (295)
- 07 Jul 2023 (141)
- 08 Jul 2023 (6)
- 09 Jul 2023 (1)
- 10 Jul 2023 (225)
- 11 Jul 2023 (164)
- 12 Jul 2023 (48)
- 13 Jul 2023 (114)
- 14 Jul 2023 (14)
- 15 Jul 2023 (31)
- 16 Jul 2023 (34)
- 17 Jul 2023 (6)
- 18 Jul 2023 (17)
- 19 Jul 2023 (22)
- 20 Jul 2023 (10)
- 21 Jul 2023 (2)
- 22 Jul 2023 (14)
- 23 Jul 2023 (121)
- 24 Jul 2023 (43)
- 25 Jul 2023 (5)
- 26 Jul 2023 (29)
- 27 Jul 2023 (19)
- 28 Jul 2023 (1)
- 29 Jul 2023 (7)
- 30 Jul 2023 (396)
- 31 Jul 2023 (64)