What kind of run for the next talk? Let me choose Bion and Sina with the talk about
Invisible Hypervisors, Delphi, Malbert, and Elisis with Hyperdi BG.
Great. Hello, everyone. Thanks for joining. My name is Bion and I'm a PhD candidate at
Fusek in Amsterdam. I'm also a security researcher, mainly specializing in UEFI,
Hypervisor, and PCI express security. My previous work includes Thunderbolt vulnerability
research. This is my colleague Sina. Hello, I'm Sina. I'm also a PhD candidate in
FI University at Amsterdam and I'm also enjoying my time spending on system programming, maintaining
Hyperdi BG, and most of the time Windows internals and Digital Designs, you can see some
of my works in my blog. So we'll be providing two talks for you today about Hyperdi BG.
Later today in the virtualization track, we'll have a general introduction to Hyperdi BG,
where we show you what it can do, but also how we've implemented all of the features
underdrewed. So if you're really interested in some in-depth technical details, please join us
later today. And the current talk is, yeah, that's happening right now where we'll be talking
about a specific use case, which is analyzing malware using Hyperdi BG. So let's talk about
Hyperdi BG. Hyperdi BG is a hypervisor based debugger, and it's a hypervisor and it's a debugger.
And the way we do is, is we leverage the Intel ISA's virtualization extensions that are
actually originally intended for virtualization, but we are using instead for various debugging
functionalities that are normally not possible with classic debuggers. And being hypervisor
based means that we operate independently of any OS level, debugging APIs. And this opens up
all sorts of possibilities, which we'll be talking about in a little bit. Our first release was
in 2022 for Windows and it's been actively maintained since. We are also working on a UE5 based OS
agnostic hypervisor agent so that we can support Linux, a BSD, and basically any other operating system.
So on X86, the CPU offers various privileged levels through so-called protection rings
and the classic debuggers like WinDBG and GDB and many other stereotypically implemented
either in Ring 3 or in Ring 0, the kernel. And basically, yeah, the deeper that you go,
the more prefers that you are, and the more feasibility you have over the system, and over the
debugging that you're debugging. So if you are into the buggers or I've used them before these
names will sound familiar to you. So there's K-Propes on Linux, which lets you do all sorts of interesting
stuff even tracing in the kernel. There is, of course, S-Trace for inspecting CIS calls and there's
P-Trace and U-Propes for user space. And if you're a Windows user, then a WinDBG will be
the tool of choice and it will let you do debugging on any of these three levels, though it
doesn't let you do it across the main, which is also one of the things that we can do.
And this is where hyperDBG lists, right there in Ring-0.
So debugging and analyzing malware, I'm giving the word Tuesday now.
So for debugging and analyzing malware, there are lots of anti debugging and anti hypervisor
techniques. And usually when a malware detects one of these, usually when a malware detects
the pretense of a debugger, it tries not to reveal its malicious behavior. And as a result,
the reverse engineer actually couldn't find and reverse the malware and couldn't find
like what is the behavior of their malware. So here we talk about our approach. We are
introducing hyperivate. Hyperivate is like an extension to HyperDBG debugger and like
reverse engineers could use HyperDBG along with Hyperivate project. For the roadmap in 2022 first,
we released HyperDBG and by HyperDBG by its nature. I mean since it doesn't use any debugging
API from the operating system like Windows, by its nature it's more transparent and lots of
the classic anti debugging methods that detect the percent of the debugger won't work on HyperDBG.
And right now, we are making it even more transparent by presenting Hyperivate project. Hyperivate
tries to mitigate and bypass those user mode process modules, kernel mode drivers and find
hundreds. It tries to hide the percent of HyperDBG as the debugger and it also hardens the
hypervisor against some hypervisors specific tampering methods like if they want to take
host IDT or other things. For 2027, we tried to reduce the footprint of HyperDBG even more
by mitigating some like some footprints and artifacts that are related to Hypervisors and are
related to PCXpress devices as well as address the subset of architectural side channel attacks like
those who detect the percent of Hypervisor by some timing side channels by some model specific
registers, performance counters, or some custom instructions like XTV, SIDT or SGVT.
Yeah, so talking about Hypervisor based transparency. As seen already mentioned,
Hypervisors and debuggers leave all sorts of traces that could be used by malware to detect
that it's running inside a virtualized environment or that it's being debugged.
There are several categories that we are currently in the process of mitigating
or have already mitigated in HyperDBG. CPU fingerprinting and Hypervisor specific IO are two
very basic ones that we've already got covered. Currently, we're working on several aspects of X86
ishubbing AF here and yeah, like in terms of certain instructions that behave differently from
a guess as opposed to bear metal. Virtual device detection is an interesting one. We'll be
talking about that in a bit. And timing side channels, you know, performance counters, we've already
mentioned them briefly. You can tell how much time has passed between, you know, the CPU that
between the time that the CPU has spent on the VM or other VMs and the host.
Windows specific detection, yeah, that is really about querying Windows APIs for a
but kind of hardware that you're running on. Same goes for file system or process analysis.
Every Hypervisor has its own application tools like VMware Tools or the SPICE agents, virtual box
guest editions. And finally, there's three remaining ones sensor metrics, very basic information
like what's a temperature of a hard drive or an SSD or what's the fan speed? Well, these
will return obviously very different numbers inside of the VM as opposed to bear metal.
Same goes for UEFI, the BIOS, and finally memory probing where some hypervisors leave certain
telltale signs in the memory and we have medications to hide them.
So, virtual device detection, yeah, this is an example PCI Express device tree on bear metal.
As you can see, lots of Intel hardware, there's one kiox, yeah, SSD, and a real tech ethernet
now let's have a look what happens when we do the same on a VMware hypervisor.
It looks completely different as you can see, but suppose you would not see the name VMware there,
right? It would be something completely different. Then let's have a look at this Intel Ethernet
Nick. Well, at first sight, it looks like a real Ethernet Nick, but really it is an Intel E1000 compatible
virtual Nick. So, if you query the metadata for this device, it will look something like this.
This occult PCI configuration space, and what we can do in hyper DBG is replaced this
metadata by metadata that belongs to a physical actual Intel network interface guard.
Now, I can hear all you're really here, you're thinking, but wait, this how can this happen or how
can this work, right? It's two different devices. The driver will do something different, maybe,
that the device won't expect. Well, the trick is that this Ethernet Nick is also E1000
compatible, but it's a physical product, so we can easily swap between those two. And the same
approach, we can imply to many other PCI Express endpoints that you've seen in previous slides.
Another showcase that we would like to share with you is Cisco. For example, you have a user
space program, it does some Cisco's, and you want to know why it's doing that or what it is
is doing with it, what parameters it sends along. Hyper DBG has several features that allow you
to do this in a quite easy way. So on the left, we have the Cisco handler in NTDLL,
for those who are not familiar, NTDLL is mapped into the user space program, and it's basically
the entry point for the Cisco handler in the kernel. So the Cisco instruction is called,
then what happens is the kernel Cisco handler RSP address is copied into the RSP, that's I832,
L-Star, and then we move on to the right to the swap GS instruction, which is the kernel code
that actually handles the Cisco. So we put an EPT hook as we call it on the move instruction,
and this will set a track flag in our flags. Now what we can do here, because it triggers a
VM exit, we can actually modify the Cisco number that was called by the user space program.
Finally, if we continue on the left, so we've executed the Cisco parameter, we arrive at the return
instruction, then the track flag again triggers a VM exit, and then we can do we can basically
modify the return value from the Cisco, or we can modify the return buffers as we would like.
So a quick debugging crash course on Windows, there is a data structure called process environment
block, and this is accessible to all user space programs, and well this is very interesting
information, especially if you're a piece of malware. There is a parameter called being debugt,
obviously it tells, it's a telltale sign, if the process is being debugged or not,
there is also LDR, which basically enumerates all of the loaded modules, and obviously if you're
debugging, then you should not really trust whatever is in this enemeration, because the malware
will be able to hide any objectionable modules there. There is also some undocumented flags like
anti-global flag, which again can be used to detect whether you're debugged or not as a user space
process. There is also a track environment block, which includes sensitive information about
threat state, and I can go on and I'll go on, but basically if you want to monitor all those
fields like be notified of any changes, then under normal circumstances with a classic debugger
you would be limited to four breakpoints, because there are only four heart-ready bug registers
that can be used for this purpose, and that's where E.P.T. hooks come to the rescue.
So in principles, there are a lot of addresses, there are a lot of locations where you can detect
the presence of the debugger, and there are probably a lot of tools out there that are able to bypass
these flags, but the difference here for HyperDVG and HyperDVG is that HyperDVG could monitor
all of these locations, both in the user mode and in the kernel mode, and what it will give us
is that it will show us that at some points a malware or a piece of code tries to access these
locations. So the reverse engineer gets an idea, okay, this malware at this location, at this
program counter tries to modify or tries to query about some flags that reveal the presence
of a debugger, so probably it is the location where the malware wants to check for its
untidy bugging and anti-hypervisor methods. And now we have a demo, a brief demo of HyperDVG.
So for this demo, we made like a application that performs a direct system call,
like instead of going through the regular Windows path to a system called through entity
other, it directly calls a system call, directly calling the anti-open file, and as you can see
first we run and the first we check with or EXD5 direct system, let EXD, that whether this
file which is responsible for VMware tools is available in this system or not, and first of all
we connect to the HyperDVG through the serial port, virtual serial port, so basically we are debugging
the guest virtual machine from the host, debugging the operating system.
So we here use a virtual pipeline which is a virtual serial device, and now HyperDVG is synchronizing
the symbol details of this specific system like this specific guest, so as you can see I use the
Hide command in HyperDVG, and Hide command either gets a process ID or a process name.
Here we use a process name and I will give it a direct scull that EXD, so right now whatever
process executes on the system that it contains direct scull, it will try to change the execution path.
So you can see that anti-open file successfully executed for this one, but for the second one
anti-open file failed with an status which reveals that the file does not exist or I don't know
the system doesn't have access to that file.
So as the conclusion, also 100 transparency is impossible here in HyperDVG tried to raise the
bar and HyperDVG's capability to provide wider system visibility and more transparency for
debugging and reverse engineering malware. As malware techniques evolve, new techniques were
also added and will be required and will be managed to the HyperDVG project, and of course HyperDVG
is like an open source project, it is on their active development and community contributions
will come the PR. So any questions? Thank you.
Thank you very much. I have a question. I seem to recall that some of the windows
I take under the L but I'm not sure, relies on these debugging flags or breakpoints
flag or something like this to make breakpoints work. Is that the case? And if so, what happens when
it's under HyperDVG? Okay, let me answer that question. So yes, there's a data structure on windows
where if the processes are being debugged, these flags get set. So the process itself knows
it's being debugged but also other processes can tell that that specific process is being debugged.
What are the breakpoints or not work is independent of the flag? It's really just a flag.
Yeah. So basically the HyperDVG just don't use any breakpoint and any debugging stuff.
HyperDVG doesn't use the flags. Yeah, it doesn't matter fine.
I think since you're running at the hypervisor, can you see the memory being protected
by VBS, like this kit secure on-claves? Yes, well currently we require hyper feed to be
disabled, but our goal is to support running as a nest-to-type hypervisor on top of HyperDVG and
then we should be able to do that. Yeah. So I have a question. The first is, does it actually
on HyperDV, modify it version? And the second one is what about performance? Sorry,
could you repeat the question about HyperDV? So the first question is, does it hyperv,
you modify and the second question is what about performance? Oh yeah. HyperDVG supports VMware,
like VMware nested visualization and works also on bare metal, but for now it doesn't support
HyperDV's nested virtualization environment and we are also not using any APIs from HyperDV. So
it's the pure hypervisor we can buy in bare metal. And what was the second question about the
performance HyperDVG has a different architecture compared to, let's say, WindyVG, we publish the
security paper, academic paper, over HyperDVG you can't see that in terms of speed,
HyperDVG gains over 1000 times faster than WindyVG because of its structure, especially on the
Escript language. Any more questions?
Hey there, thanks cool talk. Have you already used it in practice to study some malware or some real
world to use case? Yes of course HyperDVG is so practical and a lot of malware reverse engineers are
using it and right now you can see probably I see maybe more than 10 or 12 reports from security
companies that they are also like their malware that they detect and reverse engineer they have
specific things that are related to HyperDVG to detect the HyperDVG. So this is actively used by
reverse engineers and also malware developers have some specific ways of detecting HyperDVG in
which we try to mitigate. We also have the questionable honor of being detected as malware
because it seems that the cheating community and video games also likes to use HyperDVG for their purposes.
Any more questions?
I don't see any, so think. He has still time. He's still have time.
Hi, thanks for talking. How does it compare to something like drag flow for other systems?
Because this is not really the original or the first one that does HyperDVG to be bugging, correct?
Well, HyperDVG is like a blue peel style hypervisor. I'm not sure if you're a familiar,
but it's running and an already running system. So I think there is no virtual machine. There is no
Zen. There is no KVM involved here. It's a pure Hypervisor and it's also a debugger. Most of the
features that are available here in HyperDVG are mostly for reverse engineering purposes and it
gives you capability to debug. Like it has its own programming language, we call it DSLank and it
provides like a lot of functionalities that are specifically meant to be used for reverse engineering.
So thank you again very much.