CTF Notes for Myself, a Noob: Forensics

1. Use exiftool to check the metadata of the file.

2. Notice that the License field appears to be a bit odd since it is a very long string of random seeming characters.

3. Given the type of characters used and the length of the string, we guess this is a base 64 encoded string. Therefore, we do

echo cGljb0NURnt0aGVfbTN0YWRhdGFfMXNfbW9kaWZpZWR9 | base64 -d

which returns the flag picoCTF{the_m3tadata_1s_modified}.

1. Use exiftool to check the metadata of the file. However, there doesn't appear to be any odd looking metadata fields.

2. The flag may be hidden inside the file itself instead. Use xxd garden.jpg. The flag picoCTF{more_than_m33ts_the_3y33dd2eEF5} can be seen spread out across the 4 lines at the end of the output.

1. Use exiftool to check the metadata of the file. However, there doesn't appear to be any odd looking metadata fields.

2. We check if the flag is hidden inside the file itself. Notice that this is an SVG file, which means that it is actually possible to open this using the cat command since SVG uses XML to describe images and XML is human readable. So instead of using xxd which would output extraneous hex codes as well, we use cat.

cat drawing.flag.svg

The problem is that cat returns output that does not have any code highlighting, which makes the output harder to read. Let us open the file with a text editor instead.

Notice that with the code highlights of vim, there appears to be a suspicious string of characters in the text portion of the SVG file. The flag picoCTF{3nh4nc3d_24374675} is actually in plain view stored using different tspan elements.

1. Download the compressed disk image into the /tmp directory of the PicoCTF webshell and unzip the file using the command gzip -d <filename>. This results in a file disk.img.

2. Run mmls disk.img. In the output, look in the Description column for the Linux partition and find the Length value for that partition.

3. Connect to the remote checker service following the instructions and type in the value found from the previous step to obtain the flag picoCTF{mm15_f7w!}.

1. Download the compressed disk image into the /tmp directory of the PicoCTF webshell and unzip the file.

2. Follow the hint in the problem description and use the srch_strings command from the Sleuthkit. The srch_strings command displays all printable strings in a file.

3. If we run srch_strings directly, you will see that a LOT of output gets spit out immediately. Do Control-C to stop the program since it is likely the flag is hidden somewhere in the output. Instead of going through all the output by ourselves, we smartly use the grep tool to let the computer do the job for us.

srch_strings dds1-alpine.flag.img | grep pico

This results in the flag picoCTF{f0r3ns1c4t0r_n30phyt3_ad5c96c0} ultimately being found.

1. Download the compressed disk image into the /tmp directory of the PicoCTF webshell and unzip the file.

2. From the problem description, we know we want to somehow get the contents of the file down-at-the-bottom.txt which is stored somewhere in the disk image. Therefore, we know we must use several of the Sleuthkit commands.

3. First use the mmls command to find the offset of the partition which is likely to store the file. This offset will be useful for later Sleuthkit commands.

4. Next, use the fls command to list all the filenames that exist in the disk. Note that by default, fls only lists the filenames of the root of the disk image. However, it is possible to list all filenames recursively using the -r option. With this command, we get a very long list of output, so let us use grep to actually find where the file is located.

5. Using grep, we may not be able to find the relative path of the file directly. However, notice that we get a number on the left side of the colon. This number is the inode number, and there is a Sleuthkit command which can actually show the contents of a file based on its inode, icat.

The commands that were run across steps 3-5 are shown below in their entirety:

mmls dds2-alpine.flag.img
fls -ro 2048 dds2-alpine.flag.img
fls -ro 2048 dds2-alpine.flag.img | grep down-at-the-bottom.txt
icat -o 2048 dds2-alpine.flag.img 18291

This results in the flag picoCTF{f0r3ns1c4t0r_n0v1c3_db59daa5}

1. Download the compressed disk image into the /tmp directory of the PicoCTF webshell and unzip the file.

2. Unlike previous questions, there are barely any hints as to where the flag may be except that it is somewhere in the disk image. However, not to worry! We will try to figure it out using the previous processes we followed. First, use mmls to determine the partitions that exist on the disk image.

One thing that is immediately notable is that there appears to be three Linux related partitions. Additionally, the first and third Linux related partitions appear to have the same descriptions! Let us check out the files stored on those partitions with the fls -ro command.

3. One thing we notice immediately is that the fls -ro output of the first Linux related partition is extremely short while the third Linux related partition's output is much longer. We also identify several other features of interest:

   
   • There appears to be a file entry at the very end of the first Linux related partition's filename output, which is named $OrphanFiles. What might this file be? Let us do some research. From this page on the Sleuthkit wiki, we see that Orphan Files are deleted files that still have file metatdata in the file system, but that cannot be accessed from the root directory. This is possible because in most file systems, the file metadata are stored in a different location than the filename.
   

   • There appears to be a lot of file entries in the third Linux related partition's filename output which has a * character between the file type and the metadata address. Additionally, the (realloc) text also appears after metadata address for several of those entries. What may these mean? According to the fls page on the Sleuthkit wiki, the * character means that the filename is in an unallocated space of the directory, i.e., the file is likely to be deleted. On the other hand, the (realloc) text means that the filename is an unallocated state but the metadata structure is still in an allocated state.

   • Finally, just by scanning through the third Linux related partition's output, there appears to be an intriguing entry called flag.txt. However, we notice that (realloc) appears in the entry. This means that the flag.txt filename is unallocated in the disk, but that its metadata is still allocated somewhere on the disk.

4. Following the above observations, we see right below the entry for flag.txt that there is actually another filename flag.uni.txt. Let us try and view the contents of the file using the icat command. The result actually turns out to be the flag picoCTF{by73_5urf3r_3497ae6b}!

The commands that were run across steps 2-4 are shown below in their entirety:

mmls disk.flag.img
fls -ro 2048 disk.flag.img
fls -ro 360448 disk.flag.img
fls -ro 360448 disk.flag.img | grep pico # tried to run this command but nothing immediately popped out :( manual scanning it is
icat -o 360448 disk.flag.img 2082 # just confirming that the flag.txt file is indeed empty
icat -o 360448 disk.flag.img 2371 # found the flag in flag.uni.txt!

1. Use exiftool to check the metadata of the file. Notice that despite the ending of the file being .txt, the exiftool output states that the file is actually a PNG file.

2. Rename the file so that the filename now ends with .png. Success! We can open the image and see the flag picoCTF{now_you_know_about_extensions}.

1. Trying exiftool, strings, and xxd did not provide me with any useful output. This means a more advanced steganography technique is likely used.

2. After some research, the zsteg tool by zed-0xff was mentioned multiple times. Let us install and try out this tool.

3. Using this tool, we are able to find the flag picoCTF{7h3r3_15_n0_5p00n_a1062667}.

1. Trying exiftool, strings, and xxd did not provide me with any useful output. This means a more advanced steganography technique is likely used.

2. Just like before, we try the zsteg tool by zed-0xff.

3. Using this tool, we are able to find the flag picoCTF{h1d1ng_1n_th3_b1t5}.

1. Open the packet capture using Wireshark.

2. Look through the hexdump of each of the packets in the packets capture. The flag picoCTF{p4ck37_5h4rk_ceccaa7f} is found in packet 4.

The flag picoCTF{p33kab00_1_s33_u_deadbeef} is found in packet 827. Notice that for that packet it returns a text/html file.