As promised last week, Apple has released the upgrade to macOS 15.0 Sequoia, together with security updates to bring Sonoma to version 14.7, and Ventura to 13.7. There should also be Safari updates to accompany the latter two.
The Sequoia update is around 6.6 GB for Apple silicon Macs, and 14.7 is around 1.6 GB. For Intel Macs, 15.0 is around 4.9 GB as an ‘update’, and 14.7 is around 860 MB.
Security release notes for Sequoia list around 77 vulnerabilities addressed, including two in the kernel, none of which Apple is aware may have been exploited in the wild. Release notes list 36 vulnerabilities addressed in Sonoma 14.7 here, and there are 30 listed for Ventura 13.7 here.
iBoot firmware is updated to version 11881.1.1, Intel T2 firmware to version 2069.0.0.0.0 (iBridge 22.16.10353.0.0,0), and Safari to 18.0 (20619.1.26.31.6).
After completing the upgrade to 15.0, you are likely to see that the installed XProtect version is 0, in other words that there is no XProtect data. You can leave your Mac to automatically download the required data from iCloud, or manually force it using the command sudo xprotect update
then entering your admin password. That will normally ‘activate’ the XProtect data previously installed, and set the version to 5272, although that will then need to be updated to 5273 separately. Don’t be surprised if you end up repeating the trip to Terminal to get this to work.
Apple will release macOS 15.0 Sequoia on 16 September, that’s next Monday, alongside iOS and iPadOS 18.0, and upgrades and updates for lesser mortals. Among the latter are Sonoma 14.7 and Ventura 13.7, as I’ll explain later. Sequoia introduces two important changes to security data checked and updated by SilentKnight, for which I have built and notarized another new version of that app, 2.11, which is essential for anyone intending to upgrade to Sequoia, and worthwhile for all running Catalina or later.
What’s coming next week
Apple has just provided release candidates for the following three new versions of macOS:
Sequoia 15.0, its first full release,
Sonoma 14.7, its first security-only update,
Ventura 13.7, the first of its security-only updates for its final year of support.
There’s not expected to be any update to Monterey 12.7.6, which is no longer supported, even with security updates.
The minor version numbers of Sonoma and Ventura will then be the same, the first time this has happened. In previous release cycles, the start of the first year of security-only updates has been with x.6, as it was with Ventura, and proceeded through the year with versions x.6.1, x.6.2, and so on. Over the coming year, we can expect 14.7.1 and 13.7.1, then 14.7.2 and 13.7.2, continuing until Ventura reaches the end of its third and final year of support in a year’s time.
Sequoia 15.1, the first release with AI support, is now expected in October, and continues in beta-testing, alongside AI-enhanced versions of iOS and iPadOS in versions 18.1.
TCC in Sequoia
The TCC database in /Library/Apple/Library/Bundles/TCC_Compatibility.bundle was introduced in Mojave (when it had a different location, of course), and has been updated with each new major version of macOS since. That has now vanished, and I can find no trace of it, nor any apparent substitute. If you run SilentKnight 2.10 in Sequoia, that will be reported as an error, so version 2.11 addresses that by omitting that result both from its display box and the text report below.
XProtect in Sequoia
Since it was first introduced many moons and versions of macOS ago, there has been a bundle named XProtect.bundle in CoreServices, most recently in the path /Library/Apple/System/Library/CoreServices/XProtect.bundle, that has provided data for XProtect scans of executable code and other security services. That bundle has been updated frequently in downloads labelled XProtectPlistConfigData. Although that can still be present in Sequoia, XProtect now uses a completely different source for its data, that is normally updated through iCloud’s CloudKit rather than Software Update.
The result is that your Mac can have an up-to-date XProtect.bundle in the normal location, but XProtect itself may not be up-to-date at all. For example, in fresh installs of Sequoia, XProtect.bundle is usually absent, and the new tool to check its version may report a number of 0.
SilentKnight versions 2.10 and 2.11 have been updated to cope with this major change, which Apple has apparently not seen fit to document (yet). They check the correct current version using a new command tool, and report that version number faithfully. At present, though, SilentKnight isn’t able to update this new form of XProtect. You can either leave macOS to do that itself in its own time, or you can run a command in Terminal to force the update immediately: sudo xprotect update
following which you’ll need to authenticate with your admin user password.
I intend to address this more completely in SilentKnight version 3, but for the time being this is fully documented in SilentKnight’s Help book and Help Reference, in these latest versions.
SilentKnight, Skint, SystHist, LockRattler
SilentKnight version 2.11 is strongly recommended for anyone intending to update to Sequoia this year, and, as it also fixes a bug in reporting Studio Display firmware in VMs, is worthwhile for those remaining with Sonoma for longer. It’s available from here: silentknight211
from Downloads above, on its Product Page, and through its auto-update mechanism.
Thankfully, as Skint doesn’t check TCC, the current version 1.08 remains fully compatible with Sequoia. The current release of SystHist, 1.20, works well with Sequoia too, and usefully distinguishes between the two different types of XProtect update, XProtectPlistConfigData delivered through Software Update, and XProtectCloudKitUpdate the new one obtained through iCloud instead.
I don’t intend to update LockRattler for the time being. It won’t report the true version of XProtect, but does report that it can’t find TCC or the GKE data. Otherwise it should continue to function as expected in Sequoia.
More to come in Sequoia 15.0
These changes to XProtect are but one of the significant changes that Apple hasn’t yet mentioned. Once 15.0 has been released, I’ll be delighted to provide fuller details of others.
Summary
On Monday 16 September, Apple will release macOS 15.0, and security updates 14.7 and 13.7.
Monterey is no longer supported.
Download and install SilentKnight 2.11 if you’re intending to upgrade to Sequoia this year.
Skint and SystHist remain fully compatible with Sequoia.
Watch here for further news on Sequoia once it has been released next week.
Sequoia 15.1 with AI will be released next month (October).
Every autumn/fall, the current version of macOS changes, and with it there are changes great and small that can affect the apps we run. If you use any of the free apps that I provide here, now is the time to check that you’re running the correct version to support both your current macOS, and any that you might aspire to in the coming months.
SilentKnight
Although most of my apps have auto-update mechanisms that inform you when their updates are available, there are some notable pitfalls that can lull you into a sense of false security. Most importantly, SilentKnight was upgraded to version 2 two years ago to ensure its compatibility with Catalina and later. Every few days I come across someone who is still using version 1 with a newer release of macOS and seeing incorrect results. If you use SilentKnight in any version of macOS from Catalina onwards, then please ensure that it’s updated to the current version 2.10: SilentKnight 2.10 (Universal App for Catalina to Sequoia)
This is particularly important if you intend upgrading to Sequoia, because of the changes it brings in how XProtect is updated. If you’re still running 2.9 or earlier, then SilentKnight will give you incorrect versions for XProtect, and at worst could report a version of 0 (zero) as it might not be able to find XProtect at all.
Skint and SystHist
For the same reason, Skint should be updated to version 1.08: Skint 1.08 (Universal App for Monterey, Ventura, Sonoma and Sequoia only)
SystHist lists full system and security update installation history, a task that invariably requires an annual update to cope with the quirks of the new version of macOS. If you’re aiming for Sequoia at some stage, ensure that you have updated it to version 1.20: SystHist 1.20 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)
Writing Tools
Although Apple isn’t intending to release any of its new AI features in the initial version of Sequoia, 15.0, but is delaying them for 15.1, you might like to prepare for that by updating my rich text editor and PDF viewer in advance. Their latest versions should prove fully compatible with Writing Tools when they’re released.
DelightEd is a Rich Text (RTF) editor with special Dark Mode features and support for interlinear text, and version 2.3 should work fully with Writing Tools: DelightEd 2.3 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)
Podofyllin is a lightweight PDF viewer (without any editing capability, so it can’t alter original PDF files) and shows source code and more. Version 1.3 should work fully with Writing Tools: Podofyllin 1.3 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)
XProCheck, Nalaprop, Precize
Other recent updates you might have missed include the following.
XProCheck to check on XProtect Remediator scans completed and reported in the log: XProCheck 1.6 (Universal App for Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)
Nalaprop for multilingual natural language parsing, now compatible with Writing Tools: Nalaprop 1.3 (Universal App for Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)
Precize, which looks deep into files, bundles and folders to show their full size including extended attributes, provides macOS Bookmarks and volfs paths as enduring file references, and detailed information contained in Bookmarks and Aliases: Precize 1.15 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)
Key points
For Catalina or later, particularly Sequoia, use SilentKnight 2.10.
For Sequoia in particular, use Skint 1.08.
For Sequoia in particular, use SystHist 1.20.
Older versions of those apps will give incorrect results when run in more recent versions of macOS.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 145. The previous version was 142.
Apple doesn’t release information about what security issues this update might add or change. There are no changes in the number or names of its scanning modules, and Bastion rules also remain unchanged.
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, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-145.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5272. Apple has now released this for Sequoia betas as well, using their new update mechanism.
Apple doesn’t release information about what security issues this update might add or change. This makes a small amendment in the Yara definitions to the detection signature for MACOS.d98ded3, and adds another rule to those to detect MACOS.DOLITTLE, in MACOS.DOLITTLE.DOFSTRGT.
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, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5272.
If you’re running a Sequoia beta and are still stuck at 5271, don’t worry if sudo xprotect check
doesn’t offer you the update to 5272. Ignore it and run sudo xprotect update
and with any luck it will update your Mac to 5272.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 142. It appears this version was first released over 12 hours ago, early in the morning GMT, but was then removed from Apple’s update servers. It has just now been made available again.
Apple doesn’t release information about what security issues this update might add or change. For the first time since its release, this update removes a scanning module, for RedPine. Bastion rules remain unchanged.
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, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-142.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
It’s the middle of August, the time when, if you’re not an Apple engineer or third-party developer, you’re most likely to be on holiday. To help you enjoy that, today I’m going to engage you in a little game I call What’s the time, Mr. APFS?
To play along with me, all you need is a copy of the latest version of Precize, version 1.15, available from here: precize115
from Downloads above, from its Product Page, or via its auto-update mechanism.
Precize update
Thanks to some questions from applice, who should really be spending more time watching the Olympics than worrying about file systems, this new version of Precize comes with significant enhancements in its datestamp reporting. First, it now gives datestamps with decimal seconds, for those who want to be truly precise, and it adds two new time fields, for Attribute Modification, and Access, as shown in the screenshot below.
Once you’ve downloaded the Zip archive, unZip it where it is, and move the Precize app from its folder into one of your Applications folders (that ensures it doesn’t undergo app translocation). Keep the Zip archive it came in, as we’ll use that in the game, whose rules are simple: all you have to do is roughly guess the times in each of Precize’s datestamp fields, for different files and bundles.
What are the times?
APFS stores four datestamps for each file and directory in its volumes, and the four fields shown in this version of Precize correspond to those four datestamps. There is a fifth that the Finder can display, the date and time that an item was added to its current location. That’s not derived from the file’s attributes, but from directories, and isn’t shown in Precize.
The four datestamps are:
Created, taken from the create_time value, the time that this item was created, given as the clock time corresponding to an unsigned 64-bit integer giving the number of nanoseconds since January 1, 1970 at 00:00 UTC, disregarding leap seconds.
Modified, taken from the mod_time value, the time that this item was last modified, likewise.
Attr Mod, taken from the change_time value, the time that the item’s attributes were last modified, likewise. Those attributes include permissions, for example, and changes made to extended attributes should also update this value.
Accessed, taken from the access_time value, the time that this item was last accessed, likewise.
By default, APFS is relaxed over how it records the last of these. Some other filesystems are strict, and change the access_time value every time a file is read. Instead, APFS only updates this if its value is prior to (earlier than) the mod_time value. You can change this behaviour by setting an APFS volume’s APFS_FEATURE_STRICTATIME flag, for instance when mounting it by using a command like mount -u -o strictatime
However, that’s not the default for APFS volumes. For example, inspect your Mac’s Data volume using the command mount | grep '/System/Volumes/Data '
and you should see something like /dev/disk6s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse, root data)
without any mention of the strictatime flag. List all mounted volumes using mount
and you’re unlikely to see any using strictatime.
File datestamps
Open the new version of Precise, so it’s poised waiting for you to drop a file onto its icon in the Dock. Then take a screenshot, and drop that file onto Precise’s icon. What do you expect the four datestamps to be?
This is an easy one for starters: the four times should be very close, and almost match the time given in the screenshot’s name. The first two should be Created and Modified, the latter perhaps a thousandth of a second behind, reflecting the time it takes from creation of the screenshot file to completing the save. Next comes Accessed, when macOS opened the file to perform its animation of the screenshot sliding away. Last of all should be Attr Mod, recording when all its attributes such as permissions were set in its destination folder.
Now copy that file to another volume. What do you expect those four datestamps to be there?
Created and Modified should remain the same, as those are preserved when the file is moved around in local file systems. But Attr Mod and Accessed should record the time that file arrived on the second volume, reflecting its new attributes and its access for the copy.
Now try a couple of harder questions. Drop the Zip archive that contained Precize onto the running app’s icon. What do you expect those four datestamps to be?
All four datestamps should record times close to when you downloaded that Zip file from here. Just as with the screenshot, Created leads, closely followed by Modified, with Accessed and Attr Mod trailing. Note that they’re all four very recent, subsequent to its download to your Mac.
Unzip that Precize Zip archive again and drop the Precize app within it onto the running app’s icon. What do you expect those four datestamps to be?
Now the Created and Modified values are taken from that app when it left my Mac here, but Attr Mod should be more recent, and Accessed is likely to be older unless you have accessed the app bundle since then.
What’s the time, Mr. APFS?
All the best games involve learning. I hope these have shown you how those four datestamps are set and changed. In summary:
Software like the Finder, when copying between local volumes, also copies most of a file’s attributes, including Created and Modified datestamps for consistency, even though it creates a new file in the destination. Attr Mod and Accessed are linked to the copy event, though.
Software like browsers, when copying from a remote server to a local volume, don’t preserve the file’s attributes, so all four datestamps correspond to the local arrival and creation of the download.
Archives such as Zip files preserve most of a file’s attributes, and reconstitute its Created and Modified values to those saved when the archive was created.
As a final exercise, using Precize, determine whether copying files by AirDrop between Macs behaves conservatively like copying between local volumes, or resets datestamps as downloading from the internet does. Why do you think that Apple designed it to work that way?
Imagine my surprise earlier this week when I went to ensure my MacBook Pro had successfully installed new versions of XProtect and XProtect Remediator. SilentKnight informed me that XProtect was still at version 5270, and there was no update available to take it to 5271. I then manually checked the version of XProtect.bundle in CoreServices, and that confirmed it hadn’t been updated, but SilentKnight still couldn’t find any update, despite XProtect Remediator updating as normal.
My next visit was to the list of Installations in System Information, where it informed me that XProtect had been updated to 5271, thanks to XProtectCloudKitUpdate, instead of the usual XProtectPlistConfigData installation downloaded through softwareupdate. After a little jiggling with the new xprotect command tool I realised what had happened, and why SilentKnight was awry.
After an unfortunate delay, described later, I’m at last able to offer a new version of SilentKnight that won’t make this same mistake when run in recent beta-releases of Sequoia. Version 2.10 now detects whether it’s running on Sequoia; if it is, instead of inspecting the version of the XProtect.bundle in CoreServices, it now uses the official method of xprotect version
instead.
Sadly, things get more difficult if XProtect is out of date. SilentKnight can’t use its normal call for update installation to softwareupdate, as that doesn’t handle XProtect updates any more in Sequoia. The official method is first to check whether an update is available using xprotect check
then perform the update with xprotect update
Although that might seem simple enough for SilentKnight to handle, both of those calls need to be made with elevated privileges. In Terminal, you’d just preface them with sudo, but apps can’t do that, and should normally use a privileged helper app, running with root privileges, something none of my apps do yet.
There’s another problem for SilentKnight in that it now needs to use two separate methods of checking for updates, and that in turn requires its code to be completely rewritten, a task I’m deferring to a whole new version, SilentKnight 3, which will only run on Sequoia. Until that’s available, bear with me and use the xprotect commands above as you need (remembering to sudo them); at least SilentKnight will now indicate when that might be necessary.
SilentKnight version 2.10 is available from here: silentknight210
from Downloads above, from its Product Page, and through its auto-update mechanism. Apart from fixing any remaining bugs, I intend this to be the final release of SilentKnight 2 with support up to and including macOS Sonoma, when updating remained so simple.
You can see the effect during one of my tests in a freshly made Sequoia VM.
At first, there’s apparently no XProtect installed at all, and the command tool returns a version of 0. Although there are updates offered for MRT (really?), Gatekeeper Compatibility Data and XProtectPayloads (XProtect Remediator), none is offered for XProtect.
I then manually updated XProtect using the command tool, and ran SilentKnight 2.10 again.
Immediately afterwards, XProtect is at the current version number of 5271 even though there’s no XProtect.bundle in CoreServices, and there’s no record of that update in the list of latest updates. That’s listed in the new version of SystHist, though, giving its mysterious XProtectCloudKitUpdate origin.
This update has been released a day later than I intended, because of a disorientating bug that caused the app to crash early whenever it tried to start up, complaining of an unreachable file path when it was starting to run its main code. I suspected a problem in the structure of the app and chased many red herrings before I realised this was the result of overenthusiastic code.
I have put the call to the xprotect command tool into conditional code, with an if to check whether it was running on Sequoia or earlier macOS. Apparently the path to the command was being checked before the instructions discovered whether that code would be run. As the path to the command tool doesn’t exist on earlier macOS, when it was being checked before determining which macOS was running, that was failing in Sonoma, as expected. Once I had worked out where this was occurring, without any clue from the errors, I had to change the type of conditional test used so the code didn’t check a non-existent path on older macOS.
Soon after the first beta-release of macOS 15.0 Sequoia, I noticed a post on X (formerly Twitter) reporting a new command tool xprotect, but never got the chance to take a look at it. With recent updates to the beta versions, its purpose has become clear: Sequoia uses a different mechanism to update its XProtect data. And that’s not compatible with any of my security update utilities, LockRattler, SilentKnight, Skint, or even SystHist.
The reason for this is that, in all previous versions of macOS going back many years, XProtect data are stored in a bundle named XProtect.bundle, where you (and my apps) can check its installed version number. But in Sequoia that bundle is neither used nor updated when XProtect data are updated. Indeed, Software Update and its command tool equivalent softwareupdate, used by my apps, can’t even see XProtect updates any more, as they’re checked and installed using a different mechanism, which is where the xprotect command tool comes into play.
Run any of those apps on a recent version of Sequoia, and they’ll dutifully report the version of XProtect found in that bundle, which will now be out of date, but the update is apparently not available, although in many cases it has already been installed and protection is up to date!
Unfortunately, as is so often the case, searching Sequoia’s release notes and other Apple sources fails to discover any information about this change, or the xprotect command tool.
SystHist was due its annual update anyway, so its new version 1.20 now handles Sequoia updates and (as well as it can) reports those it can find to XProtect. This new version is available from here: systhist120
from Downloads above, from its Product Page, and through its auto-update mechanism.
Skint (and its menu bar companion SkintM) version 1.08 now checks correctly for the XProtect version in Sequoia, and is available from here: skint108
from Downloads above, from its Product Page, and through its auto-update mechanism.
I’m not proposing updating LockRattler to address this issue, as SilentKnight and Skint are now capable of handling most needs. If this distresses you, please let me know and I’ll see what I can do in the coming weeks. However, without major internal surgery it’s never going to work fully with Sequoia, I’m afraid.
I was hoping to release a new version of SilentKnight today too, but Xcode gremlins are currently blowing that away, and I fear I have some reconstruction needed before it will do anything other than crash! As soon as I have a stable release, I will make it available.
These changes are sufficient to make it unwise to continue with the current major version of SilentKnight, as all its update code needs to be reworked so that it handles other updates through softwareupdate, as it does at present, and has a privileged helper app to obtain updates using the new mechanism for XProtect alone. My intention therefore is to provide one final update to SilentKnight 2 that will work without being able to update XProtect in macOS 15. That will be the final release to support macOS Catalina to Sonoma. The new version will be SilentKnight 3, will require Sequoia, and I hope will be released before Sequoia 15.0 hits the streets.
I apologise for this, and for the mess it’s causing for SilentKnight in Sequoia, but as you’ll appreciate this is all way beyond my control. I will also be writing further about what appears to be happening with XProtect for the weekend.
Apple has just released patch updates to bring macOS Sonoma to version 14.6.1, and Ventura to 13.6.9. There’s no update for Monterey, though.
There are no entries for these updates in Apple’s security release notes, which simply report “no CVE entries” for both. However, the matching updates for iOS apparently refer to important bug fixes, including one that prevented changing Advanced Data Protection settings. Whether that’s the same for Sonoma and Ventura is anyone’s guess.
There are no updates to firmware on T2 Intel models, or on Apple silicon, and Safari’s version and build numbers haven’t changed either.
The 14.6.1 update is just over 650 MB to download on Intel systems, and around 1.4 GB on Apple silicon.
Looking through the contents of the /System folder shows small build increments in the Security framework and some keychain-related files such as Keychain Circle Notification app. There are no other changes in /System or the bundled apps at all.
Apple has just released updates to XProtect Remediator security software (Catalina or later), bringing it to version 141, and to XProtect (for all macOS from El Capitan or so) bringing it to version 5271.
Apple doesn’t release information about what security issues these updates might add or change.
XProtect’s Yara definitions add two further signatures to its long list of those for MACOS.DOLITTLE, these being qualified as DOFNPXR and DOFDLMARM.
XProtect Remediator adds a new scanning module for Dolittle, the same codename that has just had a family of 14 detection rules added in XProtect. There are no changes to Bastion rules for the behavioural version of XProtect (Ventura and Sonoma only).
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, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-141 and XProtectPlistConfigData_10_15-5271.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
I’m pleased (if not delighted) to release three new versions of my free utilities that work with text, one way or another. These fix problems that prevent their previous versions from having access to the new AI Writing Tools in macOS Sequoia. As they’re the first new builds of these apps for a year, they should also improve performance and user experience across all more recent versions of macOS.
DelightEd is a rich text editor designed to work well with appearance modes, specifically Dark Mode. While it doesn’t support the embedding of images or graphics, thus is text-only, it was designed to overcome problems when displaying rich text within apps, as it generates text that displays correctly regardless of mode. It’s also unusual for its extensive support of interlinear text.
Select a block of text in this new version, and when your Mac is running a beta-release of Sequoia 15.1, the contextual menu offers the full suite of Writing Tools. However, as it doesn’t use TextKit 2, it doesn’t display the fancy effects while those tools are applied.
DelightEd version 2.3 is now available from here: delighted23
from Downloads above, from its Product Page, and via its auto-update mechanism. This version should be compatible with all versions of macOS from High Sierra to Sequoia, although support for Writing Tools is only available in Sequoia 15.1.
Podofyllin is a lightweight PDF viewer that can’t alter the original PDF, although it can save and export it in different forms. It also gives access to the full source for each PDF, allowing you to discover hidden contents and see the file’s complete metadata. It’s perhaps the only PDF viewer that lets you open multiple independent views of the same PDF for simultaneous reference.
The view on the right of its main window shows all text extracted from the PDF; select a section of that, and you can now use the contextual menu to apply Writing Tools to that text. macOS may also allow you to select text in the central PDF view and apply Writing Tools to that, although that currently doesn’t work.
Podofyllin version 1.3 is now available from here: podofyllin13
from Downloads above, from its Product Page, and via its auto-update mechanism. This version should be compatible with all versions of macOS from High Sierra to Sequoia, although support for Writing Tools is only available in Sequoia 15.1.
Nalaprop takes advantage of the linguistic capabilities of more recent versions of macOS to parse text, mark up its different parts of speech, and produce frequency counts of words and their stems (lemmas). This works across all those languages supported by these linguistic features, and with multilingual text.
Support for Writing Tools extends to two of its three panels: select the text you want to proofread, summarise, or rewrite, and use the contextual menu to invoke that AI feature.
Nalaprop version 1.3 is now available from here: nalaprop13
from Downloads above, from its Product Page, and via its auto-update mechanism. This version should be compatible with all versions of macOS from Mojave to Sequoia, although support for Writing Tools is only available in Sequoia 15.1.
Although I have been testing these, just in case there are any nasty bugs in them, I’ll leave the previous versions available from their product pages, ready if you need to revert to them.
As I forecast only yesterday, Apple has today released macOS Sonoma version 14.6. According to its previous calendar, this should be the last release of the cycle featuring general bug fixes and any remaining enhancements. In previous years this has been released in September, just before the first release of the new version of macOS. This year, in September we could see either 14.7 or 14.6.1, Sonoma’s first security-only update.
Apple hasn’t provided any release notes at all for 14.6, although it did for the release candidate, where it stated that this fixes app crashes when running iPhone and iOS apps on Apple silicon Macs, and a complex bug resulting in the hardware video decoder not being used when it should have been.
Security vulnerabilities addressed total 54, of which several are bugs in open source code. These are detailed in Apple’s security release notes.
There are firmware updates for all Macs with T2 or Apple silicon chips, and probably several other recent Intel models. T2 Macs should now be running version 2022.140.5.0.0 (iBridge: 21.16.6074.0.0,0), and Apple silicon Macs iBoot version 10151.140.19. I will analyse other models and update the firmware tables here, and SilentKnight’s expectations, later in the week, to allow time to update.
Sonoma 14.6 has a build number of 23G80.
Looking at changes in the System volume, there are many minor increments in build numbers, including both public and private frameworks. Of the bundled apps, in addition to several minor build increments, the following appear more substantial:
Music updated to version 1.4.6
News to version 9.5
Photos a large build increment
Safari to version 17.6 (19618.3.11.11.5)
Stocks to version 6.2.3
TV to version 1.4.6.
In the /System/Library folder, APFS is updated to version 2236.141.1 and the FileProvider framework has a significant build increment.
These confirm that many small general bug fixes are included with the long list of security fixes, although there’s no sign of any new kernel extensions or private frameworks with exotic names.
Apple has just released the update to bring Sonoma to version 14.6, together with security updates to Ventura (13.6.8) and Monterey (12.7.6). I expect that there will also be a separate update to Safari for Ventura and Monterey.
The 14.6 update is around 2.2 GB for Apple silicon Macs, and 1.8 GB for Intel models.
iBoot firmware for Apple silicon Macs is updated to version 10151.140.19, firmware of Intel Macs with T2 chips is updated to version 2022.140.5.0.0 (iBridge: 21.16.6074.0.0,0), and Safari to version 17.6 (19618.3.11.11.5).
Significant bugs fixed include app crashes when running iPhone and iOS apps on Apple silicon Macs, and a complex bug in video decoding in which the hardware decoder wasn’t used when it should have been.
Security release notes for Sonoma reveal a total of 54 vulnerabilities have been addressed, including several in open source code, but none is reported as having been known to be exploited yet. Those for Ventura list 36, and for Monterey 32.
I’ll update this article with further details as they arrive.
Apple has just released updates to XProtect Remediator security software (Catalina or later), bringing it to version 140, and to XProtect (for all macOS from El Capitan or so) bringing it to version 5270.
Apple doesn’t release information about what security issues these updates might add or change.
XProtect’s Yara definitions have a single change, adding a DOFMVAD signature to its long list of those for MACOS.DOLITTLE.
No new scanning modules are added to XProtect Remediator, and there are no changes to Bastion rules for the behavioural version of XProtect (Ventura and Sonoma only).
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, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-140 and XProtectPlistConfigData_10_15-5270.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
XProCheck is one of my unique utilities, to the best of my knowledge the only app that checks whether your Mac has been running its XProtect Remediator (XPR) anti-malware scanner, and reports the results of its scans in full detail. I’m delighted to release a new version of XProCheck that improves both its checks and reports.
Apple introduced XPR two years ago, as a greatly enhanced replacement for its Malware Removal Tool, MRT, which is no longer maintained. XPR is installed on all Macs running Catalina or later, and normally performs two sets of scans, one as the user and the other as root, every 24 hours or so. It currently contains scanning modules for 22 different types of malware, and one to cover those previously included in MRT’s checks. Its scans will not only detect known malware, but will also try to remove (‘remediate’) those that it does detect.
Strangely, XPR doesn’t report detections or remediations to the user, but can report them to third-party security software using Endpoint Protection (Ventura and later). As far as I’m aware, though, few if any security products make use of that, leaving XProCheck as the only way to monitor XProtect Remediator scans and reports.
XProCheck version 1.6 brings one major improvement, in changing the method used to check log entries for XPR’s reports. Previous versions have used the log show command, but this new version now reads the log directly using the OSLog API. Although this does have a small memory leak that would only be significant if you were to run dozens of checks in succession, it brings considerable improvements in speed, particularly when checking scans over longer periods, and on Apple silicon Macs.
This version of XProCheck typically takes less than 60 MB of memory before running any checks, rising to less than 70 MB after it has completed its first check. That may rise by less than 1 MB with each subsequent check made before quitting the app, so is almost unnoticeable.
There are two more cosmetic improvements: XProCheck reports now also give the time of its checks in local time as well as GMT/UTC, and the width of the scanner name field is a little greater, to better accommodate CardboardCutout.
XProCheck version 1.6 runs on all Intel and Apple silicon Macs in all versions of macOS from Catalina to Sequoia betas, and is available from here: xprocheck16-1
from Downloads above, from its Product Page, and through its auto-update mechanism.
Hot on the heels of the slightly earlier update to XProtect, Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 139.
Apple doesn’t release information about what security issues this update might add or change. There are no new scanning modules, and Bastion rules remain unchanged.
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, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-139.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5269.
Apple doesn’t release information about what security issues this update might add or change. This adds a whole new family of 11 rules to detect MACOS.DOLITTLE, including individual rules D2MPLN, EXTINST, AGNSYM, DYINSTXR, AGNXR, DOFSRP, DOFSDCRYP, DOFCONSH, DOFDLM, DOFINLXR and DOFDECS. Several of these are so large that the Yara file has more than doubled in size from 6,250 to over 13,200 lines.
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, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5269.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Sometimes developing software is a journey of exploration without a clear destination. A couple of weeks ago, I wrote about how log entries from Battery Center revealed useful information about input devices like keyboards and mice, and Uninterruptible Power Supplies (UPS). Several of you remarked that it would be useful to have a utility to provide easy access to those. This is my first progress report, and comes complete with a first version of that utility, Unhidden.
Battery Center
It turns out that those log entries from the com.apple.BatteryCenter don’t come from macOS itself, but from one of three new Private Frameworks added to macOS Sonoma: BatteryCenter itself, and two supporting frameworks BatteryCenterUI and BatteryUIKit. In Ventura and earlier, similar log entries came from com.apple.iohid, although those weren’t as extensive.
Battery Center appears to support Battery widgets in /System/Library/CoreServices/Batteries.app named BatteriesAvocadoWidget, and offered in Sonoma’s new range of widgets.
Thus, com.apple.BatteryCenter periodically checks known connected input devices (‘HID’ for Human Interface Devices), UPS, and internal batteries in Mac notebooks, and publishes lists of information in the log. That data is used by the background service app Batteries.app to feed the data displayed in the Battery widgets available in Sonoma.
Unless your Mac has a Battery widget installed, perhaps on its Desktop, Battery Center entries don’t appear in its log. When you do add a Battery widget to the Desktop, though, checks are made every few seconds, and their results written to the log, and those continue even after removing the widget, at least until the next time that Mac is shut down or restarted.
Third-party software isn’t supposed to access private services like Battery Center, so creating an independent utility to perform similar functions would have to capture its own data. However, given access to the log, it’s possible to read Battery Center’s entries there instead.
Unhidden
This initial version does one job: each time you open a new window in the app, it displays the most recent results obtained by Battery Center, across all the devices that it checks. There are three essential requirements:
The Mac must be running macOS Sonoma or later (including Sequoia betas); this works on both Intel and Apple silicon Macs.
The user must have admin privileges, as those are required to access the log.
Battery Center must be running. This normally requires that a Battery widget has been installed since the last time that Mac started up, unless it’s already running.
Each time Unhidden opens a fresh window, it inspects the log for Battery Center entries. It initially checks the last 5 seconds, then increases the time period up to a maximum of half an hour. It then either reports that it can’t find any entries from Battery Center, or it displays them in the window.
Standard display gives all key results obtained in compact lines. If those aren’t clear or large enough, there’s optional Large Text.
Supported devices
Unhidden has been tested with the following:
Apple wireless Magic Keyboards, both operating on battery and when connected by their charging cable
Apple wireless Magic Mice, both operating on battery and when connected by their charging cable
Apple wireless Magic Trackpad 2, both operating on battery and when connected by their charging cable
Supported UPS connected by a USB cable
Standard Mac notebook internal batteries, both charging and not.
The range of peripherals is wide, and to make it easy to report problems with other devices, and errors, Unhidden has a Debug Mode. To enter that, it must be selected in Settings, the app quit, and opened again. Instead of seeing normal results in its window, Debug Mode displays the original raw log entries, together with a button to save those in a text file. Please add problem entries to this article as comments, or send them to me by email (address in the About page), so that Unhidden can accommodate more devices correctly.
Download
Unhidden version 1.0 is now available only from here for the time being: unhidden01
Future
I’d really like to discover a way of activating Battery Center without having to fiddle with widgets, something I’ll be looking at next. There are several alternative ways to present these results, and to check them at regular intervals, perhaps presenting changes graphically. Please let me know where you’d like Unhidden to go, if you’re interested in my developing it any further.
Login
