Introduction to Hardware Hacking: How you too can find a decade old bug in widely deployed devices
Laulheret, Philippe
From small business to large enterprise, VOIP phones can be found on nearly every desk. But how secure are they? What if your phone was spying on every conversation you have? This talk is an introduction to hardware hacking and as a case study I’ll use the [REDACTED] Deskphone, a device frequently deployed in corporate environments. I’ll use it to introduce the tools and methodology needed to answer these questions. During this talk, attendees will get a close up look at the operations of a hardware hacker, including ARM disassembly, firmware extraction using binwalk, micro-soldering to patch an EEPROM and get a root shell over UART, and ultimately uncover an already known decade-old bug that somehow remained unnoticed in the device’s firmware. Beyond the case study I will also address alternative tactics; some did not work, others may have but were not the lowest-hanging fruit. When it comes to hardware hacking, the process is as important as the result; knowing that there are multiple ways to reach the end goal helps researchers remain confident when hurdles arise. After the talk, attendees will have an increased distrust towards always-on devices; however, they will have the background knowledge to investigate the products and systems they encounter daily.
 Without further ado, because we stay on schedule. Felipe is here from Portland by way of France, from what I understand. And he is going to talk to us about breaking into embedded devices, including phones. Phones that you might have on your desk at work. Phones that might be... I'm not even going to get into that. Phones that might be around. Let's learn about embedded device hacking. Let's give Felipe a big round of applause. Have a good time, man. Thank you. Thank you, everyone. I'm really excited to be here. It's like a big honor. Today we're going to talk about hardware hacking. I'm going to share this introduction to it. I hope I can share some love about hardware hacking. Who am I? I'm Felipe Lodorette. I'm a senior security researcher at McAfee, adventlet research. I do software and hardware volume research. You can find me on Twitter at ph.lol. Before joining McAfee, I spent two years doing embedded security. Before that, I was a C++ dev. I'm more coming from a software background, actually. You could wonder why should you care about hardware hacking in the first place. I can see two main reasons. First, it's actually really fun and empowering to be able to break open a device that you're having at your home, at work, whatever. Instead of considering that it's a black box, you can start poking at it and understanding how it works. Then in a more pragmatic way, if we consider security in the past couple of years, software is becoming much and much harder to break. If you try to, I know, like, find a world in a web server by itself, it's kind of hard. But if instead you can just open the device, solder a couple of wires, and get a shell from that, that's much easier. So hardware hacking is great because it's also like a lot of low-hanging foods, basically. So today we're going to talk about Avaia phones, and especially like the phone picture on the right side of the slide is a 9611G model. So Avaia is like one of the biggest view IP solution provider. You can find them like all over the place. It covers like 90% of the 4100 company, and I think that's a specific model of phones starting in 2006, and it's going to be enough life at the end of the year or something. And the funny, on the bottom right of my slide, there is this funny like a screenshot from like a firmware download page from like a really old software for these phones, where actually like you can see that you can only download that specific firmware if you're like a DoD customer. So basically you can see that these phones are like going to a lot of different places. So regarding prior art in hardware hacking, there's like a lot of information nowadays on the internet, like you can find a lot of blog posts, tutorials. There's like the hardware hacking village that you all go and check out. CTF as well, where you can like practice like kind of like the software side of stuff. And on my slides, there's like a bunch of links at the end, so you can like download the slides at later time, and also those slides, I've like the one I've uploaded, I have like more text on them, so it's like more like standalone, so you can read more. And yeah, RedBalloon Security found like two assies in the same phone, something like five years ago or something, and I like a talk at RSA called Stepping Ponds that I would also recommend to check out online. So for the next 40 minutes, so I'm going to talk about hardware hacking and use that phone as a base to like support that conversation. And basically the idea of like the whole situation is like couple of like 12 years ago maybe a very forked some open source code and they never applied security patches to that. And it turns out that like me by poking at the device, I found that and it was like women like unnoticed for like 10 years that they were like actually like a CVE that got released like 10 years ago for DEF CON. So I'm going to talk about how I found that, like that it was like some stupid like you know code inside the firmware. But more interesting I think is talking about the whole process, you know, like how I did it and why I did what I did it. Why I did stuff I did when I did it. You know like basically like sharing the process so that and you know also like sharing, you know what if the stuff I tried didn't work or also like stuff that didn't work because you know what works for one device might not work for another and having just like that mental model of what we can do and what we cannot helps you a lot approaching like any kind of device and that's I really think why I want people to take away from that talk is more like learning the process so that you can check out like whatever device you have. And yeah I would want to like insist that if I can do it I think everyone in this room can do it as well. As I said more from like software background and hardware hacking is still like you know like a little scary little foreign to me but it's in the end it's really not that hard if you have like a good process and you know work with patience. So how did the whole project start? To be honest I was like you know working at work and we were like all these cubicles and on every desk I see this like phone like standing on the desk. I'm like wait a minute these phones run Linux they have you know network access they have like mics and stuff it's like how secure is that you know like you wonder like what's up with it did people consider the security of those? So the first step before you know even like I start like stealing my co-workers phone and breaking it apart you can and that's general step is you can check out the FCC website usually like any device that has Wi-Fi or Bluetooth has to be on the FCC website for like compliance reason. So that's what I found that's not my phone that's like a other model of like same brand basically and like really close. So you see all these cool pictures but more interesting is the inside of the phone. So we can enhance it and on the left side in red I've highlighted like this like random debug connector I don't know what it is but that's interesting to see that's there. And on the right side there is like that like in purpose there is that flash memory so that's usually where the file system of the phone is going to be stored and the whole point of that is just to get an idea of what to expect you know before even approaching a real target like burning hardware and stuff so that you know like if it's going to be a easy target or hard target you know if everything was covered in black epoxy that would be harder. So another important step is like getting like online material like you know marketing brochures so you have an idea of what are the phone capabilities and the ecosystem surrounding it so that you have an idea of you know like the attacks your face and you can also find like user manuals and stuff and for instance I found that one that was pretty cool it's like a user like our advanced user manual that says oh if you want a serial connection to the phone you need that funky box and yeah which is interesting it teach it tell us that yeah you can find a serial connection and you may have some special hardware for that but are we going to see that in a bit. And after that you also want to check like forums and so that you can find like what poor user are doing like for instance I found like the default password for the phone in debug interface because a system admin so here I talk talking about that online and if you're lucky you can also download the firmware of an idea of what's up there and I will cover that in a minute. Okay so what do we do now? We have an idea of like what it might look inside. This is a hardware hacking talk so we're going to avoid warranties and so the point is like you open the phone first and the trick is like usually you always expect to find the same stuff inside and if you look at the labels of the components you will see and you google that you will find out like what it is. So for instance that's my phone and you can see in the center the CPU above it like the RAM in like a lavenderish color like some unpopulated like header that I marked with a question mark. This I think the same header as the one we were like seeing in the picture before and it might be JTAG I did not have to use it so I don't know actually. In purple we have like the AEPROM so that's what the whole like some settings and stuff. In dark blue in the bottom of the slide is like a keyed LG45 so I was kind of confused when I was looking at that and I didn't know even the term for it and the idea is just a regular LG45 like Ethernet plug but with a weird connector so that you cannot plug the wrong stuff into it. And more interesting in yellow the UART so it's UART is kind of like the serial console and we have like this exposed like pads and so usually like in manufacturing or something you would have like Pogo pins that would like directly connect to the pads and that's that one is actually really interesting because you would expect to find a serial console on that and on the back we can see the same name flash that we've seen in the previous picture and yeah from that is like where the file system would be like stored on the device. So okay you have we looked at the stuff inside and like other thing that's interesting to look at is like test points and debuggators so and like basically all these kind of stuff that are not components and you can ask why would you expect to find them inside and couple of reasons like one is like just usually like the death board that the guys are going to use is the same as the production board and maybe they're just not going to solder the debugg components it's the same as if you had like software and it was built with like debugg symbols for instance and also like part of the manufacturing process this test points and stuff might be used for like flashing the device or making sure it's flash properly and sometimes you know like something died or something like that and you know like something died on in the real world and they want to like do a post mortem to understand what happened and that's useful as well. So what kind of stuff you want to look for in that situation you want to look at UART that we like looking at before JTAG that I'm going to cover in like in a minute and then like you can also have like random test points that are chilling there like all over the table all over the board and there might be like long test points like like TP1, TP2 whatever and sometimes that might be like not interesting to you but sometimes you can find interesting stuff like you might find out like oh if you short like TP64 with ground it's going to reset the device which might be actually useful in some extent. So looking at UART so as I said this for like serial connection and it comes in like three or four pins the three pins will be ground transmit and receive and the fourth pin would be like VCC so three volts five volts whatever and usually you don't care about that one you don't even want to plug it you don't have to and the trick to know is the serial console send data at different speed and there are only like a couple of it's called like both rates and there's only like a few common both rates value so if you try to plug your system into the UART and you just see gibberish on screen the probably the reason is you just have the both rates wrong and you could just like try to cycle through like all the possible one and you would find something eventually I think. JTAG is another one that's interesting so that's for like hardware debugging and with that you could like you know debug the CPU usually and execute like instruction by instruction and whatnot and they come in many different shapes number of pins and whatnot so some example like on the bottom of the slide but actually only a couple of wires are interesting and at the end of the slides I was like sending you an article about like understanding JTAG better but basically like if you look on the top right side of my slide there is like a dev board and there's like a nice JTAG connector like plug there and on the other hand like on the bottom right it's like some random device I was looking at which you can see there should be a JTAG but it's never been soldered on and so I had to solder directly onto that stuff and the trick to remember here if you kind of like solder your own connector is you actually may have to add like extra resistors called like pull up and pull down resistors that connects like one pin to ground or one pin to like VCC and the point of that is actually I don't know the point of that but the reason is like if you don't have them it might not work well or it's more work most of the time it's going to be glitchy so and if you follow the instruction from like for like our ARM specification for like what resistor you need so you might skip them but then you might waste time like understanding why it's a weird really like fucked up sometimes so I would recommend like remember the pull up and pull down resistors so that's just a random board that my co-worker was looking at just to show you that what I said is actually fairly generic on the left side we have like few art on the right side there's like some JTAG connectors uh there is the uh a price there is like the main CPU whatever that's under like a shield and usually you do that for um preventing um interferences so it's like a Wi-Fi module so that's why and the cool thing to know is usually the shield is grounded so like if you're looking for the ground on your thing like either the shield on that kind of stuff or like the casing around the internet port or whatever is also actually like fairly useful so uh now that we learned how to uh look into stuff we need to know what hardware you need for um interfacing with what's inside so I'm going to present like a bunch of cool hacking toolset that's important so the first one uh you may want this pin or like the stickers I don't know if you're familiar with that but um actually like what's really important is like safety um so you know don't work with stuff that's plugged in the wall uh remember to unplug stuff work in like well ventilated room it's important and uh yeah just don't be stupid when you're like uh messing with hardware uh but yeah so next picture from the lab uh I'm holding um soldering iron you can usually switch tip for like if you're like large tip for like big soldering and tiny ones for small soldering I have a microscope so that's really useful for doing uh tiny soldering and the trick is I tend to drink a lot of coffee and I shake so I would I was thinking like I couldn't do that but actually if you um if you're careful and the trick is like really like try to um you know when you bring like try to hold your arm like straight and well grounded and under the microscope you can actually do a lot of stuff that's you just don't think you you wouldn't be able to use you would think you shouldn't be able to do it but you actually actually can. Sorry um top right side um it's what I actually use for doing tiny soldering and um it's like top right like flux so it's kind of um magic glue magic uh gooey sti- substance that you put on um pins to uh when you're soldering surface mount or pads so that it works really well so don't never forget flux uh bottom is um like in the same uh size like uh copper wires like um NML wire that you use usually for making cords you know for like radio or whatever um and the trick is like the uh the wire is actually um coated in uh varnish so it doesn't uh short and you can use that to do like really tiny point to point like soldering and that's actually really useful and just next to it you have like some desoldering week so like the idea is if you put too much solder and you fuck it up uh you can put the week on top of the solder blob that you messed up with and you um put the soldering iron on top of that it's going to get really hot so you want to hold it through like the plastic casing and it's going to absorb all the like extra solder and you can clean up your stuff. Then I put like a picture of like some random like uh jumper wires that are usually always useful to have and on the bottom right I have like that crazy uh heat gun uh which is like 60 bucks at Home Depot it's meant to like help paint dry or something I'm not sure but it's actually really useful for if you're on the chip if you want to remove components by just like hitting them and pulling them off. So um more cool hardware um that's a multimeter um if you're not familiar with that it's you use it for um fine voltage of chip you don't know like what's the actual voltage so the black goes to around and with the red you uh with the right probably you select poking around to measure the voltage and the other really cool stuff is you can set it in continuity mode and when you have like connection between the two probes it beeps so if you do like crappy soldering job as I was describing just before you can make sure that you actually did a proper job where like everything is connected the way you think by you know making sure that both like when you probe like both sides it actually beeps and that's actually a fairly useful uh tool. The other one is this is a logic analyzer uh the name is like a Sally um that's a brand and the idea is the same as in software you have like ways of communicating between process like in hardware you have like ways of communicating between chips or the CPU and the chip and it's uh it's like a lot of different standards different ways of doing stuff but the logic analyzer like know a lot of them and it's going to convert like a bunch of signals that go going on to wires into actual data and that's actually really useful that would be your eyes like when you're doing debugging you know and that's like a some spy communication uh which spies just some random protocol uh that's like an FTDI cable also come in many uh or serial cable it comes in many different shapes and stuff and the idea is just like when you want to do like UART you you plug that into your laptop and you connect the other side to like the UART port and you get like a console it shows up at the serial port and uh as an example I have uh on the bottom right um like a Raspberry Pi that's you can actually get a serial console and you don't need like HDMI cable or anything to interface with that. Whew um the bus pirate uh also like cool device um it does um it's kind of dependent of the hardware hacking uh sorry the um the Sally the logic analyzer so instead of absorbing data it's like send data so it speaks a bunch of different protocol and you can use Python to program it so it's very useful if you want to like read flash program um microcontrollers and that kind of stuff. Uh more cool stuff like how about I was talking about JTAG that's the JTAG debuggers that you that's why you would plug actually like the the JTAG port on they come in many different like uh price range and what not so on the bottom right is a fly swatter it's like probably like 30 bucks I think and it works okay and above it's like a J-link which is more fancy and the idea is expensive the stuff is the more probably the more reliable it is and it comes with like better software and why not and on the bottom right the pink board is a JTAGulator that uh Joe Grand the same guy we met like those badges uh made and it's really awesome so if you have like that board you don't know what it is and there's like a bunch of test points and you're like I bet there is some JTAG somewhere in it but you don't know where you can just wire like all the test points to the JTAGulator and it's going to brute force like and try to find everything so it's really cool um another interesting important tool is flash readers so um usually flash content uh the flash has the file system and stuff and uh so you want to like interface with that and uh it comes in two flavor I guess you can do like in circuit stuff so you have like either like a little like clamp that you put on the chip or like the little rectangular one um and the clip on um so like the Raspberry Pi is a good one for that and on the top right is like a flash cat uh it's like for the rectangular one um but you can also like choose to like actually disordered the chip and in that case you would have like some like like socket adapter so you can clip the chip on and then you plug it into your flash cat or whatever and it's going to read it and I will cover like why what's what's why it's important like both in a minute and finally it's kind of the um last uh hope so let's say uh you know your flash is encrypted there is no UR there is no firmware so you can try to do like the more crazy stuff like fault injection and side channel like so that's a chip whisperer so like more like uh kind of hard more badass device and the idea with that is um it you can do stuff like um you you uh wire it and to the CPU and you're going to drop the power on the CPU for like a split second and it's going to like mess up some instruction and you can bypass checks and stuff that's what people use for like gaming console hacking and um that kind of stuff so uh what do we do now um that we have an idea of what's inside the phone and um you know um the tools we can use so like I think the three post potential track one is messing with the UR so the serial console and the other one is messing with the flash and trying to recover the firmware or something and then maybe you can just download the firmware online and the three are like valid approach and sometimes it's good to just go from one to another to another and you know whatever you find like some hurdle you can like go from one to another uh so I want to go for the UR first and that's what I'm greeted at by when I connect my FTDI cable to the UR port that I was showing before so we can see like on the left side the um the console thing it's like dot dot dot usually when you see that you can press space or escape and it's going to interrupt the booting process of the phone and in that situation uh but somehow here it didn't work and uh I will cover that why in a minute and on the top right side of the slide um we can see it read something from the eProm and decided to set the console to DevNull. So you don't want console to be DevNull because that goes nowhere but that's interesting to know that there's some potential there. And finally it says like booting Linux so it can confirm us that it's a Linux board but then there is nothing more after that. So that's some good thing, bad things. So the problems are like nothing shows up after like the Linux is as booted probably because of the DevNull situation and when I press key it's not working and I'm going to like come up with like why that happened. So at that point I was still like okay I cannot go anywhere so I'm going to try to recover the firmware to try to understand what's up with that. Multiple ways of recovering firmware's is like an easy way that you can download it online and actually that worked. There is like some cool snapshot of that. Sometimes encrypted on our case it wasn't. But yeah so you can also try to sniff a firmware update that's really useful for IoT devices in general and you can use a network tab which is like the thing pictured on top right of the slide. Or you can mirror your port on your switch or whatever. The problem with all of that is oftentimes the firmware update is going to do over like HTTPS or it might be and in case you're like stuck. And then you want to go for like a more like hardware hacking stuff like you're going to dump a flash for instance. And there's like even more advanced techniques that I will briefly like talk about. So how do you dump a flash? There is two ways as I was mentioning just before. You can do in circuit programming and out of circuit. So in circuit is cool because you don't have to you know like remove stuff, break stuff. But a couple of issues with that. The main idea is to read the flash. You need to power the flash. And if you if it's like still plug it into the whole system. When you're like Raspberry Pi for instance going to try to read the flash it's going to try to power like everything else that's connected to the same like in a bus line, a power line. And either you know your Raspberry Pi is not strong enough to power like a V-O-I-P phone which you would expect. And in that case, but it's just not going to work. Or maybe your Raspberry Pi is really strong and it's going to do it. But then the problem is the CPU start booting and it's going to talk with the flash and that's going to mess up your stuff. So in that situation you have like two choices usually. Either you can try to like lift up the pin, the power pin so that it doesn't happen. Or you can kind of go a little more like a low approach where you want to keep the CPU in reset. So I've been successful with that many times where I just like start like trying to ground like random test point of stuff on the board praying that it's not going to fry anything. And usually at some points like I'm going to notice that okay when I do that the phone like light up but doesn't boot, that's good. And maybe better ways you can disorder the chip with like the big like heat gun and whatnot. You have to be careful though because if you like pull it too hard you might like bend pins and it's going to be like useless. But a good trick to know is like you can make a little like tin foil a hat or whatever like around the chip so that like when you're heating up the chip like the stuff around it doesn't like get too hot. So you don't accidentally like knock off like some like tiny like components that would be like a pain in the butt to put back. And bottom right is like I was, I thought I would have to do that on the phone so I wanted to practice first and I just took like some random USB thumb drive and I tried. And actually that worked really nice. But the trick is remember I also put some plugs because it helps. And yeah just don't be careful with when you pull it off. A few other tricks that actually didn't work on this one but are good to know. Uh U-boot is the most common boot loader uh not used here but it's you would find that on pretty much every other device. And the idea is you can also interrupt the boot process of that and ask nicely U-boot hey can you load the flash in memory? And then uh U-boot is also able to dump in a hex like in the screen. Um the the memory is this way you can just like write little script to do that and recover everything on the flash which is really cool. But usually like dev don't like letting you do that so they set they lock that approach so you cannot like press space when you're in the boot process. But there is a trick that I also call like the YOLO approach where um instead when the idea is like U-boot is going to load from the flash like the the new kernel or something. But if while it's happening you start like poking with you know like a wire that's connecting to ground. You start poking the NAND flash like some of the pins. It's going to mess up like what uh U-boot is reading. And after a couple of tries uh U-boot is going to be like damn that kernel is fucked up. I don't know what to do and it's going to give you like a shell. So that's really cool. But yeah as I said that one wouldn't work on our phone unfortunately. But there are just some cool examples that I found online where like some guy actually did that. And uh I underlined in uh in like purple on the bottom like the command you need to use to like load the the flash in memory. And on the right side this like little block of text is um sorry is how uh U-boot is panicking and be like eh I don't know how to do with your kernel. And give you the the shell. So um so a few more like tricks for um dumping the flash. So you can use JTAG. So usually you have uh if JTAG works you're going to be able to um dump the RAM. So in this case that wouldn't be really like dumping the flash. That would mean the firmware. But in a lot of devices it's going to load the whole stuff in memory. So if you can dump the memory you are like the same. You're pretty good there. And kind of the last hope but that's one of my favorite about hardware hacking is you can do crazy stuff. Um and an example is uh ScanLime um that person on the internet who um she had um a Wacom tablet that she wanted to dump the um the firmware off. And there was like no attack surface at all. But she realized that like when you just like USB stuff. So when you plug your USB um onto the laptop there's some USB exchange that I don't know anything of. But it sends like USB descriptor. And if you if you glitch the CPU just at that time um it's going to like you know miss like a boundary check and it's going to send away more data. And with that uh she was able to recover like the full flash uh full memory or something. So it's really impressive but and that's what's kind of awesome about hardware hacking. Okay so uh we recovered the firmware uh in my case just by downloading online. But what do we do now? We want to analyze it. Um the best tool for that is called Beanwalk. And it's just basically a magic dictionary that's going to like look at your binary blob of stuff and be like hmm halfway through it looks like there's a zip file. I'm going to try to extract it. It tries. Maybe it works. Maybe it doesn't depending if it was actually a zip file or not. And it does that for everything. And uh it might also find like compressed file system uh such as like Squash FS, GFS2, etc. And sometimes like your um your firmware file might just start with like health headers or just like random like ARM code that you could like look at. So I run Beanwalk on the so that's the firmware file I've done on it from the website. And once again it's easy mode. It's just a tar file and they already like split it up into boot one, boot two and GFS2. So like Beanwalk has nothing to do here really and I can just extract the whole file system. And that's cool because from there I can look at what's on the phone just like that. Uh but the more interesting use case for Beanwalk is I took like a different firmware file for like another Avaya phone. And this one is way more interesting because Beanwalk for find like a way more lot of stuff. And uh I've highlighted like you find the file system and is able to extract it. And there's also that random like MySQL stuff which I think is false positive. Then you need to be aware that there will be a lot of false positive so don't blindly trust what Beanwalk says. And uh really really funny stuff that I was looking at uh if you run strings on that specific image um you will find like U-boot strings. So that phone is using U-boot and the cool stuff I was describing before would actually work on that one. Look. So now that you have extracted the firmware file what do you want to look for? One of the most uh interesting stuff is uh finding the update mechanism. So assuming you have uh encrypted firmware like if you reverse engineer that you might find the keys and how to extract like subsequent uh firmware updates without having to do like any hardware stuff. And then you want to look for like secrets like passwords, certificates, and so on and so forth. Uh originally my goal was to look at the main binary so that's the thing that deal with like the VOIP stack uh that could make sense to look at that. And um also you want to look at the bootloader because it may have a hidden command, explain why our console is not working, that kind of stuff. So remember the point of all of that was I wanted to get a shell on the device and um what's the process to do that? So the one I want to go for is I want to fix the serial console you know like the dev null was not cool. Um but also our approach would be like messing with your boot arguments. Um not working here obviously. Uh but you know you can specify the console you want and uh the init script can be marked as like oh I want bin bash as my init script and then you have a console. Uh and like kind of last resort stuff that I was considering as well is you could patch the firmware uh in our case the firmware is signed so uh that won't work unless you try to glitch it which really hard. But you can also try to patch the file system so the way bin work extract the gffs 2 stuff you could modify it and then like repack it and flash it directly onto the flash. And that's usually like a foolproof method like that would work in most cases. So instead I'm going to uh reverse uh um the bootloader and um for that um because I wanted to understand like why dev null uh the console was set to dev null and stuff. I'm going to cover arm in much detail and I would recommend you to check out azalea lab tutorials that cover everything but just useful here um there is this notion in arm of literal pool which is um inside the code section you would find some little chunk of data and that's usually like used to like load in registries um absolute addresses, imended values, magic offset that kind of stuff. And uh FYI like in case of function calls um the arguments are going to r0 to r3. The return value is r0 and when you like want to return from your call it's the return address is saving like the lr register that stands for like link register. Um and the big trick, the big problem here is um we like trying to load the bootloader so it's uh it's not really elf. So if you try to import it in IDA IDA doesn't know what to do with it. And so you need to find the loading address for that stuff so it match what's where the phone is loading it. Couple of tricks um so none of your lucky end is going to be printed on screen. That's our case, sweet. Um but otherwise we want to look at like header file, headers in the in the bootloader file or maybe reset vectors that's stuff where like specifically for ARM like the CPU needs to know uh specific addresses where like there's like a reset or like an interrupt happening and it's like fairly like um square like that how that's being set up. So if you find that and you find like what looks like an interrupt vector handler or something you can find like oh that must be the address. And uh finally the literal pullout was mentioning uh really useful because it's going to contain like absolute addresses or point to strings and stuff so uh if if like you have strings and they look like all fucked up you probably got the wrong address. And uh QuaxLab uh what a blockbuster body so I would recommend you checking it out. So as I said in our case it was easy um when it boots it prints uh the jump whatever and that's actually why you should load it. And um on the bottom right side it's like a bunch of strings um so it's a bunch of addresses that point to strings uh this is not from IDA and um we can see that um it's like all the strings like prints well so that means that it's loaded properly it's not like all messed up. Okay so now that we have the bootloader and we can like work it with IDA uh we want to search for strings uh we were looking at you know like that sentence like EEPROM, Red Successful, whatever. So we can use like cross-reference in IDA to find where the string is coming from and look at the function that handles that. And uh yeah just as a FYI about like EEPROM and SPI so the EEPROM that's on the board is called a SPI EEPROM and SPI is just one of those protocol I was mentioning before. EEPROM is just like a small memory um whatever and the SPI uh protocol is just like four wires um and the IDA the CPU is sending command and the EEPROM like reply and uh that's a dump from like using the logic analyzer to have a look at what it would look like in real life. Uh that's the data sheet of the EEPROM uh that you can find online if you google the label on it. Um the cool thing is in bottom left uh of the slide it tells you like the pinout so you know how to connect stuff to it. And on the right side of the slide um it tells you which which opcodes are for like the co- SPI command you would send. Like for instance if you send uh three it's going to be a read, if you send two it's going to be a write. So that's uh that's something useful to know right. Oops sorry. Back to the um back to the IDA and uh the bootloader we can see uh the strings we were like looking for and something extremely promising is we can see the console set to DevNull but above that is like a burn to those options and it's actually saying like oh setting console to like your zero or your one. So we want these ones to be printed. Um that's a that's a function that actually does print that string and uh what it does is roughly uh clear some bytes on the stack and then read from it from from a magic address and it's going to compare like bytes um that has just been read. And if we have the good value it's going to actually print on the console setting the console for uh DevTUI uh AM zero. So we want that to happen. Uh and something you can ask me is like well how did you find that read-uprm function you know and there like multiple ways of doing that uh the easy way that I've highlighted in green in that screenshot is uh on the bottom right we can see some like logging that says oh eProm read fails so I know that function is responsible for reading eProm uh but maybe maybe the firmware you're going to look at is not uh as verbose in which case um as I said before like to read from an eProm you know you have to send three over SPI so if you find like the SPI function and you see like sending three you know what it is. That's what I've highlighted in um yellow. Um but then like how do you find the SPI function you know it's kind of uh problem uh two ways for that um in my case once again it was logged so it was easy but usually like the main trick is um you have this um something called uh mapped uh IO a memory mapped IO and it's this kind of like magic address values in the CPU that like if you write to them it's actually going to send data over like your auto-SPI or whatever. If you're lucky you're going to have a data sheet for the CPU and it specifies exactly what are those addresses. If you're unlucky um you have to guess and that's really hard and at that time maybe you should like look for something else or just you know you're going to spend a lot of time on that. So we want to uh patch the eProm now so we can enable the console. The plan of action is we know the read write commands uh we want to interface with the flash so to do that um sorry the eProm we um we need like a spy uh device and we've seen before the best pilot is a perfect candidate for that. And we need to connect to the chip uh unfortunately like it's a really tiny one and so like the clip I was showing are like too big for that. You can buy online some rigs that people make um it's like expensive and it's like five weeks to get them. So instead I went kind of crazy and I tried to solder like um little wires onto the thing and I was like honestly that's never going to work. But it happened to actually work and I was like sweet and it's all like look like cross because it's like all the flux that remains on that. Um and that's the code for the best pilot. It's super like boilerplate uh thing and when you just write um this magic values that uh sorry I was asked to like replace them with like emojis. But uh the idea is like just after that you're greeted with console is set to uh like you are zero and now we have a lot of more stuff uh printed on console which is great. But unfortunately I get like this a harder like the input are still like not working. I was like trying to press space or type like it's like asking for oh you want to look at the route? What's uh it have nothing happened like what happened? It's like just cut the trace so you cannot send data. We have the board so we can look at it. Um so uh that's just like uh zoom up on the thing and at that time I was like you know looking at the UART pad and stuff like with my multimeter like trying to beep out like where it goes you know it's following the continuity testing and eventually it reached some wires like on the right side and the wires are that little hole that connect one side of the board to the other. So the trick is the actual like trace that connects the UART to whatever uh goes to the other side of the board and goes back and forth and it's like really like tedious. And eventually I kind of lost where it was going but it was kind of under that the mode port uh that's like the keyed uh RG45. Um and so um remember like the recon side uh recon part um we have that box and it's like oh damn that's the thing. So I kind of went to like my Yoru approach again where um I was holding like I had a plug like a jumper cable in my um the transmit of my FTDI cable and uh so I had like this like wire that I could poke around and on the other side I was like pressing keys on the console trying to see if something happened and meanwhile I was poking like to the pins one by one and I think at the second one it actually worked and I got greeted by uh like a wood shell on the device. So that was cool um but the trick was um on the right side of like a proper setup where I plugged my ethernet cable into the plug. So at that time I didn't want to know where the keyed RG45 was so I just like sanded the plastic of the ethernet cable so I could like shove it in and yeah it just works so that was nice. Uh now that we have a wood shell it's like uh a lot of debug strings pre-prene on screen and that's annoying. So um the trick was like I want to kill the process that's like floating my console uh as I said watch dog that's going to reboot the device if that happens so I uh highlighted in the corner like the magic command that you can run to kill that. It's just like random Linux stuff. Uh so now we can finally do some very research um and really what you're doing to do is like look at process running, poke around, look at open ports uh that's just a bunch of processes uh you see cool stuff but uh that's when it started getting interesting. I think at some point I was tired of looking in Ida and I was like I'm going to poke more and I looked at DH client and I was like huh. And the really funny part is like I run DH client and I see this like 2007 copyright I was like whoa that's not a good thing and if you just run DH client by itself it's like false. I was like that's weird and if you like run it the right way they print a debug message and say oh we modified it to work it better on our device. And I was like huh that's interesting. So if we look back uh and we look for the specific version it turns out that ten years ago actually for Defcon uh John Oberhide um really is like an exploit for that specific version of DH client so I was like whoa that's that's easy. Um but we want to make sure that it's actually still vulnerable so um the fun was like uh dumb like um stack overflow like while handling DHCP options. So we can compare the original source code with the patch source code because DH client is open source and just to keep in mind that might be like mitigation like stack cookies ASLR or whatnot. So if we look at the vulnerable code on the left side we can see a mem copy like I didn't read that's using like data.lane as a field while on the patch version that we replace that by four. So the idea is like this bug is uh subnet it's a bug in the subnet mask handling and the subnet mask should be like four bytes but the way the DHCP option works is that you can send up to like 255 bytes I think and it used to just don't be trust whatever you're sending which is bad. And if we look in either like the actual like function uh we can see there is no stack canary and the on the left on the right side it's it's not using that magic force so it's it's obviously like still vulnerable. So it's time to exploit stuff um working on the fun was tedious I was like I'm going to try to set up QMU um if you're not familiar with QMU it's can do like emulation of arm stuff or like many other system and can do either like user land or full system. User land wouldn't work here because uh DHCP is uh we try to modify an IP and stuff and that's not cool um but instead we can do a full system emulation and uh those tutorials tell you how to like set up a cool image for that and we just want to set up the network properly uh because we want to interfere with DHCP and naturally um the um QMU stack would give you a ditched DHCP for yourself so you have to be stay like don't do that and yeah. So I run it in DH in QMU and after like all these I thought and it's still stake fault and like huh. So it turns out that like I modified stuff that actually causing the stake fault and um I'm not going to cover that too fast because I'm running like a little over time but uh basically it's creating that weird socket uh it's like a named socket and uh so that's like the main application that the VOP stack can talk with DHCP and share options um and uh the idea is like that's like the main application and we can see what it does. That's not super interesting but basically on the left side is like sending data to configure the HCLI and that start up and on the right side I reimplemented that in Python and uh you can run that with like sockets um so socket is just a kind of like netcat in um more like uh more tools so you can create that name socket and the idea you run the Python script on the host you run sockets on the um QMU like binary image and it would just work. So now we can start debugging uh DHCP clients um you can run GDB we can try to like actually run the Pock uh I couldn't compile the original proof of concept it was like using really old tools and it's just after like a couple of hours like I was like ah fuck that I'm tired. So instead I use a Skape based uh exploit Skape is a Python library that lets you like you know mess with uh network packets like a fairly low level. And um so now we want to like reach the um uh venerable code so um I was explaining the bug is in the subnet mask option and the way DHCP works is like a tag length value like type of stuff so you say oh this option is a uh subnet mask here's the length here's the value and obviously it was like it should be four but if you send more it's fine but for the DHCP specs and so we can use Skape for doing that. So uh that's my like a chunk of my Skape script and just the payload in purple is interesting. Um basically just sending the subnet mask option with uh data that would be like AAAA, BBBB, CCCC and so on and so forth so that uh when it crashes in GDB uh we can see like all the register we control and we know um exactly um you know if we want to affect which register which chunk of the shell code we need to change. And we can see that we actually controlling uh PC so the program counter so that's good. We know that we have um we can exploit we have control for execution and there are like a few more details that I'm going to skip over but um we need to scour uh to craft a shell code now uh unfortunately like it looks like the stack is uh you cannot execute the stack so we would have to warp it and that's tedious. But um cool stuff is like if you look for there is like a system calling that binary that I think also a Viya added and we do control R4. So if we put us if we can put a string in memory in the address we know that could be a valid like system command and put the address in R4 we're good. Um so if you think about it DHCP clients DH clients we receive configuration values from the server so probably there is going to be stuff that are stored somewhere and um it turns out that ASLR is disabled sorry I forgot to mention that. Um but then we the idea is like I just send like sending like AAAA's as like a bunch of uh options and look at memory to see if I could find that string somewhere and eventually eventually the domain option was a good one and so um now I can show you uh a cool demo that's how I happen when you actually run the whole stuff. So uh on the um on the left side we have the phone that's booting. The phone is booting and the window uh the terminal window is like on the left side is a rogue DHCP client running on payload and on the right side is um it's a web server that will provide like a post exploitation kind of stuff. So we can see the packet is running. To make sure it works I was cutting uh Dev random on the uh on the screen so that's why it looks like noise. It's fetching data from the um web server and I don't know if you can see but it's loading like Steve.data uh FYI like Steve is actually my uh boss that's him. And uh just then I'm uh still like I don't know if that sounds but I'm exfiltrating audio from the main speaker and you can see in VLC that when I'm speaking and clopping my hands it's actually like reading the audio on the attacker laptop. So that's pretty scary because you can turn your um phone into um you know listening device. Thank you. So um yeah and just FYI like all the tools I use are like actually already on the phone like you're like netcat you're like stuffed to like dump the audio to like STD in so you it's just like writing some shell script like bash script whatever. And then you can see the dump the audio to like STD in so you it's just like writing some shell script like bash script whatever. So um as a conclusion uh for mitigation like you want to make sure you monitor your network so that you don't have like punks like sending uh you know like weird DHCP packets and uh actually like McAfee uh firewall like can detect that uh FYI. You want to segregate your network um to make sure that for instance the coffee pot is not able to like send weird DHCP packets to your phone and make sure I actually patch your phone because you know it's the patch got released like I released the patch like a month ago so make sure it's actually patched. And uh if you want to think about why this kind of bug happened like the technical debt is really hard to handle and you know probably like someone had like in good faith um okay um someone in good faith um forked the stuff and they forget about it so um and just as a real quick um embedded systems are not black boxes so I would just encourage everyone to um look at them and uh you can do it now as well. So if you have questions uh ask me on Twitter or whatever and thank you for your time guys. Thank you very much for joining us for this recap of our presentation.
 Without further ado, because we stay on schedule.  Felipe is here from Portland by way of France, from what I understand.  And he is going to talk to us about breaking into embedded devices, including phones.  Phones that you might have on your desk at work.  Phones that might be...  I'm not even going to get into that.  Phones that might be around.  Let's learn about embedded device hacking.  Let's give Felipe a big round of applause.  Have a good time, man.  Thank you.  Thank you, everyone.  I'm really excited to be here.  It's like a big honor.  Today we're going to talk about hardware hacking.  I'm going to share this introduction to it.  I hope I can share some love about hardware hacking.  Who am I?  I'm Felipe Lodorette.  I'm a senior security researcher at McAfee, adventlet research.  I do software and hardware volume research.  You can find me on Twitter at ph.lol.  Before joining McAfee, I spent two years doing embedded security.  Before that, I was a C++ dev.  I'm more coming from a software background, actually.  You could wonder why should you care about hardware hacking in the first place.  I can see two main reasons.  First, it's actually really fun and empowering to be able to break open a device that you're  having at your home, at work, whatever.  Instead of considering that it's a black box, you can start poking at it and understanding  how it works.  Then in a more pragmatic way, if we consider security in the past couple of years,  software is becoming much and much harder to break.  If you try to, I know, like, find a world in a web server by itself, it's kind of hard.  But if instead you can just open the device, solder a couple of wires, and get a shell from  that, that's much easier.  So hardware hacking is great because it's also like a lot of low-hanging foods, basically.  So today we're going to talk about Avaia phones, and especially like the phone picture on the  right side of the slide is a 9611G model.  So Avaia is like one of the biggest view IP solution provider.  You can find them like all over the place.  It covers like 90% of the 4100 company, and I think that's a specific model of phones starting  in 2006, and it's going to be enough life at the end of the year or something.  And the funny, on the bottom right of my slide, there is this funny like a screenshot from like a  firmware download page from like a really old software for these phones, where actually  like you can see that you can only download that specific firmware if you're like a DoD  customer.  So basically you can see that these phones are like going to a lot of different places.  So regarding prior art in hardware hacking, there's like a lot of information nowadays  on the internet, like you can find a lot of blog posts, tutorials.  There's like the hardware hacking village that you all go and check out.  CTF as well, where you can like practice like kind of like the software side of stuff.  And on my slides, there's like a bunch of links at the end, so you can like download the  slides at later time, and also those slides, I've like the one I've uploaded, I have like  more text on them, so it's like more like standalone, so you can read more.  And yeah, RedBalloon Security found like two assies in the same phone, something like five  years ago or something, and I like a talk at RSA called Stepping Ponds that I would also  recommend to check out online.  So for the next 40 minutes, so I'm going to talk about hardware hacking and use that  phone as a base to like support that conversation.  And basically the idea of like the whole situation is like couple of like 12 years ago maybe  a very forked some open source code and they never applied security patches to that.  And it turns out that like me by poking at the device, I found that and it was like women  like unnoticed for like 10 years that they were like actually like a CVE that got released  like 10 years ago for DEF CON.  So I'm going to talk about how I found that, like that it was like some stupid like you know  code inside the firmware.  But more interesting I think is talking about the whole process, you know, like how I did it  and why I did what I did it.  Why I did stuff I did when I did it.  You know like basically like sharing the process so that and you know also like sharing, you  know what if the stuff I tried didn't work or also like stuff that didn't work because  you know what works for one device might not work for another and having just like that  mental model of what we can do and what we cannot helps you a lot approaching like any  kind of device and that's I really think why I want people to take away from that talk is  more like learning the process so that you can check out like whatever device you have.  And yeah I would want to like insist that if I can do it I think everyone in this room  can do it as well.  As I said more from like software background and hardware hacking is still like you know  like a little scary little foreign to me but it's in the end it's really not that hard  if you have like a good process and you know work with patience.  So how did the whole project start?  To be honest I was like you know working at work and we were like all these cubicles and  on every desk I see this like phone like standing on the desk.  I'm like wait a minute these phones run Linux they have you know network access they have  like mics and stuff it's like how secure is that you know like you wonder like what's  up with it did people consider the security of those?  So the first step before you know even like I start like stealing my co-workers phone and  breaking it apart you can and that's general step is you can check out the FCC website  usually like any device that has Wi-Fi or Bluetooth has to be on the FCC website for  like compliance reason.  So that's what I found that's not my phone that's like a other model of like same brand  basically and like really close.  So you see all these cool pictures but more interesting is the inside of the phone.  So we can enhance it and on the left side in red I've highlighted like this like random  debug connector I don't know what it is but that's interesting to see that's there.  And on the right side there is like that like in purpose there is that flash memory so  that's usually where the file system of the phone is going to be stored and the whole  point of that is just to get an idea of what to expect you know before even approaching  a real target like burning hardware and stuff so that you know like if it's going to be  a easy target or hard target you know if everything was covered in black epoxy that  would be harder.  So another important step is like getting like online material like you know marketing  brochures so you have an idea of what are the phone capabilities and the ecosystem surrounding  it so that you have an idea of you know like the attacks your face and you can also find  like user manuals and stuff and for instance I found that one that was pretty cool it's  like a user like our advanced user manual that says oh if you want a serial connection  to the phone you need that funky box and yeah which is interesting it teach it tell us that  yeah you can find a serial connection and you may have some special hardware for that but  are we going to see that in a bit.  And after that you also want to check like forums and so that you can find like what  poor user are doing like for instance I found like the default password for the phone in  debug interface because a system admin so here I talk talking about that online and  if you're lucky you can also download the firmware of an idea of what's up there and I  will cover that in a minute.  Okay so what do we do now?  We have an idea of like what it might look inside.  This is a hardware hacking talk so we're going to avoid warranties and so the point is like  you open the phone first and the trick is like usually you always expect to find the same  stuff inside and if you look at the labels of the components you will see and you google  that you will find out like what it is.  So for instance that's my phone and you can see in the center the CPU above it like the RAM in  like a lavenderish color like some unpopulated like header that I marked with a question mark.  This I think the same header as the one we were like seeing in the picture before and it might be  JTAG I did not have to use it so I don't know actually.  In purple we have like the AEPROM so that's what the whole like some settings and stuff.  In dark blue in the bottom of the slide is like a keyed LG45 so I was kind of confused when I was  looking at that and I didn't know even the term for it and the idea is just a regular LG45  like Ethernet plug but with a weird connector so that you cannot plug the wrong stuff into it.  And more interesting in yellow the UART so it's UART is kind of like the serial console and we have  like this exposed like pads and so usually like in manufacturing or something you would have like  Pogo pins that would like directly connect to the pads and that's that one is actually really  interesting because you would expect to find a serial console on that and on the back we can see  the same name flash that we've seen in the previous picture and yeah from that is like where the  file system would be like stored on the device. So okay you have we looked at the stuff inside  and like other thing that's interesting to look at is like test points and debuggators so and  like basically all these kind of stuff that are not components and you can ask why would you  expect to find them inside and couple of reasons like one is like just usually like the death  board that the guys are going to use is the same as the production board and maybe they're just  not going to solder the debugg components it's the same as if you had like software and it was  built with like debugg symbols for instance and also like part of the manufacturing process  this test points and stuff might be used for like flashing the device or making sure it's flash  properly and sometimes you know like something died or something like that and you know like  something died on in the real world and they want to like do a post mortem to understand what  happened and that's useful as well. So what kind of stuff you want to look for in that situation  you want to look at UART that we like looking at before JTAG that I'm going to cover in like  in a minute and then like you can also have like random test points that are chilling there like  all over the table all over the board and there might be like long test points like like TP1, TP2  whatever and sometimes that might be like not interesting to you but sometimes you can find  interesting stuff like you might find out like oh if you short like TP64 with ground it's going to  reset the device which might be actually useful in some extent. So looking at UART so as I said  this for like serial connection and it comes in like three or four pins the three pins will be  ground transmit and receive and the fourth pin would be like VCC so three volts five volts  whatever and usually you don't care about that one you don't even want to plug it you don't have to  and the trick to know is the serial console send data at different speed and there are only like a  couple of it's called like both rates and there's only like a few common both rates value so if you try to  plug your system into the UART and you just see gibberish on screen the probably the reason is you just  have the both rates wrong and you could just like try to cycle through like all the possible one and  you would find something eventually I think. JTAG is another one that's interesting so that's for  like hardware debugging and with that you could like you know debug the CPU usually and execute  like instruction by instruction and whatnot and they come in many different shapes number of pins  and whatnot so some example like on the bottom of the slide but actually only a couple of wires  are interesting and at the end of the slides I was like sending you an article about like  understanding JTAG better but basically like if you look on the top right side of my slide there  is like a dev board and there's like a nice JTAG connector like plug there and on the other hand  like on the bottom right it's like some random device I was looking at which you can see there  should be a JTAG but it's never been soldered on and so I had to solder directly onto that stuff  and the trick to remember here if you kind of like solder your own connector is you actually may  have to add like extra resistors called like pull up and pull down resistors that connects like  one pin to ground or one pin to like VCC and the point of that is actually I don't know the point  of that but the reason is like if you don't have them it might not work well or it's more work  most of the time it's going to be glitchy so and if you follow the instruction from like for  like our ARM specification for like what resistor you need so you might skip them but then you might  waste time like understanding why it's a weird really like fucked up sometimes so I would  recommend like remember the pull up and pull down resistors so that's just a random board that  my co-worker was looking at just to show you that what I said is actually fairly generic on the  left side we have like few art on the right side there's like some JTAG connectors uh there is the  uh a price there is like the main CPU whatever that's under like a shield and usually you do that for  um preventing um interferences so it's like a Wi-Fi module so that's why and the cool thing to know is  usually the shield is grounded so like if you're looking for the ground on your thing like either the  shield on that kind of stuff or like the casing around the internet port or whatever is also actually  like fairly useful so uh now that we learned how to uh look into stuff we need to know what hardware  you need for um interfacing with what's inside so I'm going to present like a bunch of cool  hacking toolset that's important so the first one uh you may want this pin or like the stickers I  don't know if you're familiar with that but um actually like what's really important is like safety  um so you know don't work with stuff that's plugged in the wall uh remember to unplug stuff work in like  well ventilated room it's important and uh yeah just don't be stupid when you're like uh  messing with hardware uh but yeah so next picture from the lab uh I'm holding um soldering iron  you can usually switch tip for like if you're like large tip for like big soldering and tiny ones for  small soldering I have a microscope so that's really useful for doing uh tiny soldering and the trick is  I tend to drink a lot of coffee and I shake so I would I was thinking like I couldn't do that but  actually if you um if you're careful and the trick is like really like try to um you know when you  bring like try to hold your arm like straight and well grounded and under the microscope you can  actually do a lot of stuff that's you just don't think you you wouldn't be able to use you would  think you shouldn't be able to do it but you actually actually can. Sorry um top right side um  it's what I actually use for doing tiny soldering and um it's like top right like flux so it's kind of um  magic glue magic uh gooey sti- substance that you put on um pins to uh when you're soldering  surface mount or pads so that it works really well so don't never forget flux uh bottom is um  like in the same uh size like uh copper wires like um NML wire that you use usually for making  cords you know for like radio or whatever um and the trick is like the uh the wire is actually um  coated in uh varnish so it doesn't uh short and you can use that to do like really tiny point to  point like soldering and that's actually really useful and just next to it you have like some  desoldering week so like the idea is if you put too much solder and you fuck it up uh you can put  the week on top of the solder blob that you messed up with and you um put the soldering iron on  top of that it's going to get really hot so you want to hold it through like the plastic casing  and it's going to absorb all the like extra solder and you can clean up your stuff. Then I put  like a picture of like some random like uh jumper wires that are usually always useful to have and  on the bottom right I have like that crazy uh heat gun uh which is like 60 bucks at Home Depot  it's meant to like help paint dry or something I'm not sure but it's actually really useful for  if you're on the chip if you want to remove components by just like hitting them and pulling them off.  So um more cool hardware um that's a multimeter um if you're not familiar with that it's you use it  for um fine voltage of chip you don't know like what's the actual voltage so the black goes to  around and with the red you uh with the right probably you select poking around to measure the  voltage and the other really cool stuff is you can set it in continuity mode and when you have like  connection between the two probes it beeps so if you do like crappy soldering job as I was  describing just before you can make sure that you actually did a proper job where like everything is  connected the way you think by you know making sure that both like when you probe like both sides it  actually beeps and that's actually a fairly useful uh tool. The other one is this is a logic  analyzer uh the name is like a Sally um that's a brand and the idea is the same as in software  you have like ways of communicating between process like in hardware you have like ways of  communicating between chips or the CPU and the chip and it's uh it's like a lot of different  standards different ways of doing stuff but the logic analyzer like know a lot of them and it's going  to convert like a bunch of signals that go going on to wires into actual data and that's actually  really useful that would be your eyes like when you're doing debugging you know and that's like a  some spy communication uh which spies just some random protocol uh that's like an FTDI cable  also come in many uh or serial cable it comes in many different shapes and stuff and the idea is  just like when you want to do like UART you you plug that into your laptop and you connect the  other side to like the UART port and you get like a console it shows up at the serial port and uh  as an example I have uh on the bottom right um like a Raspberry Pi that's you can actually get a  serial console and you don't need like HDMI cable or anything to interface with that.  Whew um the bus pirate uh also like cool device um it does um it's kind of dependent of the hardware  hacking uh sorry the um the Sally the logic analyzer so instead of absorbing data it's like send  data so it speaks a bunch of different protocol and you can use Python to program it so it's  very useful if you want to like read flash program um microcontrollers and that kind of stuff.  Uh more cool stuff like how about I was talking about JTAG that's the JTAG debuggers that you  that's why you would plug actually like the the JTAG port on they come in many different  like uh price range and what not so on the bottom right is a fly swatter it's like probably like 30  bucks I think and it works okay and above it's like a J-link which is more fancy and the idea is  expensive the stuff is the more probably the more reliable it is and it comes with like better  software and why not and on the bottom right the pink board is a JTAGulator that uh Joe Grand the  same guy we met like those badges uh made and it's really awesome so if you have like that board  you don't know what it is and there's like a bunch of test points and you're like I bet there  is some JTAG somewhere in it but you don't know where you can just wire like all the test points to  the JTAGulator and it's going to brute force like and try to find everything so it's really cool um  another interesting important tool is flash readers so um usually flash content uh the flash has  the file system and stuff and uh so you want to like interface with that and uh it comes in  two flavor I guess you can do like in circuit stuff so you have like either like a little like  clamp that you put on the chip or like the little rectangular one um and the clip on um so like  the Raspberry Pi is a good one for that and on the top right is like a flash cat uh it's like  for the rectangular one um but you can also like choose to like actually disordered the chip  and in that case you would have like some like like socket adapter so you can clip the chip on  and then you plug it into your flash cat or whatever and it's going to read it and I will cover  like why what's what's why it's important like both in a minute and finally it's kind of the um  last uh hope so let's say uh you know your flash is encrypted there is no UR there is no  firmware so you can try to do like the more crazy stuff like fault injection and side channel  like so that's a chip whisperer so like more like uh kind of hard more badass device and the idea  with that is um it you can do stuff like um you you uh wire it and to the CPU and you're going to  drop the power on the CPU for like a split second and it's going to like mess up some instruction  and you can bypass checks and stuff that's what people use for like gaming console hacking and  um that kind of stuff so uh what do we do now um that we have an idea of what's inside the phone  and um you know um the tools we can use so like I think the three post potential track one is  messing with the UR so the serial console and the other one is messing with the flash and trying to  recover the firmware or something and then maybe you can just download the firmware online and the  three are like valid approach and sometimes it's good to just go from one to another to another  and you know whatever you find like some hurdle you can like go from one to another uh so I want  to go for the UR first and that's what I'm greeted at by when I connect my FTDI cable to the UR  port that I was showing before so we can see like on the left side the um the console thing  it's like dot dot dot usually when you see that you can press space or escape and it's going to  interrupt the booting process of the phone and in that situation uh but somehow here it didn't  work and uh I will cover that why in a minute and on the top right side of the slide um we can see  it read something from the eProm and decided to set the console to DevNull. So you don't  want console to be DevNull because that goes nowhere but that's interesting to know that  there's some potential there. And finally it says like booting Linux so it can confirm  us that it's a Linux board but then there is nothing more after that. So that's some good  thing, bad things. So the problems are like nothing shows up after like the Linux is as  booted probably because of the DevNull situation and when I press key it's not working and  I'm going to like come up with like why that happened. So at that point I was still like  okay I cannot go anywhere so I'm going to try to recover the firmware to try to understand  what's up with that. Multiple ways of recovering firmware's is like an easy way that you can  download it online and actually that worked. There is like some cool snapshot of that. Sometimes  encrypted on our case it wasn't. But yeah so you can also try to sniff a firmware update  that's really useful for IoT devices in general and you can use a network tab which is like  the thing pictured on top right of the slide. Or you can mirror your port on your switch or  whatever. The problem with all of that is oftentimes the firmware update is going to do  over like HTTPS or it might be and in case you're like stuck. And then you want to go for  like a more like hardware hacking stuff like you're going to dump a flash for instance. And  there's like even more advanced techniques that I will briefly like talk about. So how do  you dump a flash? There is two ways as I was mentioning just before. You can do in circuit  programming and out of circuit. So in circuit is cool because you don't have to you know like  remove stuff, break stuff. But a couple of issues with that. The main idea is to read the  flash. You need to power the flash. And if you if it's like still plug it into the whole  system. When you're like Raspberry Pi for instance going to try to read the flash it's  going to try to power like everything else that's connected to the same like in a bus line,  a power line. And either you know your Raspberry Pi is not strong enough to power like a  V-O-I-P phone which you would expect. And in that case, but it's just not going to work.  Or maybe your Raspberry Pi is really strong and it's going to do it. But then the problem  is the CPU start booting and it's going to talk with the flash and that's going to mess  up your stuff. So in that situation you have like two choices usually. Either you can try  to like lift up the pin, the power pin so that it doesn't happen. Or you can kind of go a  little more like a low approach where you want to keep the CPU in reset. So I've been successful  with that many times where I just like start like trying to ground like random test point of  stuff on the board praying that it's not going to fry anything. And usually at some points  like I'm going to notice that okay when I do that the phone like light up but doesn't boot,  that's good. And maybe better ways you can disorder the chip with like the big like  heat gun and whatnot. You have to be careful though because if you like pull it too hard  you might like bend pins and it's going to be like useless. But a good trick to know is  like you can make a little like tin foil a hat or whatever like around the chip so that  like when you're heating up the chip like the stuff around it doesn't like get too hot.  So you don't accidentally like knock off like some like tiny like components that would be  like a pain in the butt to put back. And bottom right is like I was, I thought I would have  to do that on the phone so I wanted to practice first and I just took like some random USB  thumb drive and I tried. And actually that worked really nice. But the trick is remember I  also put some plugs because it helps. And yeah just don't be careful with when you pull it  off. A few other tricks that actually didn't work on this one but are good to know. Uh  U-boot is the most common boot loader uh not used here but it's you would find that  on pretty much every other device. And the idea is you can also interrupt the boot process  of that and ask nicely U-boot hey can you load the flash in memory? And then uh U-boot is  also able to dump in a hex like in the screen. Um the the memory is this way you can just  like write little script to do that and recover everything on the flash which is really  cool. But usually like dev don't like letting you do that so they set they lock that  approach so you cannot like press space when you're in the boot process. But there is a  trick that I also call like the YOLO approach where um instead when the idea is like U-boot  is going to load from the flash like the the new kernel or something. But if while it's  happening you start like poking with you know like a wire that's connecting to ground. You  start poking the NAND flash like some of the pins. It's going to mess up like what uh  U-boot is reading. And after a couple of tries uh U-boot is going to be like damn that  kernel is fucked up. I don't know what to do and it's going to give you like a shell. So  that's really cool. But yeah as I said that one wouldn't work on our phone unfortunately.  But there are just some cool examples that I found online where like some guy actually did  that. And uh I underlined in uh in like purple on the bottom like the command you need to  use to like load the the flash in memory. And on the right side this like little block of  text is um sorry is how uh U-boot is panicking and be like eh I don't know how to do with your  kernel. And give you the the shell. So um so a few more like tricks for um dumping the  flash. So you can use JTAG. So usually you have uh if JTAG works you're going to be able to um  dump the RAM. So in this case that wouldn't be really like dumping the flash. That would  mean the firmware. But in a lot of devices it's going to load the whole stuff in memory. So if  you can dump the memory you are like the same. You're pretty good there. And kind of the last  hope but that's one of my favorite about hardware hacking is you can do crazy stuff. Um and an  example is uh ScanLime um that person on the internet who um she had um a Wacom tablet that  she wanted to dump the um the firmware off. And there was like no attack surface at all. But  she realized that like when you just like USB stuff. So when you plug your USB um onto the  laptop there's some USB exchange that I don't know anything of. But it sends like USB  descriptor. And if you if you glitch the CPU just at that time um it's going to like you know  miss like a boundary check and it's going to send away more data. And with that uh she was  able to recover like the full flash uh full memory or something. So it's really impressive but  and that's what's kind of awesome about hardware hacking. Okay so uh we recovered the  firmware uh in my case just by downloading online. But what do we do now? We want to  analyze it. Um the best tool for that is called Beanwalk. And it's just basically a magic  dictionary that's going to like look at your binary blob of stuff and be like hmm halfway  through it looks like there's a zip file. I'm going to try to extract it. It tries. Maybe it  works. Maybe it doesn't depending if it was actually a zip file or not. And it does that for  everything. And uh it might also find like compressed file system uh such as like Squash  FS, GFS2, etc. And sometimes like your um your firmware file might just start with like  health headers or just like random like ARM code that you could like look at. So I run  Beanwalk on the so that's the firmware file I've done on it from the website. And once again  it's easy mode. It's just a tar file and they already like split it up into boot one, boot  two and GFS2. So like Beanwalk has nothing to do here really and I can just extract the  whole file system. And that's cool because from there I can look at what's on the phone  just like that. Uh but the more interesting use case for Beanwalk is I took like a different  firmware file for like another Avaya phone. And this one is way more interesting because  Beanwalk for find like a way more lot of stuff. And uh I've highlighted like you find the file  system and is able to extract it. And there's also that random like MySQL stuff which I think is  false positive. Then you need to be aware that there will be a lot of false positive so don't  blindly trust what Beanwalk says. And uh really really funny stuff that I was looking at uh if  you run strings on that specific image um you will find like U-boot strings. So that phone is  using U-boot and the cool stuff I was describing before would actually work on that one. Look.  So now that you have extracted the firmware file what do you want to look for? One of the most  uh interesting stuff is uh finding the update mechanism. So assuming you have uh encrypted  firmware like if you reverse engineer that you might find the keys and how to extract like  subsequent uh firmware updates without having to do like any hardware stuff. And then you want to  look for like secrets like passwords, certificates, and so on and so forth. Uh originally my goal was  to look at the main binary so that's the thing that deal with like the VOIP stack uh that could  make sense to look at that. And um also you want to look at the bootloader because it may have a  hidden command, explain why our console is not working, that kind of stuff. So remember the  point of all of that was I wanted to get a shell on the device and um what's the process to do  that? So the one I want to go for is I want to fix the serial console you know like the dev  null was not cool. Um but also our approach would be like messing with your boot arguments. Um  not working here obviously. Uh but you know you can specify the console you want and uh the  init script can be marked as like oh I want bin bash as my init script and then you have a  console. Uh and like kind of last resort stuff that I was considering as well is you could  patch the firmware uh in our case the firmware is signed so uh that won't work unless you try to  glitch it which really hard. But you can also try to patch the file system so the way bin work  extract the gffs 2 stuff you could modify it and then like repack it and flash it directly onto  the flash. And that's usually like a foolproof method like that would work in most cases. So  instead I'm going to uh reverse uh um the bootloader and um for that um because I wanted to  understand like why dev null uh the console was set to dev null and stuff. I'm going to cover arm  in much detail and I would recommend you to check out azalea lab tutorials that cover everything  but just useful here um there is this notion in arm of literal pool which is um inside the code  section you would find some little chunk of data and that's usually like used to like load in  registries um absolute addresses, imended values, magic offset that kind of stuff. And uh  FYI like in case of function calls um the arguments are going to r0 to r3. The return value is  r0 and when you like want to return from your call it's the return address is saving like the  lr register that stands for like link register. Um and the big trick, the big problem here is um  we like trying to load the bootloader so it's uh it's not really elf. So if you try to import  it in IDA IDA doesn't know what to do with it. And so you need to find the loading address for  that stuff so it match what's where the phone is loading it. Couple of tricks um so none of your  lucky end is going to be printed on screen. That's our case, sweet. Um but otherwise we want to  look at like header file, headers in the in the bootloader file or maybe reset vectors that's  stuff where like specifically for ARM like the CPU needs to know uh specific addresses where  like there's like a reset or like an interrupt happening and it's like fairly like um square  like that how that's being set up. So if you find that and you find like what looks like an  interrupt vector handler or something you can find like oh that must be the address. And uh  finally the literal pullout was mentioning uh really useful because it's going to contain like  absolute addresses or point to strings and stuff so uh if if like you have strings and they look  like all fucked up you probably got the wrong address. And uh QuaxLab uh what a blockbuster  body so I would recommend you checking it out. So as I said in our case it was easy um when it  boots it prints uh the jump whatever and that's actually why you should load it. And um on the  bottom right side it's like a bunch of strings um so it's a bunch of addresses that point to  strings uh this is not from IDA and um we can see that um it's like all the strings like prints  well so that means that it's loaded properly it's not like all messed up. Okay so now that we  have the bootloader and we can like work it with IDA uh we want to search for strings uh we were  looking at you know like that sentence like EEPROM, Red Successful, whatever. So we can use like  cross-reference in IDA to find where the string is coming from and look at the function that  handles that. And uh yeah just as a FYI about like EEPROM and SPI so the EEPROM that's on the  board is called a SPI EEPROM and SPI is just one of those protocol I was mentioning before. EEPROM  is just like a small memory um whatever and the SPI uh protocol is just like four wires um and the  IDA the CPU is sending command and the EEPROM like reply and uh that's a dump from like using the  logic analyzer to have a look at what it would look like in real life. Uh that's the data sheet of  the EEPROM uh that you can find online if you google the label on it. Um the cool thing is in  bottom left uh of the slide it tells you like the pinout so you know how to connect stuff to it.  And on the right side of the slide um it tells you which which opcodes are for like the  co- SPI command you would send. Like for instance if you send uh three it's going to be a read,  if you send two it's going to be a write. So that's uh that's something useful to know right.  Oops sorry. Back to the um back to the IDA and uh the bootloader we can see uh the strings we were  like looking for and something extremely promising is we can see the console set to DevNull but  above that is like a burn to those options and it's actually saying like oh setting console to  like your zero or your one. So we want these ones to be printed. Um that's a that's a function  that actually does print that string and uh what it does is roughly uh clear some bytes on the  stack and then read from it from from a magic address and it's going to compare like bytes um  that has just been read. And if we have the good value it's going to actually print on the  console setting the console for uh DevTUI uh AM zero. So we want that to happen. Uh and  something you can ask me is like well how did you find that read-uprm function you know and  there like multiple ways of doing that uh the easy way that I've highlighted in green in that  screenshot is uh on the bottom right we can see some like logging that says oh eProm read  fails so I know that function is responsible for reading eProm uh but maybe maybe the  firmware you're going to look at is not uh as verbose in which case um as I said before like to  read from an eProm you know you have to send three over SPI so if you find like the SPI  function and you see like sending three you know what it is. That's what I've highlighted in um  yellow. Um but then like how do you find the SPI function you know it's kind of uh problem uh  two ways for that um in my case once again it was logged so it was easy but usually like the  main trick is um you have this um something called uh mapped uh IO a memory mapped IO and it's  this kind of like magic address values in the CPU that like if you write to them it's actually  going to send data over like your auto-SPI or whatever. If you're lucky you're going to have a  data sheet for the CPU and it specifies exactly what are those addresses. If you're unlucky um  you have to guess and that's really hard and at that time maybe you should like look for  something else or just you know you're going to spend a lot of time on that. So we want to uh  patch the eProm now so we can enable the console. The plan of action is we know the read write  commands uh we want to interface with the flash so to do that um sorry the eProm we um we  need like a spy uh device and we've seen before the best pilot is a perfect candidate for that.  And we need to connect to the chip uh unfortunately like it's a really tiny one and so like the  clip I was showing are like too big for that. You can buy online some rigs that people make um  it's like expensive and it's like five weeks to get them. So instead I went kind of crazy and I  tried to solder like um little wires onto the thing and I was like honestly that's never going to  work. But it happened to actually work and I was like sweet and it's all like look like cross  because it's like all the flux that remains on that. Um and that's the code for the best pilot.  It's super like boilerplate uh thing and when you just write um this magic values that uh sorry I  was asked to like replace them with like emojis. But uh the idea is like just after that you're  greeted with console is set to uh like you are zero and now we have a lot of more stuff uh  printed on console which is great. But unfortunately I get like this a harder like the input  are still like not working. I was like trying to press space or type like it's like asking for  oh you want to look at the route? What's uh it have nothing happened like what happened? It's like  just cut the trace so you cannot send data. We have the board so we can look at it. Um so  uh that's just like uh zoom up on the thing and at that time I was like you know looking at the  UART pad and stuff like with my multimeter like trying to beep out like where it goes you know  it's following the continuity testing and eventually it reached some wires like on the right  side and the wires are that little hole that connect one side of the board to the other. So  the trick is the actual like trace that connects the UART to whatever uh goes to the other side of  the board and goes back and forth and it's like really like tedious. And eventually I kind of lost  where it was going but it was kind of under that the mode port uh that's like the keyed uh  RG45. Um and so um remember like the recon side uh recon part um we have that box and it's like oh  damn that's the thing. So I kind of went to like my Yoru approach again where um I was holding  like I had a plug like a jumper cable in my um the transmit of my FTDI cable and uh so I had  like this like wire that I could poke around and on the other side I was like pressing keys on  the console trying to see if something happened and meanwhile I was poking like to the pins one  by one and I think at the second one it actually worked and I got greeted by uh like a wood shell  on the device. So that was cool um but the trick was um on the right side of like a proper setup  where I plugged my ethernet cable into the plug. So at that time I didn't want to know where the  keyed RG45 was so I just like sanded the plastic of the ethernet cable so I could like shove it in  and yeah it just works so that was nice. Uh now that we have a wood shell it's like uh a lot of  debug strings pre-prene on screen and that's annoying. So um the trick was like I want to kill  the process that's like floating my console uh as I said watch dog that's going to reboot the device  if that happens so I uh highlighted in the corner like the magic command that you can run to kill  that. It's just like random Linux stuff. Uh so now we can finally do some very research um and  really what you're doing to do is like look at process running, poke around, look at open  ports uh that's just a bunch of processes uh you see cool stuff but uh that's when it started  getting interesting. I think at some point I was tired of looking in Ida and I was like I'm  going to poke more and I looked at DH client and I was like huh. And the really funny part is like I  run DH client and I see this like 2007 copyright I was like whoa that's not a good thing and if you  just run DH client by itself it's like false. I was like that's weird and if you like run it the  right way they print a debug message and say oh we modified it to work it better on our device.  And I was like huh that's interesting. So if we look back uh and we look for the specific  version it turns out that ten years ago actually for Defcon uh John Oberhide um really is like an  exploit for that specific version of DH client so I was like whoa that's that's easy. Um but we  want to make sure that it's actually still vulnerable so um the fun was like uh dumb like um  stack overflow like while handling DHCP options. So we can compare the original source code with  the patch source code because DH client is open source and just to keep in mind that might be  like mitigation like stack cookies ASLR or whatnot. So if we look at the vulnerable code on the  left side we can see a mem copy like I didn't read that's using like data.lane as a field while on  the patch version that we replace that by four. So the idea is like this bug is uh subnet it's a  bug in the subnet mask handling and the subnet mask should be like four bytes but the way the  DHCP option works is that you can send up to like 255 bytes I think and it used to just don't be  trust whatever you're sending which is bad. And if we look in either like the actual like  function uh we can see there is no stack canary and the on the left on the right side it's it's  not using that magic force so it's it's obviously like still vulnerable. So it's time to  exploit stuff um working on the fun was tedious I was like I'm going to try to set up QMU um if  you're not familiar with QMU it's can do like emulation of arm stuff or like many other system  and can do either like user land or full system. User land wouldn't work here because uh  DHCP is uh we try to modify an IP and stuff and that's not cool um but instead we can do a full  system emulation and uh those tutorials tell you how to like set up a cool image for that and we  just want to set up the network properly uh because we want to interfere with DHCP and  naturally um the um QMU stack would give you a ditched DHCP for yourself so you have to be  stay like don't do that and yeah. So I run it in DH in QMU and after like all these I thought and  it's still stake fault and like huh. So it turns out that like I modified stuff that actually  causing the stake fault and um I'm not going to cover that too fast because I'm running like a  little over time but uh basically it's creating that weird socket uh it's like a named socket and uh  so that's like the main application that the VOP stack can talk with DHCP and share options um  and uh the idea is like that's like the main application and we can see what it does. That's not  super interesting but basically on the left side is like sending data to configure the HCLI and  that start up and on the right side I reimplemented that in Python and uh you can run that with  like sockets um so socket is just a kind of like netcat in um more like uh more tools so you  can create that name socket and the idea you run the Python script on the host you run sockets on  the um QMU like binary image and it would just work. So now we can start debugging uh DHCP clients um  you can run GDB we can try to like actually run the Pock uh I couldn't compile the original  proof of concept it was like using really old tools and it's just after like a couple of hours  like I was like ah fuck that I'm tired. So instead I use a Skape based uh exploit Skape is a Python  library that lets you like you know mess with uh network packets like a fairly low level. And um  so now we want to like reach the um uh venerable code so um I was explaining the bug is in the  subnet mask option and the way DHCP works is like a tag length value like type of stuff so you  say oh this option is a uh subnet mask here's the length here's the value and obviously it was  like it should be four but if you send more it's fine but for the DHCP specs and so we can use  Skape for doing that. So uh that's my like a chunk of my Skape script and just the payload in  purple is interesting. Um basically just sending the subnet mask option with uh data that would be  like AAAA, BBBB, CCCC and so on and so forth so that uh when it crashes in GDB uh we can see like  all the register we control and we know um exactly um you know if we want to affect which  register which chunk of the shell code we need to change. And we can see that we actually  controlling uh PC so the program counter so that's good. We know that we have um we can  exploit we have control for execution and there are like a few more details that I'm going to  skip over but um we need to scour uh to craft a shell code now uh unfortunately like it looks  like the stack is uh you cannot execute the stack so we would have to warp it and that's  tedious. But um cool stuff is like if you look for there is like a system calling that binary  that I think also a Viya added and we do control R4. So if we put us if we can put a string in  memory in the address we know that could be a valid like system command and put the address in R4  we're good. Um so if you think about it DHCP clients DH clients we receive configuration  values from the server so probably there is going to be stuff that are stored somewhere and um it  turns out that ASLR is disabled sorry I forgot to mention that. Um but then we the idea is like  I just send like sending like AAAA's as like a bunch of uh options and look at memory to see if I  could find that string somewhere and eventually eventually the domain option was a good one and  so um now I can show you uh a cool demo that's how I happen when you actually run the whole  stuff. So uh on the um on the left side we have the phone that's booting. The phone is booting and  the window uh the terminal window is like on the left side is a rogue DHCP client running on  payload and on the right side is um it's a web server that will provide like a post  exploitation kind of stuff. So we can see the packet is running. To make sure it works I was  cutting uh Dev random on the uh on the screen so that's why it looks like noise. It's fetching  data from the um web server and I don't know if you can see but it's loading like Steve.data uh  FYI like Steve is actually my uh boss that's him. And uh just then I'm uh still like I don't know if  that sounds but I'm exfiltrating audio from the main speaker and you can see in VLC that when  I'm speaking and clopping my hands it's actually like reading the audio on the attacker laptop. So  that's pretty scary because you can turn your um phone into um you know listening device. Thank  you. So um yeah and just FYI like all the tools I use are like actually already on the phone  like you're like netcat you're like stuffed to like dump the audio to like STD in so you it's just  like writing some shell script like bash script whatever. And then you can see the  dump the audio to like STD in so you it's just like writing some shell script like bash script  whatever. So um as a conclusion uh for mitigation like you want to make sure you monitor your  network so that you don't have like punks like sending uh you know like weird DHCP packets and uh  actually like McAfee uh firewall like can detect that uh FYI. You want to segregate your  network um to make sure that for instance the coffee pot is not able to like send weird DHCP packets  to your phone and make sure I actually patch your phone because you know it's the patch got  released like I released the patch like a month ago so make sure it's actually patched. And uh  if you want to think about why this kind of bug happened like the technical debt is really hard  to handle and you know probably like someone had like in good faith um okay um someone in good  faith um forked the stuff and they forget about it so um and just as a real quick um embedded  systems are not black boxes so I would just encourage everyone to um look at them and uh  you can do it now as well. So if you have questions uh ask me on Twitter or whatever and  thank you for your time guys.  Thank you very much for joining us for this recap of our presentation.
Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_0_71.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_72_263.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_264_4103.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_4104_8171.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_8172_8219.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_8220_8291.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_8292_8363.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_8364_9671.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_9672_10091.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_10092_10691.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_10692_10763.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_10764_10919.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_10920_11639.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_11640_13355.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_13356_19427.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_19428_32687.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_32688_34811.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_34812_35903.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_35904_36071.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_36072_36299.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_36300_36431.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_36432_36551.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_36552_37367.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_37368_39755.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_39756_39935.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_39936_40091.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_40092_40235.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_40236_40499.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_40500_40931.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_40932_41891.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_41892_41939.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_41940_45587.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_45588_45659.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_45660_47423.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_47424_47543.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_47544_49211.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_49212_49691.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_49692_53891.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_53892_53963.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_53964_54047.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_54048_54251.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_54252_55151.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_55152_55403.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_55404_56399.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_56400_56447.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_56448_56531.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_56532_58235.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_58236_59315.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_59316_59711.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_59712_60251.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_60252_60959.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_60960_61019.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_61020_61247.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_61248_61343.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_61344_62603.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_62604_63191.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_63192_64127.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_64128_64187.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_64188_64463.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_64464_64763.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_64764_65555.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_65556_66983.png Philippe_Laulheret_-_Intro_to_Hardware_Hacking_-_D_HuCbr2588-w_66984_69168.png
Without further ado, because we stay on schedule. Felipe is here from Portland by way of France, from what I understand. And he is going to talk to us about breaking into embedded devices, including phones. Phones that you might have on your desk at work. Phones that might be... I'm not even going to get into that. Phones that might be around. Let's learn about embedded device hacking. Let's give Felipe a big round of applause. Have a good time, man. Thank you. Thank you, everyone. I'm really excited to be here. It's like a big honor. Today we're going to talk about hardware hacking. I'm going to share this introduction to it. I hope I can share some love about hardware hacking. Who am I? I'm Felipe Lodorette. I'm a senior security researcher at McAfee, adventlet research. I do software and hardware volume research. You can find me on Twitter at ph.lol. Before joining McAfee, I spent two years doing embedded security. Before that, I was a C++ dev. I'm more coming from a software background, actually. You could wonder why should you care about hardware hacking in the first place. I can see two main reasons. First, it's actually really fun and empowering to be able to break open a device that you're having at your home, at work, whatever. Instead of considering that it's a black box, you can start poking at it and understanding how it works. Then in a more pragmatic way, if we consider security in the past couple of years, software is becoming much and much harder to break. If you try to, I know, like, find a world in a web server by itself, it's kind of hard. But if instead you can just open the device, solder a couple of wires, and get a shell from that, that's much easier. So hardware hacking is great because it's also like a lot of low-hanging foods, basically. So today we're going to talk about Avaia phones, and especially like the phone picture on the right side of the slide is a 9611G model. So Avaia is like one of the biggest view IP solution provider. You can find them like all over the place. It covers like 90% of the 4100 company, and I think that's a specific model of phones starting in 2006, and it's going to be enough life at the end of the year or something. And the funny, on the bottom right of my slide, there is this funny like a screenshot from like a firmware download page from like a really old software for these phones, where actually like you can see that you can only download that specific firmware if you're like a DoD customer. So basically you can see that these phones are like going to a lot of different places. So regarding prior art in hardware hacking, there's like a lot of information nowadays on the internet, like you can find a lot of blog posts, tutorials. There's like the hardware hacking village that you all go and check out. CTF as well, where you can like practice like kind of like the software side of stuff. And on my slides, there's like a bunch of links at the end, so you can like download the slides at later time, and also those slides, I've like the one I've uploaded, I have like more text on them, so it's like more like standalone, so you can read more. And yeah, RedBalloon Security found like two assies in the same phone, something like five years ago or something, and I like a talk at RSA called Stepping Ponds that I would also recommend to check out online. So for the next 40 minutes, so I'm going to talk about hardware hacking and use that phone as a base to like support that conversation. And basically the idea of like the whole situation is like couple of like 12 years ago maybe a very forked some open source code and they never applied security patches to that. And it turns out that like me by poking at the device, I found that and it was like women like unnoticed for like 10 years that they were like actually like a CVE that got released like 10 years ago for DEF CON. So I'm going to talk about how I found that, like that it was like some stupid like you know code inside the firmware. But more interesting I think is talking about the whole process, you know, like how I did it and why I did what I did it. Why I did stuff I did when I did it. You know like basically like sharing the process so that and you know also like sharing, you know what if the stuff I tried didn't work or also like stuff that didn't work because you know what works for one device might not work for another and having just like that mental model of what we can do and what we cannot helps you a lot approaching like any kind of device and that's I really think why I want people to take away from that talk is more like learning the process so that you can check out like whatever device you have. And yeah I would want to like insist that if I can do it I think everyone in this room can do it as well. As I said more from like software background and hardware hacking is still like you know like a little scary little foreign to me but it's in the end it's really not that hard if you have like a good process and you know work with patience. So how did the whole project start? To be honest I was like you know working at work and we were like all these cubicles and on every desk I see this like phone like standing on the desk. I'm like wait a minute these phones run Linux they have you know network access they have like mics and stuff it's like how secure is that you know like you wonder like what's up with it did people consider the security of those? So the first step before you know even like I start like stealing my co-workers phone and breaking it apart you can and that's general step is you can check out the FCC website usually like any device that has Wi-Fi or Bluetooth has to be on the FCC website for like compliance reason. So that's what I found that's not my phone that's like a other model of like same brand basically and like really close. So you see all these cool pictures but more interesting is the inside of the phone. So we can enhance it and on the left side in red I've highlighted like this like random debug connector I don't know what it is but that's interesting to see that's there. And on the right side there is like that like in purpose there is that flash memory so that's usually where the file system of the phone is going to be stored and the whole point of that is just to get an idea of what to expect you know before even approaching a real target like burning hardware and stuff so that you know like if it's going to be a easy target or hard target you know if everything was covered in black epoxy that would be harder. So another important step is like getting like online material like you know marketing brochures so you have an idea of what are the phone capabilities and the ecosystem surrounding it so that you have an idea of you know like the attacks your face and you can also find like user manuals and stuff and for instance I found that one that was pretty cool it's like a user like our advanced user manual that says oh if you want a serial connection to the phone you need that funky box and yeah which is interesting it teach it tell us that yeah you can find a serial connection and you may have some special hardware for that but are we going to see that in a bit. And after that you also want to check like forums and so that you can find like what poor user are doing like for instance I found like the default password for the phone in debug interface because a system admin so here I talk talking about that online and if you're lucky you can also download the firmware of an idea of what's up there and I will cover that in a minute. Okay so what do we do now? We have an idea of like what it might look inside. This is a hardware hacking talk so we're going to avoid warranties and so the point is like you open the phone first and the trick is like usually you always expect to find the same stuff inside and if you look at the labels of the components you will see and you google that you will find out like what it is. So for instance that's my phone and you can see in the center the CPU above it like the RAM in like a lavenderish color like some unpopulated like header that I marked with a question mark. This I think the same header as the one we were like seeing in the picture before and it might be JTAG I did not have to use it so I don't know actually. In purple we have like the AEPROM so that's what the whole like some settings and stuff. In dark blue in the bottom of the slide is like a keyed LG45 so I was kind of confused when I was looking at that and I didn't know even the term for it and the idea is just a regular LG45 like Ethernet plug but with a weird connector so that you cannot plug the wrong stuff into it. And more interesting in yellow the UART so it's UART is kind of like the serial console and we have like this exposed like pads and so usually like in manufacturing or something you would have like Pogo pins that would like directly connect to the pads and that's that one is actually really interesting because you would expect to find a serial console on that and on the back we can see the same name flash that we've seen in the previous picture and yeah from that is like where the file system would be like stored on the device. So okay you have we looked at the stuff inside and like other thing that's interesting to look at is like test points and debuggators so and like basically all these kind of stuff that are not components and you can ask why would you expect to find them inside and couple of reasons like one is like just usually like the death board that the guys are going to use is the same as the production board and maybe they're just not going to solder the debugg components it's the same as if you had like software and it was built with like debugg symbols for instance and also like part of the manufacturing process this test points and stuff might be used for like flashing the device or making sure it's flash properly and sometimes you know like something died or something like that and you know like something died on in the real world and they want to like do a post mortem to understand what happened and that's useful as well. So what kind of stuff you want to look for in that situation you want to look at UART that we like looking at before JTAG that I'm going to cover in like in a minute and then like you can also have like random test points that are chilling there like all over the table all over the board and there might be like long test points like like TP1, TP2 whatever and sometimes that might be like not interesting to you but sometimes you can find interesting stuff like you might find out like oh if you short like TP64 with ground it's going to reset the device which might be actually useful in some extent. So looking at UART so as I said this for like serial connection and it comes in like three or four pins the three pins will be ground transmit and receive and the fourth pin would be like VCC so three volts five volts whatever and usually you don't care about that one you don't even want to plug it you don't have to and the trick to know is the serial console send data at different speed and there are only like a couple of it's called like both rates and there's only like a few common both rates value so if you try to plug your system into the UART and you just see gibberish on screen the probably the reason is you just have the both rates wrong and you could just like try to cycle through like all the possible one and you would find something eventually I think. JTAG is another one that's interesting so that's for like hardware debugging and with that you could like you know debug the CPU usually and execute like instruction by instruction and whatnot and they come in many different shapes number of pins and whatnot so some example like on the bottom of the slide but actually only a couple of wires are interesting and at the end of the slides I was like sending you an article about like understanding JTAG better but basically like if you look on the top right side of my slide there is like a dev board and there's like a nice JTAG connector like plug there and on the other hand like on the bottom right it's like some random device I was looking at which you can see there should be a JTAG but it's never been soldered on and so I had to solder directly onto that stuff and the trick to remember here if you kind of like solder your own connector is you actually may have to add like extra resistors called like pull up and pull down resistors that connects like one pin to ground or one pin to like VCC and the point of that is actually I don't know the point of that but the reason is like if you don't have them it might not work well or it's more work most of the time it's going to be glitchy so and if you follow the instruction from like for like our ARM specification for like what resistor you need so you might skip them but then you might waste time like understanding why it's a weird really like fucked up sometimes so I would recommend like remember the pull up and pull down resistors so that's just a random board that my co-worker was looking at just to show you that what I said is actually fairly generic on the left side we have like few art on the right side there's like some JTAG connectors uh there is the uh a price there is like the main CPU whatever that's under like a shield and usually you do that for um preventing um interferences so it's like a Wi-Fi module so that's why and the cool thing to know is usually the shield is grounded so like if you're looking for the ground on your thing like either the shield on that kind of stuff or like the casing around the internet port or whatever is also actually like fairly useful so uh now that we learned how to uh look into stuff we need to know what hardware you need for um interfacing with what's inside so I'm going to present like a bunch of cool hacking toolset that's important so the first one uh you may want this pin or like the stickers I don't know if you're familiar with that but um actually like what's really important is like safety um so you know don't work with stuff that's plugged in the wall uh remember to unplug stuff work in like well ventilated room it's important and uh yeah just don't be stupid when you're like uh messing with hardware uh but yeah so next picture from the lab uh I'm holding um soldering iron you can usually switch tip for like if you're like large tip for like big soldering and tiny ones for small soldering I have a microscope so that's really useful for doing uh tiny soldering and the trick is I tend to drink a lot of coffee and I shake so I would I was thinking like I couldn't do that but actually if you um if you're careful and the trick is like really like try to um you know when you bring like try to hold your arm like straight and well grounded and under the microscope you can actually do a lot of stuff that's you just don't think you you wouldn't be able to use you would think you shouldn't be able to do it but you actually actually can. Sorry um top right side um it's what I actually use for doing tiny soldering and um it's like top right like flux so it's kind of um magic glue magic uh gooey sti- substance that you put on um pins to uh when you're soldering surface mount or pads so that it works really well so don't never forget flux uh bottom is um like in the same uh size like uh copper wires like um NML wire that you use usually for making cords you know for like radio or whatever um and the trick is like the uh the wire is actually um coated in uh varnish so it doesn't uh short and you can use that to do like really tiny point to point like soldering and that's actually really useful and just next to it you have like some desoldering week so like the idea is if you put too much solder and you fuck it up uh you can put the week on top of the solder blob that you messed up with and you um put the soldering iron on top of that it's going to get really hot so you want to hold it through like the plastic casing and it's going to absorb all the like extra solder and you can clean up your stuff. Then I put like a picture of like some random like uh jumper wires that are usually always useful to have and on the bottom right I have like that crazy uh heat gun uh which is like 60 bucks at Home Depot it's meant to like help paint dry or something I'm not sure but it's actually really useful for if you're on the chip if you want to remove components by just like hitting them and pulling them off. So um more cool hardware um that's a multimeter um if you're not familiar with that it's you use it for um fine voltage of chip you don't know like what's the actual voltage so the black goes to around and with the red you uh with the right probably you select poking around to measure the voltage and the other really cool stuff is you can set it in continuity mode and when you have like connection between the two probes it beeps so if you do like crappy soldering job as I was describing just before you can make sure that you actually did a proper job where like everything is connected the way you think by you know making sure that both like when you probe like both sides it actually beeps and that's actually a fairly useful uh tool. The other one is this is a logic analyzer uh the name is like a Sally um that's a brand and the idea is the same as in software you have like ways of communicating between process like in hardware you have like ways of communicating between chips or the CPU and the chip and it's uh it's like a lot of different standards different ways of doing stuff but the logic analyzer like know a lot of them and it's going to convert like a bunch of signals that go going on to wires into actual data and that's actually really useful that would be your eyes like when you're doing debugging you know and that's like a some spy communication uh which spies just some random protocol uh that's like an FTDI cable also come in many uh or serial cable it comes in many different shapes and stuff and the idea is just like when you want to do like UART you you plug that into your laptop and you connect the other side to like the UART port and you get like a console it shows up at the serial port and uh as an example I have uh on the bottom right um like a Raspberry Pi that's you can actually get a serial console and you don't need like HDMI cable or anything to interface with that. Whew um the bus pirate uh also like cool device um it does um it's kind of dependent of the hardware hacking uh sorry the um the Sally the logic analyzer so instead of absorbing data it's like send data so it speaks a bunch of different protocol and you can use Python to program it so it's very useful if you want to like read flash program um microcontrollers and that kind of stuff. Uh more cool stuff like how about I was talking about JTAG that's the JTAG debuggers that you that's why you would plug actually like the the JTAG port on they come in many different like uh price range and what not so on the bottom right is a fly swatter it's like probably like 30 bucks I think and it works okay and above it's like a J-link which is more fancy and the idea is expensive the stuff is the more probably the more reliable it is and it comes with like better software and why not and on the bottom right the pink board is a JTAGulator that uh Joe Grand the same guy we met like those badges uh made and it's really awesome so if you have like that board you don't know what it is and there's like a bunch of test points and you're like I bet there is some JTAG somewhere in it but you don't know where you can just wire like all the test points to the JTAGulator and it's going to brute force like and try to find everything so it's really cool um another interesting important tool is flash readers so um usually flash content uh the flash has the file system and stuff and uh so you want to like interface with that and uh it comes in two flavor I guess you can do like in circuit stuff so you have like either like a little like clamp that you put on the chip or like the little rectangular one um and the clip on um so like the Raspberry Pi is a good one for that and on the top right is like a flash cat uh it's like for the rectangular one um but you can also like choose to like actually disordered the chip and in that case you would have like some like like socket adapter so you can clip the chip on and then you plug it into your flash cat or whatever and it's going to read it and I will cover like why what's what's why it's important like both in a minute and finally it's kind of the um last uh hope so let's say uh you know your flash is encrypted there is no UR there is no firmware so you can try to do like the more crazy stuff like fault injection and side channel like so that's a chip whisperer so like more like uh kind of hard more badass device and the idea with that is um it you can do stuff like um you you uh wire it and to the CPU and you're going to drop the power on the CPU for like a split second and it's going to like mess up some instruction and you can bypass checks and stuff that's what people use for like gaming console hacking and um that kind of stuff so uh what do we do now um that we have an idea of what's inside the phone and um you know um the tools we can use so like I think the three post potential track one is messing with the UR so the serial console and the other one is messing with the flash and trying to recover the firmware or something and then maybe you can just download the firmware online and the three are like valid approach and sometimes it's good to just go from one to another to another and you know whatever you find like some hurdle you can like go from one to another uh so I want to go for the UR first and that's what I'm greeted at by when I connect my FTDI cable to the UR port that I was showing before so we can see like on the left side the um the console thing it's like dot dot dot usually when you see that you can press space or escape and it's going to interrupt the booting process of the phone and in that situation uh but somehow here it didn't work and uh I will cover that why in a minute and on the top right side of the slide um we can see it read something from the eProm and decided to set the console to DevNull. So you don't want console to be DevNull because that goes nowhere but that's interesting to know that there's some potential there. And finally it says like booting Linux so it can confirm us that it's a Linux board but then there is nothing more after that. So that's some good thing, bad things. So the problems are like nothing shows up after like the Linux is as booted probably because of the DevNull situation and when I press key it's not working and I'm going to like come up with like why that happened. So at that point I was still like okay I cannot go anywhere so I'm going to try to recover the firmware to try to understand what's up with that. Multiple ways of recovering firmware's is like an easy way that you can download it online and actually that worked. There is like some cool snapshot of that. Sometimes encrypted on our case it wasn't. But yeah so you can also try to sniff a firmware update that's really useful for IoT devices in general and you can use a network tab which is like the thing pictured on top right of the slide. Or you can mirror your port on your switch or whatever. The problem with all of that is oftentimes the firmware update is going to do over like HTTPS or it might be and in case you're like stuck. And then you want to go for like a more like hardware hacking stuff like you're going to dump a flash for instance. And there's like even more advanced techniques that I will briefly like talk about. So how do you dump a flash? There is two ways as I was mentioning just before. You can do in circuit programming and out of circuit. So in circuit is cool because you don't have to you know like remove stuff, break stuff. But a couple of issues with that. The main idea is to read the flash. You need to power the flash. And if you if it's like still plug it into the whole system. When you're like Raspberry Pi for instance going to try to read the flash it's going to try to power like everything else that's connected to the same like in a bus line, a power line. And either you know your Raspberry Pi is not strong enough to power like a V-O-I-P phone which you would expect. And in that case, but it's just not going to work. Or maybe your Raspberry Pi is really strong and it's going to do it. But then the problem is the CPU start booting and it's going to talk with the flash and that's going to mess up your stuff. So in that situation you have like two choices usually. Either you can try to like lift up the pin, the power pin so that it doesn't happen. Or you can kind of go a little more like a low approach where you want to keep the CPU in reset. So I've been successful with that many times where I just like start like trying to ground like random test point of stuff on the board praying that it's not going to fry anything. And usually at some points like I'm going to notice that okay when I do that the phone like light up but doesn't boot, that's good. And maybe better ways you can disorder the chip with like the big like heat gun and whatnot. You have to be careful though because if you like pull it too hard you might like bend pins and it's going to be like useless. But a good trick to know is like you can make a little like tin foil a hat or whatever like around the chip so that like when you're heating up the chip like the stuff around it doesn't like get too hot. So you don't accidentally like knock off like some like tiny like components that would be like a pain in the butt to put back. And bottom right is like I was, I thought I would have to do that on the phone so I wanted to practice first and I just took like some random USB thumb drive and I tried. And actually that worked really nice. But the trick is remember I also put some plugs because it helps. And yeah just don't be careful with when you pull it off. A few other tricks that actually didn't work on this one but are good to know. Uh U-boot is the most common boot loader uh not used here but it's you would find that on pretty much every other device. And the idea is you can also interrupt the boot process of that and ask nicely U-boot hey can you load the flash in memory? And then uh U-boot is also able to dump in a hex like in the screen. Um the the memory is this way you can just like write little script to do that and recover everything on the flash which is really cool. But usually like dev don't like letting you do that so they set they lock that approach so you cannot like press space when you're in the boot process. But there is a trick that I also call like the YOLO approach where um instead when the idea is like U-boot is going to load from the flash like the the new kernel or something. But if while it's happening you start like poking with you know like a wire that's connecting to ground. You start poking the NAND flash like some of the pins. It's going to mess up like what uh U-boot is reading. And after a couple of tries uh U-boot is going to be like damn that kernel is fucked up. I don't know what to do and it's going to give you like a shell. So that's really cool. But yeah as I said that one wouldn't work on our phone unfortunately. But there are just some cool examples that I found online where like some guy actually did that. And uh I underlined in uh in like purple on the bottom like the command you need to use to like load the the flash in memory. And on the right side this like little block of text is um sorry is how uh U-boot is panicking and be like eh I don't know how to do with your kernel. And give you the the shell. So um so a few more like tricks for um dumping the flash. So you can use JTAG. So usually you have uh if JTAG works you're going to be able to um dump the RAM. So in this case that wouldn't be really like dumping the flash. That would mean the firmware. But in a lot of devices it's going to load the whole stuff in memory. So if you can dump the memory you are like the same. You're pretty good there. And kind of the last hope but that's one of my favorite about hardware hacking is you can do crazy stuff. Um and an example is uh ScanLime um that person on the internet who um she had um a Wacom tablet that she wanted to dump the um the firmware off. And there was like no attack surface at all. But she realized that like when you just like USB stuff. So when you plug your USB um onto the laptop there's some USB exchange that I don't know anything of. But it sends like USB descriptor. And if you if you glitch the CPU just at that time um it's going to like you know miss like a boundary check and it's going to send away more data. And with that uh she was able to recover like the full flash uh full memory or something. So it's really impressive but and that's what's kind of awesome about hardware hacking. Okay so uh we recovered the firmware uh in my case just by downloading online. But what do we do now? We want to analyze it. Um the best tool for that is called Beanwalk. And it's just basically a magic dictionary that's going to like look at your binary blob of stuff and be like hmm halfway through it looks like there's a zip file. I'm going to try to extract it. It tries. Maybe it works. Maybe it doesn't depending if it was actually a zip file or not. And it does that for everything. And uh it might also find like compressed file system uh such as like Squash FS, GFS2, etc. And sometimes like your um your firmware file might just start with like health headers or just like random like ARM code that you could like look at. So I run Beanwalk on the so that's the firmware file I've done on it from the website. And once again it's easy mode. It's just a tar file and they already like split it up into boot one, boot two and GFS2. So like Beanwalk has nothing to do here really and I can just extract the whole file system. And that's cool because from there I can look at what's on the phone just like that. Uh but the more interesting use case for Beanwalk is I took like a different firmware file for like another Avaya phone. And this one is way more interesting because Beanwalk for find like a way more lot of stuff. And uh I've highlighted like you find the file system and is able to extract it. And there's also that random like MySQL stuff which I think is false positive. Then you need to be aware that there will be a lot of false positive so don't blindly trust what Beanwalk says. And uh really really funny stuff that I was looking at uh if you run strings on that specific image um you will find like U-boot strings. So that phone is using U-boot and the cool stuff I was describing before would actually work on that one. Look. So now that you have extracted the firmware file what do you want to look for? One of the most uh interesting stuff is uh finding the update mechanism. So assuming you have uh encrypted firmware like if you reverse engineer that you might find the keys and how to extract like subsequent uh firmware updates without having to do like any hardware stuff. And then you want to look for like secrets like passwords, certificates, and so on and so forth. Uh originally my goal was to look at the main binary so that's the thing that deal with like the VOIP stack uh that could make sense to look at that. And um also you want to look at the bootloader because it may have a hidden command, explain why our console is not working, that kind of stuff. So remember the point of all of that was I wanted to get a shell on the device and um what's the process to do that? So the one I want to go for is I want to fix the serial console you know like the dev null was not cool. Um but also our approach would be like messing with your boot arguments. Um not working here obviously. Uh but you know you can specify the console you want and uh the init script can be marked as like oh I want bin bash as my init script and then you have a console. Uh and like kind of last resort stuff that I was considering as well is you could patch the firmware uh in our case the firmware is signed so uh that won't work unless you try to glitch it which really hard. But you can also try to patch the file system so the way bin work extract the gffs 2 stuff you could modify it and then like repack it and flash it directly onto the flash. And that's usually like a foolproof method like that would work in most cases. So instead I'm going to uh reverse uh um the bootloader and um for that um because I wanted to understand like why dev null uh the console was set to dev null and stuff. I'm going to cover arm in much detail and I would recommend you to check out azalea lab tutorials that cover everything but just useful here um there is this notion in arm of literal pool which is um inside the code section you would find some little chunk of data and that's usually like used to like load in registries um absolute addresses, imended values, magic offset that kind of stuff. And uh FYI like in case of function calls um the arguments are going to r0 to r3. The return value is r0 and when you like want to return from your call it's the return address is saving like the lr register that stands for like link register. Um and the big trick, the big problem here is um we like trying to load the bootloader so it's uh it's not really elf. So if you try to import it in IDA IDA doesn't know what to do with it. And so you need to find the loading address for that stuff so it match what's where the phone is loading it. Couple of tricks um so none of your lucky end is going to be printed on screen. That's our case, sweet. Um but otherwise we want to look at like header file, headers in the in the bootloader file or maybe reset vectors that's stuff where like specifically for ARM like the CPU needs to know uh specific addresses where like there's like a reset or like an interrupt happening and it's like fairly like um square like that how that's being set up. So if you find that and you find like what looks like an interrupt vector handler or something you can find like oh that must be the address. And uh finally the literal pullout was mentioning uh really useful because it's going to contain like absolute addresses or point to strings and stuff so uh if if like you have strings and they look like all fucked up you probably got the wrong address. And uh QuaxLab uh what a blockbuster body so I would recommend you checking it out. So as I said in our case it was easy um when it boots it prints uh the jump whatever and that's actually why you should load it. And um on the bottom right side it's like a bunch of strings um so it's a bunch of addresses that point to strings uh this is not from IDA and um we can see that um it's like all the strings like prints well so that means that it's loaded properly it's not like all messed up. Okay so now that we have the bootloader and we can like work it with IDA uh we want to search for strings uh we were looking at you know like that sentence like EEPROM, Red Successful, whatever. So we can use like cross-reference in IDA to find where the string is coming from and look at the function that handles that. And uh yeah just as a FYI about like EEPROM and SPI so the EEPROM that's on the board is called a SPI EEPROM and SPI is just one of those protocol I was mentioning before. EEPROM is just like a small memory um whatever and the SPI uh protocol is just like four wires um and the IDA the CPU is sending command and the EEPROM like reply and uh that's a dump from like using the logic analyzer to have a look at what it would look like in real life. Uh that's the data sheet of the EEPROM uh that you can find online if you google the label on it. Um the cool thing is in bottom left uh of the slide it tells you like the pinout so you know how to connect stuff to it. And on the right side of the slide um it tells you which which opcodes are for like the co- SPI command you would send. Like for instance if you send uh three it's going to be a read, if you send two it's going to be a write. So that's uh that's something useful to know right. Oops sorry. Back to the um back to the IDA and uh the bootloader we can see uh the strings we were like looking for and something extremely promising is we can see the console set to DevNull but above that is like a burn to those options and it's actually saying like oh setting console to like your zero or your one. So we want these ones to be printed. Um that's a that's a function that actually does print that string and uh what it does is roughly uh clear some bytes on the stack and then read from it from from a magic address and it's going to compare like bytes um that has just been read. And if we have the good value it's going to actually print on the console setting the console for uh DevTUI uh AM zero. So we want that to happen. Uh and something you can ask me is like well how did you find that read-uprm function you know and there like multiple ways of doing that uh the easy way that I've highlighted in green in that screenshot is uh on the bottom right we can see some like logging that says oh eProm read fails so I know that function is responsible for reading eProm uh but maybe maybe the firmware you're going to look at is not uh as verbose in which case um as I said before like to read from an eProm you know you have to send three over SPI so if you find like the SPI function and you see like sending three you know what it is. That's what I've highlighted in um yellow. Um but then like how do you find the SPI function you know it's kind of uh problem uh two ways for that um in my case once again it was logged so it was easy but usually like the main trick is um you have this um something called uh mapped uh IO a memory mapped IO and it's this kind of like magic address values in the CPU that like if you write to them it's actually going to send data over like your auto-SPI or whatever. If you're lucky you're going to have a data sheet for the CPU and it specifies exactly what are those addresses. If you're unlucky um you have to guess and that's really hard and at that time maybe you should like look for something else or just you know you're going to spend a lot of time on that. So we want to uh patch the eProm now so we can enable the console. The plan of action is we know the read write commands uh we want to interface with the flash so to do that um sorry the eProm we um we need like a spy uh device and we've seen before the best pilot is a perfect candidate for that. And we need to connect to the chip uh unfortunately like it's a really tiny one and so like the clip I was showing are like too big for that. You can buy online some rigs that people make um it's like expensive and it's like five weeks to get them. So instead I went kind of crazy and I tried to solder like um little wires onto the thing and I was like honestly that's never going to work. But it happened to actually work and I was like sweet and it's all like look like cross because it's like all the flux that remains on that. Um and that's the code for the best pilot. It's super like boilerplate uh thing and when you just write um this magic values that uh sorry I was asked to like replace them with like emojis. But uh the idea is like just after that you're greeted with console is set to uh like you are zero and now we have a lot of more stuff uh printed on console which is great. But unfortunately I get like this a harder like the input are still like not working. I was like trying to press space or type like it's like asking for oh you want to look at the route? What's uh it have nothing happened like what happened? It's like just cut the trace so you cannot send data. We have the board so we can look at it. Um so uh that's just like uh zoom up on the thing and at that time I was like you know looking at the UART pad and stuff like with my multimeter like trying to beep out like where it goes you know it's following the continuity testing and eventually it reached some wires like on the right side and the wires are that little hole that connect one side of the board to the other. So the trick is the actual like trace that connects the UART to whatever uh goes to the other side of the board and goes back and forth and it's like really like tedious. And eventually I kind of lost where it was going but it was kind of under that the mode port uh that's like the keyed uh RG45. Um and so um remember like the recon side uh recon part um we have that box and it's like oh damn that's the thing. So I kind of went to like my Yoru approach again where um I was holding like I had a plug like a jumper cable in my um the transmit of my FTDI cable and uh so I had like this like wire that I could poke around and on the other side I was like pressing keys on the console trying to see if something happened and meanwhile I was poking like to the pins one by one and I think at the second one it actually worked and I got greeted by uh like a wood shell on the device. So that was cool um but the trick was um on the right side of like a proper setup where I plugged my ethernet cable into the plug. So at that time I didn't want to know where the keyed RG45 was so I just like sanded the plastic of the ethernet cable so I could like shove it in and yeah it just works so that was nice. Uh now that we have a wood shell it's like uh a lot of debug strings pre-prene on screen and that's annoying. So um the trick was like I want to kill the process that's like floating my console uh as I said watch dog that's going to reboot the device if that happens so I uh highlighted in the corner like the magic command that you can run to kill that. It's just like random Linux stuff. Uh so now we can finally do some very research um and really what you're doing to do is like look at process running, poke around, look at open ports uh that's just a bunch of processes uh you see cool stuff but uh that's when it started getting interesting. I think at some point I was tired of looking in Ida and I was like I'm going to poke more and I looked at DH client and I was like huh. And the really funny part is like I run DH client and I see this like 2007 copyright I was like whoa that's not a good thing and if you just run DH client by itself it's like false. I was like that's weird and if you like run it the right way they print a debug message and say oh we modified it to work it better on our device. And I was like huh that's interesting. So if we look back uh and we look for the specific version it turns out that ten years ago actually for Defcon uh John Oberhide um really is like an exploit for that specific version of DH client so I was like whoa that's that's easy. Um but we want to make sure that it's actually still vulnerable so um the fun was like uh dumb like um stack overflow like while handling DHCP options. So we can compare the original source code with the patch source code because DH client is open source and just to keep in mind that might be like mitigation like stack cookies ASLR or whatnot. So if we look at the vulnerable code on the left side we can see a mem copy like I didn't read that's using like data.lane as a field while on the patch version that we replace that by four. So the idea is like this bug is uh subnet it's a bug in the subnet mask handling and the subnet mask should be like four bytes but the way the DHCP option works is that you can send up to like 255 bytes I think and it used to just don't be trust whatever you're sending which is bad. And if we look in either like the actual like function uh we can see there is no stack canary and the on the left on the right side it's it's not using that magic force so it's it's obviously like still vulnerable. So it's time to exploit stuff um working on the fun was tedious I was like I'm going to try to set up QMU um if you're not familiar with QMU it's can do like emulation of arm stuff or like many other system and can do either like user land or full system. User land wouldn't work here because uh DHCP is uh we try to modify an IP and stuff and that's not cool um but instead we can do a full system emulation and uh those tutorials tell you how to like set up a cool image for that and we just want to set up the network properly uh because we want to interfere with DHCP and naturally um the um QMU stack would give you a ditched DHCP for yourself so you have to be stay like don't do that and yeah. So I run it in DH in QMU and after like all these I thought and it's still stake fault and like huh. So it turns out that like I modified stuff that actually causing the stake fault and um I'm not going to cover that too fast because I'm running like a little over time but uh basically it's creating that weird socket uh it's like a named socket and uh so that's like the main application that the VOP stack can talk with DHCP and share options um and uh the idea is like that's like the main application and we can see what it does. That's not super interesting but basically on the left side is like sending data to configure the HCLI and that start up and on the right side I reimplemented that in Python and uh you can run that with like sockets um so socket is just a kind of like netcat in um more like uh more tools so you can create that name socket and the idea you run the Python script on the host you run sockets on the um QMU like binary image and it would just work. So now we can start debugging uh DHCP clients um you can run GDB we can try to like actually run the Pock uh I couldn't compile the original proof of concept it was like using really old tools and it's just after like a couple of hours like I was like ah fuck that I'm tired. So instead I use a Skape based uh exploit Skape is a Python library that lets you like you know mess with uh network packets like a fairly low level. And um so now we want to like reach the um uh venerable code so um I was explaining the bug is in the subnet mask option and the way DHCP works is like a tag length value like type of stuff so you say oh this option is a uh subnet mask here's the length here's the value and obviously it was like it should be four but if you send more it's fine but for the DHCP specs and so we can use Skape for doing that. So uh that's my like a chunk of my Skape script and just the payload in purple is interesting. Um basically just sending the subnet mask option with uh data that would be like AAAA, BBBB, CCCC and so on and so forth so that uh when it crashes in GDB uh we can see like all the register we control and we know um exactly um you know if we want to affect which register which chunk of the shell code we need to change. And we can see that we actually controlling uh PC so the program counter so that's good. We know that we have um we can exploit we have control for execution and there are like a few more details that I'm going to skip over but um we need to scour uh to craft a shell code now uh unfortunately like it looks like the stack is uh you cannot execute the stack so we would have to warp it and that's tedious. But um cool stuff is like if you look for there is like a system calling that binary that I think also a Viya added and we do control R4. So if we put us if we can put a string in memory in the address we know that could be a valid like system command and put the address in R4 we're good. Um so if you think about it DHCP clients DH clients we receive configuration values from the server so probably there is going to be stuff that are stored somewhere and um it turns out that ASLR is disabled sorry I forgot to mention that. Um but then we the idea is like I just send like sending like AAAA's as like a bunch of uh options and look at memory to see if I could find that string somewhere and eventually eventually the domain option was a good one and so um now I can show you uh a cool demo that's how I happen when you actually run the whole stuff. So uh on the um on the left side we have the phone that's booting. The phone is booting and the window uh the terminal window is like on the left side is a rogue DHCP client running on payload and on the right side is um it's a web server that will provide like a post exploitation kind of stuff. So we can see the packet is running. To make sure it works I was cutting uh Dev random on the uh on the screen so that's why it looks like noise. It's fetching data from the um web server and I don't know if you can see but it's loading like Steve.data uh FYI like Steve is actually my uh boss that's him. And uh just then I'm uh still like I don't know if that sounds but I'm exfiltrating audio from the main speaker and you can see in VLC that when I'm speaking and clopping my hands it's actually like reading the audio on the attacker laptop. So that's pretty scary because you can turn your um phone into um you know listening device. Thank you. So um yeah and just FYI like all the tools I use are like actually already on the phone like you're like netcat you're like stuffed to like dump the audio to like STD in so you it's just like writing some shell script like bash script whatever. And then you can see the dump the audio to like STD in so you it's just like writing some shell script like bash script whatever. So um as a conclusion uh for mitigation like you want to make sure you monitor your network so that you don't have like punks like sending uh you know like weird DHCP packets and uh actually like McAfee uh firewall like can detect that uh FYI. You want to segregate your network um to make sure that for instance the coffee pot is not able to like send weird DHCP packets to your phone and make sure I actually patch your phone because you know it's the patch got released like I released the patch like a month ago so make sure it's actually patched. And uh if you want to think about why this kind of bug happened like the technical debt is really hard to handle and you know probably like someone had like in good faith um okay um someone in good faith um forked the stuff and they forget about it so um and just as a real quick um embedded systems are not black boxes so I would just encourage everyone to um look at them and uh you can do it now as well. So if you have questions uh ask me on Twitter or whatever and thank you for your time guys. Thank you very much for joining us for this recap of our presentation.
we're going to talk about Avaia phones, and links at the end, so you can like download the hardware hacking and use that phone as a base to going to talk about how I found that, like that like learning the process so that you can check like all these cubicles and on every desk I see and stuff it's like how secure is that you know and stuff so that you know like if it's going to surrounding it so that you have an idea of you also download the firmware of an idea of what's what it might look inside. This is a hardware I did not have to use it so I don't know connector is you actually may have to add like that but um actually like what's really important like when you want to do like UART you you plug whatever and it's going to read it and I will over like HTTPS or it might be and in case you're phone unfortunately. But there are just some cool just a tar file and they already like split it up originally my goal was to look at the main binary to get a shell on the device and um what's the that we have the bootloader and we can like work EEPROM is just like a small memory um whatever multiple ways of doing that uh the easy way that this bug is uh subnet it's a bug in the subnet concept it was like using really old tools and want to like reach the um uh venerable code so um actually patch your phone because you know it's