Setting Up an x86_64 Reversing Environment in Kali on an M1 MacBook with VMWare Fusion
There is a tl;dr at the bottom if you need just the instructions. Keep reading if you are into the whole story of how I figured this out. Trust me, it's fascinating.
The Entry of Kali on M1
In 2020, when Apple launched its "M-Series" MacBooks with incredible metrics like performance, battery life, and just the general UX, I finally bought one in November 2022. However, the only issue was that this is an ARM machine, so binary analysis of x86_64 would be a pain. But I thought I would deal with it later (I was not doing much pen-testing at this point due to some other things in life).
Long story short, I finally got a chance in April this year to start my journey again, and after looking around for some time, I settled on VMWare Fuson, and this is where our story begins.
Installing Kali on VMWare is pretty straightforward: you download the Apple Silicon installer image from Kali, create a new VM in Fusion, select this installer image, go through the VM setup, and install Kali.
The main problem is that this is the ARM version of Kali, so you can't run x86_64 binaries in this one, and this guide shows you how.
The Objective
To run x86_64 binaries on ARM, you need
- An emulator
- Supporting binary support and libraries
Thankfully, the team at Kali has put together a guide to install the things required. In short, you need to run the following commands.
kali@thuderdome:~$ sudo dpkg --add-architecture amd64 # add AMD64 packages to APT
kali@thunderdome:~$ sudo apt update
kali@thunderdome:~$ sudo apt install -y qemu-user-static binfmt-support # install standalone QEMU emulator to run binaries from other architecture
kali@thunderdome:~$ sudo apt install libc6:amd64 # install amd64 system librariesNow comes the tricky part.
How do you compile code to x86_64 binary??
This should be simple. There is a multi-architecture version of GCC called gcc-multilib.
And that's when shit hit the fan.
Did you notice what happened?
Don't worry, I didn't either.
I installed it and compiled a C program to print Hello World, and it worked!!
With that success, I shut down the VM and went to sleep (it was 3 in the morning by then, and these things eat a lot of time).
Insanity is doing the same thing over and over and expecting different results.
The following day, I started the VM, entered the login credentials, and the VM background just froze. I knew something was wrong.
Honestly, this is not the first time a Kali install has given me the middle finger. I faced so many issues with Kali for many years; at this point, it was just tradition. Plus, I messed with the home and boot partitions a bit last night, and I thought it had something to do with that.
So I rebooted the VM into recovery mode, logged in as root in the terminal, and switched the user to my regular one, and everything went fine. This should not happen if there were an issue with the partitions, so something else was causing the mischief here.
I wrestled with this for some time, finally gave up, deleted the VM, created a new one, and installed everything again, and guess what? The same issue on reboot.
Finally, I gave up on Kali (for I forgot how many times at this point) and installed Parrot Sec.
The Wise Parrot
Installing Parrot OS is the same, except it takes much longer than Kali and looks worse. Setting up the x86_64 libs was straightforward, too, and it followed the same steps as the above.
The default display resolutions of these VMs are atrocious on Mac, and you have to change them to something sane every time. The settings manager, called "Control Center," has the display settings in Parrot.
After I installed gcc-multilib, I found something fishy.
Notice the option for Control Center before I installed gcc-multilib.
That's gone.
And that's when I looked closely at what this command was doing.
This command deleted the control center, settings-daemon, and the whole x11-server, the display server drawing the GUI!!!
Thankfully, I found another package, gcc-x86-64-linux-gnu, which provides a cross-compiler and doesn't bork the display server.
The Final Showdown
Parrot is fine, but why settle for less if you can use Kali?
So I created a new, final VM, installed Kali on it, set up the x86_64 tooling, and am finally left with the GCC compiler.
I typed in the infernal command and saw this.
This thing deleted not just the desktop environment but also, god knows what, other important stuff. It's no wonder the VM hung on login without these.
So I installed the excellent cousin of this package (gcc-x86-64-linux-gnu), and everything started working great.
TL;DR
Here are the commands that install everything necessary to compile, run, and debug x86_64 binaries in the ARM version of Kali.
kali@thunderdome:~$ sudo dpkg --add-architecture amd64 # add AMD64 packages to APT
kali@thunderdome:~$ sudo apt update
kali@thunderdome:~$ sudo apt install -y qemu-user-static binfmt-support # install standalone QEMU emulator to run binaries from other architecture
kali@thunderdome:~$ sudo apt install libc6:amd64 # install amd64 system libraries
kali@thunderdome:~$ sudo apt install gcc-x86-64-linux-gnu # install gcc cross-compiler to compile code to x86_64
kali@thunderdome:~$ sudo apt install gdb-multiarch # install GNU Debugger with x86_64 support