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.
In previous articles, we explored certain iOS unified logs related to the unlock process as well as the WhatsApp application. In this current article, I aim to share the Unified Logs that you can analyze when a user makes a call with their iPhone. Indeed, if the user calls a chosen contact from the Phone application or by using Siri, for example, the generated Unified Logs will be significantly different, providing valuable clarification.
It is crucial to note that these distinctions in the logs can play a pivotal role in various investigations, particularly in the field of road traffic accidents. Therefore, a thorough understanding of these specific logs can offer valuable insights into how users interact with their phones when making calls.
Mobile Phone Application
As we have previously examined (see this article: WhatsApp Unified Logs ), opening an application by clicking on its icon generates a significant quantity of logs. The SpringBoard process, in particular, records a log explicitly stating the application that has been opened (in the case of a Native application). The analysis of the unified logs provided below sheds light on the opening of this application.
Timestamp | Event |
2023-12-15 22:02:03 | SpringBoard: Allowing tap for icon view 'com.apple.mobilephone' |
2023-12-15 22:02:03 | SpringBoard: Icon tapped: <private> |
2023-12-15 22:02:03 | SpringBoard: Initiating launch from icon view: <private> |
2023-12-15 22:02:03 | SpringBoard: Bootstrapping application<com.apple.mobilephone> with intent foreground-interactive |
2023-12-15 22:02:03 | SpringBoard: [sceneID:com.apple.mobilephone-default] Scene lifecycle state did change: Foreground |
2023-12-15 22:02:04 | MobilePhone: Resuming to tab type: 4 |
The first three logs recorded by the SpringBoard process are self-explanatory, and it does not seem necessary to provide further detailed descriptions since they explicitly mention that the "mobilephone" application was launched from the icon, thus indicating a potential manipulation of the device. However, it is important to note that the fourth log, "Boostrapping application...," is registered only when the application was not running in the background prior to its opening (Therefore, do not be surprised if you do not find this log during your future investigations). In other words, the application is completely closed before the user activates it. The final log from the SpringBoard process is recorded once the application is open on the iPhone's screen and ready to be used, while the log from the MobilePhone process, specific to the "Phone" application, indicates which "tab" the user lands on when the application opens. The five following tabs are displayed to the user when the Phone app opens:
Each of these tabs is assigned a number that will enable investigators to determine from which one the call was made.
Timestamp | Event | Tab |
2023-12-15 22:02:05 | MobilePhone: Activity continuity - Activity needs saving as the tab bar tab changed to 1 | Favourites |
2023-12-15 22:02:05 | MobilePhone: Activity continuity - Activity needs saving as the tab bar tab changed to 2 | Recents |
2023-12-15 22:02:05 | MobilePhone: Activity continuity - Activity needs saving as the tab bar tab changed to 3 | Contacts |
2023-12-15 22:02:05 | MobilePhone: Activity continuity - Activity needs saving as the tab bar tab changed to 4 | Keypad |
2023-12-15 22:02:05 | MobilePhone: Activity continuity - Activity needs saving as the tab bar tab changed to 5 | Voicemail |
Returning to the initial table, we can discern that the user accessed the keypad when the application opened ("MobilePhone: Resuming to tab type: 4 "). Additionally, each time the user switches tabs, a corresponding entry in the aforementioned table will be recorded. This enables investigators to precisely determine the sequential steps undertaken by the user.
Simultaneously, when the application is exited, either by putting it in the background or closing it entirely, the MobilePhone process records a similar log. For example:
Timestamp | Event |
2023-12-15 22:02:07 | MobilePhone: Wrote out last tab type: 4 |
These two logs of opening and closing, therefore, enable investigators to precisely determine the user's location within the application at the moment they exited it.
Calls from Contacts Tab
Before being able to click on a contact's name, the user will need to navigate to the "Contacts" tab. Therefore, you should find one of the two previous Unified Logs mentioning "tab 3" (either the log "Resuming to tab type: 3" or the log "Activity continuity - Activity needs saving as the tab bar tab changed to 3"). Once on the correct tab, the user will then click on the contact's name they wish to call, and the following unified logs will be recorded:
Timestamp | Event |
2023-12-15 22:02:07 | MobilePhone: [CNContactContentViewController] setting contact with identifier BAA334FE-0D1B-4EBA-8676-8E90EE3683A5:ABPerson |
2023-12-15 22:02:07 | MobilePhone: [CNContactContentViewController] setting contact with identifier C30E9AAC-8263-4B6C-8ED2-26CB345DC30A:ABPerson |
2023-12-15 22:02:07 | SpringBoard: Received trusted open application request for "com.apple.InCallService" from <FBApplicationProcess: 0x73e92c510; application<com.apple.mobilephone>:1041(vB80)>. |
2023-12-15 22:02:07 | callservicesd: Call started outgoing: <private> |
2023-12-15 22:02:07 | callservicesd: All calls ended. Setting uplink and downlink muted to NO. |
As can be observed in the table above, each contact has a unique alphanumeric identifier (first and second unified logs in the table above are examples for two different contacts). Once the user clicks on the contact of their choice, they can initiate a call, generating the SpringBoard log that indicates the "InCallService" application was opened by the com.apple.mobilephone application. This is particularly interesting. Furthermore, when the call begins, the callservcicesd process records it in a log titled "Call started outgoing." Finally, when the call concludes, this event is also logged by the callservicesd process. These diverse unified logs allow us to precisely determine how the call was initiated.
Calls from Keypad Tab
Similarly to calling a saved contact, the user needs to click on the "Keypad" tab before being able to type a number, thereby generating a log that mentions this as tab number 4. Locating this log serves as a good initial indicator.
From the Keypad Tab, the user must, of course, type the number they want to call.
During, my research, I observed the following surprising thing: each number on the keypad will generate a different log! In other words, it is possible to precisely determine the number entered by the user simply by analyzing the unified logs:
Event | Number |
mediaserverd: SSServerImp.cpp:732 -> Incoming Request : actionID 1200, inClientPID 1041(MobilePhone), inBehavior 0, customVibeDataProvided 0, loop 1, loopPeriod 0.000000, inFlags 0, inClientCompletionToken 1, inClientAudioSessionID 0 | 0 |
mediaserverd: SSServerImp.cpp:732 -> Incoming Request : actionID 1201, inClientPID 1041(MobilePhone), inBehavior 0, customVibeDataProvided 0, loop 1, loopPeriod 0.000000, inFlags 0, inClientCompletionToken 2, inClientAudioSessionID 0 | 1 |
mediaserverd: SSServerImp.cpp:732 -> Incoming Request : actionID 1202, inClientPID 1041(MobilePhone), inBehavior 0, customVibeDataProvided 0, loop 1, loopPeriod 0.000000, inFlags 0, inClientCompletionToken 3, inClientAudioSessionID 0 | 2 |
... | ... |
mediaserverd: SSServerImp.cpp:732 -> Incoming Request : actionID 1207, inClientPID 1041(MobilePhone), inBehavior 0, customVibeDataProvided 0, loop 1, loopPeriod 0.000000, inFlags 0, inClientCompletionToken 4, inClientAudioSessionID 0 | 7 |
mediaserverd: SSServerImp.cpp:732 -> Incoming Request : actionID 1208, inClientPID 1041(MobilePhone), inBehavior 0, customVibeDataProvided 0, loop 1, loopPeriod 0.000000, inFlags 0, inClientCompletionToken 5, inClientAudioSessionID 0 | 8 |
mediaserverd: SSServerImp.cpp:732 -> Incoming Request : actionID 1209, inClientPID 1041(MobilePhone), inBehavior 0, customVibeDataProvided 0, loop 1, loopPeriod 0.000000, inFlags 0, inClientCompletionToken 6, inClientAudioSessionID 0 | 9 |
As shown in the table above, the number associated with the actionID (from actionID 1200 to actionID 1209) recorded by the mediaserverd process informs us about the digit pressed by the user! Once again, these unified logs reveal which digits were pressed by the user and in what order. Ultimately, when the user decides to call the number entered on the keypad, and subsequently when the call concludes, the two previously examined call logs will be recorded.
Call from Speed Dial
The user also has the option to save favorite contacts as a "Widget." This will generate an icon for that contact on the "Today" screen of the iPhone. When the user scrolls to the side and accesses the "Today" page, the first two unified logs in the table below are recorded by the SpringBoard process:
Timestamp | Event |
2023-12-15 22:03:47 | SpringBoard: Today view overlay will appear. animated: Yes. |
2023-12-15 22:03:47 | SpringBoard: Overlay today view did scroll to reveal icons |
2023-12-15 22:03:47 | SpringBoard: Setting visibility of widget com.apple.PeopleViewService.PeopleWidget-iOS to visible settled |
2023-12-15 22:03:47 | SpringBoard: [0x73f872800-timeline[com.apple.PeopleViewService.PeopleWidget-iOS:SingleContactWidget_iOS:systemSmall:-9220794473229687680:148.00/148.00/20.20:(null)]] Received actions: {( <UIOpenURLAction: 0x2832254c0; info: <BSSettings: 0x2832273c0> { url = people:showSearchResult?contactIdentifier=BAA334FE-0D1B-4EBA-8676-8E90EE3683A5:ABPerson; }; responder: <_BSActionResponder: 0x281fab640; active: YES> clientInvalidated = NO; clientEncoded = NO;> )} |
2023-12-15 22:03:47 | callservicesd: Call started outgoing: <private> |
2023-12-15 22:03:47 | callservicesd: All calls ended. Setting uplink and downlink muted to NO. |
These first two logs provide clear information regarding the user's access to the "Today" page. In the course of my investigation, I found my contacts' widgets located at the bottom of the "Today" page. Before being able to click on any of them, I had to scroll down, and at the moment when the widgets were displayed on my screen, the third log in the above table was recorded. Once the various widgets of the contacts are available, the user can then click on one of them. By clicking on the desired contact, their respective "page" opens and generates the fourth log in the table above. It is noteworthy that this log also mentions the alphanumeric code assigned to the contact (as we have seen previously), and it is perfectly identical to the one assigned from the Contact tab.
These various Unified Logs thus enable digital investigators to demonstrate that the phone was indeed manipulated with the intent of making a call. Finally, and merely for informational purposes, exiting the "Today" page generates the following two unified logs:
Timestamp | Event |
2023-12-15 22:07:09 | SpringBoard: Overlay today view did disappear |
2023-12-15 22:07:09 | SpringBoard: Today view overlay did disappear, animated: YES. |
Call with Siri
Certainly, before being able to ask Siri a question and receive a response, it is necessary to activate Siri. To highlight this, the first log in the table below can be helpful. Indeed, this log is recorded when Siri is activated (and also when Siri is exited by the user), whether the phone is locked or unlocked:
Timestamp | Event |
2023-12-15 22:10:23 | SpringBoard: Siri: speech interaction activity started |
2023-12-15 22:10:24 | SpringBoard: Siri: preheat |
2023-12-15 22:10:24 | SpringBoard: Siri: Successfully started preheat |
2023-12-15 22:10:24 | assistantd: Sending SpeechRecognized command |
2023-12-15 22:10:24 | |
2023-12-15 22:10:24 | callservicesd: Call started outgoing: <private> |
2023-12-15 22:10:24 | SpringBoard: [0x2815616c0:(FBSceneManager):sceneID:com.apple.InCallService-F61C1AB1-9A74-471E-B686-BCCF02BBFEC9] Scene lifecycle state did change: Foreground |
2023-12-15 22:10:24 | callservicesd: All calls ended. Setting uplink and downlink muted to NO |
The first three unified logs recorded by the SpringBoard process simply show the activation of Siri, which can be of significant importance and a good starting point if you need to demonstrate the use of Siri. The fourth log is recorded when Siri responds vocally (for example, to confirm what has been said and to request confirmation) to our request. This log, therefore, attests to an interaction between the user and Siri.
The fifth log is particularly interesting as it indicates that the opening of the "InCallService" location was generated by the assistantd processes, which is none other than a process related to Siri. This reminds us of what we studied earlier in the "Call from Contacts Tab" section, where the unified log recorded at the time of the call stated, "SpringBoard: Received trusted open application request for "com.apple.InCallService" from <FBApplicationProcess: 0x73e92c510; application<com.apple.mobilephone". Therefore, we can easily discern the difference between a call made from the Phone application and one initiated through Siri by investigating the specific unified logs for each of these two methods.
Conclusion
There are myriad ways to make a call with an iPhone, and we've only explored a few here. However, the various examples we've examined in this article should enable you to investigate these actions with precision and detail, shedding light on whether the user did indeed manipulate their phone.
Throughout this article, we have explored unified logs that allow us to highlight the different steps taken by the iPhone user in order to make a call. We have observed that unified logs recorded when clicking on a contact's name, entering a number on the keypad, or activating Siri are distinct. The investigation of these unified logs will thus enable forensic investigators to determine which method was employed, which can be crucial in certain digital investigations.
More generally, I hope that these various articles will convince you of the importance of investigating unified logs when you find yourself tasked with examining an iPhone. Indeed, although it requires a certain amount of time, they illuminate the entire keystrokes made by the user to perform a specific action!
Enjoy your Digital Investigations !
Lionel Notari
Yorumlar