 So today we're going to talk about hardware back during. So just a bit of disclaimer, I'm not a terrorist. That being said, if you read the abstract, you already know that everything is open source. So like there is nothing much to release. The whole point of this talk is to demonstrate something you somehow probably know a little bit, which is that the X86 architecture is massively plagued by legacy. I still think the talk is relevant because we're trying to, I mean, you will see that the back door we're doing is holders of magnitude better than existing work. So we'll start by a bit of architecture, trying to introduce a problem, or we engineer this back door. We do a bit of an overview of the state of the art. I introduce you to the proper back door itself. And we'll discuss a bit of cryptography and why it's actually not helping. And to finish, I'll explain you like, oh, we can extend this work to back door like a proper nation state. All right, so this is a sexy slide, or maybe not so much. I basically started working with computers by disassembling viruses and really assembly when I was like 15. And nobody told me it was art, so like it didn't seem as such. I'm a big fan of like anything low level, to be honest. I think hardware backdooring is like pretty much the limit where you can go. So what's relevant? We do, I mean, I part of the organization of a conference in Paris, it's called Akito Agoso. All right, so for the sexy slide, that the Akito Agoso T-shirt, if you found out for cryptography, anything low level, feel free to submit. And if you don't understand what I'm saying, I'm French, I learned English in India, and I live in Australia. So that's three degrees in, as pure as it gets. So if at any point in time, like you really do not understand what I'm saying, please ask me to reformulate. All right, let's start with a bit of fun. So in case you've been in Bernadine for like the past few months, there was a report for the U.S. CNAID where they basically realized that every computer is built in China nowadays. I mean, even if it's designed in western countries, it's essentially manufactured based on components coming from China anyway. So this leads to a bit of, I mean, how can we guarantee that this hardware is not backdoor? So a bit more fun, like, if you've read the media recently, like, it's very much in the air to say that China is backdooring. I'd like to say, I mean, I'd like to go a bit more technical, like, is it actually credible? Is it possible to backdoor hardware at all? For instance, in France last week, the government realized that all the routers we have on our core network is basically UI or ZTE. They said, wow, that's scary. Let's change everything and buy Alcatel, Lucent instead. All right, so enough fun. Let's talk a bit about architecture. So let me introduce you to the problem. This is the problem. So this is, of course, the X86 architecture. It was designed in 1981 and it has evolved very little. So basically, you have, to the bottom, you have what we call the super IO to which the very slow peripheral are connected, like a floppy, the mouse, a keyboard. Then you have the south bridge, which is a bit faster. Typically, your Ethernet card, your CD ROM, your song driver would be there. Then you have the north bridge, where much faster peripherals are connected. So typically following the PCI extension. So it could be like, you know, gigabyte, Ethernet, Ymax, or video. So what's the big problem? There are actually two problems. The first problem is that at each layer, so say you take the south bridge, you have a CD ROM driver and you have an Ethernet card. So they are like very much physical peripherals. They both contain FIAMOIR, which allow to, I mean, control the behavior and, you know, allow software, I mean, from user land and no operating system to actually interact with them. The big problem is that your CD ROM driver can control your network card and vice versa, actually. And this is a bit unexpected. Another problem that we'll discuss later is that the TPM chip is actually very low in the full chain. And it's a passive chip, unlike on game consoles, for instance, where if you remove the crypto chip or if the software is actually not calling it, the whole thing won't boot. On AX86 architecture, the cryptographic chip, which can contain like cryptographic keys, it's much like an Ashes M release. So it actually also provides functions to do cryptography and not just the keys. If you don't want to use it, you don't have to. So like, let me not spoil it. I'll get back to this later. A bit of state-of-the-art. So, I mean, going as, getting execution as early as possible has been a goal since pretty much the first viruses. Brain was the first acknowledged IBM PC virus back in the 80s. So, I think it's a great idea. The work which is really relevant to us would be like the 2009 research from Core Security. They actually did, in fact, a BIOS firmware and they did it the hard way. Like, they took a Howard Phoenix BIOS. They identified where is the checks and functions. They introduced new code inside it, hostile code. And they compensated the checks. So in terms of reverse engineering, if you want to go this way, it's going to be pretty tough to infect a new motherboard. You need to reverse engineer again like the Wolfian wire. All the work relevant to us is mostly bootkitting, which is something entirely different. It has nothing to do with the BIOS. It's a fact of booting a computer from a CD-ROM or a floppy and patch the kernel on the fly. So basically, they all work the same way. You hook in the interrupt vector table, interruption 13, which is anything which is disk-created. So like if you want to write to disk or write from, sorry, write to disk or read from disk in memory, one sector at a time, you do it through interruption 13. The wall point of the boot loader, which is the master board record of the first bootable hard drive, is actually to unpack a kernel in memory. And when this is done, you never use the interrupt vector table again. Awesome. The must be a party or something. All right. So the idea is that if you hook this interruption 13, while the operating system is trying to load, sorry, while the boot loader is trying to unpack a kernel in memory, you can actually hook any read or write. And you can patch the kernel on the fly. And you don't have to touch the file system at all. Okay. So now let me get to the meet. So pretty much like you, I guess, I'm not being paid to actually write malware. That being said, let's imagine for a minute that we want to do malware. If I have to do one, I'd better make one which is actually awesome because I don't want to do that again. So I want it to be persistent, not just between boots, but like even if you remove, you know, physical parts of your machine or if you remove the hard drive entirely, like if you replace the entire operating system, I still want to get to have persistence. The stuff should be stealth. So we'll see that it's actually possible to make a malware where zero percent of hostile code is on the machine, not even on firmware and PCI firmware, et cetera. Ideally, it should be portable as an OS independent. Of course, we want remote access. We want to be able to patch remote updates. Even if we're going to backdoor, essentially PCI expansion ROMs and the bios firmware. Okay, when you come to state level quality, there are basically two features which make it like, but this is usable by a state. The first one is plausible deniability. It's a fact of saying, well, you know, I mean, it's suffering another alternative to explain why something went bad in case you discovered. Saying, for instance, oh, you know, it was a mistake or something like that. And these second alternatives allows you to, you know, in case people really insist like, oh, you try to do evil. You can say, no, you're a conspirationalist. The other one is non attribution, which is really saying it wasn't me. Usually nowadays it's like it wasn't me, it was China. If we get to make a backdoor, I wanted to cross network parameters, bypass firewalls, authentication proxies, et cetera, because like they are so abundant in corporations nowadays. I want some degree of redundancy. And it's needless to say I don't want it to be detected by any antivirus. All right, let me explain you how it works, roughly. Sorry, I'm a bit sick. All right, so this is a typical corporate network. So you have the users. You have some toys in the middle. It can be like IDS, IPS, you know, gateway with firewalls, sorry, with antiviruses, whatever. And you have firewall with proper DNS segmentation, which allows only HTTP after authentication. So basically if you want to reach an network, it's going to be a bit tough. It's supposed to work this way. The user is supposed to authenticate against a firewall before reaching the internet. So this is, oh, it's supposed to work. What we're really going to try to do is this. We're going to come with a Wi-Fi router. Have the buyers try to connect to this Wi-Fi router. And if we do that, like basically all the IPS, IDS, any parts you may find in the middle are basically going to be useless. That being said, if it doesn't work for whatever reason, we can still default to using Ethernet. Okay, so let's go to the design. So instead of starting my malware from scratch, like most virus authors do, I took advantage of open source software. And I think it's actually a massively good idea for several reasons. So the base component is core boot, which is the back end of a bias. Basically when you boot your computer, the first software which is actually executing in memory is responsible for discovering where is the RAM, where is the hard drive, where are the peripherals. So this is the role of core boot. C bias is the front end of the bias. In the core boot language, it's a payload, but I use another, I mean, I will define something else as a payload. So C bias is really responsible for creating an intervector table in memory. And if you have core boot plus C bias, you can actually boot an operating system. An amazing thing about core boot is that it's super modular, and you can actually embed any PCI firmware to control like peripherals directly inside the main firmware. So I'm using one which is called IPXE, which is an extension of the PXE standard, which instead of doing just DHCP and FTP, can actually boot an operating system remotely over, say, HTTP. And instead of using just DHCP over Ethernet, IPXE allows you to use Wi-Fi, WiMax. It knows a bunch of protocols like it has a full TCP stack, and even IO protocols like it has FTP, HTTP, even HTTPS. So that's pretty awesome, like you don't have to do all that yourself again. And then we use a bunch of payloads, which are basically boot kits. I get back to this. So I was mentioning non-attribution. One of the benefits of using open source is that it wasn't written might be. It's actually written by something else, but really. In terms of development, I mean, if you have journalists like Stuxnet, years to develop by a whole team of specialists, so I did this by myself in four weeks. And I think it's really, really, really, really hard to detect as malicious because all those components are actually not malicious, apart from the payload. But, well, there is a trick. So it works like this. We're going to flash the bias. Let's assume we are a manufacturer in China or whatever, or I'm just part of the supply chain delivering your laptop. Like when you buy your laptop, anybody who touches it before you can actually backdoor it. So we're going to flash not only the main bias, but also a few PCI expansion ROMs. Like I explained you, if we flash only the CD-ROM drive, we can actually control the network card. The idea is to, in case the bias is ever flashed by someone for normal maintenance, we can flash it back using a PCI expansion ROM. We're going to boot a payload over the network, typically over HTTPS. Like I explained before, we're going to try to use Wi-Fi or Wi-Max if it's available, which leaves no trace on the corporate network. So it pretty much looks like this. The core in blue is made of core boot, then C-bias, which is the front end, and IPXE, which is really a PCI expansion ROM, but also embedded in the main firmware, we're going to putt in the bias. And then the only piece which is really malicious is the boot kit. But the boot kit never touches the disk, and it's not embedded in your hardware, in your PCI expansion ROM, when your bias ROM either. Instead, so execution goes like this. So your CPU starts in 8086 compatibility mode, in real mode, which is essentially a legacy thing. I mean, for you, if you have done like programming under MS-DOS, you know, painful it is to work with this. You don't have multitasking. You have only access to the first megabyte of memory also. So core boot gives execution to C-bias, which is going to set the intro vector table, which itself is going to call IPXE to perform network booting. And the only malicious piece is going to be fetched every time you boot of a Wi-Fi or Ethernet, if nothing else is available, over HTTPS. So there again in terms of, you know, analyzing network traffic, deep packet analysis, this is just not going to work. We can use actually client-side certificates to ensure that there is no man in the middle during the HTTPS connection. Any questions so far? Okay. So in terms of the features, we're going to embed in RACCHASL. We're going to try to remove the NX bit. If you manage to do this, every mapping becomes executable again. We're going to try to make every mapping in ring zero writable. We're going to try to remove CPU updates. So I don't know if you're really familiar with this. Every CPU vendor has basically a way to correct mistakes because like hardware has bugs also. If you look at the Erata in the Intel CPU, it actually has a bunch of small mistakes which allow to modify the control flow of execution. So it's actually big mistakes. When this happens, instead of replacing every physical CPU, what they do is pushing a small microcode which is digitally signed by the manufacturer, typically Intel or AMD, inside the CPU and compensate for this problem. This is typically performed at BIOS level. We're going to remove anti-SMM protection. SMM which stands for system management mode. It's like ring minus zero or patch mode really. If you're familiar with the problem introduced by DuFlo regarding SMM at Consec West in 2006 and 2009, there is basically a generic exploit locally which will allow you to get to ring minus two. So even the operating system will not know what you're doing. And you're switching essentially to a 16-bit mode which has higher privileges than the kernel. So like you can patch back the kernel if you will. We're going to try to disable randomization and eventually we're going to load a boot kit. So the boot kit was actually contributed by Piotre Bagnat. If you're familiar with Conboot, it's a modified version of Conboot to like remove the fancy displays and stuff, but essentially it's Conboot. All right, let's do it. So if you want to remove the NX bit, first of the NX bit is a modern specific register. So if you read the AMD 64 manual, I mean AMD was the first one to actually introduce the NX bit in 97. So it's pretty smart to look at all they did it before it was actually copied by Intel. So there is a specific bit in a model specific register which is called the extended feature enable register. You hardly ever use that honestly. If you flip the bit 11, every mapping becomes executable again. So like to do this, you first must make sure that your CPU actually does support NX. And essentially what you do is like the three last lines. You read the content of this model specific register, you flip bit 11 and you write it back. The only difference is that we don't do MOV with model specific registers. We use RD on SR and WR MSR instructions to read and write to model specific registers. So this is only going to work if your CPU supports it. Okay, changing every mapping. This is a difficult part, right? After we have the demos and the fancy shit. So basically in CR0, control register 0, BIS16 defines if what is mapped in memory is writable or not. So it's actually something pretty common in viruses and in exploitation. If you've seen last year at DEF CON, Dan Rosenberg talking about remote kernel exploitation, he explained how to do it. So you read control register 0 into AAX, you flip the bit in question, you write it back. And that's it. You just every mapping just became writable in ring 0. So it doesn't work for user land, just for ring 0. Like if ever you have a vulnerability affecting the kernel, you're going to be bank vulnerable. It's going to be a lot easier to exploit. Removing CPU updates, that's pretty easy. You just remove the microcodes from core boots and like there is nothing else to do. Regarding SMM, so typically the protection against SMM is to set a bit, which is called delock, which prevents you to talk ever again, to switch ever again to system management mode when you trigger an SME. So since core boot actually does not support this feature, we have nothing to do and the shell code to do it is just a knob. Disable SLR, all right, that's tougher. It's very much OS dependent, because I mean hardware is not responsible for randomization, it's very much a software thing. The idea is that if you want full SLR, it has to be done in kernel land. If you don't have full randomization, it can actually be done in user land by patching the dynamic linker, like Stefan Esser did on iPhone, for instance. But if you want full SLR, like the base address of your main binary has to be randomized, and only the kernel can do this. So the idea is actually to patch the seed, which is going to be used to create this randomization. And if you patch this seed, so it's been identified, for instance, for Windows 7 by Kumar and Kumar at Akinza box in 2010, if you patch this seed with a known value, your mapping is going to be repeatable all the time. So what happened is that there is no randomization anymore. So if we manage to get all of this done, we have permanent lowering of the security of any operating system because we actually even lowering the security of the hardware. Like if we remove the CPU updates, what we're really lowering is the security of the hardware. And since NX was basically introduced in 97, you're back to the security of 97, which with the knowledge we have of exploitation today is Christmas time. Indeed, since we do this in the firmware embedded in your hardware, even if you change, say, your hard drive entirely, or you replace the operating system, we still have persistence. Just a little bit more of theory and then we go, I promise, to the demos. So currently, the boot kit I'm using is Comboot, a slightly modified version. So it's capable of booting any version of Windows 32 or 64 bit. That being said, if you want to be able to, I mean, when Windows 8, for instance, is going to be released, we want to be capable of owning this. So instead of embedding Comboot directly into Coreboot, into the biosfirmware, which we could do, it's a much better idea to do it remotely and to fetch it every time at boot time. Sorry about this. So we write nothing to the hard drive. So there is zero evidence on the file system. Like I told you, we try to have as little evidence on the network also as possible. The code which is flashed on the motherboard or on the PCI devices is not hostile. So there is zero reason for an antivirus to spot it as hostile. And if they do, it's actually a face positive. All right, I get back to the rest later. So I think it's actually a good approach to start using open source to make viruses. In terms of portability, Comboot is capable of, I mean, it's supporting, let me show you. So we said the state of the art, the work from Core Security is to support one bios, which is like several motherboards. Comboot is actually supporting that many. So I had nothing to do. All right, so this is pretty epic. The amount of reverse engineering there to do is actually massive. Like for most of them, they don't even have the data sheets. What they do is they use a physical device which just give you the last error code. So imagine trying to port a bios with that much information. It's sick. Anyway, and the good thing is that I don't have to maintain my back door. They do it for me. In terms of modularity, like we said, we can embed everything inside the bios itself or put several components on the PCI firmware, on the bios itself, and this gives us a degree of repeatability, if you will. And in terms of network stack, I don't know if you've ever done any kind of programming in real mode, but even trying to do a TCP connection is virtually impossible because you don't have multitasking. So what they do is actually cheating. They switch to protected mode to be able to have multitasking, et cetera, and then they go back to real mode before transferring execution to the master board record. From the master board record perspective, it's invisible. All right, let me tell you a bit of the configuration files of IPXE. I think I'm going super fast. All right. So we can try to get DHCP and if it fails, we can default to a static IP. We can do awesome stuff with web application, like we can authenticate against a web application. We can send parameters. It has actually a few mac roles like, or to send your IP address and your Mac to a web page on the internet. So from there, we can send emails. We can do router farming. The image humiliation is limit really. We can even change the boot loader, change the configuration file of IPXE from another server on the internet, which avoids us to hard code anything. Then when you happy with all that stuff, you say actually, oh, I changed my mind and let me actually boot the proper boot kit, which is really made of two parts, mem disk, which is going to be the kernel. So you can fetch it, for instance, over FTP from a Chinese website, if you will, or just over HTTP. And same thing for the main boot kit. I hid them into PDF files, but it's really very much like the kernel renamed as memdisk.pdf, so that if for some reason there is some kind of network analysis, it's going to be harder to check. All right. Let's go to the, thank you for your patience. Let's go to the demo. This one is called evil remote kernel on edge of death. Okay. I could actually flash it on my main box, but like you would see nothing, which is not very visual for a demo. So instead, I'm going to use KVM, which is an emulator, which is also supported by Corbut. I'm just going to start a small network sniffer for you to see what's happening. We're going to focus only on HTTP. Okay. So the whole comment is this. So we start KVM. We specify a different bias from the one of KVM, which is actually my malware, RaxaStar. We tell him to be full screen. We want a network connection. I actually have Ethernet here today. And you boot me a drive which is very much a Windows 7. It better work. It's not working. It is. All right. Okay. I will need someone innocent to type my admin password. Do you know my admin password? Oh, don't be shy. Can you come over? Yeah, yeah, you may. Yeah. So the idea that you know how to use Windows, you choose any password you want. All right. And it's actually booted, right? So no, thank you, mate. So like, let's look at what's really happened here. So first off, the application, I mean, the bias downloaded a second configuration file from a remote website, okay, using HTTP. This is very much an IPXC configuration file, which tells him, all right, you're going to try to send me an email using a web application from the bias. And we're going to fail over just a, sorry, is it too small? Is it better? I don't know how to make it bigger on that stuff. All right. So the idea is that it's downloading an alternate configuration file and then it's going to, it's going to boot on a, no, sorry, this is already the alternate configuration file. It's going to boot on a blog, essentially. Which is the blog I used last year for my blackout talk, because I'm too lazy. All right. We can see that actually, these two files have very much been fetched. So this is a memdisk thing. And the other one is the actual payload, which is a recrafted code version. All right. So let me check my mails, because you guys are a bit boring, you could have applause there. So I'm a bit pissed. Okay. So if I go to my mails, I have a message from Rakshasa. You can read this. Sending me the IP parameter, like the IP, the Mac, the network mask, the gateway, and the DNS. So this was actually a Windows 7 64 bit. Oh, do you get to see this? Yep. But this is very much comboot, like it's going to work with any, any Windows 3D. Any questions so far? Okay. So let's go to more interesting stuff. Obviously for the Apache logs, we have the traces also of, you know, what the IP address, the next mask, et cetera. So like we mentioned, we have a, we actually receive emails seemingly from the bias. This is before booting the operating system. I'd like to tell you about how to properly build a botnet. A botnet you cannot shut down. You must know that Microsoft is using signed updates. Why not do this for my botnet? If I want to make a botnet from a bias, I can very much sign the updates also. So that if low enforcement ever sees the CNC, the commanding control, they will not be able to shut it down. Right? Because like, this is how they do it, right? They hijack one server, one CNC, and they send a shutdown command. If you do that, there is still a problem, like the availability of a CNC. And to do this, what we can do is rotate the CNC every say, every five minutes over the entire internet. It's unlikely that you're going to shut down the entire internet to shut down my botnet. So one day it's going to be Amazon, one day it's going to be Google, one day it's going to be NTNT. Next day it's me. So I push my updates. And I think if Malware was actually doing this, which is not really happening today, it would just be impossible to shut down. Any question? Okay. Let's talk about mitigation and in particular cryptography, because it's usually the one which comes to mind. So first off, we can very much do an evil-made kind of attack, booting a fake prompt, and TPM is not going to help you there. Because TPM is not enforced by the hardware. Even if you seal your computer, you have full disk encryption and you're using TPM. If I flash your hardware with RACCHASA, and next time I boot, I bring a fake logging prompt, you cannot see the difference. And TPM is not capable of enforcing the real full disk encryption login to boot. So this is a bit of a problem. We can do all this stuff like boot train to brute force, et cetera. I shield that like, definitely in 2018 if you're interested. So this is very much of a problem. The other problem is that even if full disk encryption is actually used, when you buy your computer, the hard drive is not encrypted. It's not possible. Well, if it was like it would be encrypted with a password, you don't know. So you would have to, or which is known by third parties. So to change the password, you would have to unseal the TPM. And bam, if you do that, you will label again. So anybody in the supply chain can very much backdoor your stuff because your hard drive is not encrypted and therefore the CPM is actually not sealed when your computer is delivered to you. You may be asking about antiviruses. If you ask me, putting an antivirus on a server is pretty much as putting lipstick on your server. Let me show you why. We said the only component which is actually malicious is kombut. So I took the legit kombut version, which is like at least three years, maybe five years old and is detected by two antiviruses on virus total. Not bad. Then I encrypted it with a super-elite packer called LZMA, which is actually the most common packer, most probably, is the one used by Linux, by default, nowadays. And it's the one used by every bias I know. And the detection rate drops to zero. All right, I want to talk about this. You could be vulnerable if you actually change your network card. If you network card, you buy it on eBay and it comes with our road PCI driver at boot time. Every PCI driver has the same privilege as the bias. So when your device is initialized, it could actually very well do the same thing, even if your bias is sane and reflash the bias back from the internet. We're going to see that later. It's actually also possible to backdoor ESXi or at least several versions of VMware using road PCI devices. So in terms of remediation, I suggest instead of trusting a few more you don't know, when you receive a computer, you flash it with firmware you can control. Typically core boot is a good idea. If you victim of a nutrition, because it's also possible to flash the bias, if you get a remote route shell, you should not trust your bias anymore. But if you want to flash every, if you want something sound, since you cannot trust your kernel anymore, you should flash every PCI firmware and the bias at the same time using a physical device like this. And nobody has the time to do it. So I suggest you just throw your server away. I told you about flashing remotely. We just saw that we can boot a remote operating system. So since the flasher for most biases is just a Linux and it's generic, flashing the bias itself remotely is a given. What's not a given is flashing other PCI expansion ROMs somewhere on your machine because they are very much hardware dependent. So say I want to flash the network PCI firmware. How do I do this? Well we saw that IPXC can actually send the MAC address to the server. So the server can know the MAC address. From there it can deduct the win number and from the win number it knows the manufacturer. And it can send back the appropriate tool and the exact version of the flasher which is appropriate for your network card. This is actually not a trick. It's something supported by IPXC which is even better. All right so back during like a state, everybody know that only China does it. So we mentioned non attribution and possible deniability. Non attribution is a given because I mean it's essentially free software. So you did not write it. You don't have to explain why you did not. You did not. For plausible deniability I suggest instead of flashing, instead of owning this, of putting a back door straight away to use a remote vulnerability on the firmware and such stuff does exist. The same guy who found the SMM thing actually found a remote vulnerability on the firmware of Broadcom network cards. It's just not enabled by default because there is a slight setting to do. But like if you change this setting, this is slightly better. I mean you can claim it's a mistake and an honest mistake. It's not a back door by itself right? But it allows you to own the computer remotely, get a remote route shell. And from there you can bootstrap the thing like flash the buyers, all the PCI devices, etc. Do you even feel it's filtered data, etc. And when you don't, the rest of the buyers, every PCI firmware and you don't. Zero trace left. So more demos. If you read this book, Millennium, it started to be bullshit around page 50 when she boots a remote operating system from the guy she's infected. Turns out this is actually possible if you have a link which is fast enough, typically Gigabit Ethernet. So this is again supported by IPXE. Let me boot a demo quickly. Okay, so I don't have a sand so we'll just do it booting a CD-ROM. But it's essentially the same thing. Sorry, let me CD-ROM. Oh, I think this is totally legit. All right, Windows is booting. I'm going to do the rest where it's booting. There is also a small problem of buyer's graphics. Like when I booted it, you didn't see any graphics, but like it's a big problem because like all the versions are better than C-Buyers actually have better menus and you can embed a proper graphic, a boot splash when booting. So for instance, you can have stuff like this. You can have a wall invaders. I'll show you in the question room if you want. When it comes to UEFI, which is often mentioned as something better than the buyers, Corboot is actually 100% compliant. If you change C-Buyers by TianoCore, which is another open source project, the only difference is going to be that the bootkit you're using, Corboot, is not going to work. But if you saw the work of Snare this week at Black Hat, he actually wrote such a bootkit. So like, I don't see why people actually try this technology either. Best thing, this is not a vulnerability, so there will be no patch for it. It's just bad design. I mean, we cannot really blame IBM for making the mistake in 81, but we keep on having like visual compatibility and stuff. Just to remind you, Microsoft in 95 did not anticipate the internet. When you bought Windows 95, the shares were open because it was supposed to be used in LANs and stuff like that. So like imaging, the kind of anticipation IBM could have won in 81 when creating every PC. And since I got the question, yes, a Mac is a PC nowadays. Any question? We're going to see just, yeah, I think that's very legit, but we're going to move to the other room for the questions. Thank you so much for your attention.