This is my second article on the Flare-On 5 CTF. This article will focus on the third challenge in the series, FLEGGO. If you haven’t read my other article detailing the first two challenges you can find it here. Unzipping FLEGGO presents us with 49 Windows Executable files. Running one of these files prompts us for a password, if we get the password wrong the program tells us to go step on a brick. We probably need to figure out the password for all of these files. This seems to be a daunting task, we can start by solving just one and working from there.
Opening the file in radare2 shows us that the program is calling two functions, fcn.004012d0 and fcn.004012d0.
Seeking into fcn.004012d0 we can see that the function is freeing up memory space at 0x404380 and 0x4043cc. It may be safe to assume that the other function will populate these memory spaces.
Going into the other function shows that my hunch was correct. The function uses the FindResource function to grab the first resource in the program and populate 0x404380 with its value. Looking at the resources using rabin2 -U shows us that the first resource stores the value 0x0040e0b0. So that memory address gets stored in the location 0x404380. I wonder if that will be important later on.
Moving back to the main function we can see the programming printing the “What is the password?” string and calling the function sub.IronManSucks_240. Jumping into this function we can see the program comparing our answer to the string “IronManSucks”, printing “Oh, hello Batman...” and returning (This is a reference to the Lego Batman movie, if you haven’t seen it go watch it). Let’s try that as a password and see what happens.
Huh, it still kicks us out. We should take a closer look at that function and see what might be causing this.
It looks like there was another check in case you got the “IronManSucks” value wrong. This check takes the value from 0x404380 (sound familiar?) and compares our string to that. We know that 0x404380 is pointing towards 0x0040e0b0, so I wonder if our password is stored there.
ZImIT7DyCMOeF6? Seems like a long shot but it is worth a try.
Looks like it downloads an image and gives me a letter associated with the image. The image has the number 7 on it, which may be where the letter “w” goes in the sequence to build up the flag.
The next thing to do is to see if the password is stored at the same location, 0x0040e0b0, in every program. If it is, then we can write a script to run all of these binaries with their passwords. That would give us all of the images along with the letters associated with each one.
Looks like the password is in the same location for every excutable! Now we just have to use r2pipe and Python to make a script that will run every executable with the correct password. If you’re not familiar with how r2pipe works you can read another one of my articles, Automating RE Using r2pipe, that walks you through the basics. The script I used is as follows:
You can also get this code on my github. I used the command ‘pfj Z @ 0x0040e0b0’ to grab the password for each executable. The script then runs each executable under wine (since I’m running Linux), passing in the correct password. It then takes the output from the program and puts it into a handy reference list that shows which picture corresponds to which letter.
I then had to manually go through every picture and see which letter it corresponded to. The final flag is firstname.lastname@example.org. The pictures turn out to be an instruction guide to a Flare-On themed Lego set! Pretty cool challenge! Unfortunately, this is as far as I got with the Flare-On 5 challenges. You can find the rest of them on their site. As always, feel free to message me on Twitter or LinkedIn to leave some feedback on this article or my blog in general.
Thanks for reading and happy reversing!
Reverse Engineering, Radare2, Linux, CrackMe, Scripting, Automation, r2pipe