 Thanks. Thanks for attending our talk. Uh, today we'll share about how we exploit the COCOMW line and the modem all the way, all the air. And finally compromise the NINAS kernel. Uh, about us, uh, we are the, uh, security researchers from the Tencent and Blade team. Uh, Tencent and Blade team, uh, is founded by the Tencent and the security platform department in 2017. Uh, we focus on, uh, security research in the areas of AIOT, mobile devices, cloud visualization, blockchain and ATC. Uh, this is the agenda. Uh, firstly we'll introduce some, uh, related works. Uh, we know that, uh, WLAN security is a hot topic in recent years. Uh, the norm you exploit on Broadcom Wi-Fi ship is on 2017 and this year on our, today our talk is about COCOM. As we know, uh, there is no public exploit on COCOM Wi-Fi ship, so how secure is the COCOM Wi-Fi? There is a simple, uh, illustration about the architecture of COCOM Wi-Fi. Uh, there are two important things. Uh, the first one is that, uh, start from Snapdragon 835. The WLAN firmware is integrated into the baseband subsystem. So the WLAN and the modern firmware are wrong in the same processor now. The second thing is that you can see, uh, in COCOM's, uh, implementation, most of the functionality is implemented in the NINAS kernel driver named QCA CLD. Uh, there are plenty of vulnerabilities in this driver. That is the well-known WLAN host vulnerabilities. Our talk is not about the WLAN host issues, it is about the WLAN firmware itself. Uh, we know that, uh, there is no public talk on the COCOM WLAN firmware previously, so how about the security status? Uh, we will answer this question. Before we go into the details of WLAN and, uh, modern firmware, we need to reduce the debugger we use to debug the firmware. This is the key step for us to analyze the modern and the WLAN. Uh, there are, uh, modern bot authenticator and the modern images in file system. You can see, uh, mba.mbn is the mba image, modem.mdt and modem.bxx uh, modem images. These images have a specific format according to COCOM's official document. Like, uh, application processor, modem processor also has its secure boot flow. The flow is like this. Uh, firstly, NINX kernel will load mba and, uh, modem images from file system to physical memory. The second, uh, uh, NINX kernel will set the start physical address of mba and reset the modem processor. Modem pbl in rom will verify the mba image. If success, it will jump to the mba code. Finally, mba will read and verify modem images. If, if success, it will jump to the modem main code. Uh, the pure boot function in NINX kernel describes the boot flow of modem. Uh, it will load, uh, mba and modem images to physical memory and then check mba and modem images to be verified and executed in modem processor. NINX kernel can restart the modem processor at any time. And it will hit pure boot function each time when restart. Uh, the modem bt we use to bypass, uh, the modem secure boot is a time of check, time of use back. When mba verifying modem images, it doesn't lock the physical memory region. Means that NINX kernel still can modify the modem images. So after mba verified one image, NINX kernel can still modify it, which means that we have bypassed the secure boot check. Uh, the port code for the, the only meaning is quite simple. There is the, uh, def, def file of pure boot function. We just let the, uh, pure recline main function after we modify modem images. Uh, after we have ability to modify the modem images, we can inject debug server to modem side. Uh, we injected, uh, demonstrated to, we did for commands from NINX side. The commands and the results will be exchanged using shared physical memory. Uh, we now can, uh, issue debug commands to debug WLAN and modem firmware. Uh, now we have the, uh, debugger. We can analyze the modem and WLAN firmware much easier. And, uh, she will introduce the following details. I'm going to introduce the reverse engine alien and the vulnerability and exploitation of WLAN. And finally, we'll get into the NINX kernel. Okay. Next, we use the architecture of Qualcomm WLAN. Uh, the WLAN is now in the business band of Switzerland. And it's hexagon architecture, a lot of octagon architecture. So we can analyze it and if we control the WLAN, we have actually controlled the base band subsystem. Okay. Uh, here is a simple figure for the WLAN architecture. Uh, from the figure, we can see that Qualcomm WLAN is not a full mark firmware. Most of the functions of WLAN, WLAN, uh, implemented in the NINX driver. You can see here in the QCAC driver. Okay. That's leading to a smaller attack surface than the other windows. The work to be done here, you know, from where you'll call the offloader. You see the offloader mic layer. Uh, the module attack surface here in the offload handler. The offload handler is actually, uh, a table, a function table. And if you inspect the OTA package and if you interested in, you'll pass the package and do, and do some job. So the attack would happen here, uh, when the offloader handler handle the package. So you can analyze it. Okay. Give an example for how the Wi-Fi access point is displayed on the Wi-Fi list. Right? If you, uh, turn on the Wi-Fi, you'll see a list of the access point. Okay. Actually, when you turn, turn on the Wi-Fi, the Android firmware will, if you command to the driver, and the driver will command the firmware to scan the nearby Wi-Fi hotspot. Finally, the firmware will be used to handle us into the handle table. When the other hotspot or access point send the package. Yes, if you have a, uh, access point, it will send out the beacons and other packages. So our handle will receive, receive the data and pass it. If you, into the management become, it will transfer it into the driver. And finally, we'll notify the, uh, user space application so that you can see the SSID and, uh, other informations. Okay. Okay. So now we have some basic things about the Qualcomm WLAN. Uh, let's start the reverse engineering. Uh, this is the firmware load by modern. Uh, this is the WLAN firmware. It will load by modern from this position and this is the distance simpler. And this is the wonderful SDK, uh, provided by Qualcomm. And, uh, instruction reference for the hexagon architecture. Okay. Okay. So, uh, the WLAN firmware has more than 8000 functions. It's a difficult task to reverse these functions without any knowledge. Uh, likely Qualcomm have got some hint. You can see the most useful thing is the string table. Uh, we can find a lot of function names. And, uh, the other thing is the import function because the WLAN firmware will load, load by the modern as a shared library. So the WLAN use, use a lot of functions from the modern and they leave the function names in the import function table. Quite useful. The string table and the import function. Okay. The target we are going to reverse engineering is the off-road handler. Uh, the module tag surface is the off-road handler. So the question is how to find the handler table? Uh, the answer is that you can first find the string from the string table, uh, that is this string, uh, non-data off-roader. And then check the reference of the string to find the function name and find the function named the non-data handler. Uh, you can see this is, this is a bigger function. Actually it's a, it's a big loop and fetch the address in the handler table and then call the functions to do the job. Okay. So this is the, uh, module tag surface. You can find the table here and find the functions. Uh, this is a sample function. One of the functions looks like this. The most important thing is to find the data pointer. If you send the data, uh, if you want to tag the W line, you first send the data. So how to find the data, the data flow. This is the entry, the one of the handler. You can see here, this is the data pointer. Uh, all cases 5B, 5A, 5-line, 5-8. This is the data pointer. So you find this function and find the data pointer. And analyze the function and the first source of the, uh, uh, data pointer then you know how, what is the function doing and handle vulnerabilities. Okay. Uh, I think this is the most important study in this, this talk. You can find the function and find the data and the handle vulnerability that you want. Okay. Okay. So let's start the exploitation. Uh, this is a load map. Uh, we are here. We can send out some signals using the Wi-Fi dango or something else. Uh, we are here. We can send out the signals, Wi-Fi signals and we are going to compromise the W line. And then we are escape into modern and finally, uh, we are into the linear kernel. Okay. To compromise the four, four linear kernel. Okay. So, before we go, let's check the uh, medication status of WN to set up an exploitation strategy. Okay. From the medication table, we can see that there are lots of medications. Uh, for example, the heap, heap have ASLR. The address of the heap is not a pixel. And the heap have practically heap cookie. So, uh, the overflow on the heap is very difficult to exploit. And also, there are DEP. Uh, you are unable to jump into the data segment. Uh, also you are unable to write to the code segment directly. If you want to do so, you have to change the memory attribution. Okay. Also, there are frame limit, frame limit to protect the SP. The frame key to protect, protect the return address. Uh, so, uh, if you wanted to use some technical like ROP, ROP, it doesn't work because the protection here. Mm-hmm. But we are very lucky. The code ASLR is not enabled. So the code address is fixed. And the CFI is not enabled. So, if we, uh, although we cannot use ROP, we can use something called the, uh, FOP, function oriented programming that is, um, in the, uh, the gadget of the ROP, all the gadget are used, uh, uh, function core, not a return core. Uh, return is a function core that is function oriented programming. Okay. And we are also very lucky. The issue we found in the global data area that is here is also low ASLR. So the address of the data is also fixed. Okay. We know the address of the data, the water around the data address. Okay. Let's see the detail of the vulnerability. Uh, it's a CVE 2019 10540. Okay. This issue has already been announced in the Android and the Qualcomm August security briefing and uh, has been patched. So if you are interested in about the detailed information of the vulnerability, please check the security briefing in August 29th. Okay. Uh, this issue has been fixed already. Uh, uh, this issue is in one of the offload handler. Uh, you, you remember this table, the offload table, there are lots of functions, uh, called offload handler. One of the handler has a problem and it's a pre-ass friend handler, uh, handler, or he, uh, what is pre-ass? Uh, pre-ass means you don't have to connect to a specified access point. You don't have to connect to, connect to a whole, whole support. You just turn on the Wi-Fi, the, then the, um, phone is one level. Okay. It's a pre-ass vulnerability. Okay. Uh, this is uh, uh, vulnerability code. I will transfer, transfer the data into the C code. Uh, this is, this is just forward. You can see this loop. And uh, uh, this low checker about the length and your copy and the amount of data into the, uh, destination, uh, your copy copy. So, uh, endless loop if you have ER for data. Okay. This is uh, vulnerability. Okay. Uh, mm-hmm. Okay. So, let's check the data around the overflow address. You can see, it will overflow from here, global buffer. And uh, uh, if you want to into a copy, all case, 44 data into each item. From here, the group of buffer into here, you can see 44 bytes of data. 44, 44, uh, it's a loop. Okay. You know, this is a loop. Okay. You see the global buffer in the global study area. So the address we, we are already low. Because there is no SLR, the mid-tech table, you remember. There is no SLR. So we know the address of the overflow data. So, it's very convenient for us to exploit. Okay. We can analyze the data around the overflow address. We can analyze the data here. And uh, uh, quickly we can find out the after set a C. This is a very useful data. It's a very useful function, uh, data pointer, pointer to, uh, something we can, uh, need to do some useful job. We call it the smart pointer. Using the vulnerability, we can overwrite this smart pointer, over, overwrite the content of this pointer. Okay. See how we use the smart pointer. We can send out a package and uh, goes into this, this is code flow to use the overwrite data. You can see, this is a smart pointer. We overwrite it. So we can, we can change it to our determination we are interested in. And uh, if we call into this code flow, finally we will overwrite these two bytes, uh, actually these three bytes, C, D and 14. We overwrite these three bytes. Okay. Let's see the detail. We overwrite the smart pointer using the vulnerability. And it will, uh, have two tests. The first test is to test our determination equal to one. And the second test is to test the smart pointer plus six equal to the mark address of the sender. And finally if the two tests are passed, it will write to the, uh, three bytes using the data from the OTA package. Uh, this is uh, the data we control and the sender. And the mark address is also we control and the sender. So the only constraint is that if we pass this, this, this check, we can write arbitrary code to the destination we are interested in. So we can overwrite something like a function point, a data point or other thing we are interested in to do the job. Okay. So we have a, uh, global write, write the primitive. So we can write it to anywhere we want if we can bypass this check. Okay. For example, uh, we overwrite the smart pointer to this address X, X, X. And the notice the bit is one. So we can bypass the check here. Uh, we can bypass the check here. Okay. And then we can write it to the offset of C. Uh, 56, 7, 8. We can see here. We can write C and D. That is uh, uh, 6, uh, 5, 6, 7, 8. We can write it to here. So we can write here. We can use, we call it the primitive global write with constraint. Okay. We can write it to anywhere if the notice the bit is one setup. So, uh, meaningful address or data is always four bytes. So how to write four bytes? The answer is quite simple. We just use the right choice. The first time on the node who writes, you know, the 5, 6, 7, 8. And the sixth time we move, move the smart pointer forward offset by two. And this one, this bit is, this bit is still R1. We can write 1, 2, 3, 4. Then 1, 2, 3, 4, 5, 6, 7, 8. Uh, 8. Uh, that is 4 bytes. And there is still another problem. You see, we want to write it to here. Um, 5, 6, and uh, the problem is this bit is not, not equal to 1. So how to solve this problem? You can set it up, set it up. And if this is 1, then we can use the global right to modify this, this, this bit. Okay? We can set up, set up it to 1. Then we can write to the target. So, this is the, this is the view. So, for this complex figure, actually, we want to control the PC and R0. R0, we have, uh, 8 bytes. The first 4 bytes is the PC. And the, uh, second is R0. But we search up from, on the memory and find this place that we can writeable and reachable by our remote packet. Okay? Then, you see, there are a lot of one, a lot of one. We can move, move the smart point forward. Move on, move on, move on. And then we can overwrite the target PC and R0. Okay? So, we have controlled the PC and R0. Uh, we can, um, we can then run some FOP to do some complex job, such as to run into the, uh, FOP and uh, mapping the WX page. This is to map some page to, uh, modify the code segment. And for example, uh, this is a code segment B-0-0 and, uh, uh, originally my phone from 9-3-6, uh, we wanted to, want to write the code segment. So, we, using the FOP to, uh, map it to 4-2-4-2, uh, using this FOP. So, now we can, uh, write to the code segment. And, uh, we can write to, we have a habitual write. So, we can copy, copy our shell code into the, into the code space and trigger it. You can see, we copy the shell code. The shell code is originally in the data package. So, we copy the data package of data into the destination. That is 4-2-4-2. Then, we trigger, trigger this function. Okay. So, now, we have running our arbitrary code in the WLAN. Actually, we have now in the WLAN, okay, we are going to the modem. The WLAN in the different process in the base binary modem. You can see the corner in the Q, U, R, T, O, S and the WLAN and the modem in the process in the running in the USB space. So, how to get into the WLAN, uh, uh, into the modem from the WLAN. There are dangerous actions such as modify the code segment and write, uh, modem data or call complex functions. Uh, but uh, uh, all illegal. If you, if you call, uh, if you do these dangerous actions, the base binary subsystem, you are crashing. Okay. But you remember, you can map memory. So, how about we map the modem memory directly into the WLAN. Okay. Just like this, we map the modem, um, memory from on the WLAN. Okay. It's a memory map. We just map the physical memory into the WLAN virtual address and then we can modify the memory content. Okay. So, we can modify the code of the modem. So, we are control the modem. So, the last step is to escape from the modem into the Linux kernel. This is the little map we are going to do. Okay. There are a lot of attack surfaces. So, if you are interested, you can read the value paper for detailed information. Okay. This is the issue, uh, the 3E, uh, 2019 and 10538, which has already been fixed in August, I'm just, I'm just, I'm just going to do the security bleeding. Uh, you can see, there is a check from the data pack, coming from the modem. Okay. Uh, what's this doing? Uh, actually it's about the memory management of co-com multiprocessor. Uh, it's a very big topic, in fact, about, about memory management. So, it's a simplified, true figure. Uh, there are two things you need to know. The first thing is, uh, the Linux master model. That means the whole system, uh, the memory of the whole system is managed by the Linux kernel. Uh, so, the peripherals such as Venus, modern, WLAN, or Bluetooth, other peripherals of system, the memory is all managed by the, by the Linux kernel. And the Linux kernel will use the SMM, MAU to, or protect the memory. For example, if the modem owns, owns this, this memory, uh, every time, and other, other peripherals such as Venus visit to this D-RUN, the SMM, MAU will check the, uh, permission and, uh, find out that the Venus doesn't have this, this permission and then the whole system is done. So, this is the two things you remember is the Linux, uh, Linux master model and SMM, MAU to protect the, uh, memory. So, the problem is here. Uh, in fact, it is, uh, a mystery log, logical. Generally, Linux will decide the address and decide to, uh, assign to other peripherals of, South-Sistam. But here, you can see the address and the size are determined by the modem. Uh, we don't know why, but if, if the modem send out the address to Linux, then Linux will use this address directly and use the size directly. So, uh, if we, we set the address to the code address of Linux, so the address will be, uh, the, so the address will be mapped into modem and then modem can modify the code address of the Linux kernel. That is the issue. Okay. So, now we are actually in the, in the Linux kernel. So, we are going to talk about how to send out the payload. Uh, actually, uh, before we are using the SCAPI and, uh, Wi-Fi dango, but it's not, not very stable. So, finally, we are using a pixel tool to send out the payload and using a pixel tool to attack the pixel tool XL. So, you can see the pixel tool send out the Wi-Fi payload and then pixel tool XL, we are receiving the payload and, uh, being a compromise. Okay. This is the whole roadmap. We are using a pixel tool, send out this and finally, we, from modem into the Linux kernel. Okay. Into WLAN, into modem, into Linux kernel. Uh, let's use some demo here. Uh, can you see? Okay. Uh, this is on the left is the pixel, pixel tool. Uh, it is, it is sending out, uh, packages, sending out the payload to attack the, the left is the pixel tool XL. Okay. You can see it's a version of the system. So, the whole process is about three minutes. Can see. Uh, now we are, we are in the shell and the, uh, the SC Linux is enforcing. So, we have no permission to do the, uh, dangerous things, such as the D-message. Okay. So, it's still sending out the payload, payload and, uh, let's, let's speed up, speed up, speed up. So, the SC Linux is still enforcing, you know, enforcing. So, the pixel tool is still sending out the payload. Okay. It's, it's about three minutes. It's probably done. Okay. Can see. I wait for about one minute. You can see. Finally, we have get into the Linux kernel and disable the SC Linux. So, uh, now. Okay. You can use the D-message. So, actually we are running a bitually called in the Linux kernel from the remote WM. Okay. So, time is up and, uh, please note this, this issues are already been fixed in the August, the briefing and the pack. Uh, you can see the detailed information here. And today we talk about how to remotely into the kernel from the OTA pack into WM and the modern, the four, four chain and the vulnerability and the exploitations and the baseband subsistence. So, thanks very much for your time. Thanks very much. Okay.