vol-users,
Registration has officially opened for the 6th Annual Open Memory
Forensics Workshop (OMFW) 2014. This half-day workshop will be held prior
to the 2014 Open Source Digital Forensics Conference (OSDFC) in Herndon,
VA, USA, on November 4, 2014.
"OMFW is the only digital forensics workshop focused on providing a venue
for the most advanced digital investigators. It is intended for those
people who realize that the only real defense against a creative technical
human adversary is a creative technical human analyst. No shady vendors
trying to describe how they re-implemented open source tools or boisterous
trainers attempting to discuss topics they only superficially understand.
This is your opportunity to learn directly from an international cadre of
pioneering researchers and practitioners who have been shaping the field
of memory analysis since its inception. Through a series of invited talks
you will have the opportunity to engage this exciting community."
We are still accepting presentations from people who are performing
innovative memory analysis research or from people who have interesting
case studies where memory forensics provided a critical component of the
investigation. If you are interested in participating, please contact us.
Submissions are due no later than October 1, 2014.
This year's workshop will also present the results of The 2nd Annual
Volatility Framework Plugin Contest! If you are interested in presenting
at the conference, submitting a contest entry is another option. Selected
contestants may be asked to present their work at the workshop and have it
featured on the Volatility Labs Blog. All contest submissions are due by
September 1, 2014.
To learn more about the workshop, read testimonials of previous attendees,
and find out what makes OMFW so unique, please visit the workshop website:
http://www.volatilityfoundation.org/#!2014/cwat
Details about the location will be provided upon registration.
Pre-registration is required and space is LIMITED, so register early.
Please note that it will NOT be possible to register at the door.
Registration closes on October 24, 2014.
Reserve your seat by contacting: info [at] volatilityfoundation [dot] org.
Thanks,
AAron Walters
The Volatility Foundation
The Volatility Team is happy to announce that Volatility 2.4 is now
publicly released.
Volatility 2.4 adds support for Windows 8, 8.1, 2012, and 2012 R2 memory
dumps, Mac OS X Mavericks (up to 10.9.4), and Linux kernels up to 3.16.
It also contains a large number of new plugins and features. Full
information can be found here:
http://volatility-labs.blogspot.com/2014/08/presenting-volatility-foundatio…
Please let me know if you have any issues or questions with the release.
--
Thanks,
Andrew (@attrc)
Hi all
I am wanting to perform memory introspection in my xen setup. I have been
using libvmi with volatility to analysis memory dumps of a domU. I have
done and tested it in Dom0 and it works.
I now want to create a similar setup in a pv domU but i am unable to get
libVMI working,.
Since i can use xl dump-core <domid> <filename> in my pv to extract any hvm
dump. I am using xsm and i have added all the necessary rules for memory
extraction.
This is the command i use to analysis the dump extracted using xl dump-core
note: i created the Linuxkbeastx86 profile to the kernel i have
infecting kbeast and this profile worked in dom0 when i used libVMI dump
memory but in the pv it does not, also tested xl dump with volatility in
dom0 and it did not work.
So can volatility process xl dump ?
below is the example out put i get
python /root/Volatility/vol.py -f /root/kbeastDump --profile=Linuxkbeastx86
linux_check_modules
Volatility Foundation Volatility Framework 2.3.1
Module Name
-----------
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
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
PyVmiAddressSpace: Location doesn't start with vmi://
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: ELF error: did not find any PT_NOTE segment with
VBCORE
VMWareSnapshotFile: Invalid VMware signature: 0x464c457f
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile Linuxkbeastx86 selected
IA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemory: Failed valid Address Space check
PyVmiAddressSpace: Must be first Address Space
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Failed valid Address Space check
if anyone could give me some advice on this
Thank you
I am writing to help spread the word of the first annual Malware Memory
Forensics (MMF) workshop that will be held along side ACSAC later this
year in New Orleans:
http://www.acsac.org/2014/workshops/issues/
I am on the review committee and the conference is being organized by
academics with deep experience related to malware and memory forensics
(e.g. General Co-Chair Golden Richard was who we chose as tech editor
for The Art of Memory Forensics).
If you are working with Volatility and performing your research inside
the framework then this is the perfect venue for a formal/academic
publication of your research . If you are a student, it would be an
ideal fit for Masters or PHD projects, and if you are in industry then
this conference works well as a bridge between industry and academia.
Any questions can be sent to myself or to Golden (CC'ed).
--
Thanks,
Andrew (@attrc)
Anyone have any idea what is causing this error with mftparser?
I have tried this in volatility versions 2.3 and 2.4. Might be a config issue with my system but not sure what it might be, so I thought I would ask the group.
Volatility Foundation Volatility Framework 2.4
Scanning for MFT entries and building directory, this can take a while
Traceback (most recent call last):
File "vol.py", line 192, in <module>
main()
File "vol.py", line 183, in main
command.execute()
File "/Users/dnardoni/volatility/volatility_24/volatility/commands.py", line 127, in execute
func(outfd, data)
File "/Users/dnardoni/volatility/volatility_24/volatility/plugins/mftparser.py", line 728, in render_body
for offset, mft_entry, attributes in data:
File "/Users/dnardoni/volatility/volatility_24/volatility/plugins/mftparser.py", line 706, in calculate
mft_entry.add_path(temp.FileName)
File "/Users/dnardoni/volatility/volatility_24/volatility/obj.py", line 747, in __getattr__
return self.m(attr)
File "/Users/dnardoni/volatility/volatility_24/volatility/obj.py", line 721, in m
return element(self)
File "/Users/dnardoni/volatility/volatility_24/volatility/plugins/mftparser.py", line 497, in <lambda>
'FileName': lambda x : obj.Object("FILE_NAME", offset = x.obj_offset + x.ContentOffset, vm = x.obj_vm),
File "/Users/dnardoni/volatility/volatility_24/volatility/obj.py", line 377, in method
proxied = self.proxied(name)
File "/Users/dnardoni/volatility/volatility_24/volatility/obj.py", line 433, in proxied
return self.v()
File "/Users/dnardoni/volatility/volatility_24/volatility/obj.py", line 443, in v
(val,) = struct.unpack(self.format_string, data)
struct.error: unpack requires a string argument of length 2
Dave
Hi all,
I pre-ordered “The Art of Memory Forensics” at March 22nd :-) and as of
today delivery is estimated for September 1st :-(. I really hope there
is a chapter about debugging the memory acquisition process. ;-)
Meanwhile may I kindly ask for your advice/hints how to debug the
following? I am not able to successfully acquire and analyze a Nexus S
Android memory dump.
Where could I start to look for errors?
How can I assure that the dump is valid?
How can I assure that the profile is valid?
Any hint is highly appreciated! :-)
Thank you,
Philipp
************************************************************
0 Where I failed :-(
Google at [1] offers three “Factory Images ‘soju’ for Nexus S (worldwide
version, i9020t and i9023)”:
2.3.6 (GRK39F)
4.0.4 (IMM76D)
4.1.2 (JZO54K)
Up to now I tried the first two.
Just in case the two memory dumps as well as the two Volatility profiles
are available here:
https://mega.co.nz/#F!CEczgBqR!ksYLENHXoMCU8qzSBn79WA
************************************************************
1 Nexus S with Android 2.3.6 Gingerbread
________________________________________
1.1 Prepare the phone
1.1.0 Boot loader is unlocked:
$ adb reboot bootloader
$ fastboot oem unlock
1.1.1 Get the factory image from [2] and flash it
$ tar –zxvf soju-grk39f-factory-5ab09c98.tgz
$ cd soju-grk39f
$ adb reboot bootloader
$ ./flash-all.sh
1.1.2 Start phone
Click through the initial settings
Enable USB debugging
Get version info:
$ adb shell
$ cat /proc/version
Linux version 2.6.35.7-gf5f63ef
(android-build(a)apa28.mtv.corp.google.com) (gcc version 4.4.3 (GCC) ) #1
PREEMPT Tue Aug 2 13:57:05 PDT 2011
1.1.3 Root the phone
Get custom recovery from [5] (…because otherwise ADB sideload SuperSU
won’t work) and flash custom recovery
$ adb reboot bootloader
$ fastboot flash recovery openrecovery-twrp-2.7.1.0-crespo.img
Get SuperSU from [6]
Sideload SuperSU
$ adb reboot bootloader
Go to “Recovery” -> “Advanced” -> “ADB Sideload” -> “Swipe to start
sideload”
$ adb sideload UPDATE-SuperSU-v2.01.zip
Reboot the phone
________________________________________
1.2 Prepare LiME
1.2.1 Get the Samsung kernel source from AOSP [7]
$ mkdir -p ~/android/kernel && cd $_
$ git clone https://android.googlesource.com/kernel/samsung.git
$ cd samsung
$ git checkout f5f63ef
1.2.2 Setting Up a Build Environment with AOSP from [8]
$ mkdir -p ~/android/aosp && cd $_
$ repo init -u https://android.googlesource.com/platform/manifest -b
android-2.3.6_r0.9
$ repo sync
$ . build/envsetup.sh
$ lunch full_crespo-user
Check compiler:
$ arm-eabi-gcc --version
arm-eabi-gcc (GCC) 4.4.3
Set environment variables:
$ cd ~/android/kernel/samsung
$ export ARCH=arm
$ export SUBARCH=arm
$ export CROSS_COMPILE=arm-eabi-
1.2.3 Compile the Samsung kernel
Configure the kernel:
$ make herring_defconfig
Build the Samsung kernel:
$ make
1.2.4 Download LiME from [9] and Cross Compile
$ mkdir -p ~/android && cd $_
$ svn checkout http://lime-forensics.googlecode.com/svn/trunk/ lime
$ cd ~/android/lime/src
Edit Makefile
(I take CCPATH from printenv | grep arm-eabi )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
obj-m := lime.o
lime-objs := tcp.o disk.o main.o
KDIR := ~/android/kernel/samsung
CCPATH := ~/android/aosp/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
PWD := $(shell pwd)
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-eabi- -C $(KDIR) M=$(PWD)
modules
$(CCPATH)/arm-eabi-strip --strip-unneeded lime.ko
$(MAKE) tidy
tidy:
rm -f *.o *.mod.c Module.symvers Module.markers modules.order \.*.o.cmd
\.*.ko.cmd \.*.o.d
rm -rf \.tmp_versions
clean:
$(MAKE) tidy
rm -f *.ko
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Build LiME module:
$ make
________________________________________
1.3 Dump volatile memory
$ adb push ~/android/lime/src/lime.ko /sdcard/lime.ko
Screen must be unlocked now in order to grant ADB shell root access
$ adb shell
$ su
# insmod /sdcard/lime.ko "path=/sdcard/lime.dump format=lime"
# exit
$ exit
$ adb pull /sdcard/lime.dump ~/android/dump/NexusS_2.3.6.dump
________________________________________
1.4 Build a Volatility Profile
Get Volatility from [10]:
$ svn checkout https://volatility.googlecode.com/svn/trunk/
~/android/volatility
$ cd ~/android/volatility/tools/linux
Edit Makefile:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
obj-m += module.o
KDIR := ~/android/kernel/samsung
CCPATH := ~/android/aosp/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
-include version.mk
all: dwarf
dwarf: module.c
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-eabi- -C $(KDIR)
CONFIG_DEBUG_INFO=y M=$(PWD) modules
dwarfdump -di module.ko > module.dwarf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Build module:
$ make
Zip profile:
$ zip
~/android/volatility/volatility/plugins/overlays/linux/_NexusS_2.3.6_GRK39F_.zip
module.dwarf ~/android/kernel/samsung/System.map
________________________________________
1.5 Examine the Memory Dump with Volatility
$ cd ~/android/volatility/
$
$ python vol.py --info | grep Linux
Volatility Foundation Volatility Framework 2.3.1
Linux_NexusS_2_3_6_GRK39F_ARM - A Profile for Linux
_NexusS_2.3.6_GRK39F_ ARM
linux_banner - Prints the Linux banner information
linux_yarascan - A shell in the Linux memory image
$
$ python vol.py --profile=Linux_NexusS_2_3_6_GRK39F_ARM -f
~/android/dump/NexusS_2.3.6.dump linux_pslist
Volatility Foundation Volatility Framework 2.3.1
Offset Name Pid Uid Gid
DTB Start Time
---------- -------------------- --------------- --------------- ------
---------- ----------
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
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
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: 0x1
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile Linux_NexusS_2_3_6_GRK39F_ARM
selected
IA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemory: Failed valid Address Space check
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Failed valid Address Space check
________________________________________
1.6 First attempt to debug
$ xxd -l 32 ~/android/dump/NexusS_2.3.6.dump
0000000: 454d 694c 0100 0000 0000 0040 0000 0000 EMiL.......@....
0000010: ffff ff4f 0000 0000 0000 0000 0000 0000 ...O............
=>
magic: 0x4c69 4d45 -> LiME
version: 0x0000 0001 -> 1
s_addr: 0x0000 0000 4000 0000
e_addr: 0x0000 0000 4fff ffff
reserved: 0x0000 0000 0000 0000
=> Address range is:
$ python -c 'print int(0x4fffffff) - int(0x40000000) + 1'
268435456
But file size is much bigger:
$ stat -c %s ~/android/dump/NexusS_2.3.6.dump
401604672
268.435.456 Bytes + 32 Bytes Header != 401.604.672 Bytes file size!!!
************************************************************
2 Nexus S with Android 4.0.4 Ice Cream Sandwich
________________________________________
2.1 Prepare the phone
2.1.0 Boot loader is unlocked
2.1.1 Get the factory image from [3] and flash it
$ tar –zxvf soju-imm76d-factory-ca4ae9ee.tgz
$ cd soju-imm76d
$ adb reboot bootloader
$ ./flash-all.sh
2.1.2 Start phone
- as described before –
$ cat /proc/version
Linux version 3.0.8-g6656123 (android-build(a)vpbs1.mtv.corp.google.com)
(gcc version 4.4.3 (GCC) ) #1 PREEMPT Thu Feb 2 16:56:02 PST 2012
2.1.3 Root the phone
- as described before -
________________________________________
2.2 Prepare LiME
2.2.1 Get the Samsung kernel source from AOSP [7]
$ mkdir -p ~/android/kernel && cd $_
$ git clone https://android.googlesource.com/kernel/samsung.git
$ cd samsung
$ git checkout 6656123
2.2.2 Setting Up a Build Environment with AOSP from [8]
$ mkdir -p ~/android/aosp && cd $_
$ repo init -u https://android.googlesource.com/platform/manifest -b
android-4.0.4_r1.1
$ repo sync
$ . build/envsetup.sh
$ lunch full_crespo-user
Check compiler:
$ arm-eabi-gcc --version
arm-eabi-gcc (GCC) 4.4.3
Set environment variables:
$ cd ~/android/kernel/samsung
$ export ARCH=arm
$ export SUBARCH=arm
$ export CROSS_COMPILE=arm-eabi-
2.2.3 Compile the Samsung kernel
- as described before -
2.2.4 Download LiME from [9] and Cross Compile
- as described before -
________________________________________
2.3 Dump volatile memory
- as described before –
$ adb pull /sdcard/lime.dump ~/android/dump/NexusS_4.0.4.dump
________________________________________
2.4 Build a Volatility Profile
Get and build Volatility - as described before -
$ zip
~/android/volatility/volatility/plugins/overlays/linux/_NexusS_4.0.4_IMM76D_.zip
module.dwarf ~/android/kernel/samsung/System.map
________________________________________
2.5 Examine the Memory Dump with Volatility
$ cd ~/android/volatility/
$
$ python vol.py --info | grep Linux
Volatility Foundation Volatility Framework 2.3.1
linux_banner - Prints the Linux banner information
linux_yarascan - A shell in the Linux memory image
Linux_NexusS_2_3_6_GRK39F_ARM - A Profile for Linux
_NexusS_2.3.6_GRK39F_ ARM
Linux_NexusS_4_0_4_IMM76D_ARM - A Profile for Linux
_NexusS_4.0.4_IMM76D_ ARM
$
$ python vol.py --profile=Linux_NexusS_4_0_4_IMM76D_ARM -f
~/android/dump/NexusS_4.0.4.dump linux_pslist
Volatility Foundation Volatility Framework 2.3.1
Offset Name Pid Uid Gid
DTB Start Time
---------- -------------------- --------------- --------------- ------
---------- ----------
No suitable address space mapping found
Tried to open image as:
- the rest as described before –
________________________________________
2.6 First attempt to debug
$ xxd -l 32 ~/android/dump/NexusS_2.3.6.dump
0000000: 454d 694c 0100 0000 0000 0040 0000 0000 EMiL.......@....
0000010: ffff ff4f 0000 0000 0000 0000 0000 0000 ...O............
=>
magic: 0x4c69 4d45 -> LiME
version: 0x0000 0001 -> 1
s_addr: 0x0000 0000 4000 0000
e_addr: 0x0000 0000 4fff ffff
reserved: 0x0000 0000 0000 0000
=> Address range is:
$ python -c 'print int(0x4fffffff) - int(0x40000000) + 1'
268435456
But file size is still bigger:
$ stat -c %s ~/android/dump/NexusS_4.0.4.dump
325775424
268.435.456 Bytes + 32 Bytes Header != 325.775.424 Bytes file size!!!
************************************************************
3 Links
[1] https://developers.google.com/android/nexus/images\#soju
[2] https://dl.google.com/dl/android/aosp/soju-grk39f-factory-5ab09c98.tgz
[3] https://dl.google.com/dl/android/aosp/soju-imm76d-factory-ca4ae9ee.tgz
[4] https://dl.google.com/dl/android/aosp/soju-jzo54k-factory-36602333.tgz
[5]
http://techerrata.com/file/twrp2/crespo/openrecovery-twrp-2.7.1.0-crespo.img
[6] http://download.chainfire.eu/supersu
[7] https://android.googlesource.com/kernel/samsung.git
[8] https://android.googlesource.com/platform/manifest
[9] http://lime-forensics.googlecode.com/svn/trunk/
[10] https://volatility.googlecode.com/svn/trunk/
Amidst the release of The Art of Memory Forensics and our upcoming
events at Black Hat, we also have scheduled several training courses for
the end of this year and early next year:
http://volatility-labs.blogspot.com/2014/07/announcing-windows-malware-and-…
Based on demand for trainings before the book's release and the amazing
pace of sales of the book (currently #1084 on Amazon), we imagine that
these classes will fill quickly. Please contact us ASAP if you would
like to attend.
Also, we reserve a small number of deeply discounted seats in each class
for full time college students studying in related fields. We offer this
to give students performing research access to the most advanced topics
in the field and also to help prepare the next wave of investigators. If
you are a college professor with students who may be interested or a
student yourself then please contact us.
--
Thanks,
Andrew (@attrc)
Tonight, myself, MHL, and Jamie will be on the Security Weekly (formerly
PaulDotCom) podcast discussing the new book:
http://securityweekly.com/2014/07/join-us-for-episode-380-with-andrew-case-…
If you cannot catch it live then they always post the recording within a
few days of the show.
Also, we are hearing that many people are getting their pre-order
shipping notifications for next week, and that the Kindle version is
already being sent to people's devices!
If you are going to be at Black Hat be sure to stop by on Thursday
during the book signing!
--
Thanks,
Andrew (@attrc)
It has been a busy year for the Volatility team, and we are inviting you
to celebrate the success with us at Black Hat and DFRWS. We have a
number of events happening across these conferences and have listed them
all in the following blog post:
http://volatility-labs.blogspot.com/2014/07/volatility-at-black-hat-usa-dfr…
We hope to see you all in Vegas and be sure to check out Dr. Golden's
talk if you will be at DFRWS!
--
Thanks,
Andrew (@attrc)
