Writeup: Secuinside CTF 2013 - PE Time
Information
- Category: reverse
Description
We think something is hidden to this file…
http://war.secuinside.com/files/PE_time.zip
Writeup
Inside the archive we found a PE (as suggested by challenge title:) and a DLL:
- PE_time.exe
- msvcr110.dll
Our first question was why a standard dll were included in the challenge files, so we checked for possible modifications:
1 | $ cat msvcr110.dll| md5sum |
But after googling a minute we noticed that this md5 hash matches with the original DLL’s one, so we simply ignore this DLL for the rest of the analysis :)
Anyway, running PE_time.exe
outputs a strange circular window with a background image.
We thought that the image inside the binary could contains “something hidden”, so we extract it using
resource extract.
Once, extracted we checked for evidences of stenography using a couple of scripts
but we didn’t find nothing suspicious.
In order to permanently delete the stenography hypothesis we googled for the original image and finally we notice that there is no difference between PE one and the original one (a pixel per pixel difference resulted in a completely black image).
Well, now its time for a bit of reversing with IDA :)
Once located the event handling routine (sub_4010F0
in my system) we noted that there were some code for handling a event we have no idea how to trigger..
and the body of the this event handling routine look pretty strange due to its algorithmic looking (there was some loop and a string comparison).
So maybe that was a good point where to investigate.
After this discover someone in the group (LMolr) suggested to eliminate the circular region and restore the original window shape.. well, maybe these are not the exact words.. but the meaning is the same :)
So, once found the call ds:SetWindowRgn
we adopt the quick and dirty approach: NOP it all :)
The result was a square window with a new button and an input box.. and the button click triggers the strange handling routine! We were on the right way..
Going back to the assembler we notice that the strange loops inside the button handler were some kind of hashing function, and the result of the hashing of the input string were compared with a fixed 4-character value C;@R
..
At that the goal were much more clear: we have to reverse the that hash because the original value could be the key.
The hashing algorithm were not to hard to understand, but considering the length of the code (4 chars) we decided to adopt another quick and dirty
approach.. reimplement the hashing function and then do a 2^32 brute force :)
With a bit of Hex-Rays magics we almost got the C code of this function, so the implementation was pretty straight forward..
1 |
|
Flag
1 | SECU |