By default, VMware listens on port 8864 on the localhost, so this is where we connect to. If we don’t specify the IP address or hostname, like here, it will connect to the localhost. The last command tells lldb which port the remote server is listening on. In the case of the kernel, we get about 400 new commands available to us. This is extremely useful, as these scripts typically extend the functionality of lldb. The second command will tell lldb to load any scripts found inside the symbol (dSYM) directories. This command is not strictly necessary, as lldb will search the /Library/Developer/KDKs path and any other which is indexed by Spotlight, but it can be still a good practice in case the search fails. The first command will tell lldb where to find the kernel symbols. Listing 4 – Starting LLBD with appropriate symbols (lldb) settings set target.load-script-from-symbol-file true (lldb) target create /Library/Developer/KDKs/KDK_10.15.4_19E287.kdk/System/Library/Kernels/kernel This can be accomplished with the following command on the guest VM: Before we do that however, we need to determine the build version we are interested in. Our first step is to download the Kernel Debug Kit (KDK) from Apple’s Developer Downloads. This is by far the easiest method we will see. We will start by debugging the original release version of the kernel, which is included by default on macOS. GUEST: macOS Catalina 10.15.4 with supplemental update.HOST: macOS Catalina 10.15.4 with supplemental update.
This blog post will describe a couple of setups that allow you to have SIP enabled while debugging. This creates a problem if we want to investigate the inner workings of macOS’s security mechanisms, since turning off SIP will also turn off most of the foundational security features of the operating system. There are many great posts describing how to set up kernel debugging between two machines, but all of them suggest that SIP (System Integrity Protection) should be disabled for kernel debugging. For macOS, however, the situation is slightly different. Doing so on the Windows platform is no mystery, as there have been countless well-written posts about kernel debugging setups.
As security researchers, we often find ourselves needing to look deep into various kernels to fully understand our target and accomplish our goals.
0 kommentar(er)
