One of the most time consuming tasks for me personally is setting up an environment for me to start reversing and writing exploits, I played a CTF recently and had to set up a new box in order for me to start playing around with binaries, so I thought it might be nice to document the process of how I like to configure my environment and dive into some of these binaries, maybe someone else might also find this useful.
Okay so I had a 64 bit Debian 7 system running in a VM, one of the first things I do is run file on the binary:
as you can see we’re looking at a 32-Bit ELF binary, running on an intel x86 chipset, dynamically linked and not stipped, meaning that we have symbols for the linked libaries and function names, as well as other debug information, this is helpful for when we want to get a general overview of the binary, we can also run strings to provide further information. All sounds good, where do we go from here? Well, it would help to run this binary so we can set this up locally, the usual layout for these types of CTF challenges is a service that runs on a remote box, you’ll then be given the address and port to connect on and start intereracting with, you’ll also be given a copy of the service thats running, the idea is to find a bug in the service and exploit it to gain access to the system in order to read the flag.
You’re probably wondering how to run this service then? Okay so first I will try to see what libraries this binary depends on in order for it to run, to do this I’ll use the ldd command, you can see the output of what this looks like below:
these are the libraries that are needed for us to run this file, most of the time these are already on our system, however sometimes you will need to provide these files, whilst I was reversing a service on ESXi, I needed to add the dependancies before the service would run. Now we just need to change the file permissions of the binary so that its executable, to do this just run chmod +x.
Once this is all done we can start to emulate the CTF challenge locally, meaning we need to run the binary as a service on our system, we’ll use the tool socat, you can install socat like this apt-get install socat. We’ll now pass socat our binary and have socat run this on localhost TCP port 4000:
Here we can see that socat is set up listening and waiting for connections, just like the CTF setup, shown below is an output of netstat and this service listening just to see what it looks like:
We can now connect to this service just like we would do remotely for the CTF challenge, we can achieve this by using netcat, later on when we start writing an exploit we write the socket connections ourselves.
as you can see we are now connecting to this service, allowing us to interact with it as we would for the challenge, however now we are running this locally, giving us the ability to perfrom satic analysis and most importantly dynamic analysis of the binary as well as other techniques. This is the first step in creating our environment and performing analysis.
Lets now try and see how much information we can gather about the binary before we start performing dynamic analysis, as I previously mentioned earler, we can use strings to see if theres any clues in the ASCII text within the binary, to run this type strings [binary], lets see what we can find:
Cool so we notice some functions that the binary is using, its always useful to see these as we can check if theres any vulnerable functions present, theres also other ways of seeing this which we’ll look at soon, challenges can also leave credentials, paths to flags and other helpful hints here too.
to get more of a static view and map out the binary we can use a tool called objdump, this will give us lots of information such as functions, sections, headers, assembly code and the memory addresses which their mapped to, as theres a lot of output I’ll briefly show parts of information that we could find useful, first off we’ll look at all the headers, type objdump -x [binary]:
We can start to get an idea of the memory structure for this binary, we can see the starting address and other different areas that could be of interest, if you look next to the flags we can see the permissions of these memory locations, this becomes important when we come to exploitation, due to mitigations that the binary can be compiled with, we’ll look into this later on. For now though we can start gathering more information, we can also look at specifics sections of the binary that could be useful such as the memory address of the GOT which we can use later for re-directing execution by overwriting entries.
We mentioned previously about mitigations how can we check for this?, well an amazing tool was written by Tobias Klein which allows us to look at what memory protections have been compiled with the given binary and dependancies:
Above shows various protections that we will need to bypass later on in the exploit development stage, the previous exmaples of objdump will come in handy with this too.
So far we have looked at tools to help us gain some idea about the memory layout of the binary, the protections its compiled with, as well as a way to interact with it. In the next sections we’ll start to look at the binary in more depth.
Its always useful to see if we can trace any of the system calls that the binary is calling and interact with it, theres a nice tool that we can use to do this called strace.
if we’re lucky, the binary isn’t checking for a call to ptrace which is what strace uses to work, if so then the binary will kill itself, this is a common anti-debug trick. As we can see, we’re able to run ptrace and see what signals and sys calls are being made.
Moving forward we can now look at the depths of the binary and how it works, lets fire up IDA, you can either get a paid version which is expensive, or the free version with limited features, you can also get the trial version of the latest version, however again its limited and you can’t save the database which is pretty useful, a cheaper alternative is Hopper. I’m not going to go into IDA in detail as that would require numerous blog posts, I’m just going to show how to get it running with a few plugins, such as Qira.
I mentioned earlier in the post about dynamic analysis and how because of the way in which we set things up previously we would be able to achieve this, we’ll start up GDB and attach to our running service, a quick tip that I find userful when I’m running gdb, is this gdb –pid `pidof binary` this will then attach to whatever processid the binary is running as.
In the above example, we are setting a breakpoint on the first entry point for the binary and then letting gdb run until the breakpoint gets it. We can then flip over to netcat and start messing around with the service until we hit that software breakpoint we set in GDB
This is our input to the service, we can tell when we hit our breakpoint because we can’t interact with it anymore until the debugger has released it, lets go over to gdb and see what this looks like:
from this point we can now start to see what happens to our input and trace it. Theres lots of cool plugins for GDB that can help with the process of vulnerability analysis and exploitation, I’ll go through some of these at the end of the post.
We can see how all of these processes pieced together and how it can help us to examine the binary, we have socat running the binary as a service, netcat connecting to it, gdb running and IDA giving us a static view, where we can comment and trace our input. I’ve listed some other tools and plugins that I find useful below.
PEDA - A plugin for GDB that helps with the exploit dev process.
checksec.sh - This is integrated into PEDA, but you can google this tool, I spoke about this earlier in the post.
gdbinit - The init file for GDB, you can download this from https://github.com/gdbinit/Gdbinit
There are numerous others out there too that I will have missed here.
Hopefully this post has been helpful for people, just to clarify this is for binaries that can run on Linux systems, I might do a quick post for Windows systems as well. If any of what I’ve spoke about in this post has been incorrect please feel free to message me via twitter or if you have any questions!
Thanks for reading, peace (: