> The shellcode would then disable memory protections like ASLR and DEP that normally prevent arbitrary code execution. This would allow the attacker to execute a ROP gadget chain or other payload to jailbreak the sandbox and run remote commands on the device.
This sounds like chicken - egg scenario. Can you clarify how original shellcode bypasses those protections?
DEP is a Windows implementation of a non-executable stack, i.e., memory permissions that do not allow execution on specific pages. Depending on the situation, an attacker can e.g., mmap() a new page with the execute permission set, write his shellcode there and jump there. Another way to bypass the NX bit is to actually use gadgets (snippets of code essentially) that are already there in the code thus they can be executed and redirect your instruction pointer to those addresses. Reusing code is generally known as ROP, JOP etc. and is mitigated by PAC for ARM (after v.8.3) and CFI for Intel (11th Gen onwards I believe).
That being said, Apple implements a ton of mitigations, both on a hardware level and on a software level which generally makes exploits on Apple devices interesting to analyze and see how they bypassed stuff.
Edit: For clarity, Apple requires both codesigning and implements PAC, among others. mmap'ing or ROP won't make the cut in this case.
This sounds like chicken - egg scenario. Can you clarify how original shellcode bypasses those protections?
I don’t think you can disable DEP on runtime.