Rosetta Hell

The plan was simple, use Docker to start a Linux container, install GDB and pwndbg, use Rosetta to run binaries and attach to the debug port, boom.

Rosetta has a GDB server built-in that allows waiting for GDB to attach before starting a process and debugging it like any good old x86-64 binary. This can be done with

ROSETTA_DEBUGSERVER_PORT=1234 ./binary

then attaching to it from within GDB with target remote :1234.

I’ve read in multiple places that the GDB stub works fine and that they use it daily to build Space-X software and cure cancer and whatnot. Spoiler alert: it did not work.

GDB crashed with a backtrace and the binary crashed with an error of an unimplemented functionality in the GDB stub. Trying GDB by itself worked, but using pwndbg or GEF caused the same issue. And there is no chance I’m using vanilla GDB, I’m not an IoT researcher..

I ended up tracing this issue in pwndbg and creating a shitty patch just to make it work.

Okay we have GDB! Let’s try debugging… it takes 10 seconds to single-step.

This is an issue with vanilla GDB as well, not as severe but still unusable. my guess is that the GDB server implementation is just too slow, and since pwndbg displays all the register and stack information with every step it takes even longer to communicate that data. I can’t do anything about that..

I’ve also tried to set up an Ubuntu ARM VM with Parallels and see how Rosetta performs there, but it was basically the same problem.

I’m still confused on how people call this “usable”, maybe it’s actually doable and these are just problems on my machine? Please let me know if you can get GDB to work with Rosetta without the latency problems.

Michaelsoft Binbows

Okay that was a rough start and I don’t wanna deal with Linux anymore, so let’s move forward to Windows. Sergei said this setup works well enough and he would never lie to me.

The idea is to install Windows 11 ARM in Parallels. Windows ARM has a built-in translation layer from x86-64 to ARM, the same way WOW64 runs x86 binaries on x86-64. Think of it as Rosetta but better.

While scrolling up through OALabs Discord server I’ve seen some people saying that debugging is sometimes scuffed and jumps around, so uuhhh hopefully we don’t run into that?

Whisky

Whisky was my last hope for Windows. it uses some wine+Rosetta magic to run Windows binaries.

I tried running both IDA Pro and x64dbg through Whisky and ran into the same problem with both. the execution will randomly stop and the debugger UI will freeze until you kill the debugged process. This also feels like a problem on my machine that can be fixed by messing with wine settings, so it’s worth a try if you’re following this as a guide.

CrossOver also has the same problem which proves money can’t buy happiness.

Linux Episode IV: A New Hope

As a Hail Mary, I decided to try running a Linux x86-64 virtual machine. I used UTM which is based on QEMU, so hopefully the JIT and nerd optimizations combined with using a minimal distro and DE can make it usable?

As a matter of fact it did! Don’t expect to run CyberPunk 2077 on it, but running Arch Linux with XFCE is usable! To squeeze more performance, I installed an SSH server on the VM and disabled GUI. Now I can connect into the VM from my terminal and use tmux, GDB, and all the nice things I need, with an option to enable GUI when necessary.

Success!

The Windows Situation

Figuring out the Linux part filled me with determination, so I decided to give Windows another shot.

My first attempt was doing the same thing I did with Linux. Setting up an x86-64 virtual machine. But that was cut short by how bad the performance was. Opening explorer.exe took about 5 seconds, you can guess the rest.

Windows 11 ARM is our only hope if we’re gonna get this to work so let’s try fixing the problems we had previously.