 Alright, so this is the Unicorn team 360 technology and I will let them go. Good afternoon everyone. Thank you for attending this talk. It's our honor to share our research with you. In this presentation, we are going to talk about our vulnerability we found in an XP SOC and we will show you how to use this vulnerability to implant malware into the peripherals which are made of these chips. Now let me firstly give a brief self-introduction. My name is Yiwei. I'm a security researcher of Unicorn team. And this is Shaokun Cao. He found this vulnerability and that is my colleague Hao Jishan. Unicorn team is a research group within 360 technology. The team was formed in 2014. We focused on the security issues in numerous types of wireless systems. During this talk, firstly, we will introduce why we did this research. Then, we will discuss the secure boot and its different types of implementation. Suddenly, we will reveal the details of our vulnerability. We provide two exploits. One is to bypass the unique ID verification in secure boot. Another is to implant malware in a peripheral. Finally, we will give our recommendations to vendors who use these chips. Secure boot is widely used in personal computer, workstation, server, and smartphone. It's used to prevent malicious code from being loaded and executed. But in the embedded systems, because its resource is limited, there is no TPM or trust wrong within these systems. So how to implement secure boot? We want to research the implementation of secure boot in closer constrained systems and try to find a common way to implant malware in two such systems. Let's have a basic understanding of secure boot. In the system which has secure boot support, there is a primary boot loader and I want a time program of memory in the main chip. The primary boot loader is designed by the chip vendor and permanently banned into its boot room at the chip manufacturing stage. The one time program of memory is used to store the root public key. It was banned at the product manufacturing stage. In the external storage, there are secondary boot loader or external driver applications corresponding public keys and signatures, etc. When the system is powered up, the primary boot loader will verify the secondary boot loader. If the secondary boot loader is loaded, it will be executed. Then the secondary boot loader will verify the kernel and so on. Otherwise the system will be hard. This mechanism ensures all the binary code executed in this system is trusted. We also can see the primary boot loader and the root public key is the root of the whole trusted chain. The master cannot be replaced or bypassed. So what can secure boot be used for? Secure boot can be used to prevent the malicious code from being executed. Here we give two attack examples. One example is a talk of Blackhead conference years 14. In this talk, the author provided a way to inject malicious feature into a 4G modem dongle and attack its user. Another example is a research provided by our team in DevCon 23. We modified the firmware of a femoral cell to use both nearby cellular users. If these products have secure boot, such attacks are hard to perform again. Secure boot also can be used to protect the copyright of product vendor. In industrial and commercial area, different types of secure boot have been implemented and used. One example is UEFI Impressional Computer and the server with the support of TPM. Just a trusted operating system is allowed to load and boot. Another example is a smartphone with the support of trusted dongle. Only the trusted OS can boot and the trusted application can be installed and executed. Both the two implementations require hardware support. The specific hardware unit insurer, the boot ROM and public key cannot be replaced. But in the embedded system or IoT system, due to the limits of cost, there is no hardware unit like trusted dongle. How do we implement secure boot? Many people want to design a lot of SOC for such cost-sensitive usage. These SOC integrate a lot of components such as flash, RAM, timer, radio thicket and so on. Which means most of the aimed application scenarios. It only requires very few external components to design a product with this type of chip. So it's widely accepted because it's easy to use and a lot cost. Chief one also design a mechanism which can be used to protect the firmware from being read out. This mechanism is called as code read protection. If the code read protection function is enabled, the attack or system program interface of these chips will be disabled. Nobody can read out or erase the flash through this interface again. But this also results the firmware cannot be updated anymore. So as a perfect show, the product vendor also designed the customized boot loader and implemented them in the application programming feature in this boot loader. With the IP support, the application error can be updated again. As the lower finger shows, if the boot loader error is not allowed to update, the public key can be stored in the boot load error. This is also fully satisfied the requirements of secure boot. That is the boot loader and the public key cannot be replaced. To understand how such a secure boot can protect the designer's copyright, we have to understand how does the copier control a hardware product. As this fix shows, firstly, the copier buys the PC of the target product. Then he recovers the PCB layout and the corresponding components through reverse engineering. Sadly, he corrects the code protecting mechanism to read out the firmware. After that, he buys the same components and reproduces the PCBA. Finally, he buys the firmware into the PCBA and he can batch carry on target products. Now let's calculate the cost that the copier needs to pay in this procedure. The main cost occurs in the PCB reverse and the firmware read out steps. According to the complexity of the PCB board, the cost of PCB reverse is from $20 to $200. In the firmware read out steps, depending on the strength of our code read protection, the cost is from $202,000 to $5,000. The total cost of copier product is much lower than designed one. This brings great damage to business firmware. So to define the copier, the chief vendor also designed a so-called Unique ID feature. They gave a unique serial number to each of their chips. The Unique ID is factory-listered into the ceiling call at the chip manufacturing stage and cannot be modified again. As the left figure shows, the product maker can read out the chief ID and combine it with the application to generate its signature. When the system boots, the boot loader read out the Unique ID and verify the signature. If the signature is valid, the application firmware will be executed and the normal function of the product can be used. Otherwise, the product becomes a break. So even the copier buys the same chip and buys the same firmware due to the Unique ID. They will get a break. When the secure boot is bent to the Unique ID, besides the cost we calculated before, the copier also needs to patch all corresponding passes to bypass the Unique ID and the signature verification in the firmware. Because the embedded firmware is strongly position-dependent, linked, the cost to reverse and patch the firmware is very high. According to the complexity of the firmware, the cost is from $5,000 to $50,000. And the copier needs to pay again when the firmware is updated. This is not a valuable deal, so the Unique ID is a good way to define the copier. Now let's have an analysis of the strength of such type of secure boot. How to bypass the secure boot verification? As we mentioned before, patch is not a good way. In high-level operating system, such as windows or Linux, we can hook the system API to change the behavior of the application but not to patch the application itself. For example, we can hook the MAC address reader API to give arbitrary MAC address to disable the application. But in the resource constraint as it is, is the hook mechanism also effective and how to implement it? Now let's shotgun and haoji to reveal the details of the exploits. Okay, the NXG Cortex-M series uses the method to access the UID. There is a function pointer in the fixed position of the ROM. After accessing the function pointer, you can invoke a ROM function. The UID of the chip can be obtained by calling this function. This subrouting is multifunctional and different functions can be selected through other parameters. This is the code that access the UID. And this function has two parameters. One is the entry parameter. And the first one, the integral of the entry parameter is the command. Where the command is 58, which is to read the UID value. And the UID value will be found in the return parameter. This is the description of the UID function in the NXP document. It's very simple. We just have to forge the same function. That's what we will hook to. As we know, debug systems can change the action of a program. We can set a debug breakpoint, hold a running program, or change the value of a variable or a register. In Cortex-M, we can do this without changing the fresh ROM. It means that if we can write a patch and write it before the bootloader, we can simulate a light debugger. It will work similar to a JTAG debugger. The FPV register is one of the registers of the debugging system. Of course, it can be accessed by the JTAG. But it can also be accessed by the code. If we write code like JTAG do, actually we are implementing a light version of soft debugger. The FPV is used to provide flash patch and breakpoints. Flash patch means that if an instruction accessed by a CPU matches a certain address, the address can be remapped to a different location so that a different value is obtained. Alternatively, the matched address can be used to trigger a breakpoint event. Then the flash patch feature is very useful for testing such as adding a diagnosis program code to a device that cannot be used in normal situations unless the FPV is used to change the program control. The FPV unit can be programmed to generate breakpoint events even if the program memory cannot be altered. However, it is limited to six instruction addresses and two literal addresses. The FPV has two functions. One is hardware breakpoint. It can generate a breakpoint event to a processor to invoke debug modes such as hold or debug monitor. Patch instruction or literal data from code memory space to SRAM. It has six instruction parameters and two literal comparators. Here is a very simple example to show how to use the FPV. The FPV remap register is set to 0x2000100. It means that once the converter is matched, the code or the literal data will be replaced by the data in the mapped memory. In this example, we set two variables to replace. One is the instruction. Another is literal data. The FPV compare 0 indicates the instruction in the offset 0x800100 will be replaced to another instruction. The FPV compare 6 indicates that the data in offset 0x800100 is replaced. If we enable the FPV by set the FPV control register to 3, the action of the code will be totally changed. It should be the data in R4 is 0x800000. But actually R4 is skipped and R1 is 0x1000 and R4 should be 0 but negative 1. In fact, the FPV has a fresh patch control register that contains an enabled bit to enable the FPV. In addition, each converter comes with a separate enabled bit in its converter control register. Both of the enabled bits must be set to 1 for a converter to operate. The converters can be programmed to remap addresses from code space to the SRAM memory region. When this function is used, the remap register needs to be programmed to provide the base address of the remap contents. The upper three bits of remap register is hardwired 2001 which is limited the remap base address location to be visiting 0x200000023FFF80 which is always visiting the SRAM memory region. And this is an example to replace the literal data. This constant int data is initial to negative 1. After compiling and linking, it will be stored into the flash. It cannot be changed again at runtime. We program the FPV to set the constant to remap this data to SRAM and try to set its value to 0. After we enable the FPV, all codes that access this constant will get 0. In order to verify this vulnerability in real world product, we use the Jlink to implement to exploit. Before discussing the detail of this exploit, let me introduce Jlink. Jlink is a powerful emulator and debug tool for ARM processors. It's very useful for ARM developers to debug their firmware and hardware. This tool is designed by Sega. They implement SQL boot in their firmware and use the unique ID provided by NXP to verify the license. It has a USB port and under normal use scenarios, it must be plugged into computer. So it's also a good carrier for hardware chosen. Based on example and the character of NXP's SOC, we can use the FPV to change the entry of ROM API function. There are function pointers in a fixed position. Therefore, find out the function pointer which you want to hook and remap it to the fake function. That's part of the code. This invokes the FPV to remap and go to the entry point of original program. Just run it before the target. And this is the fake IP, which is the original IP is directed to. In this example, we replace the command number 58, which is to access the UID. In other cases, it will jump to the original own entry so that it only modifies the UID but will not change any other function. You should remap the original function to the fake one. Now, let me show you the demonstration. In this video, you can see after we burn the jailing firmware and our exploit code, the development board has the same function as jailing. Okay, that's my partner, Mr. Haoqi finish this topic. Thanks for my colleagues explanation about the details of the attack. So in the following sentence, I will introduce you guys how to really exploit or illegal copy real product of the XP production. So in this video, we will show you how to copy jailing production one step by step. But before that, I will really apologize for the bad solutions of the video because we kind of like made a mistake. So in this video, can we make this? It doesn't matter. So just click it. So before we started this video, I want to, as we mentioned in the previous discussion, we needed the firmware of the jailing to do our patch stuff because we didn't actually modify the firmware. We actually patched some kind of code sections, some kind of data sections inside of the firmware and do our stuff to bypass the anti-colon mechanisms. So in this video, we kind of like, so before that, we needed the firmware of this jailing production. But as we discussed before, the jailing production has kind of like code read protections. With these protections, you can't read the firmware outside. You can't extract the firmware. And because they're, I mean, if this code read protection is enabled, then you can't access this production with the jailing or not with the ISP programming system. I mean, you can actually erase the data. You can actually erase the code, but you can read them out. So, but there is a very simple way you can get the firmware. And they basically store this firmware in the desktop applications. Remember, jailing has some software on your PC, on your Mac, so you can just upgrade your, upgrade the firmware of the jailing hardware. So basically, they just store this firmware in plain text. So you can just extract or you can just copy them out. With the extracted firmware, so we can do the data go copy. So let's start. So in the right bottom corner, so you can see we actually have a computer. We actually have a jailing. We have a development board. On the development board, evaluation board, so you can just see there's exactly the same chip, you know, we were using on the, I'm sorry, my bad. Yeah, we were using the exactly the same chip, same microprocessors on the evaluation board. And this is exactly the same with the jailing hardware production. So with the hardware, we can just download this hardware into the evaluation board. And my colleague is just doing this stuff. So you can see, because the error here means we actually got to power it up. And right now this is the firmware downloading. You can see. So with the firmware and with the same chip, basically if there is no license of application, there is, if there is no signature, basically they are just the same products, right? Same hardware, same software. But the truth is, so right here if you flash it, you can see there is two jailings in the hardware list. Now we launch the jailing software command line to verify if all of them are working on that. So this is the first one. This is the legal copy. And right now we are trying to confirm the second one. This is the illegal copy, which is also the evaluation board. See, it's totally different because the verification procedure is not passed. I mean, it's failed. So after this, we are trying to deploy our patch by leveraging the FBB unit. So before that, remember we just talked about there is code protection mechanism inside of the firmware. So if we just burn this firmware and we run it, then the evaluation board is dead because you can't actually, you can't actually erase it. You can't actually program it by the JTAG, right? But there is also another way to just use the ISP programming mechanism to erase all these code sections. This is really my bad. So right now my colleagues is trying to erase the evaluation board and make it as brand new so we can do the patch stuff after that. And there is two code flash magic you can do since like this. Then this evaluation board is blank. So we can do the next step. Connect it. So this is actually the code, we clone the unique ID and we do the hook functions. So basically while compiling it, we can just use the original firmware as a section of our new firmware. So we can just put our bypass code and the patch code inside of another region of the flash and combine all of these together as a new firmware and download it into the hardware. And try to flash it and verify. And now we launch a new jet ink terminal to verify if our work is doable or not. So this is the original one. This is the legal copy. And the second one is the evaluation board. So right now you can see there is totally the same. And the serial number, if our solution is better, I mean, if our radio solution is better, then you can see the unique ID or the serial number is exactly the same. You can just use it exactly the same as the production. So we basically would call it a legal copy. But I mean, we just do this for phones, not for profit. So we were trying to say, oh, is there any way we can just explore this, you know, do something more interesting? So then we were thinking about how about the hardware charging? I mean imagine this scenario. So like the US is trying to attack the Iraq, right? There was a case that CIO, FBI, I can't remember, but they kind of like they intercept a bunch of printers which were sending, which was intended to send into the Iraq, right? So they implement a bunch of, they just intercepted it, they patched the firmware and those kind of printers just steal a lot of stuff for them. So we were thinking about can we do that? I mean patch the firmware, patch the firmware of the embedded system is not quite easy. It's not like a computer. You can do this easily. You have a lot of Hoke platform to do this. But with the FPV function, we can do this very easily. I mean the FPV function is very simple. You can just Hoke a function or you can just Hoke a snap of code to do some other stuff. It won't, it won't infect the integrity of this firmware. And you don't have to actually analysis the firmware. And so you can just put your code and invoke this function. That's all. So we were thinking about how to inject hardware charging inside of the jelly production. And the jelly is using the AXP chip, right? So, which is also based on the core system for core. And it has a giant flash. It's very, I mean it's pretty enough for us. So the jelly firmware is also used as a lower part of the flash. So we can just, there's enough place for us. So we can just place this hardware charging inside of the blank region. So if we, if we want, we can just, we can just inject this hardware charging inside of the firmware before we, before some other, some other people purchased this hardware. So how about add a battery USB into a jelly, right? You purchase a jelly. It's huge expensive. And you saw, and you said you can, it has accelerated your development procedure. But it turns out it's a bad, it's a bad USB. It can just do all of this stuff from your computer. Because it, because you just, because you just connect this hardware into your computer and into your laptop. And you think, okay, this is safe enough. I can do my stuff. So in the, so I mean if you were trying to bypass the anti-clone mechanism, we were talking about the unique ID verification function. But in this one, we can just hook another, we can just hook another, another system, system function call. So in this case, we were, we were, we were, we were hooking the CSTIC handler. So this is basically an exception handler. I mean, there's a, there's a, there's a bunch of function inside of the hardware inside of the system. It needed. It's kind of like a time, time slice. So this one will just help you to count the time, right? So this is a, this is a, I mean all of these computers, all of this embedded system we just use, we just use a function like this. So we, so this is our main target. And after we do that, I mean the normal function, we just keep it original. It's not, I mean we didn't, we didn't harm the integrity of this firmware. So how to trigger this charging? I mean, you can, it can be just considered that we have two part of the firmware. The first part of the firmware is the original part of the jet ink. It can do the debug probe. It can do all of the things. This is what you do for the 800 bucks. But if we, and another part is the bad USB. This part of the function, it will be executed in some times. And it will just inject a bunch of code into your computer. And actually like the USB, USB, like USB device, like your keyboard, like your mouse, it can do everything, right? Just basically it's a human. So we have two part of the firmware. And we hook the time interrupt entry. So we do this by the, hooking the function firmware that inter, that which is the, which is the system handler. It's a previous slice. So the, the rest of the thing is, I mean the rest of the thing we need to do is like the first step is we try to compile this bad USB code. The second step is we try to hook this critical function. And once this critical function is executed, okay, then we can just execute our firmware. I mean, it's a bad USB stuff. And also the jet ink will just act as pretty normal. You can just use this to download, to debug everything else. I mean, it doesn't matter. But suddenly it becomes a bad person. I'm sorry. So this is the details of our attack implementation. And so you can, so you can see the first step is of course the power up, right? Of course this is after we download our firmware into this hardware. So the first thing, I mean, it's just a power up. And we also, we don't want to make our code run a bit executed, you know, in the beginning of this power up procedure. I mean, we want to be executed, we want it to be executed in some certain time. So nobody will just be noticed. So we put an attack flag inside. I mean, remember the sys tick? So this is basically some, like the time counter. So we set up a, we set up a time counter and we told them, okay, when this, if this jet ink is powered like, you know, five minutes, then our, then our charging will be executed. This sounds like more reliable when, when we just put a jump inside of the, I mean, in the beginning of the firmware and to do all this better stuff, I mean, too obvious. Somebody will just notice, okay, I just plug in this and my computer is, my computer is doomed. Nobody won't like that. So that's why we choose this critical function, system function as our whole function and we choose time counter as our attack method. So, so in this video, we can show you, this is the demo of our beta USB. And so this is the code, this is the, this is the original code of the beta USB and you can see right now we are trying to compile all of this into a firmware and we download into the jet ink, official jet ink stuff. So, right, download and we left our computer right over there and left it wrong. So you can see, now this is no man touching the, touching our computer and it's just open a DEF CON website. So imagine that it can just open everything. Just steal stuff like a personal account or download the firmware into your computer and execute it and you can be noticed. So, actually, as we mentioned before, this is not actually an XP chip, it's an XP chip support. I mean, this is because we have debug function inside of our protection. So this is basically, this is basically accelerate some hackers try to attack, try to attack your production. This is to help them to lower the, lower the difficulty. So all, basically all of this Cortex-M3 Cortex-M4 of XP series chip, they have the same FPB function, I'm sorry, same FPB unit. So you can just leverage it or you can say, you can say just exploit this into a malicious function. So, but also there's some other vendors also have the chip that provide the UI features. So you can also clone their product or you can also implement hardware charging inside of their production. You can, I mean, I mean, in an old fashioned way, if we want to implement hardware charging, we need to analyze the hardware, we need to analyze the firmware and we try to implement all of this inside. But with this, we can just use FPB to hook a function to patch some stuff. This will be much easier. And somebody was, I just want to say, is there any mitigation measure? And of course, the first step is never leak your firmware. If you don't have, if nobody can get your firmware, of course they can't, they can't do this. I mean, what's the point, right? You have, you don't have the firmware and you give them a bunch of hardware and tell them, you can, okay, you're gonna do this. Nobody will use that. So also the second one is what we suggested for the XP chip. So basically, I'm sorry, for the jetting enterprise. So basically there was just a disable the FPB function before they call the critical API. So I mean, it's, it's not a sufficient, it's actually not a sufficient kind of measure. But it's much harder for the hackers to try to do stuff like what we done before. Also we, also you can just patch the firmware to, you know, there's a blank, there's a bunch of blank flash regions of the firmware. So you can just patch this firmware to set all this blank flash area to a specific value. So for example, you can just use instruction like the BL reset handler. That means if the, if the code, if the blank flash region was, was being excluded, they would just directly jump back into the, back into the beginning so it's not usable anymore. So also you should always verify the signature of the entire flash instead of just just a piece of code. It's totally not secure, right? It's a, I mean, it's just a little giant blank hole and let us set, and total answer, okay, you can take it to it. It's, I mean, so we also receive the advice from the P-3rd of the XP. I mean, it's a, it's a, it's also a security group of the XP. So there was just the enterprise who, all the companies who were willing to use their XP chip that is, enable the code rate protection. I mean, the code rate protection setting has three levels. There is a level one, level two, and level three. I mean, level one and level two, there's only, it just disables the JTAG. You can also use the, leverage the ISP to do the better stuff like what we have done before. But if you enable the level three, yes, you can't use JTAG. You can't use ISP. I mean, you can, this chip is, is not reprogrammable. But, but that also means if your production has something wrong, and it ships a ton of thousands of stuff like to the, to the users, to the end point, and if something wrong, then you were doomed. All of this will be refunded, and your company will be broke. So the kind of matters is like, it's not a good idea to put in critical, to put a critical API into the address reason that can be remapped. I mean, it's just the, the name is called like a flash patch and the break one. That also means it can only, I mean, only the, only the flash region can be remapped. So nothing else. So you can just put it in some critical register or some higher address. That'll be, that'll be much better. So we can recommend this SOC vendor to just prohibit reading, remapping all of this wrong API in the subsequent product. I mean, if you just ship it, if you ship it before it, it can be recalled, right? This is much harder. So this is a reference of our product, I mean, our work. So you can see the principle is much, is pretty easy, but you can do a lot of better stuff to do this. So thanks, and thanks, thanks guys. So if you have any questions, you can just ask me right now.