[hsb]Team Harambae Presents: Rootcon 12 CTF Update + CryForBin 2,3,4,6,7,8 Write-Up

11 min readSep 30, 2018


It’s been a while readers! On this post, I will update you guys re: the result of our team — [hsb]Team Harambae’s recently-concluded Rootcon 12 CTF campaign AND a multi-feature write-up of my favorite category: Forensics! I will also talk about the reason behind our new [hsb] tag at the end of this post, so make sure to read all the way to the end!

Rootcon 12 CTF Result + Some Insights:

If you’re an avid reader, you might remember that my team and I — [hsb]Team Harambae — won our first CTF campaign last Rootcon X. When we lost last year’s Rootcon 11 CTF to arguably the country’s best and most-experienced CTF team — [hsb]Ethical Hackers Club — we vowed and worked hard to try to come back better and wiser this year (my teammate even went as far as getting an OSCP in the process. crazy. 🙊)! After a grueling, 24-hours of Rootcon CTF madness, it is with a full heart that I announce to you that we were very lucky to win this year to get our second set of the coveted Rootcon black badges! 💚

This year was definitely different. The challenges were still frustratingly hard, but this year’s CTF featured a lot of challenges that served as our saving graces: Forensics challenges. Our bread and butter 💚

Anyway, I’m not gonna waste any more of your time, so let’s dig in!

Challenge Write-ups

CryForBin 2

Let’s start with the easiest one. First, we were given a .zip file named secret_flag.txt.zip.

A quick unzip -l will display the contents of the .zip file:

unzip warns us that there are 14 extra bytes at the beginning or within the zip file, let’s check it out:

Supplying the first 14 bytes — notsosecurezip — as the password will let us extract the secret_flag.txt.

And the flag is:

CryForBin 3

This one’s a bit trickier. We were given a file called logmein.

A quick file command will show us the following:

Cute. We got an executable file. Let’s try to run it:

It asks for a userid and login password. Let’s rerun it again while randomly supplying a userid and login password:

We’re just wasting time here 😆. Let’s try to open it using my favorite, radare2:

Can I get some claps for an outrun-inspired color scheme?

As you can see on the image above, the program expects an input string r00tc0n to proceed, let’s try it out:

Nice! It displayed a new error: Incorrect login password. Let’s take a closer look again:

We can see that there is a string 573313_T0g_00f that was pushed in reverse due to endianness. It is then compared to the login password, and if successful, the program will give us the flag.

Finally, supplying the string in reverse as the second argument value will give us the following output and the flag:


CryForBin 4

This challenge is really frustrating because it requires you to fix a broken PNG file called imcomingtogetyou.png. Luckily, we have the idea that a PNG file is composed of chunks with the following specifications:

[data length (4 bytes)]
[chunk type (4 bytes)]
[chunk data (n bytes with n=data length)]
[crc (4 bytes)]

Every chunk in a PNG file is composed of 4 repeating sets: A 4-bytes data length, 4-bytes chunk type, n-bytes chunk data with n being the value specified by the data length, and finally a CRC worth 4-bytes.

Let’s open the PNG file in my favorite hex editor: 010Editor

Lots of things to see here. First off, the editor tells us that there is a CRC error. However, when you look closely at the chunk types and their specified lengths (especially the highlighted portions):

You can see that the specified data length for the first iTxt doesn’t actually match the size of the chunk data inside it. Let’s try to fix it:

Do note that we are fixing the file under the assumption that this PNG file doesn’t have any strings appended on it and only the data lengths and CRCs were edited to break it. If you look closely, the data length (30 bytes==0x1E) doesn’t actually match the number of bytes that are displayed in the chunk data (13 bytes==0x0D). Let’s change it and expect some CRC errors:

Right off the bat, running the PNG template on the file using 010Editor will tell you that the CRC is wrong. Let’s change it to the recommended value and move on:

After fixing the PNG file, we can finally open and view it:

what the actual f

Alright, we already fixed the PNG file. Now, we have to fix the pixels? 😢

Anyway, I’d spare you the eyesore and tell you the flag,


Hooray 🎊

CryForBin 6

This challenge took most of our time, but we almost beat the hell out of each other when we finally saw the answer 😆

First, we need to verify our assumption that the file that we got is a memory image. We can do that by using file, or manual inspection:

Ok, file didn’t work. Let’s try manually inspecting the file:

A file that starts with the hex header 53 ff 00 f0 53 often indicates a memory image file. Now that we have a certain level of confidence that the file that we got was a memory image. Let’s verify it using volatility:

Well, it worked and we also got a suggested profile for the (now confirmed) memory image. Hooray!

Now, let’s look at the process list (pslist) to identify the list of processes that were running when the target machine’s memory was imaged:

Can I get some claps for my WindowsXP-inspired wallpaper? 👏

As you can see on the image above, there is an unusual amount of notepad processes that were running on the target computer at the time of imaging. Let’s check ’em out using a plugin called notepad:

The notepad plugin displays the text/s that was/were displayed on the notepad application/s while the system was undergoing the memory imaging process. Running the following command:

$ volatility -f cryforbin6 --profile=WinXPSP2x86 notepad

and piping its output to a file will give us the result below:

At this point, removing the Process: and Text: tags will give us the following output:

Are you seeing the pattern now?

Hmm. Can you see the pattern? Let’s filter it a bit further so we can see it better. Let’s remove the question marks (?), the hex numbers enclosed in angle brackets (<>), and d’s with a trailing newline character (d\n). We will be left with this:

for real(???)

Nope. That wasn’t the flag. At this point, I burned through some of our precious time to find another way to solve this problem. After a few hours, I came across the screenshot plugin.

Opening the screenshot images, you’ll come across this image:

And there you have it. The flag. We were actually one letter away from the flag, fam.

My guess as to why the first method worked is because the attacker might have typed the relevant letters on the open notepad applications as positional indicators. I might be wrong though 😅

CryForBin 7

For this one, let’s skip the inspection/verification process and go straight to analysis since we are already quite certain that this is a memory image.

Let’s look for the appropriate profile for this memory image using imageinfo.

Now that we have the appropriate profile, we will be able to run the appropriate plugins for this memory image. (You can list all the available commands/plugins by providing the correct profile and adding the -h flag)

As always, run pslist so we can get a feel of the running processes on the system during the image acquisition phase.

As you can see, there are (still) a lot of notepad processes. Let’s keep that in mind for now, as I’m about to demonstrate another useful plugin.

One of the most useful plugins in volatility is called cmdline as it displays process command-line arguments. Using this plugin will aid you in looking for processes with weird arguments or long arguments (base64-encoded lengthy parameters, anyone? 🙈). Not to mention that it also lists the file path of the launched process, which is VERY useful in finding evil. Let’s try to use it:

As you can see, there are a lot of command-line arguments for csrss.exe.

Csrss.exe (Client Server Runtime Process), prior to Windows 7, is responsible for the graphical subsystem and drawing things on the screen, among other important operating system functions.

I usually use cmdscan after using cmdline as it lists the command history of the system itself. It also parses the memory of csrss.exe for commands that attackers entered through a console shell. These two are very powerful plugins, and have aided me in finding evil throughout my forensics journey. Now, for the output of the cmdscan command/plugin:

That is actually the flag in ascii art. The perp executed the command cmd.exe along with those parameters. The full flag:

Another way to solve this is to run the notepad plugin, as it will show you the text that was typed on a notepad application during the course of the image acquisition phase.

So why did this work, too? The attacker probably typed the text in notepad prior to executing cmd.exe with those as its parameters 😎

CryForBin 8

This is probably my favorite challenge among the three, as it proves the importance of the cmdscan command.

The challenge description:

A memory dump was taken of a workstation with a possible backdoor planted.  Analyze the memory dump to determine what was executed and provide its last two arguments in the format flag_is{first-second}

As always, run imageinfo first.

Now, I will show you the importance of the cmdscan command. As I have discussed on the previous challenge, it lists the command history of the system itself. It also parses the memory of csrss.exe(prior to Windows 7) or conhost.exe(Win7 and above) for commands that attackers entered through a console shell.

As you can see, the cmdscan command listed the commands that were executed by the attacker through the console. The flag is: flag_is{update-allhxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxity}

Conclusion/Final Insights

All in all, the forensics challenges were very interesting and challenging. It just probably looks so easy because we already knew the commands that were appropriate for the provided scenarios, but forensics in general is actually more than that. And honestly, I still have a long way to go; I still have more books to read, more mistakes to make, and more challenges to solve.

One final note, though. A memory image is now considered as a very essential phase in the DFIR process/es as it actually provides you with evidences that may be unavailable in the system’s disk image. For example, it is useful when looking for encryption keys that may be stored in the system’s memory in order to decrypt an encrypted disk. You can also go as far as dumping the SAM hive to get a list of the password hashes available on the system. The list can go on and on, and this proves the amount of evidences that are otherwise unavailable to you when you skip the phase of acquiring the system’s memory image.

As for references, you may look into these links:

  1. Volatility Command Reference — https://github.com/volatilityfoundation/volatility/wiki/Command-Reference
  2. The Art of Memory Forensics — https://www.amazon.com/Art-Memory-Forensics-Detecting-Malware/dp/1118825098
  3. PNG file specification — https://www.w3.org/TR/PNG-Structure.html
  4. Radare2 Documentation — https://beta.rada.re/

Happy Hunting and Keep Fighting the Good Fight, Blue Team fam!

..oops. I also promised to explain the reason behind our new and shiny [hsb] tag.


[hsb] stands for hackstreetboys. I co-founded this group with my teammate Ervin and the [hsb]Ethical Hackers Club founder Ameer, with the high ambition of being the country’s premier CTF team. We aim to be an organization that encourages knowledge-sharing — a place where all the members can gain direct mentorship from each other through joint discussions and continuous participation. We aim to be a close-knit group that may, (hopefully)one day, regularly put the Philippines in the international CTF world map. We hope that through this group, we may be able to share our knowledge to fellow countrymen — especially the younger generations — so that someday, they may carry the same ambition and goals that we had when we formed this team.

Currently, membership is invite-only as we are still trying to establish some house rules and other team management problems. We will announce a recruitment activity in the near future, so stay tuned for that 😃

And oh, the top three teams this Rootcon 12 CTF were:

  1. [hsb]Team Harambae
  2. [hsb]Ethical Hackers Club
  3. [hsb]hackdog

Congrats, hackstreetboys! I’m so proud of what we’ve managed to achieve this year! Looking forward to more CTFs with you guys 💚

Thank you for reading all the way through, reader! I hope you learned something new today! 😄

With love,