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


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/ journal. Although the history had been cleared on the camera, Google searches for “”, “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\\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 “” 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\\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 “” may suggest that it is.

Figure 4


Data downloaded to the download application was found in the sisodownloads.db file located at \data\data\\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\\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


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\ 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 directory. A keyword search in EnCase was done for known sent text message content, but the search resulted in nothing. 


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/\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.

Wednesday, March 13, 2013

Cellebrite File System Dump

Back when I was first figuring out how to acquire the Samsung Galaxy Camera, I did a file system dump using Cellebrite's UFED Logical. Having some time after work, I decided to take a look at what the Cellebrite found using the Physical Analyzer we have at the LCDI. I didn't spend a serious amount of time looking at the data since it was dumped early in the research stage and not much had been done yet.

I never used the Physical Analyzer before today, but from my short interaction with it, I found it to be quite useful and extensive. Below you can see the left panel that provides you with numerous types of data to look at. The first thing I looked at were the SMS messages, since technically the camera isn't a phone. There is no default text message application on the camera, so this text had to of come from either the application Talkatone or Google Voice. Either way, it's very interesting that the Cellebrite picked it up as being a text message and not just some application cache.

Next, I looked at Facebook data. There were many different SQLite databases found, not for just Facebook, but for the entire camera. This was expected and the Physical Analyzer did a great job of parsing the databases, as well as giving me an option to export them. Looking at a database without it being parsed can be tricky to get through, but I wanted to see what data was stored in plain text. Below is the database file for the Facebook friends Sammy Sung has. I used my brother's data for an example. You'll notice that the camera, and many other devices, store pretty personal information:

In yellow we obviously have my brother's name on Facebook, Joe Stamm. Right after that we're given his email address and phone number because it is on his Facebook page. This link includes his Facebook ID, but has been blurred out for privacy reasons. Below that, highlighted in green, we have a link to his profile picture. Upon putting the link into a web browser, I was presented with a picture of my brother. Luckily, he got some of my good looks.

Now, I could struggle through the rest of the ASCII and try to get the same information for all the other Facebook user's that are friends with Sammy Sung, but that would take way too much time. Instead, I used the built in database parser. Just by clicking on the .db file, I automatically got brought to the Database View within the Physical Analyzer. This presented me with an organized list of data, including the Facebook ID and first and last name of every Facebook friend Sammy has, their email address, their phone number, and their birthday. This data is only presented if the users have this information on their Facebook page: 

Lastly, I noticed Physical Analyzer had a Timeline option. A timeline in any forensic software is such a relief and saves an examiner from rummaging through months or even years and years of data. So within this feature, I can jump to whatever date I want to and look for specific things that were occurring on the camera at that time. Below you'll see that on January 30, numerous bookmarks were deleted and on January 31, various emails were sent to the camera:


Wednesday, March 6, 2013

Where am I?

I'll have to admit that I have been slacking lately with this project as I've been so busy with school and work. Now that I'm on spring break for a week, I finally have plenty of time to get some things done. Every time I think I'm done gathering data, I think of something else I'd like to do. So in respect to doing a full analysis, I am not there yet. In the mean time, I have been playing around with Oxygen and Santoku. I haven't deleted any data yet, but I wanted to forensically look at the data I have so far.

I downloaded Oxygen Forensic Suite 2013 and surprisingly, the camera was recognized. This was not the case when I first tried Oxygen, but that was before the camera was rooted and I was using an older version of the software. Knowing that both EnCase 7 and Oxygen can acquire the camera, I decided to dabble some more into Santoku.

Today I found my Android Forensics book (which I've been looking for this whole time) and used Santoku's terminal to try the logcat and dumpsys commands. I used the command "adb shell logcat > log.txt" to  dump the logs from the camera to a text file on Santoku. I found that this dump didn't capture as much data as the command "adb logcat" did. Using the latter, the results were presented within the terminal and were updated every couple of seconds. I noticed that when I touched the screen on the camera, the log was updated with the word PUSHED and when I shut the display off, a number of LCD requests were created. It was pretty interesting to watch the log do a live update and it's something I'd like to look further into.

What I found more interesting though, was the command "adb shell dumpsys > dump.txt" This dump consists of account data, application data, network data, and much more. It turns out to be a pretty extensive word document and can take a while to sort through if you don't know what you're looking for specifically. Thanks to Andrew Hoog's android forensic book, I was able to filter through the dump and find what I wanted.

I ran the command and opened the dump.txt file. I found the 6 accounts created on the camera:

You'll notice the dump says 7 accounts, but this is because it is associating the name Sammy Sung with the Facebook account.

Next, I looked for Last Known Locations, which provided me with pretty exciting data:

Looking at the mTime under Passive, we can convert that number to:

Beneath the mTime is mLatitude and mLongitude. This is the location of the camera when it last connected to a cell tower. I threw these numbers into this website to see if the locations were accurate. I had expected the locations to be somewhat close to where I was, but to my surprise, they were dead on:

I'm still looking more into what logcat and dumpsys have to offer. Andrew's book goes into numerous other Linux commands to run in order to find all sorts of data on the camera. I plan on spending the rest of my week trying out these commands and gathering as much data as possible from them.

Wednesday, February 6, 2013


Today I rooted the Samsung Galaxy camera. Someone already figured out how to do this, so it made my research process go a lot faster. There are multiple tutorials online for rooting the camera, but the one I found to be the easiest can be found here.

The first thing I did was shut off the camera and downloaded the recovery and cache package, CF-Auto-Root and and flashing tool, Odin3. I then held the Power On + Volume Down + Camera buttons to get the camera to boot to download mode.

Once in download mode, I opened Odin3 and plugged in the camera to my workstation. The ID:COM section will turn yellow when the camera is recognized, which can be seen  below.

Next in the PDA section, I selected the CF-Auto-Root.tar.md5 file and pressed start. When the process was over and the camera was rooted, Odin showed me this:

The camera automatically rebooted and started as normal. I knew the device was rooted because the application SuperSU was found.

I unplugged the camera and then plugged it back in. I opened FTK Imager hoping that the camera would at least be recognized, but it wasn't. I tried to use dd to image the device, but had no luck doing so. DD did not recognize the camera either. Running out of options, I decided to try EnCase 7 to try to acquire the device. EnCase 7 has smartphone acquisition capabilities and obviously Android was an option.

Once the acquisition was complete, I was able to view all the contents of the camera. Now that I know I can acquire the camera, I will start deleting some data to see if I can find it later in EnCase 7.

Monday, February 4, 2013

Roadblock #1

So for some reason I had the idea that everything would work out smoothly. I would generate some data on the camera, delete some emails and pictures, image the camera and start my analysis. Luckily, I was proved to be wrong early on in the acquisition process. The camera gets recognized as a portable media player and cannot be imaged with FTK Imager. I thought this was a slight hiccup, and maybe I could use some other method to extract the data. I decided to go to Champlain's on campus forensic lab and use the XRY software we have.

Everything seemed to be going smoothly. XRY recognized the camera as a Samsung USB modem, but could not acquire it. I'm really unsure as to why this happened, but my guess is the software I was attempting to use was not made for cameras. My next option was to image the SD card and see what I could get. To my surprise, there wasn't one at all. Just a piece of plastic in the microSD slot. I could obviously buy an SD card, but would that provide me with Facebook, Twitter, and email data? Probably if I moved the application data to that external storage. But how often are people doing this? From a forensic point of view, I doubt we would find much from an SD card being that most users don't think to store their applications on the SD card and use internal storage instead.

I remembered an activity we did in my mobile forensics class using Santoku and decided to try this method just for fun. I  downloaded the ISO and created a virtual machine. A tutorial on how to use Santoku with Android can be found here: Below are the results AFLogical presented to me when I attempted to extract data from the camera:

AFLogical OSE was installed on the camera using the command 'adb install AFLogical-OSE_1.5.2.apk'

Next, I used the mkdir command to create a folder for the output. 'ADB pull' pulls data from the SD card

I located the output files

Inside both output folders, these files were found

This was the only picture extracted from the camera

So although there is no SD card, AFLogical was still able to extract one picture from the Samsung Galaxy camera. Call logs, contacts, MMS, and SMS were not extracted by the software, so I needed another option to get all the data I want.

I looked into grabbing RAM using LiME and also another Android data extraction method, DDMS. I only did some preliminary research on these tools and have not yet tried them. I found a way to root the camera, so I think I will try that out first because I know it will give me access to the data I'm looking for. If I have time toward the end of this project, I will try to extract data using LiME and DDMS.

Thursday, January 31, 2013

Sammy's Credentials

Feel free to add these accounts and interact with them! I need all the data and help I can get :)

Facebook: Sammy Sung
Twitter: @sammysung131
Instagram: sammysung131
Phone: 802-448-0816

It's Here!

Today I received the Samsung Galaxy Camera thanks to Jon Rajewski! Needless to say, I am so excited to play with this product all weekend and come up with a fake profile to do some testing with. After talking to my roommates about my project, we've come up with the name Sammy Sung. I think it's pretty original and it definitely fits this project.

For the past half hour I've been taking pictures, editing them with the awesome built in features, and in a few minutes I'll set up Facebook, Twitter, Instagram and email accounts for the user "Sammy Sung". To generate as much data as possible, I'm going to ask all of my friends to add these accounts and interact with them. We'll share photos, talk in chats, write on each other's walls, send emails, and much more. I do not have a SIM card for this camera, so I don't have 3G/4G access. I do have WiFi up and running, so this will work just as well. 

Below are the applications that came with the camera:

There is also a feature called Kies via WiFi. I had never heard of this before, but from researching the topic it seems like a typical backup option. You can backup the data from the camera to your PC via WiFi. This is definitely a feature I'll be looking more into once analysis begins.

As soon as I create the profiles for Sammy Sung, I will post the account information so anyone can interact with the accounts if they would like.