At BSides Chicago for the bsjtf CTF, I wrote a .NET Reverse Engineering Challenge. Now .NET gets a lot of crap. A LOT. So I wanted to write something that was a bit tougher to R/E in .NET. I have been developing in .NET since 1.0 was released. Yes, most of it can be bloated or improperly coded, but I strive to write secure code in .NET. With that, I wanted to see if it was possible to create something in .NET that was difficult to reverse engineer. Well, it seems that I was successful. No one was able to solve the R/E challenge. So I figured I would do a write up on this so everyone could see how this one was done.

The challenge (Return to Xork) started out with this text


TARGET: Indiglow Games
LOCATION: Byes, Nepal (28° 0′ N / 84° 15′ E)


Indiglow Games has long been a supporter of the rogue operative network. They hide back doors into their popular games like Return to Xork. I never got into those text based games, but apparently they are popular with the kids.

We’ve extracted an executable that was downloaded when we loaded up the Xork game. Take a look at it, see if you can figure out what it does.

The file is attached.

Good luck agent!


There was a file attached. When you downloaded it you realized it was a .NET executable. Running the .NET asked for a secret code. Anything you entered resulted in a bunch of gibberish for output.


The next step is to decompile the .NET. There are several tools out there like ILSpy or dotPeek. You could even use the decompiler provided by Microsoft with the .NET Framework tools. When you decompile the executable you will notice four functions. a(), b(), c(), and d().1750783259xor_dotpeek


Looking through the code, you would notice that functions a(), b(), and c() are called, but d() is never called. Looking at d(), you see that it returns the application GUID. This was hint #1. The secret code was the GUID of the application. This could be found using dotPeek or even a “strings” on the file.


So, if you enter the GUID you get closer but it’s still gibberish.


Looking at function a(), you notice that the function XOR’s the secret code (GUID) with the Framework Version name. This was hint #2 as well in the -help section. The current TargetFramework is v4.5. The –help section references v.4.0. What you needed to do was change the Framework Version from 4.5 to 4.0. You could do this in Visual Studio, but the easier way was just to change it in the hex editor.


After that, when you enter the GUID as the secret code it dumps the flag.

366793486xor_solutionAnd there you have it. 🙂

Share →