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 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)
We are very happy to announce that you can now see the table of contents
and search through the Art of Memory Forensics on Amazon!
http://amzn.to/1o3ACn7
This book, written by the core Volatility developers, is over 900 pages
of memory forensics and malware analysis across Windows, Mac, and Linux.
It will be officially released at Blackhat and around this time it will
also be available through Amazon and other retailers. It will be
available in both hard copy and digital formats.
If you have any questions about the book please let us know, and we will
have more information about the release at Blackhat as it gets closer.
--
Thanks,
Andrew (@attrc)
