Once getting through stage 2 you will have an EXE file. It requires windows (I ran it in a VirtualBox VM seeing as I had no idea what it would do – can’t be too careful!), cygwin and the crypt library when installing cygwin.
Running the EXE you will see that you require some kind of license.txt – if you create an empty one then you get an error about it being invalid. The next stage is working out what is required to make the license.txt file valid. Being new to this realm of reverse engineering, but being comfortable with work with ASM I tried a number of tools – strace, objdump and strings. Each yielded useful bits of information – especially strings.
However the real breakthrough came when I ran the exe file through a tool called IDA Pro – the freeware version is sufficient for this exercise.
Running the binary through IDA Pro produces a very comprehensive flow of the program. If you navigate this flow you will being to see calls to printf which relate to the message we get on the screen.
Manually following the flow allows you to ascertain what the programme is checking for in license.txt. After seeing a call to fopen64 you will find a cmp instruction on the first 4 bytes of the file. It compares it with this 32 bit hex value 0x71686367 – if you convert this into an ASCII string you will see that it translates to ‘gchq’. This is the ‘magic word’ that the license.txt file begins with.
Adding the those four characters to the license.txt file will result in you getting the message about license.txt being invalid – it needs something more. So continue to follow the program flow and we see the following steps –
- Load a string from memory – the string is hqDTK7b8K2rvw
- Pass the above string as the salt and the string from license.txt to the crypt(3) function
- Compare the result to hqDTK7b8K2rvw and set a flag if it they match using strcmp()
The challenging step here is to decrypt the password. There are a couple of helpful clues – crypt(3) uses DES the result is used in the salt. The output of crypt(3) includes the salt at the beginning of the string. So the salt is ‘hq’. We also know that crypt(3)does not allow a password of more than 8 characters, and we can assume that this isn’t going to be too challenging so an attack on it with a lower case string / dictionary is a good place to start. We also know that the password is 8 characters long as the pointer to the read in string from license.txt is incremented by 8 later one.
I’ll leave this part of the challenge as an exercise to the reader – there are plenty of tools – think rainbow tables, john the ripper, crack etc… (as an aside, it took my Macbook Pro around 2 hours to crack it).
The program continues –
- It prints out two loading “stage 1” and “stage 2” keys – which is a massive clue as to what goes next in the license.txt file. I always wondered what those unused values in the previous challenge were kicking around for…
- If we are successful in the above password step then the program processes four values – the above crypt hash, and the three 32 words read from the text file (note you have to have these in the license.txt file as binary values, not text – so you’ll need a script to output that or a hex editor to create the file).
- The four values are formatted into a URL (as per the other challenges) which will lead you to the final solution to the entire problem.
Now, sit back… relax, and enjoy a well earned break or apply for the job… your call…
I just thought I would present some personal comments/reflections on this challenge – firstly as an engineer who works day to day with very low level embedded this was an interesting tangent to that circle of work. I often have to dig assembly and understand the finer points of computer architectures, so much of the above feels familiar – albeit with a very different architecture and slant on what you are trying to achieve. All in all it was a bit of fun, I learnt some stuff and walked out of my usual circles. I might even continue to expand on these skills when I find a suitable project…