You can use the devicetree plugin in Volatility to display the device tree in the same format as the DeviceTree tool. The following highlighted entries show the device stack of HarddiskVolume1 that is associated with volmgr.sys:

$ python vol.py -f win7_x86.vmem --profile=Win7SP1x86 devicetree

DRV 0x05329db8 \Driver\WMIxWDM
---| DEV 0x85729a38 WMIAdminDevice FILE_DEVICE_UNKNOWN
---| DEV 0x85729b60 WMIDataDevice FILE_DEVICE_UNKNOWN
[REMOVED]

DRV 0xbf2e0bd8 \Driver\volmgr
---| DEV 0x868e7e20 HarddiskVolume1 FILE_DEVICE_DISK
------| ATT 0x868e7b28 - \Driver\fvevol FILE_DEVICE_DISK
---------| ATT 0x868e78c0 - \Driver\rdyboost FILE_DEVICE_DISK
------------| ATT 0x85707658 - \Driver\volsnap FILE_DEVICE_DISK
[REMOVED]

To help you understand the use of the devicetree plugin in forensic investigation, let's take a look at a malware which creates its own device to store its malicious binary. In the following example of the ZeroAccess rootkit, I have used the cmdline plugin, which displays process command-line arguments. This can be useful in determining the full path of a process (you can also use the dlllist plugin). From the output, you can see that the last svchost.exe process is running from a suspicious namespace:

svchost.exe pid: 624
Command line : C:\Windows\system32\svchost.exe -k DcomLaunch
svchost.exe pid: 712
Command line : C:\Windows\system32\svchost.exe -k RPCSS
svchost.exe pid: 764
Command line : C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted
svchost.exe pid: 876
Command line : C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted
[REMOVED]

svchost.exe pid: 1096
Command line : "\\.\globalroot\Device\svchost.exe\svchost.exe"

From the earlier discussion, if you remember, \\.\<symbolic link name> is the convention used to access a device from the user-mode using the name of the symbolic link. When a driver creates a symbolic link for the device, it is added to the \GLOBAL?? directory in the object manager namespace (which can be viewed using the WinObj tool, as we discussed earlier). In this case, globalroot is the name of the symbolic link. Then, the question is, what is \\.\globalroot? It turns out that \\.\globalroot refers to the \GLOBAL?? namespace. In other words, the \\.\globalroot\Device\svchost.exe\svchost.exe path is the same as \Device\svchost.exe\svchost.exe. At this stage, you know that the ZeroAccess rootkit creates its own device (svchost.exe) to hide its malicious binary, svchost.exe. To identify the driver which created this device, you can use the devicetree plugin. From the following output, you can tell that the svchost.exe device was created by the 00015300.sys driver:

$ python vol.py -f zaccess1.vmem --profile=Win7SP1x86 devicetree
[REMOVED]
DRV 0x1fc84478 \Driver\00015300
---| DEV 0x84ffbf08 svchost.exe FILE_DEVICE_DISK

In the following example of BlackEnergy malware, it replaces the legitimate aliide.sys driver on the disk with the malicious driver to hijack the existing service (as covered in Chapter 10, Hunting Malware Using Memory Forensics, in the Investigating Service section). When the service starts, the malicious driver creates a device to communicate with the malicious user-mode component (DLL injected into the legitimate svchost.exe) process. The following devicetree output shows the device created by the malicious driver:

$ python vol.py -f be3_big_restart.vmem --profile=Win7SP1x64 devicetree | grep -i aliide -A1
Volatility Foundation Volatility Framework 2.6
DRV 0x1e45fbe0 \Driver\aliide
---| DEV 0xfffffa8008670e40 {C9059FFF-1C49-4445-83E8-4F16387C3800} FILE_DEVICE_UNKNOWN

To get an idea of the type of operations supported by the malicious driver. You can use Volatility's driverirp plugin, since it displays the major IRP functions associated with a particular driver or all the drivers. From the following output, you can tell that the malicious aliide driver supports IRP_MJ_CREATE (open), IRP_MJ_CLOSE (close), and the IRP_MJ_DEVICE_CONTROL (DeviceIoControl) operations. The operations that are not supported by the driver typically point to IopInvalidDeviceRequest in the ntoskrnl.exe, which is the reason you are seeing all other non-supported operations pointing to 0xfffff80002a5865c in ntoskrnl.exe:

$ python vol.py -f be3_big_restart.vmem --profile=Win7SP1x64 driverirp -r aliide
Volatility Foundation Volatility Framework 2.6
--------------------------------------------------
DriverName: aliide
DriverStart: 0xfffff88003e1d000
DriverSize: 0x14000
DriverStartIo: 0x0
   0 IRP_MJ_CREATE                  0xfffff88003e1e160 aliide.sys
   1 IRP_MJ_CREATE_NAMED_PIPE       0xfffff80002a5865c ntoskrnl.exe
   2 IRP_MJ_CLOSE                   0xfffff88003e1e160 aliide.sys
   3 IRP_MJ_READ                    0xfffff80002a5865c ntoskrnl.exe
   4 IRP_MJ_WRITE                   0xfffff80002a5865c ntoskrnl.exe
  [REMOVED]
  12 IRP_MJ_DIRECTORY_CONTROL       0xfffff80002a5865c ntoskrnl.exe
  13 IRP_MJ_FILE_SYSTEM_CONTROL     0xfffff80002a5865c ntoskrnl.exe
  14 IRP_MJ_DEVICE_CONTROL          0xfffff88003e1e160 aliide.sys
  15 IRP_MJ_INTERNAL_DEVICE_CONTROL 0xfffff80002a5865c ntoskrnl.exe
  [REMOVED]