Can't acquire via firewire or process firewire memory dump obtained via Inception

[GoogleCodeExporter]

I'm not sure whether this is one problem or two. I've been trying to get 
Firewire memory acquisition or analysis to work under Volatility, and failing 
miserably.

Should the --info option list a Firewire address space? It doesn't currently, 
but some old data I've found shows that it used to. Is Firewire really 
supported under 2.3, or is the documentation in error?

Additionally, I have a dump I've pulled via Firewire using Inception, but 
Volatility refuses to analyze it properly, and crashes to boot! Here's the 
output from my attempt. The Inception Firewire dump does appear to actually 
contain memory data.

$ python vol.py -f inceptiondump_Win7x64_beforelogin.bin --profile=Win7SP1x64 
imageinfo
Volatility Foundation Volatility Framework 2.3.1
Determining profile based on KDBG search...

          Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64, Win7SP0x64, Win2008R2SP1x64
                     AS Layer1 : AMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/cygdrive/c/Users/john.mccash/Desktop/memimage/inceptiondump_Win7x64_beforelogin.bin)
                      PAE type : No PAE
                           DTB : 0x187000L
                          KDBG : 0xf6fc000170a0
          Number of Processors : 4
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0xfffff80002e01d00L
Traceback (most recent call last):
  File "/cygdrive/g/volatility-read-only/vol.py", line 183, in <module>
    main()
  File "/cygdrive/g/volatility-read-only/vol.py", line 174, in main
    command.execute()
  File "/cygdrive/g/volatility-read-only/volatility/commands.py", line 121, in execute
    func(outfd, data)
  File "/cygdrive/g/volatility-read-only/volatility/plugins/imageinfo.py", line 35, in render_text
    for k, v in data:
  File "/cygdrive/g/volatility-read-only/volatility/plugins/imageinfo.py", line 100, in calculate
    yield ('KPCR for CPU {0}'.format(kpcr.ProcessorBlock.Number), hex(kpcr.obj_offset))
TypeError: hex() argument can't be converted to hex

$ python vol.py -f inceptiondump_Win7x64_beforelogin.bin --profile=Win7SP1x64 
pslist
Volatility Foundation Volatility Framework 2.3.1
Offset(V)          Name                    PID   PPID   Thds     Hnds   Sess  
Wow64 Start                          Exit
------------------ -------------------- ------ ------ ------ -------- ------ 
------ ------------------------------ ------------------------------
Traceback (most recent call last):
  File "/cygdrive/g/volatility-read-only/vol.py", line 183, in <module>
    main()
  File "/cygdrive/g/volatility-read-only/vol.py", line 174, in main
    command.execute()
  File "/cygdrive/g/volatility-read-only/volatility/commands.py", line 121, in execute
    func(outfd, data)
  File "/cygdrive/g/volatility-read-only/volatility/plugins/taskmods.py", line 140, in render_text
    for task in data:
  File "/cygdrive/g/volatility-read-only/volatility/win32/tasks.py", line 70, in pslist
    for p in get_kdbg(addr_space).processes():
  File "/cygdrive/g/volatility-read-only/volatility/plugins/overlays/windows/kdbg_vtypes.py", line 42, in processes
    raise AttributeError("Could not list tasks, please verify your --profile with kdbgscan")
AttributeError: Could not list tasks, please verify your --profile with kdbgscan

Original issue reported on code.google.com by johnmcca...@gmail.com on 6 Mar 2014 at 3:32

• Merged into: #521

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

OK, I found one of the problems. The instructions for installing the 
forensic1394 library that go with Inception only do so for python3, and they 
also place them under /usr/local, which isn't where Volatility wants them. Once 
I fixed that, the Firewire address space was populated into volatility. However 
I still can't process the memory image I'm collecting this way. Any idea why? I 
get the following output when I try to process the memory image

$ vola -f  volatility_firewire_Win7x64.img --profile=Win7SP1x64 pslist
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
 MachOAddressSpace: MachO Header signature invalid
 LimeAddressSpace: Invalid Lime header signature
 WindowsHiberFileSpace32: No xpress signature found
 WindowsCrashDumpSpace64: Header signature invalid
 HPAKAddressSpace: Invalid magic found
 VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
 VMWareSnapshotFile: Invalid VMware signature: 0x0
 WindowsCrashDumpSpace32: Header signature invalid
 AMD64PagedMemory: No valid DTB found
 IA32PagedMemoryPae: Incompatible profile Win7SP1x64 selected
 IA32PagedMemory: Incompatible profile Win7SP1x64 selected
 FileAddressSpace: Must be first Address Space
 ArmAddressSpace: No valid DTB found

Original comment by johnmcca...@gmail.com on 6 Mar 2014 at 6:23

[GoogleCodeExporter]

One further note: If, instead of imaging the memory via firewire using 
imagecopy, I attempt to just run pslist, Volatility seems to peg the cpu on the 
collecting system and zone out indefinitely.

Might this be significant?

More to the point, can somebody validate that analyzing memory via Firewire or 
memory dumps collected via Firewire has worked in the past?

Thanks
John

Original comment by johnmcca...@gmail.com on 6 Mar 2014 at 7:02

[GoogleCodeExporter]

I think ikelos can comment more on this one.

Original comment by jamie.l...@gmail.com on 7 Mar 2014 at 4:46

[GoogleCodeExporter]

Hiya John,

Yes, I can confirm that acquisition by firewire should be possible using 
volatility 2.3 (although it's quite temperamental because an additional delay 
is needed between enabling the bus, setting it to sbp2 mode, and then 
reading/writing data, see commit r3575 for more the patch).

I don't know why firewire acquisition would push the *target* CPU up to 100%, 
as far as I'm aware, the CPU simply allows access via DMA to the whole of 
memory, and then steps out of the picture.  Volatility does do a very large 
number of very small reads, however, so if there is a request setup cost, that 
could be what's causing the high usage.  I haven't experienced that myself 
(although I also haven't used it a great deal in anger, either).  You could try 
acquiring the memory using the imagecopy plugin (and try different values for 
the block size using -b)?

As to reading the previously acquired image, since memory can change during the 
acquisition process, it's possible that a critical pointer that was read 
earlier might point to a location that was shifted around later on.  Volatility 
should probably catch the exception more gracefully, but given that we're not 
convinced the read was perfect, it may well be that KPCR 1 couldn't be 
found/read, and so its offset wasn't available.  Does this happen with every 
image you acquire through inception, or just this one?

Original comment by mike.auty@gmail.com on 7 Mar 2014 at 5:22

[GoogleCodeExporter]

Hey Mike,
I've pulled memory via both Inception, and Volatility, but neither one works 
when I go to analyze them. The CPU is pushed to 100% on the acquiring host, not 
the target, when I try to do a direct command such as:

python vol.py -l Firewire://forensic1394/0 pslist

If I just do

python vol.py -l Firewire://forensic1394/0 imagecopy --profile=Win7SP1x64 -O 
image.img

then it appears to work, but I'm unable to successfully analyze the resultant 
image using volatility. I've tried this test 2-3 times on the same host (after 
downgrading it to 4G, so I'm sure I'm getting the whole thing)

Suggestions for troubleshooting? Inception is able to successfully patch memory 
on the target to allow login with no password, so at the very least, the 
python3 version of forensic1394 has to be working correctly.

Thanks
John

Original comment by johnmcca...@gmail.com on 7 Mar 2014 at 7:23

[GoogleCodeExporter]

Hiya John,

Have you tried applying the changes in r3575 to let the bus settle before 
making reads of it?  Without that you'll likely get read errors very early on.

If neither inception nor volatility is able to acquire a valid memory image 
then I'd start by acquiring one on the host directly, and testing that you can 
actually analyze the memory using the profile you've chosen.

Bear in mind that Win7 profiles can take a long time to run even something 
simple like pslist, and I'm not surprised the CPU is pegged at 100% on the 
acquiring machine.

Let me know how you get on with those two options and then we may be able to 
troubleshoot further from there...

Original comment by mike.auty@gmail.com on 27 Mar 2014 at 8:35

[GoogleCodeExporter]

Mike,
Sorry for the delay. I've been buried in work for the last month, and am just 
getting back to this. I did try r3575, but it doesn't seem to help. The 100% 
processor issue appears to be an actual hang of some sort, rather than the job 
just taking a long time.

Interesting update here... I just retried a slightly different way. I'd 
originally been testing using a Kali Linux boot CD, with forensic1394, 
inception, and volatility installed on top. I recently reinstalled the OS on 
the same hardware with the new 3.0 SIFT Kit (I used to have Win7 on that 
system), so I put forensic1394, inception, and volatility on that, with one 
minor difference. Instead of the 0.2 version of forensic1394 specified by the 
Inception instructions, I just pulled the most recent subversion tree. I didn't 
think, at the time, that it was different, since the package hadn't been 
updated in a couple of years, but it looks like it actually is.

The upshot is that Inception and Volatility appear to be working identically, 
once I got past a Volatility error which seems to be occurring because the 
Firewire hardware I'm testing with incorrectly reports its max transfer size.

They're not working CORRECTLY, mind you, just identically. Both appear to image 
memory from the target, but both generate a python error at the end of the 
acquisition "failed to read from Firewire device". The memory dumps that both 
generate seem to behave the same when analyzed by Volatility, as well. When I 
run kdbgscan on either one, it appears to find a KDBG object, but lists it as 
having "0 processes" and "0 modules"

Thoughts?
John 

Original comment by johnmcca...@gmail.com on 22 Apr 2014 at 5:18

[GoogleCodeExporter]

I'm thinking this error I'm now getting on images captured by both utilities is 
the same as the one I was previously getting from Inception, as it looks the 
same when I run imageinfo.
John

Original comment by johnmcca...@gmail.com on 22 Apr 2014 at 5:35

[GoogleCodeExporter]

Hiya John,

Yes, version 0.2 didn't feature a patch I sent Freddie that had a typo in the 
read function which meant it wouldn't throw an exception on firewire read 
errors (you'd just get a whole bunch of 0s).

The question is how much memory the machine has, that you're trying to image.  
Firewire will only go up to 4Gb in its address space, and after that it'll 
stop.  Also, if you have exactly 4Gb in the machine, it'll probably be a little 
off.  If you have less, then you'll definitely fall off the edge of the memory, 
rather than stop gracefully.  Since there's no way to determine how much memory 
is available via firewire (other than trying to read it and fail with an 
exception), I'm not surprised at all that you're getting an exception at the 
end of reading.  That's expected behaviour.

As to why you're getting 0 for both processes and modules, I've helped debug 
someone's issue when they were grabbing 8Gb through firewire (since they'll 
only ever get 4 due to limitations in the firewire specification), so again, 
it's dependent upon how much memory you had in the machine you were imagining.

Firewire has never really been a stable and acceptable way to gather memory, 
it's much *more* stable now thanks to Freddie's work than it used to be, but 
it's still not perfect, and with the 4Gb limit its time is limited.  Perhaps 
something like thunderbolt will help advanced that, but so far the tech's too 
new to have anything working (that I'm aware of).

Original comment by mike.auty@gmail.com on 29 Apr 2014 at 12:02

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 18 Feb 2015 at 6:55

• Changed state: Duplicate