 speakers for the next talk are going to be Igor Sochinsky and Nikola Korner. Both of them do reverse engineering for fun and for living. Nikola wrote a couple of Python scripts to disable the internal management engine and is studying electrical engineering at the University of Milano. And today they are going to speak about internal management and layout, research and facts for a lot of myths that were traveling around the world and around the internet for the past year I would say. Please welcome them with a big applause. Okay, thank you everyone for coming. That's quite a lot of people. This is the first time I speak with so many front of him, but we'll see. Anyway, just a little bit about me. Yeah, I'm a software developer at a little company called Hextrace, but in my free time I do some reverse engineering, and so happens that the company develops the software for reverse engineering, so that's a bit of a good fit, I think. I'm not a security researcher, so my day job is just software development. So this is just my hobby, so to speak. But as my hobby, I did a bit of hacking of leaders. This is Amazon Kindle, the first version, the ugly one. Yeah, I did a bit of blogging back then. Yeah, this was, I found serial port and then did some extractive file system. Anyway, it's not related to this one, just a bit of background. And then I get interested in them to me, and the result is this talk. Hope you'll find it interesting. I'm Nicola Kornow. I do hobby reverse engineer, and I'm interested in doing it yourself hardware. I'm currently an electronics engineer student in the Politecnico di Milano, and I'm not a security researcher. I like to build my own stuff from scratch, and I really like PCB milling like this one. Okay, yeah, just a little disclaimer that all that we describe here is information either from public sources or from our own first engineering. Of course, as always, you can't be sure that everything that we say is 100% correct. It's just our opinion, and it may turn out wrong in the future. And we don't have any ideas with Intel or any special relationship, so everything we say is not endorsed by Intel or anything like that. Okay, let's go on. So just a little bit about what is Intel ME? Yeah, ME is, nowadays it means management engine, but originally it was called Manageability Engine. It was quite a big thing in early 2000. Then, a bit later, now Intel tends to call it Converged Security Engine, or just Converged Security Engine. So depending on which generation or which document you're reading, it may be called different things. But it's basically all the same thing. And in mobile or embedded platforms, there is a variation called Trusted Execution Engine or TXE. It's a little cut down and smaller firmware, but it's also a similar thing. And in server platforms, Intel server platforms, there is also a version of ME running a different firmware called Server Platform Services. So basically most Intel platforms nowadays, they have some variation of it. And what is it? Well, Intel says this on their frequently asked question page. Built into many Intel chipset-based platforms is a small, low-power computer subsystem, which performs various tasks. Yeah, I cut some things because it didn't fit. Tasks while computer is running or during sleep and so on. It must function correctly to get the most performance and capability from APC. So it's a bit vague, but that's what they say. And yeah, what other people say? Yeah, for example, some people say that it's a bug door made for NSA. And it has no useful purpose. And of course, I guess you can blame me as well because my first presentation on this topic was called Routkitten Europe Top. Yeah, just a bit of explanation about it. When I submitted the abstract at the beginning, I was looking just at the antisept feature that Intel was using back then. And that one did indeed work like a Routkitten. But in the process, yeah, I have this a bit of habit that I get easily distracted. And once I started looking at this antisept, I found that it's implemented in the Intel ME. And then from there, it's kind of all kinds of things open. I started looking into what else is in that ME and so on. So anyway, my point is that it's not necessarily Routkitten. It was just kind of maybe a bit of clickbait title to get my submission accepted, which I succeeded. Yeah. So anyway. And there is, for example, article from Haka Day. It's a bit difficult to read, I guess. So I will read some of it. It says among other things, it's a microcontroller which has direct access to everything in a computer. Every computer with an Intel chip made in the last few years has one. And if you are looking for a perfect vector for Routkitten, you won't find anything better than the ME. It's the scariest thing in your computer. And this fear is compounded by ignorance. No one knows what ME can actually do. And without being able to audit the code on the ME, no one knows exactly what will happen when it's broken open. Yeah. So anyway, this is just one article, but there were many similar articles in the recent years and so on. So for example, on Reddit, there was this discussion. And one post says, the compressor theorist in ME also makes me believe that Intel is not entirely responsible for the ME. I imagine that NSA and other triple letter agencies have had their share of responsibility for it, too. Well, of course, it's Reddit. Who knows who is posting it. Yeah. Another example on phoronics forums. The US government can still make demands of what it should or shouldn't contain. The US government has a long-term plan to control the entire internet. The ME is, of course, part of that plan. Or in IRC, just a random channel. And some guy says, yeah, there was a discussion about limiting risks with ME. And the guy replies, how can I limit my risk when there is a dedicated computer on top of a computer that has full access and can be disabled? There is no need for hardware. It's a built-in hardware break door. It bypasses any firewall, latches to any Wi-Fi signal cannot be disabled, and so on. So, yes, that's all sounds pretty scary. But is it all or is this true? So, in my opinion, after looking at this whole thing, I think that most of these kind of scary things are quite far-fetched. And just to answer part of the first question, that is it has no useful purpose? And I say, no, it does have purpose. Just because it personally has no purpose, that you don't see a purpose, doesn't mean that there is no purpose. So, initially, ME was created to implement something called AMT to solve real IT problems. And let's see what are those problems. So, just a bit of history on the remote management. So, in the late 90s, it began when people had many computers, but they didn't want to have monitor air keyboard for each one of them. They had something called keyboard video switch, or later keyboard video mouse. Then later appeared a standard called wired for management, which included among other things wake online and reboot execution environment, which are still in use over nowadays. Then IBM introduced alert online that allowed the network card to send various alerts in case something happens with the computer. But it was just one way. Then in 2001 Intel introduced alert standard format one, which allowed to send some more things. But it was UDP only and it had no encryption. Two years later they added encryption and improved some things, but it still was not completely enough for many purposes. And just in the background, they did some research with many enterprises. And they announced something called AMT in 2004 on Intel developer forum. And in one presentation, they showed this picture that we have new technology, which allows all this. And ASF allows only this. And of course, anyone in enterprise who sees this picture, he sees all this green and says, they think that's really good thing, I need to have it. And it was very popular. So one year later they released it. First version had processor hidden inside the network card. Well, not card, but network chip, which was on the motherboard. It had features which were not supported by previous one, by alert standard format ASF. For example, it had ID direction. So you could mount an image over the network and boot the remote computer over it. It had serial over LAN. So you could have serial console. Yeah, for some reason they used SOAP API, so XML over HTTP. But the XML was the thing back then. Yeah. Then they started working it, improving it. It was very popular. And they decided, why do we need to put it in the network card? Let's put it inside the North Bridge. We have some space. It's just a synthesizable core. It's not a big deal. And more platforms can have it. Then they did some more improvements. For example, in 2007, they started releasing the first variants of this firmware without AMT. To support mobile users, for example, QST is quite system-technologizing. Basically, fun management. So when the processor gets hot, it tells the embedded controller to turn on the fans so it gets a little colder. So basically it's something that works without involvement of the main CPU. And I guess they just had some spare space and they decided we can have this feature and it will really improve the work of our hardware. So why not do it? They also added TPM because people started, well, not people, but standard. Yeah, there was initiative by Microsoft, trusted computing, and TPM standard appeared and they decided why people need to have an extra chip and spend more money when we can just add it inside and it will be cheaper for people and so on. And then they added the first version of antisept. I didn't look at it, but that's the first time it appeared. Then in 2009, they moved to so-called, we call it generation 2. They switched to a different CPU to a more efficient instruction set. And they added also KVM support. So previously what had to be done in hardware using external switches, now it could be done over the network. So you could have full control of the computer, like see the video, use the mouse and keyboard and so on. They used the version of VNT protocol. Anyway, just some milestones. They're not really interesting, I guess. I'll skip them. So the summary is that originally it was created for this AMT, Advanced Management Technology, I think. Or what they called it, V process umbrella term, which is not really concretely defined. But eventually they also added other features, which were not related to AMT, but just because they could be useful and they had the opportunity. So they added many things, for example, one I didn't mention is ICC integrated clock control. So previously you had to have a separate chip on the motherboard, which was responsible for controlling the clocks. Now it could be integrated all in the chipset. And as again, the customers saved on the bill of materials. And it was also a bit more secure because once the clocks were set, they were locked and they could not be controlled by other software inside the OS, so you couldn't overheat your computer accidentally. Of course, antisept was added also part of it. Then the dynamic application loader for the applets, they implemented the one-time password, for example. And one feature I think was that they really liked was the silicon workaround capability for patching bugs in hardware that previously they had to replace the entire chips and nowadays they could just release a new firmware and the bugs would be fixed. So that's I guess their kind of motivation for all of these things. So I think it's kind of reasonable that they added this to ME because they had the opportunity and it saves them the money and their customers. And when people do say that it was NSA and they controlled the NSA, then as you know recently that it was discovered that on request of government agencies Intel added the bit that would allow to disable ME early so that it doesn't run for the rest of the operating period of your computer. And then if they had control over the Intel why would they request this bit? It doesn't really make sense in my opinion. And here's the post from one guy on Hacker News and he claims to be an internal engineer. Unfortunately a bit hard to read. And he says I worked in Intel on ME for three years and I can tell you two things. ME was not born out of desire to spy on people nor was it to the best of my knowledge created at the request of US government or others. It was an honest attempt at providing functionality that we believed was useful for this admins. It was initially to be going much worse. Early pilots with actual customers such as large British bank were going to run a lot more stuff, think a full JVM and have a lot more direct access to the user land. Security concerns scrapped this idea pretty early on. In retrospect I personally believe the whole thing was about the idea and everybody is free to crop on Intel for it. But the thing was never net as a backdoor or anything like that. So I kind of totally agree with this guy. So I think it's kind of something that kind of spun out of control and it was not really meant to be as bad as it turned out. So I bit more about other myths. So people say that it's always on when the UPC is off. Well, it's kind of true but it has some circumstances. So just a little bit about ME power states. So when the UPC is on, ME is also working and everything is fully powered. But when UPC is sleeping, ME can be in different states. For example, one of the states is called M1. So main CPU is suspended. But ME functions. It has a bit of RAM which is working. It has access to the RAM and ME systems are working. And once some time out expires, it goes to the off state. And in that case, it's completely powered off. So it works for a bit and then it goes off. But it can have so-called wake mode. So when the packet comes over on the LAN and ME is active, it works up and can handle the request. So it's kind of off but not completely off. But anyway, it's when you power down your computer, usually it's off. In some cases, you can configure it in the BIOS if you have ME. Here's the picture. You can configure that it should be only on when the computer is on or when the computer is in the sleep. It can also be powered if it's on IC power and so on. So this setting depends on your system. Sometimes it's configurable, sometimes it's not. So another one. It can lock the PC with a common servant over there. Yes, it was kind of true. It's for some time, but it's not anymore. So first you need the ME which has this TTT, which means self-deterrence model, so anti-seft. And it was only present in the ME since 4.9 to 9.0. In 10, it was removed. And for this to be possible, the anti-seft needs to be enabled and your computer needs to be enrolled in the anti-seft program because it has to be periodically pinging the server so that the PC is not stolen. And yes, for a short time it had support for 3G. And these 3G chips had to be connected directly to the chipset. For example, if you had a USB key with 3G, it wouldn't work. Only USB built-in module. And this command to turn off, to kind of break the PC had to be signed by the Intel. So it had to go through Intel servers to be really active. And eventually in 2015, Intel removed it and it's completely gone. So it's not present in the modern PCs. And all the other anti-seft solutions which are offered, they don't use ME. They all use a BIOS or UFI module which works on the operating system level. So it's a software agent. So another one. It can read all that on my PC. It's a bit complicated. So it can read the host memory. So, for example, it cannot read your hard drive directly. It can maybe patch some driver or whatever that it would cause the data to be read from hard drive and then fetch the data from the RAM. But it cannot access the hard drive directly, as I know of course. And according to the documentation in the book about ME, the sensitive areas are blocked from those reads. For example, the SMM is blocked and cannot be read by this DMA engine. It has a bit of access to the internal GPU. But as far as I know, it has no actual read access to the pixels. So it can kind of redirect data from the Intel drivers to the GPU and do the key exchange, but it cannot directly decrypt the data. However, there is a bit of footnotes, so to speak. It can emulate the IDE or USB device on the host. So it could boot a different image. Well, the admin could boot a different image using AMT. And then, of course, it could access the file system or whatever. But this is not directly ME itself. It's something that uses ME. And one more note that this is all about generation 2 of ME. So in ME 11, Maxim was talking yesterday and he claims that it has access to more devices on the host. So maybe the situation has changed. So I don't know. So it can read some stuff, but not everything. And then people say it's a block box. We can't audit it. Just give up. And I say not really. For example, there is a tweet from Daniel Bilar on Twitter. And he quotes his friend who says it was the follow-up to the Krakatak, which was basically a bug in the implementation of the specification. And he says whenever you have a specification, how do you break it? So read the specification, RFC. Every time it says must, check that they really did. Every time it says must not, check that they did not. Every time it says should, assume that they did not do it and test for it. Every time it mentions a requirement that does not affect functionality, assuming it was done wrongly by at least one company and nobody noticed because it still works. So anyway, I think this thing also applies like, well, for Intel you don't really have specifications, but you have some documentation which describes various flows, for example, for activation, for enrollment and so on. So you can also do the same thing. Just follow those specs and see if they really followed correctly. And maybe you can find some bugs. And in addition, there is black box auditing. So plenty of products can be audited without source code and audited without the source. And just as a kind of point to my previous slide, there is a master thesis by Vasilios Ververis in 2010 called security evaluation of Intel's active management technology. So all of his work, it did not involve any reverse engineering. He just read the documentation provided by Intel and he tried to activate Intel ME or, well, not ME, IMT and see if it's really activated the way they describe and he tried to find some kind of holes in that specification and he did find some things which were fixed later by Intel, but at that time they were really kind of bugs. For example, Intel says that IMT should not be pinging the activation server before. It goes into step mode. But Vasilios, he found that in some cases it does pings the activation server. So apparently it was not completely implemented correctly by Intel. And in the later versions, Intel changed the way the activation works and now it's more correct. So you don't have to have the source code to sometimes even reverse engineering to just audit. And even if you don't have source code, you have the binary code. So the firmware is available on Flash. It's not encrypted for now. So you can just figure out how to extract it, just assemble the code and see what it does. And in my opinion, it's a superior approach. So when you have the binary code, you see what is actually being executed. So you don't see the comments. You're not confused by comments, by the variable names or whatever. Or code formatting. Like remember the go to fail that Apple had in their encryption code. Not encryption, I don't remember. Something with keys. Anyway, there was a go to which was indented a bit wrongly. And it was not obvious when you just glance at the code. So when you have it in binary, it's kind of hard to miss such things. And you don't have the comments, but sometimes comments, they tend to go stale. And they may describe things which are not really true anymore. And with the binary, it's a bit harder. One downside, of course, it's much, it takes a lot of more time. But that's life. And so just to summarize, there were some bugs that we found until recently. And just mentioned previously, this is by Vasil Cerveris. He found some issues by just monitoring the network during the activation process and trying to change some things. Then the other vulnerability that was found this year, earlier this year, about the empty digest that could be sent to login to the empty. And that one was found just looking at the network traffic again and trying things. So without source code again. And the last one with buffer overflow again was found without source code just by decompiling the binary code. So just to summarize, even if it's black box and you don't have source code, you can audit it. And maybe you can even get by without this version. Of course, it's better with reverse in my opinion, but you can try without it in my work. Now, one more thing. You can write an undetectable rootkit for it. It's healthy and undetectable. And indeed, there were some attempts of making rootkits for the generation one M.E. In particular, in 2009, at Black Hat, there was a presentation by Invisible Things Lab. It was probably the first research on this topic. They found a bug in some biases which allowed access to the Intel's memory area. And at that time, it was just plain text code. So not protected, not anything. And they could inject some code into M.E. memory and execute their code. So this allowed them to kind of have a rootkit like thing. But it has some detentions. It has to be infected on each reboot. And since then, Apple, sorry, not Apple, Intel fixed it. They implemented integrity checking, so you cannot longer do this. All modifications will be detected and rejected. The machine will reboot. Then there was Patrick Steven who wrote a book on detecting DMI attacks. So I think it's not, it can't be considered undetectable anymore. So you can detect DMI by some side effects. And it's not so stealthy anymore. And some people say, okay, it's there and you cannot remove it and you cannot do anything. So I think it's a myth. Let's see what can be done about it. So about one year ago, I started playing with Core Boot and I asked myself if I could remove the Intel M.E. firmware. And unfortunately, the Libre Boot FAQ page had the answer. And it seems that before version six, it was possible to disable Intel M.E. just by removing the firmware from the spy flash. Unfortunately, this isn't available anymore because starting from version six, if you remove the Intel M.E. firmware, the PC will turn on and will turn off after 30 minutes. So it seems that it is not technically required. It seems like an artificial lock. So I started looking for a way at least to reduce its firmware. And I found this message on the Core Boot mailing list by Tram Elatson in which he tried to remove parts of the Intel M.E. firmware. And he found out that the PC still turned on without turning off after 30 minutes. And in a few days, he found out that he could actually remove parts of Intel M.E. without compromising the correct boot of the system. So I tried to do his work again. And I avoided doing things by hand with the next editor. I started writing M.E. Cleaner, which is a Python script able to reduce an Intel M.E. firmware image to the minimum image needed for a correct boot of a PC. So first of all, where is the Intel M.E. firmware? Where is it located? It is located on the same chip as the BIOS UFI. So reading and writing it is quite simple because you can either use an external programmer, which can be a cheap Linux board with an SPI interface or a dedicated programmer. Or in some cases, you can also use the vendor tools to flash the BIOS to dump and write again your modified image. Now this is possible because the spy chips in the Intel system can be used to send the spy chips in the Intel systems, our partitioned. So this is the scheme. You have the Intel flash descriptor, which contains different partitions inside the SPI chip. So we have the descriptor region, which is like a partition table, and then different partitions. For example, the BIOS region and the Intel M.E. firmware region. All we want is the Intel M.E. firmware. So we just have to extract it. And we can use it with the help of IFD tool from the core boot project. So first step, let's try to remove every partition from the firmware except for the FTPR, which seems to be the fundamental one needed for the correct boot. Indeed, the Intel M.E. firmware is partitioned. This is the simplified scheme. So we have an FPT, which is the firmware partition table, which contains a list of the partitions inside the firmware image. In this image, we can see that there is the FTPR, which is the core partition, and the NFTP partition, which is the partition with the network stack and AMT. Removing this partition is quite easy, because inside the FPT we have these entries, and each entry has the offset and the size. So all we have to do is just to remove the code from the offset to the offset plus the size. The partitions are signed, but they are signed individually, so we can remove the whole partition without any major effect, because the signature was inside the partition, so we removed both the code and the signature. Moreover, the FTP is not signed. It just has a checksum. So it's quite easy to remove everything we want. So I tried it. I flashed back the result on my PC, and it worked. So this was the first step. The next step was to try to remove the LZMA modules. Now things are becoming a bit complicated, so let's review the layout of the Intel ME firmware. So we have the SPI chip, which contains different regions, for example the descriptor, the BIOS, and the ME region. Inside the ME firmware we have different partitions, for example the FTPR and the NFTP, and inside each code partition, for example the FTPR, we have different modules. The modules can be either Huffman compressed or LZMA compressed. They use two different kinds of compression schemes, because LZMA offers better compressions, but it needs a loaded firmware to be used. On the contrary, Huffman has a worse compression ratio, but can be done directly by the hardware. So they use Huffman to compress the early stages modules and LZMA for the later stages. So different partitions have different structures, but since we kept only the FTPR partition, we are only interested in that, and that is a code partition. Moreover, the internal structure of the partition changes between the different Intel ME generations. So generation one is not of our interest, because Intel ME could be removed completely, so no problem for us. And let's focus on generation two, because I started from that. So this is internal scheme of generation two code partition. So we have a section that is a manifest, which contains the RSA signature of the list of the modules. Here you can see that we have different modules, and each entry has the name, the offset, the size, the compression type, and most importantly hash. This means that the modules are not directly signed. Each module is hashed, and the list of the hashes is then signed. Luckily for us, the hashes are lazy-evaluated. So invalidating a hash of a module doesn't prevent a loading of a previous one. This is important, because it means that we can stop the boot of the system by invalidating a module. All the sequence module will not be loaded, but the previous one are okay. So I tried again. I updated ME cleaner, and I tried to remove every partition in the FTPR, LZMA compressed, so that only five modules were kept. I flashed back the result, and it worked again. So at this point, I had removed most of the code, but there were still the Huffman modules, and I wanted to remove at least most of them. The documentation online for the Huffman modules were very poor, so I relied on the source code of ANAFME, which is a decompressor for Intel ME generation 2 for the Huffman modules, and I recovered this structure. So while the LZMA modules were just a single block of data from the offset to the offset plus the size, the Huffman compressed modules are fragmented. So there is a single partition share, Huffman stream, and we have an LLUT, which stands for local lookup table, which contains a list of entries that has a valid flag and the offset. The offset's point to the Huffman chunks, which are a fixed size uncompressed data, but from our point of view, since we're seeing only the compressed data, they are variable size. This, let's say, complex scheme was probably used by Intel to further shrink the Huffman compression, because in this way, different chunks can be reused again in different modules. However, once I understood the structure of this, all I had to do was to create a white list of the modules that couldn't be removed because they are part of a partition of a module that I don't want to be removed, and remove all the others. So I tried to remove the module with less important name, just to start, which was FTCS, and I flashed back the result, and it worked again. So I moved on, and I tried to discover which modules were really needed for the boot, and I found out that only two modules were needed. These two modules were the BUP, which stands for bring up, which is the first loaded module, which initializes all the system and turns off the 30 minutes watchdog. The ROMP module, which is not always present, seems to contain some sort of configuration data read by BUP, but it's very small, something like two kilobytes, so not a problem. Interestingly, there is no kernel now because the kernel module has been removed. So it seems that on generation two, it's possible to have a fully functioning PC without a kernel running in Telami. So next step, recover the free space. Why? Because I was using core boot, and the Telami firmware image was something like five megabytes. While the code remaining after the removal was much, much less, and I wanted to recover that space because I wanted to store a Linux kernel directly inside my spy chip. Why not? So I started just by truncating the image just after, let's say, the last valid module. And that worked. Well, that was expected because the space that I had removed wasn't mapped by anything inside the Telami, so I could easily remove it. But that wasn't enough because, let's see for example this scheme. Between the FPT, which is at the beginning of the ME image, and the FTPR, which is our partition that we must keep, there may be other partitions that I had previously removed. And now they are not there anymore. So I have the FPT, something like one megabyte of FF, and then finally my code. And I want to recover that space. So I have to figure out how I can move the partitions. And you may say, well, it's easy. You just move the code, you correct the entry inside the FPT, the offset of that entry, and that's all. Unfortunately, on generation two, it's not possible because, well, it's not that easy because it seems that some offsets inside the FTPR partition are not relative to the beginning of the FTPR partition, but they are relative to the FPT. So you can't move the code without adjusting them as well. It took a bit of time, but I was able to find them out, and luckily they are unsigned. So after many tries and breaking my laptop many times, I found out which ones were the responsible for this behavior and I corrected them as well. I flashed back the result and it worked again. So this is the current situation. Starting from a 5 megabyte image, we have now an 84-kilobyte image, which is moreover full of free space because as you can see there is the FPT padding, just the header and some pointers, padding again, 50 kilobytes of data, which is the real data, and then padding. So starting from 5 megabytes, now we have, let's say, 50 kilobytes. And just to have an idea, this is the size comparison of my image. So you can see that most of the space is dedicated to the network stack and to Intel AMT. We have a small partition of FTPR plus a small partition of EFFS, which is an internal file system that Intel ME can read and write. And inside the FTPR, the only thing that we really need for the core output of the PC is that BUP plus sometimes the ROMP, but it is very, very small. So I decided also to port my work on Generation 3. Now don't start leaving the room saying, oh, my God, it's starting again from the beginning. No, with Generation 3 it was much, much easier because the internal structure of the partition have changed. Without any change, I was able to remove all the partitions except for FTPR because the structure was the same. But the internal scheme of the partitions have changed. And this one is the new internal scheme of the code partitions. Now they are indexed by the code partition director, the CPD, as depicted in the picture. So we have three different types of entries, which are the name of the partition dot man, which is the old manifest plus the extensions, a module metadata and a module data. As you can see, also the signature scheme has changed. So there is the old module manifest that signs the extensions that hashes the kernel metadata, that hashes the kernel data. But luckily for us, the lazy evaluation of the hashes is still valid. So we can exploit again the lazy evaluation to remove as many modules as possible. So this is the list of the types. So I tried again. By trial and error, I figured out which modules were really needed and which one were not. And it seems that only four modules are really needed. So syslib RBE, which is sometimes a very small partition, like the corresponding of ROMP, the kernel this time and the BUP partition. After weeks, some weeks later after my work, the positive technologies researcher shared the discoveries of a method able to disable intrami. So they conferred my work and they found a nice bonus, let's say, which was that intrami generation three, so starting from intrami 11, which is Skylake, has a kill switch, which is the HAP bit. If you want to learn more about the HAP bit, I suggest you to read the blog post here. I just tell you that it's a bit, you set this bit to one, intrami turns off just after the system initialization. Just after the run of the BUP module. Igor Skoczynski, moreover, found a different bit, the alt ME disabled bit, which should achieve the same result, but on generation two. So we have two different bits, one on generation two and one on generation three that are able to soft disable our intrami without trying to modify the code. So the final result is that a combination of HAP bit and alt ME disabled bit is able, plus the code removal, is able to completely turn off intrami just after the hardware initialization. Moreover, these two bits force intrami to turn off and report the same status to the system, so it seems that it is better supported by commercial bios implementations. Moreover, to check the status of intrami, I used the intrami tool, a tool from the core boot project, to retrieve the status of intrami. So here you can see its output on a ThinkPad X220 with the sole code removal. So for example, you can see the error code, which is image failure. So it tried to load a module, but that module hadn't a valid hash. And you can see that the firmware in it complete has not been completed. And the current progress phase is the BUP phase. Intrami is stuck trying to load the kernel, but it can't load the kernel because the kernel is not correctly hashed. With the addition of the alt ME disabled bit, you can see that the status of intrami had changed. And now the progress state is ME disabled. So different states, but the result is the same. Moreover, thanks to the testing performed by the community, I found out that ME Cleaner is not limited to my PC, but works on any PC from Nihon to Kofilik. So the current line of Intel products are covered by ME Cleaner. As you can see, the firmware size, if you want to retrieve the space, is greatly reduced. So we go from 1.5 megabytes or 5 megabytes, depending on the intrami firmware, to 84 kilobytes for generation 2, and from 2 megabytes or 6.6 megabytes for generation 3 to 330 kilobytes. Many, let's say unwanted features are now gone. So on generation 2, there is no kernel running anymore. We lose the NFTP, so no more network stack or AMT for intrami. The dynamic application loader is gone, and the platform trust technology, which is the firmware TPM, is gone. Okay. Something bad can happen sometimes. So on many PCs, and this depends only on the firmware implementation of your PC. You can have a brick, so the PC doesn't turn on at all. No way. You can have a slight boot delay, so some seconds before the screen turns on. On some biases with dual-bios feature, there is an automatic rollback of the ME Cleaner modification, so you flash ME Cleaner, you turn on the PC, and you find that the ME firmware inside your SPI flash has been downgraded to the previous version. And sometimes you can also see these warning messages, so careful. Your intrami firmware is damaged. Press F to continue. Some features that someone can like are now gone. So first of all, you can't have overclocking with this kind of removal, because the ICC partition, which was one of the modules removed by ME Cleaner, is now gone. You don't have obviously Intel AMT anymore. You don't have Intel PAPV, which is the protected audio-video path anymore, so some kinds of DRM may be broken now. And some parts of Intel SGX are gone, plus other stuff. Now you may say, okay, this is good, but I want to see some proof. Well, first proof, you're seeing these lights, they are my PC, my PC doesn't have Intel ME, the full Intel ME anymore. Let's see, however, demo. So we have initially the original ME image, which is, as you can see, five megabytes. Let's run ME Cleaner on it. Here it is. Good luck. And you can see that now the modified ME image is only 84 kilobytes. Let's see the difference between these two. You can see that the original ME image, as in his FPT, many partitions, the modified as only one, the FTPR. So let's dump the current running firmware on my PC. You can see these reassuring messages from my flesh on, ignore them, everything is safe. Let's extract the Intel ME firmware from the dump, okay, with IFD tool. You can see here, you can see flesh region to Intel ME dot bin, which is 84 kilobytes. Let's compare it with my modified image. You can see it's the same, so I'm running my modified image on my PC. Let's then see the current status of Intel ME, with Intel ME tool. So as you can see, the firmware in it hasn't completed. It's stuck in the initializing, and as you can see in the progress phase state, Intel ME has been disabled. Moreover, note that the response from Intel ME is not complete, as for example Intel ME cannot give you its current capabilities because that part of the firmware is now gone. So what can you do? Well, you can try and clean on your system. However, be careful, because it's a bit dangerous, so you may want to have a recovered way to restore your PC. If it works, well, if it doesn't work, not well, but please report both of them. And, well, I would also like to thank all these people that directly or indirectly helped me in this research. And that's all. Here's some links to our projects. You can check on my GitHub. I have some tools for working with ME for extracting images. If you're interested in universal engineering, I have some stuff. So you can dump the images and extract modules and assemble them. I'm planning to, I'm populated now, so that we'll have more information about the internal structure of ME so we can make more sense of the assembly. Hopefully that will help people to investigate more about how it works and discover other things about it. And I guess we can take some questions. Thank you, Igor. Thank you, Nicolas. If you would like to ask a question, please line up at the microphones. In the room there are six of these. If you would like to leave, please leave to my left, your right hand side only. Thank you. Is there a question from the IRC? Hello? Hello? Currently not. All right. So microphone number one, your question. Can we enter ME, access memory met IO? I'm not sure. I think probably not. Because it uses DMA and I don't think DMA works over MMAO. But of course, I don't have currently the execution inside ME. But you can ask Maxim maybe he can try and see if it works. He has execution in ME 11. But as far as I can tell, probably not. I hope that answers the question. Okay. Microphone number three, your question. Yes. In your presentation you mentioned the word break the laptop quite a number of times. If one actually has access to a clip-on programmer for the BIOS, how safe is this? Can you always reprogram the entire thing and recover, get everything back the way it was? Or can you actually really damage your laptop beyond repair? Okay. First of all, no laptop have been armed during this... during this research. I have here my laptop. I've bricked it something like 40 or 45 times, something like that. And it's still working. So that's partially answer your question. Yes. If you have access with an external programmer and you have a valid dump, you can always roll back the modifications. And that's why if you go on my GitHub page, you see that I always recommend using an external programmer because once you have a valid dump, so you should be really careful while doing your first dump, you're always safe. For example, I've physically broken a SPI chip. I removed it. I soldered another one and they flashed back the firmware and it's still working. So if you have an external programmer, you should be always safe. My number four, your question. Hi. Hi, great talk, first of all. Thank you. Small question. Does the removal of the Intel IME reduced the power consumption of the whole PC as well? A little bit maybe because of the reduced bite size. I think so, but because you don't have Intel IME running anymore. But the point is that Intel produced Intel IME in such a way that its impact on the power consumption was minimal. So I think that the removal of its firmware shouldn't change much the situation of your PC. Yes, on the other hand, I think that since the clock control module is removed, you may lose the clock control. So for example, the reducing of the processor speed that is sometimes used to reduce the power may be gone. So it may actually consume more power, but I don't think anyone has actually measured. So it's an open question for now. And I guess it depends on the board on the actual firmware and how it's configured and so on. Okay, thank you. Mic for number five. What's your question? Are you guys in contact with the Intel company? So just to make, you could tell them to make sure that in future on version four or something, they do not start signing all of the stuff because they would make these fixes or cleanings impossible, I see. Sorry, I didn't quite get. Do you want them to start signing? No, stop signing. Stop signing. I mean, in your talk, you mentioned that certain parts were luckily not signed, but... No, I said they're not encrypted for now. Yes. Well, they did start encrypting one module for now. They start encrypting the PAVP. And some people theorized on Twitter that it's related to some contract with Netflix. So apparently they want to hide some DRM keys or whatever. But the rest of the firmware is still open, so you can still extract it and disassemble. So I don't think they plan to start encrypting the rest. It doesn't really make sense. Their threat model, I think, does not rely on the prosecution. I think it's just contractable obligations that they have to encrypt that part just because of DRM. So I think it will stay encrypted for the foreseeable future. Microphone number two, your question? In the slides earlier, you had some RAM area you mapped to the ME. Is this part of the main computer's RAM? And how is it reserved? How does the ME make sure the actual user OS doesn't... Yes, so this is called the UMA, Unified Memory Architecture. Not sure why is the name. But this works in a way similar to some graphic adapters work. So it takes a part of the RAM of the computer and resorts for the use of graphical device for ME. And this is enforced by the chipset. So the host processor cannot access it. So, yeah, it's like that. So the BIOS has to configure it properly to allocate this memory and lock the registers. And if BIOS does not lock the registers, then you can have access to that memory in theory. And that was the kind of the attack in 2009 that they broke the ME the first time. But for the moment, it's enforced by the chipset. So once the register is configured properly, you cannot access that memory from the main CPU. But in theory, you could access it, for example, by using hardware attack. So just by accessing the address lines on the RAM. However, it will not be enough. As I mentioned, they started integrity checks. So ME, once it gets back the memory into its own RAM, it checks if it has been modified. And in that case, it shuts down the computer. So there's protection against modification. Thank you. I'm fully aware there are still questions, but unfortunately, there are times I put a story. Can people still find you for further questions? On the conference, I mean. Okay. If you have other questions, we can talk on the floor. Thank you. Thank you.