Usb control msg(0x21, 2) Exploit

This vulnerability exists in versions 3.1, 3.1.1, 3.1.2 (and probably previous) of iBoot on all iDevices, fixed in 3.1.3 firmware. Users of iPhone 3GS (new bootrom), ipt2 (MC) and ipt3 who saved their SHSH for 3.1.2 firmware can use it for tethered jailbreak of firmware 4.0 [1]

Credit (Alphabetical)

• vulnerability: pod2g and westbaer, also discovered independently by gray, also discovered independently by geohot
• exploitation: ius, chronic, pod2g, and posixninja
• payload (greenpois0n): chronic and posixninja

Vulnerability

pod2g and westbaer discovered, via some reversing + fuzzing, you could overwrite the content of 0x0 thanks to Apple not checking the contents of a register they should have, shown in the disassm below. Now, the reason that this is useful is because the MMU maps whatever is running (LLB, iBoot, etc.) to 0x0 so that if an exception vector is triggered, it would jump to the one designed to be used with what is running, versus jumping to what is normally located at 0x0, the bootrom.

All you need to do is send the following (assuming you're using libusb 0.1.x)...

usb_control_msg(iDev, 0x21, 2, 0, 0, 0, 0, 1000);

And thanks to our vulnerability, it will do this:

memcpy(0, LOAD_ADDR, 0x2000);

As you can see, we have full control over the first 0x2000 bytes of iBoot.

Disassm

// R5: a pointer to a buffer is here if requesttype==0xA1.
//     however, if requesttype==0x21, R5 is undefined.

SRAM:22009ED2                 code_1                                  ; CODE XREF: handle_file_io_control_req+62�j
SRAM:22009ED2 014 36 49                       LDR     R1, =usb_file_loadaddr
SRAM:22009ED4 014 36 4B                       LDR     R3, =usb_file_offset
SRAM:22009ED6 014 28 68                       LDR     R0, [R5]
SRAM:22009ED8 014 09 68                       LDR     R1, [R1]
SRAM:22009EDA 014 1B 68                       LDR     R3, [R3]
SRAM:22009EDC 014 22 1C                       ADDS    R2, R4, #0
SRAM:22009EDE 014 C9 18                       ADDS    R1, R1, R3
SRAM:22009EE0 014 07 F0 94 EF                 BLX     memcpy
SRAM:22009EE4 014 00 2E                       CMP     R6, #0
SRAM:22009EE6 014 53 D0                       BEQ     return
SRAM:22009EE8 014 01 23                       MOVS    R3, #1
SRAM:22009EEA 014 33 60                       STR     R3, [R6]
SRAM:22009EEC 014 50 E0                       B       return

Exploitation

So, how do you actually run code with this? Well, chronic suggested that since the irq vector was in constant use, we try that, so we were able to simply replace the address of the irq vector handler (0x00000038) in the 0x2000 iBoot chunk that we send with 0x41002000, and then just tack our payload to the end of that chunk. Of course, since we are hijacking the irq exception, you must disable interrupts first. Here is the basic procedure:

• Call enter_critical_task(); disabling interrupts, so that your code can reliably execute.
• Restore 0x38 (irq handler) with the original irq vector address
• DO WHAT YOU WANT AT THIS POINT, YOU MAY NOT USE INTERRUPTS.
• Call exit_critical_task(); re-enabling interrupts.
• Call the irq handler so that the interrupt request that you hijacked can execute.

Roadblocks

• If what you send is not 0x2000 bytes, the remainder is filled in with zeroes, which is bad.
• Due to the above rule, you need the first 0x2000 of a decrypted iBoot by the time your payload is done running.
• You must disable interrupts to reliably execute your payload. Due to this, this will rule out the possibility of reading the 0x2000 iBoot chunk needed from NOR, since nor_read(); requires interrupts.

One way to get around the need of sending the 0x2000 iBoot chunk is to hook the image_load(); function in the LLB which is sitting intact in memory. This was successfully done in blackra1n.

The PwnageTool method requires an IPSW to be input in order to create a custom firmware anyway, so the 0x2000 chunk is not an issue. It can just be copied from the iBoot in the IPSW.

Implementation

blackra1n