This semester I’m taking a Computer Security course. So far we’ve discussed OS security features, storage features, and buffer overflow attacks.  While listening to a lecture on return oriented programming I was reminded of this challenge. Though I was too busy to partake while it was happening, I was glad to see it is still available to complete. Below I catalog the challenges and how I approached them. Feel free to comment with any questions and I can try to clarify!

Task 1.1 - Information Gathering and Triage

A military organization captured a laptop of a known explosives expert within a terrorist organization.  Further analysis revealed that the laptop contained a debug version of the remote client interface that the individual used to communicate with the IEDs. To help detect other client programs in use, we are cataloging binary signatures and basic network signatures for every version of the IED software we find. To support these efforts, your task is to compute the SHA256 hash of the client binary and identify the source and destination TCP ports that it uses when connecting to an IED.

For this challenge we are given a binary called “client”.  The first request is rather simple - generate a SHA256 hash of the file. This simply required me to run the sha256sum program that comes by default on most linux distros.  After completing this, my next thought was to simply run it in my Kali Linux vm to see what happens.   Hmm, that was interesting. Obviously the file exists because we can see its a 32-bit executable.  It must just have been written to mess with the user and main returns 127.  

Next, I threw it into Hopper on my mac to disassemble the file.  Taking a look at the call tree I can see that it branches out the most on the right, so that must be where the real execution takes place.


I followed the tree down to the right and was able to find the place where the program communicates via stdout that it will be attempting a connection and specifies the ports.  From there I simply needed to convert the two hex values pushed onto the stack before the format string.  

Final answers for this stage:

SHA256: ec4c4d4e60fdae486865171fd44a4142792d18dab6221ed9ce041811ef49e4
Source Port: 12666
Destination Port: 8080

Task 1.2 - Information Gathering and Triage

Great work! Based on the signatures you provided, we were able to collect network communications that we believe contains traffic to an IED that is about to be detonated. Unfortunately, there appears to be a lot of unrelated network traffic in the collected data since other programs use the same port. Using the provided packet capture file (PCAP), we need your help to create more specific signatures for identifying network communications with the IED. This would be a huge first step in detecting when an IED has been armed, for example, which would allow us to alert troops in the region around where the signal was collected. For this task, your goals are to identify the version string sent by the client software when initiating a connection to the IED and to determine the IP address of the undetonated IED from the packet capture.
UPDATE: Intelligence suggests that the version strings are 11 characters long and look something like x.x-xxxxxxx

Ahh, the next step requires some network traffic analysis. Thankfully I already had wireshark installed on my mac (and they finally updated it this summer to stop using X11 windowing) so I was able to open the pcap right away.  My time this past summer as a security engineer intern prepared me well. I was trained in wireshark and spent a great deal of time analyzing customer traffic to determine if there were any suspicious anomalies.  The challenge here can really be summed up by the question: Do you know how to use wireshark (and regex)?  If you don’t already know how to use it, prepare yourself.  Its a wonderfully powerful tool which is great. But its also a powerful tool with TONS of options and can have a steep learning curve at first.  If you’d like to learn more, howtogeek has a solid tutorial ( to get you up to speed.

So, how did I solve this one?  Given that the pcap has 138 different endpoints and is 3.8 MB total it was unreasonable to sift through by hand.  Thankfully, the update provides all of the direction we need. I spent a bit dusting off the regex cobwebs in my brain and built a functioning expression that matched!

Now that I had the expression, I tried filtering off of it. This filter still left me with 279 packets to sift through - not bad, but still quite time consuming.  I took another look at the pseudo code provided by hopper and noticed that it didn’t seem to be calling any libraries for HTTP or implementing any HTTP protocols so I appended a “not http” filter and voila! I was left with a ton of reassembled PDU’s and a single tcp session.  Upon inspection of the tcp session stream (it was stream 52) I was able to grab the version number and the destination IP and submit them.

Final Wireshark Filter and Answer:

frame matches "[a-zA-Z0-9]\.[a-zA-Z0-9][-][a-zA-Z0-9]{7}" && not http
Destination IP:
Version Number: 3.6-dev8925