RSS

Android Forensics

The article tries to cover various Android forensic techniques which can be helpful in a variety of situations. The techniques or discussions below can be either logical or physical however we will try to stick mostly to logical techniques. By word ‘logical’ I intend to say the technique would mostly involve accessing the file system etc. This article also assumes that the reader has basic knowledge about android programming and other concepts related to android. Primary steps involved in the Android forensics are passcode bypass and data extraction. Let’s proceed to learn more.

Bypassing the Android passcode:

Firstly it’s important to note that every technique comes with some limitation or the other. You will need to figure out which technique would help you depending on the circumstances. Circumventing the passcode may not be always possible. We will take a few scenarios and see how you can take advantage in each case.

There are currently 3 main types of pass codes supported by android devices – Pattern lock, PIN and alphanumeric code.

1. Smudge Attack:

This is not specific to any android device but used generally by forensic analysts where they can deduce the password of a touch screen mobile. The attack depends on the fact that smudges are left behind by the user’s fingers due to repeated swiping across same locations. The pattern lock or any pass code is something that the user will have to swipe every time that he wants to use his mobile. So we can infer that the smudges would be heaviest across the same locations and hence under proper lighting and high resolution pictures we can deduce the code. So during examining any device, forensic analysts usually take care to avoid hand contact with the screen so as to check for the smudge attack.

smudge attack

2.  If USB – debugging is enabled:

If USB debugging in android is enabled, then bypassing the lock code can be done in matter of seconds. Imagine an attacker wants to get access to his friend’s files and applications on his android mobile, you can first ask his handset for some false reason (ex to make a call) and turn on the USB debugging under Settings -> Developer Options ->USB debugging and hand over the mobile back to him. So later on any some convenient time, when you get access to the device you can exploit it using any of the following ways. Now adb (android debugging bridge) is primarily a command line tool that communicates with the device. ADB comes along with the android platform tools. To explain in simple terms, this is what happens when you deal with adb:

  • An adb daemon runs as a background process on each android device.
  • When you install android SDK on your machine, a client is run. The client can be invoked from shell by giving an adb command.
  • A server is also run in the background to communicate between the client and adb daemon running on the android device.

You can use any of the below methods to take advantage of the USB debugging to bypass the screen lock:

Using UnlockAndroid.apk:

Before going ahead with this process you can download the Unlockandroid.apk file from the below location.

URL: http://www.securitylearn.net/wp-content/uploads/tools/UnlockAndroid.apk 

1. Connect the device to the machine where Android SDK (including platform tools etc) is installed.
2. 
Open command prompt and type cd C:\android-sdk-windows\platform-tools>adb.exe devices.
3. 
The device must be identified by the adb if everything is going fine.
4. 
Now copy the above UnlockAndroid.apk file into C:\android-sdk-windows\platform-tools directory.
5. 
In command prompt type, C:\android-sdk-windows\platform-tools>adb.exe install UnlockAndroid.apk and observe that the application gets installed on the device.
6. 
Now to start the application just type: C:\android-sdk-windows\platform-tools>adb.exe shell am start -n com.rohit.unlock/com.rohit.unlock.MainActivity
7. Observe that the screenlock is bypassed now you can access all the application and folders in the mobile phone. Below is a screenshot of the process.

unlock android apk

Deleting the gesture.key file:

If the android device is using pattern lock and it it’s a rooted device then the below process can be tried which will bypass the screen lock.

1. Connect the device to the machine where Android SDK (including platform tools etc.) is installed.
2. Open command prompt and type cd C:\android-sdk-windows\platform-tools>adb.exe devices.
3. 
The device must be identified by the adb if everything is going fine.
4. 
Connect to adb shell by typing : adb.exe shell.
5. 
The terminal appears giving you access to shell. Now type rm /data/system/gesture.key. This is the file where pattern is stored.
6. 
Now after this, restart the phone and you will still observe that the device is asking for the pattern. However you can draw any random pattern and unlock the device.

Below is the screenshot of the process.

gesture key deletion

Updating the sqlite files:

If the phone is rooted, then by updating the sqlite files you can bypass the screen lock. Here are the details.

cd /data/data/com.android.providers.settings/databases
sqlite settings.db
update system set value=0 where name='lock_pattern_autolock';
update system set value=0 where name='lockscreen.lockedoutpermenantly';

Cracking the Android PIN:           

We have seen how to bypass the screen lock and how to completely delete or disable the lock screen. But what if we wanted to know the actual PIN so that you can lock/unlock at any time? In android, the PIN that user enters is stored in /data/system/password.key file. As you might expect, this key is not stored in plain text. It’s first salted using a random string, then the SHA1-hashsum and MD5-hashsum are calculated and concatinated and then the final result is stored. Seems very complicated but not to the modern computing power.

Below is the code for the same.

public byte[] passwordToHash(String password)
{
if (password == null)
   {      return null;   }
String algo = null;
byte[] hashed = null;
try {
      byte[] saltedPassword = (password + getSalt()).getBytes();
      byte[] sha1 = MessageDigest.getInstance(algo = "SHA-1").digest(saltedPassword);
      byte[] md5 = MessageDigest.getInstance(algo = "MD5").digest(saltedPassword);   hashed = (toHex(sha1) + toHex(md5)).getBytes();
      }
catch (NoSuchAlgorithmException e)
    {        Log.w(TAG, "Failed to encode string because of missing algorithm: " + algo);
    }
return hashed;
}<span style="font-size: 13px; line-height: 19px;"> </span>

Since the hash is salted it’s not possible to use a regular dictionary attack to the get original text. Here are the steps you can follow to try to crack the PIN.

1. Pull out the salt using adb. Salt is stored in the ‘secure’ table from /data/data/com.android.providers.settings/databases/settings.db
2. Get the password :  sha1+md5: (40+32) (stored at /data/system/password.key)

Ex:  0C4C24508F0D29CF54FFC4DBC5520C3C10496F43313B4D3ADDFF8ACDD5C8DC3CA69CE740

3. Once you have the md5 and the salt you can brute force using the tools available in market (Ex hashcat) to get password.

Data Extraction:

After having seen different ways to bypass the android screen lock, now let’s have a look at how to extract the data from an android phone. You can extract the data of all the files on the system or only those relevant files which you are interested in. But for any form of extraction it’s important that the device is unlocked or USB-debugging is previously enabled. There are 2 types of extractions.

Extracting through ADB: As explained earlier, adb is a protocol that helps you to connect to android device and perform some commands.

Boot Loader Extraction: This can be done when the device is in Boot Loader mode. This takes advantage of the fact that during boot loader mode the android OS will not be running.

Before extracting the data, it is important to know how the data is stored in android device so that we understand where to look for and which data to pull. Android stores the data mainly in the below 4 locations:

  1. Share Preferences: Data is stored in key-value pairs. Shared preference files are stored in application’s ‘data’ directory in the ‘shared_pref’ folder.
  2. Internal Storage: Stores data which is private in device’s internal memory (something like NAND flash).
  3. External Storage: Stores data which is public in device’s external memory which might not contain security mechanisms. This data is available under /sdcard directory.
  4. SQLite: This is a database which holds structural data. This data is available under /data/data/Package/database.

For example if you want to analyse the Facebook android application, here is how you do it. Download and install the Facebook application and sign in to it. Now as soon as you install any application in android, the corresponding application data is stored in /data/data folder. However due to the security restrictions, you cannot access or pull this data unless you have root privileges on the phone. By using adb let us see what the /data/data folder consists of. As shown in the below fig a quick ‘ls’ on the /data/data folder gives the below results.

data data folder

Whether its browser or gallery or contacts, everything is an app in android. They are the applications which come along with the phone. Application like games, social network apps etc. are the applications installed by the user. But the data belonging to any of these applications will be stored in /data/data folder. So the first step is to identify where your application is.

android app location

To see the contents of that application, ‘ls’ into that directory.

android app files

As you can see these are the folders created by the facebook application on your phone. For instance the cache folder may consist of images which are cached and stored for faster retrieval during normal browsing. The main area of focus would be the databases folder where the data related to the user would be stored. Here comes the concept of application security. If the application is secure enough, it would take proper steps not to store any of the sensitive data permanently in the databases folder. Let us see what kind of data Facebook stores the when you are currently logged in. For that you happen you can pull the android folder into your system using the below command.

C:\android-sdk-windows\platform-tools>adb.exe pull /data/data/com.facebook.katana C:\test

The databases folder must be now copied into the ‘test’ folder in your C drive.

copy fb db

In the ‘databases’ folder you see DB file types which are the sqlite files where the data is stored. To view the data present in them, you can use a browser such as Sqlite browser. Download and install SQlite browser. In the Sqlite browser, click on File à Open Database and select any of those DB files.

sqlitebrowser

 

This shows you the database structure and helps you to browse the data stored in them. Now logout of the application and you might notice that the data present in those tables would be deleted by the application.

So to conclude, in this article we have seen how to bypass the android screen lock under different conditions and how to extract the application data from android phone.

 

Posted by on May 27, 2013 in Android

Leave a comment

Tags: ,

Disable ASLR on iOS applications

ASLR – Address Space Layout Randomization is an important exploit mitigation technique introduced in iOS 4.3. ASLR makes the remote exploitation of memory corruption vulnerabilities significantly more difficult by randomizing the application objects location in the memory. By default iOS applications uses limited ASLR and only randomizes part of the objects in the memory. The image compares the different memory sections for partial and full ASLR applications.

partial vs full ASLR - iOS

In order to take full advantage of the ASLR, the application has to compile with -fPIE -pie flag (“Generate Position-Dependent Code” build option in Xcode). This flag is automatically checked by default in the latest version of the XCode (from iOS 6). So, all the applications that are compiled in the latest SDK will automatically use full ASLR. To find out whether the application is compiled with PIE flag or not, connect the iPhone over SSH and execute the below command.

Otool –Vh ApplicaitonBinary

PIE enabled iOS app

The above image shows PIE at the end of the file header. It indicates that the Facebook application is compiled with PIE flag and uses the full ASLR.

During the pentest, ASLR might cause issues while reversing or decrypting the application. To overcome this problem, Peter Fillmore wrote an awesome tool removePIE that can be used to disable the ASLR of an iOS application. It disables the ASLR by flipping the PIE flag.

Steps to disable the ASLR of an iOS Application:

1. Download removePIE.zip and extract it.
2. Copy removePIE to the iPhone using the below SCP command (password is alpine).

SCP removePIE root@iPhoneIP:/var/root

3. The SCP command copies the removePIE file into /var/root directory on the iPhone. This can be verified by connecting to the iPhone over SSH.

copy removePIE to iPhone

4. Copy removePIE to the corresponding application’s home directory.

removePIE to application directory

5. To disable ASLR of an application, run the removePIE command on the application binary.

./removePIE ApplicationBinary

disable ASLR of iOS app

The above command takes a backup of the application binary, then flips the PIE flag and disables the ASLR. This can be confirmed by running the otool -Vh ApplicationBinary command.

PIE disabled

The above image does not show PIE flag in the file header. It confirms that the Facebook application no more uses the full ASLR.

Note: removePIE does not accept the application path as an argument. Supplying the binary path to the program, ends up with segment fault:11 exception. 

References:
1. http://www.peterfillmore.com/2013/01/removepie-tool-for-disabling-aslr-on.html
2. iOS 4 security evaluation white paper by Dai Zovi

 

Posted by on May 23, 2013 in iPhone

3 Comments

Tags: , , ,

Penetration testing of iPhone Applications – Part 4

In the first part of the article, we have discussed about the iPhone application traffic analysis. Second part of the article covered the privacy issues and property list data storage. Third part covered in-depth analysis of the iOS keychain data storage. In this part we will take a look at different types of files stored/created in the application’s home directory and other insecure data storage locations.

Sqlite storage

Sqlite is a cross-platform C library that implements a self-contained, embeddable, zero-configuration SQL database engine. Sqlite database does not need a separate server process and the complete database with multiple tables, triggers, and views is contained in a single disk file. The Sqlite database offers all the standard SQL constructs, including Select, Insert, Update and Delete. As Sqlite is portable, reliable and  small, it is an excellent solution for persistent data storage on iOS devices.

Sqlite library that comes with iOS is a lightweight and powerful relational database engine that can be easily embedded into an application. The library provides fast access to the database records. As the complete database is operated as a single flat file, applications can create local database files and manage the tables & records very easily. In general, iOS applications use the Sqlite database to store large and complex data as it offers good memory usage and speed. Sqlite database that comes with iOS does not have a builtin support for encryption. So most of the iOS applications store lots of sensitive data in plain text format in Sqlite files. For example, to provide offline email access, Gmail iOS application stores all the emails in a Sqlite database file in plain text format.

Unencrypted sensitive information stored in a Sqlite file can be stolen easily upon gaining physical access to the device or from the device backup. Also, if an entry is deleted, Sqlite tags the record as deleted but not purge them. So in case if an application temporarily stores and removes the sensitive data from a Sqlite file, deleted data can be recovered easily by reading the Sqlite Write Ahead Log.

The Sqlite files can be created with or without any file extention. Most common extentions are .sqlitedb &.db. The below article explains, how to view Sqlite files and how to recover the deleted data from Sqlite files on the iPhone. For this exercise, I have created a demo application called CardInfoDemo. CardInfoDemo is a self signed application, so it can only be installed on a Jailbroken iPhone. The CardInfo demo application accepts any username & password, then collects the credit card details from the user and stores it in a Sqlite database. Database entries are deleted upon logout from the app.

Steps to install the CardInfo application:

1. Jailbreak the iPhone.
2. Download the CardInfoDemo,ipa file –  Download link.
3. 
On Windows, download the iPhone configuration utility – Download link.
4. 
Open the iPhone configuration utility and drag the CardInfoDemo.ipa file on to it.

iPhone configuration utility

5. Connect the iPhone to the windows machine using USB cable. Notice that the connected device is listed in the iPhone configuration utility. Select the device and navigate to Applications tab. It lists the already installed applications on the iPhone along with our CardInfo demo app. Cardinfo demo iOS app install

6. Click on Install button corresponding to the CardInfo application and it installs the CardInfo application on to the iPhone.

cardinfo ios demo app

Steps to view  CardInfo Sqlite files:

1. On the Jailbroken iPhone, install OpenSSH and Sqlite3 from Cydia.
2. 
On windows workstation, download Putty.
3. 
Connect the iPhone and the workstation to the same Wi-Fi network. Note: Wi-Fi is required to connect the iPhone over SSH. If the Wi-Fi connection is not available SSH into the iPhone over USB.
4Run Putty and SSH into the iPhone by typing the iPhone IP address, root as username and alpine as password.
5. 
Navigate to /var/mobile/Applications/ folder and identify the CardInfo application directory using ‘find . –name CardInfo’ command. On my iPhone CardInfo application is installed on the – /var/mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/ directory. 

cardinfo directory

6. Navigate to the /var/mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/CardInfo.app directory and notice CARDDATABASE.sqlite3 database file.

cardinfo sqlite file

7. Using sqlite3 command, view the CARDDATABASE.sqlite3 and notice that CARDINFO table is empty.

Note: Sqlite files can also be copied from the iPhone to a workstation over SSH and viewed using Sqlite data browser & Sqlite spy tools.

cardinfo sqlite before login

8. On the iPhone, open CardInfo application and login (works for any username and password).

cardinfo login

9.Enter credit card details and click on Save button. In the background, it saves the card details in the Sqlite database.

cardinfo - card details                    cardinfo - saved details

10. View CARDDATABASE.sqlite3 and notice that CARDINFO table contains the credit card details data.

cardinfo sqlite after save

11. Logout from the application on the iPhone. In the background, it deletes the data from the Sqlite database.

cardinfo logout

12. Now view CARDDATABASE.sqlite3 and notice that CARDINFO table is empty.

cardinfo sqlite after logout

Steps to recover the deleted data from CardInfo Sqlite file:

Sqlite database engine writes the data into Write Ahead Log before storing it in the actual database file, to recover from system failures. Upon every checkpoint or commit, the data in the WAL is written into the database file. So if an entry is deleted from the Sqlite database and there is no immediate commit query, we can easily recover the deleted data by reading the WAL. In case of iOS, strings command can be used to print the deleted data from a Sqlite file. In our case, running ‘strings CARDDATABASE.sqlite3’ command prints the deleted card details.

cardinfo sqlite recovered

In iOS, if an application uses the Sqlite database for temporary storage, there is always a possibility to recover the deleted temporary data from the database file.

For better security, use custom encryption while storing the sensitive data in Sqlite database. Also, before deleting a Sqlite record, overwrite that entry with junk data. So even if someone tries to recover the deleted data from the Sqlite file, they will not get the actual data. Use iOS data protection constants while creating the Sqlite files.

Cookies.binarycookies

Most of the iOS applications do not want to prompt the user for login everytime. So they create persistent cookies and store them in cookies.binarycookies file on the application’s home directory.  During penetration test, investigate the cookies.binarycookies file for sensitive information and to find session mangement issues. Cookies.binarycookies is a binary file and the content is not in readable format. So I wrote a python script BinaryCookieReader.py that can read the cookie file and display the content on the screen.

Steps to read the Cookies.binarycookies:

1. On Windows, download WinScp, Python & BinaryCookieReader.py.
2. 
Connect the iPhone and the workstation to the same Wi-Fi network.
3. 
Run WinScp and SSH into the iPhone by typing the iPhone IP address, root as username and alpine as password.
4. 
Navigate to the Library/Cookies folder in the application’s home directory.
5.
Copy the Cookies.binarycookies file to the windows machine by dragging it.

Cookies-Binarycookies-File

6. On windows, open command prompt and run the below command to list the contents of cookies.binarycookies file.

Python BinaryCookieReader.py [Cookies.binarycookies file path]

Below is the screenshot of cookies created by Facebook iOS Application.

facebook iOS cookie file

Keyboard Cache

In an effort to learn how user’s type, iOS devices utilize a feature called Auto Correction to populate a local keyboard cache on the device. The keyboard cache is designed to autocomplete the predictive common words. The problem with this feature is, it records everything that a user types in text fields. The cache keeps a list of approximately 600 words. The keyboard cache is located at Library/Keyboard/en_GB-dynamic-text.dat file. To view the Keyboard cache, copy the en_GB-dynamic-text.dat file to a computer over SSH and open the file using a Hex Editor. Below is the screenshot of a keyboard cache Hex view.

iOS keyboard cache

Keyboard Cache does not store the informtion typed in the fields which are marked as Secure. By default, passwords and strings with all digits (pins & credit cards) are marked as Secure. Hence the data typed in those fields does not store in the keyboard cache. But data typed in other text fields like username, security questions & answers might get stored in the keyboard cache. During a pentest clear the existing keyboard cache by navigating to iPhone Settings -> General -> Reset -> Reset Keyboard Dictionary (shown in the below image), then browse the application & enter data in text fields and anlyze whether the data is getting stored in the keyboard cache or not.

Clear iOS keyboard cache

During the application development, to disable auto complete for a text field, either mark it as secure (ex: mytextField.secureTextEntry = YES) or disable the autocomplete (mytextField.autocorrectionType = UITextAutocorrectionTypeNo;).

Along with the keyboard cache, when a user copies data from a textfield, iOS stores the data into a pasteboard (clipboard in other operating systems). The pasteboard is shared among all the application, so the information copied in one application can be accessed from other application by reading the pasteboard. If the application is dealing with senstive data, it is recommended to use private or application specific pasteboard.

Snapshot Storage

Pressing the iPhone home button shrinks the iOS application and moves it to the background with a nice effect. To create that shrinking effect, iOS takes a screenshot of the application and stores it in the Library/Caches/Snapshots folder in the respective application’s home directory. This might result in storing the user’s sensitive information on the device without user’s knowledge. Snapshots stored on the iPhone will automatically cleared after the device is rebooted.

Ex: Incase of Gmail iOS application, when a user press the iPhone home button after viewing the email, a snapshot of users’ email gets stored on the device without user’s knowledge. Below snapshot is captured after viewing a mail from the Citibank.

Gmail iOS App Snapshot Storage

During development, the application snapshot problem can be fixed in two ways.
1. Remove sensitive data or change the screen to blank before the applicationDidEnterBackground()
function returns.
2. Instead of hiding or removing sensitive data, application’s back grounding can be disabled altogether by setting the “Application does not run in background” property in the application’s Info.plist file.

File Cache

Along with plist files, sqlite files, binary cookies & snapshots, iOS applications can store other format files like pdf, xls, txt, etc. when viewed from the application. For example, in Yandex.Mail iPhone application, when a user views an attachment it gets stored on the device and remains on the device even after user logged out from the mail application. Applications which are storing temp files on the device, should clear those files upon logout/close for better security.  Below is the screenshot of Yandex.Mail attachement directory.

iOS Yandex Mail Attachement Storage

Error Logs

In general, iOS applications write data into logs for diagnostic and troubleshooting purpose. Also, during development, applictions developers commonly use NSLog for debugging purpose. These logs might include requests, responses, cookies, authentication tokens and other sensitive data. On the iPhone, data passed to the NSLog funciton is logged by Apple System Log (ASL) and the data remains on the log until the device is rebooted. Also, Error logs are not bounded by the application sandbox. Which means, error log generated by one application can read by other application. So if an application logs sensitive data, a malicious application can actively query for this data and send it to a remote server.

Error logs on the iPhone can be viewed directly using Console app. Console app is available in AppStore. Error logs can also be viewed using iPhone configuration utility or by syncing the device with iTunes and looking at CrashReporter folder.

For this exercise, I have created a demo application called CardInfoDemo. CardInfoDemo is a self signed application, so it can only be installed on a Jailbroken iPhone. The CardInfo demo application accepts any username & password, then collects the credit card details from the user and writes it into the error log.

Steps to view the error logs:

1. Install CardInfoDemo application on the iPhone.
2. On windows, install & open the iPhone Configuration Utility.
3. 
Connect the iPhone to the windows machine using USB cable. Notice that the connected device is listed in the iPhone configuration utility. Select the device and navigate to Console tab.
4. 
On the iPhone, open CardInfo application and login (works for any username and password).
5. 
Enter credit card details and click on Save button. In the background, it logs the card details.

CardInfoDemo iOS App

6. On the iPhone configuration utility console tab, you can notice the card details logged by the CardInfoDemo application.

iOS App Error log

For better security, do not log sensitive data. Also, remove debugging and troubleshooting logs from the application before publishing it.

Penetration Testing iPhone Applications is going to be covered in a series of articles. Below are the links for next articles. 

Part 5runtime analysis of iOS Applications.

References:

1. Debunking NSLog Misconceptions
http://blog.gdssecurity.com/labs/2012/3/28/debunking-nslog-misconceptions.html
2. What’s in your iOS Image Cache ?
http://software-security.sans.org/blog/2011/01/14/whats-in-your-ios-image-cache-backgrounding-snapshot
3. Hacking and Securing iOS Applications by Jonathan Zdziarski

 

Posted by on April 15, 2013 in iPhone

2 Comments

Tags: , , , , , , ,

Recovering data from the iPhone corrupted backups

At times when iTunes couldn’t finish the backup process (USB cable disconnect during backup/iOS upgrade, Power failure during backup), the backup gets corrupted and remains unreadable. As the corrupted backup does not contain meta files like Manifest.plist & Manifest.mbdb, it is not possible to restore the backup onto the iPhone and it is also not possible to read the backup using backup reader software like iPhone backup browser & iPhone backup extractor. So I wrote a python script iOS-corrupted-backup-reader.py that can read & recover data from the corrupted backups. Usage of the script is listed below.

Steps to use iOS-corrupted-backup-reader.py (Windows):

1. On windows, install Python 2.6.
2. Download iOS-Corrupted-Backup-Reader.py and place it in C:\ drive.
3. Create two folders backup & output in C drive.
4. From the iOS backup directory C:\Users\[user-name]\AppData\Roaming\Apple Computer\MobileSync\Backup\[iPhone-UDID]\,  copy all the files and place them in C:\backup directory.
5. Open  the command prompt, navigate to C:\ drive and type the below command.

\Python26\python.exe iOS-Corrupted-Backup-Reader.py c:\backup c:\output

6. It converts the backup files into readable format and places them in C:\output directory.

Steps to use iOS-corrupted-backup-reader.py (Mac OS X):

1. Create two folders backup & output on Desktop.
2. Download iOS-Corrupted-Backup-Reader.py and place it on Desktop.
3. From the iOS backup directory ~/Library/Application Support/MobileSync/Backup/[UDID], copy all the files and place them in backup directory.
4. Open the terminal and run the below command.

Python iOS-Corrupted-Backup-Reader.py ~/Desktop/backup/ ~/Desktop/output/

5. It converts the backup files into readable format and places them in output directory.

The script extracts and structures all the default files like Contacts, SMS, Calendar, etc. into directories with actual file names. Other third party application files are converted into readable format and gets stored in other-data folder in output directory without actual file names. Manifest.mbdb file maps the actual filenames to backup filenames and the mbdb file is not available in the case of corrupted backups. So it is not possible to get the exact file names. In general, most of the iOS applications store the data in plist, sqlite and Jpeg format. You can use plist editor sqlite spy and image viewers to open the files and read the data manually.

Note: Data recovery is only possible in the case of normal backups. If the backup is encrypted (encrypt backup option is checked in iTunes), it is not possible to read & recover the data from the corrupted backups.

 

Posted by on April 1, 2013 in iPhone

41 Comments

Tags: , ,

iOS – Sqlite3 command killed:9 problem

Executing commands on a Jailbroken iPhone (>iPhone 4), might suddenly fail and display killed:9 error. In that case, follow the below steps to resolve the problem.

Steps listed below explains how I fixed the Sqlite3 command killed: 9 error. The same technique works for other binaries and commands too.

Steps:
1. Create a self signed code signing certificate.

On Mac OS X, go to Keychain Access -> Certificate Assistant -> Create a Certificate. It opens the certificate assistant window. Enter name (in my case it is securitylearn.net) and select certificate type as Code signing. Check let me override defaults option. Hit continue until it creates the certificate.

OS X self signed certificate

After creation of the certificate, the keychain looks as shown in the image below.

Certificate in keychain1

2. Connect to the iPhone over SSH using Cyberduck.
3. Copy the sqlite3 executable located at /usr/bin from the iPhone to Mac.
3. Open Mac terminal and run the below command to sign the sqilte3 with self signed certificate.

Codesign -fs securitylearn.net sqlite3

4. Replace the sqlite3 executable on the iPhone with newly signed sqlite3.
5. Now executing sqlite3 command works without any errors.

 

Posted by on March 29, 2013 in iPhone

Leave a comment

Tags: , , ,

The Paraben’s iRecovery Stick Review

The Paraben’s iRecovery Stick is an USB flash drive designed to recover deleted data from the Apple iOS devices like iPhone, iPad & iPod touch. The product allows the investigators to recover data either directly from the device or from the iTunes back-up files. It is designed to support all iOS versions ranging from 1.x to 6.x and it works with iPhone 3GS, 4, 4S, 5 & other iOS devices. The iRecovery stick will not only recover the deleted data, it also downloads all the contents of the device. The article explains the usage of iRecovery stick and covers the pros and cons of it.

iRecovery stick features:

  • Downloads phone contents – downloads all the user data like photos, contacts, calendar, etc.
  • Recovers deleted data – recovers deleted text messages, contacts, call history, etc.
  • Easy to use – simply connect the iPhone and the iRecovery stick to the computer, then click the start button in the recovery software.
  • Portable – It is an USB thumb device and easy to carry.
  • Inconspicuous – It resembles a commonly used USB thumb drive, so it can be used as a spy device and no one would suspect that the device is used to recover data from the iPhone.
  • Works on backup files – recovers data from iTunes backup files.

 

Setup:

The iRecovery stick shipment box contains the iRecovery stick and an USB cable that is compatible with the iPhone 3GS, 4 & 4S. The iRecovery stick is compatible with Windows XP & 7 and provides an easy-to-use user interface. iRecovery stick does not support vmware/virtualbox environment and Linux & Mac OS X operating systems. Also, it is mandatory to turn off the antivirus software running on the Wndows OS for better data recovery. The iRecovery Stick is a portable and a simple to use USB flash drive which contains the recovery software – iRecoveryStick.exe. Recovery software included in the iRecovery stick can be installed on to the hard drive or it can be executed directly from the USB drive. Below image displays the contents of iRecovery stick USB drive.

iRecovery stick USB drive

Installation of the iRecovery software is well documented in the iRecovery Getting Started manual located in the USB flash drive.

Data acquistion and Recovery from the device:

The iRecovery Stick is very simple to use. Simply connect the iPhone to a Windows based computer with the USB cable and then connect the iRecovery stick to the same computer throuh an USB port. Once the two devices are connected, run the iRecoveryStick.exe program. Welcome screen of the iRecovery stick software is shown in the below image.

iRecovery stick device recovery

Once open, click on start recovery button (highlighted in the above image). Then the recovery software prompts to choose connected device as shown in the image below.

iRecovery stick connected device

Click on the device to start the recovery process (shown in the below image). The data recovery process will take several minutes to few hours to complete based on the size of the iPhone disk. During a test on Intel i5 2nd generation processor laptop it took 14 minutes to recover 256MB data from the iPhone 4.

iRecovery stick data recovery

The recovery process acquires existing data and recovers deleted data from the iPhone, but the majority of the data will be normal user’s data which has never been deleted. Once the recovery process is completed, then it immediately displays all the data recovered from the iPhone (shown in the below image). The recovery process downloads the existing contents of the phone such as contacts, call history, text messages, calendars, notes, pictures, multimedia and all other user’s data like safari history, safari bookmarks, GPS history & application cookies. It also recvovers different types of deleted data including text messages, contacts, call history, and calendar entries. The iRecovery stick is not capable of carving the file system, so it can only recover the deleted data from the Sqlite database files and does not recover the deleted files from the file system, i.e it does not recover the deleted photos.

iRecovery stick recovered data

The user interface also provides an option to generate easily readable report or to export the recovered data to Excel sheets. During a test, export to Excel option took more time than the actual recovery process.

iRecovery stick export to excel

The iRecovery stick does not have the capability to bypass the iPhone passcode. So if the device is protected with a passcode, unlock it before connecting it to the computer for recovery.

Data acquisition and Recovery from the backup:

The iRecovery Stick can also recover data from the iTunes backups. In general, iTunes backup contains a copy of everything on the device like contacts, SMS, photos, calendar, music, call history, notes, network settings, safari bookmarks, cookies and application data, etc. So the iRecovery stick recovers the same types of data it recovers from the iPhone itself. To recover data from the backups, run iRecoveryStick.exe and load the iTunes backup files created in Windows. Welcome screen of the iRecovery stick software is shown in the below image.

iRecovery stick backup recovery

Click on start import from iTunes backup button (highlighted in the above image). Then the recovery software prompts to choose specific iOS version as shown in the image below.

iRecovery stick backup recovery-1

Clicking on the specific iOS version prompts the user to open the existing iTunes backup as shown in the image below. In general iTunes backup gets stored in the below locations.

Windows XP – C:\Documents and Settings\[user name]\Application Data\Apple Computer\MobileSync\Backup\

Windows 7 – C:\Users\[user name]\AppData\Roaming\Apple Computer\MobileSync\Backup\

iRecovery stick open backup

Once the backup is selected, then the recovery process gets started. The data recovery process will take several minutes to few hours to complete based on the size of the backup files. During a test on Intel i5 2nd generation processor laptop it took 15 minutes to recover 300MB data from the iTunes backup.

Once the recovery process is completed, then it immediately displays all the data recovered from the backup files. The recovery process extracts the existing contents from the backup such as contacts, call history, text messages, pictures, multimedia and all other user data like user’s internet browsing history & application cookies. It also recvovers different types of deleted data from the backup including text messages, contacts, call history, calendar entries and notes.

The iRecovery stick can only recover data from the iTunes normal backups and it does not work with the iTunes encrypted backups.

What data is recovered:

Once the recovery process is completed, iRecoveryStick displays the recovered data in an easy readable format as shown in the image below.

iRecovery stick recovered data

The recovery process recovers the below existing data from the device/backup:

  • Messages – sent/received SMS messages including the exact date and time.
  • Contacts – phonebook data with creation and modification dates.
  • Call history – call logs including the exact duration time.
  • Graphics – photos & thumbnail images.
  • Organizer – calendar & notes.
  • Multimedia – mp3 files & recorded videos.
  • Internet data – safari history, safari bookmarks, safari suspend state, safari cookies, email accounts, youtbue bookmarks and application cookies.
  • Tracking history – geographical locations. It contains longitude and latitude coordinates along with a timestamp and is displayed in the Google Earth viewer.
  • Other data – this data includes maps history, maps bookmarks, maps directions and other properties.

 

The recovery process recovers the below deleted data from the device/backup:

  • Recovered data
    • Contacts
    • SMS
    • iMessages
    • Notes
    • Call history
    • Calendar data
    • Internet data
    • Tracking history

 

The iRecovery stick does not recover data from the iOS keychain file. Also, it does not recover the deleted files & photos.

Conclusion:

The iRecovery stick is a simple to use tool for data recovery from iOS devices. It recovers most of the data from the device, however it does not recover deleted files from the file system. Due to this limitation it may not be a great tool for forensic investigators. However this is the perfect device for employees, parents, spouses, boyfriends & girlfriends who wants to spy or recover the deleted SMS, contacts, call history and web history from iOS devices.

The paraben’s iRecovery stick costs around 200$. So in my personal opinion, I feel it is worth for money.

 

Posted by on March 21, 2013 in iPhone

2 Comments

Tags: , ,