5:39 p.m.
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.