int for(ensic){blog;}

In chapter 8.16 of their book Forensic Discovery Dan Farmer and Wietse Venema say about the persistance of memory through the boot process:

Although most computers automatically zero main memory upon rebooting - many do not. This is generally independent of the operating system; for instance, motherboards fueled by Intel CPUs tend to have BIOS settings that clear main memory upon restart, but there is no requirement for this to happen.

I haven't seen information in the memory survive a reboot. I must have been using the wrong hardware. Fortunately such a (rare?) case is publicly documented, in the images provided by the DFRWS Memory Analysis Challenge. Based on the BIOS information in the memory dump the computer is a Sony Vaio PCG-R505TLK. You might review its specs at Sony's support site. Main components are an Intel Celeron processor and a 815 series chipset. The BIOS by Phoenix Technologies is of version R0202U1, dated 06/26/01.

I ran both images through ptfinder --nothreads. Here are the resulting listings for images no. 1 and 2.

Kntlist, one of the two tools which won the challenge, calculates the system boot time from the kernel variable KeBootTime. For the first image that is 2005-06-05 00:32:27Z.

Now compare that with the output of PTfinder. There are several processes which started around that time. But there are also traces of three processes which started earlier:

1. 2005-06-03 01:25:53Z csrss.exe, PID 168
2. 2005-06-03 01:25:54Z winlogon.exe, PID 164
3. 2005-06-04 23:36:31Z winlogon.exe, PID 176

While there was no exit time recorded, it is highly unlikely that these processes were still running. Kntlist did not find a single of these processes by cross-checking lists of processes, threads and handles. In addition there is an instance of winlogon.exe with a PID of 176 (note the duplicate PID!) which was started at 2005-06-05 00:32:44Z, the assumed boot time of the system.

It is not documented how the system reached the state conserved in the memory dump. But the story continues. Fom the DFRWS' website:

In addition, while he was attempting to create forensic duplicate of the drive, the system rebooted unexpectedly. When the system came back up, Daniels acquired the physical memory again [...].

Now let's have a look at the second image. According to kntlist the system was booted 2005-06-05 15:00:56Z. And again there are traces of three processes which were started before that time:

1. 2005-06-05 00:32:43Z csrss.exe, PID 180
2. 2005-06-03 01:25:53Z csrss.exe, PID 168
3. 2005-06-05 00:32:40Z smss.exe, PID 156

Two of them, the first and third, were active at the time the system crashed and rebooted. The second already was an artefact at that time, you've seen it just before in the first image's listing. This clearly shows that at least parts of the main memory can survive a reboot.

Edit 04/25/06: There's some more interesting reading on data lifetime.