linux_find_file error

[rageek]

I am new to Volatility and am trying to recover a file from a Lime memory snapshot using volatility. I successfully linux_enumerate_files and linux_find_file -F, but when I try to use linux_find_file -i with the inode address, I get a Python error on 2.5 or physical address err on 2.4. I am not really python literate and cannot decide if this is the result of a code error or if it could result from my memroy file. Аny help or a bug fix if it is a bug, would be appreciated.

The details:

Linux kernel 3.9.9 SMP.
Memory snapshot taken with current Lime built on the target machine.
Have tried with Volatility 2.4, 2.5 and from git clone.

All three return the same for...

python ./vol.py -f /mnt/sdata/robert/mem.lime --profile=LinuxSlack-3_9_9x86 linux_find_file -F /home/sarah/graphics/lamp_WIP.xcf
Volatility Foundation Volatility Framework 2.5
*** Failed to import volatility.plugins.registry.dumpregistry (ImportError: No module named Crypto.Hash)
...   ...
*** Failed to import volatility.plugins.tcaudit (ImportError: No module named Crypto.Hash)
Inode Number          Inode File Path
        35391964 0xee98ab48 /home/sarah/graphics/lamp_WIP.xcf

But when I try to extract and save the file, with 2.4 I get this...

python ./vol.py -f /mnt/sdata/robert/mem.lime --profile=LinuxSlack-3_9_9-profilex86 linux_find_file -i 0xee98ab48 -O new.xcf
Volatility Foundation Volatility Framework 2.4
*** Failed to import volatility.plugins.malware.svcscan (ImportError: No module named Crypto.Hash)
...   ...
ERROR   : volatility.plugins.overlays.linux.linux: phys_addr_of_page: Unable to determine physical address of page. NUMA is not supported at this time.

And with 2.5 and git clone I get this...

python ./vol.py -f /mnt/sdata/robert/mem.lime --profile=LinuxSlack-3_9_9x86 linux_find_file -i 0xee98ab48 -O new.xcf
Volatility Foundation Volatility Framework 2.5
... ...
WARNING : volatility.debug    : Cant find object radix_tree_node in profile <volatility.plugins.overlays.linux.linux.LinuxSlack-3_9_9x86 object at 0xbfcbf6c>?
Traceback (most recent call last):
  File "./vol.py", line 192, in <module>
    main()
  File "./vol.py", line 183, in main
    command.execute()
  File "/home/robert/lime/volatility-git/volatility/volatility/plugins/linux/common.py", line 63, in execute
    commands.Command.execute(self, *args, **kwargs)
  File "/home/robert/lime/volatility-git/volatility/volatility/commands.py", line 145, in execute
    func(outfd, data)
  File "/home/robert/lime/volatility-git/volatility/volatility/plugins/linux/find_file.py", line 137, in render_text
    for (file_path, inode) in data:
  File "/home/robert/lime/volatility-git/volatility/volatility/plugins/linux/find_file.py", line 126, in calculate
    for page in self.get_file_contents(inode):
  File "/home/robert/lime/volatility-git/volatility/volatility/plugins/linux/find_file.py", line 238, in get_file_contents
    data = self.get_page_contents(inode, idx)
  File "/home/robert/lime/volatility-git/volatility/volatility/plugins/linux/find_file.py", line 202, in get_page_contents
    page_addr = self.find_get_page(inode, idx)
  File "/home/robert/lime/volatility-git/volatility/volatility/plugins/linux/find_file.py", line 193, in find_get_page
    page = self.radix_tree_lookup_slot(inode.i_mapping.page_tree, offset)
  File "/home/robert/lime/volatility-git/volatility/volatility/plugins/linux/find_file.py", line 170, in radix_tree_lookup_slot
    height = node.height
AttributeError: 'NoneType' object has no attribute 'height'

Looking into the module.dwarf file from the profile I do see multiple elements with radix_tree names or paths, although I have no idea how to interpret them.

I have made much use of duckduckgo and friends and read much from the VolatilityFoundation docs and here on github, but to no avail.

Could someone please nudge me in the right direction.

Thanks!

[Andrew Case]

Can you please git pull the latest Volatility and recreate your profile? I made a change to module.c that should include the proper structure definitions into the profile.

[rageek]

Thanks for the response Andrew!

I was able to recover the file I needed from the above memory snapshot by simply bypassing the line of code in the pythin file and having it return success instead. Poor hack, I know, but it resolved that immediate need.

That was on a machine at a different location so I will need to update on it, hopefully in the near future. In the mean time I will do the git pull and schedule some useful playtime locally so that I can learn my way around volatility better - the above use has been my only exposure!

Thanks again, and a belated happy new year!