After the DFIR Summit and DFRWS I decided to take a short DFIR sabbatical (unpaid of course) just to recharge, and, as I had anticipated, something new was released on Android while I was on break. At the beginning of August Google released Nearby Share, Android’s new peer-to-peer data transfer feature.
Nearby Share is a replacement for Android Beam, which was removed in Android 10. Beam used NFC, and required users to tap the back of their phones together to initiate a connection for data transfer. While it seemed like a neat feature, Beam never really seemed to catch on with a majority of Android users. There had been some whispers that Google was working on a replacement, and these were confirmed in March of this year with the arrival of the second Android 11 Developer Preview. Right now, Nearby Share is released as a beta on Pixels and select Samsung devices.
Nearby Share is not a separate app. It is baked into Google Play, so once the beta period is finished, Nearby Share will be rolled out via a Google Play update; no waiting on OEM testing/deployment. Google has said Nearby Share will be available on devices running Android Marshmallow (6.0) and higher, which, at the time of this article, represents 84.9% of Android phone/tablet deployment. So, this feature will be seen in a wide variety of devices. Additionally, it will also make its way into Chromebooks . Very Apple of you, Google.
For testing I was using a Google Pixel 3 and a Samsung Galaxy A30 both running Android 10. They were up-to-date on their patches (as of August of 2020) and rooted using Magisk, and while some of the data did not require root access, some did, so your ability to get some of the data will depend on the capabilities of your extraction tool(s). In order to not set off any alarms, I signed into both devices using the same Google account, which had been enrolled in the beta program.
There is a reason I titled this article the way I did. Nearby Share is very….very…similar to iOS’ AirDrop, both in function and forensics. But, before I get to that, let’s take a look at how it appears to users.
A Walkthrough
Nearby Share is buried in the Settings app: Settings > Google > Device Connections > Nearby Share. Figure 1 shows the menu.
Nearby Sharing was OFF by default once I updated the app, but this may change once the beta period concludes. Nearby Share requires a Google account (my test account is in the green box), and if a user is logged in on the device, it will default to that account, but a user does have the option to add an additional account. Device Name (blue box) is set by default, but can be changed (I changed mine to what is seen in the screenshot).
Note that down at the bottom of the screen is an informational section indicating Bluetooth and Location services need to be on in order for Nearby Share to work, and while it is implied, Wi-Fi should be turned on (I assume it will be turned on if Wi-Fi is used for the data transfer). If you are an iOS user all of this should sound familiar (AirDrop requires Bluetooth and Wi-Fi).
The red box in Figure 1 is the device visibility options. Tapping it brings a user to what is seen in Figure 2.
The interesting thing about Nearby Share is that it is mostly limited to a user’s contacts. In other words, a user could not send a file (a pesky Unsolicited Richard Photograph, for example) to a random stranger unless Nearby Share was open on the random stranger’s device. Here I have my setting set to “All Contacts,” but the other two settings break down as follows:
Some Contacts: Only selected contacts can see your device and you can see the same types of devices as the “All Contacts” setting. The selected contacts are seen towards the bottom of the screen
Hidden: No one can see your device and you can see the same types of devices as the “All Contacts” setting.
Remember these settings because we will revisit them later.
When a user decides they want to use Nearby Share to send a file to another person it is as simple as brining up the share sheet. See Figure 3, which is from my Galaxy A30.
The red box in Figure 3 is the Nearby Share option. Tapping it brings up what is seen in Figure 4. Figure 5 shows what a nearby user would see if they were a contact (my Pixel 3).
When a user has decided to share a file and taps the Nearby Share button, the device will start looking for nearby devices in the user’s contact list. If one is found it is displayed in the share sheet (Figure 6). Choosing the found contact will cause Nearby Share to open on the found user’s device (Figure 7), and Nearby Share will ask if they want to accept the incoming file (Figure 8). The found user has the option to accept or decline the file, and hitting the accept button will download the file, which will open using the appropriate on-device app (if one is present).
That’s it. Nearby Share is straight forward, and very AirDrop-like. The similarities to not stop there, though.
AirDrop Nearby Share Forensics
When discussing the forensics of Nearby Share I could literally take Sarah Edwards’ article on AirDrop, copy it here, and just change out the iOS vernacular for Android. I will admit it took me some time to realize there was not much being left behind that could lead to attribution, but there is a small amount, and how much an examiner can recover depends on a few factors, time being one of them.
There are a few artifacts left behind that I would consider “low-hanging fruit,” and were present on both my Pixel 3 and Galaxy A30. These artifacts reside in /data/data, so again, an examiner’s ability to get to these depend on the state of the phone and the capabilities of the tool(s) they are using. The first is nearbysharing:service:state.xml, which resides in /data/data/com.google.android.gms/shared_prefs/. See Figure 9.
This file describes the settings for Nearby Sharing. The blue box contains the device name, the green box has a unique identifier, and the yellow box contains the account using Nearby Share and the fact that it is enabled. The red box describes the setting for the device’s visibility. Here it is set to “1,” which is “All Contacts.” A value of 2 is “Some Contacts” and a value of 3 is “Hidden.” See Figure 10.
A note about this file. The semi-colons in the file name prevent it from being created on Windows systems. To get around this, I compressed the com.google.android.gms file on the Android device, and then brought the zip file into macOS. I used Keka to uncompress the zip folder, which replaced with semicolons with back slashes. I then replaced the backslashes with dashes (macOS accepted the backslashes but I replaced them anyway). Just know that if you are working on a Windows system this may be an issue you will need to work around.
The next file is nearby_sharing_account_metadata in /data/data/com.google.android.gms/files/nearby/%ACCOUNTNAME%. This file contains the account name, along with a URL to the picture for the account. For me the file resided in the ./thisisdfir@gmail.com folder. See Figure 11.
If a user added a second account for Nearby Share, the second account would have its own, separate folder.
The next file is downloads.db in the /data/data/com.android.providers/database folder. If you recall in my transfer of the Richard Pryor photo from the Galaxy A30 to the Pixel 3 (Figures 6 and 7), the time was around 13:32 (Eastern Daylight Time). Looking in the downloads.db file finds an entry at 13:33:09. See Figure 12.
Looking further in that database entry finds the file received by the Pixel 3, and a description of “Downloaded by Nearby Share.” See Figure 13.
If you look at Figure 8 you will see the file name of the file being shared is the same as what is found in the database. In my testing I found files transferred between devices retained the same file name and some of the original metadata, specifically, the make/model of the camera and some of the camera settings. I was not able to get GPS data to replicate between transfers.
(Light) Reverse Engineering and Cats with Logs
So far there has not been an artifact or data point that would lead to attribution. I searched all over both devices for anything that could lead to the identification of a device that either sent or received data via Nearby Share, and I was not able to find anything. No database, no xml, no protobuf….nothing. I then tried a small amount of dynamic analysis using Android’s inotifyd, and still struck out. There were files and databases that were being written to, but nothing that had information about a device. I also looked at other ancillary files (e.g. that log device connections) and still nothing.
Striking out there, I then turned to the .apk for Google Play Services. I extracted a copy of it, plugged it into Android Studio, and started poking around. Eventually, I found the code seen in Figure 14.
I am not a coder, but I do understand enough to know that the string in the red box in Figure 14 should be somewhere. Drawing some inspiration from Sarah’s AirDrop article, I turned turned to logcat to pull device logs. logcat is used for debugging purposes, but can be leveraged by examiners. The good thing is that as long as adb is enabled, logcat can be used; root is not needed. Because logs can be a bit unwieldy, I opted to have the output saved to a text file. So I ran the following command on the Pixel 3 (it also worked for the Samsung device):
logcat -d > /sdcard/download/PixelLog7.txt
This retrieved roughly 24 hours of logs on the Pixel 3. Figure 15 shows the first bit of data that could be used for attribution.
Based on the entry here, it appears the Pixel is establishing a connection over Bluetooth with a device with the MAC address B0:6F:E0:AC:F0:A1. The time seen here is around the time of the Richard Pryor picture download (Figure 12). The MAC address belongs to the Samsung device. See Figure 16.
Scrolling down a little further finds the area in Figure 17.
The red box contains the entire log entry, but I have highlighted a portion inside the log entry in the blue box, which is the string from the code seen in Figure 14. As a bonus, the name of the file being transferred is also seen in the red box (just above the blue one). Figure 18 shows the nearbysharing:service:state.xml from the Samsung phone.
Nearby Share uses both Bluetooth and Wi-Fi, and decides which one to use at the time of the transfer. In the transfer here, the phones were sitting on either end of my desk, which is not that large, so a short range protocol like Bluetooth makes sense here. In another transfer, I found the the Wi-Fi MAC address (the randomized/spoofed one seen by my wireless router – not the ACTUAL one) in the logs after I placed the phones at opposite ends of my office. The lesson here is if you do find a MAC address, make sure you check ALL of them.
A couple of notes here here. First, you will see the deviceID field in the logs does not match what is in the nearbysharing:service:state.xml file. I am not sure why this does not translate well in the logs. I am still working on that part, and if I figure it out I will update this article accordingly. Second, the name in the fullName field on the Samsung phone is the same as that of the Pixel 3. That is because the Google account was signed into both devices. If we were talking about different users, the fullName field would have a different value.
Let’s have a look at the logs on the Samsung device. I ran the same logcat command from the shell, and was…well, disappointed…for a brief moment. The logs start only a minute before I ran the command, so the amount of logs I was able to retrieve is small compared to the Pixel. Additionally, there was NO mention of the Pixel 3 or its Bluetooth MAC address in the logs around the time of the transfer. However, there was a small amount of data to indicate what was happening. See Figure 19.
The log entry in the red box indicates the focus of the screen was changed to the Nearby Share share sheet. The time is just before we see the Bluetooth connection in the Pixel logs. Another lesson: make sure you look at ALL the logs. Correlating what was found in the Pixel logs to what was found in the Samsung logs is just a good as if there had been more explicit data in the Samsung logs.
Log Limitation
There is a limitation to the logs: retention. As was just mentioned, the amount of logs generated by logcat differed on both device. The Pixel 3 had about 24 hours worth of logs, versus the Samsung, which had just a few minutes. This is a very small window of time from an investigative standpoint, but not from a debugging one. So, if this artifact is of interest to you, I would suggest getting the logs as quickly as possible.
I also noticed another issue with the logs. Some times after the logs are extracted there is no trace of a transaction. In the logs from the Pixel, for example, there was only one transaction, even though I had conducted multiple Nearby Share transactions during the period covered by the logs. I imagine there is some log rollover occurring, so be aware that the transaction(s) you are looking for may be absent from the logs.
Conclusion
Nearby Share will be seen on a majority of Android devices in the very near future. Google has rolled it into Google Play Services, so users will not have to wait for OEMs to test and deploy the feature; a simple update to the Google Play app will allow users to start using Nearby Share.
There are a few artifacts left behind when a user sends/receives data via Nearby Share, however, finding artifacts for attribution can be difficult and can depend on how quickly a device can be examined. Hopefully, Google will decide to provide more logging with this feature in the future.
