Wednesday 4 January 2012
Sunday 1 January 2012
A small diversion...
I figured I should start by addressing something that Harlan pointed out in this continuing recent twitter discussion regarding “contributing to the community” (stemming from the two posts I mentioned in my last post, along with this new one). He hit the nail on the head with the characterization of the attitude that some of us have towards contributing (namely, being afraid to speak up), describing it as, “paralysis.”
However painful to admit, I have a problem with paralysis, beyond just the fear of looking stupid on the internet before the whole world. I realized that it is something I fight every day in everything I do, whether it is learning something new, meeting new people, snowboarding on a new scary run, or trying out a new recipe when I'm cooking for others. It may be paralyzing fear at first, but it is fighting and overcoming that fear that has brought me satisfying growth in both career and personal endeavors. Like my friend told me (jokingly) when I first started snowboarding - “If you never fall, you're not pushing yourself hard enough.” But I think there's some truth to that - if you are constantly afraid of failing, you're probably not pushing your limits and learning (which reminds me of this recent article).
Part of being able to conquer this fear is having confidence – and the rewarding successes we enjoy after having defeated one of these little obstacles helps to build that confidence. I have been slowly gaining confidence in my own abilities and overcoming the fear of speaking up...I still have a long way to go, but I certainly would never have made it this far this quickly if it weren't for the continuing support and encouragement (however blunt sometimes ;) ) of the active members of the DFIR community.
When I first learned to snowboard, all my friends were already expert skiers and snowboarders. They goaded me into joining them in the back bowls and expert runs, even though I couldn't keep up with them and was scared to death most of the time. But having a constant push of someone more experienced than you can be a great motivation, especially when they can help you learn from your mistakes. That is why I am thankful that we have so many intelligent, caring individuals in this community, who are truly dedicated to growing the field. Thanks guys, for all your help and support.
Well, one quick opening paragraph turned into a post of its own...I think I'll save my technical content for a separate post (hopefully tomorrow if I don't finish tonight). I have a brief overview of a few network forensics analysis tools (NFAT) that I recently evaluated that I wanted to share.
Wednesday 14 December 2011
Sunday 27 February 2011
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.
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? ;)
Wednesday 23 February 2011
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.
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/
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