Hello again, folks! I'm back with another (final) guide on runtime crypters which is an extension on my previous runtime crypter guide. If you have not read it yet, I highly recommend that you do since the fundamental theory of the PE format. Again, this will be a 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.
This advanced guide will be discussing a concept which has some relation to packing technology so if you're interested in that, this may serve as a really basic introduction. I currently do not know what this technique is called but don't worry, I will explain its method and procedure so if anyone knows what it's called, just put it down in the comment section below, or not, whatever you want... I will be putting up my source code if anyone wants to have a look at what's happening in the technical code viewpoint but since this is purely conceptual, please do not expect it to work on all applications and if you're using it to test malware, do not expect it to be undetectable. This means that I will not be running it under an active antivirus environment. (Sorry!).
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.
Disclaimer: This is an article which shows how the runtime crypter works. It is meant to be a guide, not a tutorial so not every little piece of information will be provided.
Visualizing the PE Format
First, we will be analyzing the target file for our proof of concept, i.e. we will be using a Dark Comet client executable. Let's create one using the Dark Comet RAT and then analyze it.
Now let's see what it looks like using PEview to dissect it.
We can see all of the headers listed and each section as well. Great!
Creating a Concept
Step 1: Adding a New Section
First, we'll need to locate and point to the file offset of the new section header
Now we need to add in the section itself. Of course, there's nothing special to doing this, all we need to do is append our routine to the file. The section header will automagically register it.
All good!
Step 2:
Step 3:
To add this onto the file, just append it as I've mentioned before.
Easy? Maybe...?
Analyzing Our Modified File
First, let's build our modified file...
Let's try executing it normally...
Yep! Everything is working perfectly fine! Awesome!
Conclusion
Again, if you're confused, please do some more research - there's more than enough resources online for this. If you have not read my previous guide on runtime crypters, please do so since the theory of the PE format is explained (to some extent anyway) over there.
Hope you've all enjoyed this two-part series and have familiarized yourselves with different, very creative and magical PE manipulation! Thanks to those who have morally supported me during the development of this program! (I'm looking at you, dill_.) I'm not sure about what I'll write about next time, but I sure hope that it'll be as informative and interesting!
That's all folks!
dtm.
P.S. Oh, right, you're looking for the source code, yes? Well, I've delayed you long enough, just remember that it is purely proof-of-concept and will not work for all applications and certainly will not guarantee undetectable malware... Oh, and about comments, they're not too detailed as of writing this but I will certainly fix this issue!
Just updated your iPhone to iOS 18? You'll find a ton of hot new features for some of your most-used Apple apps. Dive in and see for yourself:
6 Comments
Congratulations dtm!. Very good work
Now I know how it works on Windows. But, just for my education, is it not needed to fix memory permissions on Windows at run-time?
Thanks, m8. What do you mean by "fix memory permissions"?
Sorry for the vague formulation of the question. Let me elaborate it.
On Linux (with ELF binaries), the section permissions are honoured. The .text section usually does not have WRITE permissions. If you try to write in the .text section your program will just segfault. This is managed by the MMU (Memory Management Unit) inside the Processor at the HW level (AFAIK). It is actually the mechanism used to implement virtual memory.
So, before writing (decrypting) to the .text section you need to add the write permission to that section (usually a call to mprotect). I checked your asm and it seems to just do the XORing of the whole section (no permission changes).
My question is: Does Windows prevents writing in the .text segment by default as it happens on Linux?. Just to know, I haven't done anything on windows in years, and I'm just curious.
Note: I think you can make your key a multiple of the page alignment and do the XOR on 16/32bits (on bx, or ebx) at once (depending on the alignment), instead of byte by byte. I do not think there will be a big improvement on performance, but your loader will probably be shorter. You will also be able to just bitwise AND a mask to iterate through the key.
Yep, you do need to set the Characteristics to include a write, see here: crypt.c, line 186.
As for alignment and XORing in 16-/32-bit blocks(?), sure, that's totally possible. I never thought of doing that so thanks for mentioning it. I was never intending on doing anything more than a basic byte-by-byte because I wanted to keep it real simple.
OK, I see. You change the permissions in the file itself.
Thanks!
Hi! I've been working on my crypter for executable files, and I'm just wondering how easy it would be to get the algorithm and the key I used in the stub, and how can I protect my stub. I'm not an expert in reverse engineering
Share Your Thoughts