It’s really annoying when you have to deal with the initialization part of a malware, most of the time a malicious executable follows the same alloc/decrypt/jump_to_decrypted_code scheme. So, I decided to write something to ease and automate the initial process investigation of a malware.
The idea behind the plugin is simple, Sequential Dumper is conceptually able to dump blocks of memory in sequence: it monitors the flow of the malware code trying to dump all the new allocated/decrypted parts in different memory areas containing code of the malware itself.
A practical example will clarify everything:
The real malware is obtained after some tedious steps: a runtime allocated buffer is used like a bridge between the original and the real malware. The original malicious file is just used to decrypt a piece of code, and then this particular code will create the real malware replacing the old original file.
A malware with this behaviour is available at VirusTotal.
Can I use Sequential Dumper with this kind of malwares? Yes you can, here is the result of the execution with the enabled plugin:
The left part of the image comes from a folder view, it shows the list of the files created by the plugin at runtime; the right part contains the logged data inside Ollydbg view. There are only two simple cryptic phrases by the plugin inside the log window, it’s pretty minimal in terms of information, but you don’t need anything else because you can understand how the code flow switches from a memory block to another. The first switch has been done from the original file to the block in memory, the other one is the jump back to the real malware. As you can see from the picture there’s a interesting message by Ollydbg “Unload C:\…”: the original malware doesn’t exist anymore, it has been overwritten by something else.
What kind of files does Sequential Dumper create?
The listed files are raw dumps taken during the execution of the malware. Every single file has a name starting with “Dump_xx” where the double ‘x’ defines the creation order sequence.
The last part of the name has two distinct forms, with or without “_on_exit” tag. I prefer to dump a block of memory before and after its execution because a decryption or a simple byte modification could happen in the middle of its code. Take in mind that a single dump will be performed if and only if the memory block has been modified.
There’s also a checksum algorithm inside the plugin because I wanted to avoid duplicated dumps, if the accessed block of memory was already dumped you’ll see the switch log message only.
Sequential Dumper is a two states plugin: enable or disable. In this first release the menu has two items only, the ‘About’ item and the other one which is used to activate the plugin. It’s not necessary to enable the plugin at the first instruction of the malware, you can activate it whenever you want.
As you might guess everything relies on Ollydbg trace system, you have to run the debuggee in trace mode otherwise it fails catching a memory switch.
Ollydbg is not allowed to trace system DLL code by default, but I would suggest you to change this setting. Why? Take a look at 1cd7fe891143415870d1e7cf12100b161d456e777dab23fe7821c53bfed87052 sample:
The malware uses CallWindowProc to run a snippet from somewhere else, in this specific case the new code resides at 0x3900060. The address is outside the original exe and if you don’t allow Ollydbg to trace into system DLL the plugin won’t catch anything from the *hidden* snippet. I think you can understand why you might need to allow Ollydbg to trace system DLL. It’s not a rule but it might help.
Sequential Dumper produces a sort of chronicle of the malware execution. It comes from a simple idea and it was born in few hours so don’t expect too much. Take in mind it’s the very first release and it may be exposed to bug. Just in case don’t hesitate to send a mail with detailed information about the bug.
The plugin has some limitations but it could be helpful for someone, what do you think?