1

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?

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.

  • Is there any resource that explains how to map the files to correct addresses in IDA or Ghidra? I searched, but in vain. – learnerX Oct 25 at 19:29
  • well in IDA you can specify this offset already when you load the file as an offset. In Ghidra, when importing the file you open Options and specify Base Address. You can alos do that later manipulating the memory map. – Paweł Łukasik Oct 25 at 20:03
1

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.

  • Thanks. That last part about mapping of addresses back to original after unpacking, any good resources on it to read for IDA? I have looked but in vain. – learnerX Oct 28 at 2:05
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.