Turn it off or not?

It has been a "gray" area in forensic acquisitions if we should turn a system off or not.  If we look at certification exam requirements, we have to pull the plug on client OS and turn the system off with OS commands if it is a server. 

In today's computers, we have 4GB or more memory that was the size of a hard drive not too long ago.  In a few years back, if someone said, "I've thrown an 8GB hard drive into the trash since I thought it was not important" would have landed investigators in jail.  We can not make those kind of decisions anymore just because we did it in the past. 

The memory is a wealth of information in malware investigations and dealing with encryption.  This also shown in the new tool "Elcomsoft Forensic Disk Decryptor". http://www.elcomsoft.com/efdd.htm


The documentation mentions how it recovers the master key from live memory or from the hibernation file.

"By analyzing the hibernation file (if the PC being analyzed is turned off);
 By analyzing a memory dump fie
 By performing a FireWire attack (PC being analyzed must be running with encrypted volumes mounted)."

Now, if that is the case, then turning the system off will lose this information and you can wait for weeks, if you're lucky, to crack the password for BitLocker, PGP or TrueCrypt. 

Why not just include into the methodology and certification exam requirements to at least consider the option of capturing the memory before turning the system off.  I like the option of forcing the hibernation file to update and then pull the plug if necessary. 

powercfg.exe -h off
powercfg.exe -h on

This way, you can turn your system off and still have the memory to analyze.

"Drawbacks?"  You might ask.
I believe digital forensics is just like any other science discipline is based on pattern recognition, risk management, and process control.  Therefore, we have to look at any drawbacks in this method.  Since the Hiberfil.sys file will be as large as the physical memory in the system, you will overwrite, 8GB in this case, unallocated space.  Thus, if you plan to data carve for previously deleted files, this might destroy evidence that can be just as much devastating to your case.  So, a light weight memory dump utility ( fau's dd, mdd, or winen ) might be the answer to this dilemma.  The main idea is to consider this option when encryption is suspected or as a standard collection methodology.

Cell Phone in Faraday Bag! Why?

As we test tools and technology in our ITDF 2320 course, we never know what information we can discover.  This week, we've tested the cell phone protection by placing them in Faraday bag and multilayer of antistatic bags. 

To our surprise, even though the Faraday bag work fairly well in some cases and not at all in others, in all cases the mesh on the Faraday bag interacted with the smart phone screen.  In one case, the movement of the bag over the screen caused the email client to open and to check one of the emails to be checked.  In most cases, just random movement was noticeable as the phone moved around in the bag. 

It might be strange to call a Faraday bag a protection mechanism when it causes more changes than just placing the phone in airplane mode and carrying it in a paper bag.

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.