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
Hi,
currently I'm preparing a Volatility Workshop ... and writing the docs I did
run several plugins. My test case contains a Win7SP1x64 image.
Everything is fine, except the contrib/malware plugins (poisonivy, zeus) did
complain about:
This command does not support the profile Win7SP1x64
No I get this error message also for timeliner!? But timeliner did work
correctly past weekend, using the _same_ Win7SPx64 image!
Using a different image containing WinXP timeliner does work correctly.
I'm using Revision 3532.
What did happen with timeliner?
Regards,
Thomas
https://code.google.com/p/volatility/
The Volatility Foundation is thrilled to announce the official release
of Volatility 2.3! While the main goal of this release was Mac OS X (x86,
x64) and Android Arm support, we also included a number of other exciting
new capabilities! Highlights of this release include:
Mac OS X:
* New MachO address space for 32-bit and 64-bit Mac memory samples
* Over 30+ plugins for Mac memory forensics
Linux/Android:
* New ARM address space to support memory dumps from Linux and Android
devices on ARM hardware
* Plugins to scan Linux process and kernel memory with yara
signatures, dump LKMs to disk, and check TTY devices for rootkit hooks
* Plugins to check the ARM system call and exception vector tables for
hooks
Windows:
* New plugins:
- Parse IE history/index.dat URLs
- Recover shellbags data
- Dump cached files (exe/pdf/doc/etc)
- Extract the MBR and MFT records
- Explore recently unloaded kernel modules
- Dump SSL private and public keys/certs
- Display details on process privileges
- Detect poison ivy infections
- Find and decrypt configurations in memory for poison ivy, zeus v1, zeus v2 and citadelscan 1.3.4.5
* Plugin Enhancements:
- Apihooks detects duqu style instruction modifications
- Crashinfo displays uptime, systemtime, and dump type
- Psxview plugin adds two new sources of process listings from the GUI APIs
- Screenshots plugin shows text for window titles
- Svcscan automatically queries the cached registry for service dlls
- Dlllist shows load count to distinguish between static and dynamic loaded dlls
New Address Spaces:
* VirtualBox ELF64 core dumps
* VMware saved state (vmss)
* VMware snapshot (vmsn) files
* FDPro's non-standard HPAK format
* New plugins: vboxinfo, vmwareinfo, hpakinfo, hpakextract
We also wanted to take this opportunity to recognize those on the
development team who's continued dedication to open source forensics and
the Volatility community has made this release possible: Mike Auty, Andrew
Case, Michael Hale Ligh, Jamie Levy, and AAron Walters. These people
volunteer their time and skills to bring you the most advanced and
innovative memory forensics framework in the world! If you appreciate the
hard work they put into Volatility, I encourage you help defend the rights
of open source developers and support developer endorsed events! Finally,
shoutz to the Volatility Community for their continued support and
feedback! In particular, the following members of the Volatility community
made significant contributions to this release:
- Cem Gurkok for his work on the privileges plugin for Windows
- Nir Izraeli for his work on the VMware snapshot address space (see also the vmsnparser project)
- @osxmem of the volafox project (Mac OS X & BSD Memory Analysis Toolkit)
- @osxreverser of reverse.put.as for his help with OSX memory analysis
- Carl Pulley for numerous bug reports, example patches, and plugin testing
- Andreas Schuster for his work on poison ivy plugins for Windows
- Joe Sylve for his work on the ARM address space and significant contributions to linux and mac capabilities
- Philippe Teuwen for his work on the virtual box address space
- Santiago Vicente for his work on the citadel plugins for Windows
If you want to learn more about Volatility 2.3 or just hang out with the
Volatility development team, I encourage you to register for the Open
Memory Forensics Workshop 2013. Please register quickly, we will be
ending registration by COB Friday, October 25 (Today). There have been a
couple last minute cancellations, so you may still have a chance to
reserve a seat!
On 23-10-13 17:28, david nardoni wrote:
> Also I would try netscan instead of connscan for win7. But it sounds like a problem with the
> memory dump
>
Yeah I suppose the memorydump is *****ed... but wanted to make sure
since I heard some rumours about having problems with *large* dumps on x64.
And indeed I meant netscan, instead of connscan. My bad.
@MHL: Thanks. indeed, old svn version... I'm using too many machines I
guess. Just updated and reinstalled from trunk.
On 23-10-13 17:37, Jamie Levy wrote:
> You must have admin in order to acquire memory... How did you manage
> to get a sample without having admin? If you have a virtualized
> environment then you can acquire the memory from outside the machine
> without having admin privileges on the acquired machine, however
> (vmsn/vmss on esx for example).
Actually, I do not know. I wasn't involved in the actual incident until
some other guys decided to ask me.
It's a bare metal box, so no hypervisor involved. Furthermore, they
might have had admin but I'll probably create some new memory samples
tomorrow and getting admin in a timely manner is quite hard. Currently
the box is next to me so I can take some time to create a good sample.
On 23-10-13 17:30, Andrew Case wrote:
> Nice to hear from someone from our class =)
Nice to see all three teachers reply on-list. Hope you enjoyed teaching
the class as much as I did attending it.
>
> A few things about your post...
>
> 8GB on x64 is where several acquisition tools seem to break, so it is
> may be that and your output seems to indicate so.
Since the box is actually idling, I might remove a DIMM and thereby
create a nice 4GB environment. The reason for keeping the 8gigs in is
that it will improve my chances of having trace still in memory instead
of having those swapped/overwritten.
Is there a fast way to tell the image is bad? (yup I think my current
one is bad, but I'm going to need to test again by tomorrow) And, is the
slowness being indicative of having a bad image?
> Also, you are using Volatility 2.2 which is quite old at this point. I
> would recommend using the latest through SVN. Not only is there many
> bugfixes, but also new plugins, such as iehist
Yup. That's the plugin I was looking for. Guess I downloaded the release
version of volatility on this box, instead of getting it from SVN. Fixed
it, thanks!
> Also, we have full support for networking information on Windows 7
> x64, you just have to use the netscan plugin and not the others
> (sockets, sockscan, etc.).
Indeed.
> Do you have any other acquisition tools you can use or are your
> machines virtualized?
I can use whatever free tools I like, and am probably allowed to spend a
moderate amount of money in order to buy stuff. Buying tools will take
time though (boss has to acknowledge the order etc etc etc) so getting
free stuff is preferred.
The infected machines are not virtualised and the malware is probably
virtualisation-aware, so that's not an option I'm afraid.
Anybody got some more useful stuff? I used volatility quite a couple of
times but never created my own images on hardware (used either somebody
else's samples or VMs).
Cheers,
Boudewijn Ector
Hi guys,
Currently I've got a sample of an infected win7 machine with enough
memory (8gb) which is not being used by anything except for 'the
malware' (no running office etc) so quite a lot of stuff should not
have been swapped out of memory yet.
Strangely, I can't dump the process:
; vol.py -f dump.raw --profile=Win7SP1x64 procexedump -p 4932
--dump-dir results/4932.bin
Volatile Systems Volatility Framework 2.2
Process(V) ImageBase Name Result
------------------ ------------------ -------------------- ------
Okay so it might be not in memory anymore... fine. So let's scan for
network activity using connscan.
This does not yield any results either.... just like svcscan.
Also the image is very very slow... on a regular machine (core i5 2400,
20gb mem) running imageinfo on the 8gb images takes about 10 minutes.
Also malfind mentions :
WARNING : volatility.obj : NoneObject as string: Invalid Address
0x05140000, instantiating _MMADDRESS_NODE
WARNING : volatility.obj : NoneObject as string: Invalid Address
0x05140000, instantiating _MMADDRESS_NODE
WARNING : volatility.obj : NoneObject as string: Invalid Address
0x21A4C320A, instantiating _MMADDRESS_NODE
WARNING : volatility.obj : NoneObject as string: Invalid Address
0x21A4C320A, instantiating _MMADDRESS_NODE
Psxview says al processes are like this:
0x000000021a841060 <PROCESSNAME> 6640 False True False
False False
Isn't that just weird? (yes it's because psscan is the only module being
able to retrieve data from memory... but isn't that strange)
This makes me presume my memory images are broken. My collaegue
probably (!) used winpmem -f for doing this. What's the best way to
create a memory image on a windows7 x64 box without having admin? (these
boxes are remotely managed and it takes a looooot of time to make sure
an admin will do something).
Or is this just perfectly normal behaviour and is win7x64 just being
badly supported by volatility? (I know the networkbased plugins don't
work but that's okay... it's being mentioned in the docs)
Furthermore: during our recent volatility training (in amsterdam), we
used a plugin for getting data from internet explorer history. I had a
look online and didn't find it, is it non-public?
Cheers,
Boudewijn Ector
Dear all,
I tried to create a Linux profile according to [1].
Which packages are needed for an Ubuntu profile? I downloaded linux-headers-2.6.32-41_2.6.32-41.91_all.deb, extracted the file on a CentOS machine and pointed the Makefile to the header's path.
The error message was: /tmp/header/usr/src/linux-headers-2.6.32-41/lib/modules/2.6.32-41/build was not found.
1. Do I have to download any other packages?
2. Is it possible to compile module.c on another distribution or do I need a running Ubuntu 10?
Thank you in advance!
Chris
[1] http://code.google.com/p/volatility/wiki/LinuxMemoryForensics
Greetings,
Vol 2.3 built from svn. Yara built from yara-project. OS is OS X 10.8.5. I tore out all the old copies of volatility while trying to get this to work.
praha:mem kovar$ vol.py -f xp-base-44f9a302.vmem --profile WinXPSP3x86 yarascan -Y 'foo'
Volatility Foundation Volatility Framework 2.3
ERROR : volatility.plugins.malware.malfind: Please install Yara from code.google.com/p/yara-project
praha:mem kovar$ yara -v
yara 2.0 (rev:223)
bash-3.2# ls -l /usr/local/lib/libyara*
lrwxr-xr-x 1 root admin 15 Oct 12 12:36 /usr/local/lib/libyara.0.0.0.dylib -> libyara.0.dylib
-rwxr-xr-x 1 root admin 113736 Oct 12 12:36 /usr/local/lib/libyara.0.dylib
-rw-r--r-- 1 root admin 393560 Oct 12 12:36 /usr/local/lib/libyara.a
lrwxr-xr-x 1 root admin 15 Oct 12 12:36 /usr/local/lib/libyara.dylib -> libyara.0.dylib
-rwxr-xr-x 1 root admin 938 Oct 12 12:36 /usr/local/lib/libyara.la
-David
Greetings,
I had the 1.6 version installed. I tore it out and tried to build 1.7 but that is failing:
bash-3.2# python setup.py build
running build
running build_ext
building 'yara' extension
cc -fno-strict-aliasing -fno-common -dynamic -I/usr/local/include -I/usr/local/opt/sqlite/include -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/local/include -I/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c yara-python.c -o build/temp.macosx-10.8-x86_64-2.7/yara-python.o
yara-python.c:259: error: expected specifier-qualifier-list before ‘YARA_CONTEXT’
yara-python.c:321: error: expected declaration specifiers or ‘...’ before ‘YARA_CONTEXT’
yara-python.c: In function ‘process_externals’:
yara-python.c:338: warning: implicit declaration of function ‘yr_define_integer_variable’
yara-python.c:338: error: ‘context’ undeclared (first use in this function)
yara-python.c:338: error: (Each undeclared identifier is reported only once
yara-python.c:338: error: for each function it appears in.)
yara-python.c:342: warning: implicit declaration of function ‘yr_define_boolean_variable’
yara-python.c:346: warning: implicit declaration of function ‘yr_define_string_variable’
yara-python.c: At top level:
yara-python.c:358: error: expected declaration specifiers or ‘...’ before ‘YARA_CONTEXT’
yara-python.c: In function ‘Rules_new_from_file’:
Shall see if I can figure that out and then come back to Volatility.
-David
On Oct 12, 2013, at 12:43 PM, Lorenzo Cantoni <lorenzo.cantoni86(a)gmail.com> wrote:
> Did you installed also the python bindings? (yarapython)
>
> Il 12/ott/2013 19:37 "David Kovar" <dkovar(a)gmail.com> ha scritto:
> Greetings,
>
> Vol 2.3 built from svn. Yara built from yara-project. OS is OS X 10.8.5. I tore out all the old copies of volatility while trying to get this to work.
>
> praha:mem kovar$ vol.py -f xp-base-44f9a302.vmem --profile WinXPSP3x86 yarascan -Y 'foo'
> Volatility Foundation Volatility Framework 2.3
> ERROR : volatility.plugins.malware.malfind: Please install Yara from code.google.com/p/yara-project
>
> praha:mem kovar$ yara -v
> yara 2.0 (rev:223)
>
> bash-3.2# ls -l /usr/local/lib/libyara*
> lrwxr-xr-x 1 root admin 15 Oct 12 12:36 /usr/local/lib/libyara.0.0.0.dylib -> libyara.0.dylib
> -rwxr-xr-x 1 root admin 113736 Oct 12 12:36 /usr/local/lib/libyara.0.dylib
> -rw-r--r-- 1 root admin 393560 Oct 12 12:36 /usr/local/lib/libyara.a
> lrwxr-xr-x 1 root admin 15 Oct 12 12:36 /usr/local/lib/libyara.dylib -> libyara.0.dylib
> -rwxr-xr-x 1 root admin 938 Oct 12 12:36 /usr/local/lib/libyara.la
>
> -David
>
>
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
Hi List,
Running volatility-2.2.standalone.exe on Win7 Pro 64bit AMD with 32GB of
RAM.
I'm new to volatility and I'm attempting to use it to troubleshoot apps
that don't play nice with the Windows clipboard. I'm using the steps
here:
http://www.infosecisland.com/blogview/22429-Detecting-Window-Stations-and-C…
I changed my registry to force a complete memory dump by setting
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\CrashDumpEnabled
to be 1. (http://support.microsoft.com/kb/969028)
I used System Internal's NotMyFault tool with the /crash switch to
create the dump.
(https://code.google.com/p/volatility/wiki/CrashAddressSpace)
The resulting c:\windows\memory.dmp file is about 34GB in size.
When I launch volatility, this is as far as it gets:
C:\Users\taa\Downloads>volatility-2.2.standalone.exe -f
c:\windows\memory.dmp --profile=Win7SP1x64 wndscan
Volatile Systems Volatility Framework 2.2
It has been showing this for close to 3.75 hours. Task Manager shows two
instances of volatility-2.2.standalone.exe running, one at a constant
1,144K RAM usage, and the other instance with RAM usage constantly
changing in the range of 58MB to 73MB, averaging 13% CPU utilization. To
mean this indicates it is doing /something/ even if it is caught in an
infinite loop.
If it's reasonable for volatility to run this long and longer, I'll just
be patient, though it would be helpful if someone could give me an idea
of how long it might take.
If this is taking too long, what can I do to troubleshoot what it's doing?
Kind regards,
Todd
