Mirror Mirror: Restoring Reflective Code Loading on macOS

Reflective, or in-memory, code loading runs a compiled payload straight from memory so it never touches disk, which sidesteps file-based scanning. This talk looks at how that works on macOS, where Apple's process memory isolation stops security tools from reading another process's memory. It reviews earlier malware that used Apple's loader APIs for the technique, some of it copied almost unchanged from old sample code.

The speaker shows that newer versions of the loader quietly write the memory buffer to a file first, which undoes the technique. He tests workarounds: redirecting the temp directory to a RAM disk, lengthening the generated file name so a hardcoded path check misses it, and finally compiling an older open-source dyld into a custom loader. That loader maps code in-process without writing files, and it still runs under the hardened runtime when Apple's supported entitlement exceptions are added.

For detection, the loading step produced no unified log or Endpoint Security events in his tests. Reactive checks such as inspecting memory mappings with vmmap or sampling threads for unknown binaries are possible but limited, and the exception entitlements are common enough to be a weak signal. The practical takeaway is to watch what the payload does after it runs.