How do they work?

SilentKnight and silnite, when running its full checks, do essentially the same tasks. They first check the version of the EFI firmware installed in your Mac, and compare that against the current version for that model in my external database. They next check the versions of the data used by security systems such as XProtect and MRT, and compare those against the current versions in my external database. They then check various security settings, such as whether SIP is enabled, and check whether any system or security updates are available from Apple. Finally, they check the record of software installations to discover the most recent security updates which have been applied.

SilentKnight runs as many of these tasks as it can concurrently, so entering the results as and when it gets them. silnite runs these one after the other, to completion, and can’t return any results until they’re all done. While SilentKnight runs all those checks when you open it, silnite has various options which can limit which checks it performs.

What external connections do they make?

Both SilentKnight and silnite connect to my GitHub server directly to obtain EFI firmware version data, and a listing of the current versions of the security data files. You are welcome to view those data here. If you wish to access those files from your own scripts or software, please contact me, particularly if you wish to do so for financial gain. When it opens, the SilentKnight app also connects to a different file on the GitHub server to check whether an update is available.

The other connection which both SilentKnight and silnite make is to Apple’s software update servers. That is performed through the softwareupdate command tool built into macOS.

If you’re using a firewall or a product like Little Snitch, you may need to add SilentKnight or /usr/local/bin/silnite to its whitelist, and possibly /usr/sbin/softwareupdate too.

If your Mac can’t provide these Internet connections, SilentKnight won’t be able to complete opening its window normally, and with some options silnite may hang. You can still use silnite to make local checks using a command such as
silnite bm
or
silnite bmx
which neither perform checks with the GitHub databases nor check for updates from Apple.

What personal data do they send?

When connecting to my GitHub server, SilentKnight and silnite send no data about your Mac, installed software, or anything else apart from those required to make a regular HTTPS connection.

To reduce the amount of data obtained from the server when looking up the EFI version, SilentKnight and silnite request the appropriate data file for the type of Mac, e.g. MacBook Pro or iMac. However they don’t even inform the server of which model they’re running on in order to do this: the Property Lists stored on the GitHub server are downloaded to your Mac for checking each time. The app doesn’t send the server a query of any kind.

When connecting to Apple’s software update server, SilentKnight and silnite run the softwareupdate command, and that obtains and sends any data to Apple which it does when run normally, e.g. in Terminal.

Why won’t silnite run without error?

silnite is written in Swift 5 and built without including its old support libraries. This makes its binary small, and improves its future compatibility. When installed in recent versions of Mojave and Catalina, its support libraries are part of macOS. Older versions of Mojave, together with previous versions of macOS, need those libraries installed.

If they’re not, trying to run silnite returns an error complaining that a library isn’t loaded, typically libswiftCore.dylib. To fix this, download and install the libraries provided here by Apple. Sadly, at present, Apple doesn’t license them for distribution in installers.

Who maintains their databases?

I do, as Apple doesn’t provide any such information. Each time that Apple releases EFI firmware updates, I manually update the versions on GitHub according to the listing which pico (thank you) and I derive from the update. Each time that Apple pushes updates to security software, I manually update those versions too. If you discover any errors, please let me know soonest so that I can check and correct the databases.

Note that EFI firmware versions given are for release versions of macOS, not those supplied with betas. However, both SilentKnight and silnite try to accommodate more recent firmware versions without reporting them as incorrect.

What about older Macs and versions of macOS?

Apple released EFI firmware updates in 2018 which changed the version numbering system. If your Mac is still running firmware older than that, SilentKnight and silnite can’t check its version, as the previous numberings are extremely confusing if not chaotic. They should draw attention to the fact that you are running old EFI firmware, though. You may wish to run eficheck (if available) to ensure that the version you have installed is acceptable.

Do they work with Catalina betas?

Yes, and where necessary I am adapting SilentKnight and silnite to try to keep pace with changes in Catalina beta releases. However, the EFI firmware versions are based not on beta releases, but on the latest general releases.

How do I update my EFI firmware?

For many years now, Apple has only released firmware updates as part of macOS upgrades, updates, and security updates. Those with access to Apple’s SUS catalogue may be able to obtain separate updates, though. You may have problems updating firmware if your Mac no longer has its original internal storage, an issue I have discussed here.

Where can I get support?

Please post support questions on the respective pages here: for SilentKnight, and for silnite. You are also welcome to send me an email; my address is given in the About page for this blog.

How come they’re free?

In general, I write the utilities available here for my own use. They do things which I want to be able to do, or to explore. Although I do have a couple of tools which I don’t intend releasing, when I write an app I try to make it sufficiently presentable to be able to share.

I first started work on security update checking when Apple released a batch of brand new MacBook Pros with SIP disabled. At that time, it was hard for a user to check the status of SIP on their Mac, so a basic checker turned into LockRattler, which still does slightly more than SilentKnight but manually.

The hurdle which I then needed to get over was how to perform checks against a database. When I realised how I could use GitHub to do this, SilentKnight was next. Several sysadmins then asked for its tools in a command, so I wrote silnite.

Why don’t they update version numbers after installing an update?

SilentKnight and silnite obtain the version numbers of security updates not from the record of software installations, which can be unreliable. On several occasions, the softwareupdate installer thinks that an update has been successfully installed when it hasn’t, something which has occurred for example in early Catalina betas. Updates which are delivered within a larger macOS update or security update also don’t get recorded separately in the record of installations.

Instead, SilentKnight and silnite actually obtain the human-readable version number from the bundle’s CFBundleShortVersionString. This isn’t without its own problems, as some updates have suffered errors. However, their biggest problem is that macOS appears to cache the value when it has been read once. So when a bundle has been updated and its CFBundleShortVersionString has changed, reading that again produces the same result.

SilentKnight and silnite try unloading the bundle once the version has been read, but that doesn’t appear to help either. The only way to get an updated version number from the bundle is to quit the app and open it again. If you know any better, please tell me how to fix this, as it has been driving me crazy for a long time now.

Why use SilentKnight or silnite at all? Isn’t Apple’s silent updating system reliable?

On the great majority of Macs, most of the time the built-in mechanisms for obtaining and installing updates work perfectly well. However, as with other critical systems in macOS, when they fail or hit an error, users are often left in the dark, as the error messages are buried deep in the log. macOS currently has no system for monitoring such issues.

As a result, some users forget to turn SIP or FileVault back on, and can run their Macs for weeks or months with them accidentally turned off. Macs have a longstanding problem with EFI firmware updates which has been highlighted previously, but still hasn’t been fully addressed. Indeed, recent changes in firmware have only exacerbated them: Macs without a T2 chip can run eficheck to determine whether their firmware is ‘acceptable’, but there’s no equivalent to check firmware for the T2 chip, and users may not be aware of the fact that they are running out-of-date firmware at all.

SilentKnight and silnite therefore bring these critical systems under the user’s watchful eye and control. It really wouldn’t be hard for macOS to do much the same, but Apple chooses not to.

(Updated 31 July 2019.)