Android forensics an Custom Recovery Image

Editor's Notes

• #4: Intake: Receive device as evidence. Receive request for examination Identification Identify device specifications & capabilities Identify Goals of Examination Identify legal authority for examination Preparation Prepare methods and tools to be used Prepare media and forensic workstation for examination Prepare tools to most recent version Isolation Protect the evidence – Prevent remote data destruction Isolate from the Cellular network, bluetooth, and Wi-Fi Processing Conduct forensic acquisition – Perform forensic analysis – Scan for malware Verification Validate your acquisition – Validate your forensic findings Documenting/Reporting Keep notes about your findings and process Draft and finalize your forensic reports Presentation Prepare exhibits – Present your findings Archiving Keep a gold copy of data in a safe place Keep data in common formats for future
• #6: Posted on May 19, 2014, by David Ashfield There are different methods of data extraction from mobile devices. Some data acquisition methods are more ‘forensically sound’, more invasive and more technical, thus requiring a greater analysis time from a specially trained forensic examiner. Logical Acquisition A logical data acquisition from a mobile device means that a bit-for-bit copy of ‘logical storage objects’ is extracted. Logical storage objects include files and directories that reside on logical storage (file system). The data extraction tool communicates with and request information from the mobile device’s operating system. A logical extraction extracts data using the manufacturers original API (application programming interface), this would normally be used by the user for synchronising the mobile devices data to a computer. The data is extracted using the mobile device’s operating system using a known set of commands such as AT-commands. Logical data acquisition has the advantage that it is much easier for forensic tools to extract system data structures and organise this data to the forensic examiner. A logical extraction is usually easier for a forensic examiner to work with, as this method of data acquisition will not produce a memory dump (binary blob) from the mobile device. A trained forensic examiner will be able to extract far more information from a mobile device physical extraction. File System Acquisition A logical data acquisition will not normally produce any deleted data, as it is normally removed by the mobile devices file system. Mobile devices that run popular operating systems such as Android and iOS are built using the SQLite database platform. When data is stored in a SQLite database on a mobile device and data is deleted, the data is not overwritten. When data is deleted in a SQLite database it is usually marked as deleted and made available to be overwritten at a later time. This means that if a file system data acquisition is available through a mobile device’s synchronisation interface, it will be possible to recover deleted data from SQLite databases. A file system extraction from a mobile device also has the advantage of showing the file structure, application data, web artefacts as well as allowing the forensic examiner to perform the analysis using tailored tools and scripts. Physical Acquisition A physical data acquisition from a mobile device means that a bit-for-bit copy of physical storage is extracted. This would give a forensic examiner a bit-for-bit copy of the mobile device’s flash memory, this is similar to the way data is acquired in traditional computer forensics. A physical data extraction extracts the data directly from the mobile device’s flash memory(s). After the data is extracted, the memory dump (binary blob) is then decoded. This type of extraction enables the maximum amount of deleted data to be recovered. Physical data acquisition is usually the most difficult extraction type to achieve, as the manufacturers of mobile devices secure against arbitrary reading of the device’s memory. Mobile device forensic tool manufacturers often develop custom boot loaders, allowing the forensic tool to access the mobile device’s memory and, in many cases bypass pattern locks or passcodes. Manual Acquisition A forensic examiner uses the mobile devices interface to investigate the data stored on the device. The forensic examiner will use the mobile device as normal, taking pictures/videos of the content displayed on screen. Data can also often be captured by connecting the mobile device to a computer using an AV (Audio/Video) adapter and taking screenshots of the device as it is navigated. Certain data types may not be extracted from certain mobile devices. For example where emails cannot be extracted from an iPad, the emails can be AirPrinted to .PDF files one email at a time. Manual data acquisition from mobile devices can be very time-consuming and only data visible to the operating system can be recovered. Manual acquisition will normally be used by a forensic examiner as a last resort.
• #15: The smudge attack relies on detecting the oily smudges left behind by the user's fingers when operating the device using simple cameras and image processing software. Under proper lighting and camera settings, the finger smudges can be easily detected, and the heaviest smudges can be used to infer the most frequent user input pattern (the password). The researchers were able to break the password up to 68% of the time under proper conditions. JTAG and Chip-off At this time, most Android devices do not encrypt the contents of the NAND flash, which makes directly accessing and decoding the memory chips a potential workaround if a pass code is enabled. There are two primary techniques, which provide direct access to the chips. Both are technically challenging. The two techniques are: Joint test action group (JTAG) Physical extraction (chip-off) Both techniques are not only technically challenging and require partial to full disassembly of the device, but they require substantial post-extraction analysis to reassemble the file system. For these reasons, JTAG and chip-off would likely be the very last choices to circumvent a locked device. With JTAG, you connect directly to the device’s CPU by soldering leads to certain JTAG pads on the printed circuit board (PCB). Then JTAG software can be 210 CHAPTER 6 Android forensic techniques used to perform a complete binary memory dump of the NAND flash, modify certain partitions to allow root access, or eliminate the pass code altogether. In the chip-off procedure, the NAND flash chips are physically extracted from the PCB using heat and air. The chip, usually a small ball grid array (BGA) package, then needs to have the BGA connections regenerated and inserted into special hardware that connects to the chip and reads the NAND flash. The advantages to these techniques are that they will work in any situation where the NAND flash is not encrypted. However, extensive research, development, testing, and practice are required to execute these techniques.
• #16: adb backup [-f <file>] [-apk|-noapk] [-shared|-noshared] [-all] [-system|nosystem] [<packages...>] http://lifehacker.com/the-most-useful-things-you-can-do-with-adb-and-fastboot-1590337225 http://forum.xda-developers.com/galaxy-nexus/general/guide-phone-backup-unlock-root-t1420351
• #36: Shared Preferences Shared preferences allow a developer to store key-value pairs of primitive data types in a lightweight XML format. Primitive data types that can be stored in a preferences file include the following: 1. boolean: true or false 2. float: single-precision 32-bit IEEE 754 floating point 3. int: 32-bit signed two’s complement integer Table 4.1 Common /data/data/<packageName> Subdirectories shared_prefs Directory Storing Shared Preferences in XML Format lib Custom library files an application requires files Files the developer saves to internal storage cache Files cached by the application, often cache files from the web browser or other apps that use the WebKit engine databases SQLite databases and journal files Data in the shell 107 4. long: 64-bit signed two’s complement integer 5. strings: string value, typically as a UTF-8 With these basic types, developers can create and save simple values that power their application. Shared preferences files are typically stored in an application’s data directory in the shared_pref folder and end with .xml. On our reference HTC Incredible, the Android phone shared preferences directory are five XML files: The com.android.phone_preferences.xml preferences file has examples of int, boolean, and string preferences: ahoog@ubuntu:~/data/data/com.android.phone/shared_prefs$ cat com.android.phone_preferences.xml <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <int name="vm_count_key_cdma" value="0" /> <boolean name="pref_key_save_contact" value="true" /> <string name="vm_number_key_cdma">*86</string> </map> As you can tell, the XML file describes the string encoding type at the start of the file, UTF-8 in this case. There are three preferences that save various settings and characteristics. Perhaps most interesting from a forensics standpoint is the updateAreaCode.xml: ahoog@ubuntu:~/data/data/com.android.phone/shared_prefs$ cat updateAreaCode.xml <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="MDN">312</string> </map> The mobile directory number (MDN) is queried and the area code for the device is stored in this file, presumably to allow a seven-digit dialing option in areas supporting that feature. Since many applications take advantage of the lightweight Shared Preferences method for storing key-value pairs, it can be a rich source of forensic data. This is especially true when examiners can recover older or deleted versions of the XML preferences file.