Re: Digital forensics of the physical memory

From: Harlan Carvey (keydet89_at_yahoo.com)
Date: 06/17/05

  • Next message: George M. Garner Jr.: "RE: Digital forensics of the physical memory"
    Date: Fri, 17 Jun 2005 09:35:16 -0700 (PDT)
    To: Ben Hawkes <ben.hawkes@paradise.net.nz>, Mariusz.Burdach@seccure.net
    
    

    Ben,
     
    > The only other thing I would like to mention is the
    > difficulty in
    > gathering a trustworthy image of physical memory. In
    > fact I would go so
    > far as saying that this is an impossibility so long
    > as the imaging
    > process relies on the host operating system. You
    > touch on this briefly
    > in Chapter 2, "Problems with memory acquisition
    > procedure", but fail to
    > note that the approaches you suggest (using dd or
    > the proof of concept
    > tools in idetect) can be circumvented by fairly
    > rudimentary kernel
    > space anti-forensics themselves.

    You've hit the nail squarely on the head here, I
    believe.

    I contacted the author directly with regards to some
    issues I saw, and though he thanked me for my
    comments, he really didn't (and has yet to do so)
    addressed those issues.

    One of the issues in particular is that he starts off
    by mentioning the FU rootkit and the SQL Slammer worm,
    both of which are specific to Windows...and then
    presents examples using only a Linux system. He
    states in the paper that similar work can be done on
    Windows systems, but never provided any information to
    that effect.

    Based on entries I made to my blog the other day, I
    ended up having a conversation w/ someone from MS
    about this very issue. The issue of using dd.exe to
    image Physical Memory goes beyond the fact that there
    don't seem to be any maps describing how physical
    memory is used by Windows systems, and that memory
    used by processes consists of both RAM and the
    pagefile. Additional issues include, as you pointed
    out, that while the imaging process is occurring, the
    kernel memory (and even user-mode memory) is
    changing...so what you end up with is a smear, for
    want of a better term.

    Even tools like pmdump.exe and LiveKD
    (SysInternals.com) are not sufficient for collecting
    user-mode memory, b/c they do not lock or suspend
    memory.

    The upshot is that in order to really capture a
    snapshot of a Windows system, you need to cause a
    crashdump. Properly configured, you can get a lot of
    valuable information from this crashdump, as it will
    contain the contents of kernel-mode memory. In
    addition, the MS debuggers "understand" this
    output...whereas the output of dd.exe is NOT
    compatible with the debuggers.

    > This is not to take away from the rest of the
    > document which, overall,
    > is quite informative and probably applicable to the
    > vast majority of
    > Linux intrusions seen today, but I think this is an
    > important point to make nonetheless.

    I fully agree...my intention is NOT to take away from
    the author's efforts, but instead use them as a
    starting point for additional work.

    H. Carvey
    "Windows Forensics and Incident Recovery"
    http://www.windows-ir.com
    http://windowsir.blogspot.com

    ------------------------------------------
    Harlan Carvey, CISSP
    "Windows Forensics and Incident Recovery"
    http://www.windows-ir.com
    http://windowsir.blogspot.com
    ------------------------------------------


  • Next message: George M. Garner Jr.: "RE: Digital forensics of the physical memory"