CSAW CTF 2014 Networking 100 Bigdata writeup


This is almost as easy as forensics 200 question, but I spent long time going behind my guess which didn’t take me to the flag. This question was actually solved by one of my teammate. Initially there were some UDP and TLS traffic and at the end we can see some traffic related to bittorrent packets. I guessed the admins might have hidden the flag in a bittorrent file. Then, I spent more time to extract the bittorrent traffic with no luck.  Later when my friend told me that I was going in the wrong direction, I decided to list of out all the protocols inside the packet and to analyze based on specific protocols. This revealed me the presence telnet protocol where the flag was given in plain text! It was simple then!




File Transfer Protocol

As part of my networking lab assignment I am given a task to implement the FTP protocol using TCP libraries. And since it is  our first  assignment, the tasks were pretty simple and just to consider implementing  very few of the FTP commands: LIST,GET, and PUT.  FTP stands for File Transfer protocol and it is built on a client server architecture. It uses separate connections for Authentication and for file transfer. We actually use this protocol to transfer files either from client to server and vice versa. A typical FTP process works like this: Once if you want to transfer or download a file from a server, the client will make a TCP control connection to the server’s PORT 21 which will remain open during the transfer process. Since it is a control connection, here we will provide our user credentials for logging into the server. Once if the server validates your credentials and if it is True then the FTP server in response creates a data connection with the client from it’s PORT 20.  Data transfer happens with the help of limited commands LIST,GET, and PUT. LIST command is used to retrieve the contents from a directory, GET command is used to download a file from Server to Client and PUT command is used to store a file from Client machine to the Server machine.FTP even offers FTPS  for the secure transmission of files using SSL/FTP libraries. We can implement the protocol in different programming languages and there are FTP libraries available for them.

Initially I thought of doing it in C,  but I am not able to implement all the commands successfully. So I did the functionality of LIST command alone in C and the other commands such as GET and PUT using Python sockets.  I didn’t used any libraries while doing it in C, I just used the normal popen() function which stores the stdout in a buffer and sends it back to the requested client.

Code Explanation:

Please click here to check out my implementation (written in Python) in my repository. This implementation is not using any FTP libraries.

Client Side:

Libraries used : Python Sockets

Arguments : Command line arguments (IP address and PORT no)

First the client connects to the server using the IP address and PORT no of the server. It is done by binding the IP address and PORT no to a socket object -> “st”.  Variable ” io ” stores our user input (either  of LIST,PUT,GET). Based on the type of input, we get the corresponding output from the server. If the command is LST, then the variable “io” containing string (“LST”) is sent to the server. Server process the command and it writes the output in a buffer and sends it back to the client’s socket. Client receives the bits from the server and stores in the variable “data” and then prints the output.

Server Side:

Libraries : Python subprocess, socket

Arguments : CLA (IP address and PORT no)

Sub-process library is used as a part for rendering the LST command . Server binds a IP address and a PORT no to a socket and it will be waiting for the client to initiate the request. If the client makes the request, the server receives the data (in our example “LST” is the command received from the client) from client in variable “cmd”. Then it executes the command equivalent to LST (ls in Linux) and takes the console output in a variable using the subprocess library and stores the output  in a data buffer and sends it back to the requested client.

Reconstructing files from Wireshark Packets

             In this post, I am going to exemplify the reconstruction of a file using 2 well-known protocols, HTTP and FTP . Let me give a quick introduction about the two protocols. HTTP stands for Hyper Text Transfer Protocol, which is an application layer protocol designed within the framework of IP suite. It is designed for an effective communication between Client and Server. It uses TCP as it’s underlying protocol. As an example, if we give a request for an URL, from our web-browser, it goes as a Request message to the server. The server then processes and Responds back to the client with a HTML page.

FTP stands for File transfer protocol, which is used to transfer files from one host to other. It makes use of two separate connections (Control and Data connections) before transferring  files. It uses TCP as it’s underlying network. Most widely used applications are FileZilla (Windows,Linux, and Mac) and ftp (Linux).

       I will be using Wireshark tool for the demo. First will start with HTTP objects. Extracting HTTP objects, from the captured packet is too easy. Just open the packet in your Wireshark, then in the menu list, select File -> Export Objects -> HTTP. Then save the required or all the files in a Directory.


          Pretty simple right? Now will look at on how to extract the files which are transfered via FTP protocol. Actually, for past few months, when i was working with CTF packet challenges, i didn’t had any practical knowledge about carving the transferred files (via FTP protocol) from the captured packers. Indeed it is simple, if you are familiar with File Signatures. I read 2-3 blogs and I came up with some ideas, to strip the files, which are transfered via FTP protocol. Take a look at this snap shot,


          Firstly, the Client ( makes a request to the Server ( for transferring a file. After that, 4 to 5, request and response messages are transferred between the two machines. Take a close look at Packet No. 10967, the client makes a request to the server for getting a file named “flag.rar”. In the next packet, server tries to send the file to the requested machine. Finally packet no 11091 indicates the transfer of file named “flag.rar” to Ok now how to extract the RAR file from the packet? You can either, write a script to extract the bytes from the captured packet and then reconstruct the entire file or you can follow the steps given below.

Understanding the Transferred file :

          Here, our transferred file is a RAR file and we know that every file which is used in this computer world, is identified by it’s File Signatures. Just Google for RAR file’s header, you will get the file signature. RAR file’s hex signature is found to be ” 52 61 72 21 1A 07 00 “. Just use this pattern to locate the file. Press CTRL + F , select the “hex value”, and then enter the pattern.


There you go! The RAR file is found in packet no.10988. Now right click and select, Follow TCP stream. Then select Raw and  Save it with a name. Alright you are done with the extraction. Use file command in Linux to check, whether we have extracted the RAR file completely from the captured packet.

h1dd3ntru7h@f0r3n51c5:~/Desktop/VolgaCTF13/200$ file Flag.rar
Flag.rar: RAR archive data, v40,

Pingo! We got the right one! :D.

Session Reuse

Session Reuse

So far I have seen only about TCP Handshaking mechanism. When I went through my final year project, I came across a term “Session reuse” in an IEEE paper. And the mechanism is quite indispensable or inevitable while implementing SSL(Secure Socket Layer). Session reuse will improve the SSL’s performance . It is achieved basically in two ways, either by Session Identifiers or by Session Tickets.

Working :

To establish a connection between a client and server it exchanges 4 messages each with a time latency of 50 ms. So totally 200 ms are consumed before the transaction of the data. Indeed, TCP handshaking is also made. It also involves public key cryptography operations for sharing common secret messages. But this operation is costly by computation-wise. To overcome this we can omit 100ms of a complete round trip and we can avoid the costliest SSL handshake by making a client requesting a abbreviated handshake.


ssl-handshake-with-resumeSession Identifiers :

           When the server sends “Server Hello” it can include a Session Identifier. Client stores the identifier and sends the “Client Hello” message + the identifier. If the server finds the corresponding session in the cache, it will accept, sends back the same identifier and continues the abbreviated SSL handshake. Else it will issue a new Session identifier and switch to a full handshake.

Session Ticket :

             Ticket mechanism is a TLS extension. First the client will send a empty “Session Ticket” in the “Client Hello” message. Then the server will answer with an empty Session ticket extension in it’s “Server Hello” message. If one of them doesn’t support the extension it will start Session Identifier mechanism. In the last exchange of a full SSL handshake, the server can include a message named “New Session Ticket”, which will contain the entire transaction log I.e the cipher suite used and the master secret exchanged by Server and Client.