 Hello everybody. I'm so sorry that there's something wrong. The next talk is without a slide because something horrible happened. My machine, my laptop, which has all the slide inside, all the information, all the demo inside is broken right before I come here. So the file system is broken and it cannot boot pass the file system check. But anyway, my talk is only 20-50 minutes, so I do my best to present my talk without a slide. So I'm very sorry and hope you understand. So my talk is about Operating System Operating System Finger-Meeting for Virtual Machine. My name is Nguyen Nguyen. I'm from Japan. I'm looking for research lab in Japan and one of my research area is studying how to protect virtual machine system. And in my talk, I present how to fingerprint the operating system running inside virtual machine. So first, what is OS Finger-Meeting? I think everybody here knows that. OS Finger-Meeting means that we try to identify which operating system running on the target target machine. And traditionally people fingerprinting system remotely via network. First of all, I have one machine over there. I have one laptop over there, laptop here, and I want to know which OS running inside that machine. And traditionally the way that we send some craft packets to the remote machine and we analyze the result sending back from that machine and we can from the network packets sending back, we can understand which OS running on the remote machine. So OS Finger-Meeting for remote system like that is well known and all problems. So in this talk, I don't present that problem, but we propose new problems. So the problem is like this. You have one virtual machine system. You have one physical system. You manage the system. And on that system, you run multiple virtual machine, okay? Virtual machine can run any OS. It can be Windows. It can be Linux. It can be BSD. It can be so this can be anything. And each OS can be any version, right? So the question is that my assumption is that I manage the system. I manage the host. And there are many virtual machine running on that. And now, how to fingerprint those virtual machines? How to know which OS running each virtual machine? So the question is that why we need that? There are two reasons why I need which OS running inside each virtual machine. So the first reason is well known. I want to protect virtual machine without knowing which OS running inside. Why? Because first of all, I am running ISP. I manage many virtual machines. And each virtual machine is used by one customer. So each customer has one virtual machine. And I don't know which OS running inside, right? They can do anything inside the virtual machine. They can do anything inside the virtual machine. So, but I don't know which OS running inside, but I still want to protect them. For example, if I know this virtual machine run Windows XP and configure worms coming, I need to put the firewall around that virtual machine, right? But if that virtual machine run Linux, I don't need to care. And sometimes I need to know detail about which OS, for example, this virtual machine run Windows. But which version? Windows XP suffer with a configure worm. But Windows 7 is not. So I want to know which OS and which version is true, right? So the question is, how to know which OS running inside each virtual machine, given that you manage the host? Any idea? How to know? You manage the host, the host, and I want to know which OS running inside. So the easy question is that you use the old way. You fingerprint each virtual machine using traditional tool like Nmap. You send crap packet to that virtual machine and analyze the result sending back. That's the old way, right? You can always use that. It's for not for virtual machine, but of course you can do that. But there are many problems with that way. Why? First one, the modern operating system. They have many mechanisms, which is turned on by the phone. So you cannot remotely fingerprint it cannot always do that. For example, Windows 7, they close all the ports they don't use. So in the case, that virtual machine has no port open and Nmap doesn't work. Or even Nmap works, the result is not correct. And modern operating system has some mechanism. First of all, Windows 7, they drop on the ICMP packet by the phone. So the tool like X-Probe, which is a remote fingerprinting tool, rely on ICMP, it doesn't work anymore. So network-based fingerprinting is not very good. And finally, if you use Nmap to fingerprint the virtual machine, even on the same system, from host to the guest, Nmap take maybe 30 seconds or so. And I'm not very happy with that. It's on the same system, but it takes 30 seconds. So I don't like that. All in traditional instruction. So there are two other ways. People propose two other ways, which is specific for virtual machine. The first one is you manage the host, right? And on the host you run virtual machine. So you can look inside the guest file system. It's doable. So the first way is that you look in the file system of the virtual machine and you analyze it to understand the file system content. And you can check out some special files there to identify the OS. So that's doable too. But there are some problems too. First one is that you need to understand the host needs to understand the file system of the guest. That's a big problem. First of all, if you run Hyper-V virtual machine and the guest virtual machine run Linux, there are 100 types of file system on Linux and there's no way for Hyper-V to understand all of them. So far, Hyper-V Windows only understand EXT second file system, but have others, XFS, ZFS, and so on. There's no way to understand. Windows cannot understand that. So looking into the file system content is not good for some Hyper-Viser. And the other reason is that if the file system is encrypted, there's no way to extract information now, right? So looking into the file system of the guest virtual machine is not good. The other way people propose is that you can knock into the memory of the guest virtual machine. It's doable because from the host you can access to the memory of the virtual machine and you can analyze the content of the memory to understand which OS run. But this way, there are some problems too. Why? Because if you want to analyze the memory of the virtual machine, you need to understand very well about the OS internals of the virtual machine. You need to understand very well how the OS organize the object inside the memory. And from open source OS, it's doable. It's not easy, but it's doable. But for the closed source OS, live Windows, it's not easy at all. So looking into the memory is not good either. So what to do now? Any way else, we need to look to find the OS running inside the guest. So my solution is that I propose a tool named UFO. UFO can fingerprint the virtual machine very well. It's much faster than NMAP. NMAP takes maybe 30 seconds or more. My tool takes only a millisecond. And it works with all the operating system. Regardless of how you tweak, you change the OS setting inside. And it works with all the virtual machine. So here's how I design my tool. So people already look at the network check fake, right? NMAP. People look at five systems. It doesn't work. People look at memory. It doesn't work. My tool looks into the CPU context. Why? From the host, you can get the CPU context of all the virtual machine you want. You can, from the host, there's some usually virtual machine provides some interface for you to query the CPU context of each virtual machine. What is the CPU context? The CPU context in my context, which means the segment resistor, task resistor, task resistor, segment resistor, and some special value like the ZDT table, global descriptor table, IDT table, interrupt descriptor table. And some features like if this OS of this virtual machine turn on fast system code or not, does it use nx, none executable or not? And why CPU context is meaningful? The reason is that Intel, Intel platform, when they design the platform, they never have strict requirements on how the OS setting those parameters. You can run the segment anywhere. You can set the ZDT table at any size. You can set the IDT table at any size. For example, on Linux, sorry I don't remember correctly but because I lost my slide, on Linux, the code segment ran as a selector 1, 9, 1, 5, 8, 1, 5, 8. But in Windows, the code segment in 0, run as sector 8. So all those things are different between OS. Each OS has a different way to set those parameters. So my technique is that I query those parameters at runtime and I match them with the database of signature. And I can fingerprint exactly the OS variant and the OS version. It's very accurate and very fast in millisecond. And the signature doesn't depend on hypervisor. It can be used for hyperv for Zen because on the hypervisor it should provide some interface for you to query the CPU context. So the final question is how to get the CPU context? For example, you know that one operating system uses code segment CS. In ring 0, it can be first of all on Windows. It can be 8, number 8 selector as a selector 8. But there's no guarantee that that's the only value. Some operating system can sometimes, at some context, use some special value. So how to get on the value? That's possible. That's possibly used by the OS. How to know that? So the easy way is that you write a tune and you periodically query the context of the OS. You can get the CPU context, right? And periodically you query the CPU context and you get the update value in the signature database. And that's not good. Why? Because even if your tune runs very tightly for example, it query every second for the CPU context, you can get many values for a specific OS context. But there's still some chance that you miss something. You miss something between the interval you query the CPU context. So writing the tune like that is easy, but it's not good. So in my solution, I profile the OS inside the virtual machine. I use QMU. QMU is open source virtual machine, open source emulator. And I can modify the source code. So I can profile the OS and I modify the QMU, run any OS inside QMU and my modification. I modify the QMU so it collects all those parameters whenever those parameters change. So I don't miss anything. So you can see that my way is very flexible. I don't need to know how the OS organizes the Internet object. Just run it on my QMU which is modified and it gets all the CPU context for me anytime the CPU changes and it automatically generates the database for me. So after that for each OS, I put, I have on signature and I put all the signature in a whole signature database and at one time I query the CPU context and match them against the signature database. And I can know which OS running inside that virtual machine. So that's how my tool work and that's the content of my talk. And my tool need be released under open source GPN license sometime this month, probably middle of this month. And it works for Zen very well, for Zen virtual machine very well. You can use it to fingerprint your OS and it has many advantages. It's very fast, millisecond. It works with all kind of hypervisor. And it's even better. There's no way in, normally there's no way for you to set the OS to change those parameters. So there's no way to fool my tool. It's very hard. Normally this OS has no option for you to change those parameters. Yeah. So that's my talk. Any question? So I'm very sorry about the broken machine, but I hope you understand the talk without the slide. And in case you want to talk with me, you can speak outside of the room. Thank you.