Download the challenge file from here.
Given a pcap file and we were asked to submit the hash of the encrypted file after reconstructing it. The challenge title will help you to get started. First I tried to learn the differences between netcat and cryptcat tools. Netcat is an opensource application which can read and write files to the network. Netcat can also be used to create backdoors ;). But netcat doesn’t encrypt the data during transit. If we can sniff the packets we can get the transferred files in clear text. The only disadvantage of using netcat. In order to fill the gap, Hobbit came up with a slightly modified version of nc called as Crypcat. It essentially scrambles the conversation using the Twofish encryption method. Twofish is an symmetric key encryption algorithm which takes a secret key as an argument to encrypt as well as to decrypt the conversation. Now, all the files/conversations which are transferred will be encrypted using the Twofish+shared secret key. Only those who know the secret key can alone will be able to see the message after decryption.
Our goal is to find the binary file which is encrypted and transferred using cryptcat. One more thing you have to understand here is, Cryptcat doesn’t use a SSL protocol to transfer files. They encrypt the data with the Twofish algorithm and resulting data will be sent across the network either using TCP or UDP protocol. So here is another question, “How are we going to categorize the encrypted data and normal data from the TCP stream. Here is some of my thoughts,
1 .Crypcat files are transferred between machines. Since it is a CTF contest, most likely between 2 machines having private address.
2. Since cryptcat and netcat uses TCP/UDP protocol, you can ignore the rest (like SSDP, SSL etc) from the pcap file.
3. You don’t need the Microsoft update files (.psf), which can be seen in the beginning – Microsoft doesn’t use Cryptcat to do them
4. You don’t have look into SSDP protocol, which relies on UDP. The protocol just advertises the broadcast packets and to discover devices. Our purpose is different here.
When you ignore the aforementioned protocols only TCP will left out. So apply the filter “tcp” in wireshark to find out the IP addresses of the machines which used cryptcat to transfer files. The IP addresses are 192.168.1.20 and 192.168.1.21. Use this filter “ip.src==192.168.1.20 and ip.dst==192.168.1.21” to get the complete conversation. As I said earlier in-order to encrypt the conversation we use cryptcat with a shared secret key. When you go through the packets, you can see that initially the conversation has happened using netcat, which will not encrypt the conversation.
You can find the secret key in those packets, which will be used to encrypt the rest of the conversations. As per the conversation shown here, herp requested derp to communicate securely using cryptcat and the secret key (Dagaga).
Also herp has sent the actual cryptcat application ( in DOS) for derp to communicate . You can find the executable in packet number 7036.
You need to extract the executable first. Because you are going to use the same executable to decrypt the encrypted conversation. Herp once again notifies derp that he has sent the executable and the secret key. You can see the message in the packets from 7091 to 7291. Packets from 7301 to 7980 are encrypted using the secret key. If you look at the packet 7692’s size, you will understand that a file has been transferred. The question here would be “How are we going to decrypt the encrypted binary file?”. I tried resending the entire pcap file with the secret key to decrypt the encrypted streams. You can do like this in your machine,
$ cryptcat -l -k Dagaga -p 7070 < pcaponly.pcap -> Machine 1
$ cryptcat -k Dagaga 10.30.10.186 7070 > file.pcap -> Machine 2
Obviously I got the same contest file again since we are encrypting the encrypted packets again. Then I thought to reconstruct the encrypted file alone (found in packet no 7692) and decrypt it using an online tool. It didn’t click anyway. Before using that you have to pull it out of the stream.
As expected the file type is a raw data, since the binary file’s header should also got encrypted.
➜ 100  file binary1.dat
Then I used openssl to decrypt it, failed again. Well I ran out of options and was thinking for a solution. We need a mechanism which can decrypt a file, while it is in transit. I remembered my early days where I used to copy small files using netcat. This has really helped me to solve this problem. Usually I use netcat like this to copy a file from one machine to another,
$ nc -l portno < filename.extension --> server end
$ cat filename.extension | nc client_ip port_no --> client end
This is how it works, while transferring a file from server we will concatenate each and every bit of the same file at the other end. Similarly I used netcat to send the encrypted file from my linux machine and on the other side I used cryptcat( found from the pcap file) to decrypt the file by specifying the secret key.
final.exe and binary1.dat are the reconstructed cryptcat application and encrypted file respectively. 10.30.10.186 is my Windows machine’s IP address. Once when the file is transferred, check the whether file type is still the raw data or changed to something else!
➜ 100  file named.dat
named.dat: PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows
Yes!!!! 😀 it did change! So the encrypted file is actually a windows binary! Now calculate the md5sum to get the flag,
➜ 100  md5sum named.dat
This is how I solved the challenge. The flag is 32170cab0f59ce6e1fc8df51a757cc99
Let me know if there are any alternate method to solve it! 🙂