|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "ASLR"
(→Kernel space ASLR - updated with example) |
(→Kernel space ASLR) |
||
| Line 22: | Line 22: | ||
* Disassembly is somewhat harder. Rather than store addresses of symbols and strings at the end of each function (DCD), the symbols/string offsets with respect to PC are now hardcoded in the instructions themselves, and need to be calculated. For Example: |
* Disassembly is somewhat harder. Rather than store addresses of symbols and strings at the end of each function (DCD), the symbols/string offsets with respect to PC are now hardcoded in the instructions themselves, and need to be calculated. For Example: |
||
| + | <pre> |
||
| − | __text:80006AA0 MOV R0, 0x27EF0E |
||
| − | __text: |
+ | __text:80046F50 loc_80046F50 ; CODE XREF: sub_80046F1C+C�j |
| − | __text: |
+ | __text:80046F50 MOV R0, 0x240BEA |
| + | __text:80046F58 ADD R0, PC ; char * |
||
| + | __text:80046F5A BL _panic |
||
| + | __text:80046F5E MOV R0, R4 |
||
| + | __text:80046F60 POP {R4,R7,PC} |
||
| + | __text:80046F60 ; End of function sub_80046F1C |
||
| + | And, as can be expected: |
||
| + | string:80287B24 aDf_memory_object_data_reclaimN DCB 0x22,"df_memory_object_data_reclaim\n",0x22,0 |
||
| + | (so sub_80046F1C is df_memory_object_data_reclaim) |
||
| − | __cstring:802859BA aBadDpMemoryObj DCB 0x22,"bad dp memory object",0x22,0 |
||
| + | </pre> |
||
Revision as of 11:30, 12 June 2012
ASLR (Address Space Layout Randomization) is a form of data security used to randomize data on the Template:Wp to help prevent exploits from taking control of the system. It first appeared in Template:Wp.
Program and dyld
- On program load, the address space offset of the program is randomized between 0x0 and 0x100000
- It always falls on a 0x1000 page boundary
- dyld is included in this sliding section
Kernel space ASLR
Mountain Lion boasts a xnu 2150 kernel, which includes, for the first time, ASLR in kernel space. Because OS X and iOS are so closely tied together, as previously surmised here, iOS 6 indeed includes ASLR.
In reply to i0nic, this is the lowdown of ASLR:
- When the kernel boots, i386_vm_init (iOS: arm_vm_init) initializes the value of vm_kernel_slide
- The kernel supports a new system call (#439 on Mountain Lion, likely #440 on iOS 6), called kas_info. This will return the value of vm_kernel_slide, but only for a privileged process.
- kld is updated to reflect the slide in symbols. Likewise OSKext::LoadExecutable and friends
- stackshot and other kernel functions take the vm_kernel_slide into consideration and subtract it from the actual positions of functions/symbols.
- Disassembly is somewhat harder. Rather than store addresses of symbols and strings at the end of each function (DCD), the symbols/string offsets with respect to PC are now hardcoded in the instructions themselves, and need to be calculated. For Example:
__text:80046F50 loc_80046F50 ; CODE XREF: sub_80046F1C+C�j
__text:80046F50 MOV R0, 0x240BEA
__text:80046F58 ADD R0, PC ; char *
__text:80046F5A BL _panic
__text:80046F5E MOV R0, R4
__text:80046F60 POP {R4,R7,PC}
__text:80046F60 ; End of function sub_80046F1C
And, as can be expected:
string:80287B24 aDf_memory_object_data_reclaimN DCB 0x22,"df_memory_object_data_reclaim\n",0x22,0
(so sub_80046F1C is df_memory_object_data_reclaim)
An upcoming book on OS X/iOS internals discusses this in detail.
- The system libraries are now stored in a big cache file, see
- This address randomized at boot time, in many possible places, higher in the address space than the program
- The functions retain a fixed offset to each other.
External Links
- Template:Wp on Wikipedia
- ASLR in the dyld on the iPhone Dev Wiki
