So I lied…one more blog post for the year. 🙂
Right before the Christmas holiday I received another really great question and I did not know the answer. My Google-Foo and phone-a-friend option went nowhere, so, as is customary, I grabbed my personal iPhone and iPad and started looking for the answer in my own data. The question was which artifact shows a phone call was made/received on a linked (using the same iCloud account) Apple device? This feature, known as Cellular Relay (aka Phone Relay or Call Relay – I will refer to it as “CR”) has been around since iOS 8 and macOS Yosemite, and is part of the set of features Apple calls Continuity.
While I have not been successful so far in finding the particular artifact in an encrypted backup, I was able to find a few .plist files that can be helpful in determining if CR is enabled, and, if so, what device(s) are eligible to make/receive phone calls. Additionally, while I was looking for CR I also stumbled across the .plist file that shows the same settings for SMSRelay (“SR”), the feature that allows Apple users to send/receive SMS messages on their non-cellular Apple devices. As with CR, determining where an SMS message originated is still something I am exploring, but I thought it was worth sharing as these files can give an examiner/investigator an idea about other devices that are linked to the same iCloud account.
For testing and a historical look, my devices were on the latest versions of their respective operating systems: iOS 16.2, iPadOS 16.2, and macOS Ventura (13.1). For the iPhone and iPad, I worked off of encrypted backups, and for macOS I simply worked on the device through the UI. I also had access to encrypted backups from iOS 14 and iOS 15.
Call Relay
The main thing to remember is that both CR and SR require a user to be signed into iCloud on devices with which they want to make/receive calls or messages; this is in addition to their iPhone. If a user has not signed into iCloud on a particular device, CR and SR are not available on that device. Additionally, any device(s) that is eligible for CR or SR have to be on the same Wi-Fi network for either feature to work. So, for example, if I am not home and receive a phone call on my iPhone, my iPad, which is at home, will not ring; however, the call log on my iPad (found in the FaceTime app) will update.
CR is not on by default. A user has to turn the feature on. The file that keeps track of CR settings is com.apple.TelephonyUtilities.plist, and it is found in /private/var/mobile/Library/Preferences/. This file is available in an encrypted backup. The first order of business is to determine if CR is on or off, and for this I observed different behavior in the file across the iOS versions. This could be due to the respective accounts having devices eligible to make receive phone calls or the fact that the feature had never been enabled. In some I observed no relevant plist keys being present (iOS 14 and iOS 15) and then a relevant key in others (also iOS 15 and iOS 16). Just be prepared to see one of two examples. Figures 1 and 2 are representative examples.
Figure 1 is an example of when no relevant plist key value is present. There is literally nothing present that is relevant to CR. Figure 2 is an example of when a relevant plist key value is present. There is a plist key relayCallingDisabled with a value of YES. Again, I suspect Figure 1 may also represent when a value had never been turned on, but it could also represent when there are no eligible devices on the account. More testing is needed here.
Once CR has been enabled a user has to determine which eligible device(s) they want to use to make/receive calls. Figure 3 shows how the UI appears to the user.
Note the color coding in Figure 3. Now, see Figure 4.
There are two relevant keys present. First, is the one seen in Figure 2, relayCallingDisabled. Here, the value is set to NO since it has been turned on (blue box in Figure 3). The second key is relayCallingDisabledForDeviceID. The key contains three items that are GUIDs with associated values (I have parts of the GUIDs redacted); the GUIDs represent devices that are able to make/receive calls. The values I have observed for the items are “1” and “0.” “1” is when the device is not allowed to make/receive calls (i.e. CR is disabled for that device) and “0” is when the device is allowed to make/receive calls (i.e. CR is enabled for that device). Slightly counterintuitive, I know, but that is the Apple way sometimes. The GUID in the middle in the red box has a value of “0” which means it can make/receive phone calls using the iPhone.
So having GUIDs is nice but they are not helpful by themselves. What devices do they represent? Fortunately, there is a place examiners can associate the GUID with the friendly name of the device: the Keychain. Using Physical Analyzer 7.59, I parsed the Keychain, and then filtered by the value “RPIdentity-SameAccountDevice.” Figures 5, 6, and 7 show the GUIDs highlighted in Figures 4 & 5 using the same color coding.
With the Keychain filtered, I was able to associate the GUIDs with the friendly names of the devices. As seen in Figure 4, the GUID in the red box had a value of “0” which indicated it was enabled for CR. Figure 5 show that the GUID is associated with the friendly name “Josh’s iPad,” which makes sense since “Josh’s iPad” was seen as having the CR switch turned on in Figure 3. The same file, com.apple.TelephonyUtilities.plist is found in my iPad in the same location as the iPhone. It is seen in Figure 8.
Figure 8 simply has the relayCallingDisabled key with a value of NO. Considering this iPad is non-cellular, an examiner seeing this should remember that this iPad was capable of making/receiving cellular calls using an iPhone on the same iCloud account and while on the same Wi-Fi network. Figure 9 shows com.apple.TelephonyUtilities.plist from Joshua’s Mac mini. It is located in /Users/%USER_ACCOUNT%/Library/Preferences/. Note the absence of any relevant key.
Just to emphasize how the files may look different across devices/OS versions, Figure 10 show the com.apple.TelephonyUtilities.plist from J2W iPhone after turning on CR. Note the presence of the relayCallingDisabled key. Remember, it was not permitted to make/receive calls as seen in Figure 3. Also keep in mind that this is also an iPhone, and could be capable of CR.
What would com.apple.TelephonyUtilities.plist look like on the iPhone if I were to turn CR off after having turned it on? Figures 11 & 12 show the result result.
After turning the CR off, the relayCallingDisabledForDeviceID key is removed from the plist, but the relayCallingDisabled key remains and the value is now YES.
One final note. com.apple.TelephonyUtilities.plist looks slightly different in iOS 14. The key value relayCallingDisabled did not appear in the file regardless of whether CR was on or off. However, if it was enabled, the key relayCallingDisabledForDeviceID was present along with any applicable device GUIDs. See Figure 13.
As previously mentioned, I have not yet been able to find any data in the encrypted backups that would give an indication on which device a call was made or received. More research is definitely needed. However, if an examiner is fortunate enough to have a FFS extraction, artifacts such as knowledgeC or biomes would be extremely helpful (e.g. appInFocus). Regardless, this particular artifact could be helpful in indicating to an examiner that other devices are on the iCloud account that could make/receive phone calls.
SMS Relay
Like CR, SR is not on by default; a user has to enable it. Figure 13 shows how it looks in the UI.
As before, Josh’s iPad was permitted to send/receive SMS messages, but the other two devices were not. The file com.apple.sms.plist stores the setting, and can also be found in /private/var/mobile/Library/Preferences/ on the iPhone. See Figure 15.
Recall that this same GUID (see in the key allowed) was seen in Figure 5 and associated with the friendly name “Josh’s iPad.” Again, this makes sense since that device has been permitted to make/receive SMS messages (Figure 14). Figure 16 shows the same file from the same directory path on the iPad.
The plist is rather simple with a single key: hasBeenApprovedForSMSRelay. The key has a value of YES. This key is deceptive, though. A plist file by the same name can be found in /Users/%USER_ACCOUNT%/Library/Preferences in macOS. It, too, contains a single key. See Figure 17.
You would be forgiven for thinking this is same as Figure 16. It technically looks like it, but I assure you it is from the Mac Mini. If you recall from Figure 14 Joshua’s Mac mini was not permitted for SR, yet here we see a value of YES for the key hasBeenApprovedForSMSRelay. I suspect this key represents that the device has been approved previously for SR but not necessarily that it’s enabled. So, examiners should be careful about how this plist key is interpreted on non-cellular devices.
What if SR is off, or it has never been enabled? Figure 18 shows how that looks.
Interestingly enough, the iPhone itself is approved for SR and lists itself with a GUID of all zeros. The difference here is that there are no other GUIDs present in the allowed key.
As with CR, I have not yet been able to find any data in the encrypted backups that indicate a message was sent/received from a particular device when SR is enabled. Again, if an examiner is fortunate enough to have a FFS extraction, knowledgeC or biome data can be valuable. But knowing additional devices may be out there can be valuable itself.
Finish Line
Call Relay and SMS Relay are a microcosm of the larger role iCloud sync’ing plays in examinations. Was a device used to send a SMS message or make a call at a particular point in time? Was it a known device, one that is currently in the examiner’s custody? Or, is it an unknown device, one that is still out in the wild? While the .plist files discussed in this post do not necessarily show a particular device was used, it can show that a particular device could have been used to make a call or send a SMS message. These files can also give an examiner a clue as to the broader list of Apple devices an iPhone user may have.
This is absolutely the last post of 2022. I want to wish everyone a Happy New Year. See you all in 2023.
