2:33 p.m.
Hello guys,
I'm trying to use Volatility through Firewire, but actually it's not
working.
My investigator PC runs Ubuntu Linux Ubuntu 12.04
I'm using the New (JuJu) Firewire stack compiled into kernel and I also
installed forensic1394.
My Firewire Bus is up and connected to a Firewire Bus on a target win7
system (4GB memory),
I can successfully dump the memory with another tool called 'inception'.
However, output only says:
vol# python vol.py -l firewire://forensic1394/0 --profile=Win7SP1x64 modules
Volatility Foundation Volatility Framework 2.3.1
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareSnapshotFile: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
FileAddressSpace: Location is not of file scheme
ArmAddressSpace: No base Address Space
What I am doing wrong?
Thank you!
--
Sebastian
12:02 p.m.
Hiya Sebastian,
From your output you can see that FirewireAddressSpace
isn't listed as
an option that was tried. That suggests that the firewire
module
couldn't locate either libforensic1394 (the preferred option and the
only one that works with the juju stack) or libraw1394 (which only works
with the old firewire stack).
Since you've said you've had inception working (which relies on
libforensic1394), my guess is that the module got installed in
/usr/local/lib rather the /usr/lib, and it's possible that python can't
find it by default but that inception can.
You can check which modules volatility can see by running "python vol.py
--info", and I suspect the "AddressSpaces" list won't contain
FirewireAddressSpace as an entry. If you run python, and then try the
command "import forensic1394", that will tell you whether python can
find it or not. If you can an exception, then you'll have to figure out
how to install it so that python can see it by default. If there's no
error, then we'll need to look further into what's causing the problem.
Also, I believe in the 2.3.1 release, it was a little temperamental
because the delay between enabling the bus, setting it to sbp2 mode, and
then trying to read data was too short. If you get it detecting
firewire but having read problems, let me know and I'll walk you through
applying a patch that might help.
Mike 5:)
1:12 p.m.
Hi Mike,
Thank you for your help! You were right, it could not find the
forensic1394 library.
I copied the lib files from /usr/local/lib to /usr/lib and now it seems
to find the libraries.
However, I now have errors during reading.
Could the reason be that the target machine runs win7 64bit 'Enterprise'
and the profile does not fit?
Thank you!
/vol# python vol.py -l firewire://forensic1394//0 --profile=Win7SP1x64
modules
Volatility Foundation Volatility Framework 2.3.1
IOError(u'forensic1394_read_device_v: General I/O error',)
IOError(u'forensic1394_read_device_v: General I/O error',)
IOError(u'forensic1394_read_device_v: General I/O error',)
IOError(u'forensic1394_read_device_v: General I/O error',)
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareSnapshotFile: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: No xpress signature found
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Location is not of file scheme
VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
VMWareSnapshotFile: Invalid VMware signature: 0xf000c740
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory - EXCEPTION: Failed to read from firewire device
IA32PagedMemoryPae: Incompatible profile Win7SP1x64 selected
IA32PagedMemory: Incompatible profile Win7SP1x64 selected
FirewireAddressSpace: Must be first Address Space
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Profile does not have valid Address Space check
Mike Auty:
Hiya Sebastian,
From your output you can see that FirewireAddressSpace isn't listed as
an option that was tried. That suggests that the firewire module
couldn't locate either libforensic1394 (the preferred option and the
only one that works with the juju stack) or libraw1394 (which only works
with the old firewire stack).
Since you've said you've had inception working (which relies on
libforensic1394), my guess is that the module got installed in
/usr/local/lib rather the /usr/lib, and it's possible that python can't
find it by default but that inception can.
You can check which modules volatility can see by running "python vol.py
--info", and I suspect the "AddressSpaces" list won't contain
FirewireAddressSpace as an entry. If you run python, and then try the
command "import forensic1394", that will tell you whether python can
find it or not. If you can an exception, then you'll have to figure out
how to install it so that python can see it by default. If there's no
error, then we'll need to look further into what's causing the problem.
Also, I believe in the 2.3.1 release, it was a little temperamental
because the delay between enabling the bus, setting it to sbp2 mode, and
then trying to read data was too short. If you get it detecting
firewire but having read problems, let me know and I'll walk you through
applying a patch that might help.
Mike 5:)
--
Sebastian
10:16 a.m.
Hiya Sebastian,
Right, so that looks like a firewire read issue, which comes down to
there not being enough of a time delay between starting up the bus,
setting it into sbp2 mode, and then carrying out the read.
This issue has been fixed in the subversion copy of volatility. You can
manually patch volatility 2.3.1 to take longer over this, by editing the
file at volatility/plugins/addrspaces/ieee1394.py, and finding the line:
self._bus.enable_sbp2()
and change it to read:
self._bus.enable_sbp2()
time.sleep(5)
You can also find a more complete patch at [1]. Hopefully that will
solve your problems, please let me know if you're still having read
difficulties...
Mike 5:)
[1] https://code.google.com/p/volatility/source/detail?r=3575
3950
days inactive
3955
days old
vol-users@lists.volatilityfoundation.org
3 comments
2 participants
participants (2)
-
Mike Auty -
Sebastian Biedermann