Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5313. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds 4 new rules for components of MACOS.MISOMESA and 7 for MACOS.MISOMAGIC, both new codenames in the Yara file, it also adds a new rule for MACOS.SOMA.AUENC, another Soma/Amos component, and amends the existing detection rule for MACOS.DUBROBBER.CHBI.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5313
Sequoia and Tahoe systems only
This update has now been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5313 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
on run {input}
set theURL to input
tell application "Google Chrome"
if not (exists first window) then make new window
set URL of last tab of first window to theURL
activate
end tell
end run
There are many more powerful PDF and image editors, yet plenty of us use Preview for those basic little tasks, where we don’t need the complications of a heavyweight. Preview isn’t without its faults, though. It can mutilate PDF annotations made by other apps, and sometimes unexpected things happen. To deal with those it has one feature that’s almost unique among PDF and image editors: it automatically saves versions using the macOS versioning system. This article explains how to make use of that.
Ask to save changes when closing documents
One important control over the behaviour of Preview and many other apps that you may not be aware of is this in the Windows section of Desktop & Dock settings. When combined with apps that use the macOS versioning system its effects are significant.
Ignoring versioning for the moment, when this setting is turned on, if you go to close an open document that has unsaved changes, before it’s closed you’ll be asked whether you want to save that changed document. This is a long-standing safety net that continues to protect us from losing lots of work by accident.
When this setting is turned off, apps may still ask you whether you want to save unsaved changes before closing a document unless the app uses the macOS versioning system. In that case, the app automatically saves a new version without offering any option. This might appear inappropriate, but as that’s non-destructive, it avoids interrupting your workflow: you can always revert to the previous version of that document, provided that you’re aware that it has been saved automatically.
If you’re not aware of what’s going on here, and how the versioning system works, this can cause odd effects you can demonstrate using Preview.
Preview’s saving grace
To see how Preview handles versions and the effect of that setting, find a copy of a suitable PDF or image file and duplicate it in the Finder. Name one copy something like testSavesOff, and the other testSavesOn. Set Ask to save changes when closing documentsoff to begin with, and open testSavesOff in Preview.
Now perform some destructive editing on that document without saving it, here a radical crop.
Leave it a couple of minutes before closing the document. Following that setting, Preview shouldn’t ask you whether to save the changed document, but will simply close it. Then quit Preview.
Now set Ask to save changes when closing documentson, and repeat the same sequence with testSavesOn instead. When you try to close that document, Preview should now ask you whether you want to save the changed document, to which you should click on Revert Changes to set the document back to its previous state instead.
Inspect the two documents using Quick Look and you’ll see that testSavesOn hasn’t changed, but testSavesOff has, although in neither case did you save those changes yourself.
All in the versions
Although you can see what has happened using Preview’s Revert To menu command, the clearest way to see what has happened to those two documents is to open them using my free Revisionist, which shows their saved versions.
testSavesOn has three saved versions. The current one is the same as the original, but the second version shows the destructive edit that you didn’t save.
testSavesOff has two saved versions, the original, and the current version is that after the destructive edit, which you also didn’t save.
Thanks to Preview’s use of the macOS versioning system, either way you’ve still got access to both versions of that document.
One point to note, though, is that the versioning system doesn’t automatically clean up old versions for you. When you’ve finished editing a document in Preview and don’t want to retain its old versions, delete them either using Revert To in Preview, or with Revisionist. Versions are only retained for the original document as long as it’s stored on the same volume. So you can also wipe old versions by duplicating a document and trashing the original, or copying it to another volume. Once they’re gone, you can’t restore them, as not even Time Machine can back up versions.
Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5312. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds three new detection rules: MACOS.SOMA.AUENB augmenting rules for the Soma/Amos family, MACOS.DUBROBBER.CHBI for another Dubrobber variant, and MACOS.ODYSSEY.LELI for an additional Odyssey variant.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5312
Sequoia and Tahoe systems only
This update has now been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5312 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
In the last few months I have had reports from several whose Macs have experienced a “SEP Panic” rather than a regular kernel panic. Although the immediate effects are the same, and my previous advice on how to deal with a kernel panic still applies, this article looks in more detail at what should be exceedingly rare events.
Essentials
If your Mac restarts or shuts down spontaneously, or ‘freezes’ for you to force it to shut down, chances are that was a kernel panic. When it starts up again, look out for the dialog inviting you to send a report to Apple. Expand that so you can see the panic log, copy and paste that into a text document, and save it. That’s the only record you have of that report, and that provides valuable clues as to what went wrong and how you might go about fixing it.
Apple will not contact you in response to sending the panic log. If you want advice or assistance about your Mac, contact Apple Support, and ensure you have your copy of the panic log ready, as they’ll need to see it.
Secure enclave
No matter how secure you try to make an operating system, if its most precious secrets are being processed by the main CPU cores, an attacker will find a way to access them. The proven solution to this is to build in a separate part of the chip with its own processor, and isolate that from everything else – a secure enclave, with its own secure enclave processor, SEP, as patented by Apple 13 years ago.
Two Mac architectures have secure enclaves and SEPs: Intel Macs with T2 (and T1) chips, where the SEP is in the T2/T1, and Apple silicon Macs, where the SEP is an integral part of the chip. These handle several different security features, including biometrics in Touch ID, management of secure encryption keys including those for FileVault, and performing encryption and decryption for the internal SSD.
The SEP runs its own operating system, sepOS, thought to be a derivative of L4, and communicates with the rest of the chip using mailboxes. When the CPU needs something from the SEP, it posts a message in the SEP mailbox, then retrieves the response when the SEP has processed that request.
What could possibly go wrong?
Like all processors, the SEP can hit problems that it can only manage by a reset, and those will result in it panicking, which in turn provokes the kernel running on the CPU to panic. Those problems can result from anything from a hardware fault to a bug in sepOS.
The SEP in a T2 chip is also known to be vulnerable to some exploits including blackbird, which can be used to ‘jailbreak’ a device using checkra1n or with malicious intent.
Reading the SEP panic log
When a kernel panic is the result of a SEP panic, the panic log is different from normal, and contains considerable detail about the SEP and what went wrong with it. As usual, though, much of that information is cryptic to say the least.
The first line in the panic log confirms that the panic originated in the SEP panic(cpu 1 caller 0xfffffe001f55e344): SEP Panic: […]
You’re then given the version of sepOS Root task vers: AppleSEPOS-2772.140.4
Unfortunately, further down it disclaims knowledge of that Firmware type: UNKNOWN SEPOS
The status of the SEP’s mailboxes are given Mailbox status:
IDLE_STATUS: 0x00000008
INBOX0_CTRL: 0x00105601
OUTBOX0_CTRL: 0x00023301
and Mailbox entries:
Unavailable
Mailbox queue pointers: […]
This is confirmed as a panic Debugger message: panic
The version of macOS is given by build number, with details of the kernel running on the CPU OS version: 24G90
Kernel version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:29 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6000
For a T2 chip, the kernel version given should be for a T8010 root:xnu-11417.140.69~1/RELEASE_ARM64_T8010
Apple silicon Macs should then confirm their iBoot versions, first the LLB (Stage 1) then iBoot Stage 2, and whether Secure Boot was used iBoot version: iBoot-11881.140.96
iBoot Stage 2 version: iBoot-11881.140.96
secure boot?: YES
T2 SEPs don’t normally give an iBoot Stage 2 version, but provide information about the Intel (x86) host iBoot Stage 2 version:
secure boot?: YES
roots installed: 0
x86 EFI Boot State: 0xe
x86 System State: 0x0
x86 Power State: 0x0
x86 Shutdown Cause: 0x5
x86 Previous Power Transitions: 0x20002000200
PCIeUp link state: 0x94721611
Information is provided about the task running on the CPU, which should normally be the kernel Panicked task 0xfffffe1fb0037248: 0 pages, 654 threads: pid 0: kernel_task
Towards the end of the panic log are details about kernel extensions. In SEP panics, that includes the SEP Manager Kernel Extensions in backtrace:
com.apple.driver.AppleSEPManager(1.0.1)[UUID]@0xfffffe001f5366e0->0xfffffe001f566a63
and last started kext at 242997189818: com.apple.iokit.SCSITaskUserClient 500.120.2 (addr 0xfffffe001ce0f6a0, size 2206)
loaded kexts:
In the list of loaded kernel extensions that follows, ensure there are no third-party entries, unless your Mac is expected to load them.
Actions
Although you should take a SEP panic seriously, there’s no need to panic yourself. This doesn’t mean that your Mac’s SEP has died, has been attacked by malware, or has released all the secrets it protects. A single panic in isolation could well just be chance, and not indicative of anything serious.
Provided that your Mac starts up correctly and then runs normally, your only essential task is to ensure that you capture and keep a copy of the panic log. If you wish, you can run hardware Diagnostics, but I doubt whether that performs any specific test intended to detect problems in the SEP. If you have potentially problematic peripherals, or any third-party kernel extensions, then you should take the hint and try to eliminate them.
If your Mac suffers any further kernel panics, capture their panic logs, and contact Apple Support with those to hand. Alternatively, book your Mac into an Apple store or authorised service provider for them to check it out for you.
Summary
SEP panics are exceedingly rare, but are readily identified from the first line of the panic log.
Ensure you copy and save a copy of the panic log.
Much of the panic log will appear meaningless, but there is some information about version numbers and kernel extensions that may be helpful.
Follow the normal recommendations, considering hardware diagnostics, and updating/removing potentially troublesome peripherals and third-party kernel extensions.
If there are any further panics, capture those and obtain support from Apple.
I hope that you enjoyed Saturday’s Mac Riddles, episode 322. Here are my solutions to them.
1: It’s about evolution, and open source for 25 years.
Click for a solution
Darwin
It’s about evolution (when Steve Jobs announced Darwin as open source in 1999, he said this to link it with Charles Darwin), and open source for 25 years (first released as open source in 2000, and still being posted on GitHub). (Darwin consists of the open source components in macOS, and includes its kernel.)
2: If the kernel isn’t Unix, this is it.
Click for a solution
XNU
If the kernel isn’t Unix, this is it (XNU is the open source kernel within Darwin, and is available as part of the GitHub distribution. Its name is an abbreviation for X isn’t Unix).
3: Mud puddles in Pittsburgh misheard as the basis for 2.
Click for a solution
Mach
Mud puddles in Pittsburgh misheard (it was originally intended to be called Muck in honour of these, but was misheard and incorrectly written down as Mach) as the basis for 2 (the Mach microkernel, developed by Richard Rashid and Avie Tevanian, formed the basis of XNU. Tevanian went on to work at Apple, then NeXT, where he designed NeXTSTEP).
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5311. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds eight new detection rules, for MACOS.BANSHEE.MA, MACOS.BANSHEE.MA2, MACOS.SOMA.GEGO, MACOS.POSEIDON.B, MACOS.TIMELYTURTLE.FUNA, MACOS.TIMELYTURTLE, MACOS.TIMELYTURTLE.INDRBYSE and MACOS.TIMELYTURTLE.INDR. Banshee, Poseidon and TimelyTurtle are new names in XProtect’s Yara rules.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5311
Sequoia and Tahoe systems only
This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5311 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
I hope that you enjoyed Saturday’s Mac Riddles, episode 321. Here are my solutions to them.
1: Where to sell an image of the Knolls in a two-year exclusive.
Click for a solution
Photoshop
Where to sell (a shop) an image (a photo) of the Knolls (originally developed by brothers Thomas and John Knoll, and licensed by Adobe) in a two-year exclusive (from February 1990 until its release on Windows in November 1992, it was exclusive to Mac).
2: Rembrandt, Claude Monet, JMW Turner and Corel.
Click for a solution
Painter
Rembrandt, Claude Monet, JMW Turner (all three were painters) and Corel (originally released in 1991 by Fractal Design, Painter was eventually bought by Corel).
3: One of the first two, it could be beige acrylic and written by Bill.
Click for a solution
MacPaint
One of the first two (together with MacWrite, it was one of the two apps bundled with the 128K Mac), it could be beige acrylic (paint the same colour as the 128K Mac) and written by Bill (Atkinson, 1951-2025, who wrote the app).
The common factor
Click for a solution
They have all been major raster graphics editors on the Mac.
XProtect is the front-line tool in macOS for detecting known malware. When a downloaded app is run for the first time and put through Gatekeeper checks, those rely on detection rules defined in the XProtect.yara file inside the XProtect bundle in /System/Library/CoreServices. Those are updated periodically to extend their coverage as new malware is detected and analysed by Apple’s security engineers. This article looks at how they have changed over the last six years.
My starting point is XProtect version 2103 released on 2 May 2019, in the heyday of macOS 10.14.4 Mojave. That contains a total of 92 rules in a text file of 42,903 bytes, for an average rule size of 456 bytes. Among those are many old chestnuts such as Bundlore.
My end point is version 5310 released this week, on 12 August 2025, for macOS 15.6 Sequoia and earlier. That contains a total of 372 rules in a text file of 969,662 bytes, giving an average rule size of 2,572 bytes. Still among those are the same old chestnuts including Bundlore.
Thus the number of rules is now 4 times what it was six years ago, and they take over 22 times as much space.
For the period up to the end of 2023, I have analysed XProtect’s Yara file in updates every 6 months, in May and November, or the closest update available. From the start of 2024 updates became more frequent, and I have therefore analysed the last update in each month. In late 2024, XProtect in macOS Sequoia started using iCloud to deliver its XProtect data updates. For this analysis I have excluded version 5273, which was only released via iCloud and wasn’t provided through the regular softwareupdate route used by all previous versions.
The number of Yara rules increased steadily until updates became more frequent in 2024, following which there was a very steep rise early that year. Since then they have continued to rise more steeply than before 2024, but now appear more linear, as seen in the red line of regression. Over this period, hardly any Yara rules have been removed.
Total size of the Yara file has followed a similar pattern, with little change until the start of 2024. It then peaked briefly before reducing slightly, pausing a little, then undergoing a step increase from 288 KB to 877 KB. Growth has been steadier for the last year, although it appears to be on track to reach 1 MB in 2026.
Average size of Yara rules changed little between 2021-2023, but increased greatly with the addition of some very large rules in June-July 2024. It has since declined slowly, as more recent rules have been far smaller.
This prodigious growth in the number of Yara rules and their size has inevitably had its effect on the time taken to complete Gatekeeper checks that include XProtect scans. macOS Tahoe has been promised to limit that, by not scanning notarized apps with XProtect, so improving app launch times.
Given that remarkably few old Yara rules have been removed over the last six years, this growth has been inevitable. However, unless old malware is incapable of being run on Macs still supported by XProtect updates, it’s hard to see how it could be safe to remove old rules. When support for running x86 code (except that for “older unmaintained gaming titles”) is dropped from macOS 28, many older Yara rules could be dropped from XProtect updates without putting Apple silicon Macs at risk, but even that isn’t an easy decision. In the meantime, at least our faster Macs should be able to complete XProtect scans more quickly.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5310. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds a single new detection rule for MACOS.SOMA.AUENA, further extending its coverage of Soma/Amos.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5310
Sequoia systems only
This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5310 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5309, and to XProtect Remediator for all macOS from Catalina onwards, to version 153. As usual, Apple doesn’t release information about what security issues these updates might add or change.
Yara definitions in this version of XProtect add a single new detection rule for MACOS.SOMA.JUENB, part of the Soma/Amos family.
XProtect Remediator doesn’t change the list of scanner modules.
There are extensive changes to the Bastion rules, which add a new definition for common system binaries, extend Rule 1 coverage to include support folders for more browsers, tweak Rules 3 and 14-17, and add new Rules 18-24.
You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-153 and XProtectPlistConfigData_10_15-5309.
Sequoia and Tahoe systems only
The XProtect update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5304 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
I hope that you enjoyed Saturday’s Mac Riddles, episode 319. Here are my solutions to them.
1: Successor to 3 inside a scheme was part of a popular atelier.
Click for a solution
InDesign
Successor to 3 (Adobe developed it to replace the ailing PageMaker) inside (in) a scheme (a design) was part of a popular atelier (for many years it was one of the leading apps in Adobe’s Creative Studio).
2: High speed subatomic particle took the lead in the 1990s.
Click for a solution
QuarkXPress
High speed (express) subatomic particle (a quark) took the lead in the 1990s (by the mid-1990s it had taken around 90% of the desktop publishing market on Macs).
3: Creator of a squire’s assistant was the first, but died before Mac OS X.
Click for a solution
PageMaker
Creator (maker) of a squire’s assistant (a page) was the first (released in July 1985 for the Mac), but died before Mac OS X (by 2000, it was moribund as Adobe was replacing it with InDesign, released in 1999, and it was never ported to Mac OS X).
The common factor
Click for a solution
They have all been leading desktop publishing apps for Macs.
This week’s dive into RunningBoard tackles one of the central questions: this subsystem repeatedly uses the term assertion, but what are these assertions, and how does RunningBoard handle them?
In computing, assertions may have their origin in hardware verification languages like Verilog, where they’re used to state required conditions in declarative form. They appear to have entered macOS through the background service assertiond, which made a name for itself as a killer of processes and apps. Power assertions have been noted in the log and elsewhere for at least the last decade, and are mentioned in IOPMLib, part of IOKit. Since macOS Catalina, assertions have been at the centre of RunningBoard, which remains essentially undocumented.
Developer app
To get a better idea of how assertions are used, I launched Apple’s Developer app on a Mac mini M4 Pro running macOS 15.5, and followed log entries for a period of over 14 seconds from the start of the launch process. Although RunningBoard’s job description records this app’s platform as 6, typical of a Catalyst app, in other log entries it’s claimed not to be a Catalyst app.
At an arbitrary start time of 01.126 seconds, LaunchServices decided to launch this app initially through CoreServicesUIAgent, which 0.04 seconds later requested RunningBoard to execute the launch request. This eventually led to a connection being initialised to FrontBoard Scene Manager, where the app was registered as a new scene, and activated.
Example assertion
FrontBoard set the process visibility to Foreground: 01.593239 com.apple.FrontBoard [app<application.developer.apple.wwdc-Release.9312198.9312203~>:2946] Setting process visibility to: Foreground
RunningBoard then announced it was acquiring a new assertion, giving its descriptor and the PID of the target process 01.593248 com.apple.runningboard Acquiring assertion: <RBSAssertionDescriptor| "com.apple.frontboard.after-life.subordinate" ID:(null) target:2946>
01.593288 com.apple.runningboard PERF: Received request from [osservice<com.apple.uikitsystemapp(501)>:748] (euid 501, auid 501) (persona (null)): acquireAssertionWithDescriptor:error:
01.593289 runningboardd acquireAssertionWithDescriptor
A fuller description followed, including the RunningBoard ID, and the attributes of the assertion 01.593324 com.apple.runningboard Acquiring assertion targeting [app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946] from originator [osservice<com.apple.uikitsystemapp(501)>:748] with description <RBSAssertionDescriptor| "com.apple.frontboard.after-life.subordinate" ID:424-748-2228 target:2946 attributes:[
<RBSDomainAttribute| domain:"com.apple.frontboard" name:"AfterLife-Subordinate" sourceEnvironment:"(null)">
]>
This assertion was made active, and RunningBoard stated how many assertions were currently targeting that process 01.593343 com.apple.runningboard Assertion 424-748-2228 (target:[app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946]) will be created as active
01.593389 com.apple.runningboard app<application.developer.apple.wwdc-Release.9312198.9312203(501)> is now targeted by 11 assertions
That triggered a state update for the process 01.593400 runningboardd state update
In this case, RunningBoard couldn’t do anything, so left the process’s assertions as they were 01.593461 com.apple.runningboard _checkForSuspendableAssertionCycle for app<application.developer.apple.wwdc-Release.9312198.9312203(501)> bailing out since it's not holding a suspendable assertion
01.593466 com.apple.runningboard Removing 0 assertions
This did, though, alter the inheritance of existing assertions 01.593556 com.apple.runningboard Process: [app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946] has changes in inheritances: {(
<RBSInheritance| environment:(none) name:com.apple.launchservices.userfacing origID:424-391-2215 0>,
<RBSInheritance| environment:(none) name:com.apple.launchservices.userfacing origID:424-391-2215 0>,
<RBSInheritance| environment:(none) name:com.apple.launchservices.userfacing origID:424-391-2214 0>,
<RBSInheritance| environment:(none) name:com.apple.frontboard.visibility origID:424-420-2216 0>
)}
This completed the acquisition of this assertion, and the process’s new state was calculated 01.593564 com.apple.runningboard Finished acquiring assertion 424-748-2228 (target:[app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946])
01.593741 com.apple.runningboard Calculated state for app<application.developer.apple.wwdc-Release.9312198.9312203(501)>: running-active (role: UserInteractiveFocal) (endowments: <private>)
This was all accomplished in around 0.0005 seconds. FrontBoard then continued processing the app’s scene 01.593743 com.apple.FrontBoard Ingesting properties from UIApplicationSceneSettings...
RunningBoard assertion numbers are of the form 424-748-2228, where the second group 748 is the PID of the source of the assertion, and the third group 2228 is a sequential number.
Assertions recorded
Assertion 424-620-2211 for LaunchServices to launch the app. For this, RunningBoard created its job description with its process ID of 2946, assigned it memory limits, stated the process will be managed, and stated it was running-active with a role of UserInteractive.
Assertion 424-424-2212 RunningBoard Underlying Assertion. RunningBoard stated the process will be created as active, calculated its processStartTime, created a new RunningBoard Coalition with an ID of 4460, set its Jetsam priority to 0 (the lowest priority over memory use), and set its Darwin GPU to “deny”. Its state was given as running-interactive-NotVisible with a taskState of 4.
Assertion 424-391-2213 foregroundApp 2946. This changed its role to UserInteractiveNonFocal, and was repeated in assertion 424-391-2214.
Assertion 424-391-2215 frontmost 2946. RunningBoard changed it to running-active-NotVisible, with a Jetsam priority of 100 (extremely unlikely to be killed to free memory), and Darwin GPU to “allow”.
Assertion 424-391-2217 LaunchServices notification. It was changed to running-active with a role of UserInteractiveFocal, handshaking took place with the process, and the launch request was recorded. Slightly later, RunningBoard announced it had started “death monitoring” of the process, in case its launch request was denied and the process was killed.
Assertion 424-748-2218 FrontBoard Bootstrap Background. Following this, the process acquired its first power assertion ID 34241, outside of RunningBoard.
Assertion 424-655-2220 File Coordination Claim, the first of a series of five similar assertions. For each, RunningBoard recorded Prevent Task Suspend, Prevent Task Throttle Down. After the last it checked for a Suspendable Assertion Cycle, then removed several assertions held for the process.
Assertion 424-2946-2227 App Nap adapter assertion. RunningBoard then enabled and configured AppNap for the process, and set the AppNap state.
Assertion 424-748-2228 FrontBoard AfterLife-Subordinate. This is the assertion detailed above.
Assertion 424-748-2229 FrontBoard Visibility Workspace Foreground Focal. With this, RunningBoard set the process to running-active-Visible with taskState 4.
Assertion 424-420-2230 App Drawing. Following that, storekitagent was running as PID 2947, accompanying the Developer app.
Assertion 424-2946-2232 CFNetwork StorageDB.
Assertion 424-2946-2233 System Animation Fence.
Assertion 424-420-2234 App Visible. Following that, uikitsystemapp was drawing, presumably for the Developer app.
Assertion 424-420-2236 FuseBoard Process Window State Visible.
Assertion 424-2946-2238 system animation fence, which was repeated a total of five times.
Assertion 424-2946-2244 Shared Background Assertion 1, following which were two more assertions for system animation fence.
Assertion 424-655-2248 File coordination claim, repeated in Assertion 424-655-2250.
All these assertions were completed in 14 seconds.
Reading RunningBoard
As shown in the series of assertions recorded in the log for the Developer app, RunningBoard provides a detailed account of milestones through the launch and early running of this app, covering much other than its security and TCC activity.
This starts with a job description containing a great deal of useful information about the app, when it’s neither visible nor focal. At that stage it’s given a minimal Jetsam priority, putting it in the front line to be forcibly quit if memory was short, and it’s denied access to the GPU. As launch proceeds, its Jetsam priority is raised to 100 and it’s allowed GPU access. Its role is then changed to UserInteractiveFocal, its window management is handled by FrontBoard and it becomes visible, and able to undergo AppNap. Two supporting services are engaged, storekitagent to handle its data, and uikitsystemapp to draw its interface.
Once the novelty of RunningBoard had worn off, I had come to consider its incessant chatter in the log as a distraction. However, a log extract obtained with the subsystem set to com.apple.runningboard provides a detailed account of events during an app’s life cycle, without the nuisance of privacy censorship, or the app having to make its own log entries.
Key points for close reading of the log
Set a predicate for obtaining log entries for the com.apple.runningboard subsystem, and initially filter entries on Acquiring assertion in the Messages field.
Identify the Process ID of interest.
Track assertion descriptions, giving the reason for each assertion.
Note assertion IDs, and interpret them with the aid of the PID given in their second number field.
Follow assertions for linked processes through their PIDs.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5305. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds a single new rule for MACOS.SOMA.JLEN, part of the Amos/Soma family of malware.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5305
Sequoia systems only
This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5305 but your Mac still reports an older version is installed, you may be able to force the update using sudo xprotect update
I hope that you enjoyed Saturday’s Mac Riddles, episode 316. Here are my solutions to them.
1: From PageRank and 10^100 to a set of letters.
Click for a solution
Google
From PageRank (Google Search was founded on the patented PageRank algorithm for ranking search results) and 10^100 (its name is derived from the very large number googol, 10 to the power of 100) to a set of letters (in 2015 it restructured under the ownership of Alphabet Inc.).
2: A hooligan went from directory to search then declined into finance and news.
Click for a solution
Yahoo!
A hooligan (a yahoo) went from directory (it started as a curated web directory) to search (followed by a search engine) then declined into finance and news (what now remains).
3: After changing name three times, this directory has gone wavy.
Click for a solution
DMOZ
After changing name three times (originally GnuHoo, it then became NewHoo, almost ZURL, next Open Directory Project, before becoming DMOZ), this directory (it was a human-curated web directory) has gone wavy (DMOZ was superseded by Curlie in 2018).
Login
