\documentclass{article} \usepackage[utf8]{inputenc} \usepackage{hyperref} \usepackage{enumitem}
\title{Whonix-on-M-Series: Bridging the Privacy Gap for Apple Silicon} \author{Michael yoseph} \date{April 2026}
\begin{document}
\maketitle
\section{Inspiration} Whonix is widely considered the gold standard for desktop anonymity, yet the official project currently lacks a production-ready build for Apple Silicon (M1/M2/M3/M4). As privacy-conscious users migrate to ARM-based Mac architecture, they are forced to choose between performance and the robust "Gateway-Workstation" isolation that Whonix provides. My goal for this CU Denver hackathon was to bridge this gap by creating a reproducible build process for UTM.
\section{What it Does} This project provides a functional, source-built implementation of Whonix optimized for the Apple Virtualization Framework via UTM. It utilizes a dual-VM architecture to ensure that no application on the Workstation can discover the user's real IP address or leak DNS queries.
\section{Technical Architecture} The system consists of two distinct Debian 12 (Bookworm) ARM64 virtual machines:
\subsection{The Whonix-Gateway (CLI-Optimized)} \begin{itemize} \item \textbf{Role:} Acts as a transparent Tor proxy. \item \textbf{Networking:} Configured with two virtual network interfaces. \textit{eth0} connects to the external NAT, while \textit{eth1} serves as the gateway for the internal isolated network. \item \textbf{Security:} Hardened kernel and \texttt{iptables} rules ensure only Tor traffic leaves the VM. \end{itemize}
\subsection{The Whonix-Workstation (GUI)} \begin{itemize} \item \textbf{Role:} The user's primary workspace. \item \textbf{Networking:} A single interface (\textit{eth0}) connected to the isolated internal network with its default gateway pointed at the Whonix-Gateway (\texttt{10.152.152.10}). \end{itemize}
\section{How I Built It} \begin{itemize} \item \textbf{Cross-Architecture Compilation:} To overcome local storage and thermal constraints on my Mac, I utilized a remote x64 NIPOGI Mini PC (16GB RAM) as a build server. \item \textbf{Derivative-Maker:} I leveraged the official \texttt{derivative-maker} tool with the \texttt{--arch arm64} and \texttt{--target utm} flags. \item \textbf{QEMU Emulation:} The build process used \texttt{qemu-user-static} to emulate ARM64 instructions during the Debian chroot phase, allowing an x64 host to output native ARM64 images. \item \textbf{Tailscale Integration:} I maintained a persistent RDP and SSH pipeline via Tailscale to sync the final \texttt{.utm.tar.gz} bundles from the build server back to my M1 Mac for testing. \end{itemize}
\section{Challenges I Overcame} \begin{itemize} \item \textbf{Storage Constraints:} Building an OS from source requires significant temporary overhead. Offloading the build to a remote server was essential. \item \textbf{Networking in UTM:} Unlike VirtualBox, UTM requires manual orchestration of host-only networks to prevent "clearnet" leaks. \item \textbf{CLI vs GUI:} Initially building the CLI flavor saved resources but required manual meta-package injection to enable the LXQt desktop environment for the Workstation. \end{itemize}
\section{What's Next} The next step is to automate the UTM metadata generation so that the network interfaces (Internal vs. NAT) are pre-configured upon import, removing the need for manual user setup and reducing the margin for human error.
\end{document}
Log in or sign up for Devpost to join the conversation.