AirDrop Analysis of the UDP (Unsolicited Dick Pic)

I saw this article “NYC plans to make AirDropping dick pics a crime” on Friday and it got me thinking. What exactly are the cops going to find if they do an analysis of a device, either the sender or the receiver? 

I’ve already done my fair share of analysis when it comes to the Continuity technology with Apple devices with Heather Mahalik at the SANS DFIR Summit in 2017. This article gave me a good reason to do a revisit on how AirDrop artifacts between mobile devices.

Testing Scenario

I’m using the scenario of sending of dick pics in the middle of Times Square as an example. I have two test phones, an iPhone 7 and an iPhone 6. The iPhone 7 belongs to “David Lightman” and the iPhone 6 belongs to “Jen Mack”.  Each device is on iOS 11 for this test. Instead of UDPs, Jen is going to be sending David USP’s instead, or Unsolicited Squirrel Pics – I suppose I need to keep this family friendly right?

AirDrop works over ad-hoc Peer-to-Peer networking over Bluetooth and Wi-Fi. When a user attempts to AirDrop someone a file it will determine who is within range and who is currently receiving AirDrop connections. This may be set to Contacts Only or Everyone (or Receiving Off for those who don’t want UDP’s, smart choice). Poor David has the setting to Everyone, he’ll get some surprises!

To send the squirrel photo to David, Jen used the native Photos application’s sharing feature to select a device to AirDrop the USP to. The only device within range that has AirDrop turned on and in a receiving mode is David Lightman’s iPhone.

Jen selects his phone and sends the picture. On David’s device he receives a pop-up, he can choose to Decline or Accept. 

AirDrop ID

Important to this analysis is an AirDrop ID. On devices this can be found in /private/var/mobile/Library/Preferences/com.apple.sharingd.plist. The keyword ‘sharingd’ is very important in this scenario as much of the Continuity artifacts can be found by searching for that process name. This plist file should be available in an iTunes backup and from any commercial forensic utility. 

Jen’s AirDrop ID is 3DAA769F9F23.

David’s AirDrop ID is E7D713098E3B, also take note of that the DiscoverableMode is set to Everyone. (Jen does not have this key, hers was set Contacts only.)

Artifacts from the Receiver’s (David Lightman) Device

Assuming that the receiver is the individual who would likely make the complaint to the cops, we will look at this iPhone first to determine what artifacts will persist and if they are show attribution to a certain device and/or owner.

Very few artifacts on the devices will actually show this connection happening. Let’s take a look at some of the main artifacts that I would explore if I had the case.

Unified Logs  

Logs can show lots of data and in great verbose detail. Unfortunately, these Unified Logs do not get backed up on iOS devices. The only way to extract them from the device is to get a physical file dump of the device (Jailbreak/Cellebrite CAS/GrayKey). (UPDATE: 12/04/18 - It has come to my attention from a commentor that these unified log files can be collected using the sysdiagnose process on iOS devices. I’ve tested this and they are in fact there. Funny enough, per Apple Documentation, it wants you to copy this archive off the device using AirDrop. 🤷🏻‍♀️ Not entirely the most forensically sound method but hey, data is data - get it with whatever means your legal team will allow. Thanks ‘G’!)

In this example on David’s iPhone, you can see the sharingd process start to scan, attempting to find peers (Continuity connections). During this process you will also see lots of wirelessproxd and bluetoothd activity as well since AirDrop uses Bluetooth and Wi-Fi services. You will also see references to AWDL or Apple Wireless Direct Link.

Follow the logs down a bit and you’ll start to run into some potentially identifying information. We are now starting to see records containing Jen’s device name “Jen Mack’s iPhone”. Pay close attention to the first record highlighted and you’ll see what looks like a MAC address, however it is neither the Bluetooth nor the Wi-Fi addresses. This address is generated different every time a connection is made, therefore not an ideal data point for attribution. 

Going back to the device’s name. This may lead you in the right direction, however anyone can name their device anything they want. I can call my iPhone X “Samsung S9” for instance, no identifying information and frankly a device that doesn’t even do AirDrop.

The next couple of highlighted sections (in red), show the start of the AirDrop connection. We can see an incoming request and start seeing records that include the AirDrop ID of Jen’s iPhone, 3DAA769F9F23. This is where I think attribution may be possible. This ID seems consistent across connections and different devices in my experience. It may be possible to tie this to an Apple ID or specific device. I have yet to find this connection however – it’s not part of the Serial, UDID, or various MAC addresses that I can tell. More research is needed here.

Next, in purple, is more metadata about the file transfer to include transfer status, media type, originating device name, source application, and associated transfer GUID.

In between these metadata records, it shows that it is transferring a file to /var/mobile/Downloads/com.apple.AirDrop/BA40D8CF-54E6-4B09-8F2F-717FB638174E/Files. Whether the user chooses Accept or Decline, the photo still gets transferred to the device.

Finally, the user receives an alert about the AirDrop’ed photo. Following this record is more details on how the user is alerted to the connection audibly and physically with alert tones and vibrations.

This particular AirDrop connect was “Declined” by David. This can be seen in the records below where the ‘selectedAction’ now shows Decline and a clean-up process has started. Highlighted in teal is the AirDrop connection closing.

If the user Accepted the AirDrop’ed photo, the logs would look like the following. The file would have been ‘accepted’ in the metadata records. Finally, since it is a photo – the default application Photos wants to import it into its files and databases. The AirDrop connection is also closed at this time.

Photos Database

Since the photo gets transferred into the user’s Photos database we can look there for hints. This is one file that does get backed up by iTunes and commercial forensic utilities. The Photos database is located /private/var/mobile/Media/PhotoData/Photos.sqlite on the physical device. 

The filename on Jen’s device was IMG_0007.JPG before it got renamed to IMG_0110.JPG on David’s phone. The original filename can be found in the ZADDITIONALASSETATTRIBUTES table in the ZORIGINALFILENAME column.

It is worth noting that the imported photo will carry the same EXIF data as the original on Jen’s device, in fact it is exactly the same photo (hashes should match). The file size and some timestamps get carried over into the Photos database. Other metadata items can be used to determine a photo from another device are the Height/Width, assuming it is from a different family of devices the pixels may be different.

In the ZGENERICASSET table, we have the same Height/Width, however some timestamps are updated to match the time of import via AirDrop. The ZDATECREATED timestamp matches the original creation of the photo. The ZCLOUDASSETGUID matches the GUID seen in the last few entries in the logs above. There does not appear to be any attribution data in this database.

Artifacts from the Sender’s (Jen Mack) Device

In the rare event that the Sender’s device was acquired, the related artifacts are below.

Unified Logs

Much of the logs look similar to the receiver. The sample below shows the sharingd process connecting to David’s AirDrop ID, E7D713098E3B and shows his iPhone device name. Again, the MAC address does not appear to be consistent and will change on every connection.

A few more lines down we can see some file conversion for the photo, IMG_0007.JPG (which apparently wasn’t needed). This is followed by an AirDrop transaction with the AirDrop ID of David’s iPhone.


The lack of attribution artifacts at this time (additional research pending) is going to make it very difficult to attribute AirDrop misuse. At best, if the cops are provided each device, they can pair the connections up – however this will require access to file system dumping services like Cellebrite CAS, GrayKey from GrayShift or performing a jailbreak to get the most accurate analysis. If the devices are named appropriately (ie: If Jen Mack’s iPhone was actually named ‘Jen Mack’s iPhone’) this may make an analysis easy, however I can see an instance where this can be abused to imitate someone else.

Curious about the USP, here you go. This was an advertisement in the DC Metro system, that for some reason whenever I saw it I giggled. 🤷🏻‍♀️

Uh Oh! Unified Logs in High Sierra (10.13) Show Plaintext Password for APFS Encrypted External Volumes via Disk Utility.app


UPATE TO THE UPDATE: Similar log entries are now found in another system log that is more persistent, see the article here.

UPDATE: This is still vulnerable on current versions of macOS 10.13.3 when encrypted an ALREADY EXISTING unencrypted APFS volume (versus, creating a NEW volume in original article). Thanks to @moelassus for pointing this out and to @howardnoakley for verifying. My verification test is below. Note that it gets stored in on-disk, collected logs (non-volatile logs).

Original Article Below:

I’ve been updating my course (Mac and iOS Forensics and Incident Response) to use new APFS disk images (APFS FTW!) and came across something that both incredibly useful from a forensics perspective but utterly horrifying from a security standpoint. Screenshot below of my course disk image.

It may not be noticeable at first (apart from the highlighting I’ve added of course), but the text “frogger13” is the password I used on a newly created APFS formatted FileVault Encrypted USB drive with the volume name “SEKRET”. (The new class images have a WarGames theme, hence the shout-outs to classic video games!)

The newfs_apfs command can take a passphrase as a parameter using the mostly undocumented “-S” flag. It is not documented in the man page.

However when run without parameters, it will show it.

I tried to recreate this scenario on my current system running 10.13.3 but was unable to do so therefore I believe this bug has been addressed. I was however able to recreate it on a 10.13 system (the image screenshot above is from a 10.13.1 system.) I have not tried it on a 10.13.2 system as I do not have one easily available. I will update this blog if someone can test it for me. UPDATE: Thanks to @ranvel (screenshot) and @applechinfo (video) for testing, it has also been fixed in 10.13.2. 

I haven’t done as much testing as I would like (I’m running up against a course update deadline after all!), but I did want to get this out immediate so it can be used for various investigations. I used the following steps to recreate this my 10.13 system.

Created a “clean” flash drive formatted “Mac OS Extended (Journaled)” using Disk Utility.app. (Quick testing shows other base formats should work similarly.) It is the Kingston DataTraveler drive labeled “Untitled” below.

Next I used the menu option “Erase” to create an Encrypted APFS volume on the drive, shown below named “SECRET_USB”. (In my testing it works the same if I go through the “Partition” options and do the same general process. The “Partition” method did error out, however it still appears to be an encrypted USB drive and the logs are the similar.)

Select “Erase” and wait until it has completed.

I used the following command to watch my unified logs in the Terminal while the process above was doing its thing:

log stream --info --predicate 'eventMessage contains "newfs_"'

…and there we have it, a plaintext password! (For better or worse.)

If anyone else does further testing I would love to know the results! Send me a message on Twitter or through my contact page!

New macOS Sierra (10.12) Forensic Artifacts – Introducing Unified Logging

I know its been a while since I've last posted - I've been hard at work delving into macOS Sierra and iOS 10 to add new artifacts into my course. Here is something new that macOS Sierra has to offer us forensic analysts!

macOS Sierra (10.12) introduced a new logging mechanism called Unified Logging. The developer reference document  states that the same mechanism will be used for iOS 10, tvOS 10, and watchOS 3 as well.

The developer docs also state that unified logs will take the places of Apple System Logs as well as Syslog which is what rely on quite heavily for log analysis on 10.11 and older systems. As of 10.12.1, these logs still exist in /var/log so don’t discount them just yet. (Also as far as I know, Audit logs are still fair game.)

The unified logs are stored in two directories:

  • /var/db/diagnostics/
  • /var/db/uuidtext/

The first file path (/var/db/diagnostics/) contains the log files. These files are named with a timestamp filename following the pattern logdata.Persistent.YYYYMMDDTHHMMSS.tracev3. These files are binary files that we’ll have to use a new utility on macOS to parse them. This directory contains some other files as well including additional log *.tracev3 files and others that contain logging metadata. The second file path (/var/db/uuidtext/) contains files that are references in the main *.tracev3 log files.

The new utility used to interact with these log files is simply called ‘log’. The ‘log’ command can be used to do everything from collecting, removing, configuring, and reviewing logging data. The new ‘Console’ application can be used to view logs in real-time (volatile logs) but you may find it easier to use the ‘log’ command to view log historically or those that are extracted from another system.

The ‘log collect’ command can collect records from a certain timeframe, log size, or type into a *.logarchive archive bundle. *.logarchive files can be imported into the Console application.

The ‘log show’ command will parse the records from the binary log files either from a specific *.tracev3 file(s) or from a *.logarchive bundle . A user can filter on different predicates filters or time frames. It is worth noting that this command by default will not show you “info” or “debug” messages – be sure to keep that in mind. You can choose between different outputs as well including syslog or JSON styles.

Additional References:

  • https://developer.apple.com/videos/play/wwdc2016/721/