The expanse of Android usage, the open source mobile Operating System, is widening every year with new innovations. It started from turning mobile phones into ‘Smartphones’ and today has reached a point where the regular wrist watches are turned into ‘Smart Watches’. Android Wear is the new big thing in gadget arena that is tempting not just the technology enthusiast but also the geeks and developers around the world. Everybody just wants to explore it, though the ways and motives are a little different for each. Therefore, in this article, we are discussing the Android Wear Smartwatch Forensics.
Innovated to cut short our unremitting usage of phones, for the so-called purpose of keeping a tab on the notifications, Android Wear allows you to check notification at a glimpse. All that one has to do is keep the device connected to their smartphone via Bluetooth connection and keep the activities synched on both the ends with Android Wear App.
Technical Specifications
Most of the Android Wear functioning is dependent upon the smartphone, with which it has to remain connected all the time.
Android Wear may be a new innovation but isn’t completely a new concept. Databank CD by Casio was one of the first digital watches introduced in the era of 1980’s, with stunning facilities like; data storage (email address, phone numbers, etc.), alarm, calculator, and more. Android Wear could be designated as the evolved version of it.
However, the facilities and functioning of a smartwatch are way different and advanced than that of a Databank. In order to study the same for a better understanding of its working and storage, a thorough examination is necessary.
Thus, we will be applying digital forensic sciences for analyzing what all information could possibly be gathered from the Wear alone, just in case the device is missing or wasn’t retrieved from the scene.
For instance, a Wear is discovered from the scene while its paired phone isn’t. Thus, a dig has to be taken into its mechanism by applying digital forensics; to discover which smartphone did the device belong to or was associated with.
Ultimately, Android Wear OS belongs to the Android OS family only, i.e. it is still Linux base. Thus, getting into its system data and performing Android Wear smartwatch forensics is almost the same as on any Android smartphone/tablet would be.
Practically getting into the device is only possible if you root the device and provide its access to the computer. That means, bothof them must be able to communicate and access to root folders must be owned. For that one needs to enable the following options and follow rest of the procedures that fall in the way. In our case we have used a Sony Smartwatch3 (SWR50):
To enable Developer Options on the watch:
NOTE: A countdown on the screen will tell in how many more taps the Developer Options will be enabled.
NOTE: Usually an RSA key is sent to the paired device (phone) for enabling debugging on the smartwatch. However, in our case the watch had been acquired without its paired device thus, it was factory reset to avoid for this hurdle. Doing this took the device to its original system state.
The Wear is all set to communicate with the computer via ADB, (part of the Software Development Kit by Android). Fulfilling a few more conditional requirements will completely prepare the device for a thorough Android Wear forensics analysis.
Condition 1: If you don’t have Android SDK, it has to be downloaded and installed on the machine to proceed further with the investigation that requires ADB Shell usage.
Condition 2: When developing or trying to get internal access to an Android-based device on a Windows machine not only do you need ADB but the correct USB driver also needs to be installed on the machine.
Different OEM’s (Original Equipment Manufacturers) support different drivers. Thus, it is advised that a universally supported ADB driver be installed instead, to avoid conflict. Once installed, the machine must be rebooted.
The device is now ready to be connected. Establish a connection between the Wear and computer using a USB cable and do the following:
Check whether the bootloader is unlocked or not and if found locked, unlock it. Just remember that the device will erase entire User Data from the device just like it does on a phone/tablet. Later, you can flash (upgrading the device functionalities beyond its default build potential) the device to customize its specifications and potential. However, there are chances that the device may go into a Brick mode which is the worst that can happen as the state is unrecoverable from.
On executing the ‘df’ command on ADB Shell, directories of the device will get listed consisting of the following:
As part of every investigation process, the analysis of original/primary data is never performed. Thus, imaging has to be done of the highlighted directories, i.e. directories important from the investigative point of view.
To be on the safer side, every time imaging is done, a hash value of the evidence must be generated both; before and after the process, just so that its authenticity is validated.
NOTE: Keep the device in write protected mode to avoid writing of new data or rewriting of existing data on the device, as it would be considered as tampering with the evidence.
Here, we are using Cat command, meant for Unix-like OS, to display the memory blocks on the system. However, the items will appear in a manner that may not be comprehensible for distinguishing purpose. To change the order of listing by name, execute the command:
Now, to begin with, the imaging process of respective directories denoted earlier as important, run the following ‘dd’ command on ADB Shell (as instructed):
Here, the MountingPoint will be the developer block that has to be imaged, destination path would be the location at which you want the image to be saved, partition type is the type of partition that you are imaging in the process, and block size, i.e. the size mentioned in the respective block you are imaging.
Ready, Steady, Trace!
Once the forensic images of desired memory blocks have been generated, the procedure of analysis on the respective .img files can begin.
As per the study conducted till now, two of the most important facts that have been gathered are:
Communication Channels: A person can easily attack the device by intercepting it via communication channels on which it basically works, i.e. NFC (Near Field Communication) or Bluetooth. This could provide anyone with unauthorized access to vital and extremely private information/data exchanged over the device and paired smartphone. Many of the popular methods and utilities to carry out such an attack are usually available for free.
In the following section, we will begin traversing directories of the Android Wear System via its forensic image as part of continuing the investigation.
Android Wear User Data Forensic Image Examination
The thing with Android Wear is that it cannot store any application individually on its system. The process requires the application to first be downloaded on the paired smartphone and then be synced by downloading a copy of the app on the device. Also, there are only a limited number of basic health-based applications that can be installed on the Wear. Chat messenger, gaming, email, or other such major applets can only be synced with the device and not installed or used on it.
Therefore, a very minute part of the complete data can be captured from the device, which actually resides on the smartphone. This is because; the device was synced with the phone and received all possible app notification alerts that were compatible with it (WhatsApp, Gmail, Facebook, etc.).
Image analysis applications can be used in the process like; FTK Imager or Scalpel, to mount and parse the forensic image of directories. We have used the latter to mount the image and extract SQLite Database of the same.
System
This memory block consists of information that is entirely related to the device’s system. This included: applications that were installed, fonts that were set by default, the framework, and applications that came from the manufacturer, etc.
The memory block name can be used to find out which one is storing the system image information, and then the command to list all directories can be executed. There you can find minute particulars about the system which includes the file system, and directories like; app (application), bin (stores basic command along with system files information), Bluetooth (stores config files for device list that are auto-paired, vendor, stack, and did), etc.
Data
Although, a smartwatch isn’t programmed in a way that it could store much of data on it. But, it still is one of the most important folders of Android Wear OS, just like it is in Android OS forensics. All the data that is stored, if stored, is in database format. It is a sqlite3 DB file and thus, it clearly has a shared preference folder too consisting of config file belonging to all the applications which include the following folders; calendar, gms, contacts, media, and settings. Each of these folders consists of respective information that is gathered from the same application on the paired device. For instance, a calendar folder would be storing all the events, alarms, important calendar dates, etc., marked on the calendar of the paired device that is synced with the Android Wear for notifying the user.
Cache
Cache, as already known is the data stored by the system, associated with an application so that future requests are handled quickly. The data is usually the replica of an existing data or result of a computation performed in the past. In the case of Android Wear as well, the data serves the same purpose.
Thus, in the cache memory block image, we discovered a fstab entry that is used for specifying partitions and devices or where & how to use partitions on a device, along with information about the file system in use. Therefore, it sums up to be a very significant information storing file. On further exploration, the findings resulted in discovering that also recovery information, partition logs, and their recovery information, etc., also got stored in it. Apart from that, information related to last_log, last_install, etc., proved quite beneficial in tracking purpose.
In addition to this, the unallocated spaces in cache gathered log file information that the log file is copied or converted as last_log.
The stages implemented, if carefully followed along with suggested precautions, majorly facilitate in exploring Android Wear smartwatch & carving out information from the device. Though the information found was scattered in different memory blocks but collectively they held large importance in discovering about the paired device. In addition to that, activities of the paired device were also discoverable by looking into the system directories of the smartwatch though it doesn’t store the complete data as is but does the partial information associated proved helpful in linking things up. Belonging to the Android family made the Android Wear smartwatch forensics examination a lot more familiar though there are some obstacles, however, they were tackled tactfully. Readers are suggested to leave any and all queries related to the blog, and it will be entertained as soon as possible. Note that the procedure is strictly for informational purpose as not many are yet aware of parsing a smartwatch and its memory, storage, etc.
