Home > CTF > ASIS CTF 2015 write-ups

ASIS CTF 2015 write-ups

Last weekend ASIS CTF took place and we (the Eindbazen team) spend some hours playing it. While we did not play the whole weekend we did solve some of the challenges. Since I enjoyed the challenges I worked on I decided to create these write-ups of them.




This challenge consisted of a file called keylead, which was a 64-bit Linux executable file (ELF):

When executed, the file showed us we needed to play a game:

This challenge is a pretty clear rip-off of the two Dice challenges I wrote for ebCTF (the Teaser BIN100 and ebCTF BIN100). Both can be found on my write up page here http://www.thice.nl/eindbazen-ebctf-write-ups/. The difference being that in ebCTF these challenges were for Windows 32-bit and Linux 32-bit. The file in this challenge was for Linux 64-bit.

Let’s look what the program has under the hood, to look at the assembly code of this program we run the objdump command:

After some research we find the following interesting compares and jumps:

We could adjust these jumps so the throws are always correct. The JNE instruction jumps when “ZF = 0” (info), we can adjust ZF in gdb by setting the eflags. Since we expect anti debug checks we can create a command script for gdb instead of typing the commands.

Before the check the eflags are:

When the check is correct the eflags are:

So, we will use this second value in our gdb command script:

When we execute this script the challenge shows us the flag:

An alternative solution is the gdb script which my teammate blasty wrote. This script changes the values of the throws, so every throw is indeed 3,1,3,3,7:

Flag: ASIS{1fc1089e328eaf737c882ca0b10fcfe6}


Best Photo

Best Photo

In this challenge we were only given a URL: http://bestphoto.asis-ctf.ir/index

When visiting this URL we see:


It seems we can upload files here, when we upload an image file the Metadata, including Exif data is shown:


The vulnerability in this challenge is SQL-injection via the file Exif data. To easily change the Exif data of an image file we can use exiftool. When we test a SQL-injection like this:

We get the following result after uploading the file:

The following tests will be parsed as correct SQL statements, and result in a 0:

The following tests will be parsed as correct SQL statements, and result in a 1:

So, we got successful SQL-injection, but it is in a very inconvenient place. It is quite some effort to exploit this by hand with each time creating new image files, so, I decided to create a proxy. The following quick and dirty Perl script will can be accessed on a local running web-server. The query string sent to the script will be used as the SQL-injection, which is put in the image file with exiftool and then uploaded to the website. The result is then printed on the local webpage.

We can access the script in the following way:

The above request results in a 1.

The above request results in an error.

Since we now have this convenient way of exploiting the SQL-injection we can now use sqlmap to speed this up:

Which will result in the following info retrieved from the database:

Flag: ASIS{908cd5cf7e6f337d232370ce7e0fd937}




This challenge consisted of a 7zip file which contained a PCAP file. The PCAP contained a couple of HTTP sessions which included multiple files being uploaded and downloaded. To export all these files we use the very convenient Export Objects function in Wireshark (File –> Export Objects –> HTTP).

Between all the other files we find seven ZIP files, which all are password protected. When we check the information of these ZIP files with zipinfo we see:

Archive VuwPO9eM seems to contain flag.txt, but it also contains another file, which seems to have a random file name and a file-size of 90.927 bytes. In archive EO4qqhn8 we also see a file of 90.927 bytes, together with a file of 202.671 bytes. That second file is the same size as a file in archive YupE1RB8, this goes on till we end up at archive xnCub4eW. In this archive we find a file with a different kind of file-name “317fc6d41e3d0f79f3e9c470cda48f52a7168c6f”, with file-size 2.731.504.

A short Google query on this file-name learns us that it is the SHA1 hash of a malware specimen, with of course the same file-size. We can download this malware specimen from the following website: http://malwaredb.malekal.com/index.php?hash=317fc6d41e3d0f79f3e9c470cda48f52a7168c6f.

The file downloads with the filename ‘c0d2dbb60f18f74c239cd17199e74979’, but we rename it to 317fc6d41e3d0f79f3e9c470cda48f52a7168c6f_plaintext.

Now that we have a file from the first archive we can use it to perform a plain-text attack on the ZIP archive. This attack can be done with PkCrack, but also with tools such as Elcomsoft and Passware. Since the last two are commercial software we will use PkCrack, which is a bit old and not all too friendly in usage, but it gets the job done.

For this attack to work we need to create an identical archive from the plain-text file we have, from the zipinfo information we could see “3.0 unx”, so probably a ZIP version for Linux with version 3. Random other ZIP file to show difference:

In this random ZIP you can see it used version 6.2 with a fat filesystem, so quite likely Windows.

Checking the ZIP version on our VM it seems to be ZIP 3 on Linux, so that seems to be the right version. We can create a ZIP file with the following command:

When checking the file with zipinfo it seems to be exactly what we need:

We now have all the files we need for PkCrack to work:

Commandline explained

This file is the plain-text version of the file we know is in the encrypted archive (the downloaded malware file).

This file is the encrypted file we extracted from the encrypted archive.

This file is a ZIP file with the plain-text downloaded malware file.

This file will be the output file with the decrypted ZIP archive.

This file is the encrypted ZIP archive file we want to decrypt.

It takes a couple of minutes for the ZIP file to be cracked, but then we got the decrypted files:

Now that we have the decrypted file of 1.793.362 bytes, we can use the same trick to crack file E0frzRAi, after which we will get the plain-text file for the next ZIP and so on.

The recovered encryption keys for the ZIP files are:

Interesting note: When you crack the ZIP archives with Passware it shows the encryption keys in reverse endianness and written as one key:

With the encryption keys we can now decrypt the archive file with the flag (or PkCrack already did this automatically):

Opening the decrypted ZIP now gives us the flag:


Flag: ASIS{b72be7f18502dde0c2ca373ee3c2b03e}

Broken Heart


In this challenge we got a 7zip file with a PCAP file in it. Looking at the PCAP in Wireshark we notice it contains multiple HTTP requests with partial downloads. For easy editing we can split out the PCAP with TCPFlow:

The files starting with “” seem to contain “Partial Content” replies:

These Partial Content replies all contain a specific range of bytes:

Sorting the files we know which parts we need of each TCPflow file:

The first part seems to be from 13 till 179538, so we are missing the first 13 bytes of the file. Looking at the beginning of this file part we notice (from experience) that it looks a lot like a PNG header (with the first part cut off):



If we look at a random normal PNG file header we can see the same HDR bytes, and the missing 13 bytes in front of it:


The bytes we need to add in front of the first part:

The next step is to combine all the data from the different parts, this is something you can script, or do by hand. I opted for the manual way, by searching for the end of the previous part in the next part it was quite easy to stitch them together. The resulting image was:

Flag: ASIS{8bffe21e084db147b32aa850bc65eb16}

  1. No comments yet.
  1. No trackbacks yet.