Debugging of any x86(_64) executable producing strange results under Parallels + Windows on Arm

Question

Recently, I have been experimenting with using an M1 (Arm64) Mac full-time for RE work, including Windows on Arm under Parallels with x86(_64) binaries. From several online sources discussing this use case, such as blogs, I was made confident that this would work without much headache. Instead however, I have been unable to debug a single executable.

So far, I have tried frida-tools, Binary Ninja and x64dbg with the latter being my primary tool. All tools have exhibited similar errors or behaviours.

The tl;dr is that all binaries I have tried to debug end up producing at least one STATUS_INSTRUCTION_MISALIGNMENT followed by EXCEPTION_ACCESS_VIOLATION very early in process load, ending up trying to access an address in the first page of memory (< 0x1000). CLI-only tools don't seem to be affected - only those with a GUI. Originally I thought this was some exception-vectoring related anti-debug technique to detect debuggers, but it is also happening with benign applications, such as Windows internal tools and ShellExView. I have also had it happen with 32-bit applications. Importantly, all of these apps work fine without debugging.

Attached is an example call stack from x64dbg:

(top line shows the 0xC7F address which ultimately faults)

Trying to investigate these call sites confuses me more. Some of it is located in executable sections, but many of the instructions are shown in red "???". Other parts are seemingly located in RW heap memory according to the memory map... I can't make heads or tails of it. Any ideas?

Answer 1

So it's not well documented - but it looks like this setup isn't possible, as effectively you're debugging an x86_64 executable being JIT recompiled to Arm64. This is why the memory seems corrupt and nothing seems to make sense.

The only valid setup is to run the entire OS under emulation e.g. via QEMU. All solutions for this at the moment are, however, dog slow.