Re: [Vol-users] Windows Server 2008

Troy, see with any of these approaches. < I will address at present only the first method, using LiveKd to acquire memory from the root OS. As we know, sophisticated malware can jump out of common VM's to the root partition. So you have to be certain that the root partition is clean before you can reliably acquire memory from the other partitions. LiveKd does produce a nice clean dump in MS crashdump format. However, the method does have a few disadvantages of which readers should be aware. The first disadvantage, as Aaron has already noted, is that LiveKd requires that you have Windbg installed. Readers of the list who are required to follow a forensic methodology may find that objectionable. However, more importantly, LiveKd essentially attaches a debugger to the system. Attaching a debugger to a contemporary version of Windows makes some significant changes to the operating system. For example, the values of nt!KdDebuggerEnabled and nt!KdDebuggerNotPresent are changed. On x64 systems the nt!KdDebuggerDataBlock is decoded and important operating system components (e.g. Patchguard) are disabled. A lot of contemporary malware will monitor the values of nt!KdDebuggerEnabled and/or nt!KdDebuggerNotPresent and either change behavior or melt when a debugger is present. A third problem is that LiveKd (like most memory forensic acquisition tools) only acquires physical memory within the OS physical memory map. It is relatively trivial, using undocumented but exported OS API's, to remove memory from the physical memory map so that the critical evidence is never acquired for analysis by most contemporary memory forensic acquisition tools. Also, some important memory artifacts may be found outside of the physical memory map even in the absence of more advanced hiding techniques. For example, the real mode interrupt vector table is located outside of the physical memory map. When BIOS or bootkits load, they typically copy some real mode code to the top of real mode memory in an area that is outside of the physical memory map. It is true that most bootkits today will attempt to remove those artifacts. However, as is often the case, installing the malicious code and then removing it is not the same as never having installed the code at all. Subtle changes remain which may be your only indication that you need to investigate this system further. The ACPI tables are not part of the physical memory map. NVRAM is not part of the physical memory map. Processor MSR registers and IOAPIC are not part of the physical memory map. Yet they both can be used to alter the flow of execution. Michael may wish to believe that this additional information "may be irrelevant for many investigations." http://lists.volatilityfoundation.org/pipermail/vol-users/2012-March/000350…. However, those are the cases that bite you in the ass. There is no magic bullet. Every investigative method has its advantages and disadvantages. However, whatever method you choose, it is important to understand how the method may affect the outcome of the investigation. At GMG Systems, we generally adopt the philosophy that more evidence is better than less. If you acquire enough evidence you are free to disregard some of it if you do not believe it pertinent to the current investigation. You still can come back to it later when you realize that you may have made a mistake. If you do not acquire some evidence, that pretty much limits your options for the future. Whatever method you choose, the "bad guys" will find out about it and look for its weaknesses. That is one reason why it is important to properly test your tools: So you are not the only one who does not know what those weaknesses are. When the operating system creates a memory dump it saves the current processor state to Pcr->Prcb.ProcessorState. The debug engine (i.e. Windbg) reads a value from that processor state to determine the segmentation (16-bit real mode, 32-bit or 64-bit proteccted mode) of the memory dump. We don't want to write anything to Pcr->Prcb.ProcessorState because we make a forensic tool and the information that would be overwritten might be relevant to some investigation. For example, it might contain the state from the last time the system hibernated. Most often though it just contains zeroes, which makes Windbg think that this is a 16-bit real mode memory dump. The irony is that Windbg uses a 64-bit linear address to look up Pcr->Prcb.ProcessorState. So it already knows that this is not a 16-bit memory dump (like that is ever going to happen on a contemporary version of Windows). Until the latest version of Windbg there was no way to tell Windbg that it had made a mistake (aside from attaching another instance of Windbg and stuffing values into the debug engine. But now we can. Think in terms of days, not weeks. Regards, George.