Jon, It took me a little while to dig up our correspondence from two years ago. Two years ago you sent me two memory "images" taken in short succession from a single computer system. The first memory "image" was acquired via firewire using Adam Boileau's code. The second "image" was acquired using GMG Systems, Inc. KnTDD. Interestingly, there were artifacts from the firewire memory acquisition in the KnTDD memory dump. Here is a comparison of the output resulting from the two methods: <Quote/> For example, consider the following start of the KdVersionBlock as acquired by KnTDD and firewire, respectively: KnTDD: 0046F6A0 38 39 41 42 43 44 45 46 D0 B9 54 80 D0 B9 54 80 89ABCDEFйT€Ð¹T€ 0046F6B0 00 00 00 00 00 00 00 00 4B 44 42 47 **70 02** 00 00 KDBGp 0046F6C0 00 00 40 80 00 00 00 00 88 64 45 80 00 00 00 00 @€ ˆdE€ firewire 0046B940 38 39 41 42 43 44 45 46 D0 70 54 80 D0 70 54 80 89ABCDEFÐpT€ÐpT€ 0046B950 00 00 00 00 00 00 00 00 4B 44 42 47 **08 02** 00 00 KDBG 0046B960 00 00 40 80 00 00 00 00 70 2E 45 80 00 00 00 00 @€ p.E€ The two octets that follow the tag "KDBG" are in each case the size of the version block. In the case of the KnTDD-acquired image the value is 70 02 (0x270). In the case of firewire the value is 08 02 (0x208). This value is hard coded in the kernel and cannot change without a change in the kernel. Also, the physical offset within the page has changed. While I can understand how a page might move to a different physical address, the offset within the page should remain unchanged. </Quote> Ideally, we should have run KnTDD twice, once before and then after the firewire memory dump. However, the fact that KnTDD was run after the firewire memory dump and produced expected results is sufficient to show that the problem occurred with the firewire acquisition, not the memory itself. The firewire memory dump evidenced a fairly high bit error rate. What is more troubling, virtual-to-physical address translation was impossible because kernel variables were displaced by arbitrary offsets within the memory dump from their expected physical locations. Interestingly, Brian Carrier also reported that some physical pages were transposed from their corresponding locations in a DD memory "dump." They were not able to explain the result. Would you say that errors of this sort "are more likely to have an impact on the tasks/processes/executables analysis and their integrity than that of other forensic artifacts that would be of value to evb's case?" Now let me qualify the foregoing: This was just one memory "image" acquired using firewire. It is entirely possible that further testing would show that more recent firewire controllers/operating systems etc. are reliable. On the other hand, firewire controllers typically are not used to acquire memory in this manner, even though the functionality technically is a part of the specification. So it is entirely possible that further testing would show that none of the existing firewire controllers are reliable for physical memory acquisition. We simply don't know. Getting back to evb's problem: I would have no problem with using firewire to unlock the computer, either directly or by recovering a user's password. My problem is with using firewire to acquire *evidence* that will subsequently serve as the basis for some action against the employee. Presumably the company intends to terminate the employee if it finds contraband on his computer. However, the employer itself may be found liable if subsequently the employer's actions are judged to have been arbitrary. An action for which the only supporting evidence is found to be inadmissible would by definition be arbitrary. Knowing something and proving it in court are two different things. As forensic experts, we are about the latter; and while we may not be lawyers, to be effective we must know at least enough about the law so as to present evidence so as to prove something. And we need to know when that presentation is not going to fly. Regards, ReC.