Android forensics an Custom Recovery Image
•Download as PPTX, PDF•
13 likes•6,898 views
Mobile Forensic Process Different Mobile Forensic Scenario Acquisition Guide Challenges of Android Forensics How to Circumvent the Pass Code Types Of Analyses(Logical analysis) Types Of Analyses(Physical analysis) Android Partition Layout Custom Recovery Modifications How Data are Stored In Android Example of Useful Data extracted from Android Image
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Android forensics an Custom Recovery Image
Similar to Android forensics an Custom Recovery Image (20)
Recently uploaded
Recently uploaded (20)
Android forensics an Custom Recovery Image
- 1. Android Forensics Presented By: Mohamed Khaled Thanks to: Ibrahim Mosaad Mohamed Shawky
- 2. Agenda • Mobile Forensic Process • Different Mobile Forensic Scenario • Acquisition Guide • Challenges of Android Forensics • How to Circumvent the Pass Code • Types Of Analyses(Logical analysis) • Types Of Analyses(Physical analysis) • Android Partition Layout • Custom Recovery Modifications • How Data are Stored In Android • Example of Useful Data extracted from Android Image
- 3. Mobile Forensic Process Intake Identification Preparation Isolation Processing Verification Documenting Presentation Archiving • Receive device as evidence. • Receive request for examination• Identify device specifications & capabilities • Identify Goals of Examination • Prepare methods and tools to be used • Prepare media and forensic workstation for examination • Prepare tools to most recent version • Protect the evidence – Prevent remote data destruction • Isolate from the Cellular network, bluetooth, and Wi-Fi • Conduct forensic acquisition – Perform forensic analysis – Scan for malware • Validate your acquisition – Validate your forensic findings• Keep notes about your findings and process • Draft and finalize your forensic reports • Prepare exhibits – Present your findings • Keep a gold copy of data in a safe place • Keep data in common formats for future
- 4. Data Acquisition Types Manual Logical Physical
- 5. scenarios The device might be found to be turned off after seizure. have internal or removable memory Locked /unlocked Have access via USB debug mode or not
- 6. Acquisition Guide A-(Unlocked) • Airplane Mode • SIM ID Cloning Isolate Device from the Network • Remove passcode • Enable USB debugging • Enable “Stay Awake” • Disable timed screen lock features Take the necessary steps to ensure physical device access is possible • Acquire supporting media • SIM card(s) • Media cards • Check associated media for device backups Physical Acquisitions
- 7. A1 - Isolate Device from the Network • Airplane Mode • Remove the SIM card. • Place device in a shielded bag, box, tent, or room.
- 8. A 2-Ensure physical device access is possible • Enable USB debugging • Enable “Stay Awake” option • Disable timed screen lock features
- 9. A3 - Physical Acquisitions • Acquire supporting media • SIM card(s) • Media cards • Check associated media for device backups(Connected PC or Network)
- 10. Acquisition Guide B-(Locked) 1 Physical access requires that USB debugging mode is enabled. Forensic tools will use custom bootloaders to bypass the passcode if applicable. 2 Acquire supporting media • SIM cards • Media card(s) 3 Check associated computers and media for device backups • Computers and media cards
- 11. Challenges of Android Forensics • Access to system partitions is Restricted to The Android OS. • Techniques for obtaining root privilege differ depending on Android version, device manufacturer and model. • The OS has Authentication mechanisms that uses passwords, tactile patterns or biometric information
- 12. How to Circumvent the Pass Code • The smudge attack • Flash a New Recovery Partition (Our Solution) • Know Gmail user name and password for the device • JTAG and Chip-off
- 13. Types Of Analyses(Logical analysis) • It is possible to backup all the present data in a cell phone without rooting – Using Android Debug Bridge (adb backup command). • $ adb backup -apk -shared -system -all -f %1.backup – created a backup file which was later converted to .tar archive • $ java -jar abe.jar unpack %1.backup %1.tar
- 17. Physical Analysis (Low level analysis ) • Low level analysis is based on exact, bit to bit, copy of userdata partition. • After the copy, this partition is stored as a single file. • which is later used as input for other analysis tools. • Only a root user can make such a copy, so the phone must have been rooted at first.
- 18. What is rooting? • Process of overcoming limitations imposed by manufacturers on smartphone or tablet owners. • Gives an owner the ability to replace and/or alter system applications and settings • Run applications requiring administrator-level privileges • This includes listing active mounted partitions and cloning them
- 19. Physical analysis(Recovery Mode) • Another Way to Do Physical Analysis is by using Recovery Rom • But first We Are Going to Talk About the Android Partition Layout
- 20. Android Partition Layout • boot loader • Splash • Boot • Recovery • System • Userdata or Data • Cache • Radio
- 21. Android Partition Layout (Cont.) • boot loader: Stores the phone’s boot loader program, which takes care of : – Initializing the hardware when the phone boots – Booting the Android kernel – Implementing alternative boot modes such as download mode. • boot: Stores the Android boot image, which consists of : – Linux kernel(zImage) – and the root file system ram disk (initrd). • splash: Stores the first splash screen image seen right after powering on the device.
- 22. Android Partition Layout (Cont.) • userdata (data): this is the device’s internal storage for – Application data – User files such as: pictures, videos, audio, downloads. – This is mounted as /data on a booted system. • system: Stores the Android system image that is mounted as /system on a device. Contains – the Android framework. – Libraries. – system binaries. – pre-installed applications.
- 23. Android Partition Layout (Cont.) • cache: Used to store various utility files such as : – recovery logs and update packages downloaded over-the- air. On devices with applications installed on an SD card – it may also contain the dalvik-cache folder, which stores the Dalvik Virtual Machine (VM) cache.
- 24. Physical analysis(Recovery Mode) • It is an operating designed to – apply updates – format the device – perform other maintenance on the devices. • The stock recovery mode on most devices is very basic – Only provides a number of limited functions – Does not provide root privileges in a shell.
- 25. Physical analysis(Recovery Mode) • Should use extreme caution when installing a custom recovery partition as the process often contains kernel and radio updates • Could render the device unusable “bricked”. • Extensive testing must be performed on a lab device first to ensure no issues occur. • Examiners should understand what is being modified on the device during the installation of a custom recovery firmware.
- 26. Custom Recovery Rom Examples • Cyanogenmod Recovery (clockworkmod) • TeamWin (TWRP)
- 27. Custom Recovery Modifications • We are going to modify in the Cyanogenmod source code • The source code is writen in C Programming language.
- 28. Custom Recovery Modifications Remove Security Pattern • The pattern file is at – /data/system/gesture.key • Other security pattern are in file – /data/system/password.key • We will also use the pre defined function”__system”. – Which will enable us to run Linux commands like ls,rm,…etc – __system("rm /data/system/gesture.key"); //remove the pattern – __system("rm /data/system/password.key"); // remove any other lock like face or voice or password.
- 29. • In order to do physical imaging you have to run command like – dd if = /dev/sda1 of =/media/pc/file.dd – Where if is the source(the media whci we want to image). – The of is the destination • So We have to know: – the name of the driver of the source partition (i.e /data or /system) – The name of the destination driver (USB Flash for example) Custom Recovery Modification Physical imaging
- 30. How To Know The Name Of The Driver For The Source Partition • Using the file – /etc/recovery.fstab • We will search in the /etc/recovery.fstab till we find the driver name equivalent to the partition we want to image
- 31. Who to Know The name Of The Destination Driver (USB Flash for example) • Vold: The volume manager daemon. • Automatically Mount Sdcard and USB Flash memory (If connected) – When Device Startup – OR When Connected • We are going to search in the Vold till we find USB or SdCard.
- 32. How Data are Stored In Android • Android provides developers with five methods for storing data to a device. 1. Shared preferences 2. Internal storage 3. External storage 4. SQLite 5. Network
- 33. How Data are Stored In Android(Shared preferences) • Allow a developer to store key-value pairs of primitive data types in a lightweight XML format. – /data/data/<com.android.contacts>/shared_prefs • Used to set the programs configuartion
- 34. How Data are Stored In Android (Internal storage) • Contain more complicated data structures. • The files are stored in the application’s /data/data subdirectory. • Files can only be read by the application. • Indicate data that may be of interest to a forensic analyst
- 35. How Data are Stored In Android (External storage) • Files stored on the internal device’s storage have strict security and location parameters. • Files on the various external storage devices have far fewer constraints. • Emulated SdCard and Actual SdCard • Examples – Pictures,Videos,…,etc
- 36. How Data are Stored In Android (SQLite) • Databases are used for structured data storage – SQLite is a popular database format appearing in – many mobile systems – traditional operating systems. – /data/data/<packageName>/databases. • SQLite databases are a rich source of forensic data.
- 37. How Data are Stored In Android (Network) • Very few applications took advantage of the network as a storage option. • The Android Developer web site provides very few details for those interested in network storage. • You can use the network (when it is available) to store and retrieve data on your own web-based services. – Dropbox – Google Drive – Onedrive
- 38. Example of Useful Data extracted from Android Image • Android Browser Password – /data/data/com.android.browser/databases/webv iew.db • .table • select * from password; – data/com.android.chrome/app_chrome/Default/L ogin • Open Login Data file using txt viewer – /data/misc/wifi/ • Open wpa_supplicant.conf file using txt viewer.
- 39. References • Android Forensics – by Andrew Hoog • Android Hacker's Handbook – Joshua J. Drake,Pau Oliva Fora,Zach Lanier,Collin Mulliner,Stephen A. Ridley andGeorg Wicherski • Developing Process for Mobile Device Forensics – Det. Cynthia A. Murphy • Android Forensics, Part 1: How we recovered (supposedly) erased data – https://blog.avast.com/2014/07/09/android-foreniscs-pt-2-how-we-recovered-erased-data/ • http://www.cclgroupltd.com/mobile-device-forensics-data-acquisition- types/ • http://www.cclgroupltd.com/mobile-device-forensics-data-acquisition- types/ • http://forum.xda-developers.com/galaxy-nexus/general/guide-phone- backup-unlock-root-t1420351
Editor's Notes
- 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
- 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.
- 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.
- 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
- 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.