May 2014 - Vol-users - volatilityfoundation.org

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

8 years, 8 months

3
6
0 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, 6 months

2
6
0 0

LiME in real world Android forensics

by masdif

Hi all, Android Memory acquisition will be part of a paper I have to write. So far I have no problem to follow the description for an AVD on https://code.google.com/p/volatility/wiki/AndroidMemoryForensic Please excuse this noob question (and my bad English) but I'm going crazy figuring this out: Can LiME be used in real life Android forensics that is Android memory is acquired without having to reboot the Android device beforehand? Let's say: I get an running Android mobile phone and for some lucky reason it is both rooted and the user interface unlocked. (Are there any statistics available how often this is the case?) My task is to acquire its RAM. As far as I understood in order to use Lime for RAM acquisition I have to a) get the Android kernel's source code from the manufacturer, b) cross compile a new kernel with some settings for later being able to insmod the LiME kernel module, c) flash the compiled kernel onto the phone and d) reboot the phone to get the new kernel running, which e) destroys all the RAM I wanted to acquire, before I can f) insmod LiME. Please be patient and give me a hint where I'm going wrong?! All papers I found so far used prepared phones. Thanks a lot and have a nice weekend, Philipp

9 years, 6 months

4
6
0 0

Many exciting updates in the world of Volatility!

by Andrew Case

There are many new developments in the world of Volatility that we are now happy to announce. - The 2014 Volatility Plugin Contest has started - We will be hosting a public training in Austin in December - We have partnered with GMG Systems to provide our students access to what we consider to be the most accurate and reliable memory acquisition tool available - The Volatility Foundation website is now live For complete information on these and more, please see the following blog post: http://volatility-labs.blogspot.com/2014/05/volatility-update-all-things.ht… -- Thanks, Andrew (@attrc)

9 years, 6 months

1
0
0 0

CentOS 5.8 profile not working

by Toan. Pham Van

Dear sir, Currently we doing investigate an security breach, our server is CentOS 5.8. After dump memory raw, we can not processing with Volatility. We have read the topic : http://lists.volatilityfoundation.org/pipermail/vol-users/2013-February/000… After edit to that DTB we found it work on LIME profile but doesn't work on Raw memory dump. Can we have some instruction how to convert Raw memory to LIME? Or how to debug to find correct DTB in raw memory only? Btw, we trying to brute force like your advise but it very long since the range is from -0x200000 -> 0x200000. Regards,

9 years, 6 months

1
0
0 0

Is there a public github branch for the osx 9.2 compatibility layer?

by Shannon Freude

I'm looking for a patch-set that gets OSX 9.2 dumps from OSXPmem at least marginally working. I know it's supposed to be in the upcoming vol-2.4 release, but I'ld really like to see the progress/use volatility instead of having to beat volafox in to shape to get 9.2 dumps to work.

9 years, 6 months

2
1
0 0

VAD nodes: Private memory, but Prototype PTEs?!

by Bridgey

Hi all, I'm trying to understand what I've misunderstood. Consider this entry from a run of vadinfo: VAD node @ 0x84f1f3b0 Start 0x7ffde000 End 0x7ffdefff Tag Vadl Flags: CommitCharge: 1, MemCommit: 1, NoChange: 1, PrivateMemory: 1, Protection: 4 Protection: PAGE_READWRITE Vad Type: VadNone First prototype PTE: 94181720 Last contiguous PTE: 94181728 This node represents a range which is private (PrivateMemory: 1). If it's private, i.e. not shareable, why are there Prototype PTEs? I though prototype PTEs were only used when a range was shareable? I have a few Vadl nodes like this. The VadS nodes in the output with 'PrivateMemory: 1' don't show any prototype PTEs. Any pointers greatly appreciated.

9 years, 7 months

1
0
0 0

USN Parser for volatility

by Spencer, Tom

Hello all, Just wanted to let people know I have released a USN Journal record parser plugin for volatility. https://github.com/tomspencer/volatility/tree/master/usnparser For anyone who wants a refresher on the USN journal and its forensic significance, I recommend these <http://journeyintoir.blogspot.com/2013/01/re-introducing-usnjrnl.html> sites <http://securitybraindump.blogspot.com/2011/07/dear-diary-today-i-was-infect…> . The USN journal has been very useful to us in a variety of circumstances, so I highly recommend including it in your work/timelining flow if you dont already. Ive even seen situations where journal records from external NTFS volumes persist in memory even after the device is removed, but those results have been inconsistent. This plugin should work on any version of Windows that does USN journaling (Vista/2008 and up, XP SP3 if you specifically turn it on), and it should play well with Unicode file names including calling out special Unicode characters like directional changes. For an example of calling out direction changes: 2014-04-16 20:51:23.116,0x257L,0x3L,0x14de3L,0x3L,0x4806360L,"utf-canary.<RLO>txt.scr",RENAME_NEW_NAME & CLOSE,ARCHIVE The <RLO> indicates a Unicode Right-To-Left Override character. This means that although the actual filename extension was txt.scr, a screen saver filetype which is expected to be an executable, it would have appeared to the user as utf-canary.rcs.txt which most users would expect to be a text file they could safely click. This is my first volatility plugin so Id love any feedback/suggestions/questions. Based on some feedback from MHL I'll be doing some testing to see if I should turn on timestamp validation by default, but I'm open to other changes/additions people would like to see. Basic notes on the plugin are below. Enjoy! Thanks, Tom A note on USN record versions. The literature I can find seems to suggest that starting with Windows NT 6.2 families (8/2012) the OS should be using version 3 records, and this plugin does support these records. That said, testing has shown that at least in memory, these OSs still seem to use v2 records. As such, unless otherwise specified with the -R3 flag, this plugin will always assume v2 records. In my testing there has been a significant number of duplicates in memory, so piping to sort u can be effective. Invocation example: CSV output $ vol.py --profile Win7SP1x64 -f Windows7SP1x64.vmem usnparser --output=csv Volatility Foundation Volatility Framework 2.3.1 timestamp,MFTEntry,MFTEntryUSN,Parent,ParentUSN,usn#,"Filename",Reason,Attributes 2014-01-26 09:01:19.079,0x5056L,0x1L,0x7beL,0x1L,0x10f35c0L,"ngen_service.log",EXTEND & CLOSE,ARCHIVE 2014-01-26 09:01:19.079,0x7d8L,0x86L,0x7beL,0x1L,0x10f3620L,"ngen_service.lock",CREATE & DELETE & CLOSE,ARCHIVE 2014-01-26 09:01:19.142,0x7d8L,0x89L,0x28eL,0x1L,0x10f39d8L,"GACLock.dat",CREATE,ARCHIVE & TEMPORARY 2014-01-26 09:01:19.142,0x7d8L,0x89L,0x28eL,0x1L,0x10f3a30L,"GACLock.dat",CREATE & DELETE & CLOSE,ARCHIVE & TEMPORARY .... BODY output, suitable for using with mactime $ vol.py --profile Win7SP1x64 -f Windows7SP1x64.vmem usnparser --output=body | head Volatility Foundation Volatility Framework 2.3.1 0|[USN JOURNAL] ngen_service.log EXTEND & CLOSE/USN: 17774016/PARENT MFT: 1982|20566|---a-----------|0|0|0|1390726879|1390726879|1390726879|1390726879 0|[USN JOURNAL] ngen_service.lock CREATE & DELETE & CLOSE/USN: 17774112/PARENT MFT: 1982|2008|---a-----------|0|0|0|1390726879|1390726879|1390726879|1390726879 0|[USN JOURNAL] GACLock.dat CREATE/USN: 17775064/PARENT MFT: 654|2008|---a--t--------|0|0|0|1390726879|1390726879|1390726879|1390726879 0|[USN JOURNAL] GACLock.dat CREATE & DELETE & CLOSE/USN: 17775152/PARENT MFT: 654|2008|---a--t--------|0|0|0|1390726879|1390726879|1390726879|1390726879 The current version's help output (flags specific to usnparser start at "-T, --timestamp"): $ vol.py usnparser -h Volatility Foundation Volatility Framework 2.3.1 Usage: Volatility - A memory forensics analysis platform. Options: -h, --help list all available options and their default values. Default values may be set in the configuration file (/etc/volatilityrc) --conf-file=/home/vol/.volatilityrc User based configuration file -d, --debug Debug volatility --plugins=PLUGINS Additional plugin directories to use (colon separated) --info Print information about all registered objects --cache-directory=/home/vol/.cache/volatility Directory where cache files are stored --cache Use caching --tz=TZ Sets the timezone for displaying timestamps -f FILENAME, --filename=FILENAME Filename to use when opening an image --profile=WinXPSP2x86 Name of the profile to load -l LOCATION, --location=LOCATION A URN location from which to load an address space -w, --write Enable write support --dtb=DTB DTB Address --output=text Output in this format (format support is module specific) --output-file=OUTPUT_FILE write output in this file -v, --verbose Verbose information --shift=SHIFT Mac KASLR shift address -g KDBG, --kdbg=KDBG Specify a specific KDBG virtual address -k KPCR, --kpcr=KPCR Specify a specific KPCR address -T, --timestamp Print timestamps instead of human-readable dates -E, --unixtime Use Unix Epoch 32-bit timestamps instead of native Windows 64-bit timestamps (loses subsecond accuracy). DOES NOT imply -T above. -C, --checktime Don't show entries with timestamps outside of unix epoch range to reduce corrupt entries -S, --strict Enable stricter checks on record integrity to further reduce corrupt entries -O, --offset Show the physical offset for each record -R RECORDTYPE, --recordtype=RECORDTYPE Force version of USN record (2 or 3) to search for. In testing so far all OS's seem to use version 2 records in memory (even 8.1/2012r2 which purport to use R3). As such, default is R2. -U, --unicode Show unicode (utf-8) filenames. Be aware that due to corrupted records there will likely be strange characters in some places. Using -C and -S can help cut this down. --------------------------------- Module USNParser --------------------------------- Scans for and parses USN journal records

9 years, 7 months

1
0
0 0

Volatility issue #383: Linux 'tmpfs' extraction on multiple CPU sytems

by Torres, Geoff (Global Cyber Security)

Hi, According to Volatility issue #383 'tmpfs' extraction doesn't work because Volatility doesn't support NUMA systems. Question 1 - Is it on the roadmap for future versions? I deal primarily with Multi-CPU cloud systems so this is definitely a desired feature. Question 2- Is it reasonably feasible to manually extract tmpfs from a system RAM dump? Following the 'linux_tmpfs' module through the debugger showed that it was able to locate the /dev/shm tmpfs file system (replicating 2 levels in my output directory), it just croaked when it came time to retrieve the actual file data. I figure that if I can manually determine whatever offset it needs then I can set the proper variable in a debug session. Any thoughts? Thanks, Geoff ============================== Geoff Torres HP Global Cyber Security 8000 Foothills Blvd. Roseville, CA. 95747 916-785-3323 ==============================

9 years, 7 months

1
0
0 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Vol-users May 2014