Trust But Verify: Reversing .NET Applications and Libraries

Posted by Brian Cardinale in Research, Reversing | 0 comments

“Trust But Verify” is a phrase that gets thrown around a lot especially in the auditing world. The phrase is useful in the civilized world, where people are generally honest. The phrase is NOT useful when it comes to trusting binaries on the internet, which should be considered the wild wild west at all times.

A little over a year ago, a colleague of mine, Dr. Reifers of DrIst Coach Consulting, were looking for a quick way to send email programatically without the need for a dedicated mail server. As this seemed like a problem solved a thousand times over, we did a quick Google search and landed on a forum with people discussing the same issue. A few posts down, lo’ and behold, someone was even offering a pre-compiled DLL purporting to perform the very task that we needed done.

Alas, Dr. Reifers and I, not being the trusting type of kind strangers on the internet, decided to dissect this generous offering from this internet citizen.

We immediately fired open our copy of .Net Reflector to investigate this precompiled present. .Net Reflector is a paid for utility with a time limited demo period that is capable of reversing .NET applications and libraries. I have since discovered another .NET reversing utility by Jon McCoy of digitalbodyguard.com called GrayWolf which will accomplish the same goal of reversing the compiled binary to it’s source code. I will be using screenshots of GrayWolf for the rest of this blog post.

When we drop our library onto the GrayWolf application, it reverses the DLL from CIL to it’s original source code.

GrayWolf opening our suspicious sendmail.dll

There is a fair amount of information at initial glance, so it is easy to be intimidaed, but just like lines of code themselves, it doesn’t make any sense until you start reading it. On the left-hand side, we see a tree with our “SendMail.dll” at the top. Three nodes down from that is “SendSMTP”, the namespace of this application which is just used for organization of code. Then we hit our first class, “DnsLookUp” which has a couple methods hung off of it. Of interest are, “GetMX”, “GetMXRecords”, and “GetMyRecords”.

GetMyRecords? That seems like an odd name for a method. Also, further down there is another class code “KeyDecoder”. This is a simple DNS program that looks up mail exchange (MX) DNS records. What type of “Keys” does it need to decode?

Upon further inspection, we also see that “GetMX” and “GetMXRecords” are, for all intents and purposes, identical except “GetMX”, which is a “private” method, meaning it cannot be accessed by any code outside its own class, and “GetMXRecords” has an additional method call at the top named “GetMyRecords”, another private method. So let’s investigate what “GetMyRecords” actually does.

As you can see, “GetMyRecords” calls the “KeyDecoder” class to extract the Windows OS Product Keys, and then the Microsoft Office keys and emails them to our not-so-friendly net-itizen! The email address has been blocked to protect the guilty. Moral of the story? Be careful of overly kind people on the internet!

Andrew and I stripped out the evil and had a working simple mail client shortly after. Further Google searching actually rendered the same (not evil) source code on another site, that was actually referenced on Microsoft’s page.