Abstract
The Samsung Galaxy Gear Smartwatch, released October 4, 2013 is a cutting edge Android companion device. The watch pairs via Bluetooth 4.0 with the Samsung Galaxy Note 3 Smartphone, and acts as a relay for certain phone features such as calendar events, calls, text messages and alarms. The Galaxy Gear has 4GB of onboard storage, an 800MHz processor and 512MB of RAM. It features a 1.63 inch Super AMOLED touch screen and only one physical button. Text messages sent from the Gear are done using the S Voice application, since there is no keyboard.
While within Bluetooth range of the Galaxy Note 3 that it is paired with, the Galaxy Gear will display and allow the user to interact with phone notifications, calls and texts. The two devices continuously sync with each other, so that the Smartwatch is able to display content which is stored to the phone, such as call logs, MMS logs, and the contact list. Photos and videos taken on the Galaxy Gear are stored on the device itself and can be sent to the paired phone using the Bluetooth connection. The Galaxy Gear itself does not have internet capability, so it is very limited in the apps and types of media it can support. For instance, to use the media player on the Gear, you must maintain a Bluetooth connection with the phone. Pressing the play button on the Gear will activate the music app and speakers on the phone; the Gear is merely a relay device and cannot play the music through its speakers nor does it function as an MP3 player itself. The majority of the settings and apps on the Galaxy Gear are installed, set up and managed from an application called Gear Manager on the paired phone.
When Bluetooth is disabled, the majority of the applications on the Smartwatch become unusable. The watch is still able to display the time, take photos and videos, and basic apps like the pedometer and stopwatch still function. While Bluetooth is disconnected, the contact list and logs app on the watch appear empty, and the watch ceases to relay notifications or alarms.
The purpose of this project was to forensically image a Samsung Galaxy Gear Smartwatch to determine what kind of information the Gear actually stores. To do this, I first purchased the Samsung Galaxy Note 3, since it is currently the only device that can pair with the Smartwatch. I set up all of my applications, preferences and imported all of my contacts to my new phone. I then purchased the Samsung Galaxy Gear Smartwatch and paired it with the phone. For the next two days, I sent and received text messages from the watch, made and answered phone calls from the watch, accessed my contact list on the watch, played one MP3 file, took three photographs and changed the notification sounds and settings.
To image the Smartwatch, I first disconnected the Bluetooth so that only the content of the watch’s internal storage would be captured. The watch has a setting that enables the user to put it in USB debugging mode. For this process, I downloaded Linux Santoku version 0.4 from santoku-linux.com, as well as the Android ADT Bundle and Android SDK Tools, both from developer.android.com. With USB debugging mode enabled, the computer was able to recognize it as an Android device and an ADB pull of the Gear’s file system could be done using Santoku version 0.4. I saved the contents in a folder named Gear and analyzed the data using Autopsy version 3.0.1 and Access Data FTK Imager version 3.1.3.2.
As I expected, since the Galaxy Gear is merely a relay device for the Galaxy Note 3, there wasn’t much data related to contacts or logs that could be recovered. Photographs taken on the device were able to be located and viewed, and data related to settings and app usage was obtainable.
Background and Process
The Samsung Galaxy Gear Smartwatch is an extremely limited device as far as what it is able to do at this point. The functionality of the device relies on a Bluetooth connection with a Samsung Galaxy Note 3 phone. The device comes equipped with some apps that will function in the absence of a paired device, such as a pedometer that counts steps based on movement of the device, a timer, a stopwatch, and a camera. The other stock apps are the contact list, log, notification, media controller, weather, and today’s schedule; these are the apps that require a Bluetooth connection to function. These apps allow limited preview and interaction with data stored on the phone. For instance, on the Galaxy Note 3, I have a calendar app which I have daily events saved to, for months in advance. The today’s schedule app on the watch allows a plain listing of the events that are stored for today only, and there is no ability to edit existing events through the watch.
When pairing a Galaxy Gear Smartwatch to a Note 3, you must install an app called Gear Manager to the phone. This is the application that allows you to set up and customize the Galaxy Gear. Through this app, you can control what notifications the Smartwatch relays. You must also set up the S Voice app to be able to make full use of the Gear. S Voice allows you to make voice commands to the watch, record audio reminders, and create text messages. The only physical button on the watch is the power button, which you hold down to power off the device, or tap twice to activate S Voice. The S Voice understands commands such as “call mom, home number”, or “text Hannah”. Text messages created on the watch have very little ability to be edited, since there is no keyboard.
Notifications can be customized through Gear Manager. A wearer will be notified of calendar events and alarms set on the phone. Incoming calls are displayed on the screen, and can be answered or declined with voice commands. Answering a call from the Smartwatch will activate a speakerphone on the watch located in the clasp of the band. Text messages are also displayed on the screen, and can be responded to from the watch. While the watch and phone are synced, the log on both devices records the events from both devices. So when a text is sent from the watch, then a text is sent from the phone, the log on both devices will list both messages without indicating which device created the message.
The Galaxy Gear Smartwatch is charged by setting it in a cradle. Five contacts on the underside of the watch will connect to the cradle. A micro USB port on the outside of the cradle is the only way to physically connect to the watch to anything. When connecting the watch directly to a computer, it simply charges. The computer is not able to see it as an external or storage device. Interestingly, the Galaxy Note 3 paired to the device could also not be recognized by the computer; it was only seen as a portable media player. Even though there were over 800 pictures on the device, the computer was unable to identify the files.
Figure 1: Screenshot of my PC’s inability to recognize the Samsung devices.
After many unsuccessful attempts to get my computer to recognize either device, I contacted Samsung Customer Service, Device Support, via chat through their website. The customer service representative sent me a link where I was able to download USB drivers to enable recognition of the phone. When I requested a driver for the watch, I was informed that the watch could not be connected to a PC. I was told that the only way to get data off of the Smartwatch was to send it to the phone via Bluetooth, and then connect my phone to my PC.
Figure 2: One of my conversations with Tech Support; I had a very hard time finding any information regarding the Galaxy Gear Smartwatch.
Since the Samsung Galaxy Gear Smartwatch is a very recent release, literature on the device is limited to product reviews and comparisons. I was unable to find any information on successfully rooting the device. After exploring the settings on the device further, I found a way to enable USB debugging mode on the watch. Once that was enabled, the charging cradle could be connected to my PC via USB and was able to be recognized as an Android device. I downloaded the Android ADT bundle and SDK tools add-on from the Android developer website.
Now that the watch could be recognized, I was able to do give an ADB pull command in Linux Santoku version 0.4, and I saved the retrieved data in a folder named Gear. It was not necessary to root the device; I was able to get a considerable amount of data from the watch. Although it is beyond the scope of this project, I intend to download some Android APK’s and attempt to do an ADB push to see how customizable the Smartwatch could be, and if it could support other apps.
I imported the Gear file into Autopsy version 3.0.1 and also into FTK Imager version 3.1.3.2 to analyze the contents. The data was pulled and sorted into folders; the device appeared to only contain one partition. I looked through the data folders to determine what kind of information was stored on the Smartwatch and the structure in which it stored data.
Under system>etc, I was able to see where all of the stock applications were stored. While using the watch, I did not attempt to delete any stock applications. Since the device was so new, there was no option for me to install any additional apps to the watch through the Gear Manager.
Figure 3: Location of system applications on the Smartwatch.
Also under system>etc, I found a file called event-log-tags.
This file contained a log on physical events on the watch. While it didn’t contain any actual data content from notifications, it did log how I responded to the notifications. It logged when sync occurred with the phone, however, there was no data here that would allow me to identify the exact device it synced with. It logged when the battery level was low, when I manually restarted the device, when I changed device settings, when calendar updates occurred, and even when Wi-Fi state changed.
Figure 4: A screenshot of a small portion of the physical event log of the device.
The folder system>etc also contained files which showed preferences I had set. On the Galaxy Gear Smartwatch, there are only three ringtone options to choose from. When I was setting up my watch, I listened to all three and then selected ringtone number two as my default. When I found the media folder containing the audio ringtones, it did not list them in order. Instead, it listed the one I selected for default first. I listened to them in the order of one, two, three, and then listened to two again before selecting it.
Figure 5: A screenshot of the ringtone files. They are in the order I listened to them in, with the one I assigned to default listed first.
The system>etc folder also contained a file named vold.conf, which appeared to be the path the media would be sent from the watch to the phone. It gives the path back to the host device, and directs where media can be saved. While this file does not offer any information to identify the exact phone it will feed back to, it’s obvious that this file directs media to a separate device, since the Smartwatch does not have the option to add an SD Card.
Figure 6: A screenshot of the file assigning the path to the SD Card of the paired phone.
This folder also contained the path back to the calendar widget on the Note 3. The file calendar.xml specifies the path to the data, confirms the sync history, and indicates whether or not I set the event to give me a reminder.
Figure 7: A screenshot of the calendar.xml file.
Under the system>csc folder, I was able to locate a file containing customer data. This file, customer.xml, listed some locational data, as well as my preferences concerning language settings. It also showed my settings I chose concerning date and time format displayed on the watch.
Figure 8: A screenshot of some of my settings saved in the customer.xml file.
The customer.xml file also contained web bookmarks. I hadn’t assigned any bookmarks while using my Note 3, but it listed the standard bookmarks for Amazon, Twitter, ESPN, etc. I thought it was very interesting that this bookmark data was located on the Galaxy Gear. This Smartwatch does not have internet capabilities. The notifications relayed to the watch from the phone do not include Facebook or Twitter notifications, or notifications from any other web-based application. Internet surfing is not possible on the Galaxy Gear, so it is notable that there are web bookmarks stored to it.
Figure 9: A screenshot of the web bookmarks stored under the customer.xml file.
I was able to locate and view the three pictures I took using the watch. Also, they were the only photos on the device, indicating that media transfer of this type is unidirectional. My phone contains hundreds of pictures, but none of them could be viewed on the Galaxy Gear, even when the devices were connected via Bluetooth. Since the internal storage of the Gear is relatively small and the small screen is not ideal for viewing anything with any amount of detail, it makes sense that the device was designed to only allow media file transfer in one direction. The photos were stored under mnt>shell>emulated>0>DCIM>Camera in the jpeg format.
Figure 10: A screenshot of the location where photos are stores, and a very blurry shot of Lili, my sister’s Yorkshire Terrier, taken from the camera on the Galaxy Gear.
The metadata of the photos also contained the date and time the photos were taken. I can confirm this was the time I took the photos within a few minutes, so the time stamp is correct.
Figure 11: A screenshot of the time stamp for a photo taken on the Galaxy Gear.
In the system>etc>security folder, I found an encryption key. I never enabled encryption on the device, nor do I see it as an option to turn on or off. I suspect it is automatically enabled to protect data transfer during the prolonged, open Bluetooth connection that is required. Since Bluetooth is designed to automatically recognize and connect to devices around it, if the data were to be sent between the devices unencrypted, any other Bluetooth device within range could potentially intercept the data.
Figure 12: A screenshot of a small portion of the data encryption key from the Galaxy Gear.
As I hypothesized, the Samsung Galaxy Gear Smartwatch does not store very much data on it, relative to what you might find on a phone or other embedded device. The Smartwatch merely relays the information stored from the phone. While the Smartwatch maintains a Bluetooth connection to a Galaxy Note 3 phone, it will display call logs, message logs, and even the user’s contact list. As soon as the Bluetooth connection is lost, the Smartwatch not only can’t receive new messages, but it can no longer display the ones it previously had on the screen. This suggests that the watch is merely acting as a second screen for the phone, rather than receiving, storing, and displaying the information from the phone screen.
After pulling all the data I could off the Smartwatch, it appears that my hypothesis is correct. If the watch had to store the data, even temporarily, to display it, there would have been evidence of that data received from the phone. There were no folders or files related to sent or received messages, incoming or outgoing calls on the watch. Even though I used the media player to activate a song, there was no information about the song on the watch. There was no evidence showing that the watch had previously displayed over 100 contacts from my phonebook on its screen. This would all indicate that the data mirrored on the Smartwatch screen was not physically stored on the device.
Since the only way I was able to acquire data from the device was just to do an ADB pull command, it is possible that I did not get all of the data. It would have been ideal to be able to make an image of the device; FTK Imager was unable to recognize the device. If I had been able to make a full image, I might have been able to find data in file slack or unallocated space. I could have potentially been able to carve data out of there. If the watch was actually receiving the data and having to store it in temporary files that were overwritten with each sync, the data from the previous sync could potentially be carved out of that space. Since I was unable to root the device, image it in a forensically sound manner, or find any literature regarding the actual internal processes and structure of the Galaxy Gear Smartwatch, I can’t even confirm that data wasn’t changed or altered when I performed the ADB pull.
One thing I struggled with on this project was locating the exact feedback route from the watch to the phone it was synced with. In all of the data I recovered, I could not locate a phone number, serial number, or the name of the device that the watch was synced to. I found generic storage and feedback pathways, but nothing to confirm that my Galaxy Note 3 was the only phone ever synced to that watch. I feel that in any forensic investigation involving the Smartwatch, it would be vital to identify the device it was synced up to. Since the majority of the data between the paired devices would be stored to the phone, it would be crucial to identify the phone. The Gear Manager app on the phone very clearly identifies the watch, via serial number and name. This would confirm the devices were paired; however one must then have possession of both devices. The data obtained from merely having the watch was not enough to identify the other paired device.
This project was interesting because it involved a brand-new product that had never been tested before in this type of setting. As exploits for the devices are created and shared, it would be interesting to see how much more data could be recovered from a Samsung Galaxy Gear Smartwatch.
Sources
Downloads obtained from:
developer.android.com. Accessed on 10-9-2013
santoku-linux.com. Accessed on 10-9-2013
samsung.com/vs/galaxygearsupport. Accessed on 10-8-2013