Introduction to iBoot

The Kernel is not the first piece of code to run on a device - far from it. There is a great deal of setup and initialisation that is required before the kernel can be loaded; this is done by a piece of software called a “bootloader”.

On Apple devices the bootloader is given the name iBoot. This actually encompasses the ROM (Read-Only Memory), first and second stage boot loaders. All three of these are used for different levels of device initialisation.

Starting with the ROM, or more commonly known as the SecureROM. This is a very small piece of software that is burned into the Application Processor of Apple devices during their manufacturing, therefore it cannot be modified. This has it’s benefits and drawbacks, most notably that if a security vulnerability is found there is no way to fix it (see Checkra1n). The purpose of the SecureROM is very early device initialisation, such as enabling cpu cores, wakeup, choosing a boot device, then verifying if it’s valid and signed by Apple.

The SecureROM cannot load the kernel itself for a number of reasons. Firstly, the different stages of boot loaders can be executed at different “Exception Levels” (discussed later). Secondly, including too much functionality in the SecureROM exposes it to more vulnerabilities. Third, it is not feasible to run the kernel directly from boot because the kernel does so much and has such a wide scope. Issues in the kernel could cause the device to be unusable as there is no previous stage to recover it, e.g. restoring the device.

Now, this explanation is more specific to iOS devices. macOS works in a similar way - especially with the upcoming ARM-based Mac’s.

The next stage that is loaded after the SecureROM depends on the device. Apple devices with the A9 Application Processor and older first load the LLB, or Low-Level Bootloader. The LLB generally will cary out low-level SoC initialisation, console buffer setup, resuming the device if necessary, finding and subsequently loading an iBoot image. Failing that, LLB will fall back to DFU mode - which is out of the scope of this article.

For devices with the A10 and newer AP, the LLB is not used. Instead, the SecureROM directly loads the iBoot image.

iBoot is where we can really start getting into how things work. As we have already established, A9 and older devices will use LLB to load iBoot, and newer devices load iBoot directly from the SecureROM. This means more platform initialisation must be done at the SecureROM level. For reference, we are reversing an iBoot for the t8010 Application Processor.

Relocation Loop

First things first, when SecureROM jumps to iBoot we land in area of code referred to as the “Relocation Loop” which is responsible for relocating the iBoot image to a specified virtual address, providing it’s not already there. When disassembling an iBoot image with IDA, rebasing the image to 0x870000000 will present one with the Relocation Loop. Let’s have a look:

#   iBoot Relocation Loop.
0x870000000     _start:  
0x870000000         ADRP            X0, #_start             ; 
0x870000004         ADD             X0, X0, #_start         ; x0 = 0x870000000 = current page address
0x870000008         LDR             X1, =0x1800B0000        ; x0 = 0x1800B0000 = iBoot Load address
0x87000000C         BL              _platform_start         ; _platform_start(x0, x1) function.
0x870000010         CMP             X1, X0                  ; check if we are running at the desired address.
0x870000014         B.EQ            _continue_start         ; jmp to _continue_start
0x870000018         MOV             X30, X1                 ; set lr to iBoot load address.
0x87000001C         LDR             X2, =0x18010DD80        ; x2 = iboot end-of-img 
0x870000020         LDR             X3, =0x1800B0000        ; x3 = iboot start-of-img
0x870000024         SUB             X2, X2, X3              ; x2 = x2 - x3 = iboot-size
0x870000028     _copy_loop:                                         ; copy loop
0x870000028         LDP             X3, X4, [X0], #0x10     ;
0x87000002C         STP             X3, X4, [X1], #0x10     ;  
0x870000030         SUBS            X2, X2, #0x10           ;
0x870000034         B.NE            loc_870000028           ;
0x870000038         RET                                     ; returns to loading address, LR.

Although I’ve written notes beside instructions, let’s discuss this more clearly. When SecureROM loads iBoot it will land at the address 0x870000000, I have named this _start, which is the virtual address iBoot was loaded to by SecureROM. The idea here is to immediately load that address into x0, and then load the desired address of iBoot into x1. The aim is to then compare the two to check whether we are already running at the desired address. However, before that, a call to _platforn_start is made - I’ll discuss this in a moment.

Now we make that compare between x0 and x1. Notice the B.EQ instruction, this means that if the two register are equal, we would jump to _continue_start - this branch call would not return. Otherwise, iBoot will assume that we are not currently running from the desired address and therefore must fix that. The desired load address is copied into x30, otherwise known as lr or the Link Register, this register is used as the return-point when a ret call is made. iBoot will calculate it’s own size by loading the end-of-image address into x2, and the start-of-image address into x3, then subtracting x2 from x3 leaving the size of iBoot in x2. We’ll continue into the _copy_loop where it will loop round until the correct values are placed, then returns.


Now, back to that _platform_start call. This function is very low level and handles modifying control bits of Apple-specific System Registers. It’s difficult to read and understand what it’s doing, so we won’t stay on the topic for too long. _platform_start must preserve registers x0 and x1 as they have been assigned important values in _start.

#   _platform_start function called by _start for low-level system reg config.
0x870013C18     _platform_start:
                    // Enable the L2 cache load/store prefetcher.
0x870013C18         MRS             X2, #0, c15, c5, #0             ; read HID5, s3_0_c15_c5_0
0x870013C1C         AND             x2, x2, #0xFFFFCFFFFFFFFFFF     ;
0x870013C20         MSR             #0, c15, c5, #0, X2             ; write HID5
0x870013C24         ISB

0x870013C28         MRS             X2, #0, c15, c5, #0             ; read HID5
0x870013C2C         AND             X2, X2, #0xFFFFFFFFFFFF3FFF     ;
0x870013C30         ORR             X2, X2, #0x8000                 ;
0x870013C34         MSR             #0, c15, c5, #0, X2             ; write HID5
0x870013C38         MRS             X2, #0, c15, c5, #0             ; read HID5
0x870013C3C         ORR             X2, X2, #0x200000000000000      ;
0x870013C40         MSR             #0, c15, c5, #0, X2             ; write HID5

0x870013C44         MRS             X2, #0, c15, c11, #0            ; read HID11, s3_0_c15_c11_0
0x870013C48         ORR             X2, X2, #0x800000
0x870013C4C         MSR             #0, c15, c11, #0, X2            ; write HID11
0x870013C50         MRS             X2, #0, c15, c1, #0             ; read HID1, s3_0_c15_c1_0
0x870013C54         ORR             X2, X2, #0x100000000000
0x870013C58         MSR             #0, c15, c1, #0, X2             ; write HID1

0x870013C5C         CMP             X1, X0
0x870013C60         B.EQ            locret_870013C7C
0x870013C64         MRS             X2, #3, c15, c7, #0             ; read L2_CRAMCONFIG, s3_3_c15_c7_0
0x870013C68         ORR             X2, X2, #2
0x870013C6C         MSR             #3, c15, c7, #0, X2             ; write L2_CRAMCONFIG
0x870013C70     loc_870013C70
0x870013C70         MRS             X2, #3, c15, c7, #0             ; read L2_CRAMCONFIG
0x870013C74         AND             X2, X2, #0x8000000000000000
0x870013C78         CBZ             X2, loc_870013C70
0x870013C7C     locret_870013C7C 
0x870013C7C         RET

Here we have _platform_start. I’ll take this as a chance to explain these rather odd looking instruction sequences. Take the following instruction, mrs x2, #0, x15, c5, #0. This looks rather daunting, but from the outset we can simplify it to mrs x2, s3_0_c15_c5_0. These are what we call “System Registers” of which we can have Generic AArch64 registers, and Apple system registers. @bazad has a neat listing all all known Apple and AArch64 System Registers so we can grasp a rough idea of what these odd-looking operations do.

Now looking back at our code listing, take a look at the system registers we are working with. You’ll notice the pattern #0, c15, c5, #0 repeats three times, remember this can be translated to s3_0_c15_c5_0. So there are three operations being performed on the s3_0_c15_c5_0 system register, each time with it being written back before the next is performed. So what is s3_0_c15_c5_0? Looking it up in Bazad’s listing, we find it’s called HID5 with it’s use unknown. However, due to… an undisclosed source… we know that the first sequence is to “Enable the L2 cache load/store prefetcher”.

The only system register we know the name and use of is s3_3_c15_c7_0, named L2_CRAMCONFIG and described as being the “LSU Error Status” by Bazad.

After Relocation.

After the relocation code returns, the following is executed. This code will disable exceptions so the execution cannot be interrupted, setup the exception table base address, clear 16K of memory at a set base address, clear 96K of memory (for an unknown reason) at another given base address, setting the current and EL0 stack pointers, zero out additional space, and then clear both aligned and unaligned space.

#   See kpwn/iOSRE for more information on the relocation code. Used as a reference
#   but with small changes due to different iBoot versions.
0x87000003C ; ---------------- Relocation code above ----------------
0x87000003C     loc_87000003C:
0x87000003C ; Masking exceptions
0x87000003C         MSR             #6, #0xF                ; MSR   DAIFSET, #0xF
0x870000040 ; Setup exception tables base address
0x870000040         ADRP            X10, #unk_870000800@PAGE
0x870000044         ADD             X10, X10, #unk_870000800@PAGEOFF
0x870000048         MSR             #0, c12, c0, #0, X10    ; Store x10 into VBAR_EL1, or Vector Base Address Register (EL1).
0x87000004C ; Clear 16K of memory
0x87000004C         LDR             X10, =0x180098000       ; base stack address
0x870000050         LDR             X11, =0x4000            ; 16K
0x870000054         ADD             X11, X11, X10           ; x11 = base_addr + 16K bytes
0x870000058         MOV             X12, #0                 ; x12 = 0
0x87000005C     _loop__clear_16K:
0x87000005C         STP             X12, X12, [X10], #0x10  
0x870000060                                                 ; x10 == base addr, x11 == size (16K).
0x870000060         CMP             X10, X11                ; if (x10 != x11)
0x870000064         B.NE            _loop__clear_16K        ;   _loop__clear_16K()
0x870000068 ; Unsure here? Appears to be clearing 96K at 0x180080000
0x870000068         LDR             X10, =0x180080000       ; loads 0x180080000 into x10 
0x87000006C         LDR             X11, =0x18000           ; 96K
0x870000070         ADD             X11, X11, X10           ; x11 == end addr, x10 == base
0x870000074         MOV             X12, #0                 ; x12 = 0
0x870000078     _loop__clear_96K:
0x870000078         STP             X12, X12, [X10], #0x10
0x870000078                                                 ; Same as _loop__clear_16K, just with 96K.
0x87000007C         CMP             X10, X11                ; if (x10 != x11)
0x870000080         B.NE            _loop__clear_96K        ;   _loop__clear_96K()
0x870000084 ; Set the stack pointer
0x870000084         LDR             X10, =0x180099000
0x870000088         MOV             SP, X10                 ; SP = 0x180099000
0x87000008C ; set EL0 SP to x10
0x87000008C         LDR             X10, =0x18009A000       ; x10 = 0x18009A000
0x870000090         MSR             #5, #0                  ; select EL0 SP
0x870000094         MOV             SP, X10                 ; SP_EL0 = x10
0x870000098 ; zero additional space
0x870000098         LDR             X10, =0x18010DD80       ; _iboot_end
0x87000009C         LDR             X11, =0x180121A88       ; fb_mbe
0x8700000A0         MOV             X12, #0xF               
0x8700000A4         BIC             X12, X11, X12           ; x11 aligned to 16
0x8700000A8         MOV             X13, #0                 
0x8700000AC ; clear more space aligned 16
0x8700000AC     _loop__clear_more__aligned:
0x8700000AC         STP             X13, X13, [X10], #0x10 
0x8700000B0         CMP             X10, X12                    
0x8700000B4         B.NE            _loop__clear_more__aligned  
0x8700000B8         CMP             X11, X12                    
0x8700000BC         B.EQ            loc_8700000CC               
0x8700000C0 ; clear the rest of the space, unaligned
0x8700000C0     _loop__clear_more__unaligned:
0x8700000C0         STR             W13, [X10], #4
0x8700000C4         CMP             X10, X11
0x8700000C8         B.LT            _loop__clear_more__unaligned
0x8700000F4         ADRP            X30, #unk_87000266C@PAGE            ; unk_87000266C point to _main_generic
0x8700000F8         ADD             X30, X30, #unk_87000266C@PAGEOFF    ; 
0x8700000FC         RET
0x8700000FC ; ---------------------------------------------------------------------------

The location for iBoot to return to is now stored in x30, being the address of unk_87000266C. This is actually an undefined section of code that IDA could not identify. When jumping to it, there is a chunk of instructions with their addresses highlighted red. By selecting all of the highlighted code, we can create a function, this function being _main_generic.

void _main_generic()
    v18 = _task_create("main", _main_task_, 1, 0x1C00);


Now, _main_generic does some uninteresting platform hardware initialisation, but it also creates and starts the “main” task which is where the majority of iBoot’s functionality regarding setup and booting lies.


In this post we have covered the very first code to run as part of iBoot. The “Relocation Loop”, as we’ve already discussed, ensures that iBoot is running at the correct address, and will move it if required. The format of System Registers, how they are accessed and written to, and the _platform_start function whose responsibility it is to configure particular system registers, such as L2_CRAMCONFIG, or s3_3_c15_c7_0. And finally the code to run after the Relocation Loop which sets up areas of memory, the stack and eventually runs the rest of iBoot.

In the next post we shall cover the early iBoot initialisation, Tasking System, how tasks are created and how they are started.

Thank you for reading, as always you can reach me by email at, and on Twitter @h3adsh0tzz.