Xinzhiyuan Report Editor: Run Haoshan [New Zhiyuan Introduction] The iPhone has exposed the "most complex" hardware-level vulnerability in history! Hackers can obtain all sensitive data with just one iMessage without the user noticing. The chain involved in the entire vulnerabili

Category：entertainment
Views：1902

New Zhiyuan Report

Editor ：run so sleepy
[New Zhiyuan Introduction] iphone exposed the "most complex" hardware-level vulnerability in history! Hackers can obtain all sensitive data with just one iMessage, and users will not notice anything. The chain involved in the entire vulnerability was extremely complex, and Karpathy exclaimed: It is not something ordinary people can do.
Recently, Kaspersky researchers discovered that hackers left a very hidden backdoor in thousands of iPhones over four years.
can directly obtain the highest level of root permissions on iPhone through this hardware-level backdoor. To successfully exploit this backdoor, one must have a very comprehensive and detailed understanding of the underlying mechanisms of Apple products.
so much so that the Kaspersky researcher who discovered this vulnerability said, "It is impossible to imagine how this vulnerability was accidentally discovered." In his opinion, it is almost impossible for anyone other than Apple and ARM to know about this vulnerability.
Spyware can use this sophisticated vulnerability to transmit microphone recordings, photos, geolocation and other sensitive data to an attacker-controlled server.
Although a reboot closes the vulnerability, an attacker can reopen the vulnerability simply by sending new malicious iMessage text to the device after it reboots. During
, no user operation is required at all, and no clues will be left, making it very hidden.
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 the scope of individual behavior, but should be a national level behavior.

A netizen who claimed that he still uses a Palm phone replied: "This is the reason why I insist on using a Palm phone."

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

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

"Operation Triangulation" attack chain

The researcher who discovered this vulnerability called it "operation triangulation".
- An attacker sends a malicious attachment via iMessage, and the application opens this vulnerability without the user noticing.
- This attachment exploits a remote code execution vulnerability (cve-2023-41990) in an undisclosed adjust truetype font command known only to Apple. This directive has been around since the early nineties and was removed in a recent update.
- During the attack, it used an advanced programming technique called "return/jump-oriented programming" and used multiple stages of code written in the nsexpression/nspredicate query language that modified javascriptcore library environment to execute a privilege escalation exploit written in JavaScript.
- This JavaScript exploit has been specially processed to make it almost unreadable, while also minimizing its size. However, it still contains approximately 11,000 lines of code. These codes are mainly used to analyze and manipulate javascriptcore and kernel memory.
- It also takes advantage of a debugging function dollarvm ($vm) of javascriptcore. Through this function, the attacker can manipulate the memory of javascriptcore in the script and call the system's native api function.
- This 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 be effective against the latest devices.
- It achieves user-level read and write control of 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).
- This tool also uses hardware memory mapped I/O (MMIO) registers to circumvent the Page Protection Layer (PPL), an issue that has been mitigated in CVE-2023-38606.
- After all vulnerabilities are exploited, the JavaScript vulnerability can be used to control the device at will, including deploying spyware. However, the attacker chose to: (a) start the imagent process and inject code to remove traces of exploitation; (b) run the safari process in incognito mode and guide to the web page containing the next stage of content.
- This webpage has a script embedded in it that can confirm the identity of the victim. Once the verification is passed, the next stage of the attack code will be loaded: the Safari vulnerability.
- safari vulnerability executes shellcode through cve-2023-32435.
- This shellcode further executes another kernel-level vulnerability, also exploiting CVE-2023-32434 and CVE-2023-38606. It's huge in size and functionality, but very different from kernel exploits written in JavaScript. All they share is part of the code related to the above exploits. However, much of its code is also focused on parsing and manipulating kernel memory.
- This vulnerability ultimately gains root privileges and proceeds to other stages, allowing spyware to be loaded.

The mysterious vulnerability

The focus of discussion is a security vulnerability that has been fixed, numbered cve-2023-38606.
The new generation of iPhone has added additional security protection measures at the hardware level, specifically designed to protect sensitive areas in the kernel memory.
Even if an attacker is able to read and write kernel memory, such as this attack using 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 took advantage of another hardware feature in Apple's own designed SoC.
To put it simply, the attacker's method is as follows: while bypassing the hardware protection, they write the data, target address and hash value of the data to some unknown hardware registers in the chip that are not used by the firmware. , to write data to a specific physical address.
Researchers speculate that this unknown hardware feature is likely designed for debugging or testing by Apple engineers or factories, or was included accidentally. Because the firmware does not use this feature, researchers have no idea how attackers know and exploit this feature.

Technical details

In a system on a chip, soc, various peripherals may provide special hardware registers for use by the central processing unit (CPU) to control these peripherals.
To achieve this, these hardware registers are mapped into memory that the CPU can access. This method is 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 "devicetree".
These device tree files can be extracted from the firmware and their contents can be viewed using the dt (devicetree) tool.
mmio storage example in the device tree
For example, in this screenshot, you can see the starting address (0x210f00000) and size (0x50000) of the acc-impl mmio range of cpu0.
While delving into the vulnerabilities used in the "operation triangulation" attack, researchers unexpectedly discovered that most of the mmio addresses used by attackers to bypass hardware-level kernel memory protection were not defined in the device tree. The vulnerability
specifically targets Apple SOCs from A12 to A16, attacking the mysterious mmio register block located at 0x206040000, 0x206140000 and 0x206150000.
This inspired the researchers’ curiosity and made a series of attempts. I searched through the device tree files and firmware files of various devices, but couldn't find any clues.
This puzzles researchers. Why are these mmio addresses used by attackers not used in the firmware? How did the attacker discover these addresses? Which peripheral devices do these mmio addresses belong to?
Afterwards the researchers decided to see if there were other known mmio addresses near these unknown mmio blocks. This time, he finally found some valuable information.
is in the information of the device tree entry of gfx-asc, which is the coprocessor of the gpu. Data dump of gfx-asc entry in

device tree
It contains two mmio (memory-mapped I/O) memory mapped ranges: 0x206400000–0x20646c000 and 0x206050000–0x206050008.

gfx-asc Correlation between mmio range and address used by the vulnerability
To be more precise, this vulnerability uses the following unknown addresses: 0x206040000, 0x206140008, 0x206140108, 0x206150020, 0x206150040 and 0x20 6150048.
researchers found that most of these addresses are located in the middle of the two gfx-asc memory regions, while the remaining one is near the start of the first gfx-asc region.
This implies that all these memory mapped input output (mmio) registers are most likely co-processors belonging to the graphics processing unit (gpu)!
The researchers then conducted a deeper analysis of the vulnerability and discovered further evidence.
During the initialization process, the vulnerability first writes to some memory mapped input and output (mmio) registers located at specific addresses of each SoC. 
if (cpuid == 0x8765edea): # cpufamily_arm_everest_sawtooth (a16)base = 0x23b700408command = 0x1f0023ffelif (cpuid == 0xda33d83d): # cpufamily_arm_avalanche_blizzard (a15)base = 0x23b7003c8command = 0x1f0023ffelif (c puid == 0x1b588bb3): # cpufamily_arm_firestorm_icestorm (a14)base = 0x23b7003d0command = 0x1f0023ffelif (cpuid == 0x462504d2): # cpufamily_arm_lightning_thunder (a13)base = 0x23b080390command = 0x1f0003ff elif (cpuid == 0x07d34b9f): # cpufamily_arm_vortex_tempest (a12)base = 0x23b080388command = 0x1f0003ffif ((~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
Assistance in the device tree and the tool pmgr developed by siguza Next, the researchers found that all these addresses correspond to the mmio (memory-mapped input/output) range where the gfx register in the power manager is located.
Finally, a third confirmation came when the researchers tried to access the registers in these unknown areas.The coprocessor of
gpu reported an error almost immediately, displaying the message: "gfx serror exception class=0x2f (serror interrupt), il=1, iss=0 – power(1)".
In this way, the researchers confirmed that all these unknown mmio registers, which were used for exploits, indeed belong to the GPU's co-processor.
This prompted the researcher to delve deeper into the firmware, which was also written using the ARM architecture and was 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 is particularly noticeable because it is in a separate mmio block from all the other registers.
It is only manipulated during the initialization and end phases of the vulnerability: it is the first register to be set during the initialization process and the last one during the end phase.
Based on the researcher’s experience, it is obvious that this register is used either to enable/disable the hardware functionality exploited by the vulnerability, or for interrupt control. The
researcher began following clues to the outage, and before long, he not only identified the unknown register 0x206040000, but also discovered what exactly the address range 0x206000000–0x206050000 mapped to. Shown below are the results of reverse engineering the vulnerable code that the researchers were able to identify. 
def ml_dbgwrap_halt_cpu():value = read_qword(0x206040000)if ((value 0x90000000) != 0 ):returnwrite_qword(0x206040000, value | 0x80000000)while (true):if ((read_qword(0x206 040000) 0x10000000) != 0):breakdef ml_dbgwrap_unhalt_cpu():value = read_qword(0x206040000)value = (value 0xffffffff2ffffffff) | 0x40000000
 2write_qword(0x206040000, value)while (true):if ((read_qword(0x206040000) 0x10000000) == 0):break
successfully converted the previous pseudocode into The ml_dbgwrap_halt_cpu function matches the function of the same name in the dbgwrap.c file of the xnu source code. This file contains code for controlling the arm coresight mmio debug registers of the main CPU. The
source code shows that there are four mmio areas related to coresight, which are ed, cti, pmu and utt. Each region occupies 0x10000 bytes and is immediately adjacent to each other. The
ml_dbgwrap_halt_cpu function takes advantage of the utt area. Unlike the other three areas, utt does not come from arm, but is a proprietary feature added by Apple specifically for convenience. Each core of the
main CPU has its own coresight mmio debug register block, but unlike the GPU coprocessors, their addresses can be found in the device tree.
Another interesting discovery is that the vulnerability author(s) know how to exploit Apple's proprietary utt area to restart the CPU, and this part of the code is not included in the xnu source code. It is reasonable to speculate that this operation is likely to be obtained through experiments.
However, it is impossible to discover through experiments the attacker's operations on the registers in the second unknown area. The researchers are not sure what blocks of mmio debug registers are there, and if these registers are not used by the firmware, how an attacker discovered their use is a mystery.
Now, let’s focus on the other unknown registers exploited.

New Zhiyuan Report

Editor ：run so sleepy
[New Zhiyuan Introduction] iphone exposed the "most complex" hardware-level vulnerability in history! Hackers can obtain all sensitive data with just one iMessage, and users will not notice anything. The chain involved in the entire vulnerability was extremely complex, and Karpathy exclaimed: It is not something ordinary people can do.
Recently, Kaspersky researchers discovered that hackers left a very hidden backdoor in thousands of iPhones over four years.
can directly obtain the highest level of root permissions on iPhone through this hardware-level backdoor. To successfully exploit this backdoor, one must have a very comprehensive and detailed understanding of the underlying mechanisms of Apple products.
so much so that the Kaspersky researcher who discovered this vulnerability said, "It is impossible to imagine how this vulnerability was accidentally discovered." In his opinion, it is almost impossible for anyone other than Apple and ARM to know about this vulnerability.
Spyware can use this sophisticated vulnerability to transmit microphone recordings, photos, geolocation and other sensitive data to an attacker-controlled server.
Although a reboot closes the vulnerability, an attacker can reopen the vulnerability simply by sending new malicious iMessage text to the device after it reboots. During
, no user operation is required at all, and no clues will be left, making it very hidden.
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 the scope of individual behavior, but should be a national level behavior.

A netizen who claimed that he still uses a Palm phone replied: "This is the reason why I insist on using a Palm phone."

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

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

"Operation Triangulation" attack chain

The researcher who discovered this vulnerability called it "operation triangulation".
- An attacker sends a malicious attachment via iMessage, and the application opens this vulnerability without the user noticing.
- This attachment exploits a remote code execution vulnerability (cve-2023-41990) in an undisclosed adjust truetype font command known only to Apple. This directive has been around since the early nineties and was removed in a recent update.
- During the attack, it used an advanced programming technique called "return/jump-oriented programming" and used multiple stages of code written in the nsexpression/nspredicate query language that modified javascriptcore library environment to execute a privilege escalation exploit written in JavaScript.
- This JavaScript exploit has been specially processed to make it almost unreadable, while also minimizing its size. However, it still contains approximately 11,000 lines of code. These codes are mainly used to analyze and manipulate javascriptcore and kernel memory.
- It also takes advantage of a debugging function dollarvm ($vm) of javascriptcore. Through this function, the attacker can manipulate the memory of javascriptcore in the script and call the system's native api function.
- This 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 be effective against the latest devices.
- It achieves user-level read and write control of 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).
- This tool also uses hardware memory mapped I/O (MMIO) registers to circumvent the Page Protection Layer (PPL), an issue that has been mitigated in CVE-2023-38606.
- After all vulnerabilities are exploited, the JavaScript vulnerability can be used to control the device at will, including deploying spyware. However, the attacker chose to: (a) start the imagent process and inject code to remove traces of exploitation; (b) run the safari process in incognito mode and guide to the web page containing the next stage of content.
- This webpage has a script embedded in it that can confirm the identity of the victim. Once the verification is passed, the next stage of the attack code will be loaded: the Safari vulnerability.
- safari vulnerability executes shellcode through cve-2023-32435.
- This shellcode further executes another kernel-level vulnerability, also exploiting CVE-2023-32434 and CVE-2023-38606. It's huge in size and functionality, but very different from kernel exploits written in JavaScript. All they share is part of the code related to the above exploits. However, much of its code is also focused on parsing and manipulating kernel memory.
- This vulnerability ultimately gains root privileges and proceeds to other stages, allowing spyware to be loaded.

The mysterious vulnerability

The focus of discussion is a security vulnerability that has been fixed, numbered cve-2023-38606.
The new generation of iPhone has added additional security protection measures at the hardware level, specifically designed to protect sensitive areas in the kernel memory.
Even if an attacker is able to read and write kernel memory, such as this attack using 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 took advantage of another hardware feature in Apple's own designed SoC.
To put it simply, the attacker's method is as follows: while bypassing the hardware protection, they write the data, target address and hash value of the data to some unknown hardware registers in the chip that are not used by the firmware. , to write data to a specific physical address.
Researchers speculate that this unknown hardware feature is likely designed for debugging or testing by Apple engineers or factories, or was included accidentally. Because the firmware does not use this feature, researchers have no idea how attackers know and exploit this feature.

Technical details

In a system on a chip, soc, various peripherals may provide special hardware registers for use by the central processing unit (CPU) to control these peripherals.
To achieve this, these hardware registers are mapped into memory that the CPU can access. This method is 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 "devicetree".
These device tree files can be extracted from the firmware and their contents can be viewed using the dt (devicetree) tool.
mmio storage example in the device tree
For example, in this screenshot, you can see the starting address (0x210f00000) and size (0x50000) of the acc-impl mmio range of cpu0.
While delving into the vulnerabilities used in the "operation triangulation" attack, researchers unexpectedly discovered that most of the mmio addresses used by attackers to bypass hardware-level kernel memory protection were not defined in the device tree. The vulnerability
specifically targets Apple SOCs from A12 to A16, attacking the mysterious mmio register block located at 0x206040000, 0x206140000 and 0x206150000.
This inspired the researchers’ curiosity and made a series of attempts. I searched through the device tree files and firmware files of various devices, but couldn't find any clues.
This puzzles researchers. Why are these mmio addresses used by attackers not used in the firmware? How did the attacker discover these addresses? Which peripheral devices do these mmio addresses belong to?
Afterwards the researchers decided to see if there were other known mmio addresses near these unknown mmio blocks. This time, he finally found some valuable information.
is in the information of the device tree entry of gfx-asc, which is the coprocessor of the gpu. Data dump of gfx-asc entry in

device tree
It contains two mmio (memory-mapped I/O) memory mapped ranges: 0x206400000–0x20646c000 and 0x206050000–0x206050008.

gfx-asc Correlation between mmio range and address used by the vulnerability
To be more precise, this vulnerability uses the following unknown addresses: 0x206040000, 0x206140008, 0x206140108, 0x206150020, 0x206150040 and 0x20 6150048.
researchers found that most of these addresses are located in the middle of the two gfx-asc memory regions, while the remaining one is near the start of the first gfx-asc region.
This implies that all these memory mapped input output (mmio) registers are most likely co-processors belonging to the graphics processing unit (gpu)!
The researchers then conducted a deeper analysis of the vulnerability and discovered further evidence.
During the initialization process, the vulnerability first writes to some memory mapped input and output (mmio) registers located at specific addresses of each SoC. 
if (cpuid == 0x8765edea): # cpufamily_arm_everest_sawtooth (a16)base = 0x23b700408command = 0x1f0023ffelif (cpuid == 0xda33d83d): # cpufamily_arm_avalanche_blizzard (a15)base = 0x23b7003c8command = 0x1f0023ffelif (c puid == 0x1b588bb3): # cpufamily_arm_firestorm_icestorm (a14)base = 0x23b7003d0command = 0x1f0023ffelif (cpuid == 0x462504d2): # cpufamily_arm_lightning_thunder (a13)base = 0x23b080390command = 0x1f0003ff elif (cpuid == 0x07d34b9f): # cpufamily_arm_vortex_tempest (a12)base = 0x23b080388command = 0x1f0003ffif ((~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
Assistance in the device tree and the tool pmgr developed by siguza Next, the researchers found that all these addresses correspond to the mmio (memory-mapped input/output) range where the gfx register in the power manager is located.
Finally, a third confirmation came when the researchers tried to access the registers in these unknown areas.The coprocessor of
gpu reported an error almost immediately, displaying the message: "gfx serror exception class=0x2f (serror interrupt), il=1, iss=0 – power(1)".
In this way, the researchers confirmed that all these unknown mmio registers, which were used for exploits, indeed belong to the GPU's co-processor.
This prompted the researcher to delve deeper into the firmware, which was also written using the ARM architecture and was 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 is particularly noticeable because it is in a separate mmio block from all the other registers.
It is only manipulated during the initialization and end phases of the vulnerability: it is the first register to be set during the initialization process and the last one during the end phase.
Based on the researcher’s experience, it is obvious that this register is used either to enable/disable the hardware functionality exploited by the vulnerability, or for interrupt control. The
researcher began following clues to the outage, and before long, he not only identified the unknown register 0x206040000, but also discovered what exactly the address range 0x206000000–0x206050000 mapped to. Shown below are the results of reverse engineering the vulnerable code that the researchers were able to identify. 
def ml_dbgwrap_halt_cpu():value = read_qword(0x206040000)if ((value 0x90000000) != 0 ):returnwrite_qword(0x206040000, value | 0x80000000)while (true):if ((read_qword(0x206 040000) 0x10000000) != 0):breakdef ml_dbgwrap_unhalt_cpu():value = read_qword(0x206040000)value = (value 0xffffffff2ffffffff) | 0x40000000
 2write_qword(0x206040000, value)while (true):if ((read_qword(0x206040000) 0x10000000) == 0):break
successfully converted the previous pseudocode into The ml_dbgwrap_halt_cpu function matches the function of the same name in the dbgwrap.c file of the xnu source code. This file contains code for controlling the arm coresight mmio debug registers of the main CPU. The
source code shows that there are four mmio areas related to coresight, which are ed, cti, pmu and utt. Each region occupies 0x10000 bytes and is immediately adjacent to each other. The
ml_dbgwrap_halt_cpu function takes advantage of the utt area. Unlike the other three areas, utt does not come from arm, but is a proprietary feature added by Apple specifically for convenience. Each core of the
main CPU has its own coresight mmio debug register block, but unlike the GPU coprocessors, their addresses can be found in the device tree.
Another interesting discovery is that the vulnerability author(s) know how to exploit Apple's proprietary utt area to restart the CPU, and this part of the code is not included in the xnu source code. It is reasonable to speculate that this operation is likely to be obtained through experiments.
However, it is impossible to discover through experiments the attacker's operations on the registers in the second unknown area. The researchers are not sure what blocks of mmio debug registers are there, and if these registers are not used by the firmware, how an attacker discovered their use is a mystery.
Now, let’s focus on the other unknown registers exploited.
def dma_ctrl_1():ctrl = 0x206140108value = read_qword(ctrl)write_qword(ctrl , value | 0x8000000000000001)sleep(1)while ((~read_qword(ctrl) 0x8000000000000001) != 0):sleep(1)def dma_ctrl_2(flag): ctrl = 0x206140008value = read_qword(ctrl)if (flag): if ((value 0x1000000000000000) == 0):value = value | 0x1000000000000000 write_qword(ctrl, value)else:if ((value 0x100000000000 0000) != 0):value = value ~0x1000000000000000 write_qword(ctrl, value)def dma_ctrl_3(value):ctrl = 0x206140108value = value | 0x8000000000000000write_qword(ctrl, read_qword(ctrl) value)while ((read_qword(ctrl) 0 x8000000000000001) != 0):sleep(1)def dma_init(original_value_0x206140108):dma_ctrl_1()dma_ctrl_2(false)dma_ctrl_3(original_value_0x206140108)
 3def dma_done(original_value_0x206140108):dma_ctrl_1()dma_ctrl_2(true)dma_ctrl_3(original_ value_0x206140108)
if (cpuid == 0x8765edea): # cpufamily_arm_everest_sawtooth (a16)i = 8mask = 0x7ffffffelif (cpuid == 0xda33d83d): # cpufamily_arm_avalanche_blizzard (a15)i = 8mask = 0x3fffff elif (cpuid == 0x1b588bb3): # cpufamily_arm_firestorm_icestorm (a14)i = 0x28mask = 0x3ffffffelif (cpuid == 0x46250 4d2): # cpufamily_arm_lightning_thunder (a13)i = 0x28mask = 0x3ffffffelif (cpuid == 0x07d34b9f): # cpufamily_arm_vortex_tempest (a12)i = 0x28mask = 0x3ffffff dma_init(original_value_0x206140108)hash1 = calculate_hash(data)hash2 = calculate_hash(data+0x20)hash2_write_ qword(0x206150040, 0x2000000 | (phys_addr 0x3fc0))pos = 0while (pos 0x40):write_qword(0x206150048, read_qword(data + pos))pos += 8phys_addr_upper = ((((phys_addr 14) mask) 18) 0x3ffffffff ffff)value = phys_addr_upper | (hash1 i) | (hash2 50) | 0x1fwrite_qword( 0x206150048, value)dma_done(original_value_0x206140108)
As long as the operation is correct, the hardware will perform a direct memory access (dma) operation and write the data to the specified memory address.
Taking advantage of this hardware feature, attackers can bypass the page protection layer (ppl), mainly to modify page table entries. In addition, it can modify the data in the protected __ppldata section. Although the vulnerability was not used to modify kernel code, in one test conducted by the researchers, an instruction within the __text_exec section of the kernel was successfully modified and triggered an "undefined kernel instruction" showing the expected address and value. "mistake.
This situation only occurred once, and other attempts resulted in amcc errors. Regarding that successful attempt, the researcher has some ideas. In the future, the researcher plans to study it in depth, because he believes that it will be very useful to turn a vulnerability originally used for attacks into a positive use, such as enabling kernel debugging on new iPhones. Significant.
After discussing all the work related to mmio (memory-mapped i/o) registers, let's now focus on the last topic: the calculation method of hash values. The specific algorithm is as follows.
sbox = [0x007, 0x00b, 0x00d, 0x013, 0x00e, 0x015, 0x01f, 0x016,0x019, 0x023, 0x02f, 0x0 37, 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, 0x0 5e, 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,
 20x052, 0x076, 0x08a, 0x091, 0x0ae, 0x106, 0x109, 0x0d3,0x12d, 0x205 , 0x22b, 0x247, 0x07a, 0x0d5, 0x153, 0x22d, 0x038, 0x054, 0x08c, 0x092, 0x061, 0x10a, 0x111, 0x206,0x 209, 0x07c, 0x0ba, 0x0d6, 0x155, 0x193, 0x253, 0x28b,0x307, 0x0bc, 0x0da , 0x156, 0x255, 0x293, 0x30b, 0x058,0x094, 0x062, 0x10c, 0x112, 0x0a1, 0x20a, 0x211, 0x0dc, 0x196, 0x 199, 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, 0x32 6, 0x329, 0x345, 0x383, 0x070,0x0a8, 0x0c4, 0x124, 0x218, 0x142, 0x222 , 0x181, 0x241, 0x178, 0x2ac, 0x32a, 0x2d1, 0x0b0, 0x0c8, 0x128, 0x144,0x1b8, 0x224, 0x1d4, 0x182, 0x2 42, 0x2d2, 0x32c, 0x281,0x351, 0x389, 0x1d8, 0x2d4, 0x352, 0x38a, 0x391 , 0x0d0,0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1e4, 0x2d8, 0x354, 0x38c, 0x392, 0x1e8, 0x 2e4, 0x358, 0x394,0x362, 0x3a1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302 ,0x1f0, 0x2e8, 0x364, 0x398, 0x3a2, 0x0e0, 0x190, 0x250,0x2f0, 0x288, 0x368, 0x304, 0x3a4, 0x370, 0x3 a8, 0x3c4, 0x160, 0x290, 0x308, 0x3b0, 0x3c8, 0x3d0, 0x1a0, 0x260,0x310 , 0x1c0, 0x2a0, 0x3e0, 0x2c0, 0x320, 0x340, 0x380]def calculate_hash(buffer):acc = 0for i in range(8):pos = i * 4value = read_dword(buffer + pos)for j in range(32) ;  as you can see this is a customization algorithm, the calculation of its hash value relies on a predefined sbox table (sbox table). He tried searching for it in the vast library of binaries, but found nothing. 
 You may have noticed that this hash is not particularly secure since it is only 20 bits (10 bits calculated twice), but as long as no one knows how to calculate and apply it, it is sufficient. This approach is best described as "security by obscurity." 
 If an attacker is not using this hardware feature and there is no guidance in the firmware on how to use it, how could they possibly discover and exploit it? 
 researchers did another test. He discovered that the m1 chip built into the mac also had this unknown hardware feature.Then, he conducted an experiment using the powerful m1n1 tool. 
 This tool has a trace_range function that can track all accesses to the specified mmio register range. Use it to monitor activities in the memory range from 0x206110000 to 0x206400000, but the results show that macos does not use these registers. 
 The GPU coprocessor involved this time appeared for the first time in Apple's SOC only recently. Researchers doubt this hardware feature had any purpose in previous retail firmware. 
 Nonetheless, the possibility cannot be ruled out that it may have been accidentally leaked in a specific firmware update or release of the xnu source code and then removed. 
 Researchers originally hoped to explore what was hidden in the second unknown area through the fix for this vulnerability in iOS 16.6. Eventually we did find out how Apple fixed the issue, but they made the fix deliberately hard to understand. 
 Apple prevents this vulnerability from being exploited by adding the mmio ranges 0x206000000–0x206050000 and 0x206110000–0x206400000 to pmap-io-ranges in the device tree. 
xnu uses the information here to determine whether to allow the mapping of certain physical addresses. All documented entries are labeled with a label name that clearly states the purpose of these memory ranges. 
                
Example of entries stored in pmap-io-ranges
 Here, pcie refers to "peripheral component interconnect express", dart is "device address resolution table (device address resolution table)", dapf Stands for "device address filter", and so on. 
 Listed below are the tag names of the exploited memory areas. These tags stand out in the list. 
 Area entry for exploiting the vulnerability 
 "Security by obscurity" is not safe 
 As you can see, this vulnerability is unusual. We don't know how the attacker learned to exploit this unknown hardware feature, nor what it was originally used to do. What. 
 I'm not even sure if it was developed by Apple or if it's caused by a third-party component like arm coresight. 
 But the vulnerability illustrates the fact that as long as there are hardware features that can bypass security protection, no matter how advanced hardware security measures are, they will become useless in the face of savvy attackers. 
 Hardware security often relies on "security through obscurity". Compared with software, hardware is more difficult to reverse engineer and analyze. 
 But this method itself is flawed, because all secrets will eventually be revealed. Systems that rely on "obscure security" for maintenance can never be truly secure. 
 Reference: 
https://arstechnica.com/security/2023/12/exploit-used-in-mass-iphone-infection-campaign-targeted-secret-hardware-feature/
https://securelist.com/operation- triangulation-the-last-hardware-mystery/111669/
Taking advantage of this hardware feature, attackers can bypass the page protection layer (ppl), mainly to modify page table entries. In addition, it can modify the data in the protected __ppldata section. Although the vulnerability was not used to modify kernel code, in one test conducted by the researchers, an instruction within the __text_exec section of the kernel was successfully modified and triggered an "undefined kernel instruction" showing the expected address and value. "mistake.
This situation only occurred once, and other attempts resulted in amcc errors. Regarding that successful attempt, the researcher has some ideas. In the future, the researcher plans to study it in depth, because he believes that it will be very useful to turn a vulnerability originally used for attacks into a positive use, such as enabling kernel debugging on new iPhones. Significant.
After discussing all the work related to mmio (memory-mapped i/o) registers, let's now focus on the last topic: the calculation method of hash values. The specific algorithm is as follows.
sbox = [0x007, 0x00b, 0x00d, 0x013, 0x00e, 0x015, 0x01f, 0x016,0x019, 0x023, 0x02f, 0x0 37, 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, 0x0 5e, 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,
 20x052, 0x076, 0x08a, 0x091, 0x0ae, 0x106, 0x109, 0x0d3,0x12d, 0x205 , 0x22b, 0x247, 0x07a, 0x0d5, 0x153, 0x22d, 0x038, 0x054, 0x08c, 0x092, 0x061, 0x10a, 0x111, 0x206,0x 209, 0x07c, 0x0ba, 0x0d6, 0x155, 0x193, 0x253, 0x28b,0x307, 0x0bc, 0x0da , 0x156, 0x255, 0x293, 0x30b, 0x058,0x094, 0x062, 0x10c, 0x112, 0x0a1, 0x20a, 0x211, 0x0dc, 0x196, 0x 199, 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, 0x32 6, 0x329, 0x345, 0x383, 0x070,0x0a8, 0x0c4, 0x124, 0x218, 0x142, 0x222 , 0x181, 0x241, 0x178, 0x2ac, 0x32a, 0x2d1, 0x0b0, 0x0c8, 0x128, 0x144,0x1b8, 0x224, 0x1d4, 0x182, 0x2 42, 0x2d2, 0x32c, 0x281,0x351, 0x389, 0x1d8, 0x2d4, 0x352, 0x38a, 0x391 , 0x0d0,0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1e4, 0x2d8, 0x354, 0x38c, 0x392, 0x1e8, 0x 2e4, 0x358, 0x394,0x362, 0x3a1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302 ,0x1f0, 0x2e8, 0x364, 0x398, 0x3a2, 0x0e0, 0x190, 0x250,0x2f0, 0x288, 0x368, 0x304, 0x3a4, 0x370, 0x3 a8, 0x3c4, 0x160, 0x290, 0x308, 0x3b0, 0x3c8, 0x3d0, 0x1a0, 0x260,0x310 , 0x1c0, 0x2a0, 0x3e0, 0x2c0, 0x320, 0x340, 0x380]def calculate_hash(buffer):acc = 0for i in range(8):pos = i * 4value = read_dword(buffer + pos)for j in range(32) ;  as you can see this is a customization algorithm, the calculation of its hash value relies on a predefined sbox table (sbox table). He tried searching for it in the vast library of binaries, but found nothing. 
 You may have noticed that this hash is not particularly secure since it is only 20 bits (10 bits calculated twice), but as long as no one knows how to calculate and apply it, it is sufficient. This approach is best described as "security by obscurity." 
 If an attacker is not using this hardware feature and there is no guidance in the firmware on how to use it, how could they possibly discover and exploit it? 
 researchers did another test. He discovered that the m1 chip built into the mac also had this unknown hardware feature.Then, he conducted an experiment using the powerful m1n1 tool. 
 This tool has a trace_range function that can track all accesses to the specified mmio register range. Use it to monitor activities in the memory range from 0x206110000 to 0x206400000, but the results show that macos does not use these registers. 
 The GPU coprocessor involved this time appeared for the first time in Apple's SOC only recently. Researchers doubt this hardware feature had any purpose in previous retail firmware. 
 Nonetheless, the possibility cannot be ruled out that it may have been accidentally leaked in a specific firmware update or release of the xnu source code and then removed. 
 Researchers originally hoped to explore what was hidden in the second unknown area through the fix for this vulnerability in iOS 16.6. Eventually we did find out how Apple fixed the issue, but they made the fix deliberately hard to understand. 
 Apple prevents this vulnerability from being exploited by adding the mmio ranges 0x206000000–0x206050000 and 0x206110000–0x206400000 to pmap-io-ranges in the device tree. 
xnu uses the information here to determine whether to allow the mapping of certain physical addresses. All documented entries are labeled with a label name that clearly states the purpose of these memory ranges. 
                
Example of entries stored in pmap-io-ranges
 Here, pcie refers to "peripheral component interconnect express", dart is "device address resolution table (device address resolution table)", dapf Stands for "device address filter", and so on. 
 Listed below are the tag names of the exploited memory areas. These tags stand out in the list. 
 Area entry for exploiting the vulnerability 
 "Security by obscurity" is not safe 
 As you can see, this vulnerability is unusual. We don't know how the attacker learned to exploit this unknown hardware feature, nor what it was originally used to do. What. 
 I'm not even sure if it was developed by Apple or if it's caused by a third-party component like arm coresight. 
 But the vulnerability illustrates the fact that as long as there are hardware features that can bypass security protection, no matter how advanced hardware security measures are, they will become useless in the face of savvy attackers. 
 Hardware security often relies on "security through obscurity". Compared with software, hardware is more difficult to reverse engineer and analyze. 
 But this method itself is flawed, because all secrets will eventually be revealed. Systems that rely on "obscure security" for maintenance can never be truly secure. 
 Reference: 
https://arstechnica.com/security/2023/12/exploit-used-in-mass-iphone-infection-campaign-targeted-secret-hardware-feature/
https://securelist.com/operation- triangulation-the-last-hardware-mystery/111669/
Video about Xinzhiyuan Report Editor: Run Haoshan [New Zhiyuan Introduction] The iPhone has exposed the "most complex" hardware-level vulnerability in history! Hackers can obtain all sensitive data with just one iMessage without the user noticing. The chain involved in the entire vulnerabili
entertainment News
entertainment Video
↑