If you are currently undertaking work in this area and having trouble interpreting any flash images, I would be happy to hear from you.

Related posts:

1. Android forensic analysis lecture at Breakpoint2012 (AU) I will be presenting a lecture on Android forensics, focusing...

Related posts brought to you by Yet Another Related Posts Plugin.

The speaker lineup is looking fascinating, with leaders in the area of mobile security (both IOS and Android), hardware reverse engineering and Windows internals being on my list of lectures to attend.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The chapter aims to inform the legal professional and fact finder as to the foundations, context, principles, practices, limitations and challenges of the field of digital forensics, in order that they may understand the field enough to effectively engage with the digital forensic expert. It is anticipated that this chapter will additionally be of interest to practitioners and researchers in the field.

The chapter is currently available only to subscribers of the loose leaf service and online via Westlaw AU and Thomson Legal Online. The chapter will be individually purchasable via the above website in due course; if you wish to purchase a copy in the short term, please contact Thomson Reuters via email.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Identifying methods of reliably transitioning from investigative goals or claims to substantiated facts has been a significant preoccupation within the field over the last decade. Perspectives have ranged across extremes: from those that deny such methods exist (“it’s an art”) to those that attempt to characterise method as a system or recipe  (“it’s a process”). Only in recent years have clear inroads been made into the relationship between digital forensics and the scientific method in general.

The chapter begins with a comparison of a wide range of perspectives on digital investigation methodologies, and follows with practical guidance on applying the scientific method as a methodology for each step of a digital investigation. The chapter concludes with an investigative scenario demonstrating how the scientific method may be applied in the context of an actual case.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The KPCR scanning approach is general purpose in nature. Assuming an appropriate value for the Directory Table Base of the kernel address space, it will yield potential KPCR structures. It is, however, time consuming. Windbg is able to almost instantly find the KPCR in images stored as dump files, so it obviously isn’t employing scanning as a method of identification.

Looking further into the Microsoft dump file format, the dump file has a header which contains a field called KdDebuggerDataBlock, which is a pointer to the kernel virtual address of a KDDEBUGGER_DATA64 structure. This is the same structure which is the end goal of the KPCR trick.

Accordingly, when run against a dump file, the experimental version of volatility currently uses the KdDebuggerDataBlock as the object root, rather than KPCR.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Apart from the inevitable changes in kernel data structures which typically come with a new kernel version, Vista brought with it a change which broke one of volatility’s key techniques for identifying kernel objects. The change was Address Space Layout Randomisation (ALSR). Thanks to Gil Peterson for sharing this detail.

Structural interpretation approaches to volatile memory analysis rely on finding an initial kernel object from which one may traverse to other objects, in order to find  objects of interest to the investigator. With XP, volatility employed “the KPCR trick”. XP reliably stored the “Kernel Processor Control Region” at a fixed kernel virtual address (0xffdff000). From the KPCR structure, one then traverses intermediate structures (KdVersionBlock, then DebuggerDataList)  to access interesting structures such as the active process list.

In Vista, KPCR is not stored at a fixed address, so the first problem in porting volatility to Vista and above, to reliably get an initial reference to a valid KPCR structure.

Damien Aumaitre points out in his 2009 paper "A little journey inside Windows memory" that KPCR is self referencing. Based on this observation I undertook the following investigations:

1. I loaded up windbg to look at the KPCR of a XP dump file.

2. Set the symbol path

.sympath SRV*C:\dev\symbolcache\symbols*http://msdl.microsoft.com/download/symbols

.reload

3. Examined the KPCR

kd> !pcr
KPCR for Processor 0 at ffdff000:
    Major 1 Minor 1
    NtTib.ExceptionList: ed89dcf0
        NtTib.StackBase: ed89ddf0
       NtTib.StackLimit: ed89a000
     NtTib.SubSystemTib: 00000000
          NtTib.Version: 00000000
      NtTib.UserPointer: 00000000
          NtTib.SelfTib: 7ffdf000

                SelfPcr: ffdff000
                   Prcb: ffdff120
                   Irql: 00000000
                    IRR: 00000000
                    IDR: ffffffff
          InterruptMode: 00000000
                    IDT: 8003f400
                    GDT: 8003f000
                    TSS: 80042000

          CurrentThread: 86724020
             NextThread: 00000000
             IdleThread: 80552740

              DpcQueue:

4. Note that the first line indicates that KPCR is at VA 0xffdff000, which is to be expected. Note also that the SelfPcr attribute (at offset 0x1c from the start of the structure) has the same value at the address of the KPCR. This is what Aumaitre means by self referencing. There exists an additional self referencing property here related to the Prcb field which I will not go into.

5. Repeating the above on a Vista image gives the following. Note that the KPCR structure is not at 0xffdff000, and again, that the SelfPcr field points to the KPCR address.

kd> !pcr
KPCR for Processor 0 at 818f4700:
    Major 1 Minor 1
    NtTib.ExceptionList: 9a7bfcf0
        NtTib.StackBase: 00000000
       NtTib.StackLimit: 00000000
     NtTib.SubSystemTib: 80148000
          NtTib.Version: 000c3fac
      NtTib.UserPointer: 00000001
          NtTib.SelfTib: 7ffdf000

                SelfPcr: 818f4700
                   Prcb: 818f4820
                   Irql: 00000000
                    IRR: 00000000
                    IDR: ffffffff
          InterruptMode: 00000000
                    IDT: 822eb400
                    GDT: 822eb000
                    TSS: 80148000

          CurrentThread: 89d5eac0
             NextThread: 00000000
             IdleThread: 818f8300

              DpcQueue:

6. I checked the offsets for the SelfPcr as below:

kd> dt -r0 _KPCR 818f4700
ntdll!_KPCR
   +0×000 NtTib            : _NT_TIB
   +0×000 Used_ExceptionList : 0x9a7bfcf0 _EXCEPTION_REGISTRATION_RECORD
   +0×004 Used_StackBase   : (null)
   +0×008 Spare2           : (null)
   +0x00c TssCopy          : 0×80148000 Void
   +0×010 ContextSwitches  : 0xc3fac
   +0×014 SetMemberCopy    : 1
   +0×018 Used_Self        : 0x7ffdf000 Void
   +0x01c SelfPcr          : 0x818f4700 _KPCR
   +0×020 Prcb             : 0x818f4820 _KPRCB
   +0×024 Irql             : 0 ”
   +0×028 IRR              : 0
   +0x02c IrrActive        : 0
   +0×030 IDR              : 0xffffffff
   +0×034 KdVersionBlock   : 0x818f3c18 Void
   +0×038 IDT              : 0x822eb400 _KIDTENTRY
   +0x03c GDT              : 0x822eb000 _KGDTENTRY
   +0×040 TSS              : 0×80148000 _KTSS
   +0×044 MajorVersion     : 1
   +0×046 MinorVersion     : 1
   +0×048 SetMember        : 1
   +0x04c StallScaleFactor : 0×962
   +0×050 SpareUnused      : 0 ”
   +0×051 Number           : 0 ”
   +0×052 Spare0           : 0 ”
   +0×053 SecondLevelCacheAssociativity : 0 ”
   +0×054 VdmAlert         : 0
   +0×058 KernelReserved   : [14] 0
   +0×090 SecondLevelCacheSize : 0
   +0×094 HalReserved      : [16] 0
   +0x0d4 InterruptMode    : 0
   +0x0d8 Spare1           : 0 ”
   +0x0dc KernelReserved2  : [17] 0

Scanning KPCR in Vista memory dumps

With the former in mind, I set about writing a volatility scanner that scans the kernel address space for potential KPCR structures. I note here that in my development I have relied on dump files generated by Matthieu Suiche’s win32dd. Dump files store the physical address of the kernel page directory base, which is enough to reconstruct the kernel address space, however, other means will be necessary if operating on raw (DD) style memory images.

The scanner runs through each kernel address space memory region, looking for memory patterns that match the following constraints:

1. The VA of the start of candidate bytes  >= 0×80000000 (i.e. it is in the kernel address space)
2. The SelfPcr field at offset 0x1c from the start of the candidate bytes contains a pointer to the virtual address of the start of the KPCR structure
3. The Prcb field at offset 0×20 within the structure contains a pointer to the start of the _KPRCB structure, which is embedded within the KPCR structure at offset 0×120.

I have observed the above scanning technique to identify one KPCR value per processor, which is consistent with the described function of the KPCR – it is a per processor structure.

Usage

The above scanner is usable as the volatility command kpcrscan, and the output of it used via the parameter –kpcr=

An example of usage is presented in the screen capture below:

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

1. Downloaded Windows Vista RTM x86 retail symbols from Microsoft. I installed them to C:\dev\VistaSP0x86\vista-x86

2. I then ran the tpi_vtypes.py program against the symbol file which corresponds to the general Vista kernel, ntkrnlmp.pdb, generating a python symbol definition file for volatility in the process.

C:\mysrc\pdbparse>c:\Python25\python.exe tpi_vtypes.py c:\dev\VistaSP0x86\symbols\EXE\ntkrnlmp.pdb > vista_sp0_x86_vtypes.py

3. Moved vista_sp0_x86_vtypes.py to the \plugins\overlays\windows folder within the volatility source tree.

4. Created a new profile implementation called vista_sp0_x86.py. I based this off the existing windows XP SP2 profile, modifying to suit. In essence, the new profile is composed of three things:

1. a definition of native types (these appear to generally apply to 32bit windows operating systems (I simply took the exiting windows definitions);
2. a definition of the specific structural types which I just generated (contained in vista_sp0_x86_vtypes.py);
3. an overlay definition (I simply reused the existing XP SP2 one with the fixups from the last post.

vistasp0x86overlays = copy.deepcopy(vtypes.xpsp2overlays)

vistasp0x86overlays['_MMVAD_SHORT'][1]['Flags'][0] =  lambda x: x['u'][0]
vistasp0x86overlays['_CONTROL_AREA'][1]['Flags'][0] =  lambda x: x['u'][0]
vistasp0x86overlays['_MMVAD_LONG'][1]['Flags'][0] =  lambda x: x['u'][0]
vistasp0x86overlays['_MMVAD_LONG'][1]['Flags2'][0] =  lambda x: x['u'][0]

vista_sp0_x86_vtypes.ntkrnlmp_types.update(crashdump.crash_vtypes)
vista_sp0_x86_vtypes.ntkrnlmp_types.update(hibernate_vtypes.hibernate_vtypes)

class VistaSP0x86(xp_sp2.WinXPSP2):
    """ A Profile for Windows Vista SP0 x86 """
   native_types = vtypes.x86_native_types_32bit
   abstract_types = vista_sp0_x86_vtypes.ntkrnlmp_types
   overlay = vistasp0x86overlays

The next post will cover the modifications to volatility needed to find KdDebuggerDataBlock – the root of kernel objects required to find active modules and processes amongst other things.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

A current limitation Volatility’s support for Windows is that it doesn’t support analysis of anything other than Windows XP. This comes down to two issues:

1. The core kernel structures (symbols) which are related to information about processes, threads, open sockets and the like, tend to change from version to version of Windows; and
2. The technique that Volatility uses to initially find those structures does not work on Vista and above.

In this post I will be relating the first steps of how I ported Volatility to accept new symbol definitions in support of Vista in x86 (ie 32 bit) systems.  Beta code (complete enough to run pslist amongst others) is now in subversion.

My approach involved integrating automatically generated type definitions for Windows XP SP3, before applying the approach to Vista. It may seem redundant to use automatically generated type definitions for XP SP3, given that volatility works fine with its own hand coded ones for this version, however, doing so provides a useful foundation step, highlighting any assumptions being made higher up in the code.

Generating new structure definitions from PDB files

Thankfully all of the heavy lifting has been done by others. Brendan Dolan-Gavit has produced pdbparse that generates volatility compatible structure definitions from the symbol files that Microsoft produces.

The steps I undertook are:

1. Downloaded Windows XP with Service Pack 3 x86 retail symbols from Microsoft. I installed them to C:\dev\XPSP3_x86\

2. Checked out via subversion the current beta of Volatility.

3. Checked out via subversion pdbparse.

4. I installed the python construct module, on which pdbparse relies.

5. I then ran the tpi_vtypes.py program from pdparse against the symbol file which corresponds to the Windows XP uni-processor kernel, ntoskrnl.pdb, generating a python symbol definition file for volatility in the process.

C:\mysrc\pdbparse>c:\Python25\python.exe tpi_vtypes.py c:\dev\XPSP3_x86\symbols\EXE\ntoskrnl.pdb > xp_sp3_x86_vtypes.py

Adding structure definitions to Volatility

Adding the new structure definitions to volatility is simplified by the new “profile” abstraction recently introduced. Profiles allow for defining sets of structure definitions specific to a particular envionment. In this case, I created a new profile called “WinXPSP3”.

The steps I took are as follow:

1. Moved xp_sp3_x86_vtypes.py to the \plugins\overlays\windows folder within the volatility source tree.

2. Created a new profile implementation called xp_sp3_x86.py. I based this off the existing windows XP SP2 profile, modifying to suit. In essence, the new profile is composed of three things:

• a definition of native types (these appear to generally apply to 32bit windows operating systems (I simply took the exiting windows definitions);
• a definition of the specific structural types which I just generated (contained in vista_sp0_x86_vtypes.py);
• an overlay definition (I simply reused the existing XP SP2 one

class WinXPSP3(xp_sp2.WinXPSP2):
    """ A Profile for windows XP SP3 """
    native_types = vtypes.x86_native_types_32bit
    abstract_types = xp_sp3_x86_vtypes.ntoskrnl_types
    overlay = vtypes.xpsp2overlays

3. Running volatility against an appropriate image resulted in the following:

c:\mysrc\Volatility-1.4_beta1>c:\Python26\python.exe volatility.py –profile Win
XPSP3 -f "C:\Users\bradley\Desktop\images\RAM\XPSP3-x86.dmp" pslist
Volatile Systems Volatility Framework 1.4_beta1
invalid syntax (xp_sp3_x86_vtypes.py, line 63)

4. Inspecting the auto-generated structure definitions where the error was yielded the following:

‘Valid’ : [ 0x0, [UNIMPLEMENTED LF_BITFIELD]],

5. Reading the above error indicated that pdbparse does not handle bit-fields in structures.  I modified tpi_vtypes.py to simply ignore any structure features that pdbparse tagged as UNIMPLEMENTED.

def print_vtype(lf):
    print "  ‘%s’ : [ %#x, {" % (lf.name, lf.size)
    for s in lf.fieldlist.substructs:
    ms =  member_str(s.index)
    if (ms.find("UNIMPLEMENTED") >= 0):
        pass
    else:
            print "    '%s' : [ %#x, %s]," % (s.name, s.offset, ms)
    print "} ],"

6. I ran volatility again:

c:\mysrc\Volatility-1.4_beta1>c:\Python26\python.exe volatility.py –profile WinXPSP3 -f "C:\Users\bradley\Desktop\images\RAM\XPSP3-x86.dmp" pslist
Volatile Systems Volatility Framework 1.4_beta1
Error – Flags has no offset in object _MMVAD_SHORT. Check that vtypes has a concerete definition for it.
Error – Flags has no offset in object _CONTROL_AREA. Check that vtypes has a concerete definition for it.
Error – Flags2 has no offset in object _MMVAD_LONG. Check that vtypes has a concerete definition for it.
Error – Flags has no offset in object _MMVAD_LONG. Check that vtypes has a concerete definition for it.
‘NoneType’ object has no attribute ‘Signature’

7. Reading the above error indicated that the new structure definitions were missing some fields. These are most likely related to the removal of the bit-fields. Viewing the structures which correspond in the original vtypes.py file for XP SP2, we have:

‘_MMVAD_SHORT’ : [  0x18, { \
  'StartingVpn' : [ 0x0, ['unsigned long']], \
  ‘EndingVpn’ : [ 0x4, ['unsigned long']], \
  ‘Parent’ : [ 0x8, ['pointer', ['_MMVAD']]], \
  ‘LeftChild’ : [ 0xc, ['pointer', ['_MMVAD']]], \
  ‘RightChild’ : [ 0x10, ['pointer', ['_MMVAD']]], \
  ‘Flags’ : [ 0x14, ['unsigned long']], \
} ], \

8. The corresponding auto-generated structure definition is:

  ‘_MMVAD_SHORT’ : [ 0x18, {
    'StartingVpn' : [ 0x0, ['unsigned long']],
    ‘EndingVpn’ : [ 0x4, ['unsigned long']],
    ‘Parent’ : [ 0x8, ['pointer', ['_MMVAD']]],
    ‘LeftChild’ : [ 0xc, ['pointer', ['_MMVAD']]],
    ‘RightChild’ : [ 0x10, ['pointer', ['_MMVAD']]],
    ‘u’ : [ 0x14, ['__unnamed_1498']],
} ],

9. In the standard Volatility type definitions, offset 0×14 into the struct is an unsigned long type called Flags, whereas is the auto generated types, the same offset is a field called “u”, which has type ‘__unnamed_1498′. Further investigation reveals that the latter type appears to be a Union structure.

10. In order to resolve this discrepancy, my goal was to take the working field definition for “Flags” from the original “_MMVAD_SHORT” structure, and transplant it in the newly generated structures.

11. The problem with doing that is that editing automatically generated code tends to lead to problems down the line. Fortunately, recent work in the volatility framework has anticipated this kind of need, with the introduction of type “overlays”.

12. The existing XP type definitions already contained an overlay for the flags field, so Michael Cohen gave me the magic incantation necessary to patch the in memory version of the overlay structure. The patched version of the _MMVAD_SHORT overlay contains a field ‘Flags’, which, when the offset of it is read, returns the offset of the ‘u’ field of the auto-generated type definition. Note that I am glossing over significant complexity here.

xpsp3overlays['_MMVAD_SHORT'][1]['Flags'][0] =  lambda x: x['u'][0]

My next post will cover adding Vista structure definitions, and a final post will cover the key modifications needed to find the KPCR structure.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

As a part of the AFF4 work I have been involved in, I recently created a set of java bindings for libewf. If you want read access to the block content or metadataof EnCase compatible forensic images from the java programming language then this is for you.

They are currently tested on the windows platform (x86). UNIX and x64 support should be trivial.

They are now included in the libewf repository as libewf-java.

Thanks to Joachim Metz for libewf and David Collett for his python bindings (on which I based my code).

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

It is not straightforward to get working so I have copied the instructions originally provided by David Loveall and further expanded on them below.

1. Extract the Windows mount_ewf files into a directory.  I used the current mount_ewf_windows-20091123.zip file found in the downloads area of libewf. Download from the same place the proxy_ewf.py file and place it in the same directory (I used c:\opt\proxy_ewf\).

2. Download and install the Visual Studio runtime files, if you don’t already have them. Don’t bother as they are now included in the mount_ewf windows distribution.

3. Download and install ImDisk. Be careful about driver loading if you are on Vista and above.

4: Install python for windows. I used python 2.5 (x86) but 2.6 should work as well.

5. If you are on an x64 system, move imdisk.exe from the c:\Windows\system32 directory into the same directory as the mount_ewf and proxy_ewf.py files. The proxy_ewf script wont be able to run imdisk.exe due to the WOW64 file virtualisation features otherwise.

6. Run proxy_ewf:

c:\python25\python c:\opt\proxy_ewf\proxy_ewf-20091123.py c:\evidence\foo.e01

If you get a "Version number mismatch" error, it is likely that the _ctypes.pyd file in the mount_ewf distribution is incompatible with the one in your just installed python distribution. I deleted the one in the mount_ewf directory and things worked fine.

At this point, you should see a new drive letter (or letters) appear in windows explorer.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.