This is an outline of my approach and solution to Dragon Research Group's Online Challenge for
August 2013. This was my first foray into anything resembling
reverse engineering/program analysis. I had a blast and learned a lot -
and I hope to learn a great deal more in this area. Throughout this
process, I moved back and forth between Windows 7 and Kali Linux environments, though I don't
imagine it's necessary to note when I did so in the write-up.
I downloaded the
.zip file, which I found to be password
protected. I fired up fcrackzip and ran it against the file - feeling a
bit silly when it quickly revealed the password to be 123456.
I extracted the file, which was an unrecognized binary file. When I
viewed it in a hex editor and browsed through the file, I saw two
.ELF at the beginning of the file, suggesting this
may in fact be an ELF file.
- A handy message pointing out that this file had been packed with
the UPX executable
I ran the
strings tool against the binary file, but that
turned up little more information.
I used UPX Packer with
upx -d to unpack the file,
resulting in the ELF file. Examining this file in my hex editor showed
quite a few more strings. I ran the program in the terminal, resulting
in message: You have 5 seconds. Factors are: %d and %d.
At this point, I tried many things with no success. What immediately
occurred to me was to multiply the two factors, and enter the result.
When this did not work, I thought perhaps the factors were multiplied
together more than just once, and tried multiplying by each factor
multiple times, hoping to randomly encounter the solution. I discarded
this approach when one of the times I ran the program, one of the
factors was 0. When I entered 0, without success, it became apparent
that the desired input was not simply some multiple of the given
factors. I did find it interesting, that the timer (at least seemed to)
reset every time I entered a response. It seemed I could enter
responses indefinitely, as long as I never paused longer than the
duration of the timer (presumably 5 seconds).
objdump to get at the assembly code of the file, and
spent a while digging around in there. This however, did not get me very
As I stated earlier, this has been my first adventure into anything of
this nature. I dusted off the copy of OllyDbg refused to run the file. I
was able to open the file in Evan's Debugger (edb),
but it didn't seem to run correctly. I could not get it to simply run
through the program, and when I tried to step-through the program, it
usually got stuck in what seemed like an infinite loop (which I believe
I may have seen later in my static analysis). In any event, I was never
able to get it to the point in the program where the prompt exists, in
order to examine the contents of the stack and registers at that point.
I had been hesitant to use IDA, as I
didn't want to feel like I was running a trial, I wanted to stick
to tools I could grow into. I'm glad I finally gave in, the free
version of IDA will be sufficient for me to grow into for a good,
long time I think.
IDA broke things down really nicely, and was a blast to use. However,
my knowledge of assembly and C is so limited, that I found myself lost
for the most part. I explored as best I could, with IDA up on one
screen, Google up on the other, and the Malware Analysis book open on my
desk. I managed to limp along enough to find the portion of code
responsible for printing "The factors are..." (
Despite knowing the general area in which to root around now, I still
was unable to parse what the program was looking for as input here.
However, just a little further down, I found something very interesting
- a string of sections of code that printed a bunch of single
From here, it was a simple (albeit tedious) task to go through all the
code, put together the string of characters listed in hex, and convert
them to ASCII. This produced lines that began to reveal the mythic creature I was
seeking. I did have some issues at first, as I (foolishly) ignored the
loops that created space characters in some places for spacing. Once I
went back and added those in, the image became very clear!
So, I never did get the active program to display the dragon image for
me, but I was able to retrieve the target information from the code.
This has really sparked an interest for me, and I'm excited to learn
more about reverse engineering and malware analysis. Thank you to
Dragon Research Group for putting on this challenge, I had a great time
working through it!
For further details on how the challenge was constructed along with
notes and write-ups from all challenge players who solved solved the
challenge, please see the updated DRG
Online Challenge August 2013 page. The newest, DRG Online Challenge September 2013 is
now available. Visit the DRG Challenges page
for information about all current, future and past challenges.