 All right. Hi, everyone. I will just skip the introduction because you see my name and you might have seen me before. I would like to start with a bit of a disclaimer. So I will be speaking about a very specific company, which is Intel at this part. This year is not about blaming anyone. It's not about saying or pointing out that something is very, very bad anywhere. This is really just about getting a clue of what we can understand from previous work or what I have personally looked into to understand what the Intel management engine is and what it's doing or what it can do. As I might have some errors in here, there will be a link to my GitHub repository later where you can also find all the slides so you can just file issues or make pull requests, which is even easier. So we'll just start with a hopefully brief introduction this time. I already gave a similar talk at C3 last year, like a month ago, with very bad timing actually. So I'm very sorry for that. I will therefore skip some of the parts ahead and there. Then I will speak about the perspective from the open source side about creating firmware and working with what we already have from vendors. Then I will give you some motivation why you should maybe look into what I looked into. I will start with how it actually started for me. Then I will give you lots of hints of directions where you could go. In the end, I will also come up with a brief conclusion. Hopefully I will make it there. So for the introduction part, you all might have already played around a bit with microcontrollers like the Arduino stuff and everything. And when people ask me about firmware and they want a very brief explanation of what it actually is, well, I point them to that. And I tell them that actually what you have in your laptop today is very much the very same thing as just playing with Arduino, except that you have 20 Arduinos in here. And of course, they all are connected together. So you have these are now 20 or more chips in your laptop. Or also if you work on servers or whatever machines, it's still the very same thing just with some minor differences. There are some components which are actually critical to the entire thing. That starts with what we know sometimes as the Southbridge or more general, the chipset, which kind of connects everything nowadays. Intel calls it the platform controller hub now because that's where all the controllers are coming together. There are two variants actually. So sometimes you have all the CPU cores also in the very same suck. Like in this example here in the picture, sometimes it's two separate chips. I will come to that later. But besides that, there is two things which actually seem like they have a lot of power and probably they shouldn't. So that's why we take a closer look here. One of them is the embedded controller, which on your laptop is for regulating battery management. For example, when you connect your charger, you will see an LED actually light up. And that even works without running an operating system. Why is that? Because there is an embedded controller actually doing that. Of course, you could also do that just in hardware directly. But there is much more to it. And this controller can also be connected to your keyboard and mouse. Sometimes it's even a dedicated chip. It can be connected to your TPM or a fingerprint sensor or whatever and also basically to everything else. There is also related work but more on that later. On servers, you have a very similar thing which is called the BMC, which you can use for power cycling or provisioning from outside. But usually, that's on a different network interface. And then there is something, which is the management engine, which is also kind of similar to that. And that's what we're focusing on today. But first, I would like to give a very, very brief perspective on the open source firmware side of things, starting with the list of projects. So we have projects you already heard about here. There is the Coreboot project, which you can use for initializing your hardware. For example, this laptop here is also running Coreboot now. Like many other devices, you might find at this event. Or people also ask us, and they want a Flash Coreboot on their device. So that can already take control of a lot of the laptop. Then there is the Linux Boot project, which can be used as a payload. We already heard about the HAT project, which is also kind of the Linux Boot approach. So you have a Linux kernel, and then you have some tools which are running on that kernel to then actually kick off your operating system. There is the Euro project, also very similar. It has its own tool, so it's similar in the approach. Then we have fire embedded controllers from Google for all the Chromebooks, open source firmware, actually. And the same thing as currently being done at System76, there are repositories online. You can find them on GitHub. Parts are on gitlab.com. Yeah, you will find it. Actually, the slides are also online, and you can just click through all the links. So all of what I'm listing somewhere is actually links behind it. So yeah, just follow them. For the baseboard management controllers on servers, we also have open source projects. There is OpenBMC and there is UBMC, also very similar actually to the Linux Boot approach. So you also have Linux kernel and just some tools which are then running on that kernel to actually control the system. OK, so let's look at the InterX 86 platforms a bit. So I mentioned sometimes you have everything in one sock. Sometimes you actually have two separate chips. People are, well, if you look back some years ago, we were used to knowing something called a CPU. There is something today which is very, very similar to that, which you can see in this picture. It's called the core processor now. There is slightly more than just a CPU in that. You can also see that it's also connected to other devices like your graphics card, for example. So that's where it's actually doing a bit more than really just processing. So yeah, it has relationships. And this is really just a very, very high level overview. Let's take a closer look at one platform, which is the Denverton platform. That's one of the few images actually where I could find a direct reference to the management engine, which is what we're looking at now. Here in the upper right corner, do I have a cursor here? No? Anyway, so in the upper right corner of this image, you see two engines managed, one of them mentioned. One of them is the management engine. One of them is called innovation engine. So what is it? The management engine, as we know it today, is basically just a microcontroller. So you can imagine something like Arduino. It's an AD51 instruction set. There have been multiple hardware versions over the time. I think this is now currently the third generation. So it's not changing very much. But there is still lots of difference among the implementations around it. It actually started with something that was called the active management technology, and that still exists today. So the first idea was to have something very, very similar to a baseboard management controller, but it's still part of the entire thing. So it's not on a dedicated chip or, well, it's actually integrated into everything. And it doesn't have its own NIC. You can still use the very one NIC, so the network interface controller, that you also use for other services. So sometimes people ask me, hey, what is this management actually? What is the engine? Is it dangerous? Does it really do everything that I heard about? Because there was references about web servers running in there, which is not untrue. And there is rumors about being capable of actually wiping your entire laptop from outside, which is also not completely untrue. So what's actually the case is, there is multiple versions of it for multiple purposes. And if you buy your whatever, ASO laptop or something for a few hundred euros, that's not very likely that you have those features in there, because they are not designed for consumers. More on that later. So now there's a bit more that was actually put in the management engine. And that's why today it's actually called CSME. So CS for Converged Security and Management Engine. I will briefly mention those security features as well. But first, let's look at the innovation engine. I've only found it in this very one picture I just showed you from what I have been told. HP Enterprise is actually using it for some purposes. And it's kind of really just a one-to-one copy of the management engine, which is why I'm mentioning this. So we can just monitor what's happening over time and see if they still exist side by side or if they diverge over time. But yeah, this is where it's starting now. But first, let's look at how the entire platform works together. So I just explained that we have lots of chips in our laptops. And one of them is actually the management engine. So it's actually part of one of your socks. What is it doing? When you power up on your laptop, there is a ROM in that chip. It's usually very, very tiny. And that's also true for many microcontrollers actually. They have something called a mask ROM or a boot ROM. So that's what's running initially. And it's quite common that you then load another image into RAM, which comes from somewhere else, to then keep running and do more things than really just the boot part. That's called RBE here. So RBE is the first phase, which is just after boot up. It's like ROM, boot, extension, or something like that. Then there is BOP, the bring up phase, which is supposed to launch the entire platform. So you should know that the management engine is also connected to all the other parts. We just heard about some core boot information, or also general firmware information for the host, which is also connected to lots of devices that needs to initialize stuff. So it's basically like you have multiple chips and multiple firmware images, which are all doing some initialization here and there. And they do not necessarily know about each other. So that's where sometimes Potentially Box come from. I see some nodding in the room. So yeah, if you keep looking into firmware, you might come across this also. Well, then eventually there is an operating system running in the management engine, but not in every version of the management engine, in some versions of the firmware of the management engine. This is really not necessary, because you don't really need it. For example, I, as a consumer, I don't provision my laptop at home from my whatever server. I just run my one operating system there, and I'm OK with that. It's not like I need to wipe it from outside or have some fresh images coming in. I just take some install medium from a USB stick or something. Well, if all that is done, the CPU research vector is actually triggered from what I know. It can be slightly different on some platforms. Some people thought it might be that the CPU is just on hold all the time and then released at this point. Now the CPU can start. It can load microcode updates, and it can just keep running the entire boot process, like what we know from all the other firmware initialization we just heard about, like what Coreboot is doing or what your vendor's UUFI is doing. And then side by side with that, there is another chip, which is also somewhere integrated, the Power Management Controller. It also gets firmware updates actually from the management engine part from what I looked at. It can be that it also differs a bit on platforms, but yeah, I mean, if you want to look more into it, you might figure out differences. And then there is the embedded controller, which is really just running side by side in a way, but it's also still connected to everything. So you have to also be able to talk to the embedded controller chip. So for example, if you look at the Coreboot project's source code, then you will also find references like, hey, here we're talking to the embedded controller. For example, to read out some sensors, so you know if the laptop is overheating, so maybe you need to scale on the CPU or something like that. All right, and then at some point you come across this. You might find this sticker on your laptop. It says something about Core i7 that sounds like the regular marketing stuff you hear. 9th generation, so a bit like was made in 2018, 17, 19. I don't know which exact year it is. And then there is this thing called vPro. And that's where I came across when I was looking at the management engine stuff. So what is it? It's actually kind of an umbrella marketing term. It does not refer to very specific features, but it may include a lot of features. Part of that is today also the active management technology, which started at some point in time. It can also contain security features. So the problem is just we don't have very much information on that. There is the ARK. It's like an archive on Intel's website, where you can read a lot about CPUs, like what their exact features are, if they have integrated graphics, whatever, and certain features. So not all the CPUs are the same. But when it comes to vPro, it does not speak about support, like hardware support. It speaks about eligibility. So not every chip is actually eligible for this. What does that mean? It does not mean that the hardware is not able to do this. So we had some discussions very recently, actually. So thank you. Now sitting here discovered that this boot guard feature that you might have heard about is actually still usable in some of those chips, which are not officially eligible. OK, so boot guard is one of those security features I just mentioned. It's able to lock your firmware down so that you can only boot images, which they should have certain signatures, checksums, or something like that. So you know what you're booting is actually OK. Usually that comes from your vendor, not from yourself. So you would have to trust your vendor now. There is other features like software guard extensions and the TXT stuff that also nine elements or nine elements cybersecurity is working on. So here's a long list about what all of this management engine technology is actually about. And there's interfaces for it. So you also need to have some part in your firmware and you also have to have some part in your operating system to actually talk to this, right? So that's implemented in the Linux kernel, for example. You can look at the source code. In the firmware, there is something called MEBX. So when you boot your laptop, you may also be allowed to talk to it if you have the corporate version of the management engine. Here's a small timeline. It's not necessarily accurate. But this is what I kind of came up with after I read from Igor Skashinsky. He also spoke a lot about ME and reverse engineering. Yeah, but I recommend looking at this slide in detail when you have some time. Version 12 of the management engine was released quite a while ago. There is some public documentation about it, not very much, but at least some. But recently, well, actually just at Curse Communication Congress, we found a laptop which also has version 14. But that's not in the archives anywhere so far. At least I haven't found anything. So it kind of stops at version 12, which allows you to deactivate this management technology. So that's maybe for corporate versions where you may need to disable this to secure your platforms more. So these are the variants I know so far, which I have found. There's the consumer version, the corporate version. Some people refer to a slim version. I don't really know where it's found. There is a server platform version. And there is now something which we're now looking into, the ignition variant. And that was my motivation to actually look into this whole stuff. So in the ADK2 mailing list, there was something popping up, which is an ignition firmware binary, which well, comes with a brief explanation, which basically says, yeah, this is a very minimal thing. It's designed for this and this chips or platform. So if we now take this and the FSPC firmware support package, which we also heard about, then now we could actually kind of make a full image to have for more for a laptop. Well, without all the reverse engineering, which we might not be allowed to do, but still all the glue code around it and then have some other critical parts actually open source. So let's follow along. Here's the license for it. It explicitly disallows decompilation, disassembly, everything which would give us really a direct clue. So this is also briefly mentioned in some other references, which I put here. Like, for example, the FSPE training, there is a slide saying, well, Intel knows there's lots of firmware engineers out there. It doesn't really directly say that, but it looks like they don't really want to disclose all the information. So as a workaround, they provide the binaries. In the white paper, they are saying that binaries are actually quite good. Because that's kind of the middle ground we can meet, as long as it works as desired, which is not necessarily always the case. So if you work with Coreboot, you might sometimes came across issues somewhere, especially if you don't have much documentation. This is also where Dexter's Law applies. You might have heard about that one, which says that only proprietary vendors actually want proprietary firmware. So I, as a consumer, would never say, hey, I want some software from you, but please make it close for us. Make me never look into it or something. Nobody would ever say that. Let's spot the issue. When we're talking about security, attackers don't play by those rules. So if there is some shady people sitting somewhere in a dark corner, and they want to hack your laptop, they do not care about that. But we're on the other side. We actually want to secure our laptops. And now we have this problem. We can't really look into it very much. So we cannot really investigate our attack model here. But we can take some first steps. There is previous work. There is some analysis tools. There has been some reverse engineering. So I put all the references here. And now we'll tell you a bit about some attacks, which actually resulted from some reverse engineering. So for example, there was the planter vault attack. This is what some shady people in the dark corner could have come up with. Nobody would have noticed because you were never allowed to look into the stuff, right? I think everybody heard about this. If not look into the stuff, it's just planter vault. Search for it, you will find it. Which, well, brings us to this question, can we actually trust the vendors? I have very briefly wanted to come up with something like a definition of trust, which is, well, inherently complicated. I just sum it up. So for me, two kinds of trust. There is something which is actually earned. And there is something called blind trust. So blind trust is basically like the, well, this will be a right model. So my question is always, why do I have to disclose what, like when I bake cookies, I will have to tell you if it contains nuts because some people may be allergic. But if I provide you with hardware, I don't have to disclose anything basically. Yeah. So security actually has many dimensions. We have heard about these security issues. There's something which is called a responsible disclosure and also coordinate disclosure. That's the model that the researchers are using. And also, well, most of the companies are using. So they don't publish information upfront. They will take it offline. They will have their internal discussions at some point. That will be information released, hopefully. Now, inter-researchers actually just wrote about this. They agree that we need common taxonomy to actually talk about those things so that we don't misunderstand each other. This is here my security perspective. Actually, some people also agreed to that, we need to be able to audit our stuff. If we cannot audit something, we cannot trust it. And therefore, no audit, no trust. So here's a brief introduction to firmware analysis. I like to look at firmware this way. It's a bit like emulating firmware, but it's really just reading the raw bytes which you have in your firmware image. You can do this with very nice tools like XSD and less. So that gives you this. This is how the me firmware is actually partitioned. So it's really just very, very simple data structures from all the tools I already mentioned before. You can come to these conclusions. It's really just simple, right? It's really just listings like these regions are here and there. Yeah, there is different sorts of entries in the firmware. You will figure it out if you look further into it. So I'm just listing those here for reference. Unfortunately, I'm almost out of time once again. So I will just skip through some of this stuff. And of course, come talk to me because I'm really interested in exchanging more about this. If you can read x86 instructions, of course, you can just look at the raw bytes because this is not decompiling or disassembly. It's really just reading, right? Yeah, time's up now. So just for a very brief conclusion, all firmware has to be open-sourced for security. That's what I propose. Some people agree. And to fully on your own hardware, we actually have to do something about this. Here's lots of projects where we have open-sourced stuff. And that's where I'm ending here. I would like to actually thank all those projects which are also present here and also my hackerspaces. Unfortunately, there is no time for questions. So this slide is for people watching the recording so you have the reference. Thank you.