Six years ago, in July 2019, Macs came closer to disaster than at any time before or since. Millions of Mac users around the world had, at some time or other, installed Zoom conferencing software, and in doing so had unknowingly put their Macs at risk. For their convenience, the old Zoom installers of that time also installed a hidden web server that was left running. That was capable of reinstalling the Zoom client, and had been discovered to contain an easily exploitable vulnerability that exposed all those Macs to remote attacks.

The only solution was for Apple to harness its old Malware Removal Tool, MRT, to remove that web server from all Macs before they came under attack. Although MRT had been widely criticised for what others considered to be weakness, on this occasion it proved its value. MRT version 1.45 was released by Apple on 10 July 2019, and averted that potential catastrophe.

Three years later, in the summer of 2022, Apple replaced MRT with its successor, XProtect Remediator or XPR, which has been vastly improved, and still contains the remnants of MRT in its MRTv3 scanning module. As Apple documents almost nothing about XPR, it has been up to others to dive deep inside it, among them Koh M Nakagawa, @tsunek0h, of FFRI Security. While others have merely scratched the surface, he has just presented a superb and deep account of XPR at Black Hat USA. You can download the slides for his presentation from here.

Status_code 30 PlugInCanceled

If you check XPR scans using SilentKnight or XProCheck, you’ll be aware that for many months some of them are terminated prematurely with a status_code of 30 and the message PlugInCanceled. This most commonly affects Adload scans, and still occurs in beta-releases of macOS 26 Tahoe. According to Koh’s research, the Adload scanning module alone contains over 1,000 Yara detection rules, accounting for the long time it takes whenever XPR runs a set of scans.

Before XPR started terminating its scans as it does now, a full set could take an hour or more, so XPR has started using a timer. If the scan exceeds the time allowed, then it will be abruptly terminated, resulting in this status_code and message. There’s nothing the user can do to avoid it, and we’re surprised that XPR continues to exhibit this behaviour.

Laptop Macs

The other significant limitation in XPR affects those using MacBook Pro, MacBook Air and MacBook models. Because XPR scans take a substantial amount of energy, even when run almost entirely on the E cores of Apple silicon Macs, daily full scans will only be run when those laptops are using mains power, and won’t be run at all on battery.

As XPR scans are also normally run when a Mac is awake but only under a light load, it’s possible for a laptop to go several days without running an XPR scan. The only solution is to leave it connected to mains power, awake and doing little else for an hour or so, when it should seize the opportunity to catch up with that and other important background tasks with similar requirements.

Unfortunately, XPR won’t warn you that it hasn’t run any scans for several days, but SilentKnight and XProCheck will.