Disclaimer: The information and analyses presented in this article are the result of personal research and testing. They are provided for informational and educational purposes only. Any commercial use of the contents of this article without prior written permission from the author is strictly prohibited. Users are not authorized to copy, reproduce, transmit, or distribute the contents of this article without permission. The author disclaims any responsibility for the consequences of using the information contained in this article. For permission requests, please contact the author directly.
A few months ago, I published an article inestigating macOS unified logs (titled "Mouse clicks and more", it is available here). Today, I would like to share some interesting insights recently discovered on watchOS. As you may have guessed, this time, we will talk about a different Apple device, the Apple Watch.
This new investigation originated from my most recent LinkedIn post, which led to a great discussion with Christian Peter about the unified logs that might be found on a Apple Watch when placing a call. We researched a few logs on our respective watches to see which entries could be relevant and collaborated to present our initial observations in the “watchOS Unified Logs – First Observations” section. Next, I went back to my favorite device (my iPhone of course) to analyze the unified logs recorded when the watch is used to initiate a call .
Over time, what began as a “Unified Logs of the Week” post , typically much briefer, turned out to warrant a full article.
Christian Peter is a well-known figure in the digital forensics community, as he us the creator of the open-source tool “UFADE,” which allow digital investigators free extractions for Apple devices. His expertise in investigations goes beyond that, as he frequently contributes insights on Android related matters as well. I would like to take this opportunity to express my gratitude for the time he gave to this topic, which I’m truly passionate about, and for offering a fresh vision. Thank you Christian, studying watchOS unified logs was definitely a good idea!
If you haven’t done it yet, feel free to download his tool from his GitHub page and follow him on LinkedIn.
watchOS Unified Logs - First Observations
Before delving into the core of this article, we wanted to share our initial impressions/findings of watchOS. Although this operating system is also from Apple, its unified logs and processes differ from those on iOS. For example,, the SpringBoard process, maybe the most important process in iOS Unified Logs, does not exist on watchOS. Its counterpart on the Apple Watch is called “Carousel,” which is then an important process to consider in any watchOS Unified Logs investigation.
Below is a brief example illustrating this difference. Let’s look at the scenario in which an application launches after the user tapped on its icon:
iOS
Activity ID | Event | Description |
0 | SpringBoard: Allowing tap for icon view 'com.apple.mobilephone' | Launching phone application |
5180103 | SpringBoard: Launching application com.apple.mobilephone from icon <private>, location: SBIconLocationDock | Launching phone application |
5180103 | SpringBoard:(FBSceneManager):sceneID:com.apple.mobilephone-default] Scene lifecycle state did change: Foreground | Launching phone application |
5180103 | SpringBoard: [app<com.apple.mobilephone>:362] Setting process visibility to: Foreground | Launching phone application |
5180103 | SpringBoard: Application process state changed for com.apple.mobilephone: <SBApplicationProcessState: 0x3028e3d20; pid: 362; taskState: Suspended; visibility: Foreground> | Launching phone application |
0 | coreduetd: Focal App: com.apple.mobilephone, Previous: | Launching phone application |
watchOS
Activity ID | Event | Description |
45112 | Carousel: CarouselClass handleMainUIEvent: <CSLMainUIEvent: 0x1724fd80; type: CSLMainUIEventTypeTappedIcon; bundleIdentifier: com.apple.NanoPhone> | Launching phone application |
45112 | Carousel: Inserting default activation request for com.apple.NanoPhone | Launching phone application |
45112 | Carousel: [0x18420240:(FBSceneManager):com.apple.NanoPhone] Scene lifecycle state did change: Foreground | Launching phone application |
45112 | Carousel: <private> transitioning to state <private>, for reason iconTap, animated YES | Launching phone application |
45112 | Carousel: [app<com.apple.NanoPhone>:222] Setting process visibility to: Foreground | Launching phone application |
45112 | Carousel: com.apple.NanoPhone moved to the foreground, (null) is no longer in the foreground, updating <private> | Launching phone application |
0 | Launching phone application |
We can observe certain similarities between the logs recorded by these two processes (for example Log #3). However, there are also a few important differences to be aware of when conducting a watchOS investigation in order to find the relevant logs. Second, watchOS processes typically include the prefix “nano”. So, don’t be surprised if you come across processes like nanoPhone, nanoCalculator, or nanoCalendar, this is perfectly normal.
Finally, it appears at first glance that watchOS captures fewer unified logs than iOS. This is only a preliminary impression based on our observations and would require further investigation. To give you an idea, iOS records roughly 10'000 logs per second when the phone is idle, while watchOS hovers around 1'000. That difference is far from negligible.
watchOS - Unified Logs Calls
When an Apple device initiates a call, a special process named callservicesd is launched. This is true for both iOS and watchOS and it is important to remember this process when investigating calls, as it can significantly help you find what you’re looking for and guide your investigation. If you don't know where to begin, searching the unified logs recorder by this process can be a good starting point.
For instance, when a call is made from the Apple Watch, we didn’t find any logs explicitly referencing the contact or number called unlike on iOS. This makes the research a bit more challenging. Indeed, searching for the dialed number within the Unified Logs can be a quick way to find other relevant information, but it won’t work on watchOS.
As a result, the initial search had to be larger, I simply looked for any logs containing the term “call” and the first logs I found were as follows:
Activity ID | Event |
187995 | Carousel: activating connection: mach=true listener=false peer=false name=com.apple.telephonyutilities.callservicesdaemon.callprovidermanager |
187995 | callservicesd: machServiceName: com.apple.telephonyutilities.callservicesdaemon.callprovidermanager newConnection: <private> |
Although these two logs are interesting, particularly due to the references “Activating connection,” “telephonyutilities,” and “callservicedeamon”, they are not sufficient to prove that a call was made. Nevertheless, as I often recommend, using the activity identifier (in this case, 187955) is an excellent way to find other logs related to those you have just uncovered. When I searched for this identifier in the Mac Console, more than 1'600 logs were found (throughout my tests, this number varied from a few hundreds to over 2'000. At this point, I have no idea what causes such a difference. However, it does not affect the logs presented later in this article):
Although this may seem like a lot, reviewing 1'600 lines is not too time consuming. It is now essential to isolate a few logs that can help us demonstrate that a call was actually placed. The unified ogs in the table below were all recorded within an interval of a few milliseconds, and each one contained the activity identifier 187995 which is importnat to link them.
# | Event |
1 | Carousel: handleOpenApplicationRequest for (null) from com.apple.NanoPhone |
2 | Carousel: performDial: 1 useRelay: 1 |
3 | Carousel: isDialRequestValid: 1 existingCallsAllowOutgoingCall: 1 isCallingAvailable: 1 |
4 | Carousel: 0009 Contact: 1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson |
5 | Carousel: statusChangedForCall <private> |
6 | callservicesd: Started tracking call: <private> |
7 | callservicesd: A paired device exists, so using that as the dialing device: <private> |
8 | call servicesd: Dialed call: <private> |
9 | Carousel: Received call status changed notification: <private> |
10 | callservicesd: Initializing new callID with device role 1 |
11 | callservicesd: 0024 Contact: 1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson |
12 | avconferenced: [NOTICE] VCConnectionManagerUseCellPrimaryInterfaceInternal:2733 callID = 408180485, network status bar request, useCellPrimayInterface = 0 |
All of these logs are recorded when a call is initiated from the Apple Watch. The first two entries (Log n°1 and Log n°2) respectively show that the application nanoPhone requested to open another application that is not mentioned and the network status check request before the connection is established. We then see “IsDialRequestValid: 1” (Log n°3), the presence of the “ContactIdentifier” GUID (Log n°4) noted by the Carousel process, and again in Log n°11, this time captured by callservicesd. Logs n°5 and n°6 confirm that the call has started, as indicated by the mentions “StatusChangeForCall” and “Started tracking call.”
Log n°6, in my opinion, serves as an excellent starting point for investigating calls initiated from the watch. Begin by searching all logs containing the phrase “Start tracking call,” and then proceed by analyzing the corresponding activity identifier. This method has often saved me time and helped me quickly locate all related logs. Log n°7 reveals that a device is indeed paired with the watch, confirming the link between the iPhone and the Apple Watch. Log n°10 indicates that a “new callID” is generated, further suggesting that the call is successfully initialized. We can therefore hypothesize that the user is attempting to reach the contact whose identifier is 1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson. As previously mentioned, this ContactID alone does not allow us to retrieve the dialed phone number without having access to the paired iPhone. Log n°12 references the callID number, and this callID is present in the paired iPhone’s logs as well (we will see that later). This correlation provides a direct link between the watch,based call data and the phone logs, that's great !
Finally, it’s worth noting that the term “private” frequently appears in these various logs. This is not surprising, given Apple’s heightened focus on data privacy. While this notation may conceal certain details that could potentially be very interesting, it does not significantly affect the investigation of the unified logs.
And on the Paired iPhone ... What Unified Logs can we find ?
A few weeks ago, I published a “Top Logs of the Week” article showcasing various unified logs that indicate how a call was initiated. For reference, you can find these articles here. Making a call via a connected watch is no exception—it also generates a log on the paired iPhone! In other words, it is relatively straightforward to show that the call was not made by operating the phone itself. Here is the relevant unified log:
Event | Activity ID | Call Origin |
SpringBoard: Received trusted open application request for "com.apple.InCallService" from <FBProcess: 0x9d3787780; osservice<com.apple.telephonyutilities.callservicesd>:144(v189)>. | 155830 | Apple Watch |
It’s interesting to note the “telephonyutilities” reference here, which we’ve already encountered multiple times in the connected watch logs. The above log confirms that the request to open InCallService was triggered by telephonyutilities.
Earlier, we briefly mentioned the call ID 408180485 appearing in the watchOS unified logs. By searching for this number in my paired iPhone’s logs, I found the following entry:
Event |
avconferenced: VideoConference [INFO] -[VideoConference(SessionDelegate) session:didStart:connectionType:localInterfaceType:remoteInterfaceType:error:]:3283 didStart:session <VCCallSession localCallID = 1973289969, remoteCallID = 408180485, state = 1, sentDidStartAsYES = 1>, didStart = 1, connType = 2, InterfaceType = NonCellular, NonCellular, error = <nil>, claimed Session = <VCCallSession localCallID = 1973289969, remoteCallID = 408180485, state = 1, sentDidStartAsYES = 1> |
This log is recorded by the avconferenced process on both the iPhone and the watch, and it explicitly references “remoteCallID = 408180485.” This establishes our first link to the unified logs recorder on the watch. Moreover, the Activity Identifier for this log is 155830, tying it to the log recorded by the SpringBoard process mentioned earlier.
Finally, we also see the notation localCallID = 1973289969. Can we find additional details in the watch logs using this ID? Yes, we can! By searching for this value in the watch’s unified logs, I found the following entry:
Activity ID on the Watch | Event |
0 | avconferenced: VCCallSession [NOTICE] -[VCCallSession setRemoteCallInfoFromInviteDictionary:]:3257 Remote callInfoBlob = callID: 1973289969, clientVersion: 1, deviceType: "iPhone12,8", frameworkVersion: "2055.56.1", osVersion: "22A5307f", localCallID = 408180485 |
First of all, both CallID numbers appear in this log, and it’s particularly interesting to note that the paired iPhone’s remoteCallID corresponds to the watch’s localCallID, and vice versa. This confirms that we have successfully linked the watch’s unified logs to those on the iPhone. We can also see that the watch’s logs contain information about the paired iPhone: in this case, the “machine ID” deviceType: iPhone12,8 corresponds to an iPhone SE 2020 (source: Github) running OS version 22A5307f (iOS 18 beta 3, source: BetaWiki), both are completely correct.
However, this alone isn’t necessarily precise enough to prove that the call was indeed made from the connected watch. Once again, I recommend searching for all logs containing the activity identifier 155830. Linking these logs helps me find another entry that (this time) confirms the call originated on the watch. That said, we still don’t know which phone number was dialed from the watch. Don’t panic—let’s go back and examine the iPhone’s unified logs again, focusing on those that have activity ID 155830.
Event |
callservicesd: Invite received for session 1B4CC8CF-8856-4935-A946-9EEC09E86AE6 from (fromID=device:545A4A2E-EDC4-4EF8-A8F0-FF8B3065254A) destination <IDSDestinationURI: 0xd7ba42a70 uri: <IDSURI: 0xd7a7f6d00; u:ASklTRx95TPQ+3XM> device [_IDSDevice 0xd7b49ebe0: Name: Lionel’s Apple Watch Model: Watch6,15 UniqueID: all 0s UniqueID Override: 545A4A2E-EDC4-4EF8-A8F0-FF8B3065254A Push Token: {length = 32, bytes = 0xeceec3e6 3e51ece1 540f718f 24dadbb2 ... 3de0bf19 38d5d90d } Service: com.apple.private.alloy.phonecontinuity nsuuid: EE5E4CBF-27FA-3168-CD69-8D059E617CB5 relationship: 1 supportsSMSRelay: NO supportsMMSRelay: NO supportsPhoneCalls: NO deviceColor: 1 enclosureColor: 1 local: YES defaultPairedDevice: YES isNearby: YES isConnected: YES isActive: YES isLocallyPaired: YES isHSATrusted: YES build: 22S101 pairing protocol: 23 min compatibility version: 9223372036854775807 max compatibility version: 23] with message <CSDMessagingRelayMessage: 0xd7addddc0> { contactIdentifier = "1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson"; destinationID = "+4176[REDACTED]"; […] uniqueProxyIdentifier = "9F06752C-1F6F-4600-9F10-B39D0310F25E"; } (timestamp: 1735900193.065453) |
We finally know which number was called!! This unified log, recorded on the paired iPhone, is truly important because it provides a great amounf of information about the connected watch and the phone number that was called. Moreover, this second log also reveals a substantial amount of additional information about de watch:
Connected Watch Name: Lionel’s Apple Watch
Connected Watch Model: Watch6,15
Supports Phone Calls: No
Color Number: 1
Contact Identifier: 1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson
Number Called: +4176[REDACTED]
Build version : 22S101 that allows us to determine the watchOS version 11,2 (source: macprime).
The uniqueProxyIdentifier value corresponds, in some logs, to the callUUID value ( we will see this later).
Timestamp of the call
It’s worth noting that the ContactIdentifier in the above log (recorded by the iPhone) is identical to the one captured by the watch (via the Carousel and callservicesd processes). The “Invite Received” log shown above does not exist when a call is placed directly from the phone. It should also be noted that this log is recorded at the same time as the call logs on watchOS.
Finally, the log contains a timestamp (1735900193.065453) in the epoch format, as confirmed by the image below (source: Epoch Converter):
If you want to determine the name under which the contact associated with the ContactIdentifier you’ve just found (in this example, 1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson) is saved, you can look up this value in the phone logs. You should then find the following entry (which has the same identifier as the others—in this case, 155830).
Event |
callservicesd: Determined compositeName: L Notari for contacts: (identifier=1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson, givenName=L, familyName=Notari, organizationName=(nil), phoneNumbers=(\n \"<CNLabeledValue: 0xd7b4e1a80: identifier=69B9BBDF-7F13-4503-BF06-E176269F8397, label=_$!<Mobile>!$_, value=<CNPhoneNumber: 0xd7b4a5050: stringValue=076[REDACTED]", initialCountryCode=(nil)>, iOSLegacyIdentifier=0>\"\n), emailAddresses=(\n), postalAddresses=(not fetched)>" |
From this log, we can see that the contact identifier 1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson is saved under the name “L Notari” and has the phone number “076[REDACTED]” (or +4176[REDACTED] if we refer to the previous log).
Finally, I’d like to show you two more logs, both linked to the previous ones by their Activity ID. The first explicitly states “start call action,” which can be useful for once again confirming that the call took place. The second confirms the date and time of the call—January 3, 2024, at 10:29:53—which we identified using the timestamp in the log mentioned earlier.
In conclusion, both of these logs contain “callUUID=9F06752C-1F6F-4600-9F10-B39D0310F25E,” which matches the “uniqueProxyIdentifier” value noted previously.
Event |
callservicesd: Asked to perform start call action <CXStartCallAction 0xd7b8a59a0 UUID=372C1532-F4E7-4094-8E14-D7240F72068E state=0 commitDate=(null) callUUID=9F06752C-1F6F-4600-9F10-B39D0310F25E handles=("<CXHandle 0xd7a7f75e0 type=PhoneNumber value=u:LN/mpsuufiEVQpo/ siriDisplayName=(null)>") contactIdentifier=1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson […] |
callservicesd: Call source manager <CXCallSourceManager: 0xd7adb6a40> completed transaction group { "com.apple.coretelephony" = "<CXTransaction 0xd7a7f76a0 UUID=99B02A4F-9A02-4CF7-8B54-F59C8021E0DC isComplete=1 actions=(\n \"<CXStartCallAction 0xd7b8a59a0 UUID=372C1532-F4E7-4094-8E14-D7240F72068E state=1 commitDate=2025-01-03 10:29:53 +0000 callUUID=9F06752C-1F6F-4600-9F10-B39D0310F25E type=PhoneNumber contactIdentifier=1B9CCD6A-F346-49B6-834F-702C63AEE1A7:ABPerson video=0 relay=1 upgrade=0 retry=0 emergency=0 isVoicemail=0 ttyType=0 dateStarted=2025-01-03 10:29:53 +0000 |
Conclusion
This first article about watchOS unified logs shows us how closely a paired iPhone and Apple Watch communicate. Many details related to the iPhone can be retrieved in the watch’s logs, and conversely, the iPhone also records information about the watch. These traces can be particularly valuable for digital investigations.
However, it’s important to remember that without access to the iPhone, the watch’s unified logs contains only limited information. While it may be possible to find certain activities, investigators could miss details that are only available in the iPhone’s unified logs. In the example covered in this article, we’ve seen that the watch logs alone are insufficient to precisely identify the dialed number (we only have the contactIdentifier "GUID"). If confirming that a call took place is possible, pinpointing the exact contact is more challenging.
In the end, being aware of the differences between watchOS and iOS is essential for digital investigators, especially the different processes specific to each Apple device. Cross-referencing the logs from both the watch and the phone provides a more complete view of the events.
Enjoy your Digital Investigations !
Lionel Notari
Comments