Hey everyone, this is my first post here on Forensic Focus. I am currently in school obtaining my Computer Science Degree. I just recently started reading the EnCE Study Guide.
I understand that if information being passed through RAM is stored in swapspace if it exceeds the amount of RAM in the computer. When the computer is in hibernate mode, the contents of RAM are dumped into hiberfil.sys.
My question is, during a live Acquisition, is it better to pull the plug hoping to get information in swapspace, or would putting the computer into hibernate before pulling the plug yield better results. Thanks ) Go easy on me
One of the aspects of a live acquisition is that the system is powered on and running…therefore, you wouldn't be pulling to plug at all.
As for the hibernation file, MS documentation states that it is compressed, and even folks I know at MS can't get the information on the compression algorithm used. While I'm sure you can get some ASCII and/or Unicode strings from a hibernation file, the format of the file as it exists on disk isn't documented or understood, so I don't really know what you'd expect to get from the hibernation file.
No clue. I just thought I'd ask. I enjoy the programming aspects since I'm a Computer Programmer. It'd be a fun thing to look into. idea
I was doing some reading today while doing some analysis on a sansa mp3 player(hopefully added to the blog soon), and came across a filesystem id of 84. This, according to microsoft is "suspend to disk" or in other words, hibernation. While I can't provide answers, that may be the search term to start with, as it gave me more results than I cared to look through.
Wouldn't it perhaps to be more prudent to see what that means to SanDisk, the manufacturer of the Sansa? Perhaps there's a reason in their specs for including that file system id.
Just a thought…
Oh I am working on it. Right now, it seems to be where they store the firmware as an encrypted .mi4 file - it's only a 20mb partition. I'm not sure how I feel about loading some of the tools since it can be a destructive process.
> …since it can be a destructive process.
I'm not sure what you're referring to? What tools? Load them where? How is this destructive and what does it have to do with an encrypted file?
I was searching about a way, how to read the hibernation file (hiberfil.sys) but all what i found is that most of MS documentation states that the file is compressed and encrypted
… till i found SANDMAN which is a c script that provides an access (read/write ) to the hibernation file made under Windows XP to Windows 2008 on x86 architecture.
I believe one way to do this on Xp, is to dump the physical memory using DD or DCFLDD, Perhaps the Pagefile.sys may also be of use, If the system is shut off abruptly the file should remain in the C\ I am currently researching if this file can be accessed at the bit level for low level copying (though if i Copy it i don't know how to analyze it). I have had a good bit of luck stringsearching Ram Images though using this command in DCFLDD
dcfldd if=/dev/mem of=C\Ram.imz status=on totalhashformat=#hash# conv=sync,noerror hashlog=C\memory_md5.txt
However this wont work in vista.
Hope this helps.
I have had a good bit of luck stringsearching Ram Images though using this command in DCFLDD
Consider Volatility as well. Testing on XP SP2 images is going well.