Getting Stepped on by Runningboards
Getting Stepped on by runningboards
With the release of Big Sur back in November, I was relieved to see that my TrueTree tool was still running with no crashes on both the Intel and the new Apple M1 chip. Previous visitors to this site are probably aware of my obsession with creating process tree’s on macOS that are as useful as possible. In the past, I’ve written about how this can be accomplished.
After taking the time to investigate TrueTree’s output on Big Sur, I noticed a new process that is now responsible for creating a large amount of children. This new process is titled runningboardd.
In a quest to quickly identify what this new processes was, I of course Googled the name. It’s undocumented and very little detail is actually known about it. However, I did stumble upon two informative blog posts from researcher Howard Oakley where he reveals some of his findings (Check them out here and here). I won’t bother repeating all the details as you can go there and read them yourself, but overall he found that runningboardd is in some way responsible for monitoring and managing some applications over the course of their life and even assisting sometimes when those applications crash or close.
The issue here for incident response analysts is that prior to Big Sur, TrueTree told us how all applications were opened whether it be from Finder, Spotlight, open command, or any other method. Now, no matter what application is opened by the user, the submitted by pid that TrueTree uses to build its output always reflects a new service called runningboardd.
The screenshot above shows the applications that I’ve opened using all different kinds of methods. It shows us that each application has a “true” parent of runningboardd which can be confirmed by looking at the output of launchctl procinfo. For example, take a quick peak at the procinfo output of my “App Store” Application.
Above in the procinfo we can see that the system tells us the ppid is pid 1 (launchd).
In the screenshot above, as mentioned, runningboardd is now reflected as the “submitted by pid”. This is one of the primary pids used by TrueTree that would tell us which application (Finder, Dock, Spotlight, etc) was used to open an application (The App Store Application in my case).
Seeing that the parent is runningboardd tells us this process was invoked by the user somehow, but we no longer get the context of how it was opened. So what the heck do we do now?
The option I am currently exploring is to look at the mach ports for the processes that reflect runningboardd as their submitted by application. If you’re not familiar with mach ports, I’m hoping to write something up in the future to break them down in a bearable language. For now, just understand that they are at the core of inter-process communication on macOS and relied upon very heavily to keep the system working (and also the entire reason macOS creates confusing process trees to begin with). A processes mach ports snapshot can be viewed using “sudo lsmp -p <pid>”
Let’s take a quick look at the mach ports for my running “App Store” application.
In the above screenshot we see signs that my current App Store application has communicated with the macOS Dock bar. Let’s take a look at what happens if I close the App Store application and then re-open it using Spotlight (cmd+space). Again, we’ll check the mach ports.
I’ve checked various applications and it appears to consistently reflect a “true” parent process.
Note that this mach port trick is not new with Big Sur. Linking these applications to each other using mach ports can be done prior to the latest macOS. It was just much simpler to do it by using the submitted by pid. Now that’s out the window and we’ll have to explore this option further. Writing a tool that pulls back the same info as the lsmp command won’t be an option due to the fact that viewing mach ports of running processes now requires a special entitlement (which Apple gives to the lsmp executable). So now I just have to ask myself if it’s really worth parsing the lsmp output for this data…
