Volatility, my own cheatsheet (Part 4): Kernel Memory and Objects
Let’s go down a bit more deeply in the system, and let’s go to find kernel modules into the memory dump.
modules
To view the list of kernel drivers loaded on the system, use the modules command. This walks the doubly-linked list of LDR_DATA_TABLE_ENTRY structures pointed to by PsLoadedModuleList.
Similar to the pslist command, this relies on finding the KDBG structure. In rare cases, you may need to use kdbgscan to find the most appropriate KDBG structure address and then supply it to this plugin like — kdbg=ADDRESS.
It cannot find hidden/unlinked kernel drivers, however modscan serves that purpose. Also, since this plugin uses list walking techniques, you typically can assume that the order the modules are displayed in the output is the order they were loaded on the system. For example, below, ntoskrnl.exe was first to load, followed by hal.dll, etc.
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 modules
Volatility Foundation Volatility Framework 2.4
Offset(V) Name Base Size File
------------------ -------------------- ------------------ ------------------ ----
0xfffffa80004a11a0 ntoskrnl.exe 0xfffff8000261a000 0x5dd000 \SystemRoot\system32\ntoskrnl.exe
0xfffffa80004a10b0 hal.dll 0xfffff80002bf7000 0x49000 \SystemRoot\system32\hal.dll
0xfffffa80004a7950 kdcom.dll 0xfffff80000bb4000 0xa000 \SystemRoot\system32\kdcom.dll
0xfffffa80004a7860 mcupdate.dll 0xfffff88000c3a000 0x44000 \SystemRoot\system32\mcupdate_GenuineIntel.dll
0xfffffa80004a7780 PSHED.dll 0xfffff88000c7e000 0x14000 \SystemRoot\system32\PSHED.dll
0xfffffa80004a7690 CLFS.SYS 0xfffff88000c92000 0x5e000 \SystemRoot\system32\CLFS.SYS
0xfffffa80004a8010 CI.dll 0xfffff88000cf0000 0xc0000 \SystemRoot\system32\CI.dll
[snip]The output shows the offset of the LDR_DATA_TABLE_ENTRYstructure, which is a virtual address by default but can be specified as a physical address with the -P switch as shown below. In either case, the Base column is the virtual address of the module’s base in kernel memory (where you’d expect to find the PE header).
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 modules -P
Volatility Foundation Volatility Framework 2.4
Offset(P) Name Base Size File
------------------ -------------------- ------------------ ------------------ ----
0x0000000017fe01a0 ntoskrnl.exe 0xfffff8000261a000 0x5dd000 \SystemRoot\system32\ntoskrnl.exe
0x0000000017fe00b0 hal.dll 0xfffff80002bf7000 0x49000 \SystemRoot\system32\hal.dll
0x0000000017fe6950 kdcom.dll 0xfffff80000bb4000 0xa000 \SystemRoot\system32\kdcom.dll
0x0000000017fe6860 mcupdate.dll 0xfffff88000c3a000 0x44000 \SystemRoot\system32\mcupdate_GenuineIntel.dll
0x0000000017fe6780 PSHED.dll 0xfffff88000c7e000 0x14000 \SystemRoot\system32\PSHED.dll
0x0000000017fe6690 CLFS.SYS 0xfffff88000c92000 0x5e000 \SystemRoot\system32\CLFS.SYS
0x0000000017fe7010 CI.dll 0xfffff88000cf0000 0xc0000 \SystemRoot\system32\CI.dll
[snip]modscan
The modscan command finds LDR_DATA_TABLE_ENTRYstructures by scanning physical memory for pool tags. This can pick up previously unloaded drivers and drivers that have been hidden/unlinked by rootkits. Unlike modules the order of results has no relationship with the order in which the drivers loaded. As you can see below, DumpIt.sys was found at the lowest physical offset, but it was probably one of the last drivers to load (since it was used to acquire memory).
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 modscan
Volatility Foundation Volatility Framework 2.4
Offset(P) Name Base Size File
------------------ -------------------- ------------------ ------------------ ----
0x00000000173b90b0 DumpIt.sys 0xfffff88003980000 0x11000 \??\C:\Windows\SysWOW64\Drivers\DumpIt.sys
0x000000001745b180 mouhid.sys 0xfffff880037e9000 0xd000 \SystemRoot\system32\DRIVERS\mouhid.sys
0x0000000017473010 lltdio.sys 0xfffff88002585000 0x15000 \SystemRoot\system32\DRIVERS\lltdio.sys
0x000000001747f010 rspndr.sys 0xfffff8800259a000 0x18000 \SystemRoot\system32\DRIVERS\rspndr.sys
0x00000000174cac40 dxg.sys 0xfffff96000440000 0x1e000 \SystemRoot\System32\drivers\dxg.sys
0x0000000017600190 monitor.sys 0xfffff8800360c000 0xe000 \SystemRoot\system32\DRIVERS\monitor.sys
0x0000000017601170 HIDPARSE.SYS 0xfffff880037de000 0x9000 \SystemRoot\system32\DRIVERS\HIDPARSE.SYS
0x0000000017604180 USBD.SYS 0xfffff880037e7000 0x2000 \SystemRoot\system32\DRIVERS\USBD.SYS
0x0000000017611d70 cdrom.sys 0xfffff88001944000 0x2a000 \SystemRoot\system32\DRIVERS\cdrom.sys
[snip]moddump
To extract a kernel driver to a file, use the moddump command. Supply the output directory with -D or — dump-dir=DIR. Without any additional parameters, all drivers identified by modlist will be dumped. If you want a specific driver, supply a regular expression of the driver’s name with — regex=REGEX or the module’s base address with — base=BASE.
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 moddump -D drivers/
Volatility Foundation Volatility Framework 2.4
Module Base Module Name Result
------------------ -------------------- ------
0xfffff8000261a000 ntoskrnl.exe OK: driver.fffff8000261a000.sys
0xfffff80002bf7000 hal.dll OK: driver.fffff80002bf7000.sys
0xfffff88000e5c000 intelide.sys OK: driver.fffff88000e5c000.sys
0xfffff8800349b000 mouclass.sys OK: driver.fffff8800349b000.sys
0xfffff88000f7c000 msisadrv.sys OK: driver.fffff88000f7c000.sys
0xfffff880035c3000 ndistapi.sys OK: driver.fffff880035c3000.sys
0xfffff88002c5d000 pacer.sys OK: driver.fffff88002c5d000.sys
[snip]For more information:
Similar to dlldump, if critical parts of the PE header are not memory resident, then rebuilding/extracting the driver may fail. Additionally, for drivers that are mapped in different sessions (like win32k.sys), there is currently no way to specify which session to use when acquiring the driver sample.
ssdt
To list the functions in the Native and GUI SSDTs, use the ssdt command. This displays the index, function name, and owning driver for each entry in the SSDT. Please note the following:
- Windows has 4 SSDTs by default (you can add more with KeAddSystemServiceTable), but only 2 of them are used — one for Native functions in the NT module, and one for GUI functions in the win32k.sys module.
- There are multiple ways to locate the SSDTs in memory. Most tools do it by finding the exported KeServiceDescriptorTable symbol in the NT module, but this is not the way Volatility works.
- For x86 systems, Volatility scans for ETHREAD objects and gathers all unique ETHREAD.Tcb.ServiceTable pointers. This method is more robust and complete, because it can detect when rootkits make copies of the existing SSDTs and assign them to particular threads. Also see the threads command.
- For x64 systems (which do not have an ETHREAD.Tcb.ServiceTable member) Volatility disassembles code in ntKeAddSystemServiceTable and finds its references to the KeServiceDescriptorTable and KeServiceDescriptorTableShadow symbols.
- The order and total number of functions in the SSDTs differ across operating system versions. Thus, Volatility stores the information in a per-profile (OS) dictionary which is auto-generated and cross-referenced using the ntoskrnl.exe, ntdll.dll, win32k.sys, user32.dll and gdi32.dll modules from the respective systems.
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 ssdt
Volatility Foundation Volatility Framework 2.4
[x64] Gathering all referenced SSDTs from KeAddSystemServiceTable...
Finding appropriate address space for tables...
SSDT[0] at fffff8000268cb00 with 401 entries
Entry 0x0000: 0xfffff80002a9d190 (NtMapUserPhysicalPagesScatter) owned by ntoskrnl.exe
Entry 0x0001: 0xfffff80002983a00 (NtWaitForSingleObject) owned by ntoskrnl.exe
Entry 0x0002: 0xfffff80002683dd0 (NtCallbackReturn) owned by ntoskrnl.exe
Entry 0x0003: 0xfffff800029a6b10 (NtReadFile) owned by ntoskrnl.exe
Entry 0x0004: 0xfffff800029a4bb0 (NtDeviceIoControlFile) owned by ntoskrnl.exe
Entry 0x0005: 0xfffff8000299fee0 (NtWriteFile) owned by ntoskrnl.exe
Entry 0x0006: 0xfffff80002945dc0 (NtRemoveIoCompletion) owned by ntoskrnl.exe
Entry 0x0007: 0xfffff80002942f10 (NtReleaseSemaphore) owned by ntoskrnl.exe
Entry 0x0008: 0xfffff8000299ada0 (NtReplyWaitReceivePort) owned by ntoskrnl.exe
Entry 0x0009: 0xfffff80002a6ce20 (NtReplyPort) owned by ntoskrnl.exe
[snip]
SSDT[1] at fffff96000101c00 with 827 entries
Entry 0x1000: 0xfffff960000f5580 (NtUserGetThreadState) owned by win32k.sys
Entry 0x1001: 0xfffff960000f2630 (NtUserPeekMessage) owned by win32k.sys
Entry 0x1002: 0xfffff96000103c6c (NtUserCallOneParam) owned by win32k.sys
Entry 0x1003: 0xfffff96000111dd0 (NtUserGetKeyState) owned by win32k.sys
Entry 0x1004: 0xfffff9600010b1ac (NtUserInvalidateRect) owned by win32k.sys
Entry 0x1005: 0xfffff96000103e70 (NtUserCallNoParam) owned by win32k.sys
Entry 0x1006: 0xfffff960000fb5a0 (NtUserGetMessage) owned by win32k.sys
Entry 0x1007: 0xfffff960000dfbec (NtUserMessageCall) owned by win32k.sys
Entry 0x1008: 0xfffff960001056c4 (NtGdiBitBlt) owned by win32k.sys
Entry 0x1009: 0xfffff960001fd750 (NtGdiGetCharSet) owned by win32k.sysFor more information:
To filter all functions which point to ntoskrnl.exe and win32k.sys, you can use egrep on command-line. This will only show hooked SSDT functions.
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 ssdt | egrep -v '(ntos|win32k)'Note that the NT module on your system may be ntkrnlpa.exe or ntkrnlmp.exe — so check that before using egrep of you’ll be filtering the wrong module name. Also be aware that this isn’t a hardened technique for finding hooks, as malware can load a driver named win32ktesting.sys and bypass your filter.
driverscan
To find DRIVER_OBJECTs in physical memory using pool tag scanning, use the driverscan command. This is another way to locate kernel modules, although not all kernel modules have an associated DRIVER_OBJECT. The DRIVER_OBJECT is what contains the 28 IRP (Major Function) tables, thus the driverirp command is based on the methodology used by driverscan.
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 driverscan
Volatility Foundation Volatility Framework 2.4
Offset(P) #Ptr #Hnd Start Size Service Key Name Driver Name
------------------ ---- ---- ------------------ ------------------ -------------------- ------------ -----------
0x00000000174c6350 3 0 0xfffff880037e9000 0xd000 mouhid mouhid \Driver\mouhid
0x0000000017660cb0 3 0 0xfffff8800259a000 0x18000 rspndr rspndr \Driver\rspndr
0x0000000017663e70 3 0 0xfffff88002585000 0x15000 lltdio lltdio \Driver\lltdio
0x0000000017691d70 3 0 0xfffff88001944000 0x2a000 cdrom cdrom \Driver\cdrom
0x0000000017692a50 3 0 0xfffff8800196e000 0x9000 Null Null \Driver\Null
0x0000000017695e70 3 0 0xfffff88001977000 0x7000 Beep Beep \Driver\Beep
0x00000000176965c0 3 0 0xfffff8800197e000 0xe000 VgaSave VgaSave \Driver\VgaSave
0x000000001769fb00 4 0 0xfffff880019c1000 0x9000 RDPCDD RDPCDD \Driver\RDPCDD
0x00000000176a1720 3 0 0xfffff880019ca000 0x9000 RDPENCDD RDPENCDD \Driver\RDPENCDD
0x00000000176a2230 3 0 0xfffff880019d3000 0x9000 RDPREFMP RDPREFMP \Driver\RDPREFMP
[snip]For more information:
filescan
To find FILE_OBJECTs in physical memory using pool tag scanning, use the filescan command. This will find open files even if a rootkit is hiding the files on disk and if the rootkit hooks some API functions to hide the open handles on a live system. The output shows the physical offset of the FILE_OBJECT, file name, number of pointers to the object, number of handles to the object, and the effective permissions granted to the object.
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 filescan
Volatility Foundation Volatility Framework 2.4
Offset(P) #Ptr #Hnd Access Name
------------------ ------ ------ ------ ----
0x000000000126f3a0 14 0 R--r-d \Windows\System32\mswsock.dll
0x000000000126fdc0 11 0 R--r-d \Windows\System32\ssdpsrv.dll
0x000000000468f7e0 6 0 R--r-d \Windows\System32\cryptsp.dll
0x000000000468fdc0 16 0 R--r-d \Windows\System32\Apphlpdm.dll
0x00000000048223a0 1 1 ------ \Endpoint
0x0000000004822a30 16 0 R--r-d \Windows\System32\kerberos.dll
0x0000000004906070 13 0 R--r-d \Windows\System32\wbem\repdrvfs.dll
0x0000000004906580 9 0 R--r-d \Windows\SysWOW64\netprofm.dll
0x0000000004906bf0 9 0 R--r-d \Windows\System32\wbem\wmiutils.dll
0x00000000049ce8e0 2 1 R--rwd \$Extend\$ObjId
0x00000000049cedd0 1 1 R--r-d \Windows\System32\en-US\vsstrace.dll.mui
0x0000000004a71070 17 1 R--r-d \Windows\System32\en-US\pnidui.dll.mui
0x0000000004a71440 11 0 R--r-d \Windows\System32\nci.dll
0x0000000004a719c0 1 1 ------ \srvsvc
[snip]For more information
mutantscan
To scan physical memory for KMUTANT objects with pool tag scanning, use the mutantscan command. By default, it displays all objects, but you can pass -s or — silent to only show named mutexes. The CID column contains the process ID and thread ID of the mutex owner if one exists.
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 mutantscan --silent
Volatility Foundation Volatility Framework 2.4
Offset(P) #Ptr #Hnd Signal Thread CID Name
------------------ ---- ---- ------ ------------------ --------- ----
0x000000000f702630 2 1 1 0x0000000000000000 {A3BD3259-3E4F-428a-84C8-F0463A9D3EB5}
0x00000000102fd930 2 1 1 0x0000000000000000 Feed Arbitration Shared Memory Mutex [ User : S-1-5-21-2628989162-3383567662-1028919141-1000 ]
0x00000000104e5e60 3 2 1 0x0000000000000000 ZoneAttributeCacheCounterMutex
0x0000000010c29e40 2 1 1 0x0000000000000000 _MSFTHISTORY_LOW_
0x0000000013035080 2 1 1 0x0000000000000000 c:userstestingappdatalocalmicrosoftfeeds cache
0x000000001722dfc0 2 1 1 0x0000000000000000 c:userstestingappdataroamingmicrosoftwindowsietldcachelow
0x00000000172497f0 2 1 1 0x0000000000000000 LRIEElevationPolicyMutex
0x000000001724bfc0 3 2 1 0x0000000000000000 BrowserEmulationSharedMemoryMutex
0x000000001724f400 2 1 1 0x0000000000000000 c:userstestingappdatalocalmicrosoftwindowshistorylowhistory.ie5mshist012012022220120223
0x000000001724f4c0 4 3 1 0x0000000000000000 _SHMSFTHISTORY_
0x00000000172517c0 2 1 1 0x0000000000000000 __DDrawExclMode__
0x00000000172783a0 2 1 1 0x0000000000000000 Lowhttp://sourceforge.net/
0x00000000172db840 4 3 1 0x0000000000000000 ConnHashTable<1892>_HashTable_Mutex
0x00000000172de1d0 2 1 1 0x0000000000000000 Feeds Store Mutex S-1-5-21-2628989162-3383567662-1028919141-1000
0x00000000173b8080 2 1 1 0x0000000000000000 DDrawDriverObjectListMutex
0x00000000173bd340 2 1 0 0xfffffa8000a216d0 1652:2000 ALTTAB_RUNNING_MUTEX
0x0000000017449c40 2 1 1 0x0000000000000000 DDrawWindowListMutex
[snip]For more information:
symlinkscan
This plugin scans for symbolic link objects and outputs their information. In the past, this has been used to link drive letters (i.e. D:, E:, F:, etc) to true crypt volumes (i.e. \Device\TrueCryptVolume).
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 symlinkscan
Volatility Foundation Volatility Framework 2.4
Offset(P) #Ptr #Hnd Creation time From To
------------------ ------ ------ ------------------------ -------------------- ------------------------------------------------------------
0x0000000000469780 1 0 2012-02-22 20:03:13 UMB#UMB#1...e1ba19f} \Device\00000048
0x0000000000754560 1 0 2012-02-22 20:03:15 ASYNCMAC \Device\ASYNCMAC
0x0000000000ef6cf0 2 1 2012-02-22 19:58:24 0 \BaseNamedObjects
0x00000000014b2a10 1 0 2012-02-22 20:02:10 LanmanRedirector \Device\Mup\;LanmanRedirector
0x00000000053e56f0 1 0 2012-02-22 20:03:15 SW#{eeab7...abac361} \Device\KSENUM#00000001
0x0000000005cc0770 1 0 2012-02-22 19:58:20 WanArpV6 \Device\WANARPV6
0x0000000005cc0820 1 0 2012-02-22 19:58:20 WanArp \Device\WANARP
0x0000000008ffa680 1 0 2012-02-22 19:58:24 Global \BaseNamedObjects
0x0000000009594810 1 0 2012-02-22 19:58:24 KnownDllPath C:\Windows\syswow64
0x000000000968f5f0 1 0 2012-02-22 19:58:23 KnownDllPath C:\Windows\system32
0x000000000ab24060 1 0 2012-02-22 19:58:20 Volume{3b...f6e6963} \Device\CdRom0
0x000000000ab24220 1 0 2012-02-22 19:58:21 {EE0434CC...863ACC2} \Device\NDMP2
0x000000000abd3460 1 0 2012-02-22 19:58:21 ACPI#PNP0...91405dd} \Device\00000041
0x000000000abd36f0 1 0 2012-02-22 19:58:21 {802389A0...A90C31A} \Device\NDMP3
[snip]For more information:
thrdscan
To find ETHREAD objects in physical memory with pool tag scanning, use the thrdscan command. Since an ETHREAD contains fields that identify its parent process, you can use this technique to find hidden processes. One such use case is documented in the psxview command. Also, for verbose details, try the threads plugin.
$ vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 thrdscan
Volatility Foundation Volatility Framework 2.4
Offset(P) PID TID Start Address Create Time Exit Time
------------------ ------ ------ ------------------ ------------------------- -------------------------
0x0000000008df68d0 280 392 0x77943260 2012-02-22 19:08:18
0x000000000eac3850 2040 144 0x76d73260 2012-02-22 11:28:59 2012-02-22 11:29:04
0x000000000fd82590 880 1944 0x76d73260 2012-02-22 20:02:29 2012-02-22 20:02:29
0x00000000103d15f0 880 884 0x76d73260 2012-02-22 19:58:43
0x00000000103e5480 1652 1788 0xfffff8a0010ed490 2012-02-22 20:03:44
0x00000000105a3940 916 324 0x76d73260 2012-02-22 20:02:07 2012-02-22 20:02:09
0x00000000105b3560 816 824 0x76d73260 2012-02-22 19:58:42
0x00000000106d1710 916 1228 0x76d73260 2012-02-22 20:02:11
0x0000000010a349a0 816 820 0x76d73260 2012-02-22 19:58:41
0x0000000010bd1060 1892 2280 0x76d73260 2012-02-22 11:26:13
0x0000000010f24230 628 660 0x76d73260 2012-02-22 19:58:34
0x0000000010f27060 568 648 0xfffff8a0017c6650 2012-02-22 19:58:34
[snip]dumpfiles
An important concept that every computer scientist, especially those who have spent time doing operating system research, is intimately familiar with is that of caching. Files are cached in memory for system performance as they are accessed and used. This makes the cache a valuable source from a forensic perspective since we are able to retrieve files that were in use correctly, instead of file carving which does not make use of how items are mapped in memory. Files may not be completely mapped in memory (also for performance), so missing sections are zero padded. Files dumped from memory can then be processed with external tools.
For more information:
There are several options in the dumpfiles plugin, for example:
-r REGEX, --regex=REGEX
Dump files matching REGEX
-i, --ignore-case Ignore case in pattern match
-o OFFSET, --offset=OFFSET
Dump files for Process with physical address OFFSET
-Q PHYSOFFSET, --physoffset=PHYSOFFSET
Dump File Object at physical address PHYSOFFSET
-D DUMP_DIR, --dump-dir=DUMP_DIR
Directory in which to dump extracted files
-S SUMMARY_FILE, --summary-file=SUMMARY_FILE
File where to store summary information
-p PID, --pid=PID Operate on these Process IDs (comma-separated)
-n, --name Include extracted filename in output file path
-u, --unsafe Relax safety constraints for more data
-F FILTER, --filter=FILTER
Filters to apply (comma-separated)By default, dumpfiles iterates through the VAD and extracts all files that are mapped as DataSectionObject, ImageSectionObject or SharedCacheMap. As an investigator, however, you may want to perform a more targeted search. You can use the -r and -i flags to specify a case-insensitive regex of a filename. In the output below, you can see where the file was dumped from (DataSectionObject, ImageSectionObject or SharedCacheMap), the offset of the _FILE_OBJECT, the PID of the process whose VAD contained the file and the file path on disk:
$ vol.py -f mebromi.raw dumpfiles -D output/ -r evt$ -i -S summary.txt
Volatility Foundation Volatility Framework 2.4
DataSectionObject 0x81ed6240 684 \Device\HarddiskVolume1\WINDOWS\system32\config\AppEvent.Evt
SharedCacheMap 0x81ed6240 684 \Device\HarddiskVolume1\WINDOWS\system32\config\AppEvent.Evt
DataSectionObject 0x8217beb0 684 \Device\HarddiskVolume1\WINDOWS\system32\config\SecEvent.Evt
DataSectionObject 0x8217bd78 684 \Device\HarddiskVolume1\WINDOWS\system32\config\SysEvent.Evt
SharedCacheMap 0x8217bd78 684 \Device\HarddiskVolume1\WINDOWS\system32\config\SysEvent.Evt$ ls output/
file.684.0x81fc6ed0.vacb file.684.0x82256a48.dat file.684.0x82256e48.dat file.None.0x82339cd8.vacb
file.684.0x8217b720.vacb file.684.0x82256c50.dat file.None.0x82339c70.datThe dumped filename is in the format of:
file.[PID].[OFFSET].ext
The OFFSET is the offset of the SharedCacheMap or the _CONTROL_AREA, not the _FILE_OBJECT.
The extension (EXT) can be:
- img —
ImageSectionObject - dat —
DataSectionObject - vacb —
SharedCacheMap
You can look at the -S/--summary-file in order to map the file back to its original filename:
{"name": "\\Device\\HarddiskVolume1\\WINDOWS\\system32\\config\\AppEvent.Evt", "ofpath": "dumpfiles/file.684.0x82256e48.dat", "pid": 684,...You can also use the parsesummary.py script to parse out the json output of the summary file. The following shows an example of using this script. In addition to the original file name, PID of the process that had the file open and size, you can see which pages were present and which pages were missing and padded with zeros in the parsed summary output:
$ vol.py -f grrcon.img dumpfiles --summary=grrcon_summary.json -D output/
Volatility Foundation Volatility Framework 2.4$ python parsesummary.py grrcon_summary.json |less
[snip]
File: \Device\HarddiskVolume1\Documents and Settings\administrator\NTUSER.DAT -> output/file.4.0x82245008.vacb
PID: 4
_FILE_OBJECT offset: 0x821cd9e8
Type: SharedCacheMap
Size: 262144
Present Pages:
Offset(V): 0xde5c0000, Length: 4096
Offset(V): 0xde5c1000, Length: 4096
Offset(V): 0xde5c2000, Length: 4096
Offset(V): 0xde5c3000, Length: 4096
[snip]
Padding:
FileOffset: 0xde62e000 x 0x1000
FileOffset: 0xde62f000 x 0x1000
FileOffset: 0xde630000 x 0x1000
FileOffset: 0xde631000 x 0x1000
FileOffset: 0xde632000 x 0x1000
[snip]Or you can use the -n/--name option in order to dump file the files with the original filename.
Not every file will be currently active or in the VAD, and such files will not be dumped when using the -r/--regex option. For these files you can first scan for a _FILE_OBJECT and then use the -Q/--physoffset flag to extract the file. Special NTFS files are examples of files that must be dumped specifically:
$ vol.py -f mebromi.raw filescan |grep -i mft
Volatility Foundation Volatility Framework 2.4
0x02410900 3 0 RWD--- \Device\HarddiskVolume1\$Mft
0x02539e30 3 0 RWD--- \Device\HarddiskVolume1\$Mft
0x025ac868 3 0 RWD--- \Device\HarddiskVolume1\$MftMirr$ vol.py -f mebromi.raw dumpfiles -D output/ -Q 0x02539e30
Volatility Foundation Volatility Framework 2.4
DataSectionObject 0x02539e30 None \Device\HarddiskVolume1\$Mft
SharedCacheMap 0x02539e30 None \Device\HarddiskVolume1\$MftThe -f/--filter option allows you to specify which view of the file you would like to dump (DataSectionObject, ImageSectionObject or SharedCacheMap). For example, if you wanted to only see the state information for an executable file, you could specify --filter=ImageSectionObject.
unloadedmodules
Windows stores information on recently unloaded drivers for debugging purposes. This gives you an alternative way to determine what happened on a system, besides the well known modules and modscan plugins.
$ vol.py -f win7_trial_64bit.raw unloadedmodules --profile=Win7SP0x64
Volatility Foundation Volatility Framework 2.4
Name StartAddress EndAddress Time
-------------------- ------------------ ------------------ ----
dump_dumpfve.sys 0xfffff88001931000 0xfffff88001944000 2012-02-22 19:58:21
dump_atapi.sys 0xfffff88001928000 0xfffff88001931000 2012-02-22 19:58:21
dump_ataport.sys 0xfffff8800191c000 0xfffff88001928000 2012-02-22 19:58:21
crashdmp.sys 0xfffff8800190e000 0xfffff8800191c000 2012-02-22 19:58:21