debugging x86_64 elf on mac silicon
how to debug x86_64 elf(linux) binaries on mac silicon(m series)
apple silicon is ARM. x86_64 ELF binaries are linux/intel. there is no native path — rosetta 2 translates mach-o x86_64, not ELF, and lldb on macOS cannot attach to ELF targets regardless.
the only correct approach is a real x86_64 environment.
lima
run an x86_64 linux vm with lima.
brew install lima qemu
limactl start --arch=x86_64 --vm-type=qemuaccess it with lima, then use gdb normally inside the vm.
note: lima uses QEMU TCG (software emulation) for non-native architectures. Apple's Hypervisor framework only accelerates native ARM guests, so x86_64 emulation is slow. expect 5-10x slowdown compared to native. this is not a lima issue.
kali vm workaround
the normal kali iso and the kali vm image from kali.org don't work on lima.
the workaround: debian vm + kali tools on top.
kali.yaml:
vmType: "qemu"
os: "Linux"
arch: "x86_64"
images:
- location: "https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2"
arch: "x86_64"
cpus: 4
memory: "4GiB"
disk: "60GiB"
firmware:
legacyBIOS: false
mounts:
- location: "~"
writable: true
ssh:
localPort: 0
loadDotSSHPubKeys: true
containerd:
system: false
user: false
provision:
- mode: system
script: |
#!/bin/bash
set -eux -o pipefail
export DEBIAN_FRONTEND=noninteractive
apt update
apt upgrade -y
apt install -y gnupg2 apt-transport-https
echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" > /etc/apt/sources.list.d/kali.list
wget -q -O - https://archive.kali.org/archive-key.asc | gpg --dearmor > /etc/apt/trusted.gpg.d/kali-archive-keyring.gpg
apt update
apt install -y kali-linux-corelimactl start kali.yaml
limactl shell kalioptional kali toolset install:
kali-linux-headless— no-gui toolskali-linux-default— default toolskali-linux-everything— all toolskali-tools-reverse-engineering— re tools only
alternatives
utm — if you want a gui. same underlying QEMU performance as lima. easier for multiple vms.
gdbserver — run gdbserver inside the vm, connect from a gdb client on the host. faster iteration than shelling into the vm every time.