While the plist file "com.apple.purplebuddy.plist" has been around a while and had some good information, it's also been a bit limited. So let's dig a little deeper and see what else we can find.
Within iOS, there's a great plist file that can help talk about device backups. This is the "data_ark.plist" that can be found within a file system image of an iOS device at the path /private/var/root/Library/Lockdown.
This file has several important keys.
 - FirstPurpleBuddyCompletion - This is a Unix millisecond epoch value which can help show the first time the "Purple Buddy" or Apple's setup assistant was completed. The main PurpleBuddy plist (anyone else always think of "bonzai buddy" when they hear purple buddy?) has its own timestamp value but other things can update it including system updates between certain iOS versions.
 - com.apple.purplebuddy-SetupState
 - com.apple.purplebuddy-RetoreState
This will show information about how the device was setup and/or restored. It will contain information relating to one of (at least) three values.
RestoredFromDevice - A Device-To-Device setup
RestoredFromiTunesBackup - Pushing a device backup from iTunes
RestoredFromiCloudBackup - Pushing a device backup from iCloud
This file can also show the computer name of where an iTunes backup has been stored from a target device. This makes tracking both source and target devices easier.
I'm one for additional validation. Also, I've found that the data_ark.plist hasn't always been so forthcoming on information. If we navigate over to private/var/mobile/Library/Preferences and locate the file com.apple.purplebuddy.plist we can find some additional information.
SetupUsingAssistant - This is the same for device to device and local backup to device.
RestoredFromCloudBackup - When restored from an iCloud backup.
The "SetupLastExit" key can also help to show when Purple Buddy was exited and can be compared to the value in data_ark.plist if available.
In this same directory (private/var/mobile/Library/Preferences) there is another very informative plist file called com.apple.migration.plist.
By reviewing the above records, it's possible to see how the device backup was restored either from device-to-device, iTunes backup, or iCloud backup! It will also list out the build version of the software it was restored FROM which can help show a pattern of upgrades/restores. The RestoredBackupProductType key also gives the model ID of the source device.
A word of warning about the "BackupDeviceUUID" value. I'm still trying to track where this value comes from but it's not the UDID in all cases that we have come to know. It would make a great keyword value on a target device though!
The Reason key is also incredibly informative and maybe my favorite. This value will show the TARGET device's UDID (which we likely already know because it's the device we're analyzing) but does show the date and time of the restore! Woo!
Now in the case of any of these backup restorations, who is going to have data on what devices are part of the Apple account? Hint, they're a fruit company and I'm not talking about Banana Republic. Obviously it's Apple.
There are several values that you can use to send off to Apple to find out some more information if you have search warrant or subpoena powers. Within the database Accounts3.sqlite (found within /private/var/mobile/Library/Accounts), a key referencing the "appleid-authentication" type will reveal the email address of the Apple ID. However, users can change their Apple ID email address over time. There's actually a better value.
The DSID or Directory Services Identifier is the numerical backing to the Apple ID used by Apple to track the account. This value can be found in a variety of places depending on which iCloud services are being utilized by the user. One of the easiest places to find this is within the plist files com.apple.icloud.fmfd.plist or com.apple.itunescloud.daemon.plist/com.apple.itunescloud.plist. If you don't have access to these legal routes, getting access to a user's "Download Your Data" results from Apple can also have most of this same information to track devices users have migrated between.
That is going to wrap up the part of this multi-part series. For the first part, please see this link on device migration artifacts form iOS to a Samsung device. Up next will be tracking device migration on generic Android.