macOS Apps - Inspecting, debugging and Fuzzing
WhiteIntel is a dark-web fueled search engine that offers free functionalities to check if a company or its customers have been compromised by stealer malwares.
Their primary goal of WhiteIntel is to combat account takeovers and ransomware attacks resulting from information-stealing malware.
You can check their website and try their engine for free at:
Static Analysis
otool
objdump
jtool2
The tool can be used as a replacement for codesign, otool, and objdump, and provides a few additional features. Download it here or install it with brew
.
Codesign / ldid
Codesign
can be found in macOS while ldid
can be found in iOS
SuspiciousPackage
SuspiciousPackage is a tool useful to inspect .pkg files (installers) and see what is inside before installing it.
These installers have preinstall
and postinstall
bash scripts that malware authors usually abuse to persist the malware.
hdiutil
This tool allows to mount Apple disk images (.dmg) files to inspect them before running anything:
It will be mounted in /Volumes
Objective-C
Metadata
Note that programs written in Objective-C retain their class declarations when compiled into Mach-O binaries. Such class declarations include the name and type of:
The class
The class methods
The class instance variables
You can get this information using class-dump:
Note that this names could be obfuscated to make the reversing of the binary more difficult.
Function calling
When a function is called in a binary that uses objective-C, the compiled code instead of calling that function, it will call objc_msgSend
. Which will be calling the final function:
The params this function expects are:
The first parameter (self) is "a pointer that points to the instance of the class that is to receive the message". Or more simply put, it’s the object that the method is being invoked upon. If the method is a class method, this will be an instance of the class object (as a whole), whereas for an instance method, self will point to an instantiated instance of the class as an object.
The second parameter, (op), is "the selector of the method that handles the message". Again, more simply put, this is just the name of the method.
The remaining parameters are any values that are required by the method (op).
See how to get this info easily with lldb
in ARM64 in this page:
x64:
Swift
With Swift binaries, since there is Objective-C compatibility, sometimes you can extract declarations using class-dump but not always.
With the jtool -l
or otool -l
command lines it's possible ti find several sections that start with __swift5
prefix:
You can find further information about the information stored in these section in this blog post.
Moreover, Swift binaries might have symbols (for example libraries need to store symbols so its functions can be called). The symbols usually have the info about the function name and attr in a ugly way, so they are very useful and there are "demanglers" that can get the original name:
Packed binaries
Check for high entropy
Check the strings (is there is almost no understandable string, packed)
The UPX packer for MacOS generates a section called "__XHDR"
Dynamic Analysis
Note that in order to debug binaries, SIP needs to be disabled (csrutil disable
or csrutil enable --without debug
) or to copy the binaries to a temporary folder and remove the signature with codesign --remove-signature <binary-path>
or allow the debugging of the binary (you can use this script)
Note that in order to instrument system binaries, (such as cloudconfigurationd
) on macOS, SIP must be disabled (just removing the signature won't work).
Unified Logs
MacOS generates a lot of logs that can be very useful when running an application trying to understand what is it doing.
Moreover, the are some logs that will contain the tag <private>
to hide some user or computer identifiable information. However, it's possible to install a certificate to disclose this information. Follow the explanations from here.
Hopper
Left panel
In the left panel of hopper it's possible to see the symbols (Labels) of the binary, the list of procedures and functions (Proc) and the strings (Str). Those aren't all the strings but the ones defined in several parts of the Mac-O file (like cstring or objc_methname
).
Middle panel
In the middle panel you can see the dissasembled code. And you can see it a raw disassemble, as graph, as decompiled and as binary by clicking on the respective icon:
Right clicking in a code object you can see references to/from that object or even change its name (this doesn't work in decompiled pseudocode):
Moreover, in the middle down you can write python commands.
Right panel
In the right panel you can see interesting information such as the navigation history (so you know how you arrived at the current situation), the call graph where you can see all the functions that call this function and all the functions that this function calls, and local variables information.
dtrace
It allows users access to applications at an extremely low level and provides a way for users to trace programs and even change their execution flow. Dtrace uses probes which are placed throughout the kernel and are at locations such as the beginning and end of system calls.
DTrace uses the dtrace_probe_create
function to create a probe for each system call. These probes can be fired in the entry and exit point of each system call. The interaction with DTrace occur through /dev/dtrace which is only available for the root user.
To enable Dtrace without fully disabling SIP protection you could execute on recovery mode: csrutil enable --without dtrace
You can also dtrace
or dtruss
binaries that you have compiled.
The available probes of dtrace can be obtained with:
The probe name consists of four parts: the provider, module, function, and name (fbt:mach_kernel:ptrace:entry
). If you not specifies some part of the name, Dtrace will apply that part as a wildcard.
To configure DTrace to activate probes and to specify what actions to perform when they fire, we will need to use the D language.
A more detailed explanation and more examples can be found in https://illumos.org/books/dtrace/chp-intro.html
Examples
Run man -k dtrace
to list the DTrace scripts available. Example: sudo dtruss -n binary
In line
script
dtruss
ktrace
You can use this one even with SIP activated
ProcessMonitor
ProcessMonitor is a very useful tool to check the process related actions a process is performing (for example, monitor which new processes a process is creating).
SpriteTree
SpriteTree is a tool to prints the relations between processes.
You need to monitor your mac with a command like sudo eslogger fork exec rename create > cap.json
(the terminal launching this required FDA). And then you can load the json in this tool to viwe all the relations:
FileMonitor
FileMonitor allows to monitor file events (such as creation, modifications, and deletions) providing detailed information about such events.
Crescendo
Crescendo is a GUI tool with the look and feel Windows users may know from Microsoft Sysinternal’s Procmon. This tool allows the recording of various event types to be started and stopped, allows for the filtering of these events by categories such as file, process, network, etc., and provides the functionality to save the events recorded in a json format.
Apple Instruments
Apple Instruments are part of Xcode’s Developer tools – used for monitoring application performance, identifying memory leaks and tracking filesystem activity.
fs_usage
Allows to follow actions performed by processes:
TaskExplorer
Taskexplorer is useful to see the libraries used by a binary, the files it's using and the network connections. It also checks the binary processes against virustotal and show information about the binary.
PT_DENY_ATTACH
In this blog post you can find an example about how to debug a running daemon that used PT_DENY_ATTACH
to prevent debugging even if SIP was disabled.
lldb
lldb is the de facto tool for macOS binary debugging.
You can set intel flavour when using lldb creating a file called .lldbinit
in your home folder with the following line:
Inside lldb, dump a process with process save-core
When calling the objc_sendMsg
function, the rsi register holds the name of the method as a null-terminated (“C”) string. To print the name via lldb do:
(lldb) x/s $rsi: 0x1000f1576: "startMiningWithPort:password:coreCount:slowMemory:currency:"
(lldb) print (char*)$rsi:
(char *) $1 = 0x00000001000f1576 "startMiningWithPort:password:coreCount:slowMemory:currency:"
(lldb) reg read $rsi: rsi = 0x00000001000f1576 "startMiningWithPort:password:coreCount:slowMemory:currency:"
Anti-Dynamic Analysis
VM detection
The command
sysctl hw.model
returns "Mac" when the host is a MacOS but something different when it's a VM.Playing with the values of
hw.logicalcpu
andhw.physicalcpu
some malwares try to detect if it's a VM.Some malwares can also detect if the machine is VMware based on the MAC address (00:50:56).
It's also possible to find if a process is being debugged with a simple code such us:
if(P_TRACED == (info.kp_proc.p_flag & P_TRACED)){ //process being debugged }
It can also invoke the
ptrace
system call with thePT_DENY_ATTACH
flag. This prevents a debugger from attaching and tracing.You can check if the
sysctl
orptrace
function is being imported (but the malware could import it dynamically)As noted in this writeup, “Defeating Anti-Debug Techniques: macOS ptrace variants” : “The message Process # exited with status = 45 (0x0000002d) is usually a tell-tale sign that the debug target is using PT_DENY_ATTACH”
Fuzzing
ReportCrash analyzes crashing processes and saves a crash report to disk. A crash report contains information that can help a developer diagnose the cause of a crash.
For applications and other processes running in the per-user launchd context, ReportCrash runs as a LaunchAgent and saves crash reports in the user's ~/Library/Logs/DiagnosticReports/
For daemons, other processes running in the system launchd context and other privileged processes, ReportCrash runs as a LaunchDaemon and saves crash reports in the system's /Library/Logs/DiagnosticReports
If you are worried about crash reports being sent to Apple you can disable them. If not, crash reports can be useful to figure out how a server crashed.
Sleep
While fuzzing in a MacOS it's important to not allow the Mac to sleep:
systemsetup -setsleep Never
pmset, System Preferences
SSH Disconnect
If you are fuzzing via a SSH connection it's important to make sure the session isn't going to day. So change the sshd_config file with:
TCPKeepAlive Yes
ClientAliveInterval 0
ClientAliveCountMax 0
Internal Handlers
Checkout the following page to find out how you can find which app is responsible of handling the specified scheme or protocol:
Enumerating Network Processes
This interesting to find processes that are managing network data:
Or use netstat
or lsof
Libgmalloc
Fuzzers
Works for CLI tools
It "just works" with macOS GUI tools. Note some some macOS apps have some specific requirements like unique filenames, the right extension, need to read the files from the sandbox (~/Library/Containers/com.apple.Safari/Data
)...
Some examples:
More Fuzzing MacOS Info
References
WhiteIntel is a dark-web fueled search engine that offers free functionalities to check if a company or its customers have been compromised by stealer malwares.
Their primary goal of WhiteIntel is to combat account takeovers and ransomware attacks resulting from information-stealing malware.
You can check their website and try their engine for free at:
Last updated