Friday, November 30, 2012

Android phone Thumbdata - Part 3

In this blog, I wanted to look further into the data storage on Android phone and look at the files in the DCIM\.thumbnails folder. 

 The first files I wanted to look at was the .thumbdata3-.... files.  The first one had a modification time of the time I took the last picture with the phone and the other the modification time of the time I recorded the last video.

Further examination showed that the first file contains 9 thumbnail images starting with the first image I took and each record is 10000 bytes long, so just by looking at the file size, we can see how many image thumbnails each one of these files contain.  Thus, the second thumbdata file is used to keep track of the thumbnails related to the videos in DCIM\Camera folder.  Each thumbnail is stored as a JPEG image that can be manually carved out by selecting the range between the signatures FFD8FF - FFD9.  

The other files that were interesting for further analysis were the image_last_thumb and video_last_thumb files.  What was most interesting to see the modification time that showed the time when the last image was taken and not the last image that was viewed.  Same was the case with the video_last_thumb, it showed the modification time of the last video recording.  

11/30/2012
12:48am formatted using on the phone utility
12:58-12:59am took pictures 1-9
1:00 am pencil video was created
1:01am CD video was created

Thus, I wanted to see what these files contained since the file mane and modification times were not reflecting what they suggested.

The last events that actually happened on the phone was that I viewed one image and the first video.
1:19am image 6 viewed
1:20am  pencil video viewed

These two files begun with the following text:
                 image_last_thumb
                          'content://media/external/images/media/9‰PNG

                 video_last_thumb
                           .&content://media/external/video/media/2‰PNG

Thus, these files are keeping the last image and last video that was added to the storage media and not the files that were last viewed.  These are the imaged that show up when a user enters the Gallery application.  


The signature of the PNG chunk is clearly visible in these files, so simply cutting the leading text and splicing the correct files header for a PNG file will allow us to see the actual images.  So, I have created a PNG file and copied its 12 byte header into each one of these files.

The resulting files could be viewed in any image viewer and confirmed the content was matching the path and file name stored in these files and these files contained the last multimedia file added to the storage device and not the last image viewed.  It is interesting why Google chose to save the thumbnail images in JPEG format and the last thumb images as PNG. 


Conclusion

Always verify your hypothesis with manual methods instead of relying third party tools.  The ability to verify findings in this manner gives you more confidence and develops your analytical skills.

Android phone erase storage -Part 2

This time, I wanted to track files as they were created and modified on the phone.  ( see previous post for phone details )

Sequence of events:

12:48am  format SD card by the utility provided on the phone ( after wiping and verifying )
12:58-12:59am pictures were taken in sequence where the images showed numbers 1 - 9, 9 being the last image.
1:00am Created a simple video showing a pencil
101am Created a simple video showing a CD
1:18am Ejected the phone from the PC
1:19am Used the phone to view image 6 ( last image viewed )
1:20am Used the phone to view the pencil video ( last video viewed )
1:20am Connected the phone to PC to create a dd image
1:35am Unmounted SD card to prepare for erase
1:37am Used Erase SD card utility to erase the contents of the storage device
1:42am Mounted card in phone again
1:43am connected to PC and created another image to analyze

  

Were the files really lost?

Looking at the image after the SD card was formatted, showed FAT was reset to its initial state.

Erasing of the SD card, updated the default folder structure where the modified date showed the time the card was erased.  Interestingly, the previous DiskCacheIndex...tmp showed the erase time and the new DiskCachIndex...tmp showed the time the newly erased SD card was mounted.

The logical sector of the DCIM\Camera where the pictures and videos were stored.  The directory entries did not keep the metadata of previously stored files.

Directory content for folder DCIM\Camera before erasure.


 After erasure the entries were cleared.

The directory content that is not part of the default folders like the DCIM\.thumbnails folder was not reset.  It's content was set to unallocated, but was not changed.

All original files were verified to still exist on the drive including the thumbnail version of the images and the first frame of the videos.

Other locations also include path information and actual image copies in the com.cooliris.media folder.  I will post another blog on analyzing those files.   They were also intact after erasing the media.


Conclusion,

Erasing the storage device is really just a simple format of the device and all data can be carved out of the image.  Thus, using the erasure utility on the Android phone should not be relied on before disposing or recycling the cell phones.  Many third party utilities can perform a more reliable wiping of the storage device in USB mode for a more secure result.



Android phone SD card MBR - SCH-R720


I wanted to find out the storage format of my SCH-R720 Android phone.  I wanted to find out the default file and folders that are created by the phone, the file type it uses, and the VBR signature of the Android formatted storage device.

Model Number: SCH-R720
Android Version: 2.3.4
Baseband Version: S:R720.06 x.EH02
Kernel Version: 2.6.35.7
Build number: GINGERBREAD.EH02

Wipe the storage device and fill it with zeros

C:\fau-1.3.0.2390\fau\FAU.x86>wipe -w 00 \\.\physicaldrive1
Forensic Acquisition Tools, 1, 3, 0, 2390 wipe, 1, 3, 0, 2390
Copyright (C) 2002-2009 GMG Systems, Inc.

After the wipe, I have verified the wipe results by searching for anything else, but zeroes on the drive in FTK Imager regular expression ( [^\x00] ).

Formatting

jumpcode                         no. of fats               sectors per track           nt reserved                      volume/partition name
oem/id name                     root entries             no. of heads               extended boot signature         fat type
bytes per sector                 total sectors            hidden sectors              extended boot signature        executable signature
sectors per allocation          media type             total sectors                extended boot signature
reserved sectors                sectors per fat              drive id                          volume serial number
Formatting the the 2GB MicroSD storage device ( by default the phone formatted the drive to FAT16 ) resulted in the following default file structure ( the RED entry is a deleted entry ).  The LOST.DIR is the first directory entry and the volume was no name associated with it by default, thus LOST.DIR create time can be considered the initial format time/date.

 Filename Full Path Size Created Modified
[root]    \[root]\ 16384

VBR    \VBR 512

[unallocated space]    \[unallocated space]\ 0

file system slack    \file system slack 512

FAT1    \FAT1 122368

FAT2    \FAT2 122368

LOST.DIR    \[root]\LOST.DIR\ 32768 2012-Nov-30 00:48:04 2012-Nov-30 00:48:04
.android_secure    \[root]\.android_secure\ 32768 2012-Nov-30 00:48:04 2012-Nov-30 00:48:04
DCIM    \[root]\DCIM\ 32768 2012-Nov-30 00:48:04 2012-Nov-30 00:48:04
Android    \[root]\Android\ 32768 2012-Nov-30 00:48:05 2012-Nov-30 00:48:04
DiskCacheIndex-1701006599.tmp    \[root]\DiskCacheIndex-1701006599.tmp 0 2012-Nov-30 00:48:08 2012-Nov-30 00:48:08
data    \[root]\Android\data\ 32768 2012-Nov-30 00:48:05 2012-Nov-30 00:48:04
com.cooliris.media    \[root]\Android\data\com.cooliris.media\ 32768 2012-Nov-30 00:48:05 2012-Nov-30 00:48:04
cache    \[root]\Android\data\com.cooliris.media\cache\ 32768 2012-Nov-30 00:48:06 2012-Nov-30 00:48:06
local-album-cache    \[root]\Android\data\com.cooliris.media\cache\local-album-cache\ 32768 2012-Nov-30 00:48:06 2012-Nov-30 00:48:06
local-meta-cache    \[root]\Android\data\com.cooliris.media\cache\local-meta-cache\ 32768 2012-Nov-30 00:48:05 2012-Nov-30 00:48:04
local-skip-cache    \[root]\Android\data\com.cooliris.media\cache\local-skip-cache\ 32768 2012-Nov-30 00:48:05 2012-Nov-30 00:48:04
local-image-thumbs    \[root]\Android\data\com.cooliris.media\cache\local-image-thumbs\ 32768 2012-Nov-30 00:48:06 2012-Nov-30 00:48:06
local-video-thumbs    \[root]\Android\data\com.cooliris.media\cache\local-video-thumbs\ 32768 2012-Nov-30 00:48:06 2012-Nov-30 00:48:06
chunk_0    \[root]\Android\data\com.cooliris.media\cache\local-album-cache\chunk_0 10 2012-Nov-30 00:48:06 2012-Nov-30 00:48:06
index    \[root]\Android\data\com.cooliris.media\cache\local-album-cache\index 44 2012-Nov-30 00:48:06 2012-Nov-30 00:48:06
index    \[root]\Android\data\com.cooliris.media\cache\local-image-thumbs\index 18 2012-Nov-30 00:48:08 2012-Nov-30 00:48:08

Next time, I will explore picture and video storage formats and the reliability of the "Erase SD card" feature the phone provides.  I'm curious to find out if that option is a format or a wipe utility.