Rick Mark

Blog

Work-in-Progress: Using Apple internal builds for RootKits

Backstory

Found this years ago while being stalked in SF mojo_thor. Recently I’ve found more kernel extensions beyond just MojoKDP that are involved. MojoKDP was originally found by running a VM, then capturing the memory state providing a core dump. (see other repo)

Overall Theory

Two Possibilities:

The AuxKC generation process and elides

When the AuxKC (auxiliary KC), or kernel extensions approved on Intel systems, is generated the system works by rebooting to a recovery environment (this prevents tampering with the KC during generation). A system then enumerates all kernel extensions loaded and approved and builds the AuxKC as those that are approved and/or loaded (loading being a proxy for approved in this case) combining all the kext bundles into a single Mach-O file. The file elides eliminates the display or error for kexts that are to be included, yet do not have backing on disk, implying that these kernel extensions can be loaded from DMA or a kernel debug session, which is the only reason that they would not be present on disk (yet still valid signed by @apple). This further implies that this is a list of kernel extensions that Apple knows may be loaded by other means but should silently ignore failures on.

The most interesting fact about the elides list is that it is a subset of the total number of extensions that are present internally, so is an explicit carve out, one that lists those useful for backdoor, privileged hardware or signals intelligence. This seems to be an extension of MojoKDP, whereby the author is at a loss to explain this behavior other than Apple’s explicit support for the signal’s intelligence community.

Leveraged Kernel Extensions

com.apple.driver.AirPort.Brcm4360-MFG

com.apple.driver.AirPort.BrcmNIC-MFG

Broadcom - perhaps these are the original manufacturer versions? Implies that there are differs but not enough data yet.

com.apple.driver.AppleAstrisGpioProbe

Astris is a debug system for iDevices, partially documented elsewhere. Just assume used to do evil things to a iDevice restored on the computer. GPIO implies general purpose IO pins. This may provide a probed devices PMGR/force_dfu pins for iDevice restore avoidance or re-infection.

com.apple.driver.AppleBSDKextStarterVPN

Based on description, some form of VPN that lives in kernel mode and operates at boot?

com.apple.driver.AppleHWAccess

Provides a user mode AppleHWAccessUserClient IOKit service that allows for direct access to physical memory

com.apple.driver.AppleIntelCPUPowerManagementDriver

com.apple.driver.AppleNVMePassThrough

Provides a IOKit user mode service AppleNVMePassThroughUC to pass through commands directly to the NVMe controller.

Dangerous on Apple products as NVMe uses namespaces to store / read things like bridgeOS root filesystem bridgeOS firmware, SysCfg, NVRAM, etc. (oh and whatever AppleEAN is?)

com.apple.driver.AppleIntelTGLGraphicsFramebuffer

com.apple.driver.usb.AppleUSBRecoveryHost

Originally designed to support restoring a macOS install on the T2 from UniversalMac which for some reason never saw completion. Probably too disruptive to existing SI investments.

For the Intel design, internet recovery suffers from a yet unsolved downgrade/upgrade problem. Internet recovery will accept any valid signed BaseSystem.dmg without rollback or timestamped signatures, making anyone in the IP path capable of pushing any build they like, including internal ones containing MojoKDP.kext. This, with the MOJO SMC key set, allows for an attacker to enable an unauthenticated kernel debug port whereby full control of the device is possible using lldb.

com.apple.driver.AppleRSM / com.apple.driver.usb.AppleUSBVHCIRSM

USBVHCI is the T2’s virtual USB over PCIe controller.

com.apple.driver.DrizzlePlatformSupport

Some god awful mashup of the SMC, bluetooth and 8254X ethernet…

Wonder if it can be tripped explicitly based on conditions even if intended to be used via VMware to give a legit use case.

com.apple.driver.DrizzleSMC

com.apple.driver.KernelRelayTesterHost

Seems paired with com.apple.driver.KernelRelayHost. Allows for a user mode application to open the IOKit class KernelRelayTesterUC to be able to call the following:

extTestFunction

Demangled Symbol: int64_t KernelRelayTesterUC::extTestFunction(KernelRelayTesterUC *__hidden this, KernelRelayTesterUC *, void *, IOExternalMethodArguments *)

extSendData

Demangled Symbol: int64_t KernelRelayTesterUC::extSendData(KernelRelayTesterUC *__hidden this, KernelRelayTesterUC *, void *, IOExternalMethodArguments *)

externalMethod

Demangled Symbol: int64_t KernelRelayTesterUC::externalMethod(KernelRelayTesterUC *__hidden this, unsigned int, IOExternalMethodArguments *, IOExternalMethodDispatch *, OSObject *, void *)

com.apple.driver.LuaHardwareAccess

Lua is a language often leveraged for lightweight extension scripts (nginx for example does this). For reasons beyond me, Apple created a Lua engine for kernel mode and signed it…

A user mode program can evaluate code in the kernel by using LuaHardwareAccessUserClient and passing Lua code to it.

com.apple.driver.MEDetect

This appears to be a tool to detect and correct “neuter” Intel management engines. This process is acomplised one of two ways, by setting an undocumented “HAP” or high assurance profile bit that disables the bulk of the ME functionality, crippling the boot code causing the ME to hang, or both. This should only be applicable for T1 and prior as the MacEFI binary comes from the T2 later on. The Intel ME is not generally used in the macOS platform, so (warning conjecture) this seems to be primarily to ensure the device’s ME / AMT / CSME is enabled for SigInt.

It is detection only as only the Intel ME can update its code, therefore it cannot be repaired barring some non-standard method. See also eficheck.

Boot Arguments:

com.apple.driver.kis.AppleKIS

Second hand knowledge says this is related to the Kanzi internal debug cable. This would be needed for demoting a device during restore. I’m strongly starting to wonder if USB-C cables plumb through pins that could be used for this purpose, or if it is used with a form of remote USB to tunnel over other transits.

com.apple.driver.usb.AppleUSBKDP

USB base kernel debug port. Combine with below to bad effect. Only documented kernel debuggers are ethernet, and legacy Firewire serial. This seems to allow for USB mode debug. See also: MojoKDP

Boot Arguments:

com.apple.iokit.RUSBHostFamily

Allow for USB devices to appear as though they are local when they are in fact not. Has a user client IOKit class, so logical that the device comes from user-mode on the system (which obviously depending the user mode binary could be from anywhere, synthetic, network, etc)

Boot Arguments:

com.apple.iokit.fipscavs-kext-tool

Wanna just break crypto? https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Module-Validation-Program/documents/fips140-2/FIPS1402DTR.pdf

Seems you can just new up a IOFIPSCipherUserClient

com.apple.kext.MojoKDP

A debug protocol with two versions (mojo1, mojo2). Original find form 2017 via Parallels memory capture and the professional edition ability to inject kernel debug. In this year I had my logic board replaced multiple times due to graphics issues, each time booting in recovery when the device was new would result in no entry for MojoKDP in ioreg but seemingly after leaving my computer in my apartment alone this node would appear, but only in recovery mode.

com.apple.pae.driver.AppleQuaibridgePCIE

From my best guess seems to be direct access to the PCIe bus?