Reversing and Analyzing a Runtime Crypter
What's up guys? Welcome to a sort of general walkthrough on how one might approach a reversing and analysis on a crypted malware. This is by no means a universal technique so don't assume that this will occur in every scenario, it's more of a demonstration than anything really.
This will be another Windows-specific guide, so I'll repeat this: If you're a hater and cringe at the slightest sound of Microsoft's grotesque baby, feel free to close this tab, delete your history, exit your browser, pour some oil onto your machine and sanitize it with fire! Else, please continue onwards.
The reason I'm writing this article is because I believe that Null-Byte needs a little break away from the Kali/Metasploit scene, something refreshing and different. I'm also doing this to promote Phoenix750's future series on the Assembly language (you commit to it now, Phoenix750, or people will be disappointed!) and also to give a little peek at what I'm currently studying.
Before we start, I'd like to point out that this analysis will be performed on the RunPE crypter so if you don't know what that is, hop on over to my other article, A Guide on Runtime Crypters, to read up on the PE file format and how the crypter works. It's rather important to know and understand these basics so that you can even begin to comprehend the what, how and why.
Right, let's dive right in and get our hands dirty!
Note: I am still currently learning more about this so if I happen to get any information incorrect, please leave a comment below or drop a message in my inbox and I will try to patch it ASAP.
We'll need to have access to some tools to analyze the crypter so let's find out what they are:
First off, we should perform a static analysis to try to gain a sort of overall view of what contents the file contains, a reconnaissance, if you will.
Let's try and analyze the file with Avast! and see if it comes up with anything.
Looks clean, but it might not actually be when it's executed.
All we need to do is to load up our crypted file into IDA to have it disassembled.
So summing all of this up this loop looks like so:
Let's take a look at the array that supposedly contains the key.
Let's take a look at the array which supposedly holds the program to be loaded.
Okay, it looks like a jumbled mess of random values but behind the mask of encryption might lie the program for which we are looking. Of course, we can possibly try to deobfuscate the content with the supposed key we just analyzed but let's first try and see the last function call in main.
And then we will run the crypter under the debugger.
Well, whaddya know, a piece of malware was lurking in the crypter. Who would've guessed?
That's it for the demonstration and thank you all for joining me. Hope you've all gained something from this, whether it be entertainment or a new insight!
P.S. I'm really, really, really disappointed in you Malwarebytes... Sigh...