The .NET is a Dangerous Place (Part 2)

If you recall from last week, after using using DotNetasploit, we successfully injected into the application, inspected the "Unlock" button, and discovered that clicking this button calls the function TestKey.KeyCheck(). At this point, it's time to open our program in Gray Dragon for a deeper dive.

Enter the Dragon Wolf

Opening and running Gray Wolf is relatively straight forward, just open the executable, and open the .NET assembly you want to view/edit.

able, and open it. After opening it, in this case, BestAppEver.exe, we'll see the below screen.

In the UI, we have 1) The assembly structure, 2) the MSIL corresponding with the selected function, resource, operation, etc. and 3) C# from the decompiled code. There's a lot that the tool can do that we won't be covering, but it's an excellent resource for editing .NET assemblies by changing the IL.

In the first panel, if you expand Best_App_Ever, you will see frm_RegBestAppEver, Program, and TeskKey (I think that's a typo by the author of the program). The item we want to know more about it "TeskKey" so click the [+] to expand and select KeyCheck(). You should now be looking at an image similar to the below which shows the decompiled function which does key verification. If we were going to write a keygen, this is exactly what we'd want to dive in to. Take note that KeyCheck is declared as "public static bool," as in Boolean, which means it returns true or false.

Refer to this image from last week.

If you notice, at line 0012, we see a reference to Best_App_ever.frm_RegBestAppEver, which is also what we see in Gray Wolf two levels up from TeskKey. Expand frm_RegBestAppEver and you will find bn_unloack_Click. Now, I think this is another typo and that the author intended for it to be unlock instead of unloack, but by the end of this post, you should be able to patch the application to do whatever you want so just deal in the mean time.

At this point, the 3rd panel should be showing you some pretty obvious C# indicating the relation of this function to the UI functionality that we saw earlier.

In panel two, we can easily identify the condition that triggers the key check failure by looking at line 29 of the IL view:

29 brfalse.s IL_005d: ldstr ("you must have typed it wrong!")

What we essentially want to patch is this part of the program. At line 22, the program calls TeskKey::KeyCheck() and takes two parameters of type string, presumably the name and key that's entered in the UI. If the result of this check is false, we jump to line 29, and receive the error message. In order to get around this and patch our program, we want it to return true instead of false. We can accomplish this by first enabling IL editing by checking the "IL Edit" textbox at the bottom. Next, highlight line 29 and in the OpCode dropdown, change brfalse.s to brtrue.s.

Once you've flipped the opcode from false to true, in the first panel, select "Save" from the bottom, and save your patched binary. After opening the patched binary, again, enter any values in the name and key fields and click "Unlock." Great success! Our patched program now accepts only incorrect name/key pairs and any legitimate combinations will actually fail. If you want to test this, use the key gen that comes bundled with the B.E.S.T App Ever and try it yourself.

Keep in mind that reversing and patching a .NET app isn't always this easy, but it's a nice way to get an overview of the tools demoed and most importantly, to learn something new.