 we have Dennis here. He just gave a talk at a main track and this is a continuation of his talk where he's going to do a quick review and then he's going to get into some of the stuff with the Xiaomi firmware and the ARM Cortex-M. I said that in a weird order. Sorry for my Yoda. All right, and with that, are you ready? Awesome. Here's Dennis. So, yeah, thank you. So who are a few have been actually in the Flamingo and saw the ever talk? Oh, okay. So I'm sorry the first 10 slides might be a little bit, you know, like coming, might be a little bit similar to the main track, but yeah, I mean I tried to get quickly over that. So the outline for the talk would be like the following. So I give you a short motivation, give you an introduction to the Xiaomi cloud and then we go to the devices and now the important part comes the step by step binary patching. Some information about me. I'm a researcher at an official university in Boston and I'm working with Professor Gewaerner Bier. I'm also a grad student at the TU Darmstadt in Germany and working there with the Zmolab. The main stuff what I do at the moment is I do reverse engineering of interesting devices, interesting devices in terms of devices which I can use in my home, for example, or use on me. So IoT at the moment is very interesting for me, smart locks and as a lock-paker, of course, also physical locks. Okay, let's start with your motivation. So why do we reverse IoT? And this is like more or less depending on like the so-called attacker model. Some people do that to find and exploit vulnerabilities to hack other people, but the more interesting stuff for me is I want to give you the possibility to disconnect your devices from the vendor's cloud. They have been like a very famous incident I think in May this year where the company Yee-Link just disconnects all the European users of the LADBOPS, by the way, just this company, disconnected all the European users of the LADBOPS because they thought like, yeah, the GDPR is risky for us because we're collecting a lot of data, so we just kill it like for all the people from Europe out of our cloud, which make all the LADBOPS in Europe more or less useless. But like two weeks later, they created like a European cloud, especially for the European users, so now it's okay again, but the thing is like it shows us that IoT devices are strongly relying on the vendor. Another thing is we want to get more functionality, for example, adding new features or localization. Devices like the smart home gateway speak Chinese, I don't, so it would be better if it would speak English or German or whatever. Another thing is also geo-blocking. Some of the devices are only working in specific countries, so if you try to connect specific IP cameras like in U.S., they won't work because they rely on Chinese servers which block U.S. IP addresses. So to avoid that, you need to do reverse engineering there. So how this whole thing started? In May 2017, I started with Daniel Wigema, and he is sitting in the front row here, and with the vacuum cleaning robots and the Xiaomi Mi Band, which is a smartwatch like this, which is also from Xiaomi, and we continue to work on the smart home gateway, the LADBOPS, mostly all the stuff that you see in the front of me, but even more, so over the time, a lot of devices were coming around. Okay, so how about the Xiaomi cloud? Xiaomi claims actually to have the biggest IoT ecosystem worldwide, so way bigger than Google or Samsung. They have over 85 million devices and 800 different models. The most interesting model that I saw so far is a smart toilet seat, actually, which has Wi-Fi and Bluetooth and can recognize the person who's sitting on it and setting up the temperature and making some lightning stuff. If you buy a product which is working with the Xiaomi cloud, then the chances are very high, but it's actually not produced by Xiaomi, but by a third party vendor. So what the cloud ecosystem is doing, it connects different vendors in one ecosystem, and all the devices are using the same protocol. This cloud system also supports different technologies, and for us as a risk engineer, the most important thing is the implementation is different from manufacturer to manufacturer. So if you see a device which is like super secure and they have all the stuff enabled like secure boot and so on, doesn't mean that it has to be the same case for all the other devices which are in the same ecosystem. Also the software quality is very, very different, so you see sometimes very stupid things, the best thing that I saw is like some file which was copied from Stack Overflow or something with some example for a batch script, so you see everything there. So this is some overview about the clouds. So what we see here is the main three technologies which we use, Wi-Fi, Bluetooth LLE and ZigBee, and the central component if you have this kind of devices, it's your smartphone actually. So on your smartphone you usually have the Mi Home app installed, and the Mi Home app is making sure that the devices get their initial setup. So you enter your Wi-Fi credentials in your smartphone, then your smartphone is talking to the IoT devices, and as soon as this is done they create their own connection to the internet. So after that they connect it directly to the internet without like the smartphone. So you can walk around with your smartphone, but the devices have still a connection. So in next step I take a look at the cloud protocol for the device to cloud communication. To connect to the cloud you need two credentials, and the one credential is the device ID, which is unique pair device. For the Wi-Fi devices it's like an 8-digit number. For the other devices it depends, for ZigBee devices it's I think some MAC address for the Bluetooth devices is also some number. And there are two kinds of keys. There's a cloud key. This is used for the cloud communication, so device to cloud communication, and this key is also static. For most of these devices it's burnt into the one-time programmable memory, so you cannot change it yourself. Every time you boot up the device it gets loaded from the one-time programmable memory, and if you do updates, if you do provisioning and so on, it always stays the same. For the token it's a little bit different. This is used for the app to device communication. For example, if you want to control the vacuum cleaning robot in your local network, it's a little bit time critical, so you don't want to wait like one second for the command to go over the cloud, so you can speak also directly with the device. And for that they use also a key, which is dynamic. That means every time you connect it to a new Wi-Fi this key gets regenerated, so it's a different key, like every time you create, for example, a new Wi-Fi or if you provision it newly. The payload itself, this protocol can speak TCP and UDP depending on what you block. So if you block TCP, then it just will happily talk over UDP, and this is how it looks like. The payload is encrypted, and the encryption key is more or less depending if you're speaking with the app or if you're speaking with the cloud. The important thing here is if you have an unprovisioned device, which you take just fresh off the packet or you have done a factory research, then the device tell you the token, which is like the second secret key, in the checksum field. So this is required that your smartphone is able to provision the device. As you see here, they do some integrity thing. This is so the checksum is also protected with the key and all the other stuff is encrypted with AES. One interesting thing here is we have this epoch timer, maybe I see it here. This thing here, which is a UNIX timestamp, and this is also used for time synchronization, because usually if you boot up a device when it doesn't have time, so over this thing, they can also synchronize the time. The protocol itself is JSON for method messages, and every packet is more or less identifiable with a packet ID, and you have two different structures, more or less, methods and parameters. This could be like commands or results. For example, if the cloud asks you something, when you send a result to the cloud, or like the vice versa. The thing here is every command and response is confirmed by the receiver. So you always make sure that the command has actually reached. I have here one example for such a command. This is the actual login, more or less, of the device to the cloud. So what happens here is if you see here, it tells the cloud which kind of Wi-Fi you have, which is the SSID of your Wi-Fi access point, what's the local IP address, and so on. For example, also the version number. So let's take a look at how these devices do their updates, and there are three different methods how they can do firmware updates. There's one thing where they can do app updates, which is the main software, more or less. So the cloud tells the device, hey, here's the firmware update under this URL, and the ND5 checks them, but you should expect us like this. The second kind of updates are MCU or Wi-Fi updates, in case of like some devices that's for example the firmware for the ZigBee part. Here is also telling like, here's the URL where you get the firmware update, but they have no integrity checks. So basically we don't tell the device what kind of ND5 has to be expected. So if you change anything there, like for example, you modify the firmware, why it gets downloaded to the device, they have no way to figure out that something was going wrong. And there's also sub-device updates. For example, if you have this smoke detector, it gets updated over ZigBee over the gateway. Then it's more or less the same thing. Instead, they have an additional checksum, which is the CRC32. They give you also the ND5, but the ND5 is actually never checked. So the protection for this kind of firmware is CRC32, which is, who thinks it's safe? Okay. So one example for communication relation here is between the light bulb and the cloud. So this is just to illustrate again, the light bulb itself connects directly to the cloud and have their own, all the stuff encrypted, but it can also connect over your smartphone. And the keys are different, of course, in terms of, it depends on the communication. Okay. So how we can disconnect these things from the Big Bad Xiaomi cloud? And for this, we developed last year a software which is called DustCloud, which acts more or less as a proxy. And this is the way how it works. So basically, it is in the middle of the communication between the device and the cloud and can act as, has different modes for it in this case. The exact modes are the following. You can use the DustCloud as a proxy. So what happens here is it takes the commands which are coming from the device to the cloud and forwards them to the cloud. Or you can just use it as an endpoint. So the commands are not forwarded to the cloud. The device thinks that it's a legit Xiaomi cloud. So it's a perfect emulation of that. You can read the traffic in plain text so you know what's going on, which data is sent to the cloud. You might even send your own commands to the device. For example, if you want to do firmware updates, switch on the lights, switch off the light. And the things what you can do also is like you can change and suppress messages which are coming from the cloud or going to the cloud. One interesting question here is, for example, if you do firmware updates and the cloud wants to push firmware updates onto your device, you can just block it or it can just change the URL or the MD5 checks for your firmware. To make the DustCloud work, you need a few things. And the first thing you need is the device ID. Then you need the cloud key so to be able to decrypt the traffic or to create the traffic. And then you need to do the DNS direction so that the whole traffic is like coming actually to your DustCloud. Okay, let's take a quick look at the products. So I'm sorry for the people who wear the other talk, it's like the same slide. If you use the Mainland China server on your smartphone, which most of the people do because the server supports most of the devices, then your smartphone supports 260 different models of devices. And this device could be Wi-Fi, ZikB, Bluetooth Ali or even combinations of that. And so this 260 are more or less depending on your server location. If you are coming from Taiwan and using the Taiwanese server, then it's like less than 100. If you are in U.S., it's a thing like 20, 25. The thing here is the models are not always compatible. So I have a rice cooker which I bought in Taiwan like two weeks ago. And I cannot connect it directly to the Chinese cloud. So I have to modify a few things because they make sure that you stay in the regions. Like I said, not all the products which are actually sold for the Xiaomi cloud are actually from Xiaomi. So this is like, I mean, this is not very official. So the thing is I just found it out by configuration files. So that most of the products are actually by the company Lumie, which are producing all kinds of different sensors like smoke detector, motion detector and so on. And also the gate base. Xiaomi itself has only 11% and most of the time they are like the Wi-Fi routers. Then we have also Yeelink, which is making like all the lightning stuff. One important information here is in this cloud, the smartphones are not connected. So basically if you have a smartphone from Xiaomi, it's not connecting to this cloud. It's like a complete different system. So we're connecting here only the stuff, everything which is like smart home in your like fridge and so on. It's not the smartphones. Okay. So now you might ask, okay, about how many devices I can you give you actually any information. And from the student 6C models I have actually 42. And my inventory is more or less 99 devices, which I bought myself for using or was engineering. Okay, let's talk about the architectures which I use usually in this kind of IoT devices. We have the Cortex-A CPUs, which are more or less the same stuff which you have in your smartphone or Raspberry Pi for example. Then you have the Cortex-M's, which are embedded devices and they are like two flavors, the one which have like Wi-Fi. So if you have a device which has only Wi-Fi, then it's very likely that it's a Marvel chip. If you have devices which can do both things like Wi-Fi and produce early, then it's very likely that you have a media tech chip. There's also a thing called MIPS, which are mostly used in IP cameras or in some routers and extensor, which some of you might know as ESP8266 or ESP32. And the focus of this talk will be more or less this. If you want to know more about the Cortex-A CPUs when you need to watch the recording of my other talk. There's one good news. I mean, we have a lot of vendors, but there's one good news and vendors are always lazy. So after looking at a lot of firmware's, what I assume what the development process is looking like, they're just taking the SDK or tool chain from the chip vendor. In this case, for example, Marvel. They add some SDK which is coming from Xiaomi. And they're just looking for an example which fits the best. For example, okay, we want to switch on the light and or switch off the light. So we need to control GPIO. So in this case somewhere, there's an example like, okay, how to switch on a GPIO. So we're taking this example, change a little bit the source code, compile it, it runs, publish a firmware. So the good thing about that is all the firmware's are more or similar. The memory layout, the functions, the strings. If you know one of them, then it's very likely that you know, that you get a better impression about the others as soon as you see the others. So with one point which I always love to talk about, why I hate ESP8266. Every time I buy a device and I see the following, I open the device and I see it's ESP controller, I'm always very, very sad. And the reason is the following. This extensor architecture is like a very weird architecture. It's like difficult to reverse engineer, not because it's secure, but the thing is, it's very hard to find a decompiler for that. I don't know if actually any decompiler is existing. This assembler support is also very limited. So there's a community plugin I think for IDA, but that's all. And most of the time you can't really use JTEC because the GPIOs are reused for other stuff. And I think the JTEC support is actually not existing more or less. The good news is it's very easy to replace the firmware. And there are two reasons. You have most of the time you have some connections. In this case you can connect to the serial or you have the pins which you need to ground to make it more or less slow to firmware. So the people here who worked with ESP8266 probably know that. And the other thing is speaking about updates, you can push the update over UART or you can just create your own OTA update. And the reason here is we don't use SSL and they transmit their unencrypted firmware over HTTP. And they don't check for the MD5. So, wow. Yeah. But reverse engineering of that stuff is not making a lot of funds. So this is like a desk lamp that they have from e-link and you have to sort of stuff and yeah, not so nice. There's one thing. If someone of you knows how to reverse engineer ESP8266 firmware and can show me and it works for me, you can win this very nice light bulb, smart light bulb which is not in ESP, I promise. So if anyone knows that, then come to me and you can get this very nice light bulb. Okay. Let's start with our devices. So here we're talking about the smart home gateway, the loud bulbs and all the added D strips. I put it in one group because they have the same processor, they have the same chip, they have the same layout so it's quite easy to work on them. So to remind you, these are the devices, for example, so they have the Wi-Fi connection directly and if you take a look at the hardware, we see the following. So we have a Marvel CPU which is a Cortex-M4F with 200 megahertz. We have a little bit of RAM, like 512 kilobyte of RAM. And depending on the device which we have, the light bulbs for example have 4 megabyte of SPI flash and the gateway has 16. All of them have Wi-Fi core and for all of them, the device ID and the key is stored in the one fingerprint memory. So if you dump the flash memory, the SPI flash for example, you don't get the key because it's on the chip. Especially for the gateway is that it has an NXP ZigBee chip. So this is like a special different controller on the device which takes care of all the ZigBee stuff. Okay, so this is like also an overview about the chip itself. So what you see, so an interesting thing here is more or less that this Marvel CPU has two ARM cores more or less. So you see one, it's the Cortex-M4F which has also this communication processor which takes care of all, like for example, Wi-Fi and so on. For the gateway, the question is okay, what kind of ZigBee devices you can connect to that and from Xiaomi, or like from the Xiaomi cloud where like a lot of devices are available. For example, door sensors, temperature sensors, power plugs, motion, detector sensors, buttons. One of my favorites is also the smoke detector which is always a thing like, hey, let's put security related, safety related devices into the cloud, what can possibly go wrong. Or like some smart door locks. Okay, so let's get a little bit more technical. So if you taking a look at the partition table of the gateway for example, you will see that they have the typical thing what nearly all of the IoT providers do. They have multiple copies of the operation system. So basically here, the application firmware, this FW is existing twice. The Wi-Fi firmware is also existing twice. And you have a boot sector and some partition which holds all the config variables. Right. Oh yeah, so the important information here is also that if you have a firmware update, it's actually the image of one partition. So if you do a firmware update, then it's just overwrites complete partitions. It doesn't replace single files because there's no files available, but it just completely replaces the partition. So, how we can get the keys? It depends a little bit on the device. So for the smart home gateway, which I have actually open here, so if you want to take a look later, it has a lot of test points and it has SWD enabled by default. If you ever have this kind of device, then here is the layout of the pins. We have SWD, we have a serial port there, so we can get some information. And the information we can get is actually as soon as the device is running, we can connect over SWD and just dump the whole memory and get the key from there. If you connect over serial, then you can get access to a CLI. And I mean, this is like a long list of commands, but the most important are this one. So you can, if you connect it over serial, you can update the firmware directly without any need to manipulate like manual models or whatever. So you can just send your own server there. So while it's very easy to get access to the gateway, it's a little bit more difficult if you have, for example, a light bulb. And then the question is, hey, can we get access to this thing without a hardware attack? And a hardware attack, what I mean with that is, so the light bulb that you see here in the picture is actually at the end of the day, if you want to extract the chip from there, you have to sort it open because it's like, you know, a little complex to open it. So this is usually the case which you don't want to use after that, after you get access to this device. So what we want to do is we want to get some access on the device without soaring the device open. And the good news here is again, the firmware are not signed, so what we can just do is, hey, just create a modified firmware which gives us the key automatically. Okay. The bonus of that would be we don't need a hardware access, but there's a big problem. And the problem is in a difference, for example, to the vacuum cleaner which runs a complete Ubuntu operation system, this light bulbs have a bare metro as, so basically you have no, so you have just one binary which is running and no like file system where you can change like individual binaries. So we need to patch the binary. Okay. So let's talk about binary patching. So if you have a binary, what happens quite often is that we have some, in our original code, we have some function which is running and at some point you have some for example branch links which are jumping in some other code. Our goal if you want to modify this thing is that we have some patch code and we somehow manipulate this branch link that instead of going to the original code it goes into the patch code. To not break the functionality after that, we want to go back at the end so we want to call the original function after that again. So what does it mean? So we need to modify the program flow, we need to add existing additional code, but the trick here is also we need to use existing functions because all the things which are not present in the firmware we need to bring somehow into the firmware. Okay. So why is binary patching so difficult? Especially for ARM it's the case so as soon as you overwrite branch instructions the new address is more or less dependent on the program counter so you cannot work with fixed addresses in the branch links. Most of the time if you want to modify binaries you need to write new code in assembly which some people can do but I think most of the time it's a little risky especially if you have a light bulb they have only one shot to put your firmware on it. If it crashes then the light bulb is done. Also what you need to do is to model the address space so you need to have some idea what the ram does look like if you want to access the ROM and so on and you need to make sure that you have specific free space for patches later and you need to call existing functions and now the problem is because we have a lot of devices you need to handle different firmware versions and different devices so luckily for us there's a great great tool for that and which is called Nexmon and this takes care of most of this problems. So what's Nexmon? Nexmon was initially developed by Danny Wiegema and Matthias Schultz at the Zemo Labs and at the TU Dammstadt. Danny is also here in the first row so if you have any questions for him he is happy to answer that it's a C-based firmware binary patching framework and it supports Cortex-A and Cortex-M binaries so you not only can modify Cortex-M firmware but you can also modify Cortex-A binaries in your Linux system for example and the main use case of this framework was to modify the full mag Wi-Fi firmware in for example smartphones or like an Raspberry Pi so what you can do with that is you can modify the ARM firmware in your smartphones Wi-Fi chip so for example the idea of that is to enable monitor ports so you can see a Wi-Fi traffic which is not supposed for you or you can do other stuff for our use case we want to use it to modify IoT firmware Nexmon itself is quite black magic so it contains a lot of make files scripts and GCC plugin so this is more than the map what it does for the Wi-Fi firmware but for us we don't need so much so for us the simplified version is absolutely okay the interesting thing here is that what Nexmon does for us is taking our patch and it makes sure that it gets linked to the correct functions which are already existing in the code so we don't care of all the linking and so on so we don't need to do it manually the requirements for that are the following so we need at some point we need to have the firmware of the binary of course then we need to know the memory layout so where the functions are or how the binary is loaded for example or how the memory is looking like if you want to write patch code then we need to have free space on the flash for the patch code if you don't have enough free space the flash chip is already full then you need to make some free space in terms of delete functions which are hopefully not used and if you want to reuse functions you need to know the function names and the signatures and you need to know where they are okay like I said this is a step by step approach let's start with step one and between the firmware so the whole time I've been talking about the smart home gateway but it's more or less the same for the laptops and for all the other products which are based on this chip okay so how we get to firmware there's one possibility if you open the device you can just dump the SPI flash for example JTEC SWD or the solder the flash a helpful tool if you want to use JTEC or SWD you can use Raspberry Pi it's absolutely sufficient for that and open OCD the good thing is Marvel gives you all the tools already to connect to this chip over SWD JTEC if you disordered the chip you can read it out with flash run the other possibility is that you intercept the traffic by the firmware update but here the idea is the following it's very advised that you actually block the updates that you get that you intercept the firmware update but you block it for the device because you don't want the device to actually update the firmware and here Xiaomi gets a little bit sneaky so if DNS is failing if they try the first time to update the firmware over with the DNS address and it fails when they sent the command again this time with IP address so if you're clever enough to redirect the host names in your router then in the second time this device will be updated for some devices not for this lightning stuff but for our devices if they use SSL most of the time you can just use fake certificates or what they experience if you block SSL at some point they fall back to HTTP and they do the update to HTTP the goal of this whole thing is to retrieve the special URL for the firmware update and the reason is the following if you want to download the firmware the file names are not easy guessable because the file name of the firmware update has the MD5 checksum of the firmware update as you usually don't know it you can download it the other thing is where CDN is using authentication so basically you get some kind of token to download the firmware which is a thing valid like for two months or so but still you need to have this token to be able to download the firmware if I just give you the URL with the file name you can download it you get the access denied so you need this URL let's assume that you have it already so you intercepted it for example the fire shark or you have the firmware image the next step what we need to do is we need to pass the firmware firmware has the bad altitude that they have proprietary format and it's like difficult in idar pro for example and you need to know where the segments are what the segments are, how big they are and where the entry point is so our goal here is to convert the firmware to some kind of elf format or elf file because the elf file has some description and it tells you where the segments for example are so we need to understand how it works and the idea here is the typical thing what you do all the time so you get some kind of SDK from the vendor for example for Marvel you can download their Amazon SDK and you just compile a sample firmware and you just look okay so at some point you have the elf file and then you look okay what's the output and then you try to figure out what's going on there and for Marvel it's the case that it creates at some point the elf file and they're using then later in the script the tool which is called EFX to a firmware which converts the firmware to a binary format so we did back then the RIS engineering for you so this is how the header looks like from the format format and we have a tool which can go from this binary format into the elf format and from elf back to binary there's one fun thing which I never tested but if someone of you has the smart Barbie doll it has the same chip actually so this is for the people of you who don't know that it's not from Xiaomi it's from the Barbie company whatever Barbie is doing it's actually a doll where your kids can tell your Barbie some stories and then as parents you can listen to the stories on your smartphone so if your kid is telling your Barbie a secret then you as parents will know that a little bit scary but yeah in case of media tech the format is looking quite similar again we have some kind of segments this time we use some kind of checksum while the Marvel firmware has no checksum in there basically if you change specific like if you change the URL in the binary then you can upload the binary and it should be fine so let's take a look at the workflow for Marvel so let's assume we have intercepted the firmware we download the firmware ourselves how we get the how we pass the firmware so as soon as we run our parser tool what it does is it figures out where the sections are and creates for us the sections as individual files and two kinds of scripts and one script is the description of the sections for the LD command which is later important for manufacturing to rebuild the firmware and the second script which you get out of our tool is that it gets commands for the object copy and also the LD command so if you run the builder command then at the end of the day you have an L file which is built up correctly as an example here this is the command which I run for the firmware which I downloaded like a few days ago and I actually yeah it's a quite new firmware you see the build date this is the data where we build actually the firmware and you see it has three sections and when we run this is how the thing looks like and as soon as I run this builder script you see there at the end of the day we get an L file which is also correctly working and in theory you could take this L file and run it on a Linux but I think shouldn't do anything at least yeah so having the L file now what can we do next while we can load it in a disassembler so I use IDER because I got at some point an IDER license I think most of you will use a different disassembler to load the file into IDER and you can figure out where the interesting areas are what I figured out at some point is that you have some spaces in the firmware where at some point the data from the one-time programmer memory is copied into this space so basically what you see here are the three main interesting fields tag MAC as the place where the MAC address is stored later tag DID is the address where the device that is stored and the key below there there's also the model number so theoretically you could get the model number but the model number is known and there's also an area for the server for example if you have a Taiwanese device when it's like TW there or if you have Chinese device it's empty right so now we need to prepare all the data for next month I showed you the partition layout in the beginning so what we figured out is that the partition has a size of 614 kilobytes and the size of the original firmware is only 569 so basically we have a lot of space for our patches so the trick is as we need space for our patches we just append 1280 null bytes which is that bad in hex so we end with a new section file we have chosen section file 2 because it contains all the code where we have the original section and we have the patch code so this is looking like this so now we have some space to put our patches in if you do it in Linux it's quite easy you can just use DD to do that so at the end of the day we have some space for our patches now the next step is we need to figure out the function names and for example for every function but you want to use later in the source code in your own patch you need to figure out if it's existing already in the firmware or not or you have to introduce it later so how we do that again we take the SDK we compile an example project which more or less contains all the stuff which we need later and because it's compiled with debug symbols what we can do is we can load the binary bindiff between our unknown executable and our example executable for either there's a free plugin which is called bindiff which you can download for me only the version 4.2 works so 4.3 is somehow completely bugged and doesn't work for me so how does it look like so you see here on the left side the name primary these are all the unknown functions which are in the binary on the right side the name secondary these are actually the functions which I used for my example project which I compiled myself so basically I can align all the functions all the unknown functions into my unknown firmware I think 70% of the functions are unknown after that so for our example for this gateway I have chosen a few functions which are interesting for me there's a PC get command which is doing a get query to a web server I found out what the address is for that there's a bind to hex command as nprintf is also quite useful the nprintf is a console output so if you connect it over serial then this command is used to output anything over serial and for the Xiaomi cloud specific there's a command called or a function called otu timer info and this is actually rocking command to the cloud if the device is connected over UDP so like I said this device can communicate to the cloud over TCP and UDP so if you patch the UDP function and something goes wrong we have still the TCP function so we can maybe unbreak the device if we did something completely horrible wrong what we use here in this otu timer info function there's at some point an snprintf and this is like the address of the snprintf this is also useful for later ok so after that we have the binary we have we know how the memory layout looks like because the header file of the firmware told us more or less where the segments are loaded at which memory addresses we created more free space for the flash of the patch in the flash for the patch and we know now the functions function names and the signatures so we need to configure our nextmon so nextmon like I said is consisting of a lot of different scripts and now I give you a step-by-step thing what you need to do if you want to add a new device the first thing is there's a firmware version file where you just need to create define a number for the device it could be any number just some number which is internally used by the gcc plugin of nextmon you can find a new device and maybe a new firmware and the next step we need to tell nextmon if you create a device where it can find everything so for example where is our original code this information we know from a deposit tool and also we need to tell where is the space for the patch code and for both things we need to tell how much space is available especially the patch size so you don't want to go over over this I actually don't know what happens if the patch is bigger than this but usually it should never happen so the next thing is now we want to define the existing functions so like I said for me the interesting function was httpc get so here you see the device sorry the function name and the signature arguments that it has and what you do here is and this is the important thing is you tell more or less the nextmon framework at which address it can find this function in the firmware and the same stuff we do for the binterx function we do it for nprintf and we do it also for this vmprintf which is giving us the console output so by this we telling it can find the stuff for this one particular device and for this one particular firmware version okay so let's write our patch compound rebuild so this is one of one of my example patches so what I do here is I actually do http request to my server so we saw in Ida where the interesting memory areas are so here are the addresses of the MAC address device at the key I created a buffer and what I do here is I convert the key into some hex format and I run just http get on my server so later on if I look at my server log I can see the key hopefully in Kleatex the important thing here is that we need to tell the nextmon framework where it has to to patch this thing so in this case this address is more or less the original branch instruction the branch link because we don't want to break the functionality of the device so here you see also we return actually in the original printf again so basically we every time if the snprintf is called in this otu info function we jump into this patch we extract the key and when we jump we go back to the original program flow so the device is still functional of that now we have our patch so if we do the rebuild thing if you compile everything with nextmon we get the sections again and then we build the firmware again and we can use the marvel tool to build the original firmware which is then patched okay so now we need to apply that and at this point I should say it before but obviously your rarity is void after that every time you open the device actually it's a problematic thing so how we do that the first step and this is the step which we can't avoid at least for the devices like the light bulbs we need to have a new firmware update it must be available so if you're already sitting on the newest firmware update it's not possible so the as soon as we get like this otu update command from the cloud then it's a good sign that means actually there's a new firmware update so we can somehow manipulate that and how this is done is actually sorry this animation is broken this would be a usual way so we would made a HTTP request to the cloud server and we would get the firmware but we don't want that because we don't want to have the newest version on the device instead what we're doing here is we're using some kind of DNS switch and we're switching this thing to our IoT village CDN so our patched firmware is downloaded to the device and then the device is very happy about that. I tried to prepare a demo but the thing is it's nearly impossible to have Wi-Fi here so I didn't want to break the devices but if you're interested you can take a look later on the devices and we can try something out there's one also one interesting thing if you get the SDK we have also some very interesting demo applications there for example with P2P demo where the devices can make some P2P network over Wi-Fi there's a Wi-Fi frame inject demo or like a Wi-Fi sniffer demo so you can use this kind of demos for your patches if you're interested in doing specific things okay so for the summary what we can do we can modify the firmware we can route the device and we can do it remotely and this is the most interesting integrity checks so we don't check for the MD5 we don't have any signatures in the firmware what we can do then is we can read all the cloud communication in plaintext because as soon as we have the key we can decrypt it and we can run it for example also with our own cloud there's one thing where I told tell everyone at the end of my slides and this is like the thing never leave your devices unprovisioned I know people who buy the light bulbs somewhere in their home and just use them as normal light bulbs but it doesn't make sense for a Wi-Fi connected light bulb what happens is this device is unprovisioned so everyone who is in proximity of this light bulb can provision that for you and install some malicious software on it also be careful with devices which you buy at Amazon or eBay and so on you have no idea what kind of firmware is installed and the thing is you can't actually check that so they have no possibility like with a laptop to figure out whether it's malicious and so on you can't do anything with the firmware there so for the conclusion the best practices for IOT devices or like in general for embedded devices are not used so we have no Md5 verification if we use HTTPS when it's broken or we don't use HTTPS at all the certificate verification is also broken the hardware security features are missing so some of the chips actually have features like secure boot or where you can some verification of the firmware in hardware they're not using that the good thing for us is we can modify devices but the bad thing is everyone else who have some knowledge about that can do that too alright so I want to thank a few people Daniel Wiggema who did the next month framework and helped me with all the research also Professor Nabeer from the Northeastern University the Zemo lab with Professor Matthias Holek from the TU Dammstadt and Rossellers and his team from the Boston University CyberLog Clinic and there's a particular reason why he's there because in the US to publish specific things is a little bit tricky with the law so basically they make sure that I'm not getting into trouble so I'm special thanks for them and that's all for my presentations and I'm happy to answer your questions or if you need any contact data you just can I created especially for the Defconn Twitter account so you can send me Twitter messages tweets whatever about me or telegram ok thank you very much