GITBOOK-4329: No subject

macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md

@@ -1051,6 +1051,7 @@ For more info check:
 * [https://gist.github.com/knightsc/45edfc4903a9d2fa9f5905f60b02ce5a](https://gist.github.com/knightsc/45edfc4903a9d2fa9f5905f60b02ce5a)
 * [https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
 * [https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
+* [\*OS Internals, Volume I, User Mode, Jonathan Levin](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
 
 <details>
 

macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md

@@ -66,6 +66,11 @@ mig -header myipcUser.h -sheader myipcServer.h myipc.defs
 
 Several new files will be created in the current directory.
 
+{% hint style="success" %}
+You can find a more complex example in your system with: `mdfind mach_port.defs`\
+And you can compile it from the same folder as the file with: `mig -DLIBSYSCALL_INTERFACE mach_ports.defs`
+{% endhint %}
+
 In the files **`myipcServer.c`** and **`myipcServer.h`** you can find the declaration and definition of the struct **`SERVERPREFmyipc_subsystem`**, which basically defines the function to call based on the received message ID (we indicated a starting number of 500):
 
 {% tabs %}
@@ -122,7 +127,9 @@ mig_external mig_routine_t myipc_server_routine
 
 In this example we have only defined 1 function in the definitions, but if we would have defined more functions, they would have been inside the array of **`SERVERPREFmyipc_subsystem`** and the first one would have been assigned to the ID **500**, the second one to the ID **501**...
 
-Actually it's possible to identify this relation in the struct **`subsystem_to_name_map_myipc`** from **`myipcServer.h`**:
+If the function was expected to send a **reply** the function `mig_internal kern_return_t __MIG_check__Reply__<name>` would also exist.
+
+Actually it's possible to identify this relation in the struct **`subsystem_to_name_map_myipc`** from **`myipcServer.h`** (**`subsystem_to_name_map_***`** in other files):
 
 ```c
 #ifndef subsystem_to_name_map_myipc
@@ -167,7 +174,7 @@ Finally, another important function to make the server work will be **`myipc_ser
 
 Check the previously highlighted lines accessing the function to call by ID.
 
-In the following is the code to create a simple **server** and **client** where the client can call the functions Subtract from the server:
+The following is the code to create a simple **server** and **client** where the client can call the functions Subtract from the server:
 
 {% tabs %}
 {% tab title="myipc_server.c" %}
@@ -231,7 +238,19 @@ int main() {
 {% endtab %}
 {% endtabs %}
 
-### Binary Analysis
+### The NDR\_record
+
+The NDR\_record is exported by `libsystem_kernel.dylib`, and it's a struct that allows MIG to **transform data so it's agnostic of the system** it's being used as MIG was thought to be used between different systems (and not only in the same machine).
+
+This is interesting because if `_NDR_record` is found in a binary as a dependency (`jtool2 -S <binary> | grep NDR` or `nm`), it means that the binary is a MIG client or Server.
+
+Moreover **MIG servers** have the dispatch table in `__DATA.__const` (or in `__CONST.__constdata` in macOS kernel and `__DATA_CONST.__const` in other \*OS kernels). This can be dumped with **`jtool2`**.
+
+And **MIG clients** will use the `__NDR_record` to send with `__mach_msg` to the servers.
+
+## Binary Analysis
+
+### jtool
 
 As many binaries now use MIG to expose mach ports, it's interesting to know how to **identify that MIG was used** and the **functions that MIG executes** with each message ID.
 
@@ -241,6 +260,14 @@ As many binaries now use MIG to expose mach ports, it's interesting to know how
 jtool2 -d __DATA.__const myipc_server | grep MIG
 ```
 
+Moreover, MIG functions are just wrappers of the actual function that gets called, which means taht getting its dissasembly and grepping for BL you might be able to find the acatual function being called:
+
+```bash
+jtool2 -d __DATA.__const myipc_server | grep BL
+```
+
+### Assembly
+
 It was previously mentioned that the function that will take care of **calling the correct function depending on the received message ID** was `myipc_server`. However, you usually won't have the symbols of the binary (no functions names), so it's interesting to **check how it looks like decompiled** as it will always be very similar (the code of this function is independent from the functions exposed):
 
 {% tabs %}
@@ -370,6 +397,14 @@ Actually if you go to the function **`0x100004000`** you will find the array of
 
 This data can be extracted [**using this Hopper script**](https://github.com/knightsc/hopper/blob/master/scripts/MIG%20Detect.py).
 
+### Debug
+
+The code generated by MIG also calles `kernel_debug` to generate logs about operations on entry and exit. It's possible to check them using **`trace`** or **`kdv`**: `kdv all | grep MIG`
+
+## References
+
+* [\*OS Internals, Volume I, User Mode, Jonathan Levin](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
+
 <details>
 
 <summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>