so much for the weekend...

Well, I had grand plans of doing some side work on the memory research this weekend, but some medication complications have left me sleepless and therefore rendered me essentially useless. Today I wanted to at least do something fun, and decided to make a good dinner...and what's a good dinner without a good drink to go with it?

They had some good looking wild-caught alaskan sockeye salmon at the market yesterday, so I picked some up and decided to make this really tasty recipe for Orange-Roasted Salmon with Yogurt-Caper Sauce, although I added some grapefruit zest and chopped fresh thyme to the seasonings - a modification I added the last time I made it, and it turned out excellent. As a side, a friend of mine turned me on to this awesome Poblano Potato Salad from the "Mexican Made Easy" show on Food Network. It's simple and really delicious (and I am *not* a potato salad fan).

The grapefruit zest reminded me of these excellent ruby grapefruits I picked up at Whole Foods, and so I decided I wanted to incorporate the juice somehow. I like the taste of Bombay Sapphire with grapefruit juice, so I started looking around for recipe inspirations. I found a few recipes with combinations of bombay, grapefruit juice, orange liqueur, and lemon juice, and had an idea. Orange Liqueur, even Cointreau, gets too sweet and syrupy for me pretty quickly...I can't take much in a drink. But I knew what I had in my fridge, and decided to make a substitute - a rosemary-citrus simple syrup. Here is the recipe for the syrup and the drink I made:

rosemary-citrus simple syrup

1/4 cup water
1/4 cup sugar
1 T fresh rosemary (coarsely chopped)
1 stalk lemongrass (coarsely chopped)
juice of 1/2 lemon
1 T orange zest
mix ingredients in a small saucepan, bring to a boil, and simmer until reduced. strain and cool.

grapefruit 'tini

1 T (1/2 oz) rosemary-citrus simple syrup
1 shots (1.5 oz) fresh squeezed strained grapefruit juice (ruby)
3 shots (4.5 oz) bombay sapphire gin

muddle luxardo cherry in bottom of martini glass. add ingredients above to a cocktail shaker with ice, shake and strain into martini glass. garnish with fresh rosemary sprig.

Yeah, I feel a little guilty for not getting any RE or memory work done this weekend, but everyone needs a little time off sometime, right? ;)

memory research interrupted...notes thus far

**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 

my entry into the blogosphere...

Ok, so I decided to start documenting some of my stumbling through research online, mostly for my own benefit, but hopefully I can manage to pull together some info that might help other people out there. I don't have any immediate plans for creating any sort of focused body of research here, I just plan to post information on whatever I'm currently working on (or interested in). This will probably entail information pertaining to the world of digital forensics, for what it's worth.