What is the difference between malware that is 'dumped' and one that is 'unpacked'?

Question

On malware sharing communities, I have been noticing that the samples shared are marked as unpacked or dumped. I have tried to load the dumped malware in IDAFree, however, there is nothing in the imports table. The malware samples are usually marked as <hash>_dump_0x00980000 for instance. 0x00980000 seems like a memory address. But what does it mean for me trying to analyze it in IDA Free? Do I have to use that information somehow in IDA to load the sample correctly?

What I know: I realize that most real-world malware are packed. I understand the motivation behind this obfuscation and I understand how it can either be automatically unpacked if we know which packer was used, or it can be manually unpacked by stepping through it in a debugger and dumping relevant memory sections.

However, I do not understand how to analyze these "dumped" samples in IDA free. Most of the time, I see nothing in imports section and that makes the sample really hard to analyze. Is there a difference between unpacked and dumped that I should know about while loading it in IDA to see the actual imports section?

Answer 1

Is there a difference between unpacked and dumped that I should know about while loading it in IDA to see the actual imports section?

You can dump anything not only packed binaries, but with packed ones it usually comes with stripped imports table just to make it hard(-er) to analyze.

After sample is unpacked it usually rebuild its import table so it can run correctly. So for you to be able to analyze the sample correctly in IDA, Ghidra or any other too, you should dump it after it's being done (it's usually the first call in the unpacked binary) or rebuild it on your own in your dump after it's being unpacked. Also it might be required to map this file to correct address so that memory addresses are resolved correctly.

Answer 2

I would say this really depends on your definition of packing. Typically packing is limited to compression moreso than protection. In this case the binary is updated to maintain virtual memory while minimizing file size. The entry point will decompress everything so, despite the files differing, the virtual memory at the point of executing the original entry point is identical to the original.

Dumping from memory is never enough by itself (in most cases) even for something as basic as compression. You will still need to rebuild the decompressed file properly (i.e adding imports, fixing section headers, etc.) These basics are done by most dumpers though, so I would say a typical dump is enough for a typical packer. What about further protection though?

In cases where a file is not only compressed but also obfuscated, the newly generated binary from a generic dump will still be exceedingly broken. For example the imports table may not only be removed but also dynamically relocated and encrypted. This will cause the dump to fail rebuilding imports which can significantly slow down reversing. Similarly the packer could strip relocations, remap sections, etc.

Dumping
Typically refers to very generic unpacking. If the packer is simple compression then this is usually all that's needed for a proper copy of the original.

Unpacking
Typically refers to more specialized unpacking. Various areas of the packer in this case will generate an image in memory different than the original copy, all changes of which need to be detected and reversed.

Answer 3

A dumped file is, as the name suggests, a memory dumped process. Memory dumped means written to disk exactly as it is mapped in memory.

If there are any relocations, dynamic mapping, rebasing etc. that are done by the loader or by the program - they will be reflected in the file. Because of this, the loader will not be able to load a dumped process out-of-the-box.

Unpacked files are generally files that have their protections removed but may run (or at least, load).

Note that, by definition, a dumped process may or may not be unpacked and an unpacked file may or may not have been dumped from memory.

At the very least, in order to make the dumped file loadable you need to:

1. Copy the VirtualAddress and VirtualSize of all sections over their RawAddress and RawSize.

2. Make sure the directories (import, export, reloc etc.) point to addresses inside available memory. They may be incorrect/corrupted, but must be inside process mapping.