Saturday, April 27, 2013

See ya later, Sammy Sung!

This capstone project has sadly come to an end. While I'm excited to start a new adventure and move on from Champlain College, I will definitely miss so much about it. My final paper on Samsung Galaxy Camera forensics is finished, but has not yet been graded. I'd still like to share the some of my findings here for others to test and learn from, as well as have others share with me any of their research. I'll go through some of the applications I found to be of most interest during my research, but my all means is not my final paper. If anyone would like to read my complete paper, feel free to email me at catstamm60@gmail.com


Chrome  

Searches were conducted in Chrome within an incognito window, but not data was found. Data created in a normal Chrome window, was found in the path data/data/com.android.chrome/app_chrome/Default/Favicons- journal. Although the history had been cleared on the camera, Google searches for “champlain.edu”, “dogs”, “how many people are in the world”, “jobs in Burlington”, “long island rail road”, and “heady topper” were all found. Even the deleted bookmark for “jobs in Burlington” was present in the file (Figure 1). Unfortunately, this journal file could not be exported and was only viewed within EnCase.













Figure 1
Default Browser

The default browser stores most of its data in its own database file called browser2.db, which is found at data\data\com.android.browser\databases. While looking through the database file, bookmarks from both Google Chrome and the default browser were found along with their created timestamps. Although the database showed bookmarks from Google Chrome, it only showed deleted bookmarks coming from the default browser (Figure 2 highlighted) and not the deleted ones coming from Chrome. 


Figure 2
There were Google searches made for “dinner recipes”, “tattoo Burlington”, “how big is the earth”, “New York Islanders”, “what movies are playing”, “android phones”, “teddy bear” and “Barack Obama”. The URL “baseball.com” was also typed into the default browser. After those words were searched for and links were clicked for them, the default browser’s history and cache was cleared. The file browser2.db did not show the complete web history in a database browser. Instead, taking a look at browser2.db-wal provided all internet searches (Figure 3). 

Figure 3
Incognito pages were used in this browser as well. Only one out of the two incognito Google searches that was found was “fish tank”. This piece of data was found in the directory data\data\com.google.android.googlequicksearchbox\cache\http. The file name for this search is c0f4d2b80c1a2e84bfc574014997b7d9.0 (Figure 4). While the file does not directly state it’s from an incognito page, the URL “google.com/proxy” may suggest that it is.

Figure 4


Downloads 

Data downloaded to the download application was found in the sisodownloads.db file located at \data\data\com.sec.android.providers.downloads\databases. Five pictures were downloaded from the internet on March 14, 2013. They were of a white android phone, an android phone chart, two bears together, a bear with a heart, and the bear from Ted. In Figure 5, the names of three downloads can be found. 

Figure 5



To determine what these pictures actually are, a search in EnCase was conducted (Figure 6). Only three downloads were found because the other two were deleted. The picture of Ted (Figure 7) was eventually found in \data\media\Android\data\com.sec.android.gallery3d\cache\nearby_cache, but the picture of the white android phone was nowhere in EnCase. 

Figure 6


 
Figure 7

 
Since the deleted Ted picture was found, it was likely that the picture of the white android phone was somewhere on the device. Because EnCase did not seem to find it, the file system dump done with the Cellebrite UFED Pro was analyzed to understand where the deleted file was stored.

While scrolling through the pictures Cellebrite found, the white phone was present. Its file name is .thumbdata3—1967290299_embedded_105.jpg. The full path to the deleted picture is shown in Figure 8.

Figure 8


 
While continuing analyzing the contents of the file system dump from Cellebrite, the directory “tdata” (Figure 9) was spotted. This directory did not show up in EnCase and in it were hundreds of embedded pictures separated into three folders: imgcache.0.EMBEDDED, imgcacheMicro.0.EMBEDDED, and imgcacheMini.0.EMBEDDED. Both the picture of Ted and the picture of the white android phone were found in the folder imgcacheMicro.0.EMBEDDED (Figure 10).


Figure 9
Figure 10

Gallery

EnCase successfully found all of the pictures that were currently present on the camera, but did not find any pictures that were deleted. False positives were found, as the camera was synced with Dropbox from the beginning of the project. Photos were automatically uploaded to Dropbox once they were taken and were stored there. When pictures were deleted from the Gallery, they were still found by EnCase in the Camera Uploads folder for Dropbox. 

Manually navigating through the photos on the camera with EnCase, three pictures were found in \data\media\DCIM\.thumbnails. The pictures were taken on January 1, 2012 before the camera was received for this project. It was later found out that these pictures came from a user who had the camera first and then reset it for this project. Aside from those three pictures, no other deleted pictures taken by the camera were found in the thumbnails folder.

Delving back into the file system dump provided by Cellebrite, the previously mentioned directory “tdata” was looked into more thoroughly. That was the location of the deleted downloaded picture of the bear Ted, so it was the next logical place to look.


The file within this directory that was most prominent in finding deleted pictures was imgcacheMicro.0. It was here that all pictures ever taken with the camera were found. This included deleted pictures, S Memo notes, screenshots, downloaded pictures and pictures shared over WiFi. The imgcacheMicro.0 folder was embedded, so numerous pictures were found in one file. To have a better viewing of all the pictures in this location, the imgcaceMicro.0 folder was exported from Cellebrite’s Physical Analyzer and was saved to an external drive. The folder imgcacheMirco.0.EMBEDDED was created and the pictures were easily accessible. By looking through the contents of the imgcacheMicro.0.EMBEEDED folder, all deleted pictures were available for viewing (Figure 11). 

Figure 11
 

Google Voice 

Since this camera in particular did not come with a SIM card or data plan, the only way to make calls or send text messages was to use WiFi. Because of that, the applications enabling call and text options needed to be closely looked at. Google Voice is a great application that provides a user with their own phone number and the ability to make calls, send text messages, and receive voicemails. 

In this case, the camera’s phone number was 802-448-0816. Multiple text messages were sent and received using Google Voice. While no conversations were deleted from the application, there were no artifacts found. Data for Google Voice gets stored in \data\data\com.google.android.apps.googlevoice. In this directory, a number of different databases are found. The SMS outbox database is empty, along with conversationsDatabase and model.db. It is unknown as to why data wasn’t present in the

com.google.android.apps.googlevoice directory. A keyword search in EnCase was done for known sent text message content, but the search resulted in nothing. 

Talkatone

Talkatone is an application with the same functionality as Google Voice, except it does not provide the user with a phone number. Unlike Google Voice, artifacts from conversations created on the camera were found. The conversations are stored as .map files, which get recognized by EnCase as picture files. These files were found in data/data/com.talkatone.android\files\sms-messages. The .map files are categorized by phone number (Figure 12). By looking at the files in EnCase’s Transcript viewer, the contents of the conversations currently on the camera were found in plain text. 

 
Figure 12

In Figure 13, highlighted in blue, is the number of the person who sent the text message “I’m gonna catfish you” to the camera. Figure 14 shows the response “Do it” coming from the camera. Unfortunately, the Last Written times for the .map files are not accurate (only the dates are) and there was no other way of telling when these text messages were sent. Furthermore, the deleted conversation from the user “Alyse” was not found. 

Figure 13
 
Figure 14

Remote View Finder


Probably the most noteworthy feature of the Samsung Galaxy camera is Remote View Finder (RVF). It is used when the camera is in camera mode and the Share button is pressed. One of the options provided is Remote View Finder. This allows another device running RVF to connect with the camera via WiFi. The camera can then be taken outside, down the hall, or elsewhere in a building using the same WiFi network. The device running RVF (in this case the Droid Bionic) can see what the camera sees and can control the camera’s functionality (Figures 15 and 16). Once a picture is taken by the camera via another device, the picture gets stored on both devices. Pictures taken using this feature were not deleted. 

Figure 15: View from Droid Bionic



Figure 16: View from Samsung Galaxy camera


The primary concern surrounding this feature was finding anything that connects the camera to the other device taking the pictures. This information was discovered in the directory data\misc\dhcp. The file dnsmasq.leases (Figure 17) provides a timestamp of the last time RVF was connected to WiFi (highlighted in blue), the MAC address of the device it connects to (highlighted in yellow), and the IP address of the network being used. 

Figure 17
 
The timestamp converted to March 16, 2013 at 3:12 PM which is when numerous pictures were taken using Remote View Finder. Doing a temporal analysis on any pictures at that time resulted in finding all of the pictures taken with Remote View Finder on March 16 at 3:12 PM (Figure 18 and 19). 

Figure 18
Figure 19
 
By the end of this project, it has been undoubtedly concluded that the Samsung Galaxy camera can be forensically acquired. Even with minimal support available for this new device from some of the industry’s leading forensic tools, data extraction is still 100% possible.

Based on the results of this project, it did not seem that the camera stored data any differently than other Android devices. Due to this, some of the same Android forensic techniques can be used to analyze the camera. This discovery will help investigators decide on a starting place and will hopefully ease their process, as Android forensics is solidly researched. In conclusion, forensically examining the Samsung Galaxy camera proved to be successful and will be useful, as well as applicable, to future forensic investigations for this device.

No comments:

Post a Comment