00:00:00.400-->00:00:05.506 >> Thank you! >> We have our next track. Network.. or next talk, Network Protocol Reverse 00:00:05.506-->00:00:11.211 Engineering with Tim Estell and Katea Murray. And your podium seems to move Uh so you guys 00:00:11.211-->00:00:16.216 give it up. [Applause] >> Thanks! The you know Network Protocol Reverse Engineering but 00:00:19.987-->00:00:24.992 don't fuck with the network so, do this at home, not here right. I'm Tim Estell this is Katea 00:00:28.729-->00:00:34.134 Murray. Katea has been coming to this since uh we were at the Alexis Park, 12, Def Con 12. 00:00:34.134-->00:00:38.538 First Def Con we came to. So this is our first time speaking though. She's been to other 00:00:38.538-->00:00:41.642 conferences but this is her first time speaking at Def Con as well. So [Applause] Good job! 00:00:41.642-->00:00:46.647 >> Thanks, Tim. And uh this is Tim, uh Tim's been having on and off, he likes to say since the 00:00:50.951-->00:00:56.156 80's. And uh he's been going to Def Con and Black Hat as well. Um, a special note about Tim, 00:00:56.156-->00:01:00.694 this is his first time speaking but I blame Tim for everything. Um so if something goes wrong, I 00:01:00.694-->00:01:04.398 blame Tim, so if this talk sucks, blame Tim, but if you like it, you're welcome. 00:01:07.167-->00:01:10.971 [Laughter] Okay so just to kind of get us started. Um what's this talk about. So sticking 00:01:10.971-->00:01:16.009 with the theme of Def Con was the Rise of the Machines, right? So we wanted to focus on 00:01:16.009-->00:01:20.847 communication protocols. >> [Audience: Can you make your font bigger?] >> Can you make 00:01:20.847-->00:01:25.852 it..? >> No. >> Can you make it bigger? [Laughter] >> Sorry >> Can you make it bigger? >> No we 00:01:31.258-->00:01:36.263 can't make it bigger. >> Tim says no, blame Tim. [Clapping] >> Thanks, thanks. >> Alright so 00:01:39.633-->00:01:44.638 anyway, sorry about the font. But the slides are on the CDs at least I'm pretty positive so if 00:01:48.508-->00:01:53.447 you wanna get them there. Um so anyway, we wanted to focus on Network uh Protocols anyway. Um 00:01:53.447-->00:01:58.385 we know the machines would communicate, um we wanted to be able to listen in. um unless 00:01:58.385-->00:02:01.388 you're part machine, we figured that we're not gonna understand the languages. So that's kind of 00:02:01.388-->00:02:05.459 where Network Protocol Reverse Engineering kind of comes in. Our hope is by the end of this 00:02:05.459-->00:02:09.796 talk that you'll be able to try reversing protocols yourselves. Obviously not here. After the 00:02:09.796-->00:02:13.300 service announcement, do not do it here. [Laughter] Um, and hopefully that you'll walk away 00:02:13.300-->00:02:17.304 with like a repeatable process. I mean for most of us that maybe have done this, there's lots of 00:02:17.304-->00:02:21.708 them so hopefully we can give you one. Um and then another one would be maybe if you could go 00:02:21.708-->00:02:26.013 any of the villages. I know the ICS one's not here this year but Internet of Things or one of 00:02:26.013-->00:02:31.284 those and try your hand at hacking. So quickly, the stretch of our talk is what we're gonna 00:02:31.284-->00:02:35.422 do is a quick overview and answer some questions, just to kind of frame things for you of 00:02:35.422-->00:02:39.993 what is Network Protocol Reverse Engineering. And then after that what we wanna do is um have a 00:02:39.993-->00:02:44.831 deep examination of some packets from some example machines that we have. Like FitBit or last 00:02:44.831-->00:02:49.870 year Tim's hacking at the ICS, ICS Village at Def Con. So we'll use those as some deep examples 00:02:49.870-->00:02:56.576 to show you guys. And lastly, we're gonna try to look at some tools and tips to keep you guys 00:02:56.576-->00:03:01.248 motivated along the way. Alright so getting started, what is Network Protocol Reverse 00:03:01.248-->00:03:06.420 Engineering? Um at the end of the day, it's just an approach or a process, really. Um 00:03:06.420-->00:03:10.057 basically it analyses protocols. Um as we've determined, we want to be able to listen in on the 00:03:10.057-->00:03:14.995 ma, machines. We wanna be able to control or influence the conversation. Um approaching 00:03:14.995-->00:03:18.665 Network Protocol Reverse Engineering pretty much involves breaking down protocols so you 00:03:18.665-->00:03:23.303 can kind of understand them. Um I'm sure a lot of people have captured packets with tools but 00:03:23.303-->00:03:26.273 when you get to it and you open up you're like oh shit, what does this mean? [Laughter] So 00:03:26.273-->00:03:31.011 sometimes, it's, we're trying to give you a process to approach us so when you do open up, you 00:03:31.011-->00:03:35.515 have the confidence to kinda understand what's there. Um and this talk, like I said we wanna 00:03:35.515-->00:03:40.220 examine like message formats with simple protocols as well as the state machines and traffic 00:03:40.220-->00:03:45.725 of a few devices for analysis. Um basically you can think of Networking Protocols as 00:03:45.725-->00:03:52.466 basically... it's not really coder software, it's just rules that get implemented. Alright 00:03:52.466-->00:03:57.337 so, the obvious thing here, is uh aren't there tools for that, right? So let's, let's ask that. 00:03:57.337-->00:04:00.774 Um there's tools out there that can help you break down these protocols. Um so the answer to 00:04:00.774-->00:04:05.545 that is , yes. Okay? Yes, there are tools for that. There's lots of tools that can help you 00:04:05.545-->00:04:10.550 decode and break down protocols. Can anyone give me a name of a top one. [Indiscernible comments 00:04:13.787-->00:04:17.958 from audience] >> Stand up John. >> Do we have another one besides for Wireshark? 00:04:20.660-->00:04:24.731 [Indiscernible comments from audience] TC Dump. [Indiscernible comments from 00:04:24.731-->00:04:29.736 audience] Alright. So, [laughter] One more, what do you got? >> It is Wireshark. >> It 00:04:34.875-->00:04:39.880 is. Yeah. [Indiscernible comments from audience] >> Alright so... >> So Cal. 00:04:43.283-->00:04:45.285 [Indiscernible comments from audience] [Laughter] >> Almost. >> Almost. Really? Last one. 00:04:45.285-->00:04:47.287 [Laughter] Alright so here's some of the tools and pretty much you guys were listing them. 00:04:47.287-->00:04:51.224 Obviously this isn't them all, but this is just a few. Um so you know, the thing about these 00:04:51.224-->00:04:54.594 tools, is there's lots of tools to help you. Right? So there's lots of tools, depending on what 00:04:54.594-->00:04:59.166 you like to do, what you like to use. But one of things that we know come, with using tools, 00:04:59.166-->00:05:04.070 they all have limitations. Right? So tcpdump, it's great, you can collect packets. Um you 00:05:04.070-->00:05:08.675 can use it for splitting, merging packets, filtering packets. Um but in some cases it 00:05:08.675-->00:05:12.913 lacks that ability to do layers of analysis or it has a lot of vulnerabilities in it. 00:05:12.913-->00:05:16.383 Wireshark. Probably everyone here probably uses it or are familiar with it. I know I use 00:05:16.383-->00:05:21.021 it all the time myself and it's a common tool for doing packet analysis. And while it can 00:05:21.021-->00:05:25.592 separate out the individual conversations it can't dissect the packet for you. Or identify 00:05:25.592-->00:05:28.995 changes between a packet and sometimes it really.. it doesn't have the ability to show you the 00:05:28.995-->00:05:35.035 state machine. And IDA Pro, while not really a packet analysis tool but if someone 00:05:35.035-->00:05:38.872 wants to look at a binary or look at code and look at API calls. There to be able to 00:05:38.872-->00:05:43.877 understand communications, you can use IDA Pro for that. Um, it provides a good picture of how 00:05:43.877-->00:05:48.415 the code is implementing a protocol but then again it... the limitation there's gonna be 00:05:48.415-->00:05:51.284 in your understanding and use. So whether or not you're not familiar with it and you don't 00:05:51.284-->00:05:57.424 know what you're looking at, again that could be a limitation. So Motivation. 00:05:57.424-->00:06:00.994 Alright so we know there's a process, right? We know that there's tools to help. So what's 00:06:00.994-->00:06:05.865 gonna be our motivation to try to learn how to break down these protocols. So the one idea is 00:06:05.865-->00:06:11.605 maybe you're a pen tester, so maybe your job is to do packet network analysis at your job. 00:06:11.605-->00:06:15.308 You wanna be able to know what is coming in your network and leaving out, out of your network 00:06:15.308-->00:06:19.646 right? Um you may have the packet capture so you're suing Wireshark but if you don't 00:06:19.646-->00:06:23.583 understand the protocols, answering customer questions becomes a lot bit harder, right? 00:06:23.583-->00:06:27.520 And you can use Wireshark for common protocols but what happens if it's an unknown 00:06:27.520-->00:06:31.825 protocol. It's something Wireshark hasn't seen before. It's gonna barf, it's gonna die. 00:06:31.825-->00:06:36.963 So what do you do then? So that's your oh shit moment right? So if you can reserve the 00:06:36.963-->00:06:41.067 protocols, if you can show what data is being there, and kind of the system workflows, that's a 00:06:41.067-->00:06:45.272 better answer for your customer right? Here's the data, I now exactly what's coming in and out 00:06:45.272-->00:06:48.975 of your network. Another reason is maybe you set up a home network. Right, so you got a lot 00:06:48.975-->00:06:52.679 of gadgets on your home network and you want to be able to see what's going in and out of your 00:06:52.679-->00:06:56.283 home network. That might be another motivation. Another motivation might just be 00:06:56.283-->00:06:59.819 curiosity. Right? You just kind of want to learn these things for yourself. To just start 00:06:59.819-->00:07:04.691 getting used to it, seeing what you can do and again because the machines take over, you want to 00:07:04.691-->00:07:09.696 be able to listen in. So how hard can it be? Uh, well depends on how you approach it. Right? 00:07:12.332-->00:07:17.137 So people design protocols and people are predictable right? So most people are gonna follow a 00:07:17.137-->00:07:20.540 certain logic and how they structure a packet how they set up the protocol for the state 00:07:20.540-->00:07:24.511 machine. And as we said before, you know network communications are really like a set of rules 00:07:24.511-->00:07:28.715 that get implemented. What if those predictable people don't follow these rules. Right? So 00:07:28.715-->00:07:33.420 there's a lot of variance and options that leaves us with an unknown protocol. Um picking out 00:07:33.420-->00:07:38.391 a checksum field is something that we statistically do. But like trying to figure out how to 00:07:38.391-->00:07:42.962 calculate how the check sums calculated can be a tedious process. And uh the same thing 00:07:42.962-->00:07:47.233 what happens with bit field can become meaningless and they ermine in the protocol because a 00:07:47.233-->00:07:52.906 lot of times developers aren't sure if they should remove them or redefine them safely. So 00:07:52.906-->00:07:58.411 sometimes that could just be a little bit harder. Why bother? This is what I ask all the time, 00:07:58.411-->00:08:05.051 Tim. So one of the reasons why, you wanna do the video? Is why would you both to do this, 00:08:05.051-->00:08:10.123 right? So in some cases it's be.. could be because you wanna be under the side of 00:08:10.123-->00:08:13.793 understanding what's going on in your network and in other cases you don't wanna be on the 00:08:13.793-->00:08:19.799 receiving end. [Video] >> On your network. That's when I noticed something strange. 00:08:19.799-->00:08:26.573 That's when I decided to hack you. >> Hack.. >> I know you run a website called Plato's Voice. 00:08:26.573-->00:08:30.977 >> Pardon Me? >> You're using Tor networking to keep the servers anonymous. You made it 00:08:30.977-->00:08:36.716 really had for anyone to see it, but I saw it. The onion rooting protocol. It's not as anonymous 00:08:36.716-->00:08:41.721 as you think it is. Whoever's in control of the exit nodes is also in control of the traffic 00:08:43.990-->00:08:48.995 which makes me... wanting control. >> I must ask you to kindly leave. >> I own 00:08:52.832-->00:08:57.837 everything. All your emails, all your files, all your pics. >> All your pics, right. So um, >> 00:09:02.675-->00:09:07.680 Can you stand real close to the mic? >> Sorry, I..I tend to pace. Sorry. Alright and I 00:09:11.785-->00:09:15.789 apologize that the font's small so we'll we'll fix that one the next talk that we do. So what 00:09:15.789-->00:09:20.326 does uh Def Con think of uh Network Protocol Reverse Engineering? Two years ago there 00:09:20.326-->00:09:27.066 were uh a couple talks uh Jesus Malina, Jeff McDonald, Dustin Hoffman, and Thomas Kensey and 00:09:27.066-->00:09:31.070 they all presented talks on specific protocols but they didn't really step through the 00:09:31.070-->00:09:35.542 process, a generalized process for how they derived the information. And in fact, Jeff 00:09:35.542-->00:09:39.379 McDonald said, "why bother spending time understanding the protocol just to break it?" And 00:09:39.379-->00:09:43.917 he was, he was introducing a fuzzing tool. And then last year they also had another talk by 00:09:43.917-->00:09:48.088 Peter Schippley and Ryan Gooley, Gooler, who presented a talk on Insteon and they uh asserted 00:09:48.088-->00:09:50.089 that the published protocol documentation was incorrect and deceptive. And they obviously 00:09:50.089-->00:09:57.063 reversed engineered it found how it really worked and used that to exploit it. So it's a good 00:09:57.063-->00:10:01.234 example of why you wanna learn protocol reverse engineering. I mean that the publisher said, or 00:10:01.234-->00:10:04.704 the vendor said, here's how the protocol suppose, supposed to work. They reversed engineered 00:10:04.704-->00:10:08.308 it and found out that that wasn't in fact the case. And then what to academics think of 00:10:08.308-->00:10:12.245 NPRE's? So uh this really started in about 2000, there were a lot of academic papers up 00:10:12.245-->00:10:15.915 through 2010. If you look at the conference CD, we have our literature survey on there, you 00:10:15.915-->00:10:19.285 can go read it. I'm not gonna bore you with that. But basically there was a lot of 00:10:19.285-->00:10:23.756 progress where they first of all said, no it will never work, you can never do this it's too hard 00:10:23.756-->00:10:27.861 and then they gradually figured it out. And and by the by 2010 there was a lot of demonstrated 00:10:27.861-->00:10:32.398 approaches that were successful for both the generalized and the specific cases. But we're not 00:10:32.398-->00:10:35.735 gonna talk about classification algorithms and how all that works. We're gonna and try to 00:10:35.735-->00:10:41.608 give you uh some steps that you can use on your own with your own tools at home. So we're 00:10:41.608-->00:10:44.544 gonna make some assumptions here to make it simple. We're gonna assume that you're gonna start 00:10:44.544-->00:10:50.083 with some frame network protocol data. Um your Pcaps may not have the start and the full session, 00:10:50.083-->00:10:53.353 you know they may have part of the middle, or the ending, or the beginning but, it's gonna be 00:10:53.353-->00:10:59.092 framed already for you Doing self, self, starting without frame data like you're doing RF 00:10:59.092-->00:11:03.196 or if you're trying to do something off of uh a imbedded systems bus, that becomes a 00:11:03.196-->00:11:07.133 whole noter challenge and problem that we're not gonna go into. We can also assume that uh 00:11:07.133-->00:11:10.904 cryptography works so we're not gonna talk about how you break encryption keys. We're just 00:11:10.904-->00:11:15.108 gonna assume that that works and there's still value in doing protocol reverse engineering 00:11:15.108-->00:11:19.279 even if you don't have the keys and can't can't reverse it because um you can understand 00:11:19.279-->00:11:24.217 and start to see where the sessions are. And how the key sessions uh keying sessions are 00:11:24.217-->00:11:28.621 uh satiated and where you may want to try introduce form faults in network. We also 00:11:28.621-->00:11:32.325 assume legal authority. So public service announcement... announcement again. That wasn't 00:11:32.325-->00:11:37.363 planned in advance, but good timing though. Um we're not lawyers but don't be evil, don't 00:11:37.363-->00:11:43.670 try this at Starbucks or here at Caesars, try this at home. Don't go to jail. If you don't come 00:11:43.670-->00:11:49.709 for us. So here's our, here's our workflow. It's a general workflow, you collect the data, 00:11:49.709-->00:11:54.614 you frame it, you start to construct a state machine, you start to look at the fields, you 00:11:54.614-->00:11:58.184 test what you know. And then you go back to the beginning and you get the data again. And we're 00:11:58.184-->00:12:04.757 gonna step through this starting with data collection. So packet collection. Step one is get some 00:12:04.757-->00:12:09.162 packets. Right so how hard can that be? Well first you wanna get some packets in a clean 00:12:09.162-->00:12:15.301 environment. So if you, if you start here at Caesars and just start sniffing traffic on the 00:12:15.301-->00:12:19.739 DefCon wireless network, um you're gonna get all sorts of noise and if you're trying to 00:12:19.739-->00:12:22.442 look at one particular protocol there's gonna be a lot of data in there that you're gonna have 00:12:22.442-->00:12:27.113 to sift through the packets of interest. So start with a clean collection. Set up your own 00:12:27.113-->00:12:32.151 environment. Get a hub. Those are harder and harder to find, I checked today and there weren't 00:12:32.151-->00:12:35.822 any in the, in the village. I even asked for them and they said no they don't have any. But 00:12:35.822-->00:12:40.426 um trying to find the hub if you can. the other option is to do some cable splicing that 00:12:40.426-->00:12:46.032 picture, fuzzy picture there is of uh of a cat five cable thats clipped so that on one end it 00:12:46.032-->00:12:51.037 can't transmit. Uh you can also buy devices that will do this for you that do do networks 00:12:53.940-->00:12:58.945 taps. Still step up close to the mic. Alright, so we'll try that and I'll try that with talking 00:13:05.585-->00:13:10.590 to the mic. Um alright so uh and the do cold boot and reboot so the first thing I like to do is 00:13:13.259-->00:13:17.697 set up my network, wait for everything to settle down so that I know all the packs that 00:13:17.697-->00:13:21.701 are coming across the network and then boot up the device of interest and watch those initial 00:13:21.701-->00:13:24.537 packets come out because you will see some interesting things come out as soon as the device 00:13:24.537-->00:13:29.042 comes up. It may beacon for other other uh devices from the same vendor, it may send out a 00:13:29.042-->00:13:34.047 request for time stamp, it may broadcast its mac address or something, or not a mac, it's uh 00:13:34.047-->00:13:38.451 IP address. It may send things out that that you can immediately start to identify 00:13:38.451-->00:13:43.790 some of the unique protocols. And then go um through the normal sequence of using 00:13:43.790-->00:13:47.660 whatever the device is and capture those packets but then go back and look for the rainy 00:13:47.660-->00:13:53.199 day captures. Try and do it under congestion, try and do it when you introduced error 00:13:53.199-->00:13:58.137 conditions or a heavy load. Try and force the device into those other cases down those other 00:13:58.137-->00:14:04.410 code paths so that all the protocols will show up in your captures. Alright and also a 00:14:04.410-->00:14:09.215 good thing to look for is the management utilities a lot of devices have uh the vendors will 00:14:09.215-->00:14:13.453 give you a web interface or something that you can run Windows box that will go and 00:14:13.453-->00:14:17.590 find all of their devices on your network. See how its broadcasting data out and see 00:14:17.590-->00:14:21.594 what those packets are or if it has a web interface. Use the Web Interface and capture those 00:14:21.594-->00:14:25.231 packets. See if they're really encrypted, see what kind of protocols they're using to try 00:14:25.231-->00:14:29.335 and communicate to the device. Unfortunately, sometimes you don't have those choices, 00:14:29.335-->00:14:33.072 especially if you're on a pen testing gig. You're just gonna collect traffic. It's gonna be 00:14:33.072-->00:14:36.943 noisy and you're gonna get stuck trying to filter this all out. Try and, try and capture that in 00:14:36.943-->00:14:41.180 smaller P cap files, don't, don't make your job harder than it needs to be. So understand 00:14:41.180-->00:14:48.087 your environment. Uh keep it simple and and collect small p caps so you have smaller sets of 00:14:48.087-->00:14:53.993 data to start analyzing. Then you move on to framings. Um. We assume that you're gonna have 00:14:53.993-->00:14:57.130 framed data so this doesn't really necessarily apply for doing this on your home network, 00:14:57.130-->00:15:03.035 that's gonna be fairly well framed for you. But um what you wanna, in other environments you 00:15:03.035-->00:15:06.439 need to look at where the packet starts and stops. So you know where the data you're interested 00:15:06.439-->00:15:11.277 in and what of, what of that you can, you can avoid. But we're gonna assume that you starting 00:15:11.277-->00:15:16.282 IPV4 uh if you're elite, then IPV6 on your home network. Okay so then what is a state machine. 00:15:19.652-->00:15:25.825 We've mentioned that a couple of times. Uh...A State machine is really just how you, you can.. 00:15:25.825-->00:15:31.397 helps you diagram how you observe the protocol acting. So I've given an example here. This 00:15:31.397-->00:15:36.402 is at the end of a TCIP connection. The three way handshake as it shuts down. 00:15:38.604-->00:15:42.542 Should be familiar to most people here. That's what I mean by state machines. Not not 00:15:42.542-->00:15:49.482 really complex. Start with that and just try understanding how the protocol interacts with each 00:15:49.482-->00:15:52.685 of the pieces of the protocol interacts with with each other and with other devices on the 00:15:52.685-->00:15:58.424 network. So here's an example for uh a FitBit. This is uh there's uh, obviously can't read 00:15:58.424-->00:16:03.930 that but it's in your uh literature survey on the CD as well as in the slides for the 00:16:03.930-->00:16:08.734 talk and the slides for the talk for those of you who didn't get the packet will be available on 00:16:08.734-->00:16:14.674 the Def Con media server about two months after, after DefCon. So you can pull them down from 00:16:14.674-->00:16:20.813 there. Um these researchers carefully diagrammed out the whole exchange here, the point 00:16:20.813-->00:16:25.117 important point is not try and read all of those teeny lines but you can see that they have 00:16:25.117-->00:16:29.355 the state machine that they derived and they broke it down logically into four different 00:16:29.355-->00:16:35.795 phases to characterize how the FitBit device was connecting to the bay station and then to the 00:16:35.795-->00:16:40.333 FitBit server back at the mother, mother ship. And that's what you want to do. Start to 00:16:40.333-->00:16:45.538 put together how this all works. This is an iterative process, the first time through you're 00:16:45.538-->00:16:50.743 not gonna get it all. Get what you can, move on, fast entertains. The next step is is 00:16:50.743-->00:16:54.180 the fields. So this is where it really gets fun. This is the past that I enjoy. So you're 00:16:54.180-->00:16:58.851 goon be looking at the fields of that packet itself. And there are lots of different ways, or 00:16:58.851-->00:17:02.922 lots of different types of fields. We've kind of broken it down here, in a logical, to me a 00:17:02.922-->00:17:08.327 logical approach for how I would approach it. Um find your own, build your own process but uh 00:17:08.327-->00:17:12.999 let's start stepping through these real quick. So string fields. So we mentioned 00:17:12.999-->00:17:18.004 Wireshark, and the thing about Wireshark is, over in that right hand column provides uh ascii 00:17:20.373-->00:17:26.379 output of the packet itself. May or may not be readable to you. Um so that's really easy. You 00:17:26.379-->00:17:30.650 capture some packets, open it up in Wireshark, find those packets, look at it. You can 00:17:30.650-->00:17:35.655 immediately see in this case this is uh uh SOAP protocol. So it's lots of XML like data, lots 00:17:38.057-->00:17:42.728 of strings you can look at and you can start to understand what that is. This is from the ICS 00:17:42.728-->00:17:46.098 village last year. I was really hoping they were going to be here this year. Because that was 00:17:46.098-->00:17:49.936 a great opportunity to go down there and um work with an industrial control system and 00:17:49.936-->00:17:54.106 and uh play with it a little bit. Capture the packets and then reverse engineer them and 00:17:54.106-->00:17:59.111 actually influence the device. So um, XML is popular becoming more more so. You see a lot of 00:18:06.218-->00:18:12.091 JSON now, that's becoming more popular as well. And then HTML, they like to embed stuff into 00:18:12.091-->00:18:15.161 HTML and that just becomes really messy to look at. But it's at least with strings it's 00:18:15.161-->00:18:21.400 easy to look at and you can, you can start to piece it together. Alright. Almost string fields. 00:18:21.400-->00:18:26.672 What do I mean by that? Well, um binary coded decimal is something that's really strange. 00:18:26.672-->00:18:33.546 You may have seen this is this geek clock. You may have one on your desk at work. Basically, 00:18:33.546-->00:18:40.152 your, you read it, you read the binary value like a clock. You're not reading hexadecimal. 00:18:40.152-->00:18:46.792 You're interpreting the the bits, you're just basically using hex but ignoring a through 00:18:46.792-->00:18:51.831 f right? This was so common at one point that embedded, embedded system libraries would 00:18:51.831-->00:18:57.570 include math functions for BCDs. So you would, you would have your real, embedded real time 00:18:57.570-->00:19:01.607 operating system library and they would give you built in math functions for doing add 00:19:01.607-->00:19:06.445 subtract and multiply in binary coding decimal. Why was, why were they doing this? Well when 00:19:06.445-->00:19:10.516 you're reverse engineering a protocol it's a lot easier to look at hex dump and read 00:19:10.516-->00:19:14.787 decimal then it is to look at hex dump and read hexadecimal then do the math in your head. 00:19:14.787-->00:19:19.792 So we'll sometimes see um IPV4 addresses uh you'll see serial numbers, you'll see dates, 00:19:22.495-->00:19:28.167 you'll see license numbers or whatever in the protocols or in the device that you're looking 00:19:28.167-->00:19:33.172 at encoded in BCD. So uh history becomes an interesting lesson in forensics. And speaking of 00:19:36.042-->00:19:40.079 history, what, what, what do they do when they have uh old devices that they want to bring 00:19:40.079-->00:19:45.851 to the internet age. Uh, going back to the ICS village last year, there was a mod bus 00:19:45.851-->00:19:51.624 protocol that the device was using. Mod was developed in '79. The internet was developed in 00:19:51.624-->00:19:56.729 '83. When the internet came along they didn't reinvent mod bus using the internet, they 00:19:56.729-->00:20:01.967 just kind of took mod bus and shoved it into IPV4. So if you look at it, it it looks kind of 00:20:01.967-->00:20:06.972 strange but um. They've, they've just basically taken an existing legacy protocol and wrapped it 00:20:09.008-->00:20:15.181 lightly in IPV4 and there you go. It's internet ready now. And then at the very bottom of that 00:20:15.181-->00:20:20.519 you'll see that the last two bytes, I can't really read it. 0000A and that would be a lot 00:20:20.519-->00:20:27.193 easier to read in in uh read the size in decimal if it's already encoded in decimal instead of in 00:20:27.193-->00:20:32.198 hex. So Bit Fields and Checksums. This is where it starts to get a little more 00:20:32.198-->00:20:37.570 complicated.Um there are a lot of fixed field values in IPV 4, 4 headers. Um checksums show up 00:20:37.570-->00:20:44.076 as as these random strings of of bytes that are in the protocol that you see over and over again 00:20:44.076-->00:20:47.780 and you gradually begin to recognize that those couple of bytes are always looking very 00:20:47.780-->00:20:52.118 random. You can do some software that will give you the entropy measurement of that and see that 00:20:52.118-->00:20:57.556 yup it's constantly a very random series of bytes. Um, typically there'll be a fixed 00:20:57.556-->00:21:02.595 size. So 8, 16, 32 bits, something like that. And you'll be able to start identifying 00:21:02.595-->00:21:07.600 where in the protocol you've got these checksums. Whether at the beginning or at the end or only 00:21:07.600-->00:21:12.838 on certain types of packets that are coming and going. So looking at those, you now that's a whole 00:21:12.838-->00:21:19.245 other topic, that's a whole another science of how do you start looking at the the 00:21:19.245-->00:21:23.582 checksums in a protocol and reveres engineering how they built it up. What C values did 00:21:23.582-->00:21:28.587 they use? Developers are lazy. They're gonna use existing code if they can so they're, they're 00:21:32.091-->00:21:37.163 it's not impossible to figure this out. Uh there are also some really strange ones. So the best 00:21:37.163-->00:21:41.033 strange example that I can give you that you should already be familiar with is the IPV4 00:21:41.033-->00:21:46.839 checksum. The way it works is you take a couple of fields out of the IPV4, create a pseudo 00:21:46.839-->00:21:51.410 header, you match them all together. Then you attach that to the TCP header, zero out the 00:21:51.410-->00:21:55.447 checksum field and you calcite the checksum. If you already, if you didn't know that in advance 00:21:55.447-->00:21:59.685 and you were reverse eng... engineering that. That would be a really big challenge. Because 00:21:59.685-->00:22:03.155 who would ever think that you would take the header that's there and only a couple of 00:22:03.155-->00:22:07.993 fields come out of that and you string them together in a different way. So it can get 00:22:07.993-->00:22:13.933 complicated, but there again, we have the example from IPV4. That's seething that all of us 00:22:13.933-->00:22:17.937 are familiar with. So just reach, reach back and do what you know about other protocols 00:22:17.937-->00:22:24.376 and try and leverage that. And then command values, this are really just bit fields with a 00:22:24.376-->00:22:31.250 purpose. You've got uh, some, typically some indicator in the the packet or in the protocol 00:22:31.250-->00:22:36.522 itself that says what kind of packet this is. Whether this is a hello world packet or it's a 00:22:36.522-->00:22:40.793 send you a heart beat message or a status message coming back or an error message going out. So 00:22:40.793-->00:22:46.165 you can you can look at these command values, try and capture all the different types of uh 00:22:46.165-->00:22:51.170 code paths that you can exercise in the device, collect those pcaps and see if you can build 00:22:51.170-->00:22:56.008 up your own dictionary of all the commands values that you can see. You're not always going to 00:22:56.008-->00:22:59.612 see a nice sequence. Often times there is a clear sequence. You can you can see, you know 00:22:59.612-->00:23:04.550 command value 1, 2 3,4,5,7. Well obviously I missed a couple in there. Let's see if we can force 00:23:04.550-->00:23:08.787 those to come out. Other times they'll look pretty random. And that could be because they're 00:23:08.787-->00:23:12.258 doing something uh with a Hamming distance. So a hamming distance is where they 00:23:12.258-->00:23:18.464 deliberately only use the bit patterns such that any single bit flip won't be interpreted 00:23:18.464-->00:23:24.036 incorrectly as a different kind of command value. So it's not necessarily going to be a strict 00:23:24.036-->00:23:28.607 sequence. So don't spend too much time trying to force the device into an error state that 00:23:28.607-->00:23:33.612 will fill in the the blanks. And then finally the all others. So understanding what state that 00:23:35.881-->00:23:40.686 the device is in when that packet leaves the device is really important for 00:23:40.686-->00:23:47.626 understanding what what possible content that packet will have and therefore what you're 00:23:47.626-->00:23:52.865 looking for and what you're trying to reverse engineer. So for example, the FitBIt 00:23:52.865-->00:23:58.671 protocol, that that the previous slide had. And it's illustrated up here does base 64 encoding. 00:23:58.671-->00:24:03.609 Um looking at that you may, it may look kind of random. But after some time and analysis you 00:24:05.811-->00:24:10.082 figure out it's base 64 encoding, it becomes pretty easy. And then they didn't they, 00:24:10.082-->00:24:15.020 didn't encrypt it which is what made, made uh, made the research possible and they were able to 00:24:15.020-->00:24:20.793 come up with the attack against the FitBit. It was because of that. So uh... Knowing, knowing 00:24:20.793-->00:24:25.130 the state and figuring out what it's doing, and then looking at, looking at the packets and 00:24:25.130-->00:24:31.670 understanding what's in them. Alright so. You've gone through your first pass and then you try 00:24:31.670-->00:24:36.275 and test. This is where you test your assumptions and see whether or not you can convince the, 00:24:36.275-->00:24:40.446 convince the device that you're legitimate. Maybe you're trying to convince the server that 00:24:40.446-->00:24:43.382 you're a legitimate end point, maybe you're trying to convince the end point that you're a 00:24:43.382-->00:24:48.687 server or appear but try and exercise it. Send out your own packets. See if you can get the 00:24:48.687-->00:24:54.093 response back. See how far down into the handshaking process or whatever the exchange is with 00:24:54.093-->00:24:59.865 that device, so that you can start to spoof it and take, take over the sessions and become one 00:24:59.865-->00:25:04.970 of the end points. So a good tool for this is, is Python. Uh a lot of you are probably 00:25:04.970-->00:25:08.440 familiar with Scapy. I don't know if anybody shouted out Scapy when we were asking for... 00:25:08.440-->00:25:12.745 there was one okay. So somebody already... so at least somebody is using scapy, yay! And Python, 00:25:12.745-->00:25:18.617 good. Um, if you had, if the ICS village was here, the approach that you took there is you 00:25:18.617-->00:25:25.090 would, you would collect the packets, um see which see the.. which packet had the command 00:25:25.090-->00:25:31.330 going into the ICS device that would tell it to enable the the switch. You could flip that, and 00:25:31.330-->00:25:35.834 then using scapy, rebuild.. reconstruct the packet and send it out. And it wouldn't be 00:25:35.834-->00:25:39.505 accepted by the device because there was in a in a Modbus protocol environment , there 00:25:39.505-->00:25:44.076 typically is no authentication. There is no SSL, that get's added on in front of that. So 00:25:44.076-->00:25:47.379 that's wrong. On, on the device you can do that. Send the, change the register value, send 00:25:47.379-->00:25:53.352 the modified packet then change the like. And then you reiterate. You wash, you rinse, 00:25:53.352-->00:25:59.124 you repeat. Um, this can go on forever so you really have to decide up front when you're 00:25:59.124-->00:26:02.861 done. What level of reverse engineering is appropriate for your project for whatever your 00:26:02.861-->00:26:07.833 goals are. If you're on a pen test gig and you just wanna prove to your client that uh 00:26:07.833-->00:26:12.838 whatever proprietary protocol they came up with or their developers implemented uh is 00:26:12.838-->00:26:17.643 leaking data that they don't, don't necessarily want to leak across their own network or not 00:26:17.643-->00:26:22.981 adequately protecting PII across their own network. And that's maybe not going to take a lot of 00:26:22.981-->00:26:26.452 reverse engineering. On the other hand if you're trying to control the device so that you 00:26:26.452-->00:26:31.557 can remotely connect into and change the behavior or change, change the state of the device. 00:26:31.557-->00:26:35.894 That may require more reverse engineering. If you're trying to completely control it from start 00:26:35.894-->00:26:39.431 to finish the device will show up on your network, think it's talking to a legitimate server 00:26:39.431-->00:26:44.002 when it's talking to you. Uh it gets more and more complex. SO figure out up front how far you 00:26:44.002-->00:26:49.007 need to go. Understanding that you're never gonna really reverse at all unless you can 00:26:49.007-->00:26:53.612 pull the firmware and get the code and do a lot more work on that. But even with a little bit 00:26:53.612-->00:26:58.617 of of work you can really start to influence devices and change the behavior. Alright so, how 00:27:01.753-->00:27:06.758 about some tips from our own experience of of what works and what doesn't. >> Nothing works. 00:27:10.729-->00:27:16.935 Um, so one of the key things we probably want to point out is maybe find the reset switch 00:27:16.935-->00:27:23.575 right. Um protocols often contain a reset, a reset process or re-synch. Um and these could 00:27:23.575-->00:27:28.447 be like basically injected during your research to capture communications. So sometimes you 00:27:28.447-->00:27:33.252 might wanna look for that initially, that's like one tip or... Um and if you can't find 00:27:33.252-->00:27:39.391 the software protocol to reset the cycle var you just kind of maybe I think it was if you 00:27:39.391-->00:27:44.496 return it back to like an known state. So aways look for like a reset or a re-synch. Because 00:27:44.496-->00:27:48.600 normally it's always there. Um, another thing Tim likes to always talk about is Legacy 00:27:48.600-->00:27:55.541 mode. Um and the client... [laughs] Yeah, blame Tim. Um a lot of times you have different 00:27:55.541-->00:28:01.446 protocol versions so you may be able to force the software to use a different version or 00:28:01.446-->00:28:06.485 Legacy version just in case. So sometimes you can find an older version, it might be there and 00:28:06.485-->00:28:10.322 you might be able to force that. So if it's a new one or a firmware update you might be... 00:28:10.322-->00:28:15.394 uh... you have to know what you're looking for, I will say that. But maybe just initially 00:28:15.394-->00:28:19.164 just think about that. So look for Legacy modes or look for like a legacy version that could 00:28:19.164-->00:28:24.169 be coming across. >> Another good uh thing to try up front is replay. So it's easy, once once 00:28:27.873-->00:28:31.376 you've captured a couple of packets, just try and send them right back to the device. Replay 00:28:31.376-->00:28:36.114 those packets back. If the device is designed well, it's gonna have some check in there 00:28:36.114-->00:28:40.218 to make sue that it's not getting replayed packets but surprisingly enough, not all of 00:28:40.218-->00:28:45.591 devices do that. So start with the simple things and see if it works. Might also be a way to 00:28:45.591-->00:28:51.430 reset it back to a known state so that you can you can uh easily automate your discovery, 00:28:51.430-->00:28:55.801 ongoing discovery. And then there's fuzzing. Fuzzing is noisy but it's easy its kind of 00:28:55.801-->00:29:00.539 a brute force approach. A lot of tools out there that will generate packets for you onto a 00:29:00.539-->00:29:05.911 network, set to fuzz. A lot of challenges with that because you may send 16 packets and the 00:29:05.911-->00:29:10.182 device resets and you don't know which of those 16 actually started the process that 00:29:10.182-->00:29:14.052 resulted in a device reset so sometimes you gotta do some... some repetition, some guessing, 00:29:14.052-->00:29:19.057 and eventually build up what what what the fuzzing, what fuzzed packet actually 00:29:21.493-->00:29:26.465 influenced the device. And then observe where your injected packets are getting caught. If 00:29:26.465-->00:29:31.436 you're trying to convince the device that you're a legitimate end uh, server or a legitimate 00:29:31.436-->00:29:35.841 end point. Where are you, how far are you getting before all the sudden the device behaves 00:29:35.841-->00:29:42.414 differently. So you're impairing the captures, the known good uh sequence of events with your 00:29:42.414-->00:29:47.686 attempt and see how far down that iteration you're getting. And then adjusting your approach 00:29:47.686-->00:29:54.593 as you as you narrow down where you're you're falling apart. >> Um and another thing is devices 00:29:54.593-->00:29:59.097 like to be discovered. So you turn on a device, most likely it's gonna say hello to 00:29:59.097-->00:30:04.970 somebody, some where. Um a lot of these companies put in some type of way to pull for status 00:30:04.970-->00:30:10.776 or pull for updates. Um even decent firmware updates. I mean you, you guys saw like the 00:30:10.776-->00:30:14.312 instance with the Drone near the White House and they sent a firmware update. There's always 00:30:14.312-->00:30:18.550 something in some type of machine or device to like say here I am, or this is where I'm 00:30:18.550-->00:30:22.421 at or some kind of status. So sometimes look for that. Or just assume that there probably will 00:30:22.421-->00:30:27.159 be something going back to a vendor. Another thing is devices like to report status right? So 00:30:27.159-->00:30:31.763 if someone has like a smart fridge who knows. It might be reporting status to someone 00:30:31.763-->00:30:36.101 saying hey I'm still working or I'm still, i'm still moving. Um so always look for that. There's 00:30:36.101-->00:30:39.805 probably going to be a packet and after awhile you can look at it, it will be repeatable. I 00:30:39.805-->00:30:44.042 mean, you'll be able to see a signature in there that, that;s the call home or that's the I'm 00:30:44.042-->00:30:49.281 still working or that's the I just died packet or something like that. So devices are always 00:30:49.281-->00:30:54.286 talking. Another thing is tools are your friend. I have a million tools for a lot of 00:30:59.291-->00:31:03.995 different things. So use them. Um, but don;t force a tool in situations where it doesn't 00:31:03.995-->00:31:08.533 work. You have to find out what works for you. Um like earlier when we were mentioning tools, 00:31:08.533-->00:31:12.804 we had at least seven different example of packet capture tools. Um I... sometimes I use 00:31:12.804-->00:31:17.676 Wireshark, sometimes I use Scapy, sometimes I use TCP Dump, sometimes I use Socket Sniff. It 00:31:17.676-->00:31:22.314 depends on the situation that I'm in or what I'm trying to do. Um I use IDA a lot. Um don't 00:31:22.314-->00:31:26.118 force anything. So just remember that there's tons of tools, there's tons of things that you 00:31:26.118-->00:31:30.689 can use. Um and I encourage you to try them all because sometimes one situation the tool 00:31:30.689-->00:31:37.529 might be your best friend and in another situation it might be your worst nightmare. >> Earlier 00:31:37.529-->00:31:41.767 I talked about the academic research and how that had been proved and put into practice. A 00:31:41.767-->00:31:46.171 tool out there actually wraps this all up nicely for you. It's called Netzob. Um, I've got the 00:31:46.171-->00:31:50.108 website.. website up there that if you can't read it, it's netzob dot org... org. So it's 00:31:50.108-->00:31:55.747 N-E-T-Z-O-B dot org. It's available for Linux and Windows. Uh I got in touch with the 00:31:55.747-->00:31:58.483 developers unfortunately they didn't think they were gonna have any of their staff here at 00:31:58.483-->00:32:01.486 this this con but uh they have been here in the past. And they're always looking for 00:32:01.486-->00:32:06.057 people to help them out. So take a look at it, see if you can help them improve it. It kind of 00:32:06.057-->00:32:12.998 wraps... wraps it all up into easy to easy to use tool for you. Alright so what the 00:32:12.998-->00:32:17.102 important thing is uh as you go through this process, you're gonna hit some dead ends. Don't 00:32:17.102-->00:32:21.540 panic. What you wanna do is avoid the, avoid the death march syndrome where you're just 00:32:21.540-->00:32:24.609 slogging away knowing that you're not going to succeed and you're doing it anyway because 00:32:24.609-->00:32:28.547 you're punching the clock because you're supposed to do this job. So avoid that 00:32:28.547-->00:32:33.618 scenario. Try and stay creative, when you get stuck, try and try and talk to others. Come to 00:32:33.618-->00:32:38.824 conferences like Def Con. Uh look at the other, the other people out there who've who've 00:32:38.824-->00:32:43.495 uh reverse engineered protocols, read up on those, look at the legacy protocols. There's lots 00:32:43.495-->00:32:47.866 of resources out there to help you if you get stuck. And talk to other people, don't don't 00:32:47.866-->00:32:52.871 just put your head down and slog on. Um, and don't give up. So, uh... there's a lot of projects 00:32:56.541-->00:33:01.546 out there that have succeeded on some pretty amazing protocols that are hard to reverse 00:33:01.546-->00:33:05.717 engineer. It it's not impossible. And as you know as the machines come along and they 00:33:05.717-->00:33:08.687 start developing their own protocols, it's going to be an interesting challenge but I'm 00:33:08.687-->00:33:11.990 not sure that they're gonna be able to come up with something that we can't, we can't reverse 00:33:11.990-->00:33:17.295 engineer anyway. So just, just keep at it. And there's also the whole approach of, of treating 00:33:17.295-->00:33:24.269 it like a game. Uh I don't know if any of you are familiar with Super Better which is a book by 00:33:24.269-->00:33:29.307 Jane Mc..McGonigal. She has a good TED talk on this swell... as well. It's all about how to 00:33:29.307-->00:33:34.880 approach challenges from a gaming mindset and uh for those of you who play games you know 00:33:34.880-->00:33:38.116 that you've got these phases when you first get the game where you're trying to figure 00:33:38.116-->00:33:41.653 things out and nothing seems to be working. And then, then things start to click and you 00:33:41.653-->00:33:44.689 start to figure out what the techniques are that are are effective at getting to 00:33:44.689-->00:33:49.828 different levels and how to how to beat the bosses. So keep the gaming mindset, you know, 00:33:49.828-->00:33:54.833 celebrate the small victories, the small wins. Keep yourself motivated. >> Um and this is 00:33:59.771-->00:34:03.408 just pretty much just the wrap up. It, I know it's kind of small. But basically what we 00:34:03.408-->00:34:08.413 covered. So we covered what is Protocol Reverse Engineering. Why you should care or maybe you 00:34:08.413-->00:34:13.218 don't, I don't know. Depends on what side you chose. Um we gave you a process, at least Tim kind 00:34:13.218-->00:34:16.888 of went down a process for you know Network Protocol Reverse Engineering. Some things to look 00:34:16.888-->00:34:21.593 for some fields to check for. Um and then we kind of walked through, you know collect the 00:34:21.593-->00:34:27.299 data, get some packets, um frame it, right?S o figure out where the data is. Um understand the 00:34:27.299-->00:34:33.238 sessions, so the state machine. Um, look for some fields, test, try it out, and kind of the 00:34:33.238-->00:34:39.044 rinse, repeat. Um basically you just gotta keep trying. Uh you know, that initial one, your 00:34:39.044-->00:34:43.148 first will do it, once you get your own process and it might now be this process but once you 00:34:43.148-->00:34:47.319 get your own process, it's repeatable, it's a lot better. Um and then we gave you some 00:34:47.319-->00:34:51.256 tips and tools. I'm sure there's tons more if anyone has any suggestions, feel free, there 00:34:51.256-->00:34:57.429 are more shirts so um but other than that, I think that's it. >> Alright, so we have time for a 00:34:57.429-->00:35:02.367 few questions. [Applause] >> Thanks!