kind of person that spends like a week fine tuning the SE Linux policies. And I first found out about the management engine, I don't know, six, eight years ago. And it just planted this little seed of doubt in my mind. You know, as I'm there working away securing the OS layer and wondering like, well, what about this back door at the hardware layer

that I can't touch and I can't get rid of? So I followed all the research and finally when there was a way to disable the management engine, I jumped on it right away. I decided I wanted to put together a talk to help all of you to streamline it so you

don't have to make the same mistakes that I did. So my name is Brian Milliron. I'm a freelance penetration tester. My company is ECR Security. I've been doing penetration testing for about eight years, primarily in the energy generation field. Prior to that, I spent about ten years as a security engineer and network architect. So

when information about the Intel ME first started coming out, they called it a chip within a chip because it's a completely autonomous subsystem. It is not actually inside the CPU as they first thought. It's located on the PCH hub. It is completely closed

source. It includes a number of modules, one of which is the AMT for remote administration. It works just like ILO for completely hardware level remote administration. It runs a Minix 3 OS. It is included in all the Intel chipsets since

2008. And some of the limited set, subset of chipsets earlier than that going back to 2006. It runs on an Intel Quark 32-bit microprocessor. It has its own separate file system which is stored in SPI flash. Some of the other modules included in the management engine are boot guard, TPM, DRM module and quite a few others. So some of the

capabilities for the management engine. It's active even in the power off S3 state. As long as the main power is connected, it can be activated. It has its own, its own

complete separate network and TCIP stack which is completely independent of the operating system. It communicates out of band and the OS cannot see or modify those packets at all. You might think well, I have a network appliance. I have SEIM. I have

you know, wire shark running on a separate system. But does that system, does that network appliance also have an Intel ME chip in it? The ME has full read write access to all areas of the system main memory. It has full access to the system bus. It operates in SMM or protected system management mode. So the OS cannot see or

interfere with any of its operations. This is basically a god mode. It can read and write to anything on the system. If it receives a magic packet over the network interface, the AMT can be activated remotely to power on the system, change settings in

the OS, change bios settings, view video output, do anything that a user could do sitting at the local terminal. Because it's intended for remote management. You might hope that a subsystem of this much power over your system would be very well locked down and

hardened in security. That is unfortunately not the case. All the way back in 2009, Invisible Things Lab developed a rootkit which lives inside the management engine in the system management mode which can hide from the operating system any malware

preventative software that you have on the operating system. It was completely persistent, could survive being, you know, the hard drive being wiped. Back in 2010, Vassilios Ververdes developed a certificate based authentication bypass to remotely enable, deploy and provision AMT even if it was disabled in the bios

previously. And then here recently just last year, 2017, the Silent Bob is silent vulnerability, remotely exploitable authentication bypass. You just send a null field to the password to the AMT and you get full remote management capabilities. The AMT must be

enabled however for this to work. This does affect not only PCs, this affects servers, firewalls, HSM, security appliances, anything on your network that has an Intel chip is vulnerable to this. Again, also in 2017, buffer overflow leading to remote code execution. So unfortunately this thing is full of holes. This is just what we've

discovered so far. It's closed source and it's very difficult to audit. And unfortunately Intel makes it very difficult to get rid of. We all wish that there was just a simple check box in the bios where you could just say turn it off. I'm not using this. I'm not even an enterprise user. But they want to make it as difficult as

possible. The management engine firmware is located in a region of the SPI flash memory that is inaccessible to the bios and the OS. The core modules are RSA signed. If the signature verification fails, it will fail to boot. They're also using LZMA and

Huffman compression as a form of obfuscation. They're using a hidden directory to make it very difficult for reverse engineers to figure out what this thing is actually doing. Additionally, there's an extra IME verification module which runs every 30 minutes

to check to see that that RSA signature. And so if you overwrite it on boot, then 30 minutes later, it's going to check and find out that the RSA signature check fails and it's going to shut your system down. So Intel has gone to great lengths to make it very difficult to disable this. So there has been some people that have speculated that

maybe this is an intentional backdoor, NSA has a history of these kind of things. I think it's useful to play a little game of what if. So if I was the NSA and I was designing a backdoor that I wanted to be loaded on every server and network appliance in the world, what would I want? I would want it to be completely independent of the main

operating system. I'd want it to be something that you cannot shut down, that can't be powered on any time even if the system is turned off. I'd want it to be not just stealthy but completely invisible to anything on the OS. I'd want it to have full access to

everything on the system. And I'd want it to have out of band communications for data exfiltration. Intel ME does all of that. What else would I want if I was the NSA? And I want to have this backdoor in every system. I'd want to have plausible deniability. I wouldn't want any evidence pointing to the NSA. I would want to have a single rogue

engineer who is going to overlook a buffer overflow. Who's going to overlook a remote authentication bypass? That way there's nothing tying it back to us. So what are some capabilities for intelligence gathering that such a backdoor might have? It could scrape

RAM to pull encryption keys directly out of RAM. It could be used to exfiltrate data off of air gap system by enabling the wireless module even if the wireless was disabled in the BIOS and not configured. It could be re-enabled and used to exfiltrate data that way. It could also be used to infect a USB drive that was plugged in. And then that USB drive is

carried to a different air gap system to infect that system and create a two directional communications channel back out to the wider world. So how do we disable the Intel management engine? The easy way? You can actually buy systems that are pre-configured

with the management engine disabled. Purism laptops, system 76 systems. That's an option when you make your purchase. You can have it disabled for you. Dell, if you're a government customer, again some of their systems, you can ask for the management engine to be disabled at time of purchase. Okay, this is Def Con. You want to do it yourself. You

want to hack it yourself. So a little bit of history. Igor Kaczynski is a reverse engineer with hex-rays. He's kind of the one that started all of this by he reverse engineered a large portion of the management engine and for the first time the rest of the world was able to see what is this thing actually doing. 2016 Trammel Hudson

discovered that he can actually overwrite part of the management engine without invalidating the signature checks. It turns out Intel was not properly implementing the integrity verification in the firmware checksums. Nicola Corno followed up on this research and created a script that would delete most of the management engine

components. You actually can delete all of the management engine modules except the buff module. 2017, positive technology discovered an additional way. There's an undocumented mode called HAP or high assurance platform that was put in at the request of the NSA which disables the management engine after boot. So it boots up, it does

its signature check and then it disables itself. It's kind of funny the NSA thinks the management engine is a security vulnerability. Who would have figured? Using both techniques together, you can disable the management engine after boot up and then overwrite it so that it cannot be reactivated. However, since the management engine is

built into the BIOS, you're going to need a new BIOS with the disabled management engine built into it. So how many of you know about Coreboot? A few, good. So it is an open source BIOS, UEFI firmware. It is supported by Google and a lot of the

engineers contribute code. It has very bare bones functionality. It initializes hardware and passes control to the OS. That's it. It does support secure boot using the V-boot module. However, it does have limited hardware support. Most Chromebooks it will work

on because Google wants it to work on their hardware. Some of the other supported hardware is mostly older models, Intel Ivy Bridge and Sandy Bridge or the AMD Athlon. It works on older Mac books, Thinkpads and elite books as well. You might be thinking, I

don't want to be stuck with older hardware, but I found for my purposes that a 4 or 5 year old elite book or Thinkpad actually does the job. If you really have some high performance applications that you need to use this on, the Intel Pixel has some very, very high level specs. So you should be able to find a system that's going to be able to suit your needs. How much is it going to cost? You should be able to build this

for under $100. If you just have a regular 8-pin chip, all you need is a Raspberry Pi and an SOIC 8-pin Pomona clip. If you have one of the 1.8 low volt chips, you're going to

need a few extra components here. You need a logic level converter, a breadboard, a capacitor and a linear power supply. But it's still pretty cheap. So the first thing you would want to do is prepare the court boot ROM. You're going to want to build from source. Check out all the sub modules. And you're going to need to download and build a

payload. You can either use C bias or legacy bias or T auto core for the UEFI depending on what you want. And it uses a menu config. It is specific to each type of hardware. That's one of the reasons that there's limited hardware support. And

you're going to need to include all the proprietary binary blobs for that specific main board. So you're going to need your video driver, your LAN and the management engine as well as a few other things. It is very important to make sure that you have the correct PCI address for the video bias or you're going to end up with a blank

screen when you try to reboot. This is something that happened to me. You always want to use the address that's listed in LSPCI on the running system. So binary blobs. I know we all hate them but until they're all reverse engineered and open sourced we have to live with them. I found this person to be the most confusing part of

the process because the documentation on the website is kind of limited in this area. So they say you need these binary blobs but they don't go into a lot of detail as to where you get them from. What you're going to need is the flash descriptor, the video bias, the cleaned Intel management engine, PCH reference code and the memory

reference code. And depending on your main board you might also need an Intel firmware support package. So where do you get this stuff? You're going to get it out of the existing bios. You're going to want to go to the manufacturer's website, download the latest bios and you're going to extract it from that binary. You can get it from the system itself just by doing a read on the bios chip. However there's always a

possibility that you get a bad read and you would end up with some corrupted code. Coreboot comes with some helper scripts. The extract blobs.sh is supposed to do all of the extraction for you. However it didn't work for me. It's a little out of date. It hasn't been maintained in a while. They also include some tools. The CBFS tool and the IDF

tool which are going to do it. And I'm going to show you how to do this manually. So this command here, the CBFS tool bios print is going to show you what's in your current bios. And it will look like this. This is kind of a typical bios structure. It tells you the offset and the binaries that are located at each offset. So here are some

commands that you will use to extract the binary blobs. I've got all the commands here for the reference code, the machine reference code, the video bios. You don't need to worry about taking pictures of this. The slides are all on my website for you. So now that

you've got all the binary blobs extracted from the firmware, now comes the good part, actually disabling the management engine. So Nicola Corna has the Emmy Cleaner script on his GitHub. Got the link for you right there. You just run that script, point it at

the existing manufacturer's bios. Excuse me, point it at the management engine binary that you extracted in the previous step. And it's going to basically overwrite everything that can be overwritten. And it will also set the half disabled bit for you. Once you have the cleaned management engine binary, you're ready to build the final Coreboot

ROM. Do a final check of your config file. Make sure that the Coreboot knows the path for all of the binary blobs including the management engine and the C bias payload. Verify again that your PCI address for your VGA is correct. And make sure that your

mainboard model and vendor are correct. Coreboot is going to pre-populate a lot of default values based on that. There's hundreds of different settings in the menu. And all of the defaults are good as long as you get the mainboard model and vendor correct. Although you can tweak it as needed as well. And once you got all that, go ahead

and build it. And next you're going to want to set up the flash ROM on your Raspberry Pi. You do want to check the flash ROM site to make sure that your hardware is supported. They do support most of the major vendors so you should be okay. And all of

the major distributions also have it built into their package management system so you don't have to build it from source unless you have a very new chip and you have to build from source in that case to get the latest and greatest version. You're also going to want to raspi config to enable the SPI. And next you're going to want to

find out physically where is the BIOS chip on your mainboard. Most likely it's going to be 8 pins. It will look a lot like this. It will be located near the CMOS battery. And the two biggest manufacturers are Gigabyte and Winbond and they will have a large G or a large W on the chip that will help you identify it. Here's another

image of a BIOS chip on the mainboard. You can see there's not really many 8 pin chips. You might have a couple. One of them is going to be your BIOS probably. If you're confused you can just Google the model number that's on the chip itself and that will tell you if it's a BIOS chip or not and which model it is. Once you've

identified it or once you've located it then you need to identify it. You need to figure out exactly which model number it is so you can get the specs. The model number will be printed on the chip. I've got an example here for what the model number actually indicates for this Winbond chip. The 25 tells you what family it is.

The X tells you it's dual SPI. The 80 tells you it's an 8 megabyte chip and the VAIZ tells you it's an SOIC 8 pin 208 mill chip. Once you have the model number you're going to need to look up on the internet the data sheet for that specific BIOS chip. You're going to need the pin out and you're going to need the voltage at the very least.

So the voltage is either going to be a 3.3 volt or it's going to be a 1.8 volt. However on this data sheet it's not going to say 3.3 or 1.8 it's going to give you a range. It'll say something like 2.7 to 3.6 volts. That's because the voltages are very rarely exact. This is an example of a pin out diagram. Notice the little dot next to the 1.

So pin 1 is going to be marked physically on the chip. You'll see there like a little indentation on the chip. That'll be pin 1 right there. Some of the them call pin 2 SO. Some of them call pin 2 DO. Some of them call pin 5 SI. Some of them

call it DI or SIO or DIO. The clock may be called S clock. The write protect may be called ACC. If you read the data sheet it's going to tell you what the function is for each pin and that should tell you which is which. CS is going to be chip select. DO is

data output. WP is write protect. GND is ground. DIO or DI is data input. CLK is clock. Hold is hold. VCC is for power. Here's a pin out showing you which pins for the

raspberry pi is going to go to which pins on your SOIC Pomona clip. You'll notice that three of the pins on the Pomona clip are actually going to go to a single pin on the raspberry pi. So you're going to need to splice three wires together or you're going to need to use a bread board to make a bridge between them. This is an example of

what it looks like all hooked up. Now if you do have a 1.8 volt chip that's called a low voltage chip you're going to need to make a step down circuit otherwise you'll fry your bias chip if you connect it directly to the 3.3 volt output on the raspberry pi. I

have here a diagram, a wiring diagram for how to connect the raspberry pi to the logic level converter and the power supply and the Pomona clip. You are going to want to have probably a 10 nanofarad capacitor in between the output on the logic level

converter and the input on the Pomona clip. This is going to remove some voltage fluctuations that could create noise in your data signal and it could cause you to get a bad read or a bad write. This is an example of a completed step down circuit

here. You see I've got the logic level converter mounted on a bread board and that thing at the top is the power supply. Now what to do if your bias chip is actually one of those super rare 16 pin chips. Well you're still only going to be using 8 of the

pins and they're all going to be the same as on a regular 8 pin chip. However you're going to have 8 pins that are extra and you're going to want to either just leave them floating loose or you can connect them to ground or to the power pin and which of those 3 it is is going to depend on the documentation. So read the documentation that should tell you. Okay so after you've got everything wired up you need

to test the connection. Before you physically connect the Pomona clip to the bias chip make sure the power is disconnected from the laptop. Power supply disconnected, battery disconnected. The raspberry pi itself should be the only source of power unless

you're using a step down circuit with a separate power supply. And here is the command to read the bias from flashrom. I recommend that you do a read 3 times and do a hash checksum of each of the reads to make sure they're all the same to make sure that you're actually getting a good read. Um if you if any if there's any variation there the

hashes don't come back the same. You're going to want to disconnect or reconnect the clip. You're going to want to check all your connections and make sure that they're firm. You got to have a good electrical connection before you do any write here. Once you get three sequential reads that are all good then you're ready to write. Uh here's the command to do a write. You're going to write your your previously prepared

corebootrom into the bias chip. And if there's not any errors everything works out well. You're going to see the the C bias uh splash boot screen it's going to look like this. So what happens if it doesn't work? Um just because the screen is blank

doesn't mean that you break the system. It could be that you have entered incorrectly the the PCI address for the video ROM so the video is outputting to the wrong address. Uh if you wait a few seconds uh coreboot will pass on the control to the the Linux kernel or whatever you're using and the Linux kernel has its own VGA driver that will take over

at that point. Um if it is truly brick you're going to need to reflash it. You can either try and reflash your coreboot ROM or you can reflash your original ROM and get it back to specs and just double check everything. Check all the settings in your config file. Check that all your wiring connections are solid. Use a multimeter to make sure that there's everything is connected well. If flashrom cannot detect your chip

you can specify manually using the M flag however usually that means there's a poor electrical connection. It should be able to automatically detect your chip if it's supported. The flashrom developers can be reached for support questions on the flashrom channel on freenode.net and the coreboot support mailing list is here. And

here are some a lot of really useful resources that I I found useful when I was researching this. And there we have it. Um here's my contact info. If you want to get

in touch with me you have some comments or feedback or you want to work together collaborate on some research with me. Or if you want to hire me here's my website. Um I've got all the information about the services I provide on the website.