I've released Process Dump version 2.0 and now today v2.1 with a few bug fixes. Version 2.0 brought a bunch of major upgrades. The main changes include:
    1.   Added a new running mode where Process Dump monitors running processes, and dumps any process that attempts to close. This is great for dumping malware after it unpacks itself. Start Process Dump like pd64.exe -closemon, then afterwards run the malware file. It will dump all processes to the local folder as they close. When you would like to stop the monitor, just press CTRL-C to stop Process Dump.
    2.   Process Dump is now multi-threaded. It spawns a thread per-process it is dumping, which speeds up the process significantly.
    3.   Added functionality for dumping unattached executable code chunks. These code chunks are executable privilege regions in process memory, but aren't part of a loaded module. All executable regions will be dumped if they include two or more references to library exports in the same process. The clean hash database supports code chunks as well, so you should only see them dumped in rare cases.

I've released Process Dump source code under MIT license on Github:
        https://github.com/glmcdona/Process-Dump

Today I also released Process Dump version 1.5. It has a couple fixes:
    1.   Fixed bug where very large memory regions would cause Process Dump to hang.
    2.   Fixed bug where some modules at high addresses would not be found under 64-bit Windows.
    3.   More debug information now outputted under Verbose mode.

I've been working a lot fighting malware as usual, and put in a bunch of time into Process Dump to make analysis easier. 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 region.

The upgraded import reconstruction algorithm works as follows:
    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.

In summary it patches up the dumped code so that all references to imported functions will resolve properly when loaded into IDA or other analysis tools.

Process Dump now has a new command-line argument that allows you to dump code from a specific address, this works if there is no PE header for the code as well:
        pd64.exe -pid 0x1a7 -a 0x401000

Will generate two files - one with a 32 and one with a 64 bit header since it doesn't know which mode you would like to analyze the code:
        notepad_exe_x64_hidden_401000.exe
        notepad_exe_x86_hidden_401000.exe

Because of the new import reconstruction approach, these dumped regions look great in IDA with all the imported function calls being resolved properly by the reconstructed import table it builds with it.

I just released Process Dump v1.3. Several improvements have been made as follows:
  -   Improved handling of PE headers with sections that specify invalid virtual sizes and addresses.
  -   Better module dumping methodology for dumping virtual sections down to disk sections.

I just upgraded my website to a new design I built based on the emacs gdb debugging layout. I think it turned out pretty interesting! A few of you may even recognize the binary I was reversing from a certain ctf :)

Also, I just released version 1.2 of strings2. I added argument flags '-a' and '-u' to extract either only ascii or only unicode strings. By default it extracts both. In this version I also patched a rare bug when processing filenames.

I pushed out an important update to Process Dump today. The fix addresses a compatibility issue for Windows XP, and resolves a few bugs. The latest version is now Process Dump v1.1.

I just released the first version of a really neat tool called Process Dump (pd.exe).

It is an extremely useful Windows command-line tool for anti-virus researchers, malware analysts, and computer breach response people. The tool dumps modules from memory back onto disk (similiar to LordPE, but better), but at the same time uses a database to exclude known-good samples. 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 the engineer to analyze, 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 both 32bit and 64bit Windows and supports dumping of both 32 and 64bit modules of course.

I released a new version to strings2 today. Several new features have been added, including using process address spaces as inputs:
  -   Added "-r" recursive flag option.
  -   Added "-pid" and "-system" flag options to specify process input sources.
  -   Piped input data is now supported.
  -   Various fixes.

I pushed out an update to MALM: Malware Monitor as Version 1.1. The changes are quite minimal:
  -   In the non-final report MALM now also prints modules that are unloaded. This was added to address confusion caused when MALM would note that a module has been loaded multiple times in the same process. It should now be clear that the process is repeatedly loading and unloading the module.
  -   A bug where MALM would cause the operating system to behave oddly after running for a long duration has been addressed. This was caused by not closing handles to system snapshots.