MoVP II - 1.4 - New HPAK Address Space

Volatility can analyze memory dumps in the "HPAK" archive format, which is proprietary to the Fast Dump (FDPro.exe) acquisition utility. As we said in a previous MoVP post, if you're not the person acquiring memory, there's no telling what tool or format will be used for the acquisition...but you still have to find a way to analyze it. Prior to the 2.3 release of Volatility, hpak files created by FDPro.exe could only be opened in H.B. Gary's Responder tool. We received a request to support hpak files because analysts were often handed hpak files, but they desperately wanted to perform the analysis with Volatility. Thus, a new address space was born....

Acquisition

When acquiring memory with FDPro.exe, use the -hpak option to create a memory dump in the hpak format. By default, without this option, raw memory dumps will be created. The advantage to using hpak is it can perform compression and also combine the system's page file(s) and and the target's physical memory into a single file.

File Format

A file with an .hpak extension has a 32-byte header. The first four bytes are "HPAK" which is the magic value. The purpose of the remaining fields in the structure are unknown, but non-critical to the task of parsing the overall layout of the file.

>>> dt("HPAK_HEADER")
'HPAK_HEADER' (32 bytes)
0x0   : Magic                          ['String', {'length': 4}]

Immediately following the header, there are a variable number of HPAK_SECTION structures, like the ones shown below:

>>> dt("HPAK_SECTION")
'HPAK_SECTION' (224 bytes)
0x0   : Header                         ['String', {'length': 32}]
0x8c  : Compressed                     ['unsigned int']
0x98  : Length                         ['unsigned long long']
0xa8  : Offset                         ['unsigned long long']
0xb0  : NextSection                    ['unsigned long long']
0xd4  : Name                           ['String', {'length': 12}]

The Header field (a string) will be "HPAKSECTHPAK_SECTION_PHYSDUMP" for the section containing physical memory. It will be "HPAKSECTHPAK_SECTION_PAGEDUMP" for the section containing the target system's pagefile. The Name field (also a string) identifies the actual name of the embedded file (i.e. pagefile.sys). If Compressed is non-zero, then the section's data (located at offset Offset and of length Length) is compressed with gzip.

It it important to note that no reverse engineering of FDPro.exe or Responder was required to build this address space - the hpak file format was simple enough to explore with a hex editor and derive the meaning of the fields. In fact, the entire process of looking at an hpak file and writing the Volatility address space took less than an hour!

Metadata

To extract metadata from hpak files, you can use the hpakinfo plugin. Here's example output of a file containing the physical memory and pagefile:

$ python vol.py -f memdump.hpak hpakinfo
Header:     HPAKSECTHPAK_SECTION_PHYSDUMP
Length:     0x20000000
Offset:     0x4f8
NextOffset: 0x200004f8
Name:       memdump.bin
Compressed: 0

Header:     HPAKSECTHPAK_SECTION_PAGEDUMP
Length:     0x30000000
Offset:     0x200009d0
NextOffset: 0x500009d0
Name:       dumpfile.sys
Compressed: 0

If you have an hpak file whose Compressed field is non-zero, then its advisable to use the hpakextract plugin to extract the raw physical memory sample to a separate file. You can then analyze the raw memory in Volatility or any other tool that supports raw memory dumps (nearly all of them do).

Conclusion

Volatility is built to perform thorough and advanced memory forensics. That's not possible if the memory dump is in a proprietary format that tools don't understand. Thus one of our side goals is to be as flexible as possible and support any and all formats that our users are likely to come across sometime in their jobs.