Home > Code, CTF > Eindbazen ebCTF write-ups

Eindbazen ebCTF write-ups

January 21st, 2015 Leave a comment Go to comments

With the Eindbazen CTF team, we hosted the CTF (ebCTF) during the hackers event OHM2013. To generate some awareness about the CTF and OHM2013 event we also held a Teaser round some time before it. Besides full-filling an organizers role I also created multiple challenges for both the teaser round and the CTF. For the teaser round I created the challenges BIN100 and FOR100, and for the main CTF I created the challenges BIN100 (together with asby), BIN200, BIN400 and NET400 (together with the NFI). This write-up contains the solutions, background info and source codes of the challenges I have worked on. Feel free to use anything from this write-up including source codes, as long as it is for non-commercial usage and please provide credits were appropriate. For commercial usage, please contact me to discuss.

 

ebCTF Teaser – BIN100

Description

Beat our dice game and get the flag.

http://dl.ctftime.org/85/499/ebCTF-Teaser-BIN100-Dice.exe

Solution

When we execute this file we see that it is a dice game and that we need to throw what the program wants:

BIN100

The dice throws seems to be done at random, so we do not have much chance of winning this game. What we can do is cheat by adjusting the code in OllyDbg. However we might want to avoid debug checks, because one of the things we should note is the calls to certain timing functions in the executable.

BIN100_time

To avoid having problems with the timing checks we should make sure we do not pause the program. Within OllyDbg we can make adjustments to the code and then save the program as a new executable. If we then execute this new executable we should not have any problems with the timing checks. We replace all the jumps to the wrong dice throws to NOPs, so all are throws are correct:

BIN100_Patches

When we now run the code outside of OllyDbg, we will get the flag. Note: When you run the code inside OllyDbg or patch the code live during execution it will most likely not result in the (correct) flag.

BIN100_flag

Source code

One of the ideas behind this challenge was to give the wrong key when people were running the challenge inside a debugger. Both a isDebuggerPresent routine and multiple timing checks were done during the execution of the code. When any of these checks failed the XOR-key which was used for the decryption of the flag would be changed so the flag would never be correctly decrypted.

The full source code of this challenge:

 

Write ups

Write ups for this challenge from others can be found here:

 

ebCTF Teaser – FOR100

Description

Eindbazen do not like Steganography challenges

flag = rev( steg.unhideBin( unhex( rot13( un7z( carve( xor( unhex( rot13( unrar( ebCTF_Teaser_FOR100.rar ) ) ) ) ) ) ) ) ) )

http://dl.ctftime.org/85/501/ebCTF_Teaser_FOR100.rar

The idea about this challenge was to make a statement about far-fetched unrealistic Forensic challenges which often appear during CTFs. But to keep it fair we would give the solution with it as well.

Solution

Step 1: unrar (ebCTF_Teaser_FOR100.rar)

The first step in this challenge was to unrar the ebCTF_Teaser_FOR100.rar file, the password for the file needed to be cracked and was “12”. After unrarring, we end up with a file Good_Luck

Step2: rot13( Good_Luck )

The Good_Luck file seems to contain numbers and some characters:

We need to rot13 this, which we can do with the following oneliner, after which we end up with hexadecimal numbers:

Step 3: unhex( Good_Luck_rot13 )

The next part is to unHex the new file, we can use the following oneliner for that:

 Step 4: xor( Good_Luck_rot13_unhex )

In this part we need to XOR the file, however we do not know with what we need to XOR it. Brute forcing a single XOR character gives us the XOR key of 0x42. We can use the following one-liner to XOR the file:

The file we end up with seems to be the following PNG file.

 

Good_Luck_rot13_hex_xor

Step 5: carve( Good_Luck_rot13_unhex_xor.png )

We can carve with multiple tools (such as PhotoRec, Scalpel, Foremost), or we can open the file with a Hex editor, below we can spot the footer of the PNG and right after it a 7zip header:

Carve

To get to the 7zip file we use the dd tool and skip the first 10388 bytes (0x000195d0 as in the screenshot above).

Step 6: un7z( Carve.7z )

Now we can unpack the 7zip file, however it is also password protected. The password can be cracked and is “21”.

Step 7: rot13( ebCTF-Stego_is_NOT_forensics )

From the 7zip file we got the file ebCTF-Stego_is_NOT_forensics.

The first part of this file seems to contain the following information:

Did you know ebCTF will take place from August 2 till August 4, 2013?
Better put that in your calendar!

After this part there seems to be some kind of encoding again which we also saw in step 2:

We can rot13 decode this with a one-liner, where we use dd to cut off the header:

Now we end up with a Hexadecimal file again:

Step 8: unhex( ebCTF-Stego_is_NOT_forensics_rot13 )

We use the same kind of one-liner as in Step 4:

It seems we ended up with a PNG again:

ebCTF-Stego_is_NOT_forensics_rot13_unhex

Step 9: steg.unhideBin( ebCTF-Stego_is_NOT_forensics_rot13_unhex.png )

The name of this next step seems to be a link to the LSB-Steganography Python software found on github.

When we run this script we end up with a new file:

Step 10: rev( unhide )

For the 10th and last step we need to reverse the file, so once again we use a one-liner:

It seems we ended up with another PNG file and the flag:

unhide_rev

 Write ups

Write ups for this challenge from others can be found here:

 

ebCTF – BIN100

Description

You showed your Windows debugger skills during the teaser, but how good are your Linux debugger skills?

http://ebctf.nl/files/c31892374badbfabd06a63ebe39d9036/bin100

BIN100 of ebCTF was a joint effort of asby and me, it was the Linux version of BIN100 from the ebCTF Teaser round. Basically the code was the same with some minor changes.

Solution

Running the program we see:

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:

The yes | head command is used to input the enters for the dice rolls. When we execute the script we get the flag:

 Source code

Write ups

Write ups for this challenge from others can be found here:

 

ebCTF – BIN200

Description

 There should be something hidden in this file, can you find it?

http://ebctf.nl/files/fcb920470457ec583006ca1de1025e17/ebCTF_BIN200.exe

The executable was a Perlscript which was converted in to an executable using Perl2Exe. The idea behind this challenge was to perform the following trick to recover the Perl source code:

Thice.nl: Perl2Exe back to Perl

Sadly enough between the creation (and testing) of the challenge and the usage of it during ebCTF someone created a Python script which made this challenge much easier sadly enough. It was not the goal of this challenge to just run a tool against the file and get the flag.

When we follow the approach described in the article or dump it with the Python script we end up with the following (truncated) source code:

BIN200

Source Code

The reason the key was added in ASCII art instead of plaintext was to make sure it would not be easy to just find the key somewhere in memory when executing the program.

Challenge source code:

 

Write ups

Write ups for this challenge from others can be found here:

 

ebCTF – BIN400

Description

Please upload 5 Windows console executable files with the same MD5 but with different printed outputs (file type: MS Windows, PE32 executable, console)

The output for the files should be:
File1: All Eindbazen are wearing wooden shoes
File2: All Eindbazen live in a windmill
File3: All Eindbazen grow their own tulips
File4: All Eindbazen smoke weed all day
File5: All Eindbazen are cheap bastards

NOTE: The goal of this challenge is NOT to attack this webservice, this is NOT a WEB challenge.

Solution

The idea behind this challenge was to follow a similar approach as described in this article:

Thice.nl: Meaningful MD5 Collisions: Creating executables

Using the Perl script from that article we can generate the source code which we can then adjust to this challenge:

When we compile this source code and then add the collisions with the Perl script we end up with 5 executables.

Output of the executables:

 

MD5 sums:

SHA1 sums:

 

Source code

The solution files can be downloaded here: ebCTF_BIN300_solution.7z

The following script was used to check the different executables that got uploaded:

Write ups

Write ups for this challenge from others can be found here:

 

ebCTF – NET400

Description

The Eindbazen ‘Forensic Unit Computer Knowledge & Advanced Persistent Threats’ and the ‘Special Unit Cracking Kiddies Investigations Team’ are currently investigating a new Scriptkiddie Group working under the name of ‘The Figuurzagers’. This team is suspected of hacking various crappy protected environments to place flags on these systems. The NFI provided us with a network tap of one of the attacks. Could you recover the flag for us?

Note: The file is in TIIT format
Encryption key: hashlib.sha256(“OHM2013 X Y!”).digest()[0:24] where X and Y represent lowercase English words that start with an r
Target Identifier: md5(eindbazen)
Provider Identifier: 51040
Hint: Remember, the first PDU will be “HI2: Start Session”

I wrote the scenario and the last part of the NET400 challenge, which was further created by the Dutch Forensic Institute (NFI). For the first part of the challenge I have to point you to the excellent write up at the end of this part. The second part of the challenge was to analyze the PCAP file, the cleartext PCAP file can be found here.

Looking at the PCAP we can see that a request is done in tcp.stream 1, which contained a pretty big hint what it was.

net400_savant

The Savant Webserver version 3.1 seems to be vulnerable to a remote exploit, as can be seen on Exploit-DB. We can find the exploit code in tcp.stream 8:

net400_exploit

The exploit code is visible, with the first part of the code being an egghunter, and the egg for the egghunter being HawkHawk. The full exploit code in Hex & Ascii:

This exploit code could be analyzed by replaying it against the vulnerable software, static analysis or by loading the shellcode in to OllyDbg:

To load the shellcode (only the part after the egg, HawkHawk) in OllyDbg we load a random binary (in this case notepad.exe) in it, copy the shellcode in our buffer (in Hex values) select a bunch of lines and then right mouse click and select “Edit–>Binary Paste”. The result will look like this:

net400_olly

If we select the first line and set the “New origin here” (right mouse menu) the shellcode will be ready for execution. Dont forget to set the memory access to full if you run in to errors (Memory Map (Alt-M), select memory segment, right mouse clock, set access–>full), this happens when memory protection is on.

If the shellcode executes correctly you will end up with the following pop-up:

net400_flag

Write ups

Write ups for this challenge from others can be found here:

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