After four years, the iPhone was attacked by the most complex attack in history! One iMessage stole all private data, Karpathy exclaimed

Recently, researchers at Kaspersky discovered that hackers had left a very hidden backdoor in thousands of iPhones over a period of more than four years.

Through this hardware-level backdoor, you can directly obtain the highest level of root privileges on the iPhone. To successfully use this backdoor, you must have a very comprehensive and detailed understanding of the underlying mechanisms of Apple products.

So much so that the Kaspersky researcher who discovered the vulnerability said, "It is hard to imagine how this vulnerability was discovered accidentally." In his opinion, it is almost impossible for anyone other than Apple and ARM to know about this vulnerability.

The sophisticated vulnerability could allow spyware to transmit microphone recordings, photos, geolocation and other sensitive data to servers controlled by the attacker.

Although a reboot closes the vulnerability, an attacker can re-enable it simply by sending a new malicious iMessage text to the device after it has rebooted.

During the process, no user operation is required and no traces will be left, making it very covert.

In this regard, OpenAI scientist Andrej Karpathy said: This is undoubtedly the most complex attack chain we have seen so far.

In this regard, Karpathy believes that this is no longer within the scope of individual behavior, but should be an act at the national level.

Another netizen who claimed he still used a Palm phone replied: "This is why I insist on using a Palm phone."

Some netizens even lamented: "If you succeed in annoying someone with such technical capabilities and resources, the last thing you need to worry about is the data on your phone."

Currently, Apple has fixed this core security vulnerability on October 25, 2023.

"Triangle Operation" attack chain

The researchers who discovered the vulnerability called it "Operation Triangulation."

- An attacker could send a malicious attachment via iMessage and the app would enable the vulnerability without the user noticing.

- The attachment exploits a remote code execution vulnerability (CVE-2023-41990) in an undisclosed ADJUST TrueType font directive known only to Apple. This directive has existed since the early 90s until it was removed in a recent update.

- During the attack, it adopts an advanced programming technique called "return/jump-oriented programming" and uses multiple stages of code written in NSExpression/NSPredicate query language, which modify the environment of the JavaScriptCore library to execute a privilege escalation exploit written in JavaScript.

- This JavaScript exploit has been specially processed to make it almost unreadable and to reduce its size as much as possible. However, it still contains about 11,000 lines of code. These codes are mainly used to analyze and manipulate JavaScriptCore and kernel memory.

- It also exploits a debugging feature of JavaScriptCore called DollarVM ($vm), which allows attackers to manipulate JavaScriptCore's memory in scripts and call native system API functions.

The attack tool is designed to be compatible with both old and new iPhone models, and for newer devices, it includes a technique for bypassing the Pointer Authentication Code (PAC), which allows the attack to work against the latest devices.

- It achieves user-level read and write control over all physical memory of the device by exploiting an integer overflow vulnerability (CVE-2023-32434) in the XNU memory mapping system calls (mach_make_memory_entry and vm_map).

- The tool also uses hardware memory-mapped I/O (MMIO) registers to circumvent the Page Protection Layer (PPL), which has been mitigated in CVE-2023-38606.

- After all the vulnerabilities have been exploited, the JavaScript exploit can be used to manipulate the device at will, including deploying spyware. However, the attackers chose to: (a) launch the IMAgent process and inject code to clear the exploit traces; (b) run the Safari process in Incognito mode and navigate to the webpage containing the next stage content.

The webpage contains a script that verifies the victim’s identity and, once verified, loads the next stage of the attack: a Safari exploit.

- Safari vulnerability to execute shellcode via CVE-2023-32435.

- This shellcode further executes another kernel-level vulnerability, also exploiting CVE-2023-32434 and CVE-2023-38606. It is very large in size and functionality, but it is very different from the kernel exploit written in JavaScript. They only share some code related to the above exploits. However, most of its code is also focused on parsing and manipulating kernel memory.

- This exploit eventually gains root privileges and proceeds to other stages, which allows the spyware to be loaded.

Mysterious loophole

The discussion focused on a security vulnerability that has already been patched, tracked as CVE-2023-38606.

The new generation of iPhones has added additional security measures at the hardware level, specifically to protect sensitive areas in kernel memory.

Even if an attacker is able to read and write kernel memory, such as in this attack exploiting the CVE-2023-32434 vulnerability, this protection prevents them from taking full control of the device.

Researchers found that in order to circumvent this hardware protection, attackers actually exploited another hardware feature in Apple's own SoC.

In simple terms, the attackers' method is this: while bypassing hardware protection, they write the data, the target address, and the hash value of the data into some unknown hardware registers in the chip that are not used by the firmware, in order to write data to a specific physical address.

The researchers speculate that this unknown hardware feature was likely designed for debugging or testing by Apple engineers or the factory, or was accidentally included. Since the firmware does not use this feature, the researchers have no idea how an attacker could have known about it and exploited it.

Technical Details

In a System on a Chip (SoC), various peripherals may provide special hardware registers for the central processing unit (CPU) to use to control these peripherals.

To achieve this, these hardware registers are mapped into memory accessible by the CPU, a method called memory-mapped I/O (MMIO).

In Apple products such as iPhone, Mac and other devices, the MMIO address range of peripheral devices is stored in a special file format called "Device Tree".

These device tree files can be extracted from the firmware and their contents can be viewed using the dt (DeviceTree) tool.

Storage example of MMIO in device tree

For example, in this screenshot, you can see the start address (0x210f00000) and size (0x50000) of the acc-impl MMIO range for cpu0.

While digging deeper into the vulnerability used in the Operation Triangulation attack, the researchers unexpectedly discovered that most of the MMIO addresses used by the attackers to bypass hardware-level kernel memory protection were not defined in the device tree.

The vulnerability specifically targets Apple's SoCs from A12 to A16, and attacks a mysterious block of MMIO registers located at 0x206040000, 0x206140000, and 0x206150000.

This aroused the curiosity of the researchers, and they made a series of attempts, looking through the device tree files and firmware files of various devices, but they couldn't find any clues.

This puzzled the researchers. Why were these MMIO addresses used by the attacker not used in the firmware? How did the attacker find these addresses? Which peripheral devices did these MMIO addresses belong to?

The researcher then decided to check if there were other known MMIO addresses near these unknown MMIO blocks. This time, he finally found some valuable information.

In the information of the device tree entry of gfx-asc, this is the coprocessor of the GPU.

Data dump of the gfx-asc entry in the device tree

It contains two MMIO (Memory-Mapped I/O) memory-mapped ranges: 0x206400000–0x20646C000 and 0x206050000–0x206050008.

Correlation between gfx-asc MMIO range and addresses used by the vulnerability

To be more precise, this vulnerability uses the following unknown addresses: 0x206040000, 0x206140008, 0x206140108, 0x206150020, 0x206150040, and 0x206150048.

The researchers found that most of these addresses were located in the middle of the two gfx-asc memory regions, while the remaining one was close to the beginning of the first gfx-asc region.

This suggests that all those memory-mapped input-output (MMIO) registers most likely belong to the coprocessor of the graphics processing unit (GPU)!

The researchers then conducted a deeper analysis of the vulnerability and found further evidence.

During initialization, the exploit first writes to some memory-mapped input-output (MMIO) registers located at addresses specific to each SoC.

 if (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) base = 0x23B700408 command = 0x1F0023FF elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) base = 0x23B7003C8 command = 0x1F0023FF elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) base = 0x23B7003D0 command = 0x1F0023FF elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) base = 0x23B080390 command = 0x1F0003FF elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) base = 0x23B080388 command = 0x1F0003FF if ((~read_dword(base) & 0xF) != 0): write_dword(base, command) while(True): if ((~read_dword(base) & 0xF) == 0): break

Pseudocode of the GFX power manager control code in the vulnerability

With the help of the device tree and Siguza's tool pmgr, the researchers found that all these addresses correspond to the MMIO (Memory-Mapped Input/Output) range where the GFX registers in the power manager are located.

Finally, a third confirmation came when the researchers tried to access registers in these unknown areas.

The GPU coprocessor reported an error almost immediately, displaying the message: "GFX SERROR Exception class=0x2f (SError interrupt), IL=1, iss=0 – power(1)".

This way, the researchers confirmed that all these unknown MMIO registers, which were used for the exploit, did belong to the GPU’s coprocessor.

This prompted the researcher to look deeper into the firmware, which was also written in ARM architecture and unencrypted, but he did not find any information related to these registers in the firmware.

He decided to take a closer look at how the vulnerability manipulated these unknown MMIO registers. Of all the registers, 0x206040000 stood out because it was in a separate MMIO block from all the other registers.

It is only manipulated during the initialization and finalization phases of the vulnerability: during initialization it is the first register set and during finalization it is the last.

Based on the researcher's experience, it is clear that this register is either used to enable/disable the hardware functionality exploited by the vulnerability or for interrupt control.

The researcher started following the clues of the interrupt, and before long, he not only identified this unknown register 0x206040000, but also discovered what exactly the address range 0x206000000–0x206050000 mapped to. Shown below is the result of reverse engineering the vulnerable code that the researcher was able to identify.

 def ml_dbgwrap_halt_cpu(): value = read_qword(0x206040000) if ((value & 0x90000000) != 0): return write_qword(0x206040000, value | 0x80000000) while (True): if ((read_qword(0x206040000) & 0x10000000) != 0): break def ml_dbgwrap_unhalt_cpu(): value = read_qword(0x206040000) value = (value & 0xFFFFFFFF2FFFFFFF) | 0x40000000 write_qword(0x206040000, value) while (True): if ((read_qword(0x206040000) & 0x10000000) == 0): break

利用程序使用0x206040000寄存器的伪代码

Successfully matched the ml_dbgwrap_halt_cpu function in the previous pseudocode with the function of the same name in the dbgwrap.c file of the XNU source code. This file contains the code for manipulating the ARM CoreSight MMIO debug registers of the main CPU.

The source code shows that there are four MMIO areas related to CoreSight, namely ED, CTI, PMU and UTT. Each area occupies 0x10000 bytes and is adjacent to each other.

The ml_dbgwrap_halt_cpu function uses the UTT region. Unlike the other three regions, UTT does not come from ARM, but is a proprietary feature added by Apple specifically for convenience.

The researchers confirmed that the address range 0x206000000 to 0x206050000 is indeed the CoreSight MMIO debug register block of the GPU coprocessor by writing ARM_DBG_LOCK_ACCESS_KEY to the corresponding addresses.

Each core of the main CPU has its own block of CoreSight MMIO debug registers, but unlike the GPU coprocessors, their addresses can be found in the device tree.

Another interesting observation is that the author(s) of the exploit knew how to reboot the CPU using Apple's proprietary UTT region, which is not included in the XNU source code. It is reasonable to speculate that this operation was probably learned through experimentation.

However, the attacker's manipulation of registers in the second unknown area was not discovered experimentally. The researchers are not sure what MMIO debug register blocks are there, and if these registers are not used by the firmware, it is also a mystery how the attacker discovered their use.

Now, let's focus on the other unknown registers of the exploit.

Register addresses 0x206140008 and 0x206140108 are responsible for enabling/disabling and executing the hardware features that the vulnerability relies on.

 def dma_ctrl_1(): ctrl = 0x206140108 value = read_qword(ctrl) write_qword(ctrl, value | 0x8000000000000001) sleep(1) while ((~read_qword(ctrl) & 0x8000000000000001) != 0): sleep(1) def dma_ctrl_2(flag): ctrl = 0x206140008 value = read_qword(ctrl) if (flag): if ((value & 0x1000000000000000) == 0): value = value | 0x1000000000000000 write_qword(ctrl, value) else: if ((value & 0x1000000000000000) != 0): value = value & ~0x1000000000000000 write_qword(ctrl, value) def dma_ctrl_3(value): ctrl = 0x206140108 value = value | 0x8000000000000000 write_qword(ctrl, read_qword(ctrl) & value) while ((read_qword(ctrl) & 0x8000000000000001) != 0): sleep(1) def dma_init(original_value_0x206140108): dma_ctrl_1() dma_ctrl_2(False) dma_ctrl_3(original_value_0x206140108) def dma_done(original_value_0x206140108): dma_ctrl_1() dma_ctrl_2(True) dma_ctrl_3(original_value_0x206140108)

Pseudocode of the exploit using registers 0x206140008 and 0x206140108

Register 0x206150020 is specifically used for Apple's A15/A16 Bionic SoC. During the start of the exploit, this register is set to 1; after the exploit is complete, it is restored to its original value.

Register 0x206150040 is used to store some status flags and the lower portion of the target physical address.

The final register, 0x206150048, is responsible for storing the data to be written and the high-order portion of the target physical address. This data is packaged with the data's checksum hash and another value (possibly an instruction). This hardware feature writes the data in blocks of 64 (0x40) bytes each for aligned writes, and requires nine consecutive write operations to write all the data to the 0x206150048 register.

 if (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) i = 8 mask = 0x7FFFFFF elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) i = 8 mask = 0x3FFFFF elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) i = 0x28 mask = 0x3FFFFF elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) i = 0x28 mask = 0x3FFFFF elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) i = 0x28 mask = 0x3FFFFF dma_init(original_value_0x206140108) hash1 = calculate_hash(data) hash2 = calculate_hash(data+0x20) write_qword(0x206150040, 0x2000000 | (phys_addr & 0x3FC0)) pos = 0 while (pos < 0x40): write_qword(0x206150048, read_qword(data + pos)) pos += 8 phys_addr_upper = ((((phys_addr >> 14) & mask) << 18) & 0x3FFFFFFFFFFFF) value = phys_addr_upper | (hash1 << i) | (hash2 << 50) | 0x1F write_qword(0x206150048, value) dma_done(original_value_0x206140108)

Pseudocode of the exploit using registers 0x206150040 and 0x206150048

As long as the operation is correct, the hardware will perform a direct memory access (DMA) operation to write the data to the specified memory address.

This hardware feature allows attackers to bypass the Page Protection Layer (PPL), which is mainly used to modify page table entries. In addition, it can modify data in the protected __PPLDATA segment. Although this vulnerability was not used to modify kernel code, in a test conducted by the researchers, an instruction in the kernel's __TEXT_EXEC segment was successfully modified, causing an "undefined kernel instruction" error showing the expected address and value.

This only happened once, and all other attempts resulted in an AMCC error. The researcher has some ideas about that successful attempt, which he plans to study in the future, because he thinks it would be very meaningful to turn a vulnerability that was originally used for attack into a positive use, such as enabling kernel debugging on new iPhones.

After discussing all the work related to MMIO (Memory-Mapped I/O) registers, let's focus on the last topic: the calculation method of hash value. The specific algorithm is as follows.

 sbox = [ 0x007, 0x00B, 0x00D, 0x013, 0x00E, 0x015, 0x01F, 0x016, 0x019, 0x023, 0x02F, 0x037, 0x04F, 0x01A, 0x025, 0x043, 0x03B, 0x057, 0x08F, 0x01C, 0x026, 0x029, 0x03D, 0x045, 0x05B, 0x083, 0x097, 0x03E, 0x05D, 0x09B, 0x067, 0x117, 0x02A, 0x031, 0x046, 0x049, 0x085, 0x103, 0x05E, 0x09D, 0x06B, 0x0A7, 0x11B, 0x217, 0x09E, 0x06D, 0x0AB, 0x0C7, 0x127, 0x02C, 0x032, 0x04A, 0x051, 0x086, 0x089, 0x105, 0x203, 0x06E, 0x0AD, 0x12B, 0x147, 0x227, 0x034, 0x04C, 0x052, 0x076, 0x08A, 0x091, 0x0AE, 0x106, 0x109, 0x0D3, 0x12D, 0x205, 0x22B, 0x247, 0x07A, 0x0D5, 0x153, 0x22D, 0x038, 0x054, 0x08C, 0x092, 0x061, 0x10A, 0x111, 0x206, 0x209, 0x07C, 0x0BA, 0x0D6, 0x155, 0x193, 0x253, 0x28B, 0x307, 0x0BC, 0x0DA, 0x156, 0x255, 0x293, 0x30B, 0x058, 0x094, 0x062, 0x10C, 0x112, 0x0A1, 0x20A, 0x211, 0x0DC, 0x196, 0x199, 0x256, 0x165, 0x259, 0x263, 0x30D, 0x313, 0x098, 0x064, 0x114, 0x0A2, 0x15C, 0x0EA, 0x20C, 0x0C1, 0x121, 0x212, 0x166, 0x19A, 0x299, 0x265, 0x2A3, 0x315, 0x0EC, 0x1A6, 0x29A, 0x266, 0x1A9, 0x269, 0x319, 0x2C3, 0x323, 0x068, 0x0A4, 0x118, 0x0C2, 0x122, 0x214, 0x141, 0x221, 0x0F4, 0x16C, 0x1AA, 0x2A9, 0x325, 0x343, 0x0F8, 0x174, 0x1AC, 0x2AA, 0x326, 0x329, 0x345, 0x383, 0x070, 0x0A8, 0x0C4, 0x124, 0x218, 0x142, 0x222, 0x181, 0x241, 0x178, 0x2AC, 0x32A, 0x2D1, 0x0B0, 0x0C8, 0x128, 0x144, 0x1B8, 0x224, 0x1D4, 0x182, 0x242, 0x2D2, 0x32C, 0x281, 0x351, 0x389, 0x1D8, 0x2D4, 0x352, 0x38A, 0x391, 0x0D0, 0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1E4, 0x2D8, 0x354, 0x38C, 0x392, 0x1E8, 0x2E4, 0x358, 0x394, 0x362, 0x3A1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302, 0x1F0, 0x2E8, 0x364, 0x398, 0x3A2, 0x0E0, 0x190, 0x250, 0x2F0, 0x288, 0x368, 0x304, 0x3A4, 0x370, 0x3A8, 0x3C4, 0x160, 0x290, 0x308, 0x3B0, 0x3C8, 0x3D0, 0x1A0, 0x260, 0x310, 0x1C0, 0x2A0, 0x3E0, 0x2C0, 0x320, 0x340, 0x380 ] def calculate_hash(buffer): acc = 0 for i in range(8): pos = i * 4 value = read_dword(buffer + pos) for j in range(32): if (((value >> j) & 1) != 0): acc ^= sbox[32 * i + j] return acc

Pseudocode of the hash function used by this unknown hardware function

As you can see, this is a custom algorithm that relies on a predefined sbox table for hash calculation. He tried searching for it in the huge binary file library, but found nothing.

You may have noticed that this hash is not particularly secure, as it only has 20 bits (10 bits calculated twice), but it is sufficient as long as no one knows how to calculate and apply it. This approach is best described as "security by obscurity".

If attackers don’t use this hardware feature, and there aren’t any instructions in the firmware on how to use it, how could they possibly discover and exploit it?

The researcher did another test. He found that the M1 chip built into the Mac also has this unknown hardware feature. Then, he conducted an experiment using the powerful m1n1 tool.

The tool has a trace_range function that can trace all accesses to a specified range of MMIO registers. It was used to monitor activity in the memory range from 0x206110000 to 0x206400000, but the results showed that macOS did not use these registers.

The GPU coprocessor involved in this attack was first seen in Apple's SoCs only recently, and the researchers doubt that this hardware feature has ever been used in any previous retail firmware.

That said, we cannot rule out the possibility that it may have been accidentally leaked in a specific firmware update or XNU source code release and then removed.

The researchers had hoped to explore what was hidden in the second unknown area through the fix for this vulnerability in iOS 16.6. In the end, they did find out how Apple solved the problem, but they deliberately made the fix difficult to understand.

Apple prevented this vulnerability from being exploited by adding the MMIO ranges 0x206000000–0x206050000 and 0x206110000–0x206400000 to the pmap-io-ranges of the device tree.

XNU uses this information to decide whether to allow mappings of certain physical addresses. All recorded entries are labeled with a label name that clearly states what these memory ranges are used for.

Example of entries stored in pmap-io-ranges

Here, PCIe refers to "Peripheral Component Interconnect Express", DART is "Device Address Resolution Table", DAPF stands for "Device Address Filter", and so on.

Listed below are the tag names of the memory regions being exploited. These tags stand out in the list.

Zone entry for exploit

Security by obscurity is not safe

As you can see, this vulnerability is unusual in that we have no idea how an attacker learned to exploit this unknown hardware feature, nor what it was originally used for.

It's not even certain whether it was developed by Apple or caused by a third-party component like ARM CoreSight.

But the vulnerability illustrates a fact: as long as there are hardware features that can bypass security protections, no matter how advanced the hardware security measures are, they will become useless in the face of savvy attackers.

Hardware security often relies on "security through obscurity" because hardware is more difficult to reverse engineer than software.

But this approach is inherently flawed, because all secrets will eventually be revealed. Systems that rely on "security by obscurity" will never be truly secure.