Stealth operation and guest kernel drivers? #213
Replies: 1 comment
-
Hi, Yes, you're right, that's an issue. It could be bypassed in several ways in HyperDbg if the target is a user-mode application like using the !syscall command and changing the system call(s) that query for a list of drivers, etc. As mentioned in the documentation and the academic paper, HyperDbg won't guarantee 100% transparency. Even though it enhances the overall transparency but our main focus is not to improve the stealthiness for now. Due to the limited number of contributors and those who spend time on developing HyperDbg, currently, we're focused to bring and add new features and make the debugger even more stable, but sure we will revisit the transparency to make it more and more transparent. As you know, this is a never-ending cat-and-mouse fight between the debugger makers and anti-debugging methods. Meanwhile, we would be happy if you can contribute to the transparent mode of HyperDbg, please take a look at Contribution Guide if you can allocate some time enhancing it. :) |
Beta Was this translation helpful? Give feedback.
-
I've been reading the documentation on the various possibilities with regards to HyperDbg operation, and it seems to me that all options involve loading a kernel driver into the debuggee, that then connects to the host through a serial port or a TCP connection.
I am confused as to how this allows stealth operation, especially for rootkits running in ring 0. After all, wouldn't that easily be detectable by checking for unsigned kernel drivers, or in the case of a HyperDbg-specific detection, looking for familiar code in the kernelspace memory?
Beta Was this translation helpful? Give feedback.
All reactions