If you’ve already upgraded to macOS Sequoia, you’ll probably be well aware of the changes it has brought in updating the data used by XProtect. Although it’s now designed to get those updates from iCloud, so far most have been delivered through the traditional Software Update route, and have had to be installed in their new location either manually in Terminal, or by waiting for the new system to get round to it. So is it worth this extra hassle: how has the new XProtect improved?

We’ve now seen two updates only for Sequoia’s XProtect, one for all Macs, and one only for older macOS. Although still early days, the differences in the XProtect bundle have been obvious. Both versions 5273 and 5275, which were only released for macOS 15, contained large additions to their detection rules, which vanished just as suddenly in 5276, the latest version common to all versions of macOS. To see what has changed, we must examine their XProtect.yara files, the only one in its bundle that has seen any changes.

YARA rules

XProtect performs static checks on code before it’s run, to assess whether there’s evidence that it’s malicious. Its tests are based on YARA rules, explained in detail here. Each rule sets out conditions that must be met for XProtect to conclude that a file is known to be malicious. For example, the rule used by XProtect to detect the Eicar test, a standard non-malicious sample used in testing, is:
rule EICAR
{
meta:
description = "OSX.eicar.com.i"
xprotect_rule = true
condition:
filesize <= 100000000 and hash.sha1(0, filesize) == "3395856ce81f2b7382dee72602f798b642f14140"
}

Its meta section names the detection and states that it’s an XProtect rule. The condition to be met for this rule requires a file size of less than 100 MB and the SHA1 hash of the whole file, from its start (0) to the end (filesize), matches the hash given. Some rules have far more complicated conditions, requiring combinations of tests.

Changing rules

New rules that have only appeared in YARA files used by Sequoia have followed a different pattern. Here’s an excerpt from an example:
rule XProtect_MACOS_DOLLITLE_CT
{
meta:
description = "MACOS.DOLITTLE.CT"
uuid = "[UUID]"
condition:
hash.sha256(0, filesize) == "[SHA256 hash]" or
…
}
where [UUID] is the rule’s unique identifier, and [SHA256 hash] is the hash value for that part of the condition.

For the first time this rule’s metadata includes a UUID, and its conditions require the SHA256 hash of the file contents to match one of a number of specific values. In this case, the rule gives only six different hashes, but in the rule for MACOS.SOMA.CT there are 3,124 hashes to match against.

So the new YARA rules tested by Apple using Sequoia’s XProtect don’t yet reveal any evidence of new capabilities. What they do suggest is that it’s capable of handling even larger sets of rules, including single rules testing well over 3,000 file hashes. Over the last year, XProtect’s YARA files have increased considerably in their size and complexity. XProtect.yara from version 2173 a year ago had only 223 rules in just over 3,000 lines of code, while version 5275 for XProtect in Sequoia has more than 350 rules requiring nearly 17,000 lines of code.

XProtect future

It seems most unlikely that Apple will ever update Sonoma or earlier versions of macOS to use comparable code in XProtect to that in Sequoia. We have already seen how it has forked XProtect’s YARA rules to deliver different versions for Sequoia and previous macOS, with the newer XProtect receiving odd-numbered releases, and older ones even-numbered. Although those have been confusing for those users who track security data updates, Apple expects us to leave it to macOS to download and install the right updates promptly.

If the last couple of weeks have been chaotic, I fear that the future will be similar. I’ll continue to do my best to inform you of updates to XProtect’s data, and to help you keep your Macs up to date, whichever version of macOS they’re running.

[Thanks to Arnaud for correcting my original reference to file sizes, rather whole-file hashes.]