Dalvik Inspector
To establish the environment for conducting the tool analysis of Dalvik Inspector alpha (DI), various attempts to build a test environment were assembled on variety of operating systems and hardware. Each was configured with a minimum suite of software applications necessary to approach this research project: Eclipse Integrated Development Environment (IDE), Android Development Tools (ADT) Eclipse plugin which included the Software Development Kit (SDK) and Android Virtual Device manager (AVD), Android Native Development Kit (NDK), Git source code management tool, and LiME physical memory extractor. Unfortunately, the first three test environments were inadequate, unstable, or unable to successfully complete the various stages needed to conduct the analysis, each having its own hardware or software shortcoming that could not be easily resolved within the limited time allotted.
Figure 1. Santoku Community Environment v.0.4
Ultimately the environment used was the Santoku Community Edition v.0.4 distribution (figure 1) installed on an HP Pavilion TouchSmart Notebook PC running Lubuntu v.13.04 Linux OS. Santoku Community Edition is a free, open source suite of tools and applications dedicated to mobile forensics, mobile malware analysis, and mobile security packaged and distributed for public use by viaForensics. Once its distribution address was added to Lubuntu’s Debian source library, Santoku was installed like a typical Debian software installation using apt-get.
List of Android test subject devices
Android phones listed in Table 1 were chosen as test subjects to acquire physical memory images from, and a physical memory image of an HTC EVO 4G smartphone already in the LiME format was also procured from the Digital Forensics Research Workshop (DFRWS) The virtual device was created using AVD (figure 2) and manually run via command line using the emulator command.
Table 1. List of Android test subject devices
Figure 2. Nexus 4 virtual device running KitKat v.4.4.2
The ability to accurately capture content of physical memory from the Android devices is important. Sylve detailed the need for an Android-specific capture tool due to tool limitations and design differences between traditional Linux builds and Google’s Android
example :
Kollar’s fmem is widely used for Linux memory acquisition on Intel-based machines. Its basic operation created character device /dev/fmem that supported read and seek operations backed by physical memory, allowing dd and other similar userland applications to read memory from the running operating system. Internally fmem obtained the starting offset specified by the read operation, checked that the page corresponding to this offset is physical RAM and not part of a hardware device’s address space, obtained a pointer to the physical page associated with the offset, then wrote the contents of the acquired page to the userland output buffer. Unfortunately, the function used to perform the page check, page_is_ram, does not exist on the ARM architecture. Additionally, the dd application bundledwith common Android ROMs does not handle file offsets above 0x80000000 correctly.Traditional Android dd uses 32-bit signed integers for offsets and storing 0x80000000 causes a 32-bit signed integer overflow. It then uses a system call to interact with a kernel function that expects a 64-bit signed integer. This means the kernel function receives a sign-extended 64-bit integer, which will obviously produces incorrect results. In the case of 0x80000000, this transforms the address used by the kernel function into 0xFFFFFFFF80000000. These issues make both fmem and dd unusable for memory acquisition on a number of Android devices