Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 14:08:26 +00:00
Code Issues Projects Releases Packages Wiki Activity

GITBOOK-4344: No subject

Browse source
This commit is contained in:
CPol 2024-05-27 14:56:49 +00:00 • committed by gitbook-bot
parent 207b2007b9
commit b0cb2370f0
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
1 changed files with 74 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

75
macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md
View file

@ -215,6 +215,31 @@ Note that in order to debug binaries, **SIP needs to be disabled** (`csrutil dis
Note that in order to **instrument system binaries**, (such as `cloudconfigurationd`) on macOS, **SIP must be disabled** (just removing the signature won't work).
{% endhint %}
### APIs
macOS exposes some interesting APIs that give information about the processes:
* `proc_info`: This is the main one giving a lot of information about each process. You need to be root to get other processes information but you don't need special entitlements or mach ports.
* `libsysmon.dylib`: It allows to get information about processes via XPC exposed functions, however, it's needed to have the entitlement `com.apple.sysmond.client`.
### Stackshot & microstackshots
**Stackshotting** is a technique used to capture the state of the processes, including the call stacks of all running threads. This is particularly useful for debugging, performance analysis, and understanding the behavior of the system at a specific point in time. On iOS and macOS, stackshotting can be performed using several tools and methods like the tools **`sample`** and **`spindump`**.
### Sysdiagnose
This tool (`/usr/bini/ysdiagnose`) basically collects a lot of information from your computer executing tens of different commands such as `ps`, `zprint`...
It must be run as **root** and the daemon `/usr/libexec/sysdiagnosed` has very interesting entitlements such as `com.apple.system-task-ports` and `get-task-allow`.
Its plist is located in `/System/Library/LaunchDaemons/com.apple.sysdiagnose.plist` which declares 3 MachServices:
* `com.apple.sysdiagnose.CacheDelete`: Deletes old archives in /var/rmp
* `com.apple.sysdiagnose.kernel.ipc`: Special port 23 (kernel)
* `com.apple.sysdiagnose.service.xpc`: User mode interface through `Libsysdiagnose` Obj-C class. Three arguments in a dict can be passed (`compress`, `display`, `run`)
### Unified Logs
MacOS generates a lot of logs that can be very useful when running an application trying to understand **what is it doing**.
@ -331,14 +356,52 @@ dtruss -c ls #Get syscalls of ls
dtruss -c -p 1000 #get syscalls of PID 1000
```
### kdebug
It's a kernel tracing facility. The documented codes can be found in **`/usr/share/misc/trace.codes`**.
Tools like `latency`, `sc_usage`, `fs_usage` and `trace` use it internally.
To interface with `kdebug` `sysctl` is used over the `kern.kdebug` namespace and the MIBs to use can be found in `sys/sysctl.h` having the functions implemented in `bsd/kern/kdebug.c`.
To interact with kdebug with a custom client these are usually the steps:
* Remove existing settings with KERN\_KDSETREMOVE
* Set trace with KERN\_KDSETBUF and KERN\_KDSETUP
* Use KERN\_KDGETBUF to get number of buffer entries
* Get the own client out of the trace with KERN\_KDPINDEX
* Enable tracing with KERN\_KDENABLE
* Read the buffer calling KERN\_KDREADTR
* To match each thread with its process call KERN\_KDTHRMAP.
In order to get this information it's possible to use the Apple tool **`trace`** or the custom tool [kDebugView (kdv)](https://newosxbook.com/tools/kdv.html)**.**
**Note that Kdebug is only available for 1 costumer at a time.** So only one k-debug powered tool can be executed at the same time.
### ktrace
The `ktrace_*` APIs come from `libktrace.dylib` which wrap those of `Kdebug`. Then, a client can just call `ktrace_session_create` and `ktrace_events_[single/class]` to set callbacks on specific codes and then start it with `ktrace_start`.
You can use this one even with **SIP activated**
You can use as clients the utility `ktrace`:
```bash
ktrace trace -s -S -t c -c ls | grep "ls("
```
Or `tailspin`.
### kperf
This is used to do a kernel level profiling and it's built using `Kdebug` callouts.
Basically, the global variable `kernel_debug_active` is checked and is set it calls `kperf_kdebug_handler` withe `Kdebug` code and address of the kernel frame calling. If the `Kdebug` code matches one selected it gets the "actions" configured as a bitmap (check `osfmk/kperf/action.h` for the options).
Kperf has a sysctl MIB table also: (as root) `sysctl kperf`. These code can be found in `osfmk/kperf/kperfbsd.c`.
Moreover, a subset of Kperfs functionality resides in `kpc`, which provides information about machine performance counters.
### ProcessMonitor
[**ProcessMonitor**](https://objective-see.com/products/utilities.html#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).
@ -346,7 +409,7 @@ ktrace trace -s -S -t c -c ls | grep "ls("
### SpriteTree
[**SpriteTree**](https://themittenmac.com/tools/) 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:
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 view all the relations:
<figure><img src="../../../.gitbook/assets/image (1182).png" alt="" width="375"><figcaption></figcaption></figure>
@ -430,6 +493,16 @@ When calling the **`objc_sendMsg`** function, the **rsi** register holds the **n
* As noted in this writeup, “[Defeating Anti-Debug Techniques: macOS ptrace variants](https://alexomara.com/blog/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**_”
## Core Dumps
Core dumps are created if:
* `kern.coredump` sysctl is set to 1 (by default)
* If the process wasn't suid/sgid or `kern.sugid_coredump` is 1 (by default is 0)
* The `AS_CORE` limit allows the operation. It's possible to suppress code dumps creation by calling `ulimit -c 0` and re-enable them with `ulimit -c unlimited`.
In those cases the core dumps is generated according to `kern.corefile` sysctl and stored usually in `/cores/core/.%P`.
## Fuzzing
### [ReportCrash](https://ss64.com/osx/reportcrash.html)