We have our next track, Network Protocol and Reverse Engineering with Tim Estelle and Katia Murray.
And your podium seems to move. So you guys give it up.
Thanks. Network Protocol and Reverse Engineering, but don't fuck with the network.
Do this at home, not here, right?
I'm Tim Estelle. This is Katia Murray. Katia has been coming to this since we were at the Alexis Park.
DEFCON 12, first DEFCON we came to. So this is our first time speaking, though.
She's been to other conferences, but this is her first time speaking at DEFCON as well. So, good job.
Thanks, Tim. And this is Tim. Tim's been hacking on and off, he likes to say, since the 80s.
And he's going to DEFCON and Black Hat as well.
A special note about Black Hat.
Tim, this is his first time speaking, but I blame Tim for everything.
So if something goes wrong, I blame Tim. So if this talk sucks, blame Tim.
If you like it, you're welcome.
Okay, so just to kind of get us started, what's this talk about?
So sticking with the theme of DEFCON was the rise of the machines, right?
So we wanted to focus on communication protocols.
Can you make the font bigger?
Can you make it bigger?
Sorry.
Can you make it bigger?
Tim says no. Blame Tim.
Blame Tim.
All right. So anyway, sorry about the font.
But the slides are on the CDs as far as I'm pretty positive, so if you want to get them there.
So anyway, we wanted to focus on network protocols anyway.
We know the machines will communicate.
We wanted to be able to listen in.
Unless you're part machine, we figure that we're not going to understand the languages.
So that's kind of where network protocol reverse engineering kind of comes in.
Our hope is by the end of this talk that you'll be able to try reversing protocols yourselves.
Obviously not here after the service announcement.
Do not do it here.
And hopefully that you'll walk away with like a repeatable process.
I mean, for most of us that maybe have done this, there's lots of them.
So hopefully we can give you one.
And then another would be maybe if you could go to any of the villages,
I know the ICS one's not here this year, but Internet of Things are one of those,
and try your hand at hacking.
So quickly, the structure of our talk is what we're going to do is a quick overview
and answer some questions just to kind of frame things for you of what is network protocol reverse engineering.
And then after that, what we want to do is have a deep examination of some packets
from some example machines that we have, like Fitbit or last year Tim's hacking at the ICS Village at DEF CON.
So we'll use those as some deep examples to show you guys.
And lastly, we're going to try to look at some,
tools and tips to kind of keep you guys motivated along the way.
All right, so getting started.
What is network protocol reverse engineering?
At the end of the day, it's just an approach or a process really.
Basically to analyze protocols.
As we've determined, we want to be able to listen in on the machines.
We want to be able to control or influence the conversation.
Approaching network protocol reverse engineering pretty much involves breaking down protocols
so that you can kind of understand them.
I'm sure a lot of people have captured packets with tools.
But when you get to it and you open it up, you're like, oh shit, what does this mean?
So sometimes it's, we're trying to give you a process to approach that.
So when you do open it up, you have the confidence to kind of understand what's there.
In this talk, like I said, we want to examine like message formats of simple protocols,
as well as the state machines and traffic of a few devices for analysis.
Basically, you can think of networking protocols as basically,
it's not really code or software, it's just rules that get implemented.
All right, so the obvious thing here is aren't there tools for that, right?
So let's ask that.
There's tools out there that can help you break down these protocols.
So the answer to that is yes, okay?
Yes, there are tools for that.
There's lots of tools that can help you decode and break down protocols.
Can anyone give me a name of the top one?
Do we have another one besides for Wireshark?
TastyDunk.
TastyDunk.
All right.
So that was, one more.
What do you got?
Yeah, it is, yeah.
All right.
So.
Almost.
Almost.
Right?
All right.
Last one.
All right.
So here's some of the tools, and pretty much you guys were listening.
I'm obviously visiting all of them, but this is just a few.
So, you know, the thing about these tools, there's lots of tools that help you, right?
So there's lots of tools depending on what you like to do, what you like to use.
But one of the things that we know with using tools, they all have limitations, right?
So TCP dump, it's great.
You can collect packets.
You can use it for splitting, merging packets, filtering packets.
But in some cases, it lacks that ability to do layer sub analysis or it has a lot of vulnerabilities in it.
Wireshark, probably everyone here probably uses it or is familiar with it.
I know I use it all the time myself.
And it's a common tool for doing packet analysis.
And while it can separate out the individual conversations, it can't dissect the packet for you or identify changes between the packet.
And sometimes it doesn't have the ability to show you the state machine.
And IDAPRO, while not really a packet analysis tool, but if someone wants to look at a binary, look at code and look at API calls to understand communications, you can use IDAPRO for that.
It provides a good picture of how the code is implementing a protocol.
But then again, the limitation there is going to be in your understanding and use.
So if you're not familiar with it and you don't know what you're looking at, again, that could be a limitation.
So motivation.
All right.
So we know that there's a process, right?
We know that there's tools to help.
So what's going to be our motivation to try to learn how to break down these protocols?
So the one idea is maybe you're a pen tester, right?
So maybe your job is to do packet network analysis at your job.
You want to be able to know what's coming in your network and leaving out of your network.
You may have the packet capture, so you're using Wireshark.
But if you don't understand the protocols, answering customer questions becomes a lot harder, right?
And you can use Wireshark for common protocols, but what happens if it's an unknown protocol?
It's something Wireshark hasn't seen before.
It's going to barf.
It's going to die.
So what do you do then?
So that's your oh, shit moment, right?
So if you can reverse the protocols, if you can show what data is being there and kind of the system workflows, that's a better answer for your customer, right?
Here's the data.
I know exactly what's coming in and out of your network.
Another reason is maybe you set up a home network, right?
So you've got a lot of gadgets on your home network, and you want to be able to see what's going in and out of your home network.
That might be another motivation.
Another motivation might just be curiosity, right?
You just kind of want to learn these things for yourself to just start getting used to it, see what you can do.
And again, because the machines take over, you want to be able to listen in.
So how hard can it be?
Well, it depends on how you approach it, right?
So people design protocols, and people are predictable.
So most people are going to follow a certain logic in how they structure a packet, how they set up the protocol, the state machine.
And as we said before, network communications are really like a set of rules that get implemented.
Well, what if those predictable people don't follow these rules?
So there's a lot of variance and options that leaves us with an unknown protocol.
Picking out a checksum field is something that we statistically do, but trying to figure out how the checksums calculate it can be a tedious process.
And the same thing will happen with bit fields can become meaningless.
And they remain in the protocol because a lot of times developers aren't sure if they should remove them or redefine them safely.
So sometimes that can just be a little bit harder.
Why bother?
This is what I ask all the time, Tim.
So one of the reasons why is why would you bother to do this, right?
So in some cases, it could be because you want to be on the side of understanding what's going on in your network.
In other cases, you don't want to be on the receiving end.
That's when I noticed something strange.
That's when I decided to hack you.
I know you run a website called Plato's Voids.
Pardon me?
You're using Tor networking to keep the servers anonymous.
You made it really hard for anyone to see it.
But I saw it.
The uninverting protocol, it's not as anonymous as you think it is.
Whoever's in control of the exit nodes is also in control of the traffic.
Which makes me...
the one in control.
I must ask you to kindly leave.
I own everything.
All your emails, all your files, all your pics.
All your pics, right.
So, um...
Can you stand real close to the mic?
Sorry.
I tend to pace. Sorry.
All right, and I apologize if the font's small.
We'll fix that on the next talk that we do.
So what does DEF CON think of network protocol reverse engineering?
Two years ago, there were a couple of talks.
Jesus Molina, Jeff McDonald,
Dustin Hoffman, and Thomas Kinsey.
And they all presented talks on specific protocols,
but they didn't really step through the process,
a generalized process for how they derived information.
And in fact, Jeff McDonald said,
why bother spending time understanding the protocol just to break it?
And he was introducing a fuzzing tool.
And then last year, they also had a...
another talk by Peter Shipley and Ryan Guler,
who presented a talk on Insteon.
And they asserted that the published protocol documentation
was incorrect and deceptive.
And they obviously reverse engineered it, found out it really worked,
and then they used that to exploit it.
So it's a good example of why you would want to learn protocol reverse engineering.
The publisher said, or the vendor said,
here's how the protocol's supposed to work.
They reverse engineered it and found out that wasn't in fact the case.
And then what do academics think of NPRE?
So this really started in about 2000.
There were a lot of academic papers up through 2010.
You can look at the conference CD.
We have our literature survey on there.
You can go read it.
I'm not going to bore you with that.
But basically, there was a lot of progress where they first of all said,
no, it'll never work.
You can never do this.
It's too hard.
And then they gradually figured it out.
And by 2010, there was a lot of demonstrated approaches
that were successful for both the generalized and the specific cases.
But we're not going to talk about classification algorithms
and how all that works.
We're going to try and give you some steps that you can use
on your own with your own tools at home.
So we're going to make some assumptions here to make it simple.
We're going to assume that you're going to start with some frame network protocol data.
Your PCAPs may not have the start and the full session.
You may have part of the middle or the ending or the beginning.
But it's going to be framed already for you.
Starting without frame data like we're doing RF
or if you're trying to do something off of an embedded systems bus,
that becomes a whole other challenge and a problem that we're not going to go into.
We also assume that cryptography works.
So we're not going to talk about how you break encryption keys.
We're just going to assume that that works.
And there's still value in doing protocol reverse engineering
even if you don't have the keys and can't reverse it
because you can understand.
You can start to see where the sessions are
and how the keying sessions are instantiated
and where you may want to try and introduce some faults in the network.
We also assume legal authority.
So public service announcement again.
That wasn't planned in advance.
Good timing though.
We're not lawyers.
But don't be evil.
Don't try this at Starbucks.
We're here at Caesars.
Try this at home.
Don't go to jail.
If you do, don't come for us.
So here's our workflow.
It's a general workflow.
You collect the data.
You frame it.
You start to construct a state machine.
You start to look at the fields.
You test what you know.
And then you go back to the beginning and get the data again.
And we're going to step through this starting with data collection.
So packet collection.
Step one is get some packets.
So how hard can that be?
Well, first you want to get some packets in a clean environment.
So if you start here at Caesars and just start sniffing traffic on the DEFCON wireless network,
you're going to get all sorts of noise.
And if you're trying to look at one particular protocol,
there's going to be a lot of data in there that you're going to have to sift through to find the packets of interest.
So start with a clean collection.
Set up your own environment.
Get a hub.
Those are harder and harder to find.
I checked today and there weren't any in the village.
I even asked for them.
They said no, they don't have any.
But try and find a hub if you can.
The other option is to do some research.
Some cable splicing.
That picture, fuzzy picture there is of a Cat5 cable that's clipped so that on one end it can't transmit.
You can also buy devices that will do this for you that do network taps.
Still step up close to the mic.
All right.
So we'll try that.
I'll try talking to the mic.
All right.
So.
So you can do cold boot and reboot.
So the first thing I like to do is set up my network, wait for everything to settle down so that I know all the packets that are coming across the network,
and then boot up the device of interest and watch those initial packets come out because you'll see some interesting things come out as soon as the device comes up.
It may beacon for other devices from the same vendor.
It may send out a time stamp.
It may broadcast its MAC address or something.
It's an IP address.
It may send things out that you can immediately start to identify some of the unique protocols.
And then go through the normal sequence of using whatever the device is and capture those packets.
But then go back and look for the rainy day captures.
Try and do it under congestion.
Try and do it when you introduce error conditions or a heavy load.
And try and force the device into those other cases, down those other code paths, so that all of the protocols will show up in your captures.
All right.
And also a good thing to look for is the management utilities.
A lot of devices have the vendors will go to them.
They'll give you a web interface or something that you can run on your Windows box that will go out and find all of their devices on your network.
See how it's broadcasting that out and see what those packets are.
Or if it has a web interface, use the web interface and capture those packets.
See if they're really encrypted.
See what kind of protocols they're using to communicate to the device.
Unfortunately, sometimes you don't have those choices, especially if you're on a pen testing gig.
You're just going to collect traffic.
It's going to be noisy.
And you're going to get stuck trying to filter this all out.
Try and capture that in small PCAP files.
Don't make your job easy.
It's going to be harder than it needs to be.
So understand your environment.
Keep it simple.
And collect small PCAPs so that you have smaller sets of data to start analyzing.
Then you move on to framing.
We assume that you're going to have framed data.
So this doesn't really necessarily apply for doing this off your home network.
It's going to be fairly well framed for you.
But what you want to, in other environments, you need to look at where the packet starts and stops.
So you know where the data you're interested in and what of that you can avoid.
But we're going to assume that you're starting with IPv4.
If you're really elite, then IPv6 on your home network.
Okay, so then what is a state machine?
We've mentioned that a couple times.
A state machine is really just how you, it helps you diagram how you observe the protocol acting.
So I've given an example here.
This is at the end of a TCP IP connection, the three-way handshake as it shuts down.
Should be familiar to most people here.
That's what I mean by a state machine.
It's not really complex.
Start with that and just start understanding how the protocol interacts with each of the pieces of the protocol interact with each other and with other devices on the network.
So here's an example for a Fitbit.
This is a, there's a, obviously you can't read that, but it's in your literature survey on the CD as well as in the slides for the talk.
And the slides for the talk for those of you that didn't get the packet.
It will be available on the DEF CON media server about two months after, after DEF CON.
So you can pull it down from there.
These researchers carefully diagrammed out the whole exchange here.
The point, important point is not to try and read all those teeny lines, but you can see that they, they have the state machine that they derived.
And then they broke it down logically into four different phases to characterize how the Fitbit device was connecting to the base station.
And then to the Fitbit device.
And then to the server back at the mother ship.
And that's what you want to do.
Start to put together how this all works.
This is an iterative process.
The first time through you're not going to get it all.
Get what you can.
Move on.
Fast iterations.
The next step is the fields.
So this is where it really gets fun.
This is the part that I enjoy.
So you're going to be looking at the fields of the packet itself.
And there are lots of different ways or lots of different types of fields.
We've kind of broken it down here in a logical, to me, logical approach for how I would approach it.
Find your own.
Build your own process.
But let's start stepping through these real quick.
So string fields.
Somebody mentioned Wireshark.
Anything about Wireshark is over in that right hand column provides ASCII output of the packet itself.
Which may or may not be readable to you.
So that's really easy.
You capture some packets.
Open it up in Wireshark.
Find those packets.
Look at it.
You can immediately see.
Lots of XML like data.
Lots of strings you can look at.
And you can start to understand what that is.
This is from the ICS Village last year.
I was really hoping that they were going to be here this year.
Because that was a great opportunity to go down there and work with the industrial control system.
And play with it a little bit.
And capture the packets.
And then reverse engineer them and actually influence the device.
So.
XML is popular.
Becoming more so.
You'll see a lot of.
JSON now.
That's becoming more popular as well.
And then HTML.
They like to embed stuff in HTML.
And it just becomes really messy to look at.
But at least with strings it's easy to look at.
And you can start to piece it all together.
Alright.
Almost string fields.
What do I mean by that?
Well.
Binary coded decimal is something that's really strange.
You may have seen this in this geek clock.
You may have one on your desk at work.
Basically.
You read the binary value.
Like a clock.
You're not reading hexadecimal.
And you're interpreting the bits.
You're just basically using hex.
But ignoring A through F.
Right.
So this was so common at one point.
That embedded system libraries would include math functions for BCD.
So you would have your embedded real time operating system library.
And they would give you built in math functions.
For doing add, subtract, multiply.
And binary coded decimal.
Why were they doing this?
Well when you're reverse engineering a protocol.
It's a lot easier to look at a hex dump.
And read decimal.
Than it is to look at a hex dump.
And read hexadecimal.
And then do the math in your head.
So you'll sometimes see IP before addresses.
You'll see serial numbers.
You'll see dates.
You'll see license numbers.
Or whatever in the protocols.
Or in the device that you're looking at.
Encoded in BCD.
So history becomes an interesting lesson.
In forensics.
And speaking of history.
What do they do when they have old devices.
That they want to bring to the internet age.
Going back to the ICS Village last year.
It was a Modbus protocol.
That the device was using.
Modbus was developed in 79.
The internet was developed in 83.
When the internet came along.
They didn't reinvent Modbus using the internet.
They just kind of took Modbus.
And shoved it into IPv4.
So if you look at it.
It looks kind of strange.
But they've just basically taken.
An existing legacy protocol.
And wrapped it lightly in IPv4.
And there you go.
It's internet ready now.
And then at the very bottom of that.
You'll see that the last two bytes.
I can't really read it.
It's 000A.
And that would be a lot easier to read.
And read the size in decimal.
It was already encoded in decimal.
Instead of in hex.
So bit fields and checksums.
This is where it starts to get a little more complicated.
There are a lot of fixed field values.
In IPv4 headers.
Checksums show up as.
These random strings of bytes.
That are in the protocol.
That you see over and over again.
And you gradually begin to recognize.
That those couple of bytes.
Are always looking very random.
You can do some software.
That will give you the entropy measurement of that.
And see that it is constantly.
A very random series of bytes.
Typically they'll be a fixed size.
So 8, 16, 32 bits.
Something like that.
And you'll be able to start identifying.
Where in the protocol.
You've got these checksums.
Whether at the beginning or at the end.
Or only on certain types of packets.
That are coming and going.
So looking at those.
That's a whole other topic.
That's a whole other science.
Of how do you start looking at.
The checksums in a protocol.
And reverse engineering.
What algorithms did they use.
Developers are lazy.
They're going to use existing code if they can.
So it's not impossible to figure this out.
There are also some really strange ones.
So the best strange example.
I can give you.
That you should already be familiar with.
Is the IPv4 checksum.
The way it works.
Is you take a couple of fields out of the IP header.
Create a pseudo header.
You mash them all together.
Then you attach that to the TCP header.
You zero out the checksum field.
And start engineering that.
That would be a really big challenge.
Because who would ever think.
You'd take the header that's there.
And only a couple of fields come out of that.
And you string them together in a different way.
And do the checksum over that.
So it can get complicated.
But there again.
We have the example from IPv4.
That's something that all of us are familiar with.
So just reach back into what you know about other protocols.
And try and leverage that.
And then command values.
Those are really just bit fields with a purpose.
Typically some indicator in the packet.
Or in the protocol itself.
That says what kind of packet this is.
Whether this is a hello world packet.
Or some sort of heartbeat message.
Or a status message coming back.
Or an error message going out.
So you can look at these command values.
Try and capture all the different types of code paths.
That you can exercise in the device.
Collect those pcaps.
And see if you can build up your own dictionary.
Of all the command values that you can see.
You're not always going to see.
A nice sequence.
Often times there is a clear sequence.
You can see the command value.
One, two, three, four, five, seven.
Obviously I missed a couple in there.
Let's see if we can force those to come out.
But other times they'll look pretty random.
And that could be because they're doing something with a hamming distance.
So a hamming distance is where they deliberately only use the bit patterns.
Such that.
Any single bit flip won't be interpreted incorrectly.
As a different kind of command value.
So it's not necessarily going to be a strict sequence.
Don't spend too much time on that.
I'm trying to force the device into an error state.
That will fill in the blanks.
And then finally the all others.
So understanding what state the device is in.
When that packet leaves the device.
Is really important for understanding.
What possible content that packet will have.
And therefore what you're looking for.
And what to try and reverse engineer.
So for example.
The Fitbit protocol.
That the previous slide had.
It's rated up here.
Does base 64 encoding.
Looking at that.
It may look kind of random.
But after some time and analysis.
If you figure out it's base 64 encoding.
It becomes pretty easy.
And they didn't encrypt it.
Which is what made the research possible.
And they were able to come up with the attack.
Against the Fitbit device because of that.
So.
Knowing the state.
And figuring out what it's doing.
And then looking at the packets.
What's in them.
All right.
So you've gone through your first pass.
And then you try and test.
This is where you test your assumptions.
To see whether or not you can convince the device.
That you're legitimate.
So maybe you're trying to convince the server.
That you're a legitimate endpoint.
Maybe you're trying to convince the endpoint.
That you're a server or a peer.
But try and exercise it.
Send out your own packets.
See if you can get the response back.
See how far down into the handshaking process.
Or whatever the exchange is.
With that device.
So that you can start to spoof it.
And take over the sessions.
And become one of the endpoints.
So a good tool for this is Python.
A lot of you are probably familiar with Scappy.
I don't know if anybody shouted out Scappy.
When we were asking.
There was one.
Somebody's using Scappy.
And Python.
If the ICS Village was here.
The approach that you took there.
Was to collect the packets.
See which packet had the command.
Going into the ICS device.
That would tell it to enable the switch.
You could flip that.
And then using Scappy.
Rebuild.
Reconstruct the packet.
And send it out.
And it would be accepted by the device.
Because in a Modbus protocol environment.
There typically is no authentication.
There is no SSL.
It's added on in front of that.
So once you're on the device.
And then you iterate.
You wash.
You rinse.
You repeat.
This can go on forever.
So you really have to decide up front.
When you're done.
What level of reverse engineering is appropriate.
For your project.
For whatever your goals are.
If you're on a pen test gig.
And you just want to prove to your client.
That whatever proprietary protocol they came up with.
Their developers implemented.
An API across their own network.
That's maybe not going to take a lot of reverse engineering.
On the other hand.
If you're trying to control the device.
So that you can remotely connect into it.
And change the behavior.
Or change the state of the device.
That may require more reverse engineering.
If you're trying to completely control it.
So that from start to finish.
The device will show up on your network.
Think it's talking to a legitimate server.
When it's talking to you.
It gets more and more complex.
So figure out up front.
How far you need to go.
Understanding that you're never going to really.
Reverse at all.
Unless you can pull the firmware.
And get the code.
And do a lot more work on that.
But even with a little bit of work.
You can really start to influence devices.
And change the behavior.
Alright.
So how about some tips.
From our own experience.
Of what works and what doesn't.
Nothing works.
So one of the key things.
We probably wanted to point out.
Is maybe find the reset switch.
Right.
Protocols often contain a reset process.
Or a re-sync.
And these can be like.
Basically injected during your research.
To capture communications.
So sometimes you might want to look for that initially.
That's like one tip.
And if you can't find the software or protocol.
To reset the cycle bar.
You just kind of maybe.
I think it was.
So always look for like a reset.
Or a re-sync.
Because normally it's always there.
Another thing Tim likes to always talk about.
Is legacy mode.
And the client.
A lot of times.
You have different protocol versions.
So you may be able to force.
The software to use a different version.
Or a legacy version.
Just in case.
So sometimes you can find an older version.
Might be there.
And you might be able to force that.
So if it's a new one.
Or a firmware update.
You might be.
You have to know what you're looking for.
I will say that.
But maybe just initially.
Just think about that.
So look for legacy modes.
Or look for like a legacy version.
That could be coming across.
Another good thing to try up front.
Is replay.
So it's easy.
Once you've captured a couple packets.
Just try and send them right back to the device.
Replay those packets back.
If the device is designed well.
It's going to have some check in there.
To make sure that it's not getting replayed packets.
But surprisingly enough.
Not all devices do that.
So start with the simple things.
And see if it works.
It might also be a way to reset it.
Back to a known state.
So that you can easily automate your discovery.
Ongoing discovery.
And then there's fuzzing.
A lot of tools out there.
That will generate packets for you.
Onto a network.
A lot of challenges with that.
Because you may send 16 packets.
And the device resets.
And you don't know which of those 16.
Actually started the process.
That resulted in a device reset.
So sometimes you've got to do some repetition.
Some guessing.
And eventually build up.
What fuzzed packet actually influenced the device.
And then observe where your injected packets.
Are getting caught.
And then convince the device.
That you're a legitimate server.
Or a legitimate endpoint.
How far are you getting.
Before all of a sudden the device behaves differently.
So you're impairing the captures.
The known good sequence of events.
With your attempt.
To see how far down that iteration you're getting.
And then adjusting your approach.
As you narrow down.
Where you're falling apart.
And another thing is.
Devices like to be discovered.
So you turn on a device.
Most likely it's going to say hello.
To somebody.
Somewhere.
A lot of these companies put in some type of way.
To pull for status.
Or pull for updates.
Even to send firmware updates.
You guys saw the incident with the drone.
Near the White House.
And then they sent a firmware update.
There's always something in some type of machine.
Or device.
To say here I am.
Or this is where I'm at.
Or some kind of status.
Everyone has maybe a smart fridge.
Who knows.
It might be reporting status to someone.
Saying hey I'm still working.
Or I'm still moving.
So always look for that.
There's probably going to be a packet.
And after a while you can look at it.
It'll be repeatable.
I mean you'll be able to see a signature in there.
That's the call home.
Or that's the I'm still working.
Or that's the I just died packet.
Or something like that.
So devices are always talking.
Another thing is.
Tools are your friend.
I have a million tools for a lot of different things.
So use them.
But don't force a tool in situations where it doesn't work.
You have to find out what works for you.
Like earlier when we were mentioning tools.
We had at least seven different examples of packet capture tools.
Sometimes I use Wireshark.
Sometimes I use Scappy.
Sometimes I use TCP dump.
It depends on the situation that I'm in.
Or what I'm trying to do.
I use IDA a lot.
Don't force anything.
So just remember that there's tons of tools.
There's tons of things that you can use.
And I encourage you to try them all.
Because sometimes one situation the tool might be your best friend.
And in another situation it might be your worst nightmare.
Earlier I talked about the academic research.
And how that had improved and put into practice.
A tool out there actually wraps this all up nicely for you.
It's called NetZob.
I've got the website up there.
If you can't read it, it's netzob.org.
So it's N-E-T-Z-O-B dot org.
It's available for Linux and Windows.
I got in touch with the developers.
Unfortunately they didn't think they were going to have any of their staff here at this con.
But they have been here in the past.
And they're always looking for people to help them out.
So take a look at it.
See if you can help them improve it.
It kind of wraps it all up into an easy to use tool for you.
Alright, so the important thing is as you go through this process
we're going to hit some dead ends.
Don't panic.
What you want to do is avoid the death march syndrome
where you're just slogging away knowing that you're not going to succeed
and you're doing it anyway because you're punching the clock
and you're supposed to do this job.
Avoid that scenario.
Try and stay creative.
When you get stuck, try and talk to others.
Come to conferences like DEF CON.
Look at the other people out there who have reverse engineered protocols.
Read up on those.
Look at the legacy protocols.
There's lots of resources out there to help you if you get stuck.
Don't just put your head down and slog on.
And don't give up.
So there's a lot of projects out there that have succeeded
on some pretty amazing protocols that are hard to reverse engineer.
It's not impossible.
And as the machines come along and they start developing their own protocols
it's going to be an interesting challenge
but I'm not sure that they're going to be able to come up with something
that we can't reverse engineer anyway.
So just keep at it.
And then there's also the whole approach of
treating it like a game.
I don't know if any of you are familiar with
Super Better, which is a book
by Jane McGonigal.
She has a good TED talk
on this as well.
It's all about how to approach challenges
from a gaming mindset.
And for those of you who play games
you know that you've got these phases
when you first get the game
where you're trying to figure things out
and nothing seems to be working
and then things start to click
and you start to figure out
what the techniques are that are effective
against the different levels
and how to beat the bosses.
So keep the gaming mindset.
Celebrate the small victories, the small wins.
Keep yourself motivated.
And this is pretty much just a wrap up.
I know it's kind of small
but basically what we covered.
So we covered what is protocol reverse engineering
why you should care
or maybe you don't, I don't know.
We gave you a process, at least Tim
kind of went down a process for
network protocol reverse engineering
some things to look for, some fields to check for
and then we kind of walked through
collect the data, get some packets
frame it, so figure out
where the data is
understand the session, so the state machine
look for some fields
test, try it out
and kind of the rinse, repeat.
Basically you've just got to keep trying
that initial one
you'll firstly do it, but once you get your own process
and it might not be this process
but once you get your own process
it's repeatable, it's a lot better.
And then we gave you some tips and tools
I'm sure there's tons more
if anyone has any suggestions feel free
there are more shirts
but other than that, I think that's it.
Alright, so we have time for a few questions.