Swift Reversing in 2024 - It's Not So Bad :)

Chris Lopez opens by explaining why reverse engineers need to be comfortable with Swift. The language dates to 2014 and has had a stable ABI since Swift 5, and macOS malware written in Swift, including recent info stealers and spyware, is becoming more common. He notes that Swift symbols are mangled but that existing decompiler plugins can demangle them, and that much of the standard library and runtime is open source, which helps when working out how code behaves.

The middle of the talk covers the low-level details, using disassembly from recent Swift malware samples. On arm64, Swift passes self in register x20 rather than x0 as C++ and Objective-C do, and many tools get this wrong. Small strings are stored inline with a marker and a length, while large strings hold a pointer that must be offset by a native bias before the text can be read. Arrays begin with a metadata header, followed by an element count and then the elements. Static heap objects live inside the binary, structs lay out much like C structs, and Swift classes are backed by Objective-C class structures, so method offsets can be traced through metadata accessors. Type metadata and value witness tables, reached through negative offsets from a type's metadata pointer, round out the picture.

To make large strings easier to analyze, he showed a Binary Ninja script that resolves them and adds comments at the places where they are used. The main takeaway is that knowing these memory layouts and the calling convention lets an analyst follow what data flows where without guessing, which makes Swift samples far less intimidating.