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.

Entry Point of Code Check for argument count

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.

File read and magic word check

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 -

Loading salt, calling crypt and doing the comparison

• 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 -

Generating the URL to get the final solution

• 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...

Share/Bookmark

This is the initial release of the embedded traffic monitor which I implemented on an XMOS XC-3 development kit. It has a 256x32 VFD attached to it with a custom board that was designed from another application (hence the buttons/IR sensor you'll notice if you are observant). Full source code is available from the embedded traffic monitor sourceforge page.

More information and pictures after the break...

The basic premise of the system is that data comes in and then goes out the other side (to general traffic the device looks like a wire) and information about that traffic collected on its way through (so at the moment it just looks at packet byte length). The data is then aggregated appropriately with the throughput being averaged over a second (sample at an interval of 100mS).

The information as well as being displayed on screen (via a simple I2C bus) is stored to an SPI flash once every 10s. This is so that if power is lost then the logged data is not.

Current Feature Summary:

• Dual MII ethernet interface
• I2C VFD for showing the resulting information
• Saving of data to on-board SPI flash memory

Future features:

• Internal switch for custom applications (so you can access the device over IP)
• A web interface to allow a user to reset stored data and maybe produce a SVG graph?
• Change display for lower cost, lower power OLED? (Farnell order code: 1498842)

And some pictures:

XC-3 Network Monitor and Display

Network Monitor Display showing a graph and data rates

Share/Bookmark