When reverse engineering macOS binaries that are written in Objective-C, class-dump is a common tool used to extract Objective-C declarations from the runtime information stored in the Mach-O files. With Swift binaries, since there is Objective-C compatability, sometimes you can extract declarations using class-dump but not always. Swift has a rich set of type metadata itself but the documentation is not up to date. With Swift 5 bringing ABI stability I thought it would be interesting to take a look at the type of metadata availble in Swift binaries.
Recently while looking into the Apple
adid daemon, I noticed that I couldn’t attach to the process with
lldb even if SIP was completely disabled. After digging into it a little bit I came to the conclusion that
adid was calling the
ptrace API passing in
PT_DENY_ATTACH. There are numerous other posts out there (like this one) that talk about defeating
PT_DENY_ATTACH if you’re running the application yourself. In my case
adid is started as a LaunchDaemon and is already running by the time a user is logged in. I decided to take a look at how you could defeat the
ptrace call even after the application is already running.
LLDB has great Python support but it’s not always clear what functionality is there or how to use it. While there is documentation on all of the classes available to scripts, some classes and methods are better documented than others. While looking for the best way to trace through some obfuscated assembly recently I came across the
thread step-scripted command and thought it would be worth writing up a short overview of what it is and how to use it.
In the previous post we looked at different ways to inject code into tasks on macOS. The goal being to create increased awareness of the type of methods attackers writing malicious code on macOS might use. In this post I wanted to focus in on the same issue of code injection but from a defenders point of view.