It supports ARMv8.3
Why should you care? If you're a developer, that gives you Javascript floats in an ARM assembly instruction. Something you could likely have lived without. But exploiters/jailbreakers are going to find this a problem, because of ARM's Pointer Authentication Codes (PAC).
As explained in this https://www.qualcomm.com/documents/whitepaper-pointer-authentication-armv83 great white paper by QCom, this involves new instructions - AUTIA/PACIA - and their variants. PACIA generate an auth code in the pointer high bits, and AUTIA authenticates it before use. Since it's cumbersome to add these instructions, they have been built-in to new patterns, notably RET (now RETAA or RETAB) and LDR (now LDRAA/LDRAB). These enable the use of two keys (accessible in EL1, kernel, but not in EL0, user) of which Apple seems to be using one (A) to authenticate the pointers and put the PAC in the high bits. The PAC can then be verified, and if the validation fails, the RETA* will fail as well - meaning an end to ROP/JOP. The instructions are a drop in replacement to the original. Compare from iPhone10:
- Code: Select all
___stack_chk_fail:
fffffff0070e97f0 STP X29, X30, [SP, #-16]! ; *(SP + 0xfffffffffffffff0) = 0x0
fffffff0070e97f4 ADD X29, SP, #0 ; R29 = SP+0x0
fffffff0070e97f8 ADR X0, #-770388 ""Kernel stack memory corruption detected"" ; ->R0 = 0xfffffff00702d6a4
fffffff0070e97fc NOP ;
fffffff0070e9800 BL _panic ; 0xfffffff007112224
_panic("Kernel stack memory corruption detected");
fffffff0070e9804 LDP X29, X30, [SP],#16 ;
fffffff0070e9808 RET ;
to iPhone 11
- Code: Select all
_func_fffffff007a09870:
fffffff007a09870 0xd503237f NOP ;
fffffff007a09874 0xa9bf7bfd STP X29, X30, [SP, #-16]! ;
fffffff007a09878 0x910003fd ADD X29, SP, #0 ; R29 = R31 + 0x0
fffffff007a0987c 0xb0ffd3e0 ADRP X0, 2095741 ; R0 = 0xfffffff007486000
fffffff007a09880 0x912e7000 ADD X0, X0, #2972 ; R0 = R0 + 0xb9c = 0xfffffff007486b9c
fffffff007a09884 0x9400e956 BL 0xfffffff007a43ddc ;
_func_fffffff007a43ddc(""Kernel stack memory corruption detected"",?,?,?,?,?,?,?);
fffffff007a09888 0xa8c17bfd LDP X29, X30, [SP],#16 ;
fffffff007a0988c 0xd65f0fff RETAA ;
and
- Code: Select all
fffffff007136080 ADD X1, X1, #1308 "com.apple.private.personas.propagate"; X1 = 0xfffffff00703151c -|
fffffff007136084 MOV X0, X19 ; --X0 = X19 = 0x0
fffffff007136088 BL __ZN12IOUserClient21copyClientEntitlementEP4taskPKc ; 0xfffffff0075efd8c
fffffff00713608c MOV X21, X0 ; --X21 = X0 = 0x0
if (R21 == 0) then goto 0xfffffff0071360c0
fffffff007136090 CBZ X21, 0xfffffff0071360c0 ;
fffffff007136094 LDR X8, [X21, #0] ; -R8 = *(R21 + 0) = .. *(0x0, no sym) = 0x100000cfeedfacf ... (null)?..
fffffff007136098 LDR X8, [X8, #40] ; -R8 = *(R8 + 40) = .. *(0x100000cfeedfaf7, no sym) = 0x100000cfeedfacf ... (null)?..
fffffff00713609c MOV X0, X21 ; --X0 = X21 = 0x0
fffffff0071360a0 BLR X8 ; 0x100000cfeedfacf
to
- Code: Select all
fffffff007ad3a7c 0x941804f9 BL 0xfffffff0080d4e60 ;
_func_fffffff0080d4e60(ARG0,"com.apple.private.personas.propagate");
fffffff007ad3a80 0xaa0003f5 MOV X21, X0 ;
fffffff007ad3a84 0xb40001b5 CBZ X21, 0xfffffff007ad3ab8 ;
fffffff007ad3a88 0xf94002a8 LDR X8, [X21, #0] ; _R8 = *(R21 + 0) = *0x0
fffffff007ad3a8c 0xf8205d09 LDRAA X9, [X8, #8]! ;
fffffff007ad3a90 0xf2e750e8 MOVK X8, 0x3a87, LSL 48 ; R8 += 0x3a87000000000000
fffffff007ad3a94 0xaa1503e0 MOV X0, X21 ;
fffffff007ad3a98 0xd73f0928 BLRAA X8 ;
Does that mean the end of exploitation? No. There's still UAFs and type confusions. But couple that with CoreTrust, which now accepts only code signatures with a CMS (certificate blob) and chain leading to Apple, and that spells the end of jtool --sign (or ldid -S, to some). Meaning you'd have to sign the entire bin pack with your dev cert - a real pain.
The other annoyance is that now iPhoneXs is 11,#... Why they fall out of model->marketing name sync after managing to catch up, eludes me
Oh, and - Another oddity is that now the iphone11 uses a 1469 kernel cache. What's that? the term refers to the AAPL engineer building the kernel caches (yes, YOU, reader from 17.x.x.x!) forgetting to set RC_ProjectSourceVersion to the right version of XNU (4900.200+something) and thus leaving XNU's LC_SOURCE_VERSION as 1469.something. This also means ZERO symbols . jtool -S, or nm -m or whatever - there are no symbols. But it's a minor annoyance - because joker2 is going to get all those symbols (and more!) back.
There's some good news - I've updated joker2 (coming soon), jtool2 (now in beta) and disarm to support all these instructions (beating IDA to ARM64 enhancements, again
. But otherwise this is serious news that I think people should know about. So now you do.EDIT (09/17) I forgot APRR as well. That's a counterpart to KTRR which only exists in the A12, so must be implemented in hardware. I believe (but not certain) it's behind vm_map_exec_lockdown() - I'll verify the flow when I have the chance and joker2 is updated for MIG calls (because otherwise you can't find the vm_map symbols anymore...). It's certainly connected to PINST (protected instructions) and is invoked on CPU start (past hibernation, to thwart people like Luca), but I need to dig deeper.
