 So welcome. Thank you for coming. This is a talk on reversing exploiting embedded devices. Just in case that wasn't obvious. So let's just get going. Let's just get started with this. But actually before I get started, I have one question. Who here has actually done exploitation on embedded devices, either MIPS or ARM? Awesome. Did you take that Pock all the way to CodeExec? Awesome. Cool. So that's what we'll be talking about here too as well. So anyway, let's just get started. So this is the outline for my talk. It's about an hour long or so. But I'm going to go through it a little bit quickly. I've done this talk before, but kind of scaled it back on the technicalities. But since this is DEF CON, we're going to go full technical for a little bit. So this is the outline. I'm not going to go through it, but let's just say we're going to get a little technical. And after this, we're going to go on an adventure to actually take the stuff that's in this talk and find our own O-days and products today. And that's what we'll be doing tomorrow. But who am I? Right? Like who's this kid up there wearing all black? So my name's Elvis. Real name. I love how everyone's cell phones started going out taking pictures. When I said that, I'm a senior security researcher at a local pentesting firm in Austin, Texas called Praetorian. I got into IoT research completely by accident, right? I started off in desktop space and this whole IoT embedded device stuff got just completely by accident. The long story that's short was that I had a coworker who found a really nasty phone, took him three seconds to find it with a really dumb fuzzer. And I said, if you can do it, why can't I? And now I'm in this trap. So I'm also known as black owl on Twitter. That's cool. So let's get started. So like I said, I found some bugs because I got compared with a former coworker of mine who found bugs really, really easily high impact bugs that was affecting the entire SDK of the manufacturer. So I did the same thing. I was fuzzing HP daemon, everything you think of the method, the URI path, HP 1.0, 1.1, 0.9, hosted long everything, maybe tons of new lines, no new lines. Everything I could think of, the UPP interface with soap, all the methods I can think of, anything that takes a string, let's put command ejections, put 3,000 A's, nothing was happening. My device was all happy Dory going, no problem man, we got this. So then I started taking it further. I was like, well, what about like Dr. Traversal, maybe pull some files. We do double percent encoding mixed characters. So we can do like percent 25, 41 for like capital A or let's just do all these crazy things or command. It's just fuzz everything but nothing was working. So what did work was I actually had to sit down, I took the firmware completely apart with BinWalk, which is fantastic. And I found hidden APIs that you would never find on the front end by fuzzing, by disassembling this that was inside the binary itself. You would not find it in the file system, it was inside the binary itself. And this particular one was it would take the value from submit URL and pass it straight to system. Pretty dope. So digging into firmware. So like I said, fuzzing stuff on the outside may just only get you on the surface. Some of the nasty stuff that you want to get into is going to be deep. You're going to have to dig for it. So extracting firmware binaries. Who here has heard of BinWalk? Yes. Awesome. BinWalk is an amazing tool. It's like a very, very high level what BinWalk is. It's a magic byte parser and extractor. That's all it does. If you look at the configuration files for BinWalk, it is just using lib magic. Offset this, this is the byte like cafe bay for like Java, right? And it just goes through the entire structure. It's supposed to be matching the entire structure up before doing any kind of extraction. If there's any kind of false positives inside of that, when you see the word invalid for this kind of stuff, it's supposed to be reducing false positives. So that's BinWalk in a nutshell. Very, very simple, straightforward, but it's super powerful. But it can also be annoying if you're dealing with dumps that are not particularly organized properly. And BinWalk just goes crazy and just says everything's an LZMA block. So great. So we can extract firmware that we can download off the internet that's not encoded or anything like that. Fun fact, a lot of encoding stuff is usually like single byte or multi byte XORs, so don't worry there. So when I got into embedded devices, well that's a lot of people. What's up guys? The one thing I didn't know was the assembly for it. I started off an x86, 64 land. I didn't know MIPS assembly. Like what the hell's a branch? What the hell's all this stuff? But what I didn't know was C. And I was like, well let me just do exactly what I did in x86. I'll just create C, compile it, maybe with some different flags, see what else comes out, and then just step through it. So this is exactly what I did. So right here, I have a local integer called RedVal. And it is initialized to zero. And in MIPS we have a dedicated register called zero. It's just always null. So right here I know that we have something called store word zero to an offset 24 of S8. 24 S8, S8 is also known as a frame pointer, also known as EVP if you want to say. So we are now, we know we're in the local variable for this function. Great. So I know S8 and I know the offset for that value. So we go further. What about calling functions? How do arguments get passed in this architecture? It's the very first one I passed hex 44, which in base 10 would be 68. And then second argument, which is A1, which is hex 65 or 101 decimal, which is A1. Great. So now we know when we're calling a function, those A registers, A0, A1, A2, A3, are going to be pointing to the arguments that we're going to pass to this function. Great. This is super simple. So now we know, like where initializing happens, I know where arguments get passed. What about return values, right? So I have this function called test. And I do a ret 66 or whatever it is, right? Well, remember that same offset 24 S8 that we saw from the beginning, that's ret val. So now we know v0, whenever a function returns, it's going to contain the value of the return from the previous function. Cool. And then we do it again, print def. Second argument is going to be an A1 because the first argument is the format string, right? And then we just keep going and then this is the final one where we finally return from main. And I put a d word in there, 43 for all capital C's, right? So we have an L-U-Y of two bytes and an O-R-I of two bytes. And I was like, all right, that's kind of cool. But what is actually O-R-I doing? Because I don't feel like reading the assembly manual right now and that's kind of want to see what's going on. So it's everything we've always done where we're trying to learn new assembly stuff. We just set the break point. We make sure step mode is on. We step one to make sure that instruction was executed. We double check to make sure the execution happened. We check the value. So now we know when L-U-Y two bytes happen, the greatest significant two bytes of that register will be that value. And then the lowest significant bytes, this is an O-R-I. So it's an or integer, but the lowest significant, since it was null, 4340 gets populated and the whole d word gets populated into that register. Why did it have to do two instructions? Some people in there, if you don't know, just want to say this is MIPS 32 bits, MIPS 1, it's four byte instructions. So every single four bytes can be different instructions. So that's why you can put four bytes for your operands to the opcode. Cool. So this is kind of, you know, kind of like annoying. You can say it takes time. You have to sit down, make some coffee, not get distracted by Mr. Robot or whatever you're watching. So what about making our lives easier? We want to find volns, right? That's our jobs. It's what we want to do. We want to pop shells. That's all we want to do. So I learned about something called GPL, the general public license, right? So when I was reading from it, at a high level, I was like, if you license your binary in your source, everything on a GPL, you have to publish it. The source has to be out there. If it's on a GPL and you're like, no, I'm not going to give you the source, that's a violation. So what if I take, I don't know, vendor A into Google and type in source code? Cool. This is all the tar balls for that device. If you download this tar ball and if you modify a little bit with a symbolic link inside of it because sometimes they break, you can compile your own binary for that device, it will upload and all that good stuff, which is what I did on this one. What about smart TVs? Complete source code is on there too. No need to take it apart and probe the flash chip on the SPI interface. Don't do that. Complete source code is in there and you may find some old libraries. Maybe WebKit is old on there. I don't know. And last vendor. Again, GPL. It's a vendor name. All there. Very, very straightforward and everything is documented beautifully. I love these guys. So it goes on and on, right? It goes on and on and on and you will run into two different types of like GPL codes with this type of devices. You'll have your Linux boxes and then your RTOS boxes. And they're completely different and I'll talk about that a little bit more on, but yeah. So I talked a little bit about software and how to get into it, how I taught myself how to like, you know, go over the hurdles of learning assembly so I can actually read this stuff and interpret what I'm reading. What about the hardware, right? Like when I started getting into this, I exhausted the software stack completely at one point and I'm like, I'm completely stuck. I have to start opening the stuff up. So the thing is though, you have different levels of like, I don't know, you can say, uh, advancedness, chair lag, you can build a super dream of your lab, you know, super lab of your dreams and you're dropping acid on chips and you're doing those crazy stuff. You don't really need that. Majority things that I do use this, maybe some of these and that's about it. Hold on, let me go back. Sorry. And maybe some of those. Yeah, sure. So what I wanted to say is that the bare bone stuff, it says $9,500 or whatever, but that's the biggest chunks from the multimeter and the soldering iron itself, right? If you have friends or just haven't land around that your biggest chunks can go away. The JTAGulator, that's a controversial topic in my opinion because if you go under the JTAG Enum project for the Arduino Nanos, which is, you can build yourself a JTAGulator basically for about five bucks. So these things, right? Have you ever seen like an Arduino, these little $5, $3 cheapy things from eBay, right? If you look at the JTAGulator source, you can see that there's a comment saying that the logic from it was actually pulled from the JTAG Enum project for the Arduino Nano. Cool. So the same logic is in there too. What's the difference though? Like, why is that so expensive and you can do this whole thing? You can't do voltage control on this. I can't say, all right, and give me 1.8 logic for your software. It's not going to work like that. It's just 3.3. So I would have to make my own like logic converter or like some sort of shield. So that's where the other thing comes into play. So that's where the JTAGulator comes more like friendly and stuff like that. But I'll talk about that another time we're offline. And then the logic analyzer is fantastic because I've seen so many boards where I go what the hell is this test point do? Where does it go? I can't figure it out. Hook up the logic analyzer, do a quick sample, analyze what you see and just go forward from there saying guessing, probing stuff with a multi-manus, a very low sample rate. You're going to go crazy because I did. So finding UART. So UART in a nutshell, right? Most people in here most know UART. It's basically just think of it like Telnet or SH. You got command line or it's just a serial output from the device. So what about finding this kind of stuff without opening a device? What if I bought some 300 old device and I go, I don't want to open it up? So what if I break it? Because I will, right? So every single wireless device, at least in the States, has to go through something called FCC qualifications. It has to be tested. If it's wireless, those radio has to be qualified. So you take this number called the SEC ID, you go on FCC's website, click a little button called internal photos, which is great. And you get the complete PCB front and back, up and down, left, right, Konami code. Awesome. And right there, like this is like not all the time, but this is a very good hunch. When you see a rose of pins like that, like those five pins I highlighted there, it looks like something that may be useful for development or testing. I don't know. It kind of looks like a shell interface. And the one below that may be some sort of JTAG interface to test like the processor or anything that's in the JTAG chain. But that's my first suspicion. So I go, that's UR maybe. So let me go probe and test it out. And spoiler alert, it was cool. So that was some easy ways. But one thing I really want to stress, don't make the same mistakes I did. Find your ground first. I have had too many smoke shows or too many moments when I'm just like, oh yeah, that should be fine. So find your ground first. The one, the one thing I like to do is like I find common grounds like this is like a shield, there was a shielding over it and I took it off. I found it to be a common ground. But like USB caseings on the outside, they're usually grounded. Just find yourself a common ground point. If you flip on the back, you'll see also casing groundings for like anything kind of porch. Find a ground and then don't use continuity mode. I used to say that and I was dead wrong. And this is why. When you use continuity mode, you know the one where you say alright, is A connected to B and it makes a noise, right? That's pumping voltage through it. And I hooked up my logic analyzer. And this was me moving the dial, so we got some noise. And the multimeter in continuity mode pumps up 1.6 volts, continuous. So if we have any kind of fuses or very, very sensitive or anything else that may blow, that's over 1.6. I don't really see anything that's, you know, says I can't handle anything over 1.6. But we just want to be careful. So instead, we use resistance mode. Resistance doesn't do voltage. It doesn't pump up 1.6 volts like we saw before. So all we need to do is to say if A connects to B, we look to resistance. If it's absolute zero, they're connected. Awesome. Or have no resistance in the middle. So yes, they're connected. Great. So that's how I find ground now is by using resistance because I was using the wrong way and learned that I could blow stuff up. But you are in a nutshell, right? We got transmit to receive a common ground. There's no clock. It's going to be like some sort of like, I think it's like asynchronous or something like that, where you have to like tell it. So basically think of it like a phone call. You talk to somebody and you hear it at the end. But now you have to figure out how fast it's talking. So there's methods of finding the baud rate for these UART devices. And it's annoying. I don't like brute forcing UART interfaces. Is it 9600? No. The attach. 33, 400, something like that. No. So instead, we take a 20 second digital capture. And if anyone's used the logic analyzer, you'll know that digital captures are very, very, very tiny. This was an analog capture probably be in the gigs. This is like a 20K file, right? So this is ambiguous. So let's just use our CSI cyber skills and we enhance this photo really well. And what I'm looking for here is something called the shortest width bit. Doesn't have to be the exact one. But I'm looking for when the falling edge and the rising edge happened again. What's the distance between that? So in this one is 8.8 microseconds. So, okay, cool. You found that. What can we do with that? So if we take that 8.8 and we take one second over 8.8 divided by a million, whatever the measurement for that is, we get 11, 36, 36, 36, 36. We're going to round it to our standards which was 11, 5, 200. But just for fun, I'm like, you know the logic, the SLA logic analyzer comes with a different kind of analyzers that come in with it. It's called the serial one. So I said, this is the baud rate. I want you to analyze this signal and see if anything comes out. And it comes back saying this particular segment is the word start and there's a space. Cool. So now I know the transmit pin on the device. I know the ground and I know the baud rate. They receive, don't hate me, but I brute force my way around until something clicks. Next one. All right. I talked about UR. So how about JTAG? So what the hell is JTAG? What is it for? I've heard people use JTAG. What can you do with it? It's literally a testing, like it's a testing suite. It's supposed to be made for quick, easy ways to diagnose hardware problems without sitting down and probing everything. So this is great, but it has a lot of functionality. So what we have here is something called a tap interface. The tap interface connects to the insides of the actual logic of the chip. It's a little bit complex. I'm not 100% there, so I'm not going to try to BS my way around. But I do understand this, which is the state machine of JTAG. So basically, when we have lines, the lines here are going to represent our boat select, TMS. And then the TCK, the clock, is going to indicate when we go from next step to next step to next step, right? So let's say that I'm at run test idle. If TMS is high and the clock happens one more time, the TMS will move over there. So now I'm at select DR scan or data register. So this is how the state machine works. And if I keep TMS high, it will go all the way up to test logic reset and correct me if I'm wrong. But based on what I have seen, there's no TDI needed for this and you'll get the ID code. TDI stuff when you start doing bypass scan and you're filling every register up with, I believe, ones to put into a bypass state. That's a different thing. But we'll go into that later. Sorry. So locate in the flash chip. So what if you find UART and it's password protected? And you can't brute force it because brute force in the root password takes like three seconds for every attempt. That's slow, right? So what if you also can't download the firmware without public? It's some sort of like proprietary device, right? So now this is where we start getting nitty gritty. So this is our comparison to computers. This would be the hard drive. So we just find out who makes this particular chip. We use Google because, you know, I'm pretty smart like that. And then we pull up our chip. And the main things I'm looking for is basically where are the interfaces I can talk to you, the input and output, and what commands can I send it in order to extract data? And also how can I put it in the right protect state so I don't erase something? Kind of like a floppy disk when you have that thing, right? So the thing is though with this is that with chips, with these flash chips, they are like a slave. When a master chip says, I want to talk to your mind, I select you. That is it. You cannot have another probe into it and talk to your chip. It's one-to-one. So when you're actually pulling the chip off or you're actually trying to dump everything. So there's two ways, right? Some people like to be non-destructive and want to keep the chip on the board. And that's a perfectly good way of doing it. And this is how you can do it. There's a thing called like it's an SOIC than the number. Like this one's 8. There's 16. There's also like breakout boards that you can buy and put the chip in here and have a huge breakout. You can put it into a breadboard and do whatever you want. But this is also this way. But the problem with this one is that you have to provide power to the chip because it's not going to turn on like magic, right? But you may turn on other devices around it and you may put the chip into a select mode. So that's not good. So what can we do without removing the chip? Find the reset pin on the processor, either ground it or put it high, whatever the data says, then turn on the device fully. The device will not do anything at all. And you should be able to communicate with JTAG and everything else because if the like there's been devices as well where you see JTAG for one second and then initialize everything goes away. It's because the driver is doing it. So if you put into a reset state everything should be communicate should communicate perfectly fine. So that's how you can do it without removing it. But I remove everything just because I like to do that. So that was a flash chip that's serial. I've been playing around with these things and I'm pretty sure these things were made by the devil. These are known as NAND flash chips and they do everything in parallel. And I have a dump here and it's offline, it's on my slides. And I'll show you the hardships I've been having with this. With all the blocks and organizing everything. And that arrow is not pointing at anything. But this is basically how I hooked it up. This is a FT2232H and there's all these white papers, there's a black hat talk on it. You can look at it. It's on my slides. And this is how it works. You hook it up, you turn it on and there's a tool out there called dump flash and you say, give me the ID code and it gives you everything. It gives you the page count and extracting this two gig thing took 12 hours super fast. So this is the thing as well when I was talking about bin walk earlier. This thing, the blocks are all over the place. So I'm trying to figure out how the microcontroller wrote to the NAND flash. I can reorganize everything. Running bin walk against it goes that for about five minutes. LZMA, LZMA, LZMA. Yeah, no. So that's the only thing about NAND flash. With SPI flash running bin walk on it, done. It's serial. But once you have started having parallel flash memory, it starts getting really complicated because it's not all nice and laid out. So exploitation. So all this software hardware stuff are cool. We've heard a million times. Let's actually break some stuff, right? That's what we're here for. So one thing I've noticed a lot. So a lot of red teamers will probably know this as well. Developers love to keep debug code in production stuff. Why? There's no TV, there's no monitor hooked up, so who cares, right? So when I first found Avalm and I, you know, made the crash, this came out out of UART and it said your return address is 434333 and your program counter is that too. Cool. So now I know my offsets off the bet. So just to verify it again, so look for debug code for signal catchers. It's probably in there. So you don't have to like cross compile GDB and attach all that stuff. So analyze the crash, this is the same thing over and over again, just like X86, analyze the crash, find your offsets and put everything in place and everything will work. So analyzing function returns. This is how I taught myself all this stuff like I said before. So we have the same program, two architectures, we have X86, all this is doing is calling stir copy, taking argument value one and just throwing it into a stack and then it prints off some stuff and then it returns. But then we have leave and ret. So leave, so EBP and ESP-CB switch I believe and then we have ret. So then we have whatever ESP is pointed to is going to pop those four bytes into EIP and move over plus four. Cool. So MIPS, same thing, load word RA from some offset from the stack. RA is return address. In MIPS we have a dedicated register for return and we have a third frame pointer from this thing. Same thing, it's like leave. So we have the same thing. Restore the frame pointer, restore the stack and then jump RA or ret. So it's having the instructions and one thing is broken out. Load it and then jump. Cool. So X86 and now ARM. So ARM is a very special architecture. That's all I'm going to say. So going from MIPS to ARM is a little bit different, but basically the same thing is going to be the same. The same thing, function return and entry and yada, yada, yada. Just return everything it was when we called it, right? So the one thing also with ARM is they have different modes and MIPS architecture also have this where you have something called a thumb mode and an ARM mode. Very, very easy to do. You have something called jump and link exchange or branch and link exchange, sorry. And the address that is going to, if the least significant bit is set, minus one, go back to that memory, minus one of that memory and then put everything into 16 bit mode. That's how it works. So if we jump into an odd memory and it's jump and exchange, 16 bit, if not, then it's our mode. Cool. So like I know this is a little boring, I apologize, guys. So just like before, we're just crashing, analyzing, crashing. Now we're starting to see everything coming to play. Everything is starting to really look the same as x86. It's all it is. Instruction, hunt and ellipsey, though, it's a different story, especially in MIPS. x86, you guys are spoiled. Spoiled with instructions. Stack flow for every single situation. Basically, win. Simple. No NX, that's all we care about. MIPS. Jump, register, stack. Nope. Move stack into T9, maybe we can call T9. Nope. Go screw yourself. So this one is more complicated. We have to rob in order to do a basic stack execution. We don't care about NX, we're not calling any kind of APIs to modify memory attributes. So this one was a little bit more interesting. So what I had to do was I had a limited set of registers. I completely skipped that by accident. So sorry about that. So basically what I had to do from the beginning, I only had a limited set of registers. First gadget, get more registers, sleep because when I was doing this at the time, I was hearing about instruction cache fleshing. Not every single MIPS device has that. This is an R3000 MIPS 1. It doesn't use instruction caching at all. There was no reason to go into this. I just put the stack, add 18 offset into it and put into A1. Move A1 into T9, jump T9. That is how I did jump ESP on MIPS. So one thing that was a little annoying and just like we all have with X86 that we've done before, are null bytes. So when I first came into this it seemed like every single instruction had null bytes and I said forget this router stuff. I'm going back and forth with this. But then I relaxed. I said all right, let's actually relax. What about X4? What if I just X4 this and that? Dope. So we don't have null bytes. We can just make an X4 encoder. So in a nutshell though, the whole thing is still the same ideas and techniques that we've used with X86. It's just a different instruction set. That is it. So before going to this a little bit more, the shell code stuff like the prelude or whatever to the shell code, I did everything in RASM. I use RASM to assemble all my instructions into op codes because I didn't feel like using an assembler and trying to get everything working correctly. No screw it. I just want these instructions and I'm just going to copy these op codes into my payload and that's going to be done with it. So this one all I did there was I had an address that was not resolving to an actual instruction so I just overwrote it with nulls. It's a knob slide. I know it's dirty but it worked. So in a nutshell, grab your libc address, find your extraction offsets, craft your shell code, test your exploit and QEMU or QMU whatever you want to call it. I'm really bad with butchering these names. I test everything in emulation first and then from there all I had to do was run the VASLR even though randomized VA space is set to 2. It doesn't work. Crash the device, restart it many, many times. Libc and everything else, all the other libraries that it loads are going to be the same place every time. So this example is from something I made. It's called the DVRF project or damn vulnerable router. Yeah, it's kind of funny. So this one, it's a very first level, it's just a stack buffer and all the same payload, copied it to my device and it works beautifully. Great. So going forward though, I'm talking about all this exploitation stuff and I was guilty of doing this. I was super guilty of doing this. I would find a vole and I would say, yes, PC is 41, 41, 41. I am done. Drop mic. But that doesn't do anything. I was limiting myself and I was limiting my voice. We need no more dust pox. And I vote that we make pox great again. But don't worry, I'm not going to build a fair day wall around these devices and make the vendors pay for it. I guarantee you that. So this is my demo now. So, yeah, so let's get started. I do this. I like to kind of get into character. Kind of have fun with this. We stay here all day, we see a lot. Have you guys ever seen stock photos of hackers? Okay. So before we get started, I'm going to set up the environment first. So the application I'll be exploiting in this demo is called Socket BOF. The application, all it does, it's listening on a socket and whatever data it gets, it just starts copies it. These levels and stuff, I'll talk again, are supposed to be educational levels to help you learn about this kind of stuff. But let's just set this up. What? There we go. Yep. All right. Sorry about that. All right. Before we get started, can we kill the lights? All right. Awesome. So what I'm going to do here, I forgot my own arguments for my own script. So that's why I had to print out the help. So we're going to set this whole thing up. I'm going to get my microphone because of the talking. Sorry. I'm a little slow. Thank you. Let me make sure that's actually I just want to make sure, you know, I don't want the demo guys to get mad at me. So we did this on 8080, right? So now so over here, let's make a new tab and C dash L, dash V, dash P. So now we have a netcat listener waiting and I'm now going to make sure that's right. 8080. All right. Cool. So without further ado, let's get this going. Oh no. Hold on. The sound's not working. No, I don't. Man. No. Oh, it works. IoT village. Before we begin, I want to say that this will be my last performance of this demo. With that out of the way, let's corrupt this application stack. But first, we need some sick hacking music. That's better. Now we need to cover our tracks for that concept. Thanks, guys. So we can also verify, so this application is still in the stuck state. So if I go back to netcat and just kill it to just verify, then it's, you know, it returns. So that was an actual exploit. So thank you for bearing with that. You can bring back the lights. So like I said, I just want to have fun with that. But like I said, I went from not knowing MIPS exploit, MIPS assembly to doing that. So it just takes some time. You guys can do it, too. It's pretty straightforward. The difference is that I learned. X86, base stack buffer overflow is pretty simple. Straight forward, like I said, a thousand times. Just know where ESP is and where the RET's going to happen and everything falls into place. MIPS, base stack buffer overflow is a little bit less straightforward because of the less instructions that you have than X86. But it's a little bit more fun, but it does require roping. So if you've never roped before in X86, you should probably do that first before coming over here. And then roping in MIPS, same thing. You're just calling different APIs and feeding different arguments. Same thing as X86. RMV5, I haven't finished this one yet because I'm still learning the many, many, many, many, many, many, many different instructions that RM provides. So this one so far I've seen is that the gadgets can be found in different modes. The same function can be found in two different types of instruction sets all in once. You can analyze a function in R mode and have different instructions that we have in thumb mode, right? Kind of as expected versus 32 versus 16-bit instruction sets. So and then at the very end, you also have something called POPPC, which can be used for your ROP. So you just POPPC, POPPC, POPPC or RET, right? So interfacing with JTAG or interacting with JTAG. So this is an Arduino Zero that I bought. I use it more because I had a Cortex processor and I wanted to play more with real-time devices. So this is the JTAGulator, like I said in the beginning where you can use the Arduino, blah, blah, blah. But I just wanted to learn actually like how does this work? So on this device, JTAG is listed out. I was like, let's brute force this and see what happens. So that's what, this is JTAGulator. You just hook up as many pins you want. Before I even do that, who here has heard of JTAGulator? I am not going further with what I was going to say about JTAGulator. Very straightforward, right? So, next step though. All right, so I find TDI, I find, you know, I find data in, I find data out, I find mode select, I find everything I need, I find the clock, now what? Now you have to actually interact with that interface, right? You have to actually talk to it. The same machine will still be the same but the instruction registers and data registers think of it as operand and opcode. Same thing, right? You have an opcode and then operand to go with it. Same thing but it's in JTAG and they're very small registers. So this is an open source project that I used called OpenOCD and this one it's funny because one of the devices that's in the other room I actually used OpenOCD to talk to JTAG so it's actually pretty cool to see that in here but once you have JTAG open and you actually can talk to it you can't just say OpenOCD my FTDI chip that's connected to JTAG. No, it has to actually know the profile. So if you go online these things have many, many, many profiles already for a lot of chips and different manufacturers like Amazon chip maker, right? It's instruction sets and all that shit. But different manufacturers will implement the same JTAG state machine and all the instructions and everything else the same. So different type of manufacturers will use the same OpenOCD configuration. Also new versions of the chip may also work on older versions for that JTAG as well and vice versa. So don't get stuck when you can't find the configuration file for your exact processor. Find something around it or with the same architecture and it may be the same. So when you open it up though this is just for people who have never used it before. You have GDB server that opens up locally and you can start dumping memory. You can do whatever you want. It's GDB, right? So what's great about this is this was on Cortex processor and Cortex has a very specific memory layout and with this one there's a specific memory address if you look at the data sheet you could dump AS keys and all that good stuff. So this is very powerful when we want to kind of extract information from it that we can't get to it normally like maybe SPI the flash chip is encrypted or all this other crap. So this is our last resort. I always like to say that start with the software stack first exhaust all your resources then go to hardware and start from easy to hard. It's the same thing that we always do in our everyday lives. So once we have the JTAG connected and it's connected to it we can say how fast is the clock going? I want to measure this I want to reset the entire processor and then halt. I want to set a break point when like you know say at this memory not memory address when memory address being written to here or like when the kernel is being loaded we can do so like for example if there's UART password you can use this at a watch point when the kernel arguments are being loaded to single user mode let it load done. So wrapping up so I want to say thank you guys a lot for sitting through this I know I've been a little repetitive a little fast but thank you guys this is wrapping up now so this is my project this is the demo that I gave you guys this is called my damn vulnerable write up firmware where it just come from this is the literal story I was in my shower thinking about damn vulnerable web app, damn vulnerable Linux I was like that's so silly there's so many of those there's not one for routers so I'm going to make one so that's what happened but how did I do this remember that tar ball thing I told you from a while ago this device was sitting in my closet not doing anything it's a $10 device now it's an 802.11n and I just picked up my thing I was like oh let's start writing firmware for this let's actually do it so that's what I did I downloaded tar ball and just started ripping they did everything and just made my own custom tar ball for it and that's on github you can download it you can fork it you can do what the hell you want with it but that's how this works so I'm working on another device the device is actually actually they actually have it in there as well it's a trend net it's an ARM device as well I'm just having issues compiling the kernel it keeps bombing out for some reason saying that processor H is not found so once I figure that out and kind of fix that then I'll have another DVRF build for ARM and what's good about this is that there's two ways to do this you can put the firmware on your device you can always revert back to there's not a one-way street and when you do that the ponables that I have on there are only accessible through UART you have to start them through UART so this forces you to open up the device plug through UART, find the directory find the executable, run it or you can emulate it I prefer both ways to see who cares right but this this idea was to learn to help people dig into this get the hands-on experience with exploiting stuff outside the x86 space and also help IOT developers I say IOT like this just it's a keyword that's very stuck in my brain so help people learn this stuff as well because I've seen 90s programming code in today's architecture when I was doing example codes of star copy and just you know funny stuff that's actually happening today I will be demoing an exploit tomorrow that's an actual one that I found that does this kind of stuff and I'll be chaining four volumes together in order to get complete compromise that'll be for tomorrow's in the IOT village same with the plug so this is where you can download the damn vulnerable router firmware stuff on github, it's the link it's on pre-tourines github I am updating it if you want to update it as well maybe if I can teach what I've learned that's all I want to do with all this stuff if I can learn it, you can learn it as well I'm not some amazing guy, I'm just some little kid from Texas my future plans is to keep working on this stuff do the ARM one, get that finished I have a blog post that I've done on introductory to hardware exploitation and then getting started with this project as well and that code for this exploit that I demoed is on the blog as well fully documented as well you can copy and paste it and do whatever the hell you want the shellcode is in there as well from BoCaster and yeah, take a look at it I'm also available on Twitter and I'm always available to help you guys out there's no such thing as a dumb answer or dumb question, maybe a dumb answer from me no such thing as a dumb question if you are confused, lost, need some help or going, hey man, I've been probing this thing for hours can't find anything to help me out I'm always here to help you guys that's what I want to do is teach and help people grow that's what we're all doing here, it's to grow conferences so before we wrap up I'll be holding a workshop tomorrow at the IOT village at 10 a.m basically it's a bring your own device type thing or maybe take one, borrow one from IOT village or just share one from a researcher we're doing a zero day hunting workshop but we're not just finding volums we're going to take it all the way to code exact two so attendees will be encouraged to craft exploits for the volums that they find just because of disclosure policies stuff like that will be safely disclosed over PGP or whatever communication the vendor prefers to the vendor first and then we'll do the exploitation and get that underway and then you can go claim your prizes or whatever but I just want to help people actually find this stuff and get the hands on experience we sit here and watch and watch and watch and actually do stuff and actually commit it so that's tomorrow at 10 a.m IOT village I can put this out online if anyone wants it you guys take pictures to the camera meter that I use and the USB microscope literally Amazon came in tried it out, worked great nothing more crazier than that but the one thing I use a lot is the FT232 which by Adafruit is $15 the equivalence to Sheikra which is $50 has a little bit more to it but it's the same chip so depending on your budget you may want to go through that route but that's the end of my talk I appreciate you guys sitting through this are there any questions for we say that? Yes the question was around was it a manipulation of chips if JTAG is disabled and stuff like that so there's one question around that too how is JTAG disabled? is it software disabled or is it a fuse if it's a hardware disabled it's kind of screwed unless you can decap it and fuse that fuse back together to bridge it if it's software find a reset pin ground it or do what the data sheet says but it's usually ground it powered on everything will turn on and no software will be loaded and the JTAG state machine will be accessible but if it's the latter you're kind of screwed so that's the only downfall right yes if GDB what? so I have cross-compiled GDB and I can teach you guys how to do this well so on my device as well I had there's no GDB on it and I had to craft my exploit so that's why I was doing the emulation route from MIPS and I believe it was like MIPS big Indian little Indian for generic instruction MIPS 1 so on there you can compile it yourself it's a little bit pain in the ass but it's doable so you would have to cross-compile it yourself put on the device or if the device has enough space on it you're going to have to go through the emulation route so that's the only two ways cross-compile it yourself put on the device because most devices usually have WGIT so put GDB on it run it or just emulate yourself through QEMO or whatever you want to use so that's if what? if you have access to GDB oh you can put GDB server on it GDB server and then just attach it to the process have it listen on socket connect over socket over the network and that's it that's the way I've done it like I've always see there GDB and then I put GDB and I use it over serial interface or GDB server connect over socket and just do everything like that or just emulate it that's pretty much it, nothing too crazy there are there any more questions? yes so the question was what is the hardware that I use to talk to the flash chips and stuff that is the Adafruit FT232H breakout board it is a FTDI chip and it supports JTAG, SPI, SQC, UR that's about it but there may be more but that's what I used and in the open OCD you just tell it the driver to use is FTDI it will automatically attach to it so yeah that's $15 so that's the one I use any more questions? yes so this one is kind of a heavy question so he was talking about the Cortex M3 M4s you know the real time devices and the trusted model trust the models right? yes trust the platform I haven't looked into that so I don't know at this time so I would have to follow up later so right now I just don't know I don't want to give you a bad answer so yeah let's sync up afterwards because I want to find you that answer because I'm curious now as well any more questions? yeah sure so if you guys want to see what's going on my not so interesting life hold on one second yeah so my twitter is it's black owl but someone already had that name so I said no so I replaced the L with the 1 and the O with the 0 that's about it nothing too crazy the images I was fuzzing live PNG with an owl image and it looked pretty cool so I took a screenshot so yeah that's about it any more questions for I just wrap up nope great again thank you guys have a great conference