AOT Poisoning: How to Hijack Binary Translation Caches on macOS and Windows

TLDR: Modern ARM-based systems like Apple Silicon and Windows on ARM use binary translation caches to improve performance for x86/x64 applications. By inducing hash collisions in these caches, an attacker can force the system to execute arbitrary code instead of the intended binary. This technique, dubbed AOT poisoning, bypasses standard code signing and integrity checks, enabling stealthy persistence and privilege escalation.

Binary translation is the silent workhorse of the modern computing transition. As we move from x86 to ARM, Apple’s Rosetta 2 and Microsoft’s emulation layers handle the heavy lifting of running legacy code. These systems prioritize performance, which means they cache the results of their translations. If you run an x86 application, the system translates it to ARM instructions once and stores the result. The next time you run that same binary, the system skips the translation and executes the cached version.

This caching mechanism is a goldmine for an attacker. If you can manipulate the cache lookup process, you can trick the system into executing your own malicious code while it believes it is running a legitimate, signed application. This is the core of AOT poisoning.

The Mechanics of Cache Hijacking

The vulnerability lies in how these systems verify the integrity of the binary before executing it from the cache. To avoid the performance hit of hashing an entire binary every time it launches, these systems use a "lookup hash." This hash is derived from a combination of file metadata: the file path, the header of the binary, the user ID, the group ID, and specific file timestamps like mtime.

Crucially, the actual code section of the binary is often excluded from this lookup hash calculation. This is a massive oversight. If an attacker can modify the code section of a binary while keeping the metadata—specifically the timestamps—identical to the original, they can induce a hash collision. The system sees the same lookup hash, assumes the binary is unchanged, and executes the poisoned cached version.

On macOS, this involves targeting the AOT files stored in /var/db/oah/. On Windows, the target is the XTA cache files. The researcher demonstrated this by creating a proof-of-concept tool, translate_tool, which allows an attacker to manually trigger the translation process and generate a poisoned cache entry.

Bypassing Integrity Checks

The most dangerous aspect of this technique is its ability to bypass code signing. When you modify a signed binary, the signature becomes invalid. However, because the system is executing the code from the cache—which was generated before the modification—the signature check happens against the original, cached version.

To make this work in a real-world scenario, you need to handle the metadata. If you modify a file, the mtime and ctime change, which would normally invalidate the lookup hash. The researcher found that on Windows, you can use the NtSetInformationFile API to manually reset these timestamps after modification. By reverting the timestamps to their original values, you effectively "hide" the modification from the cache lookup logic.

This leads to a powerful privilege escalation vector. If you can replace a legitimate, signed installer with a poisoned version, the system will prompt the user to run it with administrative privileges, believing it to be a trusted application from a verified publisher. This is exactly what happened with CVE-2022-42789, where the researcher demonstrated that an attacker could gain elevated execution by manipulating these cache mechanisms.

Real-World Impact and Engagement

For a pentester, this is a high-value technique for persistence. Once you have local access, you don't need to drop a suspicious, unsigned binary that will trigger EDR alerts. Instead, you can poison the cache of a legitimate, signed application that is already installed on the system. Every time the user launches that application, your code executes.

The impact is significant because it turns trusted, signed binaries into vehicles for malicious code. It is a classic A03:2021-Injection scenario, but at the binary level rather than the web level. During an engagement, look for applications that are frequently executed and have writeable directories. If you can gain write access to the binary, you can use the techniques outlined in the XTA cache poisoning repository to establish a persistent backdoor that is invisible to standard integrity checks.

Defensive Considerations

Defending against AOT poisoning is difficult because it exploits the fundamental design of binary translation. The fix, as implemented by Apple in response to this research, is to include more robust integrity checks in the cache lookup process, such as verifying the dynamic code signing status at runtime.

For blue teams, the focus should be on monitoring file integrity for critical system binaries and applications. Any unexpected modification to a signed binary should be treated as a high-severity alert, regardless of whether the file's timestamps appear "normal." If you are managing an environment with ARM-based devices, ensure that your EDR solution is aware of the specific cache directories used by the OS and is monitoring them for unauthorized file creation or modification.

This research highlights a critical gap in how modern operating systems handle the trade-off between performance and security. As binary translation becomes more prevalent, we should expect to see more research into these "invisible" layers of the OS. If you are a researcher, the cache lookup logic is a prime target for future exploration. The next time you see a system service that caches binary data, ask yourself: what happens if I change the data but keep the hash the same?