I built LiME from the tarball on the project site (not latest svn) and was able to dump memory successfully (type=lime). After many trials and tribulations I was able to get the Volatility profile built for CentOS 5.3x64 (had to remove pmem from the Makefile). I put the profile in the correct directory, and vol.py --info lists it as expected, however when I try to use the profile with the memory image I get an error.
chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ vol.py --profile=LinuxCentOS_5_3x64 -f /fun/ir/geriatrix.lime linux_lsmod
Volatile Systems Volatility Framework 2.3_alpha
WARNING : volatility.obj : Overlay structure cpuinfo_x86 not present in vtypes
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
JKIA32PagedMemoryPae: No base Address Space
AMD64PagedMemory: No base Address Space
JKIA32PagedMemory: No base Address Space
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
MachOAddressSpace: MachO Header signature invalid
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
VMWareSnapshotFile: Invalid VMware signature: 0xf000ff53
WindowsCrashDumpSpace32: Header signature invalid
JKIA32PagedMemoryPae: Incompatible profile LinuxCentOS_5_3x64 selected
AMD64PagedMemory: Failed valid Address Space check
JKIA32PagedMemory: Incompatible profile LinuxCentOS_5_3x64 selected
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Incompatible profile LinuxCentOS_5_3x64 selected
On a hunch I checked the directory I built the profile in (copied headers & source from the target system):
chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ grep cpuinfo *
System.map-2.6.18-128.el5:ffffffff8006f328 t show_cpuinfo
System.map-2.6.18-128.el5:ffffffff80103251 t cpuinfo_open
System.map-2.6.18-128.el5:ffffffff8020eadb t show_cpuinfo_max_freq
System.map-2.6.18-128.el5:ffffffff8020eafa t show_cpuinfo_min_freq
System.map-2.6.18-128.el5:ffffffff8020f759 t show_cpuinfo_cur_freq
System.map-2.6.18-128.el5:ffffffff802f0bc0 D cpuinfo_op
System.map-2.6.18-128.el5:ffffffff80308420 d proc_cpuinfo_operations
System.map-2.6.18-128.el5:ffffffff803319a0 d cpuinfo_cur_freq
System.map-2.6.18-128.el5:ffffffff80331b20 d cpuinfo_min_freq
System.map-2.6.18-128.el5:ffffffff80331b60 d cpuinfo_max_freq
Platform running Volatility (2.3_alpha, latest from svn):
Linux hydra 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Source of memory image:
Linux geriatrix.smtps.net 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
What am I missing?
--
chort
Yesterday we published a new blog post on using bulk_extractor during
memory forensics investigations. The writeup focused on the ability to
create PCAP files of resident network data inside a memory capture. If
you are not using this capability in your investigations then you are
definitely missing out!
http://volatility-labs.blogspot.com/2015/01/incorporating-disk-forensics-wi…
--
Thanks,
Andrew (@attrc)
We are pleased to announce that BSidesNOLA 2015 will take place on
Saturday, May 30th in the heart of downtown New Orleans. Full details
can be found on the following page:
http://www.securitybsides.com/w/page/91550808/BSidesNOLA
Our call for papers is currently open and we will be accepting
submissions through March 1st. Please spend time on your CFP
submission(s) as we receive a large number each year and inevitably have
to reject some of them. If you look at our lineup from last year
(http://www.securitybsides.com/w/page/71231585/BsidesNola2014) and the
year before (http://www.securitybsides.com/w/page/62741761/BsidesNola)
you will see that we attract some of the best speakers and researchers
in the industry. You don't want to miss our speakers' party so send us
your best stuff!
Also, we are very excited to announce that Chris Rohlf will be keynoting
this year. He has many years experience in the industry and is currently
in charge of all penetration testing efforts inside of Yahoo. He will be
speaking on performing offensive computer operations at scale.
Please let us know if you have any questions, and if you plan to attend
you must register on the Eventbrite page!
--
Thanks,
Andrew (@attrc)
Was writing to let everyone know that the DFRWS challenge is out for
this year and it involves analyzing both a usual linux memory sample as
well as analyzing GPU memory from a nvidia device. The challenge's
creator worked with nvidia to have an acquisition tool capable of
getting the memory off the devices. The latest git version of Volatility
can analyze the Linux side, but the real purpose of the challenge is to
encourage memory forensics research against the GPU. Hoping for some
exciting results from it!
http://www.cs.uno.edu/~golden/gpu-malware-research.html
--
Thanks,
Andrew (@attrc)
vol-users,
If anyone is planning to attend ShmooCon today and wants to meet up,
please send me a note offlist. We can discuss features you would like to
see integrated into future releases, the benefits of Volatility training,
half-baked anti-forensics schemes, why Andrew only drinks Champagne, and
where we are headed with Volatility 3.0!
AAron Walters
The Volatility Foundation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi folks,
Sorry for the short notice. We have 4 seats available for our Malware
and Memory Forensics Training class in Ottawa in February. Send me a
note if you're interested. It will probably be the only time we're in
Canada in 2015.
Cheers!
MHL
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
iF4EAREKAAYFAlS0MwUACgkQXnt9v1O0LItfcAD+O6PZ8v4/nowcwbW3z8SCNMf1
KUXdE4fFu5jEUivfJYIA/0DzpkzsaViQ//bwuRse3kKGnrAmTwKVFpfZMJiAWO8j
=N5qi
-----END PGP SIGNATURE-----
WARNING : volatility.obj : NoneObject as string: Pointer Owner invalid
I saw some people also having the same issues, but I am not seeing the fix anywhere. Suggestions?