Security Incidents mailing list archives
Re: Digital forensics of the physical memory
From: Harlan Carvey <keydet89 () yahoo com>
Date: Fri, 17 Jun 2005 09:35:16 -0700 (PDT)
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 ------------------------------------------
Current thread:
- Digital forensics of the physical memory Mariusz Burdach (Jun 15)
- Re: Digital forensics of the physical memory Ben Hawkes (Jun 17)
- Re: Digital forensics of the physical memory Mariusz Burdach (Jun 17)
- Re: Digital forensics of the physical memory Harlan Carvey (Jun 17)
- RE: Digital forensics of the physical memory George M. Garner Jr. (Jun 18)
- RE: Digital forensics of the physical memory Harlan Carvey (Jun 20)
- Re: Digital forensics of the physical memory David Pick (Jun 20)
- Moderator's note: Re: Digital forensics of the physical memory Daniel Hanson (Jun 20)
- part deux, was -> RE: Digital forensics of the physical memory Harlan Carvey (Jun 20)
- Re: part deux, was -> RE: Digital forensics of the physical memory Ben Hawkes (Jun 20)
- Re: Digital forensics of the physical memory Ben Hawkes (Jun 17)