Hello Valdis, > The original demonstration was for a Mac - google for 'pwn a mac with your > ipod' > and that should find it. ;) > > There's also Firescope: ftp://ftp.firstfloor.org/pub/ak/firescope/ > which has been used for debugging Linux kernels.
Right, I heard about the original demonstration a while back, but hadn't found a decent tool until recently. I also looked at firescope, which looks quite interesting, but obviously isn't quite the tool for my task. > Well, the problem is that Firewire allows for DMA control from the other > end of the wire. > > For Linux, it's addressable by either: > > 1) Making sure there's no ieee1394 driver loaded by blacklisting it in > whatever udev/modules file your distro uses for such things. No driver > loaded means the near end of the wire isn't initialized, so it doesn't work. > > 2) Force the module to be loaded with the parameter 'phys_dma=0'. > This causes the ieee1394 chipset to be initialized with settings that > reject the DMA requests. Right, I've tested this in various scenarios and it seems to work out. The Linux kernel does not open up the physical request filters when phys_dma=0. However, do you know if there's anything interesting that can be done if physical requests are denied, but the asynchronous request filters are opened up? I don't know quite enough about FireWire yet to know that answer. This article has some interesting tidbits: http://www.matasano.com/log/695/windows-remote-memory-access-though-firewire/ > I'm sure that if it's been used to hack Macs and debug Linux kernels, > somebody is using it for investigations. :) Well, what I am getting at, is has anyone tested the techniques well enough to feel comfortable using it on an important investigation? You know, like one that could go to court. I'm sure people are using it for various fun things, and may even gumshoe sysadmins might be using it, but is it stable enough yet to be forensiclly sound? thanks, tim
