HackTrinity '19 solutions

Nice and simple, to get you into the groove of challenge-solving.

Flag:

The title is short for Read The F***ing Rules, and I did.

Flag:

I happened to be on their Twitter page when this one was released.

Flag:

HackTrinityCTF

This is a classic warm-up reverse engineering challenge. Running the binary presents an input field for a serial key, which presumably protects the flag.

There are usually 2 approaches to these kinds of challenges — static and dynamic analysis. Static analysis involves disassembling the instructions of a program in assembly language, sometimes producing C-like pseudocode, and figuring out what it does without actually running it. On the other hand with dynamic analysis, you would normally run the program in a debugger and inspect its allocated memory while it is running. Just for this example, I will demonstrate a method for each of those approaches.

First let's start with static analysis. I use Hopper Disassembler because it has a free version that has enough functionality. Drag the binary into Hopper and you will see several panels. The left side displays the symbols with their labels (like function names, values, etc) and the middle section shows the disassembly of the selected symbol. Most programs, especially ELF binaries, start in main, so select that and choose pseudo-code mode. The main function shows the general flow of the program when it executes. Variables are declared at the top, some functions are called, and at the end there is basic control flow implemented using an if statement, then the program exits.

The first two variables concern command-line arguments, which we don't need to worry about here. Then 4 functions are called:

1. fwrite prints a string found at 0x400d28 to the screen
2. fgets reads 0x23 (35) bytes from standard input and stores it in var_60
3. ascii_unshift is a user-defined function that we will look at shortly
4. strcmp compares var_60 to var_30 and returns 0 if they are the same

So it basically asks the user to input the serial key, passes some sequence of bytes at address 0x400d00 to ascii_unshift and compares the user input to var_30. Now let's look at what ascii_unshift does and why var_30 is relevant. It takes in 2 parameters, loops over the bytes in the second one, bitwise right-shifts them by 1 and saves the result in the first parameter. This may seem confusing if this is your first time reversing, so here's a cleaned up version of ascii_unshift to help you understand:

int ascii_unshift(var1, var2) {
    for (int i = 0; i < strlen(var2); i++) {
        var1[i] = var2[i] >> 1;
    }
    return var1;
}

Essentially we get var_30 from a bitwise right-shift operation on a given string, in this case main passes 0x400d00 to ascii_unshift. So where does 0x400d00 come from and why is it important? If you look at the symbols again, you can see shifted_serial is at that address, so let's check it out.

The serial key is formatted in 5 groups of 6 uppercase letters separated by dashes, so the Z-separated bytes just need to be shifted right once in order to retrieve the key (which is what ascii_unshift does). I wrote a script to do that and it printed the key right away.

denovo1.py

When I entered the correct serial key into the binary, it said to guess a number between 1 and 100, but that part doesn't need reversing. When you get the number right, the flag will be shown. Also, if you haven't noticed, there is a shifted_flag symbol that can be deciphered just as easily, so you could skip this last part altogether and shift the flag instead of the key.

Now for the dynamic part, I will be using gdb because it is the standard GNU debugger and is included in almost every Linux distribution. Run gdb denovo_v1_x86 to start the debugging process. Same as in Hopper we want to disassemble the main function, so type disas main to do that. Looking at the instructions, notice the function calls to fwrite and fgets and others. It is practically the same as what we've already seen, except expressed in assembly. We know that at the strcmp call, the user input is compared with the serial key. Just before that, two values are being loaded into rdi and rsi to be used as function parameters.

Let's set a breakpoint at the strcmp line and inspect those registers. A breakpoint pauses code execution, which gives time to inspect or change the program's memory and resume when needed. Great, the serial key has been recovered! So let's quickly recap the commands:

• b is short for breakpoint and sets a breakpoint at a given address
• r is short for run and runs the program, stopping at every breakpoint
• x/s means examine memory as a string

Flag:

One of the first things you should do with media files is read their metadata. A popular tool to do just that is exiftool. Running it against the file shows some strange text in the title of the video.

If you're not familiar with Base64 encoding then you'll likely dismiss it as some sort of anomaly. The character set of Base64 is usually alphanumerics, +, and /, and you'll learn to spot that type of text with enough practice.

Decoding the Base64 string will output the flag.

Flag:

Open your Tor browser and navigate to the given URL to be greeted with a phpBB-based forum. First you need to register an account. Then simply find the auction post, which is the only post there, and scroll down to the bottom to reveal the flag.

Flag:

If you've been following the news around this time, this challenge might look familiar. The webpage shows a message, akin to the one left by the hacker that defaced the LUAS website. The key take away here is that the ransom note asks for 0.2 ZEC to be sent to t1gok64PM8APnrSWXgBxboqHrszFYqP5v3L, which is a Zcash wallet address. And if you know anything about cryptocurrencies, you'll know that the transactions are public information for most crypto coins.

So what does that mean? Well, let's see if there's a way to find out this account's recent activity. Great, some money has been received, around 0.2 ZEC. But wait, the same amount was sent somewhere else. Let's follow the money:

t1gok64PM8APnrSWXgBxboqHrszFYqP5v3L

t1SG8g9mKchT5LBvEbRF35rrBYsX9JHutgb

t1VNt93X3pXSDPep4Q7vGiEtsnYHMa63Q2w

t1MHpjzxU4atBQgzbbiuLVVgMqDfBqjeoNU

t1UsHt8hn5ZK4mfMu1ddj6BFfDJPdQmZ9Ns

Finally landing on an account that has not sent anything out, the most obvious choice from here is to see if Google has indexed any pages mentioning that address. And indeed there is one — a blog by Mael Bonzaro.

Flag:

Opening the website leads to a page with an image and an Order button. Clicking on the button redirects to a simple ticket purchasing interface. Trying to buy one ticket works fine, as the basket counter successfully increments, but clicking on Add to basket doesn't work the second time as the button becomes greyed out.

You could simply Inspect Element and re-enable the button by removing the disabled HTML attribute (since this is all happening on the client side), or you could look at the source code and figure out that buying a ticket means sending a request to /addItemToBasket.php?id=1, so then just fetch("/addItemToBasket.php?id=1") from your browser's JavaScript console and cash out 2 tickets. But that's boring :P let's do it on the command line.

Flag:

This challenge requires a VPN connection to HackTrinity servers using the OpenVPN standard protocol. Upon connecting you are allocated a subnet, essentially a small range of IPs on the virtual network, in the form 10.137.x.x/28 and the task is to find a web server on the network that has the flag.

A great tool for probing networks is nmap, and I used it to find out if any devices were running some kind of web server. Bingo! It found 10.137.5.99 and identified an open port for HTTP traffic, so this must be where the flag is hosted.

Flag:

If you open the file in a browser and Inspect Element on the text, you'll notice that there are a lot of invisible characters written as HTML entities. This is because the file uses non-printable Unicode to hide some data, probably the real flag.

The character that comes up the most is ‌ so let's look it up. Wikipedia says that it is a zero-width non-joiner generally used to help with writing ligatures, especially in Middle Eastern languages. All that's left is to look for steganography that uses these symbols.

A DuckDuckGo search for zero width steganography returns https://330k.github.io/misc_tools/unicode_steganography.html as the first link. Great, looks like we're in luck as someone has already implemented this technique.

Flag:

This is yet another OpenVPN challenge. Normally you would want to scan the network for devices, but the description says to listen more. This suggests that you may be able to get the flag just by monitoring the network traffic.

A perfect tool for this job is Wireshark, so open that and select the interface connected via OpenVPN to start intercepting packets being sent on that network. You will immediately notice an influx of UDP packets from different hosts. To inspect the stream, right click on one of the packets and choose Follow > UDP Stream. Then look through the stream contents until you see the flag.

Flag:

The hint for this challenge was a dead giveaway. There are very few services this popular that ask for a phone number. The first (and last) place I looked was WhatsApp. Just add the given number to your contacts and check their WhatsApp profile picture.

Flag:

According to Wikipedia, a CIA file is a Nintendo 3DS importable archive. You could spend a lot of time trying to get ctrtool to extract the archive's contents, only to realise that a better first step would be to find a 3DS emulator.

I downloaded Citra, which is a cross-platform Nintendo 3DS emulator, and loaded the given file to check out if it did anything. A window popped up with instructions to "touch the four corners" to get the flag, even though there were more than four corners. Defeating the impossible presented me with the flag!

Flag:

In the previous Denovo challenge I covered the basics of reverse engineering. This time it's a bit more complicated as the function we need to reverse is a good bit larger. Let's open up Hopper and view the main function in pseudo-code mode. The code looks similar to the previous one, except that ascii_unshift has been replaced by dnv_decrypt as the new decryption function. Here is a break down:

1. fwrite asks for the serial key and fgets reads user input from STDIN (standard input) storing it in var_70
2. The asm { rep … } loop fills the new variable var_40 with zeros (read more about stos)
3. dnv_decrypt is called with the address of var_40, the address 0x400d40, a constant of 0x2c (44) and var_70
4. denovo_app is called if dnv_decrypt returns 1 or else the program exits with an error

Now let's look at the dnv_decrypt function.

1. It takes in 4 parameters; it was called with var_40, encrypted_flag at 0x400d40, 0x2c (44), and the user input from var_70
2. Makes sure that the last parameter is a string of length 0x22 (34)
3. Loops 30 times while adding values to var_B
4. Loops over the 2nd parameter as many times as specified by the 3rd parameter while bitwise XORing each value with var_B and storing the result in the 1st parameter
5. And finally compares the first 12 characters of the result to the 12 characters at the start of the flag

So the whole "encryption" is a basic XOR operation with a static value stored in var_B. The only part of the code that affects var_B is the bit at the bottom of the loop, and we need to find out its final value.

Some offset from the 4th argument — the user input — is stored in var_9, which is added to var_B minus 0x41 (65) only if var_9 is in the ASCII uppercase range (65 to 90). Looks like it just ignores the dashes in the user input and increases var_B by the offset of each value in the user input from the start of the uppercase alphabet, hence the 0x41 (65) which is the letter "A" in ASCII. And when var_B reaches a certain value, XORing it with encrypted_flag will produce the flag.

So all we really have to do is find out what the final value of var_B should be. This is easy because XOR is a reversible operation. So if a = b ^ c is true, then both b = a ^ c and c = a ^ b are also true. In this case, the encrypted flag XORed with var_B produces the real flag. So to find the value of var_B, we can XOR a known part of the flag (we know the first part is HackTrinity{) with the encrypted flag.

Find encrypted_flag in the left section, take the first character which is 0x1b (27), and XOR it with H (72). Cool, now we know that 83 is the value of var_B. The last thing to do is to XOR the bytes in encrypted_flag with 83 and recover the flag. A short Python script should do the trick.

denovo2.py

Flag:

This strange language claims to be Turing complete. I know from experience with esoteric languages that Brainfuck is turing complete as well, and it was created by Urban Müller. See the connection?

If you look at the character set of Brainfuck you'll notice that, out of the 8 symbols available, the comma (used for taking user input) is seldom used. I then tried to guess what each symbol translated to based on how Brainfuck programs are usually written.

The general gist of a Brainfuck program is as follows:

• Set the initial cell to a desired value, usually a common multiple for other cells that will be used for outputting text.
• Create a loop that moves the pointer to further cells, changes their value by at least a factor of 2, and then moves back to the initial cell, repeating the process until the initial cell reaches zero. This effectively produces multiplication.
• Output the ASCII representation of a cell when the desired value is reached, and repurpose the cell to print other values if needed.

You can, just by looking at other Brainfuck programs, tell which symbols go where. Some parts need guessing, like the + and - characters, but for the most part it isn't too hard to rule out certain combinations.

In essence, the given text translates to this Brainfuck code:

-[------->+<]>-.[--->++++<]>+.++.++++++++.>-[--->+<]>-.-[--->+<]>+.---------.+++++.-----.+++++++++++.+++++.++.[->+++++<]>++.----------.+++++.+++++++++++.-.++++++.+[->+++<]>.++++++++++++.+++.+.++++++++.--[->+++<]>.+++++++++++++.-------.+++++++++..[--->+<]>-.++++.

Flag:

Just like the one above, this is basically a Brainfuck translation without the comma. At that time the Turing-Lang challenge wasn't released yet, and I had some trouble figuring out the structure of Big Chungus+3 as that could have been a reference to Brainfuck+3 which has 3 symbols more than its parent language.

Not in the mood to try to write a Brainfuck+3 brute forcer, I took my chances by assuming it was Brainfuck and modified my Brainfuck interpreter to iterate over all permutations of chunga, chungus, chunky, big, karen, ricardo and fudd and map them to different combinations of Brainfuck symbols until one eventually prints the flag. And indeed it did. There are only 7 symbols and therefore 7 factorial (5040) possibilities, so it didn't take too long, having completed in under 1500 iterations.

bfbf.py
chungus.txt

Flag:

First things first, let's connect to the VPN and scan the network for active hosts. Running nmap -sV 10.137.24.0/24 reveals two devices: 10.137.24.210 with port 66 open, and 10.137.24.212 with no open ports.

Let's use netcat to see what port 66 is all about. Run nc 10.137.24.210 66 to be greeted with the first line from The Tragedy of Darth Plagueis The Wise meme. The meme transcribes a conversation between Anakin and Palpatine from a Star Wars episode; in this case the server is taking on the role of Palpatine. Obviously we have to respond, so copy Anakin's text and keep the ball rolling.

Once the final message "Not from a Jedi." is received, the server for some reason expects more data to be sent, as it responds to random text instead of closing the connection. What if the other host, the one with no open ports, is having a conversation with the server that contains the next few lines?

The challenge description says not to eavesdrop, so it's plausible that this might require an attack like ARP spoofing, where we trick the server into thinking we're the client and vice versa, making any traffic between the two devices sniffable with a tool such as Wireshark and thus "eavesdropping" on their conversation. Let's try this!

Running arpspoof -i tap0 -t 10.137.24.212 10.137.24.210 does the trick. Now all we need is to inspect the traffic and see what's being sent. Nice, we have something! One packet from 10.137.24.212 says "Senator, what's this I've found?". Let's write a script to send all current lines to the server and see what we get. Turns out the flag is sent as the following response by the server.

wise.py

Flag:

The corrupted ZIP file opens just fine on my computer, and apparently some versions of Android as well, but let's look at it from the perspective of a broken archive. A great tool for inspecting ZIP files is zipdetails because it provides an in-depth analysis of a given file, down to the byte.

Running zipdetails zippy_flag64.zip reveals a lot of information about the structure of the corrupted file. Notice how the compressed and uncompressed lengths are huge for flag.txt while the payload is clearly smaller than 0xFFFFFFFF bytes. What if we just extract the contents of the payload (i.e. the file) at the correct offset and length, and then decompress it manually? It would work because we know the compression used is Deflate, which is the standard compression method in PKZIP and should be included in the zlib library.

Lucky for us, Python has a zlib module that implements Inflate (the reverse of Deflate) and can help decompress the payload and retrieve the contents of the file. Here's a rundown of the Python code to solve this challenge:

Python 3.7.2 (default, Jan 17 2019, 12:26:41)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> with open('zippy_flag64.zip', 'rb') as f:
...     data = f.read()
...
>>> start, end = 0x3a, 0x66   # Info taken from zipdetails output
>>> payload = data[start:end] # Payload containing flag.txt contents
>>> import zlib
>>> zlib.decompress(payload, -zlib.MAX_WBITS) # https://github.com/kimci86/bkcrack/blob/master/tools/inflate.py
b'HackTrinity{g0ttA_l0ve_pkz1p_l1m1tati0ns}\n'

Flag:

We're given a file that has an unusual extension. Run file flow.reference to find out what kind of file it is. Cool, it's a regular Linux 64-bit ELF binary, let's execute it and see what it does. It asks for a password, which we don't know yet, but playing around with the input we can produce a segmentation fault by entering a large number of characters. This is usually an indicator of a buffer overflow, probably because the input function gets was used instead of fgets.

Let's see what gdb has to say about this. Aha! There is our gets, as suspected. The reason it is insecure (and even has its own section in the man page to tell you about this) is because it can write more data than the size of the allocated buffer it is writing to. In order to actually exploit this vulnerability, we have to find the offset at which our input produces a segfault. Playing around with the input, you will find that entering more than 40 characters is enough to trigger it.

The segmentation fault occurs because our input overwrites a value on the stack that acts as the return pointer for the main function. Then when it tries to pop the stack and jump to the address we overwrote, it will crash because the address is probably filled with garbage data or the wrong machine code instructions.

Going back to gdb, notice there is a call to printf with a parameter loaded from 0x4007e078. Similarly a call to puts is made just above with a parameter loaded from 0x4007e048. Let's check out what is at those addresses. Interesting, so they are different branches of execution in the main function. Entering the correct password would lead to the printf call which will print the flag, but what can be done without knowing the password?

Think about it, we have control of the stack and we know which branch to take to print the flag. All that's left is to redirect code execution to reach that part. The address we want to jump to when returning from main should be the address at main[+97] as that is where the flag is loaded as a parameter.

Run python -c 'print(" " * 40 + "\x56\x1c\x00\x40")' > exploit to write 40 characters and the desired address (in litte endian format) to a file. Then send its contents as input to the binary and see if the exploit works. Nice, we got the "flag" locally and now it's time to trigger it on the server and get the real one. Run nc ht3.hacktrinity.me 1337 < exploit to win a flag!

Flag:

After connecting to the VPN and scanning the network with nmap, there is one device that's reported as active. Let's check it out. The webpage has a simple interface for image conversion. Uploading a JPEG/PNG/GIF file converts it successfully, but trying to upload a different format produces an error. The idea here is to get the flag from the server without knowing the format. One way to do this is to find an RCE (Remote Code Execution) vulnerability, and then look for the flag on the filesystem. It helps to know that the website is "Powered by ImageMagick" because it has had a long history of serious vulnerabilities.

One that comes to mind is called ImageTragick, which has its own website that gives details and code snippets of exploits. The first example on the home page is an RCE which is just what we need.

Under the hood, the convert command from the ImageMagick suite uses curl to send requests if a remote image is specified in an MVG (Magick Vector Graphics) script. This can be exploited by modifying the URL field to add regular shell commands, since the input is not sanitised and is simply inserted into curl -s -k -L -o … "URL_HERE" … where you could add your own quotation marks and inject code.

A classic netcat reverse shell can be achieved with nc -e something … which runs the executable something across the remote connection, so /bin/sh would send the default shell of the system. Here is how to encorporate this into an MVG script: We also need to bypass the file format filter, which is easy enough and only involves changing the extension to .jpg or another accepted one.

Once that's done, start a listener with nc -lkp 1234 (without the -p flag on Mac and BSD) and upload the exploit script to hopefully get a shell. It worked! Now it's time to find out where the flag is hidden. Wandering around the filesystem reveals the flag in plain sight.

Flag:

If you call the number using a Voice over IP (VoIP) account, a female voice will answer with "please enter your two-digit voicemail PIN" after which you are given about half a minute to get the PIN right.

If entered correctly, the voice would respond with the flag. I'm sure there are better ways to hack these voicemails than the way I did, but a random bashing of numbers worked for me :P

Flag:

Here we have a gzipped tar archive which, when uncompressed using tar -xzf disk.img.tar.gz, extracts into a large disk image file. Running file disk.img to identify its contents says that it is an x86 boot sector with an extended partition table and one partition. This suggests that we're dealing with a bit-by-bit copy of a hard drive of some kind.

In this case we need to identify what format the flag is in. If one could "alt-tab away" from it, it may be some kind of media file. For tasks like this, foremost is a great tool when it comes to extracting files from within other files. Running foremost disk.img and inspecting the output folder, you will eventually find this image:

Flag:

This challenge was fun to solve. It hints at Server Side Request Forgery (SSRF), which is one of several viable methods for finding a Tor hidden service's real IP address. A lot of "onion" forums were deanonymised in this way.

So how does it work? Well, forums allow users to set their profile image. You could either choose to upload a picture, or you could provide a link to one via a web address. The URL would then be requested by the server, fetching the image and setting it as the user's profile picture. How does this help find the real IP of the server?

Imagine you own a web server (technically you do, your home router) and you're hosting an image on it, allowing public access and logging the IP address of every connection made. Could you not link to said image on your profile page of the Book of Kells forum? Of course you could!

Flag:

This was a very fun challenge, it took me a lot of time and research, and finding the flag felt very rewarding. The reason it took quite long was because this type of challenge is extremely rare for a CTF and the solution doesn't come to mind very quickly.

Here we need to get inside a home network and retrieve the flag from a webserver, usually running on port 80 or 443 for HTTP or HTTPS respectively. In an ideal scenario, a home network is perfectly secure from foreign attacks because the router doesn't allow incoming connections unless they were initiated from inside the network. However, things are never perfect.

Connecting to the VPN and scanning the network with nmap -sV 10.137.27.0/24 shows a device running 2 services:

• Port 80 running darkhttpd version 1.12
• Port 5431 running MiniUPnPd version 2.1

Opening a web browser and navigating to the device's IP address shows a fake home router page, listing some key information needed to help exploit the network later. The curious protocol in question is UPnP, which stands for Universal Plug'n'Play and is used by many smart-devices like TVs and gaming consoles to request port forwarding rules automatically and without user interaction. Surely that must be a way into the network.

If an outsider can set port up forwarding rules on a home network, they can access any interal device with relative ease. If the MiniUPnPd instance was poorly configured, it would be fairly simple to forward port 80 onto the internally connected device. Luckily there is upnpc, a UPnP command-line client counterpart to the server.

The command I needed to run to create a rule that forwards port 8080 of the router to port 80 of the internal device is upnpc -u http://10.137.27.195:5431/rootDesc.xml -m tap0 -a 10.137.27.178 80 8080 tcp. The path /rootDesc.xml refers to an XML document on the server that advertises the services it offers and how to access them, including device discovery and creating port mapping rules. The command sends a packet to the server that looks like this: You can see how this looks similar to an HTTP request, which it basically is but with a slightly more verbose syntax. (Ignore the different IP address, I took the screenshot later in the day.)

After setting the port forwarding rule, I just went to port 8080 on the router and found the flag in a text file.

Flag:

We are given a gzipped tarball containing an executable and 2 shared object files. Without knowing what the challenge is about, we can already tell that some parts involve cryptography because the object files are named after the RC4 encryption algorithm.

Running the binary shows the same output as the other Denovo apps. Let's open the main file in a disassembler and have a look at the flow of the program. Looks fairly simple to begin with, it asks the user to enter a password and makes sure that the length of the user input is 0x22 (34) and then continues to the denovo_layer0 function, passing var_30's address (user input), argc and argv as parameters. It seems that denovo_layer0 has a lot going on. Let's break it down:

1. User input is moved to var_168
2. A string with the process ID of the current program and "layer1" is written to var_110, e.g. "/denovo_1337_layer1"
3. The user defined function layer_key does something to var_168 and possibly stores the result in var_140
4. rc4_dlopen is called with var_110, var_140 and what look to be 2 memory addresses
5. If var_150 (the return value) is not 0 then dlsym tries to dynamically load the file descriptor var_150
6. The return value of dlsym is called with the original user input var_168 (twice), argc, argv and "layer1"
7. Finally rc4_dlclose is run, probably to clean up open file descriptors

What's interesting is that the flow here hinges on a modified version of the user input. Let's have a look at what's inside the layer_key function. The first argument is stored in var_18 and is loaded with the first 2 bytes from the user input. Then a loop of 32 iterations tests something and writes an ASCII - or 0 to var_18 depending on the outcome. So why is this function zeroing out parts of the user inputted serial key? Hmm...

This is where dynamic analysis comes in handy. Run gdb and set a breakpoint at the layer_key function, then check the value of rdi and rsi. So the serial key was zeroed out after the 2nd character, but why is that? Let's investigate further by looking at the contents of rc4_dlopen.

Load the shared object file librc4_ext.so in a disassembler and inspect that function. I simplified it and saved it in a text file because Hopper did a bad job. I renamed a few things, so here is what's happening:

1. TARGET is the string produced by sprintf, and STRIPPED is the modified serial key
2. DATA1 and DATA2 are the memory addresses from earlier
3. SHMEM is a shared memory object stored in TARGET
4. MAPPED is a writeable allocated memory region, the same size as DATA2
5. rc4_encrypt is where the magic happens
6. validate_elf checks the state of MAPPED
7. Then the function ties its loose ends and tries to use dlopen to load the mapped memory region as a dynamic library
8. Lastly, it returns either the file descriptor from dlopen or zero if an error occurs

Let's have a look at validate_elf and see what it's all about. All it does is check if MAPPED starts with 0x464c457f which are the magic bytes of an ELF file. This is starting to make some sense, so let's keep investigating.

Inside rc4_encrypt in librc4.so we see what looks like a standard implementation of the RC4 encryption algorithm. But wait a minute, the modified serial key is being used as the seed that generates the encryption key. And now we know that the hex numbers DATA1 and DATA2 are the offset and length of the encrypted data. This is great news for us and terrible news for Denovo.

You see, RC4 is a stream cipher meaning that each encryption operation happens sequentially, one byte at a time. In RC4 each byte of the key is bitwise XORed with each byte to be encrypted (or decrypted, makes no difference in an XOR operation). The RC4 algorithm simply defines how the key stream is generated, but the rest is just XOR and is nothing to worry about.

Back to the task at hand, we may already know what's going on. Let's take a reasonable guess and say that:

• A key stream is generated from our serial key, which was modified to only retain the first 2 letters
• The data at offset DATA1 of length DATA2 is XORed with the key stream
• The function validate_elf checks if the decrypted data is a valid ELF binary
• If the tests have passed, the decrypted data is loaded as a dynamic library and called from within denovo_layer0
• Judging by the "layer1" string from before, there may be many more layers

Let's test this theory out. I wrote a Python script to extract the encrypted data and attempt to decrypt it with RC4 by trying all 26*26 (676) letter combinations followed by zeros. If the result passes the test at validate_elf then this theory checks out. Since this is a stream cipher, we only need to decrypt the first four bytes to check if a key works. Wonderful! It seems to have worked. Let's check the output file denovo_layer1 and see if it's a real ELF binary. That's great news! And all occurrences of layer1 got upgraded to layer2 which confirms the theory of multiple layers.

So what is the next step? Well, we can assume that the 2nd layer also needs to be decrypted. Except this time the offset of the encrypted data is different. Let's use objdump to check the symbols in the original file — denovo_v3 — and see if anything stands out. Cool, the constants we used to get the offset and size of the encrypted data are stored in _binary_layer1_dnv_start and _binary_layer1_dnv_size. And notice how the section .denovo spans from _binary_layer1_dnv_start to _binary_layer1_dnv_size, it means we can extract the data just by looking for this section in the binary.

To ease the process of searching through a complex file format, I employed a popular Python module called pwntools (which only supports Python 2 at the time of writing). It found .denovo without any problems, so let's check if denovo_layer1 has the same section as well. Great, this will make the next part a whole lot easier. But what about the key streams for the subsequent layers? For now we will assume that we need to brute force 2 characters at a time, adding to the previous correct guess as we move deeper into the layers. If this turns out to be wrong, no big deal. This script attempts to brute force all 15 layers, as there are 30 letters in total and we need to take on 2 at a time. Running it produces 15 files named layer1 through to layer15 and also outputs the whole serial key. Awesome!

Now let's look at what Denovo has been hiding from us in the bottom layer. Quite a lot, it seems. What's happening here is:

1. A temporary directory is created with the path /tmp/den
2. Some gzipped data is written to /temp/den/doom.html.gz
3. Then the data is uncompressed into /temp/den/doom.html
4. And finally it is opened in a web browser

We know what the offset and size of the data is by looking at the call to fwrite, and then we can extract the data ourselves. Note that the starting address of _init is 0x1000 so we must remove that from our offset. Now let's open the output file doom.html in a web browser. Alright, impressive! A DOSBox running the game DOOM in a Javascript sandbox. I guess we must play to find the flag. Hit enter a few times to immerse yourself in a world of 8-bit ultra-realistic gaming. Look to the left to see a door and a lever beside it. Interact with the lever using the space bar and enter the unlocked room to see the one and only... flag! Wow, what a challenge! In reality most of the "working stuff out" took me several days, but that was one hell of a learning experience.

One thing I found that could be improved upon was removing the file I/O overhead by cracking the serial key and storing the layers in memory instead of saving them to a file with each iteration.

I tested this by hardcoding the offsets based on previous tests and modifying the script slightly. The result was a much faster Denovo 3 serial key brute forcer.

denovo3.py

Flag:

If you remember the first Trinity Ball challenge, this one is basically the same. The only difference being that the server responds with {"status":"too_many_tickets"} when manually requesting /addItemToBasket.php?id=1 more than once.

One possible attack in this scenario would be a race condition, where we perform several actions in quick succession and hope that a malicious one succeeds. In this case, we need to find a way to send multiple simultaneous requests to the server using the same cookie. This can be done with the magical bitwise AND operator & in both a JavaScript console and a shell.

Flag:

We are presented with a phpMyAdmin instance, which is a client for MySQL/MariaDB in a web interface, and we're supposed to get the flag from the webserver that's hosting it.

One of the "features" of MySQL is the ability to load files from the client. No, not your computer, but the client itself. It's called LOCAL INFILE and it follows a very simple sequence of interactions: The MySQL docs also has a practical example that shows the packet structure. Luckily, we don't need to endure the painful process of installing a MySQL server, but we do need a publicly accessible VPS to abuse this feature. (You could also do this locally, but you would need to set up port forwarding.)

There's a GitHub project called Rogue MySql Server that simulates a MySQL server by crafting similar packets. It's great because it implements the LOCAL INFILE request — all we need is to specify which file we want from the client, which is /tmp/flag.txt in this case. I modified line 144 to ensure that every response to the client will be a request for the flag file. This helped in preventing an error message that kept coming up when trying to login: Run the modified script, then "login" to your server through the phpMyAdmin web portal (use any username, no password needed) and then check the log file mysql.log created by the script to view the response, and there you will find the flag.

Flag:

This last challenge comes with a single ELF binary that produces the same output as the other Denovo challenges. Let's check it out in Hopper and take a look at what's inside. Interesting, main calls eso_new with __TMC_END__ and continually calls eso_next on the return value. Let's find where __TMC_END__ is located. Looks like this is the ESO program that the error message in main was referring to. Take note of the offset because we might need to extract the data at some point. The next important part to look at is eso_new. It's a little complicated, so let's simplify it a bit. The function expects an ESO program based on the signature at the start of the input data. It then allocates some memory and fills it with offsets from DATA in the following manner, starting from an offset of 11 bytes:

1. First it reads until a null byte (0x00), so it may be looking for a string
2. Then 1 byte is read, which appears to be either 0 or 1
3. Lastly, judging by the increase of temp by 6 and starting offset of temp + 2, a 4 byte value is parsed
4. This process is repeated a number of times specified by DATA[9] (i.e. LENGTH)

The next part also iterates a LENGTH number of times and does the following with every loop:

1. If the byte from #2 above is 1, zero out a number of bytes specified by #3 above
2. Else if it's a 0, copy X bytes from DATA to Mem1 where X is the number from #3 above
3. Increase the write offset by the number of bytes written

Then finally Mem1 is returned. To understand more closely the kind of data we are working with, let's extract the ESO program from __TMC_END__ and analyse it. Maybe if we're lucky it could be found in a .denovo section like in the previous Denovo challenge. Great, we can just copy the .denovo section into a file, but wait... it says _binary_layer0_bin_end. Looks like this challenge, just like Denovo 3, involves layers. Let's have a look at this first layer then, which is just the contents of .denovo. We've established how an ESO program is parsed by looking at eso_new, so now let's actually view the raw bytes and try to figure out what's going on.

The magic bytes ESO identify the file type. Then we see some bytes that don't quite make sense, we'll come back to them in a bit. Remember that temp in eso_new started at 11, so let's follow the first loop's steps from this offset. A sequence of bytes is read until a null byte is reached. Then one byte is checked for 1 or 0, and 4 bytes are read to determine the copied data size for the next loop.

What immediately stands out is how large the 4 byte value is — there's no way 0x7e000000 (2113929216) is the real size, that's more than 2 GB. Then it dawned on me... the values must be interpreted as big endian, and this would usually carry through the whole file.

Let's continue with the first loop in eso_new. The 9th byte in the file should tell us the number of iterations, but since the value is 0 we can only assume it is 2 bytes long, so then 5 is the correct value. This also matches how many strings can be found at the top of the file that start with . and end in a null byte, as well as being followed by 5 bytes of which the first is either 1 or 0.

Thus far the file structure of an ESO program strongly resembles an ELF binary, which is also parsed in sections. I think we're getting somewhere. We have section names, sizes, and a value that decides whether or not to write the section's data to the allocated memory. And we know the data is interpreted in big endian format.

So where do we go from here? I think that looking at the section names, we may be able to figure out what to do. We have:

• .data, 0x7e (126) bytes
• .s_offset 0x4 (4) bytes
• .stack zero bytes due to a non-zero value in the first loop (see #2 above)
• .layer 0x36c0 (14016) bytes
• .text 0x324 (804) bytes

That looks about right. Add the sizes together, plus the 72 bytes of the header we covered so far, and we get the size of this ESO file. This means the sections can be read sequentially and extracting them is trivial, but now we must figure out what to do with them.

Clearly .layer must be the first of many layers in this challenge. Looking at the ASCII strings after the header, .data is probably the same as the section in assembly and defines some constants. Now what about .s_offset? It's size is only 4 bytes. The previous Denovo challenge had us brute forcing the serial key 2 characters at a time, so maybe this section contains the offset of the character(s) to brute force in the serial key. If the value is less than the length of the serial key then we're likely on the right track. The value is 0x1c (28) which is indeed within the range of the serial key, so we'll go along with that.

In Denovo 3 there was basic XOR encryption using a keystream generated by the RC4 algorithm, but we don't know what encryption is used here, if any. Let's extract the contents of .layer and look deeper. Reading this in the same manner as eso_new parses ESO programs, notice how the data immediately after the 11th byte follows a similar pattern as the ESO file we just looked at. If we look at the first byte at position 0xb (11), which is 0x7b, we can see it being repeated 4 times at relatively similar offsets as in the ESO file. That's likely the . at the start of the section names. Also, 0x55 comes up several times in a row, so those are probably null bytes.

The fact that the values are repeated suggests that a linear encryption scheme is being used. Maybe another XOR? Let's verify this hypothesis by XORing 0x7b with 0x2e (ASCII .) and seeing if it equals 0x55 (ASCII U), since anything XORed with a null byte stays the same. If it works, we can then XOR the whole file with 0x55 and decrypt this layer. Awesome! We've confirmed that the encryption is XOR and can hopefully continue this layer by layer. The character U was used to decrypt the first layer, and we must find the correct character used to decrypt the others. Also the .s_offset value (4 bytes starting at 0x60) is again less than 34, which could indeed mean that the XOR key is at that offset in the serial key.

The serial key has 30 letters in it, so we have to repeat this process another 29 times. Let's script an ESO parser that tries to XOR all uppercase letters with each layer until it yields a valid ESO program. Here's the result: I saved the last layer in a file called denovo_v4.eso so let's take a look at it. Nice, we've cracked the program. Unfortunately there isn't a Doom level hidden inside, but there is a YouTube video so let's check it out. Lo and behold, the flag is in the description.

denovo4.py

Flag: