Programming – Page 5

Sniffing correct serial in .NET crackmes

2015-04-242015-04-24 kao

Introduction

In this tutorial I'll show you a generic way how to break most of the crackmes written in VB.NET. It uses the fact that most crackmes made by beginners will calculate correct serial and do a simple comparison "if enteredSerial = correctSerial then"...

To break such a crackme, you only need to find this comparison and sniff the correct serial. This is a very common approach in x86 world but in .NET world it's not that popular yet.

As for my target, I'm using "RDG Simple Crackme .NET v4 2015"

GetProcAddress in .NET

In x86 world you can use GetProcAddress function to get address of any API function from any DLL. Can we do something similar in managed environment like .NET? It turns out that we can, but it's a little bit harder.

So, for example, to get address of Assembly.Load(byte[]) you need to do:

MethodBase mb = typeof(Assembly).GetMethod("Load", new Type[] { typeof(byte[]) });
IntPtr handle = mb.MethodHandle.GetFunctionPointer();
Console.WriteLine("Assembly.Load() = {0:X}", handle.ToInt32());

This works well with static classes and static methods. How about non-static methods like RijndaelManaged.CreateDecryptor(byte[], byte[])?

That's doable as well, like this:

RijndaelManaged rijndael = new RijndaelManaged();
mb = rijndael.GetType().GetMethod("CreateDecryptor", new Type[] { typeof(byte[]), typeof(byte[]) });
handle = mb.MethodHandle.GetFunctionPointer();
Console.WriteLine("RijndaelManaged.CreateDecryptor() = {0:X}", handle.ToInt32());

To make this reference almost complete - here's how to get address of .ctor:

ConstructorInfo ctor = typeof(MyClass).GetConstructor(Type.EmptyTypes);
IntPtr ctorPtr = ctor.MethodHandle.GetFunctionPointer();
Console.WriteLine("MyClass constructor = {0:X}", ctorPtr.ToInt32());

There are a few gotchas, however..

In case your target type is located in assembly that's not NGEN'ed yet, I suggest that you use ngen and install the assembly in cache. That can prevent certain problems later.
Addresses of functions are obviously different in .NET 2.0 and 4.0. You must compile for correct framework version and target the correct .NET assembly.
Addresses of functions are different for x86 and x64 framework versions, too. Make sure your assembly is compiled correctly.

Sniffing string compare

Suprisingly, string comparison in VisualBasic.NET and other .NET languages is different. It's caused by Option Compare statement present in Visual Basic language. So, if the crackme is made in VB.NET, you need to examine Operators.CompareString(string,string,bool) function. For crackmes made in other languages, you'll need to examine string.Equals(string) or some other variation of this method.

So, using the code I mentioned above, I learned that address of Operators.CompareString(string,string,bool) on my PC is 599F1D30. Now I need to sniff data passed to this function.

There are several possible approaches. You can try using VisualStudio & Reflector plugin as SpoonStudio tried, you can try using ILSpy and it's debugger plugin, or you can inject DLL into crackme process, as suggested by noth!ng - but I prefer to use OllyDbg.

Load crackme in OllyDbg, make sure that all the anti-anti-debug plugins are working, all the exceptions ignored, put a breakpoint on 599F1D30 and hope for the best.

Nope. Operators.CompareString is called literally thousands of times. So, we need to do something smarter.

For example, we can use conditional logging breakpoints in Olly. Those breakpoints are quite slow, but it's still faster than to write some sort of hooking DLL and inject it into crackme. So, we need to set 2 logging breakpoints - one for each string compared. Here is first one:

Place second breakpoint at the next instruction (59CD1D31) and log string at edx+8.

Run the crackme, enter some fake but easily recognizable serial and few minutes later we have the answer:

My entered serial was "1234567890123456789012345678901234567890" and it's being compared to "C49476D583364356253377056314435396D456F44796C7A55746431564433544". Hmm, could that be the correct serial for my nickname? 😉 Yes, it is!

Final notes

This was quite nice crackme and I only showed the simplest way to beat it. When you start looking into it, you'll find some nice anti-debug tricks, some nice anti-patching tricks and pretty nicely obfuscated code.

But that's a matter for another story. Have fun!

Catch me when you can

2015-04-08 kao

Introduction

Exception filters have been part of ECMA-335 specification since the very beginning. I'm guessing, they were added because Visual Basic used them extensively and therefore Visual Basic.NET had to support them as well. They look something like this:

Try
   'Try statements.
Catch cle As ClassLoadException When cle.IsRecoverable()
   'Catch statements.
End Try

Until now C# supported try/catch but did not have support for filters. That's going to change in C# 6.0/VS2015.

How does it work

In early versions of VS2015 the syntax was "catch-if", as you can see in the initial announcement. In the latest VS2015 CTP builds, they changed syntax to "catch-when", and there's a good reason for it.

So, how does it work and what does it mean for reversers?

It's a compiler-level feature

As I mentioned before, .NET Framework has supported exception filters since the very beginning. So, this feature works even in .NET 2.0 - if you decide to target .NET 2.0 Framework in VS2015 project settings. Not that you really want to do that..

It's very useful for debugging

catch-when is implemented as an IL exception filter. So, when an exception is thrown, exception filters are processed before the stack is unwound. This means that filter method has created an error report that included the current stack trace, it would show the frame in which the exception occurred. Sounds complicated? It isn't.

Let's implement exception filtering in the "old" way:

private void button2_Click(object sender, EventArgs e)
{
   try
   {
      ThisCanThrow();
   }
   catch (Exception ex)
   {
      if (filter(ex))
         textBox1.AppendText("Interesting exception");
      else
         throw(ex);
   }
}

and this is how the stack looks when we get to filter(ex):

You can't see much here. All the context is gone, you must rely on exception stack trace and message. That's what we've always done, right? 🙂

If we write it in a "new" way, the code looks like this:

private void button1_Click(object sender, EventArgs e)
{
   try
   {
      ThisCanThrow();
   }
   catch (Exception ex) when (filter(ex))
   {
      textBox1.AppendText("Interesting exception");
   }
}

and stack trace will give us full context of exception:

Much better, isn't it? You can see which method threw the exception, on which line, you have access to local variables and everything else. Yummy! 🙂

Decompiler support for exception filters is crappy

They say, a picture is worth thousand words.. In a very simple example, Reflector gets the code structure right, just filter conditions are missing:

ILSpy handles it slightly worse, filters are messed up and unreadable. Filter code is gone, too:

And the latest JustDecompile just throws an exception:

Have fun with it!

Here is a small keygen-me for you to play with: https://www.mediafire.com/?k5b9vy0p9dfgb97

The difficulty is 2/10, you should be able to solve it in 30 minutes or so. The entire protection is designed to show you try-catch-when feature, so avoid patching - you can't learn anything by nopping-out few instructions. 😉

Miserable state of open source code

2015-03-11 kao

Yesterday I wanted to make a small API hook detector in C#. It has to parse PE file, find exported functions, read bytes from the beginning of function and then compare them with the bytes in process memory. Sounds simple, right?

Well, good luck finding a PE parser that actually works!

Looking for PE parser

Most of PE parsers stop at parsing DOS header, NT headers and section headers. But I needed something that would also parse export table for me. After a couple of Google searches I ended up with PEReader by DKorablin. From the first look it's decent and even has a demo application. What else could you want?

Hmmm, how about working correctly on really simple files? 😉

Sorry, nope.

It sure finds exported functions but it mismatches function names & RVAs. So, if you wanted to examine, say, CreateFileW, you will end up examining DeleteFileA. Or some other random API. Great job!

But it's opensource. Just fix it and submit a patch!

Umm, no. I was looking for a PE parser that I can take, load it in VS and use it. I don't want to spend days hunting down bugs and fixing them - this stops me from doing what I really want to do.

So, dear opensourcer, if you are publishing your code, make sure it actually works. If it doesn't work, please don't publish it at all - it's not helping anyone. Don't waste other people's time..

P.S. I ended up with using DNLib and writing my own PE export parsing. At least, I know it works properly..

.NET exception “The remote certificate is invalid”

2015-02-092015-07-22 kao

For one project I needed to make a simple tool that fetches file from webserver via HTTPS connection. Sounds easy, right?

There are plenty of ways of doing things, but to keep it simple, lets ignore error handling, timeouts, authorization and other features:

HttpWebRequest httpRequest = (HttpWebRequest)WebRequest.Create({url_here});
HttpWebResponse response = (HttpWebResponse)httpRequest.GetResponse();
... process response ...

It should work, right?

And yes, it works most of the time. For example, it fetches page from https://google.com/ without any problems.

But for some sites it mysteriously crashes with exception:

Error: System.Net.WebException: The underlying connection was closed: 
Could not establish trust relationship for the SSL/TLS secure channel. ---> 
System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

Cause of the error

It turns out that sites that are using self-signed, expired and otherwise bad certificates will cause this exception. How nice from .NET devs - they're trying to protect me! Well, no, because I still need to download that information!

Solution

I found lots of solutions of the web - and quite a few of them failed. Some of them are .NET 4.5 only, some of them are overly complicated class consisting of 20+ lines. I need something simple, that works everywhere from .NET 2.0 up and is actually readable!

This one works for me: put this line before doing any HTTPS requests:

ServicePointManager.ServerCertificateValidationCallback += delegate {return true;};

It effectively suppresses all certificate validation errors. Problem solved!

Example site for testing your code: https://www.pcwebshop.co.uk/