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.
Having recently written a few articles about the investigation of the iOS Unified Logs, I wanted to explore these logs on macOS for some time now. While my main "speciality" (if I can say it like this) remains the iOS logs, I thought that it might be interesting to compare the unified logs found on various Apple devices.
The first question I asked myself was: "What unified logs are recorded by my Mac when I click somewhere with my mouse?" Will the processes be different from those recorded by my phone, or do the logs look similar? Well, let's have a look!
The parameters of my test were as follows:
Mac Mini 2023 (M2) with Sonoma 14.6.1
Mouse Bluetooth Apple "Magic Mouse"
Finally, I want to clarify that the unified logs presented in this article are all recorded within a few milliseconds. Indeed, clicking on a window to bring it to the foreground generates a lot of logs in a very short period of time (less than a second). This is why the timestamps of the log entries were not included in the tables of this article, as I felt it wouldn’t provide useful information.
macOS Unified Logs - Mouse Click
After a few experiments, it appears that every left-cick generates the same sequence of those following three logs:
Category | Process | Event |
packages | WindowManager | 0[outside of RPC]: activation ordering click on window 7b9 time 286174478793708 |
general | WindowManager | Click activation from WindowServer. Setting frontWindowID=<private> frontWindowTimestamp=286174478793708 |
general | WindowManager | WindowManager Ordering <private> above relative to <private> from: windowServerClickActivation |
I also paid attention to the Activity Identifier of these unified logs, but unfortunately, it's not useful. I've never seen it show anything other than a '0'.
There are, however, several interesting things to note in these logs:
The three unified logs mention 'click' and 'activation' in their messages.
The first log contains the identifier of a window, '7b9' in my example. This is very important and we will come back to it later.
Finally, a timestamp is mentioned in the first two logs (Based on my tests, I believe this timestamp corresponds to the number of nanoseconds since the last boot of the device).
These are the first three macOS unified logs I analysed when a user performs a left click with their mouse ... and there's more! The logs provided below are generated by the 'WindowServer' process and can help us to determine not only when the user clicks the left mouse button but also when they released it. To avoid cluttering the table below, I didn't specify the category of these unified logs since it's always 'default,' nor the activity ID, as it is once again '0.'"
Left button click:
Process | Event | Action |
WindowServer | [Event] Process button state old:0 new:1 SenderID:0x100000ae8 t:6800131468952 | Press on left button |
WindowServer | [Event] GlobalButtons:1 (Last SenderID:0x100000ae8) | Press on left button |
WindowServer | [Event] context.globalButtons(0) != translator->globalButtons(1) t:6800131468952 | Press on left button |
The unified logs recorded by the "WindowServer" process also contain a timestamp (t:6800131468952) but these do not correspond to the timestamps of the "WindowManager" process that we saw previously. Therefore, I did more in-depth tests and these timestamps are close to the machTimestamp (some info on the different mach timestamp here). However, there is a small discrepancy between the two values. Here are two examples:
Example n° 1:
Example n°2:
In my opinion, this difference is explained by the fact that the "machTimestamp" value is the mach_continuous_time and that the value in the "eventMessage" of the unified log is the mach_absolute_time:
To try to confirm this hypothesis, I put my Mac Mini to sleep for several minutes and we can see that the difference between these two values has increased:
All of this remains just my own hypotheses and I can only recommend you to confirm them during your digital investigations.
When the button is released:
Process | Event | Action |
WindowServer | [Event] Process button state old:1 new:0 SenderID:0x100000ae8 t:6800134127884 | Released left button |
WindowServer | [Event] GlobalButtons:0 (Last SenderID:0x100000ae8) | Released left button |
WindowServer | [Event] context.globalButtons(1) != translator->globalButtons(0) t:6800134127884 | Released left button |
Of course, if the user keeps the button pressed for any reason (e.g., to select text), you might observe a gap of several seconds between these two sets of three logs, which is explainable! For example, in the case of a simple click to open an application, these six unified logs will follow one another in less than a second. The question is whether these logs are different when a right-click is performed with the mouse... and they are! This means we will know exactly which button the user clicked, which is a bit scary (but not surprising ...)!
Here are the unified logs recorded when the user right-clicks on his mouse:
Process | Event | Action |
WindowServer | [Event] Process button state old:0 new:2 SenderID:0x100000ae8 t:7262660533445 | Press on right button |
WindowServer | [Event] GlobalButtons:2 (Last SenderID:0x100000ae8) | Press on right button |
WindowServer | [Event] context.globalButtons(0) != translator->globalButtons(2) t:7262660533445 | Press on right button |
WindowServer | [Event] Process button state old:2 new:0 SenderID:0x100000ae8 t:7262663265925 | Released right button |
WindowServer | [Event] GlobalButtons:0 (Last SenderID:0x100000ae8) | Released right button |
WindowServer | [Event] context.globalButtons(2) != translator->globalButtons(0) t:7262663265925 | Released right button |
We can see that the logs are "similar" between a left click and a right click. However, the right click has a status of '2,' while the left has a status of '1,' making it easy to determine which mouse button the user clicked! Sounds great!
Mouse buttons have two states: either they are released (meaning they are not being pressed) and their state is 0, or they are pressed (the user performs a click) and their state is 1 for a left click and 2 for a right click. With all these unified logs, you'll already be able to show that a user has interacted with the computer.
macOS Unified Logs - Foreground Applications
I mentioned earlier the window identifier, the '3c.' This can be very interesting for providing more information about the window in which the click was made. I did a simple search for this identifier to find more details, and here’s what I found:
Category | Process | Event |
Window | ChatGPT | order window front conditionally: 3c related:0 |
Here is the first information about the application in which the user clicked (of course, in the context of my test, I know this is accurate).
Here are other examples with different applications:
Category | Process | Event |
Window | Spotify | order window front conditionally: 34 related:0 |
Window | Console | order window front conditionally: 5f5 related:0 |
Window | order window front conditionally: 8C7 related:0 | |
Window | Microsoft Excel | order window front conditionally: 8ed related:0 |
Window | order window front conditionally: 7b9 related:0 |
Since relying on a single unified log can be risky, it can also be useful to check which application was in "foreground" when the click was made to confirm this first observation.
The unified logs recorded by Apple devices are increasingly cautious about data protection, so many logs containing the terms 'foreground' or 'foremost' do not show the application's name but <private> instead. Making our work more complicated. Here are a few examples:
Category | Process | Event |
SkyBridge | WindowServer | Process now frontmost: <private> |
Bluetoothd | SystemSettings Foreground App now changed : <private> | |
Bluetoothd | Foreground App is now <private> | |
Bluetoothd | notify Foreground app changed :<private> |
These logs indicate a change in the application being in the 'foreground,' but we need to investigate further to identify which one it is. The first two logs that provided me with a bit more information are as follows:
Category | Process | Event |
front | launchservicesd | SETFRONT: pid=611 asn=0x-0x10010 foreground=1 oldFrontPid=59549 oldFrontASN=0x-0x4142067 |
general | WindowManager | Setting frontProcessIdentifier=611 frontProcessTimestamp=288032282868333 |
Once again, these logs do not directly mention the application brought to the foreground but provide a PID number (611 in this case) and a timestamp, which can be helpful. The first log, explicitly mentioning 'SETFRONT' with the new PID in the foreground 'pid=611' and the old 'oldFrontPid=59549,' seemed very interesting.
Continuing my analysis, I was able to identify the next two logs, recorded a few milliseconds after the two presented above:
Category | Process | Event |
cas | launchservicesd | Moving App:"ChatGPT" asn:0x0-10010 pid:611 refs=8 @ 0x14060a440 to front of visible list. |
cas | WindowManager | Making App:"ChatGPT" asn:0x0-10010 pid:611 refs=8 @ 0x14060a440 into menu bar owning process, oldOwner=App:"Console" asn:0x0-3f33f3 pid:59549 refs=6 @ 0x1415b0f30 |
These two logs allow us to identify which application was brought to the foreground by the user (finally!). In this example, it was ChatGPT (pid=611). The second log also reveals the application that was previously in the foreground, 'Console,' with PID 59549 (pid:59459 in the log table).
Finally, I want to discuss a few other unified logs that can help confirm these hypotheses:
Category | Process | Event |
connection | ChatGPT | Gained inheritances: {( <RBSInheritance| environment:(none) name:com.apple.frontboard.visibility origID:159-154-137663> )} |
connection | Console | Lost inheritances: {( <RBSInheritance| environment:(none) name:com.apple.frontboard.visibility origID:159-154-137724 0> )} |
I also find these logs interesting because they are directly recorded by the processes of the concerned applications, unlike the others. The first one, recorded here by the 'ChatGPT' process, confirms that the application has been brought to the foreground with 'Gained [...] frontboard.visibility,' while the 'Console' process records the opposite with 'Lost [...] frontboard.visibility.'
All the presented logs point in the same direction: the Console, which was previously the foreground application, has been replaced by "ChatGPT".
macOS Unified Logs - Process ID
We have seen in the previous logs that it would be useful to have unified logs that help to know which process corresponds to each PID, making it easier to identify the application referenced by a log mentioning a PID number (e.g pid=611)
Returning to these examples, here are two logs that could help us determine this:
Category | Process | Event |
assertion | ChatGPT | Acquiring assertion: <RBSAssertionDescriptor| "AppNap adapter assertion" ID:(null) target:611> |
dnssd_server | mDNSResponder | [R63901] getaddrinfo stop -- hostname: <mask.hash: 'LcJP/9pBfSe0EQgGsKVL+Q=='>, client pid: 611 (ChatGPT) |
The two logs above can also help us link the PID number to the corresponding application. However, this method is far from convincing... and there's a much better way to do it!
To get this information, we need to display it in the Console! Yes, it's that simple. Since it's not shown by default, right-click on the displayed columns at the top and select 'PID' -> this will show the PID number for each process! Very handy and much more convincing.
Conclusion
As we saw in previous articles on iOS, unified logs keep a vast amount of information that are interesting to investigate. The unified logs from Apple computers follow the same pattern, as every mouse click is documented. We can even determine which button the user pressed (left or right, for example), in which window of their computer, and for how long... In short, these unified logs allow for complete activity reconstruction!
Enjoy your Digital Investigations !
Lionel Notari
Comentários