[_glmcdona]

I just released a Windows 32 and 64bit command-line tool for dumping modules from running processes back from virtual alignment to file alignment on disk. The tool is similar to LordPE module dumping, but is focused on a larger scale by being able to dump all modules from specific or all processes. It can for example dump all modules from all processes which do not pass a known clean hash database check. The clean hash database is easy to build using the tool while on a clean system.

In this way, you can for example take a snapshot of your machine to build the clean database, run a malware sample, then dump all modules from all processes on the machine. Only the modules not matching the clean hash database will be dumped back to disk for analysis, which will typically include all the unpacked components from the malware in all processes. Similarly, this tool can be used when responding to a breach incident to find the malware that has breached a workstation. The tool supports dumping of both 32 and 64bit modules of course.

I would love to have feedback on possible improvements, if it is useful at all, or bug reports. The download can be found here:
http://split-code.com/process-dump.html

or direct download links for the 32 and 64 bit versions are as follows:
- Windows 32bit: http://split-code.com/files/pd_x86_v1-0.zip
- Windows 64bit: http://split-code.com/files/pd_x64_v1-0.zip

[Buster_BSA]

Windows XP x64 with SP3: The tool crashes with next message:

The procedure entry point EnumProcessModulesEx could not be located in the dynamic link library PSAPI.DLL

[_glmcdona]

Darn, that's embarrassing. For some reason I thought that was a standard library. I will take a look to see if I can link it statically and come out with another version tomorrow. Thanks a lot for trying it out!

[Buster_BSA]

Correction: x86, not x64.

[_glmcdona]

I updated Process Dump to version 1.1. It now supports Windows XP, and a fixed a bugs:
- Fixed a compatibility issue with Windows XP. The psapi.dll function EnumProcessModulesEx is only available on Windows Vista and above, so I removed the dependency on this function in the 32-bit build of the tool.
- Corrected a bug when processing some modules where Process Dump would print that it is dumping a module, but there is no corresponding dumped file.
- Corrected a missing implementation for the "-p <pid>" dump flag. It is now implemented.

The downloads to the latest version are:
- Windows 32bit: http://split-code.com/files/pd_x86_v1-1.zip
- Windows 64bit: http://split-code.com/files/pd_x64_v1-1.zip

And a screenshot of the resulting dumped modules by the tool when dumping all the modules in the "chrome.exe" processes:

[_glmcdona]

Updated Process Dump to version 1.4.

Download latest version here:
http://split-code.com/files/pd_latest.zip

Depends on Microsoft Visual C++ 2008 Redistributable:
http://www.microsoft.com/en-ca/download ... aspx?id=29
http://www.microsoft.com/en-ca/download ... x?id=15336

I've been working a lot fighting and reverse-engineering malware as usual, and put in a bunch of time into Process Dump to make analysis easy. It now uses an improved import reconstruction algorithm, and is also able to dump code from specific addresses - building a PE headers along with reconstructing an import table for the specified region.

The aggressive import table reconstruction approach patches all DWORD (x86) or QWORD (x64) values that correspond the address of an export to their corresponding library and export. Here is the description of the new algorithm:
1. Copies OriginalFirstThunk over FirstThunk array for each imported library. (original import reconstruction approach)
2. Looks at all modules loaded in the current process, and builds a list of the addresses of all exported functions.
3. Searches the region or module that is being dumped for any DWORD (x86) or QWORD (x64) matching an exported address in the process.
4. For each match, adds an imported library with FirstThunk pointing to the DWORD or QWORD to patch up, linking it to the exported function of the corresponding library.
5. The size of the last section is increased, and the extended original import table is placed here.

This works great, since even imports loaded by GetProcAddress() will be reconstructed for analysis in IDA:



I added another new feature do dump code at a specific address, eg:
pd64.exe -pid 0x1a7 -a 0x401000

If the target address does not have a PE header, it will generate a 32 and 64 bit PE header automatically as well as generate a reconstructed import table so that it can be analyzed nicely.

Here is the updated help page for the tool:

Code: Select all

Process Dump v1.4
  Copyright ® 2015, Geoff McDonald
  http://www.split-code.com/

Process Dump (pd.exe) is a tool used to dump both 32 and 64 bit executable modules
back to disk from memory within a process address space. This tool is able to find
and dump hidden modules, and it uses a clean hash database to exclude dumping of
known clean files. This tool uses an aggressive import reconstruction approach that
links all DWORD/QWORDs that point to an export in the process to the corresponding
export function.

Before first usage of this tool, when on the clean workstation the clean exclusing
hash database can be generated by either:
  pd -db gen
  pd -db genquick

Example Usage:
  pd -system
  pd -p chrome.exe
  pd -p "(?i).*chrome.*"
  pd -pid 419
  pd -pid 0x1a3
  pd -pid 0x1a3 -a 0x401000

Options:
  -pid (pid)  Dumps all modules not matching the clean hash database
      from the specified pid into the current working
      directory. Use a '0x' prefix to specify a hex PID.

  -p (regex)  Dumps all modules not matching the clean hash database
      from the process name found to match the filter into
      specified pid into the current working directory.

  -system   Dumps all modules not matching the clean hash database
      from all accessible processes into the working
      directory.

  -g    Forces generation of PE headers from scratch, ignoring existing headers.

  -v    Verbose.

  -nh   No header is printed in the output.

  -nr   Disable recursion on hash database directory add or
      remove commands.

  -ni   Disable import reconstruction.

  -db gen   Automatically processes a few common folders as well as
      all the currently running processes and adds the found
      module hashes to the clean hash database. It will add
      all files recursively in: 
        %WINDIR% 
        %HOMEPATH% 
        C:\Program Files\ 
        C:\Program Files (x86)\ 
      As well as all modules in all running processes 

  -db genquick  Adds the hashes from all modules in all processes to
      the clean hash database. Run this on a clean system.

  -db add (dir) Adds all the files in the specified directory
      recursively to the clean hash database. 

  -db rem (dir) Removes all the files in the specified directory
      recursively from the clean hash database. 

  -db clean Clears the clean hash database.

  -db ignore  Ignores the clean hash database when dumping a process
      this time.  All modules will be dumped even if a match
      is found.

[Buster_BSA]

Thank you very much for the update and the new features!

[_glmcdona]

Thanks Buster. Let me know if you run into any problems or have any feature requests :)

[jtl]

Cool stuff. Just curious can this dump injected DLL's that have been hidden/removed on the process PEB list?

[_glmcdona]

Cool stuff. Just curious can this dump injected DLL's that have been hidden/removed on the process PEB list?

Yup, it works for modules not in the PEB list. It loops through the target address space, and any MZ header at a 0x1000 alignment is marked for dumping. If the module is in the PEB list it will include the module name in the dump, otherwise it uses the name "hidden", eg:
"mstsc_exe_hidden_4CE0000.dll"

You can also manually specify it to dump a module by giving the address of the module to dump, eg:
"pd64 -pid 0x1a7 -a 0x4ce0000"