**Edit - 9/28/2016 - fixed RegRipper links
I was hoping to have time to write up some formal notes on my research, but unfortunately, I have been tasked with something more urgent. As such, I have to put this quest aside for the time being, but I wanted to make sure I captured a snapshot of where I'm leaving off (to facilitate picking it back up in the near future).
This is a loose, informal capture of the information I've found thus far, and the resources that have been most useful along the way. I realize that I have not correctly documented my references here - this is not meant to be a formal document by any means, just an organization of info for my own purposes (my bookmark manager was quickly becoming unmanageably large). That being said, I thought it may be of some use to others researching these topics.
I have recently been investigating methods for extracting key system information (namely OS version, physical RAM size, and CPU type) from volatile memory. While there are numerous existing tools available (such as volatility) that provide this functionality, they currently do so by parsing an existing image of live memory in search of certain hex signatures to find kernel structures and registry hives that contain these data.
The first such structure is the Kernel Processor Control Structure (KPCR). To quote Brendan Dolan-Gavitt, "The KPCR is a data structure used by the Windows kernel to store information about each processor, and it is located at virtual address 0xffdff000 in XP, 2003, and Vista." (2a)
This led me to wonder - is this structure located in the same offset in Windows 7 and 2008? What about 32-bit vs. 64-bit? I haven't had a chance to answer this question yet, but it looks like it *should* remain static in the newer Windows versions (need to verify).
Furthermore, one of the fields in the KPCR structure points to the _DBGKD_GET_VERSION64 structure, which contains a linked list of _KDDEBUGGER_DATA64 structures (2a). Given the KernBase field of the _KDDEBUGGER_DATA64 structure (at offset 0x18, according to the MS include files), the kernel image can be located. The executable will depend on the number of CPUs in the machine and whether physical address extension (PAE) is enabled (2d):
NTOSKRNL.EXE : 1 CPU
NTKRNLMP.EXE : N CPU
NTKRNLPA.EXE : 1 CPU, PAE
NTKRPAMP.EXE : N CPU PAE
Jamie Levy wrote up an excellent followup to Brendan's post (2b) which enumerated the different Size tags (from the _DBGKD_DEBUG_DATA_HEADER64 struct defined in wdbgext.h) for Windows 2000 through Windows 7/2008, and both x86 and x64 versions. As she also mentions, this OS determination was implemented by Mike Auty and integrated into volatility 1.4 (in the imageinfo.py plugin).
Need to investigate: How does volatility utilize the KPCR offset in imageinfo.py (kpcroffset = volmagic.KPCR.v())? Can this virtual address be mapped to a physical address by finding the kernel page directory table base and mapping according to the method described in section 3.2 of (2c)? If we can find the physical memory address where this structure is mapped, where does it reside? Can we typically find it in the first 100 MB of RAM? What about in the first 1000 MB? In other words, can we discover this information about the operating system quickly, without having to search the entirety of RAM?
I would also like to be able to find out the amount of system RAM quickly, to be able to estimate the expected size of the image, as well as get a rough idea of how long the imaging process will take. There is a registry key that holds physical memory information (HKLM\HARDWARE\RESOURCEMAP\System Resources\Physical Memory\.Translated) of type REG_RESOURCE_LIST, stored as a binary value in hexadecimal format. According to (1e), REG_RESOURCE_LIST is a "series of nested arrays. It stores a resource list used by a device driver or a hardware device controlled by that driver. The system writes detected data to the \ResourceMap tree." I have not determined if this resource list actually provides information regarding the total amount of physical RAM in the system. However, according to Brendan Dolan-Gavitt's paper research on the Windows registry in memory (1f), there are certain registry hives that reside only in memory, and are not stored anywhere on disk; one of these hives happens to be the HARDWARE hive, generated at boot time.
I still have a great deal of work to do in understanding how to enumerate the registry hives by mapping the cell indices to virtual addresses. I also need to look into volatility's integration of (the very excellent tool) RegRipper. A prototype implementation was developed by Brendan Dolan-Gavitt (1d) back in 2009, but I haven't had a chance to look at the current volatility source to see if it has been formally integrated.
UPDATE: I just came across the "Volatility and RegRipper User Manual" by Mark Morgan, detailing how to use volatility and RegRipper together to carve out registry information from volatile memory. I'll definitely have to pick back up here when I get back to all this.
So, a lengthy to-do list ahead of me, but I'm hoping to get back to this soon.
References:
1. RAM size info (from registry):
1a. Enumerating Registry Hives, http://moyix.blogspot.com/2008/02/enumerating-registry-hives.html
1b. Cell Index Translation, http://moyix.blogspot.com/2008/02/cell-index-translation.html
1c. Challenges in Carving Registry Hives from Memory, http://moyix.blogspot.com/2007/09/challenges-in-carving-registry-hives.html
1d. RegRipper and Volatility Prototype, http://moyix.blogspot.com/2009/03/regripper-and-volatility-prototype.html
1e. Types of registry data, http://kb.chemtable.com/en/types-of-registry-data.htm
1f. Forensic analysis of the Windows registry in memory, http://dfrws.org/2008/proceedings/p26-dolan-gavitt.pdf
2. OS version info (from kernel)
2a. Finding Kernel Global Variables in Windows, http://moyix.blogspot.com/2008/04/finding-kernel-global-variables-in.html
2b. Identifying Memory Images, http://gleeda.blogspot.com/2010/12/identifying-memory-images.html
2c. Windows operating systems agnostic memory analysis, http://www.dfrws.org/2010/proceedings/2010-306.pdf
2d. Basis – DBGKD_GET_VERSION64 and KDDEBUGGER_DATA64 http://antirootkit.wordpress.com/2009/03/31/basis-dbgkd_get_version64-and-kddebugger_data64/
3. General:
3a. NIST sample memory images, http://www.cfreds.nist.gov/mem/Basic_Memory_Images.html
3b. Volatility framework, https://www.volatilesystems.com/default/volatility
3c. Russinovich ME, Solomon DA. Microsoft Windows internals, Fourth edition: Microsoft Windows Server(TM) 2003, Windows XP, and Windows 2000 (pro-developer), http://www.microsoft.com/learning/en/us/book.aspx?ID=6710
3d. RegRipper, (Harlan Carvey) https://github.com/keydet89/RegRipper2.8
3e. Volatility and RegRipper User Manual, http://volatility.googlecode.com/files/How%20to%20use%20Volatility_v2.pdf
I was hoping to have time to write up some formal notes on my research, but unfortunately, I have been tasked with something more urgent. As such, I have to put this quest aside for the time being, but I wanted to make sure I captured a snapshot of where I'm leaving off (to facilitate picking it back up in the near future).
This is a loose, informal capture of the information I've found thus far, and the resources that have been most useful along the way. I realize that I have not correctly documented my references here - this is not meant to be a formal document by any means, just an organization of info for my own purposes (my bookmark manager was quickly becoming unmanageably large). That being said, I thought it may be of some use to others researching these topics.
I have recently been investigating methods for extracting key system information (namely OS version, physical RAM size, and CPU type) from volatile memory. While there are numerous existing tools available (such as volatility) that provide this functionality, they currently do so by parsing an existing image of live memory in search of certain hex signatures to find kernel structures and registry hives that contain these data.
The first such structure is the Kernel Processor Control Structure (KPCR). To quote Brendan Dolan-Gavitt, "The KPCR is a data structure used by the Windows kernel to store information about each processor, and it is located at virtual address 0xffdff000 in XP, 2003, and Vista." (2a)
This led me to wonder - is this structure located in the same offset in Windows 7 and 2008? What about 32-bit vs. 64-bit? I haven't had a chance to answer this question yet, but it looks like it *should* remain static in the newer Windows versions (need to verify).
Furthermore, one of the fields in the KPCR structure points to the _DBGKD_GET_VERSION64 structure, which contains a linked list of _KDDEBUGGER_DATA64 structures (2a). Given the KernBase field of the _KDDEBUGGER_DATA64 structure (at offset 0x18, according to the MS include files), the kernel image can be located. The executable will depend on the number of CPUs in the machine and whether physical address extension (PAE) is enabled (2d):
NTOSKRNL.EXE : 1 CPU
NTKRNLMP.EXE : N CPU
NTKRNLPA.EXE : 1 CPU, PAE
NTKRPAMP.EXE : N CPU PAE
Jamie Levy wrote up an excellent followup to Brendan's post (2b) which enumerated the different Size tags (from the _DBGKD_DEBUG_DATA_HEADER64 struct defined in wdbgext.h) for Windows 2000 through Windows 7/2008, and both x86 and x64 versions. As she also mentions, this OS determination was implemented by Mike Auty and integrated into volatility 1.4 (in the imageinfo.py plugin).
Need to investigate: How does volatility utilize the KPCR offset in imageinfo.py (kpcroffset = volmagic.KPCR.v())? Can this virtual address be mapped to a physical address by finding the kernel page directory table base and mapping according to the method described in section 3.2 of (2c)? If we can find the physical memory address where this structure is mapped, where does it reside? Can we typically find it in the first 100 MB of RAM? What about in the first 1000 MB? In other words, can we discover this information about the operating system quickly, without having to search the entirety of RAM?
I would also like to be able to find out the amount of system RAM quickly, to be able to estimate the expected size of the image, as well as get a rough idea of how long the imaging process will take. There is a registry key that holds physical memory information (HKLM\HARDWARE\RESOURCEMAP\System Resources\Physical Memory\.Translated) of type REG_RESOURCE_LIST, stored as a binary value in hexadecimal format. According to (1e), REG_RESOURCE_LIST is a "series of nested arrays. It stores a resource list used by a device driver or a hardware device controlled by that driver. The system writes detected data to the \ResourceMap tree." I have not determined if this resource list actually provides information regarding the total amount of physical RAM in the system. However, according to Brendan Dolan-Gavitt's paper research on the Windows registry in memory (1f), there are certain registry hives that reside only in memory, and are not stored anywhere on disk; one of these hives happens to be the HARDWARE hive, generated at boot time.
I still have a great deal of work to do in understanding how to enumerate the registry hives by mapping the cell indices to virtual addresses. I also need to look into volatility's integration of (the very excellent tool) RegRipper. A prototype implementation was developed by Brendan Dolan-Gavitt (1d) back in 2009, but I haven't had a chance to look at the current volatility source to see if it has been formally integrated.
UPDATE: I just came across the "Volatility and RegRipper User Manual" by Mark Morgan, detailing how to use volatility and RegRipper together to carve out registry information from volatile memory. I'll definitely have to pick back up here when I get back to all this.
So, a lengthy to-do list ahead of me, but I'm hoping to get back to this soon.
References:
1. RAM size info (from registry):
1a. Enumerating Registry Hives, http://moyix.blogspot.com/2008/02/enumerating-registry-hives.html
1b. Cell Index Translation, http://moyix.blogspot.com/2008/02/cell-index-translation.html
1c. Challenges in Carving Registry Hives from Memory, http://moyix.blogspot.com/2007/09/challenges-in-carving-registry-hives.html
1d. RegRipper and Volatility Prototype, http://moyix.blogspot.com/2009/03/regripper-and-volatility-prototype.html
1e. Types of registry data, http://kb.chemtable.com/en/types-of-registry-data.htm
1f. Forensic analysis of the Windows registry in memory, http://dfrws.org/2008/proceedings/p26-dolan-gavitt.pdf
2. OS version info (from kernel)
2a. Finding Kernel Global Variables in Windows, http://moyix.blogspot.com/2008/04/finding-kernel-global-variables-in.html
2b. Identifying Memory Images, http://gleeda.blogspot.com/2010/12/identifying-memory-images.html
2c. Windows operating systems agnostic memory analysis, http://www.dfrws.org/2010/proceedings/2010-306.pdf
2d. Basis – DBGKD_GET_VERSION64 and KDDEBUGGER_DATA64 http://antirootkit.wordpress.com/2009/03/31/basis-dbgkd_get_version64-and-kddebugger_data64/
3. General:
3a. NIST sample memory images, http://www.cfreds.nist.gov/mem/Basic_Memory_Images.html
3b. Volatility framework, https://www.volatilesystems.com/default/volatility
3c. Russinovich ME, Solomon DA. Microsoft Windows internals, Fourth edition: Microsoft Windows Server(TM) 2003, Windows XP, and Windows 2000 (pro-developer), http://www.microsoft.com/learning/en/us/book.aspx?ID=6710
3d. RegRipper, (Harlan Carvey) https://github.com/keydet89/RegRipper2.8
3e. Volatility and RegRipper User Manual, http://volatility.googlecode.com/files/How%20to%20use%20Volatility_v2.pdf
No comments:
Post a Comment