custom Android profile: No suitable address space mapping found - Vol-users

26 Jun 2013

      Good day,

As the title suggests I am working with a custom Android installation and I have
encountered the "No suitable address space mapping found".

I have not cross-compiled lime.ko and module.ko with exactly the same compiler that I used
to build the rest of my installation but I have carried out the build pointing to the same
kernel directories and lime.ko can successfully be used to get a memory dump. Can this be
the reason for the inconsistency?

Here is what I did:

1. I have downloaded lime from svn:

URL: http://lime-forensics.googlecode.com/svn/trunk/src
Repository Root: http://lime-forensics.googlecode.com/svn
Repository UUID: e105e084-e930-c66b-6cfa-9f740464420f
Revision: 17
Node Kind: directory
Schedule: normal
Last Changed Author: Joe.Sylve(a)gmail.com
Last Changed Rev: 15
Last Changed Date: 2013-03-19 08:10:00 -0700 (Tue, 19 Mar 2013)

2. I have downloaded volatility from svn:

URL: https://volatility.googlecode.com/svn/trunk
Repository Root: https://volatility.googlecode.com/svn
Repository UUID: 8d5d6628-2090-11de-9909-f37ff7dbbc12
Revision: 3444
Node Kind: directory
Schedule: normal
Last Changed Author: michael.hale(a)gmail.com
Last Changed Rev: 3440
Last Changed Date: 2013-06-18 10:08:37 -0700 (Tue, 18 Jun 2013)

3. I have cross-compiled lime for a custom android installation and produced a kernel
module and with it I have successfully retrieved a memory dump of size a little less than
2GB.

1951400096 Jun 25 14:50 mem.dump

4. I have also created a profile pointing to the same custom android installatin:

*** note that pmem is not visited and pmem.c is not compiled ***

cd volatility/tools/linux
edit Makefile and cross-compile module.c and produce module.ko
dwarfdump -di module.ko > module.dwarf

head module.dwarf

.debug_info

<0><0x0+0xb><DW_TAG_compile_unit> DW_AT_producer<"GNU C
4.6.x-google 20120106 (prerelease)"> DW_AT_language<DW_LANG_C89>
DW_AT_name<"/home/antonios/dev/tools/volatility/tools/linux/module.c">
DW_AT_comp_dir<"/media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/out/target/product/jflteatt/obj/KERNEL_OBJ">
DW_AT_low_pc<0x00000000> DW_AT_high_pc<0x00000000>
DW_AT_stmt_list<0x00000000> <Unknown AT value 0x2134><0> <Unknown AT
value 0x2135><0>
<1><0x2d><DW_TAG_typedef> DW_AT_name<"__s8">
DW_AT_decl_file<0x00000001
/media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/kernel/include/asm-generic/int-ll64.h>
DW_AT_decl_line<0x00000013> DW_AT_type<<0x00000038>>
<1><0x38><DW_TAG_base_type> DW_AT_byte_size<0x00000001>
DW_AT_encoding<DW_ATE_signed_char> DW_AT_name<"signed char">
<1><0x3f><DW_TAG_typedef> DW_AT_name<"__u8">
DW_AT_decl_file<0x00000001
/media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/kernel/include/asm-generic/int-ll64.h>
DW_AT_decl_line<0x00000014> DW_AT_type<<0x0000004a>>
<1><0x4a><DW_TAG_base_type> DW_AT_byte_size<0x00000001>
DW_AT_encoding<DW_ATE_unsigned_char> DW_AT_name<"unsigned char">
<1><0x51><DW_TAG_typedef> DW_AT_name<"__s16">
DW_AT_decl_file<0x00000001
/media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/kernel/include/asm-generic/int-ll64.h>
DW_AT_decl_line<0x00000016> DW_AT_type<<0x0000005c>>
<1><0x5c><DW_TAG_base_type> DW_AT_byte_size<0x00000002>
DW_AT_encoding<DW_ATE_signed> DW_AT_name<"short int">

zip volatility/volatility/plugins/overlays/linux/mylinux.zip module.dwarf System.map

  adding: home/antonios/dev/tools/volatility/tools/linux/module.dwarf (deflated 92%)
  adding:
media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/out/target/product/jflteatt/obj/KERNEL_OBJ/System.map
(deflated 74%)

5. python vol.py --info

LinuxmylinuxARM - A Profile for Linux mylinux ARM

6. however 

python vol.py --profile=LinuxmylinuxARM -f mem.dump linux_pslist

results in:

Volatile Systems Volatility Framework 2.3_beta
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: 0x0
 WindowsCrashDumpSpace32: Header signature invalid
 AMD64PagedMemory: Incompatible profile LinuxmylinuxARM 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

I have not cross-compiled lime.ko and module.ko with exactly the same compiler that I used
to build the rest of my installation but I have carried out the build pointing to the same
kernel directories and lime.ko can successfully be used to get a memory dump. Can this be
the reason for the inconsistency?

Antonios