BlackRa1n Exploit Explained

Source : usb_control_msg(0x21, 2) Exploit - The iPhone Wiki


usb_control_msg(0x21, 2) Exploit

This vulnerability exists in the versions of iBoot found in firmwares 3.1/3.1.1 and 3.1.2 (and presumably everything before) on all iDevices. It was fixed in iBoot-636.66.33, which was included with 3.1.3. iPhone 3GS (new bootrom) and iPod touch 3G owners who saved their SHSH for the aforementioned firmwares, and MC-model iPod touch 2G owners can use it for a tethered jailbreak on 4.0.

Credits (alphabetically)

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)...
Code:
usb_control_msg(iDev, 0x21, 2, 0, 0, 0, 0, 1000);
And thanks to our vulnerability, it will do this:
Code:
memcpy(0, LOAD_ADDR, 0x2000);
As you can see, we have full control over the first 0x2000 bytes of iBoot.

Disassm
Code:
// 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