We are provided a Windows 32-bit executable file, pretty standard in our field. After doing some initial surface analysis we can identify some interesting strings, which include a set of unique IP addresses and the following:

  • PAN{!?!BetterBeLittleCrazyThanLittleSmart!?!}

  • Time is tight so start from 0 sec and use the dbg hints

I’m going to go out on a limb here and assume that this is NOT the correct flag and it’s likely going to be used in order to generate the actual final flag. Also, time is tight; likely this is referring to the amount of time we have to submit the flag. Limiting the submit time for flags is something that’s been seen in other CTF challenges before and it can be quite tricky depending on how little time we are given.

Lets jump right into some quick static analysis and a debug session to see what’s actually going on.

Breaking at the start of the code and taking a look at the first real function call we see a pattern of LoadLibrary and GetProcAddress calls, this is a pretty common way to load the imports of a packed/obfuscated binary. Continuing our analysis we see that the string passed to each of the GetProcAddress calls is garbage and before these calls we actually have another function call that leads us to a deobfuscation function that takes the garbage argument to GetProcAddress as its argument. It’s obvious at this point that before loading our imports, the function names that are being imported are being deobfuscated before import loading successfully takes place.

After letting the program run past this point, we get to another interesting spot in our analysis, a call to RtlAddVectoredExceptionHandler and one of it’s parameters is a function address that I renamed EH_Location for the sake of following along.

Figure 1: Adding EH

The interesting thing about this is that the function that’s being set as our exception handler contains the string we previously saw during initial surface analysis, PAN{!?!BetterBeLittleCrazyThanLittleSmart!?!}. Because I want to make sure I get here, I set a breakpoint at the start of this function so that when the EH is called I know I’ll get to follow the execution of it.

We also see another function below this at sub_E1B10. This function contains a lot of interesting code, including TextOut which basically just prints out a string.

Continuing on, we hit the privileged instruction CLI. We already know that an Exception Handler was registered earlier on in the code so we might as well let this run to see what happens, perhaps this will trigger something interesting in our custom VEH? Unfortunately, this didn’t lead us anywhere too exciting but it did get us to an illegal instruction, error message during our debugging. Illegal instruction messages tend to lead off with the offset, so lets start there.

Figure 2: Illegal Instruction @ E51931

Checking out the offset of the illegal instruction (E51931) we see two 0xFF instructions, these are causing us to hit our exception handler again and because it’s a different exception type, it takes a different path and leads us to a new piece of code. At this point we continue to execute the application and the TextOut function gets called with our flag and it’s printed to the screen.

Figure 3: Flag printed to screen

Now that we have the flag, we have to be quick to actually submit it to the server, some folks may write a script to do this, but I just did it the old fashioned and submitted my flag to the Web UI. If we do it fast enough we end up with this:

Figure 4: Correct Flag

Ultimately, the challenge uses the list of IP addresses that were found earlier to grab the current time from the time server and this returned value is then used to encrypt the string BetterBeLittleCrazyThanLittleSmart, once this is done the SHA1 value of this hash is printed to the screen and this value is checked in the flag checker server when the contestant enters it.