iOS Unified Logs - WiFi and AirPlane Mode

In the dynamic realm of iOS functionality, the Control Center emerges as a pivotal interface, offering users seamless access to critical device settings and utilities. Among its array of features, Wifi and Airplane Mode stand out as fundamental components, pivotal for managing connectivity and device operation.

However, the Control Center is not the sole avenue for managing these functions; Wifi and Airplane Mode can also be controlled through the Settings application of the phone, and certain options can be easily modified using Siri. These various methods of manipulating Wifi and Airplane Mode will generate iOS Unified Logs unique to each action.

Regarding Wifi, multiple options are available to the phone user. It is possible to configure networks to "Auto Join," allowing the phone to automatically reconnect to them each time, thus eliminating the need to re-enter the required password with each connection attempt. In instances where the Wifi network is new, for example, the user will be prompted to enter this password. All of these actions generate distinct iOS Unified Logs, enabling digital investigators to accurately reconstruct the user's actions.

Control Center

In previous articles, we have seen that it is possible to activate an application in several different ways (such as clicking on the icon or asking Siri, for example). The Control Center is no exception to this rule, as there are also multiple ways to make it appear on the screen., for example:

1. Horizontal swipe on the screen

2. Using the "Back Tap" feature of the iPhone (which allows for configuring the action triggered by tapping the back of the phone two or three times).

As you can see, Siri does not appear here. Indeed, it is not possible to summon this special menu onto the screen by asking Siri. Depending on whether option 1 or 2 presented above is used by the user, the generated logs will differ. Let's delve into this in more detail.

Horizontal swipe on the screen

I'm likely taking little risk in stating that every iPhone owner has accessed the Control Center through a swift swipe of their screen. This action generates the following logs:

Timestamp	Event
2024-02-11 19:43:01	AccessibilityUIServer: [PHOENIX] -[AXPhoenixMitigator setTouchOn:] TouchOn: 0 -> 1
2024-02-11 19:43:01	SpringBoard: Deferring device orientation updates for reason: Control Center Visible
2024-02-11 19:43:01	wifid: Control Center launched
2024-02-11 19:43:01	SpringBoard: Updating control center window visibility - hidden:NO alpha:1.00

The first iOS Unified Log in the table above informs us that the user touched the screen of their phone. With the subsequent unified logs recorded, it is rather straightforward to hypothesize that the user touched the screen to bring up the Control Center. From these, we can note the following mentions: "Control Center Visible", "Control Center Launched" et "control center window visibility - hidden:NO"

Back Tap option

An option that may be much less known than the first to access the Control Center is to configure its opening by tapping on the back of the phone. This can be set up from the Settings application (Accessibility - Touch - Back Tap) and can prove to be practical in certain circumstances. Once in the "Back Tap" menu of the phone, the user has the possibility to configure two different options depending on whether they tap two or three times against the back of their phone.

Good news, the iOS Unified Logs are so precise that their analysis allows digital investigators to determine whether the user tapped two or three times against the back of their phone to access the Control Center. Let's once again delve into this in more detail.

Timestamp	Event
2024-02-11 19:55:41	AccessibilityUIServer: [PHOENIX] -[AXPhoenixAnalytics _sendEvent:completion:] Back Tap Event: {"assetVersion":9,"eventType":"AXPhoenixAnalyticsEventTypeDoubleTap","accelerometer"
2024-02-11 19:55:41	AccessibilityUIServer: Failed to handle event in time for event tap: System back tap
2024-02-11 19:55:41	SpringBoard: Deferring device orientation updates for reason: Control Center Visible
2024-02-11 19:55:41	wifid: Control Center launched
2024-02-11 19:55:41	SpringBoard: Updating control center window visibility - hidden:NO alpha:1.00

The last three logs in the table above have already been discussed previously, so I will not revisit them. What is very interesting to note here is the first Unified Log, as it explicitly mentions "Back Tap Event" and "EventTypeDoubleTap". The second log presented simply confirms that the phone has indeed undergone a "back tap". Since we can see the launch of the Control Center immediately after this action is performed, forming a hypothesis once again is rather straightforward.

The user also has the option to tap three times on the back of their phone to access the Control Center (or perform another action they have configured beforehand). In this case, the recorded log will be very similar to the one discussed above, except it will mention "EventTypeTripleTap" instead, as shown in the table below:

Timestamp	Event
2024-02-11 20:02:03	AccessibilityUIServer: [PHOENIX] -[AXPhoenixAnalytics _sendEvent:completion:] Back Tap Event: {"assetVersion":9,"eventType":"AXPhoenixAnalyticsEventTypeTripleTap","accelerometer"

Airplane Mode

One of the simplest ways to activate and deactivate Airplane Mode is to do so directly from the Control Center. Since the Unified Logs specific to this menu have already been discussed, I will focus here on the subsequent actions:

Timestamp	Event	Action
2024-02-11 20:15:24	SpringBoard: Toggle AirPlane Mode state to on	Airplane mode changed to ON
2024-02-11 20:15:24	SpringBoard: enabling airplaneMode	Airplane mode changed to ON
2024-02-11 20:15:32	SpringBoard: Toggle AirPlane Mode state to off	Airplane mode changed to OFF
2024-02-11 20:15:32	SpringBoard: disabling airplaneMode	Airplane mode changed to OFF

It is important for me to specify that the first (as well as the 3rd) log is not recorded when Airplane Mode is activated from the Settings application. If, during your digital investigation, you come across the logs above, I would suggest taking the time to analyze the Unified Logs just before them. This should help you to hypothesize that Airplane Mode was activated or deactivated from the Control Center.

In the event that Airplane Mode is modified from the Settings application, you could search for logs showing that the user opened this application (if you are unsure which logs to investigate, I suggest this article about Making a Call]), and then look for the following logs:

Event	Action
Preferences: Setting airplane mode enabled: 1	Activating AirPlane mode from Settings

Indeed, if you can show, through the investigation of Unified Logs, that the Settings application was opened just before the Airplane Mode was modified, the hypothesis of a modification of the Airplane Mode state from this application should be considered.

Generally, if you want to perform a quick initial analysis of the Unified Logs specific to the modification of Airplane Mode, you can look into those presented in the table below. As you will notice, the process recording the log informs us about the method used to modify the Airplane Mode state.

Event	Action
SpringBoard: Setting airplane mode enabled: 1	Activating AirPlane mode from Control Center
Preferences: Setting airplane mode enabled: 1	Activating AirPlane mode from Settings
assistant_service: Setting airplane mode enabled: 1	Activating AirPlane mode with Siri

WiFi

WiFi, much like Bluetooth, which will be covered in a future article, allows only for deactivation, but not for complete shutdown. In other words, even if WiFi is deactivated, it may still be able to use certain connections like AirDrop, AirPlay, etc.

In general, the state of WiFi on your iOS device will be in one of the following 4 states:

WiFi State	Definition
Associated	The WiFi is active, and the phone is connected to a network.
Power ON	The WiFi is active, but the phone is not connected to any network.
User-disconnected	The WiFi is partially inactive. The phone cannot connect to a WiFi network, but certain services remain available.
Power OFF	WiFi is turned off. No WiFi connection is possible.

In the first instance, it may be interesting to know, quite generally, when the phone was connected to a WiFi network or not. For this purpose, you can begin by investigating the following two Unified Logs:

Event	Definition
SpringBoard: Wifi is associated? NO	The WiFi is not connected to any network.
SpringBoard: Wifi is associated? YES	The WiFi is active and connected to a network.

Each time the phone transitions from one state to another, a log (this is an abuse of language, as many logs will be recorded for each state change) will be registered. It is important to note that these state changes can occur manually or automatically. To illustrate this point, let's consider the example of losing connection to a WiFi network, which can happen when the user manually disconnects from a network or when they move too far away from it. I would like to reiterate that the Power OFF status cannot be obtained from the Control Center.

To disable these two types of connections, the user will have no choice but to go through the Settings application or ask Siri, for example. It will not be possible for them to do so from the Control Center.

Control Center

The actions possible from the Control Center, in my opinion, are rather limited, and it seems to me that the three described in the table below are the only ones possible:

Event	Definition
SpringBoard: Toggled WiFi state from power-off to power-on	From Power OFF to Power ON
SpringBoard:Toggled WiFi state from user-disconnected to power-on	From user-disconnected to power ON
SpringBoard:Toggled WiFi state from power-on to user-disconnected	From Power ON to user-disconnected

It is not possible (unless I am mistaken) to perform any other WiFi updates from the Control Center.

Settings

If it is not possible to fully disable WiFi from the Control Center, it is also not possible to set up WiFi in a user-disconnected (partially turned off) state in the Settings application.

Event	Definition
Preferences: <private>: old state Power Off new state Power On	From Power OFF to Power ON
Preferences: <private>: old state Power On new state Power Off	From Power ON to Power OFF
Preferences: <private>: old state UserDisconnected new state Power Off	From user-disconnected to power ON

As we can observe in the table above, the mention of "WiFi" does not appear in these logs as it is likely encapsulated within the "private" variable. Therefore, we can couple these different logs with those presented below to be more precise:

Event	Comment
sharingd: WiFi state changed: NotConnected -> Off	"Notconnected" is another way to say that the WiFi is active but not connected.
SysMon: WiFi state changed: Off -> NotConnected	Same comment as above

By simply combining a few Unified Logs, it is indeed perfectly possible to show how (which actions were taken) the state of WiFi was changed.

Siri

Siri does not have the ability to modify the state of a connection in the Control Center, which means it will be able to turn OFF or ON the WiFi but not to put it in a state like "User-deactivated," for example. Personally, I have also not succeeded in connecting or disconnecting from a WiFi network using Siri. In other words, I could not do anything other than activate or deactivate the WiFi as I could have done from the Settings application.

Every time I asked my voice assistant (Siri) to turn on or off the WiFi, the following log was recorded:

Event	Definition
assistant_service: Toggled Wifi State.	WiFi's state changed.,

Although the log above does not directly indicate which action was taken on the WiFi connection, investigating the logs recorded just afterward allows us to determine it. And this log still remains very interesting in my opinion!

The two logs below precisely show us how to determine which action was taken by Siri:

Event	Definition
sharingd: SysMon: WiFi state changed: Off -> NotConnected	From Power OFF to Power ON
sharing: WiFi state changed: NotConnected -> Off	From Power ON to Power OFF

The simple analysis of these few logs (Especially the first one), allows us to demonstrate that Siri had an impact on the state of the WiFi.

When the user powers on the WiFi, several events can occur. When we are at home, it is entirely normal for our phone to connect automatically to our home network, for example. In this case, the password for this network would have already been entered in the past. I will not revisit the logs of the WiFi connection state change here, as these Unified Logs have already been discussed previously.

Auto Join

When the phone connects to a network automatically, it utilizes the function called "Auto Join." This method of connection is very convenient because the user will not need to enter the password.

Timestamp	Event
2024-02-12 20:16:39	[WiFiPolicy] {AUTOJOIN, ASSOC*} Attempting auto join association of Pixel_4617
2024-02-12 20:16:39	__WiFiDeviceManagerKnownNetworkSuitabilityCheck: current network Pixel_4617 is a Priority Network
2024-02-12 20:16:39	rapportd: SysMon: WiFi state changed: NotConnected -> Connecting, 0x0 < > "Pixel_4617"
2024-02-12 20:16:39	wifid: [WiFiPolicy] {LINK+} __WiFiDeviceProcessLinkEvent: link up to Pixel_4617
2024-02-12 20:16:40	[WiFiPolicy] {AUTOJOIN, ASSOC*} Auto join association completed (0) with current state: Associating, network: Pixel_4617
2024-02-12 20:16:40	[WiFiPolicy] {AUTOJOIN, ASSOC*} Auto join association succeeded, network: Pixel_4617
2024-02-12 20:16:40	rapportd: SysMon: WiFi state changed: Connecting -> Connected, 0x8 < WPA > "Pixel_4617"
2024-02-12 20:16:40	networkserviceproxy: Wi-Fi network Pixel_4617 is active

These logs can be valuable in demonstrating that the investigated phone may have been present at the location of the action in the past. The first one in the table, as its name suggests, informs us about an attempt to auto-join. The second one mentions a "Priority Network," which is a special setting that you can configure for each WiFi network (you can refer to the following link for more information: https://support.apple.com/en-us/102169).

The following logs simply confirm that the phone was indeed able to connect to the WiFi network it was attempting to connect to automatically. It is also interesting to note that the name of the WiFi network the phone is attempting to connect to is mentioned several times in these logs "Pixel_4617".

Auto Join no activated

In the event that the Auto Join option is not active for any reason, the user may need to enter the password of the WiFi network to connect because it is not saved in the phone. However, this does not necessarily mean that the phone has never connected to this WiFi network before. Other hypotheses are also to be considered, for example:

• The password of the WiFi network has been changed.

• The user clicked on "Forget this network" at some point.
  

It is also possible that the password of the network is already known to the phone, but the "Auto join" option is not activated for this particular WiFi network. Therefore, if the logs specific to auto join are not present during the investigation of the phone, it seems essential to be able to determine accurately whether the password was still stored in the phone's memory (not the user's) or not.

Password not in Keychain

In the table above, the third and fourth logs clearly help us hypothesize that the password was not stored in memory. Indeed, they specifically mention "password is nil for Gucci-24Gzh" and "unable to find password in keychain." Investigating these two logs could be sufficient for us, but others are also presented in the table.

Timestamp	Process	Event
2024-02-12 20:42:36	Preferences / SpringBoard	-[WFNetworkProfile password]: fetching password from keychain for <private>
2024-02-12 20:42:36	Preferences / SpringBoard	WiFiNetworkCopyPassword: Copy password for Network <private>
2024-02-12 20:42:36	Preferences / SpringBoard	-[WFNetworkProfile password]: password is nil for Gucci-24Ghz
2024-02-12 20:42:36	Preferences / SpringBoard	unable to find password in keychain
2024-02-12 20:42:36	kbd	-[WBSSavedAccountStore _fetchAndFilterPasskeysData]: Loaded 0 passkey keychain records from personal keychain
2024-02-12 20:42:36	kbd	-[WBSSavedAccountStore _fetchAndFilterRecentlyDeletedPasskeysData]: Loaded 0 recently deleted passkey keychain records from personal keychain
2024-02-12 20:42:36	kbd	No sidecar items found in access group com.apple.password-manager

I would like to clarify the following two points. Firstly, the "Gucci" WiFi network is not mine; I would never give it such a name. Secondly, you may have wondered if the fourth log contained a typo since it mentions "nil" instead of "null," but it is indeed recorded this way by Apple.

Password not requested (password saved in KeyChain)

Timestamp	Process	Event
2024-02-19 20:23:15	Preferences / SpringBoard	-[WFNetworkProfile password]: fetching password from keychain for <private>
2024-02-19 20:23:15	Preferences / SpringBoard	WiFiNetworkCopyPassword: Copy password for Network <private>
2024-02-19 20:23:15	Preferences / SpringBoard	password provided to assoication parameters for <private>
2024-02-19 20:23:15	wifid	[corewifi] BEGIN REQ [ASSOC] (pid=1859 proc=Preferences service=com.apple.private.corewifi.internal-xpc intf=(null) uuid=6DFF0 info={     AssocParams = "scanResult=<redacted> - ssid=<redacted> (1141998574), bssid=<redacted>, security=wpa3-transition, rsn=[mcast=aes_ccm, bip=none, ucast={ aes_ccm }, auths={ psk sae }, mfp=capable, caps=0x8C], channel=5g112/80, cc=DE, phy=n/ac/ax, rssi=-67, bi=100, age=346ms, profile=<redacted> - ssid=<redacted> (1141998574), security=wpa3-transition, assoc=2024-02-19 19:26:43.673 +0100 (user), bssList=[(bssid=<redacted>, channel=5g112/80, assoc=2024-02-19 19:32:35.365 +0100), (bssid=<redacted>, channel=2g2/20, assoc=2024-02-19 19:02:52.357 +0100)], hasPassword=1, eap=(null), remember=1, forceBSSID=0, bandPref=0, colocatedScopeID=(null)has6GHzOnlyBSS=0"; })
2024-02-19 20:23:15	wifid	[corewifi] __associate Manual Association Requestion from user
2024-02-19 20:23:15	wifid	-[WiFiIDSSyncEngine knownNetworksListChanged]: role 1, isKeychainUnlocked 1

The first two Unified Logs are similar to those presented in the first case, so it will be important to pay attention to those that follow. The third one also contains a typo, but it is indeed recorded in this way. Although lengthy, the fourth log is very important as it states "BEGIN REQ." This log is recorded at the moment when the connection attempt is made (if the user entered the password, this log is recorded once the user clicks "Join") and contains several values that are interesting to study, such as "assoc=2024-02-19 19:26:43." The most attentive readers may have noticed the following two things:

1. The variable "assoc=" is mentioned several times in the log, which can be quite confusing.

2. Several dates and times are present in the log, but none record the latest connection. Indeed, the last connection is mentioned in the timestamp of the log, and those within the log are from previous connections to this network.
   

In any case, regardless of the method that had to be employed to connect to a WiFi network, once the connection is established and validated, several Unified Logs will allow you to highlight this:

#	Event
1	SpringBoard: [SBWiFiManager] updateCurrentNetwork: network change -> 'yallo5EC1E9'
2	SpringBoard: [SBWiFiManager] updateCurrentNetwork: current network has been set... currentNetwork: yallo_5EC1E9: isHidden=0, isEAP=0, isSAE=1, isWPA=1, isWEP=0, WAPI=0, type=0, enabled=true, saveData=2, responsiveness=(null) ((null)) isHome=Home, isForceFixed=0, transitionDisabledFlags=0, foundNanIe=0, isPH=0, isPublicAirPlayNetwork=0, hs20=0, previousNetwork: (null), isPrimaryInterface: 0
3	SpringBoard: [SBWiFiManager] signal strength bars changed to 2
4	SpringBoard: Wifi is associated? YES
5	SpringBoard: WiFi state changed from power-on to associated
6	SpringBoard: [SBWiFiManager] updateCurrentNetwork: network change -> 'yallo5EC1E9'
7	itunestored: ISNetworkObserver: Set network type "WiFi"

The logs presented in the table above will not always be recorded. This depends on the method of connection the user had to employ. We can take the penultimate log recorded by the SpringBoard process as an example. This log will not be recorded if the user connected to a network from the Settings application but will be in the case of "Auto Join" or a connection from the Control Center.

The second log provides a wealth of interesting information about the WiFi network the phone has just connected to. We can mention, for example, the security protocol "WPA, WEP, WAPI" or the variable "IsHome=Home". Regarding the latter, this WiFi network is indeed my home network, so I'm not surprised, but I couldn't explain how SpringBoard knows it (and I'm not sure I want to know...").

The third one is indeed very interesting, but it's important to note that it's not recorded only when the WiFi connection is established. It's recorded regularly when the strength of the WiFi network intensifies or deteriorates, for example. However, it can be useful to be able to determine if the person was in an area where the connection was good or not.

Personally, the last log in the table, recorded by the itunestored process, can be very interesting because it simply and easily indicates that the connection is now made via WiFi. We will see later that a similar log is recorded by this same process when the connection switches to 4G. In other words, and as you have probably understood... I love this log!

I really want to revisit log number 3 because an even more detailed log exists to determine the quality of the WiFi network the phone is connected to:

Process	Event
Preferences	-[WFNetworkListController _networkLinkQualityDidChangeNotification:]: linkQuality.scaledRssi 0.947368 bars 3

I won't lie, I find this log quite remarkable because it allows us to determine the WiFi quality very precisely (the closer the decimal number is to 1, the better the connection) while also informing us about the number of bars.

Although this log is very interesting and, in my opinion, crucial, it remains important not to overinterpret it! Indeed, even when staying still, it is perfectly normal to observe slight variations. However, walking around my apartment, I quickly realized that the quality could degrade rapidly (from 0.95 to 0.40, for example). Therefore, this log should not be taken as an exact science but rather as an indicator.

Based on my research, I have formulated the following hypotheses:

1. WiFi is at 3 bars when the Link Quality Scale is approximately over 0.68.

2. WiFi is at 1 bar when the Link Quality Scale is approximately under 0.32.

In the case where the connection switches from one network to another, the simplest log to analyze is this one:

Process	Event
configd	en0: SSID is now Pixel_4617 (was yallo_5EC1E9)

Ultimately, the loss of a connection can be due to various factors. The user may turn off their WiFi, activate airplane mode (from the Settings), the WiFi network may suddenly be disconnected, or the user could move too far away, for example.

These different actions will once again generate quite different logs:

Event	Action	WiFi state
wifid: [WiFiPolicy] {LINK-} Link went down: Pixel_4617 - isInVoluntary 0, reason Powered Off(5), subreason 8, rssi -19	Turning off WiFi from Settings / Activating AirPlane mode from Settings	Power OFF
wifid: [WiFiPolicy] {LINK-} Link went down: Pixel_4617 - isInVoluntary 1, reason Deauth(1), subreason 3, rssi -18	WiFi network disconnected	Power ON or Associated
wifid: [WiFiPolicy] {LINK-} Link went down: Pixel_4617 - isInVoluntary 0, reason Control Center/3rd Party Client(1011), subreason 0, rssi -17	Clicked on "Forget this network" / Deactivating from Control Center	Power ON or Associated in the 1st case. User-disconnected in the 2nd case.

This list is certainly not exhaustive, and other reasons explaining a disconnection could appear during your investigations. However, we can already notice the mention of "isInVoluntary" (0 = True and 1 = False).

When the user intentionally (or unintentionally) disconnects from a WiFi network, their phone may automatically reconnect to the 4G / 5G network provided by their mobile operator. In such cases, in addition to the logs of WiFi disconnection we have analyzed previously, we can add the following ones:

Process	Event
wifid	WiFiManagerPrivateMacUpdateProperty WFMacRandomisation : Updated property <LinkDownTimestamp> of network <Pixel_4617> with value <2024-02-14 17:55:54 +0000> to the list of private mac networks
wifid	Total connection time to Pixel_4617 36.072264
wifid	WiFiManagerReloadNetworksDisabledUntil: Adding Pixel_4617 disabled until 2024-02-15 04:00:00 +0000
SpringBoard	[SBWiFiManager] updateCurrentNetwork: current network has been set... currentNetwork: (null), previousNetwork: Pixel4617: isHidden=0, isEAP=0, isSAE=1, isWPA=1, isWEP=0, WAPI=0, type=0, enabled=true, saveData=0, responsiveness=(null) ((null)) isHome=Unknown, isForceFixed=0, transitionDisabledFlags=0, foundNanIe=0, isPH=0, isPublicAirPlayNetwork=0, hs20=0, _isPrimaryInterface: 1

Once again, not all of these logs will necessarily be recorded depending on the method used to disconnect from a network. However, if you notice a WiFi disconnection (as mentioned in the previous table, stating "Link went down...") during your investigation, it can be interesting to delve a little deeper into what information you may find..

In the event that the user wishes to click on "Forget This Network," they must first click on the "i" next to the WiFi name in the Settings application. This action results in the following log being recorded:

Process	Event
Preferences	'<private>' is forgettable

Ultimately, when the user completely turns off the WiFi, it is evident that the phone will no longer be able to connect to a WiFi network. In this case, the connection will revert to a 4G/5G connection, or internet may simply no longer be available on the phone.

Event	Comment
SpringBoard: dataNetwork changed to 4G	Data network switched to 4G
Itunestored: ISNetworkObserver: Set network type "4G"	Data network switched to 4G
SpringBoard: disabling dataNetwork	Data network unavailable and phone has not internet connexion.
itunestored: ISNetworkObserver: Set network type "(null)"	Data network unavailable and phone has not internet connexion.

In the first case (the first two logs above), the phone automatically switches to the 4G network when the WiFi is disconnected, whereas in the second case, internet is simply no longer available on the phone (network data not available).

In both cases, the SpringBoard process records a log regularly stating whether the data network is active or not (as if it were on standby):

Event	Comment
SpringBoard: dataNetwork is unchanged, still enabled	Mobile data is enabled on the phone
SpringBoard: DataNetwork is unchanged, still disabled	Mobile data is disabled

To conclude, I would like to share the log below with you, which can provide some information about the SIM cards inside the phone.

Process

Event

SpringBoard

[STTelephonyStateProvider Slot 1]: updated data connection type -- manager: <STTelephonyStateProvider: 0x282b378d0> {     dualSIMEnabled = YES;     slot1SubscriptionInfo = <STMutableTelephonySubscriptionInfo: 0x282b337b0> {         SIMStatus = kCTSIMSupportSIMStatusReady;         registrationStatus = registered;         cellularRegistrationStatus = registered;         dataConnectionType = noConnection;         signalStrengthBars = 1;         isPreferredForDataConnections = YES;         isProvidingDataConnection = YES;         operatorName = Swisscom;     };     slot2SubscriptionInfo = <STMutableTelephonySubscriptionInfo: 0x282b33840> {         SIMStatus = kCTSIMSupportSIMStatusNotInserted;         registrationStatus = registering;         cellularRegistrationStatus = notRegistered;         dataConnectionType = noConnection;         signalStrengthBars = 1;         isPreferredForDataConnections = NO;         isProvidingDataConnection = NO;         operatorName = 0x0;     }; }

Conclusion

As we have seen throughout this article, the Unified Logs related to WiFi are abundant but provide crucial details about the various actions taken by the user of the examined device. Whether through the Control Center, the Settings application, or even using voice commands, we observe that these different interaction methods generate distinct logs regarding WiFi as well as Airplane Mode.

The meticulous analysis of these logs reveals a wealth of information about user habits and preferences, as well as the history of interactions with the WiFi network and Airplane Mode settings. This data can be crucial in digital investigations, allowing investigators to accurately reconstruct past events and understand the context in which certain actions were performed.

Despite the large quantity of Unified Logs presented in this article, which may seem daunting at first, I can only encourage you to undertake their analysis gradually. Indeed, each log holds valuable information that, when interpreted correctly, can provide significant insights into the past usage of the device. Mastering the analysis of Unified Logs is an essential skill for digital investigators and security researchers, and it can lead to crucial discoveries in various investigative scenarios.

In essence, Unified Logs offer a transparent window into the past activities of the device, thus opening new avenues for digital investigation and data security protection.

Enjoy your Digital Investigations !

Lionel Notari