08 Apr 2015

Catch me when you can

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:

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:

and this is how the stack looks when we get to filter(ex):
stack_trace_old
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? smile

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

and stack trace will give us full context of exception:
stack_trace_new
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! smile

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:
catch_when_reflector
ILSpy handles it slightly worse, filters are messed up and unreadable. Filter code is gone, too:
catch_when_ilspy
And the latest JustDecompile just throws an exception:
catch_when_justdecompile

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. wink

11 Mar 2015

Miserable state of open source code

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? wink

Sorry, nope.

Results from PEReader and CFF
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..

09 Feb 2015

.NET exception “The remote certificate is invalid”

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:

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:

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:

It effectively suppresses all certificate validation errors. Problem solved!

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