For this particular challenge, users are given an application created for the Windows mobile platform. There are a couple of ways to go about solving this challenge, however, approaching it statically is probably the easiest versus setting up the Microsoft Windows mobile emulator or debugging the code on an actual phone. Should the user run the application in an emulated environment, they are presented with the following:
Figure 1 Application running in emulated environment
Looking at the provided binary, if we unzip the file two times, we’re presented with the following files:
Figure 2 Unzipped files from Windows mobile application
The executable in question is a .NET binary, which we can decompile using a program such as dnSpy. Looking at the underlying code, we can see that obfuscation has been implemented to make it more difficult to read and understand.
Figure 3 Decompiled code in Windows mobile application
Stepping through the code and renaming functions along the way allows us to get an understanding of what is going on. The code performs the following:
The code checks to see if the SystemProductName is ‘Virtual’, indicating it is running within an emulator.
A Boolean check is performed against a function that always returns True, which must be manually changed.
The screen resolution is checked to look for a width greater than 1000 and a height of 5.
Should all of these conditions be met, the code execution will proceed. Otherwise, the user is presented with a response of ‘Hounds Released!’.
Figure 4 One of the many error messages encountered
If the user makes it this far, the code will start looking at the provided user input to determine if the correct key is provided. The length of the key is first inspected. If the key does not have a length of 12, a random error message will be returned. However, should it have a length of 12, code execution proceeds. The code then makes the following checks:
Checks to see if the SystemProductName starts with a ‘V’, which it should since our previous check was looking for ‘Virtual’. The 6th byte of this string (‘a’) is stored to later be used in the key.
The first byte of the provided key is checked for a ordinal of 66, or the character ‘B’.
The embedded MrBurns.jpg file is loaded, and the 7th byte is read and later used in the key (‘J’).
The SystemManufacturer is checked for a length of 5 and the last three characters of ‘kia’. Based on all possible manufacturers, we can conclude that this code is looking for a string of ‘Nokia’. The first two characters are stored to a variable and later used in the key (‘No’).
The 2^nd^ through 4^th^ characters of the provided key are XORed against a key and checked for a result of ‘DIE’. Reversing this process allows us to conclude the application is looking for an inputted string of ‘AdP’ at bytes 2 through 4 of the provided key.
The 5^th^ through 8^th^ characters of the provided key are checked against a long embedded string, looking for a value of ‘uzzl’.
The same checks are performed against the 9^th^ and 10^th^ characters, looking for ‘3’ and ‘r’ respectively.
Finally, further checks are made against the last two bytes of the provided key, looking for ‘!’ and ‘?’.
An embedded Garbage.jpg is read and attempted to be decrypted against the provided key if all of these conditions are met.
In addition to everything encountered, various red herring code snippets are included to waste the reverser’s time. Also, string obfuscation was used via the l1() and llll() functions, which unhex and XOR strings respectively. To make things slightly more difficult, function overloading is also used to make reversing a bit trickier.
Taking everything learned, we can conclude that the application is looking for a key of length 12. The string of ‘aNoJ’ is then concatenated at the end. Based on the checks encountered, we can conclude that the provided key must be that of ‘BAdPuzzl3r!?’. Using this key gives us the following result:
Figure 5 Key after using correct input string