When I was asked by SecDaemons to give a talk to the club about a security topic I was excited about the opportunity. The best way to learn something is by teaching it and I wanted to learn more about reversing .NET assemblies. I have created two write-ups for .NET challenges from CSAW which have helped me learn how to use some of the reversing tools. These challenges are easy in scope and a lot of fun.
For this challenge, running the executable starts a console application asking the user if they really run random binaries on their system. Any answer to this question will result in the program terminating. After running the binary though a decompiler the source code is generated and a snippet of that is below.
The third line in the Main function shows the first issue. There is a exit command prematurely terminating the program. Since this is a small program it can be fixed in-place easy enough. Using the Reflexil extension for the decompiler, a patched executable can be created which has the exit command and its argument removed.
Running the patched program at this point causes it to hang showing there must be more to this assembly then just a premature termination. In the code, the program is looking for a specific folder on disk. The first part of the path is easy since C:\Program Files\ is in plain text. This folder already exists in Windows so there something else that is missing. The code is using the Program.marker variable to search for a subdirectory of Program Files. It’s also using a MD5 hash library to query for the folder instead of a plain text folder name. Converting the byte array into it’s hex equivalent produces FF97A9FDEDE09EAF6E1C8EC9F6A61DD5 and decoded it becomes ‘Intel’. The final step is to create this folder and run the patched program again which generates the key.
The binary for this can be found here.
This reversing challenge is another fun puzzle to solve. Running the executable launches a WinForm application with a single text box and button. Entering an input into the box and submitting it displays assorted messages that does not help solve the problem.
Viewing the decompiled source of this application it is obvious that the code has been obfuscated. Running the application through de4dot to strip this does not help very much. The first area to look at in solving this is what happens when the button is clicked. The snippet of this method shows that there is an If…Else block which will either show the key to the user or display a failure message.
This code shows that based on the time on day and other variables a string is generated. That string is compared to what the user enters and if they match the key is display. The approach to solving the puzzle is to understand how everything is generated and enter the correct information in the application. There is also another easier way to solve the puzzle with Visual Studio. Once the application is compiled and running the debugging functionality of Visual Studio can be leveraged to examine memory at runtime.
Stopping at this breakpoint the input of the user is displayed as ‘password’. Also, the value of the correct input is displayed in the str variable. By copying this value and pasting it into the text box of the application the key is then displayed to the user.
The binary for this can be found here.
The slides to the presentation for the talk can be found here.