 So first I applaud your enthusiasm for embedded vulnerability analysis because you know who cares how this badge works and what cool stuff is on it right so I'll probably go there after my talk but anyway I'd like to give a big thanks to my colleague Mike Costello who's going to help run the demo. My name is Ang Tui and I'm presenting Frack the firmer reverse analysis console and actually I gave this talk yesterday at black and I ran out of time a little bit so I'm going to make this talk small so I can or short so I can give you guys a really long cold demo of all the stuff I didn't get to show yesterday. Who am I? What I do? I'm some guy. I go to Columbia. I'm a co-founder of a company called Red Bullen Security. I write academic papers sometimes about the defense and exploitation of embedded systems and on the offensive side you know I like to do some tinkering with these devices. Last year I presented a root kit at blackhead that ran on a large number of Cisco IOS router images in an OS agnostic way and a few months ago I discovered the HPR few arbitrary firmware modification vulnerability. So just out of curiosity how many of you guys have heard that or heard about that? Good. How many of you guys went out and updated the firmware to your printers? One? Okay this is the right crowd. How many guys went out and updated the firmware to other people's printers? All right good. Excellent. As part of the presentation I did for our chaos communication congress I wrote this root kit for this laser jet printer that turned it into among other things a reverse IP proxy. Now this is useful because once I compromise this printer through a malicious print job I can then use this reverse IP proxy to tunnel through the corporate firewall, the perimeter firewall and using that printer to compromise machines inside the protected network. And in fact my demo used Metasploit I just auto-poned in through this proxy printer to own machines inside the protected environment. And I started working in a third embedded device type which will remain unnamed for now and I realized that my workflow for this type of thing looks pretty similar. The stuff I did for Cisco IOS root kit and the HP laser jet root kit and even the work that I do on the defensive side for red balloon security usually starts with this. It starts with the analysis of the original binary firmware image that I get from the vendor. If you think about it this is really useful if you want to understand how this mysterious embedded device works, how if there are vulnerabilities inside and how you can protect these embedded devices against exploitation you really want to run some useful analysis on the code and the data that reside on these devices. That says firmware analysis by the way. And by useful analysis I mean static analysis, dynamic analysis, tank tracking, symbolic execution, vulnerable library identification. These are things that we as security researchers know how to do fairly well for general purpose computers but of course we're working in the embedded space where things are a little bit more complicated. In order to do this for embedded devices you're going to have to go through this laborious terrible process called guess what the proprietary firmware format is and unpack it reverse engineer that. And only when you finish doing that can you really get to the part where you start doing useful analysis on the binary, on the data and the code. And every single vendor uses a different former packing format. It's all security through obscurity. This doesn't buy them any security at all really. But what it does mean is that for security researchers to look at this code and data you're going to have to spend a lot of time reverse engineering through these mysterious file formats. And like I said every vendor is different but you know I generally start the process by trying to find something that serves as a package manifest. Some binary header that tells me how many records are contained in the firmware image. And there's generally more than one. The sizes of these records maybe they'll give me some hint about what they do and how they're encoded etc. But not always. Once I figure this out I go out and I extract the binary records. And for every single one I have to figure out whether the record contains data or code. Whether this is obfuscated in some way, compressed in some way, encrypted in some way. And for every record I need to figure out whether there's a checksum algorithm or digital signature attached to it. And when I've done this I'm actually not done because this is not a single step process. It's recursive. Right? Because if you think about it a lot of times when you unpack a binary image often times you'll find another packed image inside that unpacked data. So for example suppose you extract a binary record that holds the boot image for an embedded device. Often times you find some code and inside that unpacked data you're going to find let's say a compressed binary record that contains the root file system for the device. So you really should think about this as a recursive process where the root of the tree is the original binary firmware and you're recursively expanding down the tree until you extract every single binary record. And when you're finally done, when you finally get to this place, this is when we can actually start doing some useful analysis on the software and the data that lives on these devices. And if you do what we do at Rebellion Security you're also interested in modifying the firmware. Changing the device behavior. You know, be it for offensive purposes like making a root kit or for defensive purposes like injecting whole space defense into these embedded devices. If you want to make modifications you're going to have to essentially do this entire repacking process. Everything you did for the unpacking you have to do in reverse recursively up this tree repacking every single record until you get to the top of the tree where you get a single binary image that contains all a packed version of all the modified code and data that then you can put onto a physical device for testing. So I did this a few times and I started thinking about where I spend most of my time, what's efficient, what's not efficient, what I can do better. So for, you know, whether I'm doing offensive work or defensive work, I usually start by, you know, figuring out how I want my payload to work. I spend some time designing it. I spend some time implementing it. Spend some time testing it. But this is by far not where I spend the majority of my time and not how I spend my Friday night. Most of the time I spend when I do this type of work is playing this terrible game called stare at the binary blob until I figure out the proprietary format of this firmware image. To give you guys an idea of what I'm talking about, this is what I do on Friday night, right? So here's a typical printer firmware image for an HP laser jet printer. You know that this contains code and data that's really useful for analysis, but in order to get anything useful out of it, you're going to have to start figuring out what the purpose of all of these bytes are, right? So for example, do I get a cursor here? Can you guys see that? You know, you can see here, this is some ASCII header, right? That's easy to understand. And, you know, down here you see some zero alignments, right? So this kind of looks like a table. You know, this is good. You have to figure out what the actual format is, but you know, that's looking pretty promising. And then after that, when you get to somewhere around here, the data gets really random and you know, who knows what's in there. It could be code. It could be data. And if you have stared at this blob for as long as I have, you'll know that 789C is the header for a compression algorithm that I'm not allowed to name. But the point is, you're going to have to spend a lot of time staring at this thing to figure out how you can actually do some useful analysis on this data. This game sucks. It wastes a lot of time is laborious. You have to do this for every device vendor and every time, every time you do it, you know, the process is the same, but it's different and it takes a lot of time. And the thing about it is, this doesn't actually push embedded security forward at all. This is just the hard work that you have to do in order to get yourself to a place like here where you can actually do something useful for embedded security. Now, wouldn't it be great if we had a tool or some automation that reduced the amount of time that we have to spend here so we can start concentrating on making, doing useful work here. And that's exactly why I wrote Frac. Frac stands for the Firmware Reverse Analysis Console. It's essentially a software framework that allows security researchers who want to get into the embedded game to get into this easily without having to spend a lot of time in starting the binary blob purgatory. And all of this code is going to be open source very soon, so I'm not going to talk about implementation level details and how it works. I want to give you guys a high level view of the different components of Frac. There are four major engines and these engines are modular in design and it very closely mirrors the workflow that I just talked about. On the left side, you have your unpacking and repacking engines. These engines are the firmware format dependent portion of Frac which has been minimized as much as possible. So here's an example. The Cisco iOS unpacker, for example, is responsible for unpacking a Cisco iOS image from the vendor, extracting the binary records in an unpacked form into an intermediate format that Frac knows how to manipulate. And then you have your corresponding repackers too that does obviously the opposite of what the unpacker does. Now, this is the firmware format dependent part. Here on the right side, you have your modification engine and your analysis engine. These modules are the firmware format agnostic part. So think about it. Let's say you wrote a symbolic execution engine to look for bugs for Cisco iOS. Now, wouldn't it be great if you could do that? You can use the same code, not on Cisco routers today, but on HP printers tomorrow. And with Frac, you can absolutely do that. So here is the workflow that I just talked about in Frac World. Let's say I'm working with Cisco iOS images. I use the firmware format dependent unpacker module. This module extracts every single record into an intermediate format. And then send those records over to the modification and analysis engines to do whatever analysis and modification I like. And you can do this in an iterative cycle. So for example, you can use the output of an analysis module as input to a modification module. And you can do this for as many cycles as you like. Now, when you're satisfied with the results of your analysis and your modification, you then send these records back to the repacking engine, right? Which then will spit out a single iOS image in this case that you can then slap onto a CF card and test it on your physical router. And we're going to show you this in our demo. So I'll give you concrete examples of what I mean by, you know, a modifier module and an analysis module. I'm also a really lazy programmer. And I know that other people have super cool wheels and I don't want to reinvent that. So the analysis engines very closely integrate with tools that we already use every day for security analysis, right? Tools like IDA Pro. Everything that you've written as far as IDA automation, whether it be dynamic or static analysis, automatically integrates with frac as it is today. I've also integrated bin walk into a lot of the auto analysis features, which you'll see in the demo. And apparently I'm working on integrating MATLAB for some of my own analysis that has to do with entropy related stuff, which I'll also show in the demo in a few minutes. Decay stands for console. And there is a very bare bone minimal tool, GUI, that the user can use to unpack, modify, explore, repack these binary images in real time. But frac is just a software framework and you can call it through library calls. And for example, this is all the code you would need to run in order for frac to unpack a Cisco iOS image. Identify a particular string inside that image. Replace it with whatever you like and then repack that image into an iOS image that has all of the proper checksums calculated, et cetera, that you can then slap onto a router, a physical real router for testing. So, you know, this is my workflow without frac. And in a lot of ways I consider this just the dark ages of embedded security analysis. This is my workflow with frac. I spend a lot less time staring at the binary blob and I spend a lot more time doing useful work as far as analysis and modification. You know, things that I think actually pushes embedded security forward. And this is what I hope frac will do for the community. I hope frac will allow security researchers who want to get into this game to get into this game easily without having to spend a lot of time staring at the binary blob. And I hope frac will collectively save the community some time so we can all just stop wasting our time with that and start getting on with making useful contributions to furthering embedded security. So, blue through the talk, Mike is going to start the demo. We're going to show you guys frac in action. And we're going to start by loading up a Cisco iOS image. This is something you can just download from Cisco. Here we're using a 7200 router image. All right, so this is a frac console. And as soon as Mike loads the frac or the iOS image into frac, frac is going to actually run a lot of auto analysis modules that tries to determine as much as possible the nature, the content of the binary record that we just loaded. So, at this point, we haven't told frac that this is an iOS image. So, you'll see as soon as Mike runs the load command, a bunch of auto analysis modules are going to run. And it's going to give us some useful information about what this firmware image that we're working with is. So, notice first that the entropy, every binary record inside frac, I automatically go out and compute the average entropy value for the binary. So, this value is anywhere between zero for non-random to eight, which is completely random. It's a modified binary Shannon entropy function. I also noticed that frac found out that this contains a MIPS header and actually has a MIPS ELF image at the header of this thing. So, this is kind of strange, right? Because, you know, we'll have a very random file that's large. We also have an auto header. So, we're going to use the Cisco iOS unpacker on this image. And this creates three children records, right? Each one of those records will have its own auto analysis done for it. So, you notice that the first record is this very small executable code that contains an ELF record that has, um, its MIPS is beginning. But the second record, very large, right? This is, um, it contains a Zlib, uh, or PK zip header. So, we're going to use the generic PK unpacker to extract that record. And this is the meat of, you know, iOS. This is the unpacked binary that you want to modify if you want to change the behavior of this router. Uh, another thing I want to show you is some very cool things that for, as far as analysis goes, you show them the, um, the entropy map for the boot loader. So, oftentimes, you know, you're going to look at a binary record and you're not exactly know what the structure of the file is. But what I did here is I have an analyzer that goes out and generates, oh, here, just do it again. Just run the analyzer again. Anyway, so this thing goes out and generates a 2D image of, uh, the entropy map of the file. So this gives you a visual idea of, you know, the structure of the data that you're looking at without really understanding what the actual specific structure is. So analyze, show the, uh, show the entropy map again. Okay, so this is, you know, this generates quickly. I want to show you some pre-generated images, um, that I did last night for the rest, entropy maps for the rest of the records. Can you show that? That's in the directory. Yeah, here. So, let's just show this one. So for example, this is an entropy map for the unpacked binary record that represents the executable code for the Cisco router, right? So if you've ever seen, you know, what an elf record should look like, this generally, you know, holds true. The black is low entropy stuff, uh, gray is middle entropy, which usually is, you know, executable code and white is completely, uh, random. So this looks like an elf record, right? You can see that visually. Uh, let's show them the IDA interactive integration. So, I mentioned the analyzer is going to integrate with, um, IDA Pro and we're going to show you that. Uh, do FS first. Alright, so Mike is going to run the IDA interactive analyzer on the executable record for Cisco iOS. Now all of your IDA Python stuff, all of the automations you built for IDA Pro interacts automatically with this, or integrates automatically with Fractu, okay? Um, so now we're going to have some fun. We're going to start modifying this from our image. For that, Mike is going to run the string finder analyzer. So this is something that's very simple. It just looks through a binary record and it tries to find a string and it tells you the beginning of the string, the length of the string, right? And the string we're looking for is, this product contains and you'll see why in a second. Okay, now once that's done, right, notice the meta information that's generated by this analyzer tells you the length of the string and the location of the string and the record that you're interested in. Now Mike is going to modify this record using a string replace with file modifier, which takes the offset that you want to replace, um, and the content which is in a file. And there's an overrun flag to see, to ask you whether you want to overrun the length of the string. And in this case, it's okay. It's just for demo. So, um, okay, you can do FS first. Okay, now once that's done, notice that there are two asterisks next to the record that we just modified, right? That means that that record has been modified. So Mike is now going to use the generic PK zip packer to pack the middle record and then once he's done with that, he's going to use the, our Cisco iOS packer to pack the entire image into a Cisco iOS image that we can then test on a router. And then as soon as that's done, we're going to fire up the original Cisco iOS image and then we're going to fire up the modified image in Dynamics and show you guys, you know, this iOS image running. Now, as soon as Mike runs the Cisco iOS packer, this is, this is where all the magic happens. This is where the packer calculates the appropriate checksums for the unpacked and uncompressed and compressed data records. And it fills in all the meta information that, you would need to get, to form a well-formed, legit Cisco iOS image that the bootloader and the router will use. Okay, now the unpacking is done. You see the meta information being exported. We're going to export this to disk. So why don't you show them what the records exported to disk look like. Do you not have that? Okay. Okay, we export it to this directory here. So Frack exports every step of its process into files so this is, you know, so that it's easy for you to work with intermediate output of Frack. And the thing we're interested in is this image here in the repack directory. That's the file that we just generated. So now Mike is going to fire up Dynamics, which is a Cisco iOS emulator. And in here we have two routers. One is the unmodified router, so I want to show you why we look for this product contained string. Okay, this guy's loading, loading, loading. Right, you see, as soon as the router boots up, this is the shell version string that says, you know, this product contains cryptographic functions not suitable for export, whatever it is. Okay, so let's check out our modified iOS image. It already booted up. Right, so we're going to do shell version. This comes up. Who knows who... Does anybody know who this handsome man is? Just shout it out. Anyone? Bueller? Bueller? It's John. It's John Stewart. He's the CEO of Cisco Systems. So I don't know if he's around, but you know, I put his face in his own router for fun. So that's it. That's our demo. One thing I want to mention is the state of support for frack now we have Packers and Repackers for Cisco iOS obviously. We also have Packers and Repackers for Cisco CNU, which is the firmware that you find on Cisco IP phones. Not the signed version, just the unsigned version. And also HPR View, so you can actually start analyzing data you find on laser printers and repacking them, making your own firmware images. And, you know, if you do this and use our tool, you'll find a lot of stuff that I guess I won't talk about now, but it makes you unhappy inside these firmware images. Right, that's John. Frack will be open source very soon, so we're working hard to get that out there. I want to do one more past internal code review before you guys see my dirty laundry. But please, sign up for our mailing list. We're going to let you guys know as soon as the code is up. The project page is frack.rebulancesecurity.com. And the last thing I want to say is thank you for DARPA Cyber FastTrack. I mean, I have nothing but good things to say about this program. Our work is funded partially by Cyber FastTrack. And also X colleagues from the Intrusion Detection Systems at Columbia wrote this really cool book, book signings at 4 o'clock. So that's it. That's my talk. Thank you very much.