Linux profile w/LiME not working
by Brian Keefer
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
9 years, 1 month
- 3
- 6
OSDFC submission, Blackhat Arsenal, & LinkedIn Group!
by Andrew Case
We wanted to give everyone a quick update on some recent events in the
Volatility community.
First, the submissions for the Open Source Digital Forensics Conference
are available for voting. This conference's talk selection works by
posting each CFP submission in anonymized form and choosing talks based
on voting feedback from the community.
All of the talks can be found here:
http://www.basistech.com/osdfcon/osdfcon-vote-for-presentations
The submission from the Volatility Team is 'Next Generation Memory
Forensics'. If it sounds interesting to you then please give it a +1!
Second, our submission to Blackhat Arsenal was accepted!
https://www.blackhat.com/us-14/arsenal.html#Ligh
At this event we will be releasing the highly anticipated Volatility 2.4
that includes support for Windows 8, 8.1, 2012, 2012 R2 as well as new
plugins for Truecrypt, Linux, and Mac.
As Blackhat gets closer we will have more information on other events
there including a book signing and release party.
Finally, we now have a LinkedIn group for the Volatility and memory
forensics community:
https://www.linkedin.com/groups?mostRecent=&gid=8128809
This group is meant to allow analysts and researchers to ask questions,
learn from each other, and network. The group is open to all but marked
private to (hopefully) avoid spam.
--
Thanks,
Andrew (@attrc)
9 years, 11 months
- 1
- 0
Process hollowing
by Carlos Angeles
Hello all,
I'm analyzing a malware sample that is doing process hollowing. While
doing dynamic analysis, with Process Explorer open, I can see the
legitimate EXE (that appears to get hollowed) get started by the
malware, and is then orphaned as the malware terminates itself. A few
seconds later I see network communication starting.
The malfind plugin identifies the process as malware but when I try to
dump process from memory, the strings on the dumped process look the
same as the strings of the legitimate file in the System32 folder.
Using the yarascan plugin (following the example on the wiki) I'm able
to locate some strings (domain name, IP address, file requested by
GET) that are associated with the PID of the suspected hollowed
process.
Oh, and the malware is packed so I assume the unpacked code is being
placed into the address space of the legitimate file in memory.
The capture is a .vmem from a VM snapshot.
Any thoughts on how I can locate the unpacked code in memory?
Shouldn't dumping the PID with procexedump contain the unpacked code?
I've dumped the process by PID and physical offset (from psscan).
Thanks,
Carlos
9 years, 11 months
- 2
- 6