In the instances where caching is being provided, the SharedCacheMap member of the _SECTION_OBJECT_POINTERS structure is an opaque pointer to the SHARED_CACHE_MAP structure. The SHARED_CACHE_MAP structure is used by the Cache Manager to track the state of cached regions, including the previously described 256-KB VACBs.  The cache manger uses a VACB index arrays to store pointers to the VACBs. As a performance optimizations, the _SHARED_CACHE_MAP contains a VACB index array, InitialVacbs, of 4 pointers, that is used for files 1 MB or less in size. If the file is larger than 1 MB, the Vacbs member of _SHARED_CACHE_MAP is used to store a pointer to a dynamically allocated VACB index array.  If the file is larger than 32 MB, a sparse multilevel index array is created where each index array can hold up to 128 entries. Since we are trying to find all the cached regions that may be memory resident, we recursively walk the sparse multilevel array looking for file data.  The _VACB contains the virtual address of where the data is stored in system cache, BaseAddress,  and the offset where the data is found within the file, FileOffset.  Using this information, we can reconstruct the file based on the cached regions found in memory.
Prior Research While some recent research made the assertion that the Windows Cache Manager had been largely ignored in memory forensics, this statement was a bit disingenuous.  In fact, there have been a number of research papers and projects that have demonstrated the importance of extracting files (memory mapped/cached) from physical memory.  The first to explore this issue was R.B. van Baar in 2008, when he published a paper, "Forensic memory analysis: Files mapped in memory", in which he showed that 25% of data in memory dumps was attributed to memory mapped files.  He also discussed a number of techniques for extracting file artifacts using both allocated file mappings and unallocated pages. While the paper did not detail the algorithms used in the analysis, we remembered, that Ruud had submitted the code for inclusion in Volatility back in 2008. Looking though the code, we noticed that he focused on a subset of PTEs found when traversing the DataSectionObject. Later that year, a team lead by Seyed Mahmood Hejazi also wrote a paper titled, "Automated Windows Memory File Extraction for Cyber Forensics Investigations", which also discussed the benefits of extracting memory mapped and cached files. Unfortunately, some discrepancies in their pseudo code and images made it difficult to replicate their research.  Their analysis of cached files also seemed to be limited to files that were small enough to be found in the InitialVacbs (1 MB).   In 2010, Carl Pulley created a Volatility plugin, exportfile, for extracting both memory mapped and cached file artifacts that he used to solve the Honeynet Project Challenge 3. In particular, he demonstrated how PDFs and Firefox artifacts could be extracted from physical memory. This was a major step forward as he was the first to actually release code that others could use and evaluate. Thus, we wanted to see if we could augment Carl's work to support PAE kernels and x64 (Shoutz to Carl!). Finally in 2011, another research team re-implemented Carl's work for a Black Hat presentation titled, "Physical Memory Forensics for Files and Cache". The work presented lacked sufficient detail or code to evaluate the effectiveness of their approach. They also demonstrated a clear lack of understanding in a number of their claims. The DumpFiles Plugin The DumpFiles Plugin works by collecting _FILE_OBJECTS from both the handle table and virtual address descriptor tree. Once those objects have been collected, it will proceed to extract all memory mapped and cached regions to a specified output directory. Typical command line usage: $ python vol.py dumpfiles -f <sample> --dump-dir <filesdir>  -S <summaryfile> --profile=<Profile>  This will create a number of extracted file artifacts in the output directory.  These files are named with the following schema: (file.$PID.[SharedCacheMap.offset|ControlArea.offset].[img|dat|vacb]). The goal of the naming schema is to help provide provenance as to where the data originated. Example output names can be seen below: file.1300.0x8704e540.img file.2648.0x868b58e0.vacb file.436.0x8a06ace8.dat It will also create a detailed summary file describing which pages where actually present and which were paged out and subsequently padded with the output file.