Validator3000

This challenge was labeled as RE in this years ctfzone CTF. The subtitle was The flag is inside, but take it easy and don’t waste your time, that should probably have been a hint on how to approach this challenge. As always reading between the lines is super helpful in a CTF. I mostly ignored this more than subtle hint and downloaded the challenge, which came as an extracable .zip archive.

It can now be found here: challenge

Upon extraction I was greeted with an .exe application. Executing it just gives us a window to enter a flag and a submit button. Upon entering something ‘wrong’ we were given feedback in form of bad flag.

So I fired up IDA to see what was going on. And I was welcomed by a ton of ‘weird/random’ looking API/function calls at least for me since I do not work with PE files at all. Eventually I found sub_401170 where 2 interesting strings can be found:

  • “Congratulations, you won!”
  • “Bad Flag”

These two were present after a this code block:

call eax    ; jumps to the value stored in eax
test eax, eax   ; test sets the zero flag 'ZF' iff the done and eax,eax yields 0
jz short loc_40137B     ; if yes jump to the bad flag ending

loc_40137B
push offset aBadFlag    ; "Bad flag"

So whatever happens to be in eax should be non zero so we jump to the good ending.

Note: the strings are in the .rdata section that is for const data. It is the read only version of the .data segment.

ida

I tried tracing what happened before to see what exactly is happening.

I found a bunch of code blocks and calls to the following functions:

  • GetWindowTextLengthW - Retrieves the length, in characters, of the specified window’s title bar text …
  • GetWindowTextW - Copies the text of the specified window’s title bar (if it has one) into a buffer.
  • SizeofResource - Retrieves the size, in bytes, of the specified resource.
  • LoadResource - Retrieves a handle that can be used to obtain a pointer to the first byte of the specified resource in memory.
  • LockResource - Retrieves a pointer to the specified resource in memory.

All of these are kinda a pointer towards that whatever is entered is loaded and compared to something loaded from memory.. At least that’s what I thought. So while nothing obvious appeared after running strings on the file it must have been generated during runtime somehow…

Luckily there is this nifty tool called ProcessHacker that is a more powerful windows task manager if you want. Also it can inspect/dump memory of a running process!

All I did was using Process Hacker in the end as shown below.

ida

And there it is! Our flag :)

I spent more time on this than I want to admit but I learned some more window reversing from this so I’m not that sad about it. Also I should have read the subtitle to this challenge more carefully. Furthermore having the right tools at hand right at the beginning can make things a lot easier..

Comments