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
