The iPhone Wiki - User contributions [en]

Talk:N72AP

2008-09-11T02:04:27Z

Wsxijn: /* interesting... */

"-It has a new GID key. -iBoot seems to map itself at 0xFF00000. -LLB is encrypted, which is new. -The s5l8900 WTF is still in the firmware strangely enough, but there is no n72ap WTF. -It uses the same KBAG method, but as previously stated, it has a new GID key so nothing can be decrypted at the time without allowing unsigned code."

Few questions...the S5L8900 WTF is an 8900 file. Is it encrypted with the old 0x837 key derived from the old GID key or the new keys? Also, my theory is if the DFU exploit still exists in the new touch, we can send an exploited WTF and from there send a patched iBoot, we could possiby get iBooter or openIboot working, we could decrypt the KBAG's. Are there any problems with this theory?

== problems ==

1. We can't send a patched iBoot without first being able to run code to decrypt th enew kbags. if the bootrom exploit still indeed exists, the nthis will definitely be doable.

2. I doubt the bootrom exploit is still there. highly.

3. The s5l WTF file is not encrypted, just compressed. If you decide to use 8900decryptor then it will recognize this and do the work for you.

4. If you can get an iBooter or implementation of it for 2.*, let me know. The iBEC is not encrypted and that would surely suffice for the purpose that you speak of. But I have some reason to believe that for some reason the iPod Touch 2 can be downgraded to an iPod Touch firmware. The reasoning behind this is that it has a totally new application processor, yet for reasons unknown, there is still support for 8900 files in it. As many know from clues hidden in firmwares dating back to 1.2 (The first build of 2.0, made available in March), 8900 encryption was used. I would have thought by now Apple would have re-written it to not have legacy 8900 support. But who knows...I may try to snag one and play around with it if that freeiphonetrade site or whatever it is called actually is legit.

== interesting... ==

Ok Chronic cool. So if we can get iBooter working (on the touch second gen), then we can send a patched iBec and from there decrypt the KBAGs on the actual touch2 hardware with iBooter. Then we could decrypt the ramdisk, rootfs, and get on our way with a jailbreak. Also, with your point about downgrading, if you are correct then we should be able to (possibly) downgrade the touch2 to 1.1.4 and use ibooter/openiboot with no problem? I have a feeling the only problem with that would be iTunes 8 will forbid even a DFU downgrade to 1.1.4, so we would either have to downgrade to iTunes 7.5 with the touch2 drivers still intact and then restore from there. That being said, I bet the only way a downgrade to 1.1.4 would work would be with a patched WTF and the DFU exploit not fixed by apple in the touch2. Should be an interesting few months for the devteam, assuming they even try to work on the touch2. Maybe we should talk to planetbeing regarding iBooter/openiboot in 2.1...

Can a patched IBEC be accepted by an unexploited stock ipod touch2? I doubt it. - CPICH

Talk:IDA Pro Setup

2008-08-14T23:15:22Z

Wsxijn: /* re: into ida */

prereqs.: IDA Pro Advanced, baseband files

wanted: Howto load these files correctly into IDA

'''Anybody to give this information here?''' TIA -caique2001-

== into ida ==
I suggest you look more into IDA Pro, see how things work. you may not be ready for a baseband yet.

the most important thing you need is the address. for example, i knew the iBoot was at 0x18000000 because at the beginning there is a routine to look if it is there and relocate it if not. also it has many references to 0x1800000 throughout the file.

Here are some key combinations to use:
c = turn the 'gibberish' into code
d = turn the 'gibberish' into data
a = turn the 'gibberish' into a string
u = undefine what you just may have done, i usually use this since there is no real edit+undo in IDA so this is the next best thing
Alt+G = change the 0 to a 1 to switch to thumb mode when needed

really i feel that you should do some more research on ARM and IDA Pro because a wiki article would not be enough to fully explain it

== re: into ida ==
I roughly know how ida works and what the keys are. I think there are some people that have already setup the right values for reversing the baseband. So what I want to see here is just a quick intro to set up the project (segments, fileoffsets, changed options, entry points and so on), not how to use ida. This should almost fit into your article above, just counting words ;-)

Yea, but if you don't understand how to get those numbers, you'll be pretty useless as a reverser. Not to discourage, but the numbers really aren't that hard to get. Look at the memory map I posted. All the information you need is here. ~geohot

== offsets ==
For example, if you look into ICE2_01.45 using a hex editor, you will see starting 0x634 there contains the memory maps. It started at 0x20000000 and ends at 0x21000000 with sections in between doing its own thing. The code/data in the .fls starts at 0xCF8 indicated by location 0xCF4. The length of the code is indicated by the location at 0xCEC which amounts to 0x5E9E18.

So, you may want to load the data in the .fls file from 0xCF8 to 0X5EAB0F at offset 0x20000000 in IDA pro.

-- CPICH

Obtaining IMG3 Keys

2008-08-07T02:50:47Z

Wsxijn: /* Get The Keys/IV */

This is one way of getting the IMG3 keys using iBoot/iBEC patch based on the Dev Team's and Geohot's exploits.

This method is tested on both Linux and Windows OS.

Epic thanks to #xpwn crew on irc.osx86.hu !

==What you need==
# Pwned 1st gen iPhone on 1.1.4 OS 
# ibooter from here [http://www.iphonelinux.org/index.php/IBooter] 
# iBEC.m68ap.RELEASE.dfu from iPhone1,1_1.1.4_4A102_Restore.ipsw 
# xpwntool from [http://www.iphone-dev.org/xpwn/xpwn-windows-nightly.zip] 
# iPhuc (for Windows users only) 
# Any Hex Editor 

==Summary==
Patched a function in the iBEC file so that it will branch to the desired memory location when the associated iboot command is called in ibooter. The desired memory location is at 0x09000000 as indicated by an earlier Geohot post and the iboot command chosen is "clearenv" in this documentation. The desired memory location will be housing the codes that enable and call the hardware aes engine so that the KBAG data can be decrypted for Keys/IV.

==Steps==

===Unpack iBEC.m68ap.RELEASE.dfu===

Utilizing xpwntool, enter this command:

xpwntool <original iBEC file> <unpacked iBEC file>
i.e.
xpwntool iBEC.m68ap.RELEASE.dfu unpacked_iBEC

===Patching iBEC.m68ap.RELEASE.dfu===

Before:
ROM:180074A0 PUSH {R4,R5,R7,LR} ;"clearenv" routine starts here
ROM:180074A2 ADD R7, SP, #8
ROM:180074A4 ADDS R4, R1, #0
ROM:180074A6 CMP R0, #1
ROM:180074A8 BGT loc_180074B4
ROM:180074AA LDR R0, =aNotEnoughArgum

After:
ROM:180074A0 '''LDR R3, =0x9000000'''
ROM:180074A2 '''BX R3'''
ROM:180074A2 ; ---------------------------------------------------------------------------
ROM:180074A4 dword_180074A4 '''DCD 0x9000000 ''' ; DATA XREF: ROM:180074A0�r
ROM:180074A8 ; ---------------------------------------------------------------------------
ROM:180074A8 BGT loc_180074B4
ROM:180074AA LDR R0, =aNotEnoughArgum

You will notice that iBEC starts at 0x18000000 but in your Hex Editor, just do the following changes at 0x74A0:
'''0x000074A0: 00 4b 18 47 00 00 00 09''' 

The idea is to tell clearenv routine to branch to 0x09000000 and BX is used because the codes to be used at 0x09000000 later will be in ARM. This "clearenv" routine is in THUMB mode. BX will enable them to switch. Save and name your modified iBEC, for example iBECmod.

===Packing the modified iBEC===
Using xpwntool:
xpwntool iBECmod iBEC.patch -t iBEC.m68ap.RELEASE.dfu

Note that the original iBEC file has to be used after -t as a template. IBEC.patch will be your modified, packed iBEC file.

===Executing patched iBEC in ibooter===

====Windows====
Put iPHUC and your patched iBEC in the same folder. Boot iPHUC and boot your iPhone in recovery mode. Type the following into iPHUC once it recognizes your iPhone:
filecopytophone iBEC.patch
It should return "filecopytophone: 0" 
Then type this:
cmd go
Your iPhone will reboot and display a blank black screen immediately. You are now ready to proceed with sending the payload and the kbag that you want to decrypt.

==== Linux ====
Put your iPhone in recovery mode, connect the USB cable and launch ibooter. Press ^F (CTRL+F) and
Enter, you will be prompted for a file name, type and patched iBEC file name and press enter. Next you will be prompted for memory location to load. Enter 0x9000000 for that and press enter.

Now type:
go
to execute the patched iBEC. Your iPhone will reboot into a blank screen and that's good. You need to reconnect the ibooter after the "reboot".

=== Calling The Hardware AES Engine ===
Type the following ARM codes in iBooter. Those were slightly modified geohot codes.

mw 0x9000000 0xe92d4090 // stmdb sp!, {r4, r7, lr}
mw 0x9000004 0xe59f0038 // ldr r0, [pc, #56]
mw 0x9000008 0xe59f1038 // ldr r1, [pc, #56] ; EnableDecrypt at 0x9000048
mw 0x900000c 0xe5810000 // str r0, [r1]
mw 0x9000010 0xe59f0024 // ldr r0, [pc, #36] ; Data ptr at 0x900003c
mw 0x9000014 0xe3a01020 // mov r1, #32 ; 0x20 bytes to be decrypted
mw 0x9000018 0xe3a02001 // mov r2, #1 ; 0x1
mw 0x900001c 0xe3a03000 // mov r3, #0 ; 0x0
mw 0x9000020 0xe1a0700d // mov r7, sp
mw 0x9000024 0xe24dd004 // sub sp, sp, #4 ; 0x4
mw 0x9000028 0xe58d3000 // str r3, [sp]
mw 0x900002c 0xe59f400c // ldr r4, [pc, #12] ; AESDecrypt at 0x9000040
mw 0x9000030 0xe12fff34 // blx r4
mw 0x9000034 0xe1a0d007 // mov sp, r7
mw 0x9000038 0xe8bd8090 // ldmia sp!, {r4, r7, pc}
mw 0x900003c 0x09000100
mw 0x9000040 0x18001791
mw 0x9000044 0x43a343a3
mw 0x9000048 0x180015c0
mw 0x9000100 0x5418c5de // KBAG data from 5A347 3G restore Ramdisk
mw 0x9000104 0x7e30b0ff
mw 0x9000108 0x0ea9b00e
mw 0x900010c 0x421f6288

Now, we are going to call "clearenv" in iBooter to execute the above codes (recall that we have patched "clearenv" in iBEC to allow it to branch to the above memory location). Simply type
clearenv
and enter.

=== Get The Keys/IV ===

Phew!!
Now, let's get the goodies. Simply type:
mdb 0x9000100

Let's see what you get in there!!!!

== Notes ==
There exists much easier method for getting the Keys/IVs (A matter of typing just a command line) but this is more fun. ;)

Obtaining IMG3 Keys

2008-08-07T01:41:11Z

Wsxijn: /* Calling The Hardware AES Engine */

This is one way of getting the IMG3 keys using iBoot/iBEC patch based on the Dev Team's and Geohot's exploits.

This method is tested on both Linux and Windows OS.

Epic thanks to #xpwn crew on irc.osx86.hu !

==What you need==
# Pwned 1st gen iPhone on 1.1.4 OS 
# ibooter from here [http://www.iphonelinux.org/index.php/IBooter] 
# iBEC.m68ap.RELEASE.dfu from iPhone1,1_1.1.4_4A102_Restore.ipsw 
# xpwntool from [http://www.iphone-dev.org/xpwn/xpwn-windows-nightly.zip] 
# iPhuc (for Windows users only) 
# Any Hex Editor 

==Summary==
Patched a function in the iBEC file so that it will branch to the desired memory location when the associated iboot command is called in ibooter. The desired memory location is at 0x09000000 as indicated by an earlier Geohot post and the iboot command chosen is "clearenv" in this documentation. The desired memory location will be housing the codes that enable and call the hardware aes engine so that the KBAG data can be decrypted for Keys/IV.

==Steps==

===Unpack iBEC.m68ap.RELEASE.dfu===

Utilizing xpwntool, enter this command:

xpwntool <original iBEC file> <unpacked iBEC file>
i.e.
xpwntool iBEC.m68ap.RELEASE.dfu unpacked_iBEC

===Patching iBEC.m68ap.RELEASE.dfu===

Before:
ROM:180074A0 PUSH {R4,R5,R7,LR} ;"clearenv" routine starts here
ROM:180074A2 ADD R7, SP, #8
ROM:180074A4 ADDS R4, R1, #0
ROM:180074A6 CMP R0, #1
ROM:180074A8 BGT loc_180074B4
ROM:180074AA LDR R0, =aNotEnoughArgum

After:
ROM:180074A0 '''LDR R3, =0x9000000'''
ROM:180074A2 '''BX R3'''
ROM:180074A2 ; ---------------------------------------------------------------------------
ROM:180074A4 dword_180074A4 '''DCD 0x9000000 ''' ; DATA XREF: ROM:180074A0�r
ROM:180074A8 ; ---------------------------------------------------------------------------
ROM:180074A8 BGT loc_180074B4
ROM:180074AA LDR R0, =aNotEnoughArgum

You will notice that iBEC starts at 0x18000000 but in your Hex Editor, just do the following changes at 0x74A0:
'''0x000074A0: 00 4b 18 47 00 00 00 09''' 

The idea is to tell clearenv routine to branch to 0x09000000 and BX is used because the codes to be used at 0x09000000 later will be in ARM. This "clearenv" routine is in THUMB mode. BX will enable them to switch. Save and name your modified iBEC, for example iBECmod.

===Packing the modified iBEC===
Using xpwntool:
xpwntool iBECmod iBEC.patch -t iBEC.m68ap.RELEASE.dfu

Note that the original iBEC file has to be used after -t as a template. IBEC.patch will be your modified, packed iBEC file.

===Executing patched iBEC in ibooter===

====Windows====
Put iPHUC and your patched iBEC in the same folder. Boot iPHUC and boot your iPhone in recovery mode. Type the following into iPHUC once it recognizes your iPhone:
filecopytophone iBEC.patch
It should return "filecopytophone: 0" 
Then type this:
cmd go
Your iPhone will reboot and display a blank black screen immediately.

From here, open iBooter and type

==== Linux ====
Put your iPhone in recovery mode, connect the USB cable and launch ibooter. Press ^F (CTRL+F) and
Enter, you will be prompted for a file name, type and patched iBEC file name and press enter. Next you will be prompted for memory location to load. Enter 0x9000000 for that and press enter.

Now type:
go
to execute the patched iBEC. Your iPhone will reboot into a blank screen and that's good. You need to reconnect the ibooter after the "reboot".

== Calling The Hardware AES Engine ==
Type the following ARM codes in iBooter. Those were slightly modified geohot codes.

mw 0x9000000 0xe92d4090 // stmdb sp!, {r4, r7, lr}
mw 0x9000004 0xe59f0038 // ldr r0, [pc, #56]
mw 0x9000008 0xe59f1038 // ldr r1, [pc, #56] ; EnableDecrypt at 0x9000048
mw 0x900000c 0xe5810000 // str r0, [r1]
mw 0x9000010 0xe59f0024 // ldr r0, [pc, #36] ; Data ptr at 0x900003c
mw 0x9000014 0xe3a01020 // mov r1, #32 ; 0x20 bytes to be decrypted
mw 0x9000018 0xe3a02001 // mov r2, #1 ; 0x1
mw 0x900001c 0xe3a03000 // mov r3, #0 ; 0x0
mw 0x9000020 0xe1a0700d // mov r7, sp
mw 0x9000024 0xe24dd004 // sub sp, sp, #4 ; 0x4
mw 0x9000028 0xe58d3000 // str r3, [sp]
mw 0x900002c 0xe59f400c // ldr r4, [pc, #12] ; AESDecrypt at 0x9000040
mw 0x9000030 0xe12fff34 // blx r4
mw 0x9000034 0xe1a0d007 // mov sp, r7
mw 0x9000038 0xe8bd8090 // ldmia sp!, {r4, r7, pc}
mw 0x900003c 0x09000100
mw 0x9000040 0x18001791
mw 0x9000044 0x43a343a3
mw 0x9000048 0x180015c0
mw 0x9000100 0x5418c5de // KBAG data from 5A347 3G restore Ramdisk
mw 0x9000104 0x7e30b0ff
mw 0x9000108 0x0ea9b00e
mw 0x900010c 0x421f6288

Now, we are going to call "clearenv" in iBooter to execute the above codes (recall that we have patched "clearenv" in iBEC to allow it to branch to the above memory location). Simply type
clearenv
and enter.

== Get The Keys/IV ==

Phew!!
Now, let's get the goodies. Simply type:
mdb 0x9000100

Let's see what you get in there!!!!

Obtaining IMG3 Keys

2008-08-07T01:38:20Z

Wsxijn: /* Linux */

This is one way of getting the IMG3 keys using iBoot/iBEC patch based on the Dev Team's and Geohot's exploits.

This method is tested on both Linux and Windows OS.

Epic thanks to #xpwn crew on irc.osx86.hu !

==What you need==
# Pwned 1st gen iPhone on 1.1.4 OS 
# ibooter from here [http://www.iphonelinux.org/index.php/IBooter] 
# iBEC.m68ap.RELEASE.dfu from iPhone1,1_1.1.4_4A102_Restore.ipsw 
# xpwntool from [http://www.iphone-dev.org/xpwn/xpwn-windows-nightly.zip] 
# iPhuc (for Windows users only) 
# Any Hex Editor 

==Summary==
Patched a function in the iBEC file so that it will branch to the desired memory location when the associated iboot command is called in ibooter. The desired memory location is at 0x09000000 as indicated by an earlier Geohot post and the iboot command chosen is "clearenv" in this documentation. The desired memory location will be housing the codes that enable and call the hardware aes engine so that the KBAG data can be decrypted for Keys/IV.

==Steps==

===Unpack iBEC.m68ap.RELEASE.dfu===

Utilizing xpwntool, enter this command:

xpwntool <original iBEC file> <unpacked iBEC file>
i.e.
xpwntool iBEC.m68ap.RELEASE.dfu unpacked_iBEC

===Patching iBEC.m68ap.RELEASE.dfu===

Before:
ROM:180074A0 PUSH {R4,R5,R7,LR} ;"clearenv" routine starts here
ROM:180074A2 ADD R7, SP, #8
ROM:180074A4 ADDS R4, R1, #0
ROM:180074A6 CMP R0, #1
ROM:180074A8 BGT loc_180074B4
ROM:180074AA LDR R0, =aNotEnoughArgum

After:
ROM:180074A0 '''LDR R3, =0x9000000'''
ROM:180074A2 '''BX R3'''
ROM:180074A2 ; ---------------------------------------------------------------------------
ROM:180074A4 dword_180074A4 '''DCD 0x9000000 ''' ; DATA XREF: ROM:180074A0�r
ROM:180074A8 ; ---------------------------------------------------------------------------
ROM:180074A8 BGT loc_180074B4
ROM:180074AA LDR R0, =aNotEnoughArgum

You will notice that iBEC starts at 0x18000000 but in your Hex Editor, just do the following changes at 0x74A0:
'''0x000074A0: 00 4b 18 47 00 00 00 09''' 

The idea is to tell clearenv routine to branch to 0x09000000 and BX is used because the codes to be used at 0x09000000 later will be in ARM. This "clearenv" routine is in THUMB mode. BX will enable them to switch. Save and name your modified iBEC, for example iBECmod.

===Packing the modified iBEC===
Using xpwntool:
xpwntool iBECmod iBEC.patch -t iBEC.m68ap.RELEASE.dfu

Note that the original iBEC file has to be used after -t as a template. IBEC.patch will be your modified, packed iBEC file.

===Executing patched iBEC in ibooter===

====Windows====
Put iPHUC and your patched iBEC in the same folder. Boot iPHUC and boot your iPhone in recovery mode. Type the following into iPHUC once it recognizes your iPhone:
filecopytophone iBEC.patch
It should return "filecopytophone: 0" 
Then type this:
cmd go
Your iPhone will reboot and display a blank black screen immediately.

From here, open iBooter and type

==== Linux ====
Put your iPhone in recovery mode, connect the USB cable and launch ibooter. Press ^F (CTRL+F) and
Enter, you will be prompted for a file name, type and patched iBEC file name and press enter. Next you will be prompted for memory location to load. Enter 0x9000000 for that and press enter.

Now type:
go
to execute the patched iBEC. Your iPhone will reboot into a blank screen and that's good. You need to reconnect the ibooter after the "reboot".

== Calling The Hardware AES Engine ==
Type the following ARM codes in iBooter. Those were slightly modified geohot codes.

mw 0x9000000 0xe92d4090 // stmdb sp!, {r4, r7, lr}
mw 0x9000004 0xe59f0038 // ldr r0, [pc, #56]
mw 0x9000008 0xe59f1038 // ldr r1, [pc, #56] ; EnableDecrypt at 0x9000048
mw 0x900000c 0xe5810000 // str r0, [r1]
mw 0x9000010 0xe59f0024 // ldr r0, [pc, #36] ; Data ptr at 0x900003c
mw 0x9000014 0xe3a01020 // mov r1, #32 ; 0x20 bytes to be decrypted
mw 0x9000018 0xe3a02001 // mov r2, #1 ; 0x1
mw 0x900001c 0xe3a03000 // mov r3, #0 ; 0x0
mw 0x9000020 0xe1a0700d // mov r7, sp
mw 0x9000024 0xe24dd004 // sub sp, sp, #4 ; 0x4
mw 0x9000028 0xe58d3000 // str r3, [sp]
mw 0x900002c 0xe59f400c // ldr r4, [pc, #12] ; AESDecrypt at 0x9000040
mw 0x9000030 0xe12fff34 // blx r4
mw 0x9000034 0xe1a0d007 // mov sp, r7
mw 0x9000038 0xe8bd8090 // ldmia sp!, {r4, r7, pc}
mw 0x900003c 0x09000100
mw 0x9000040 0x18001791
mw 0x9000044 0x43a343a3
mw 0x9000048 0x180015c0
mw 0x9000100 0x5418c5de // KBAG data from 5A347 3G restore Ramdisk
mw 0x9000104 0x7e30b0ff
mw 0x9000108 0x0ea9b00e
mw 0x900010c 0x421f6288

Now, we are going to call "clearenv" in iBooter to execute the above codes (recall that we have patched "clearenv" in iBEC to allow it to branch to the above memory location). Simply type
clearenv
and enter.

Obtaining IMG3 Keys

2008-08-07T01:04:38Z

Wsxijn: /* Linux */

Obtaining IMG3 Keys

2008-08-07T01:04:12Z

Wsxijn: /* Linux */

Obtaining IMG3 Keys

2008-08-07T01:03:15Z

Wsxijn: /* Windows */

Obtaining IMG3 Keys

2008-08-07T00:48:23Z

Wsxijn: /* Patching iBEC.m68ap.RELEASE.dfu */

Obtaining IMG3 Keys

2008-08-07T00:45:49Z

Wsxijn: /* Windows */

Obtaining IMG3 Keys

2008-08-06T23:06:23Z

Wsxijn:

Obtaining IMG3 Keys

2008-08-06T23:04:37Z

Wsxijn: New page: This is one way of getting the IMG3 keys using iBoot/iBEC patch based on the Dev Team's and Geohot's exploits. This method is tested on both Linux and Windows OS. Epic thanks to #xpwn cr...

Main Page

2008-08-06T22:17:43Z

Wsxijn: /* Keys */

<table border=1 width=100%><tr>
<td bgcolor=#64ff64 width=50%><center>[[PwnageTool|Jailbreak]]</center></td>
<td bgcolor=#ff6464 width=50%><center>[[Unlock 2.0|Unlock]]</center></td>
</tr>
<tr>
<td colspan=2>
<center>[[Disclaimer]]</center>
</td>
</tr>
</table> 


{| cellspacing="3" width="100%"
|- valign="top"
|width="20%" class="MainPageBG" style="border: 1px #999999; color: #000; background-color: rgb(255,255,255)"|
<div style="padding: .3em .7em .7em"> __TOC__ </div>
|width="80%" class="MainPageBG" style="border: 1px #c6c9ff; color: #000; background-color: #f0f0ff"|
<div style="padding: .3em .7em .7em"> {{:Welcome}} </div>
|}

==Hardware==
* [[m68ap|iPhone (m68ap)]]
* [[n82ap|iPhone 3G (n82ap)]]
* [[n45ap|iPod Touch (n45ap)]]

==App Processor (Jailbreak)==
The iPhone makes use of the [[S5L8900]] platform as application processor. Here is where the [[Jailbreak|jailbreak]] applies.

==Baseband (Unlock)==

The [[Baseband Device]] is where the [[unlock]] applies.

==File formats==
* [[8900 File Format]]
* [[IMG2 File Format]]
* [[IMG3 File Format]]
* [[secpack]]
* [[secpack 2.0]]
* [[seczone]]

==Protocols==
* [[Recovery Mode 0x1280]]
* [[Recovery Mode 0x1281]]
* [[DFU 0x1222]]
* [[WTF 0x1227]]
* [[Normal Mode 0x1290]]
* [[Restore Mode]]
* [[Baseband Bootrom Protocol]]
* [[Interactive Mode|Baseband Bootloader Protocol]]

==Keys==
* [[AES Keys]]
* [[Apple Certificate]]
* [[Baseband RSA Keys]]
* [[Baseband TEA Keys]]
* [[VFDecrypt Keys|Root Filesystem DMG Keys]]
* [[IMG3 Keys / IVs]]
* [[Let's Get Them IMG3 Keys / IVs]]

==Application Development==
* [[Toolchain]] (Includes tutorials)
* [[Toolchain 2.0]] (Includes tutorials)
* [[Frameworks]]
* [[Apple Certification Process]]
* [[Distribution Methods]]

==Tutorials==
see [[Tutorials|here]]

==Useful Links==
see [[Useful Links|here]]

==Definitions==
* [[jailbreak]]
* [[activation]]
* [[unlock]]
* [[Baseband Device|baseband]]
* [[Baseband Bootloader|bootloader]]
* [[DFU]]
* [[NORID]]
* [[CHIPID]]

==Other Stuff==
* [[Image Tool]]
* [[XPwn Tool]]
* [[DFU Utility]]
* [[DMG, HD Util, and HFS Plus]]

Talk:Research: Pwnage Patches

2008-08-03T17:33:07Z

Wsxijn: /* uhhhhh */

What is more important, is the code before 1800587C.

Compilers translate actions like

:if (condition is good)
::then

into conditional jumps. What you can see with the MOV and NEG is most probably the result of a failed condition (-1) (or failed function result). Afterwards it depends on the compiler, how it further treats the result.

Maybe the original pseudo code is as follows:

sig_check_result = do_check(important args);
...
if (sig_check_result == 0)
everything goes fine ...
...
a.s.o

So the question is, why it goes to the branch where R0 is set to -1 (patch 0) and what conditional branches lead to this code position? And the even more important question is, what is the underlying pseudo code?

And the even more important question is, why is it really necessary to do reverse engineering of reverse engineering?? Could be much more simple the questions are answered by some people that tend to mystify some things... </sarcasm>

said people would like to document, but most of the they're too busy using the little free time they have actually getting stuff done that people need done rather than documentation that 1% wants

If it's really like this, then I retract my statement. But then I hope 'said people' catch up on everything... Missing documentation and rare information (policies) were the main causes of the foundation of this wiki.

== seriously? ==

so wait, if you don't have the time to document it, why are you getting mad that others are? some people are interested in it...is something wrong with that? if you aren't interested, you don't have to look at this page if you don't want to. Pwnage, especially Pwnage 2.0, is especially mystifying to some people. Pumpkin, I have personally asked you if I may take a look at the individual patches to understand ARM better and to see how Pwnage works, but you politely declined my offer. I mean...if I am curious about something, and I cannot find out about it via the official creators, is it a sin for me to want to find out anyway? I really don't see what the big deal is...Apple can just as easily extract and diff the files. They would especially want to do this, come to think of it. It is only the developers that might want to find out how Pwnage really works that are in the dark.

I must say, I really like what you have done. The concept of your "Simple Unlock", it seems, you have applied to activation, and Pwnage itself. I'm not even being sarcastic. I really think it is pretty awesome.

Peace,
[[User:ChronicDev|ChronicDev]]

This is not about me wanting to keep this stuff secret, it's about what's efficient. I've already said that we don't have time to document them, but that we'll probably eventually get around to it. It just seems like a waste of resources to have anyone who is capable of reversing what we've done actually doing so, when there are so many other things that need looking at that the devteam could never even think of having the time to do. Why reverse something that will eventually be documented when Apple's stuff is sitting there and we all know it will never be documented?
--pumpkin

I strongly disagree. Let's take the example of zero-g, this little application, which unlocks at least 2G capabilities for a couple of people. Several people asked for the source code. Including me. With the effect of not even getting an answer. Oh, no, there is an answer, which IMHO is extremely arrogant, something like ''if you know what's going on, it's not much different from lamesaft''. Oh, yeah, funny, funny. Lamesaft with size of ~400 bytes not much different to zero-g having ~1000 bytes. To go further, I would have to reverse the code of zero-g. Not that this is difficult, but I don't have the time and I am not amused about being forced doing so. To sum it up: A lot of people are pissed off of the dev team. And it is not, that there are no reasons for. And it's not, that the dev teams work would not be really cool. It's just behavior and communication, which is inappropiate and partially premature.
-caique2001-

Bladox asked specifically to keep that code private. They (and we) do not wish to see more chinese crap coming out, thinking they have the ultimate solution because it worked for 2 minutes on their phone, resulting in more scams and legal risks. That network attack will be throughly documented, in due time (i.e. when it's not worth making a scam out of it any longer). And no, the previous comment wasn't really funny, it's actually very true. So rather than trying to understand how that thing works (as we stated previously, it doesn't), you should focus on other more interesting issues, such as issues that can be solved.
-Zf

to caique2001:
we realize that from the outside it must look like we're secrecy-loving clock-and-dagger assholes basking in our own knowledge, but there really are good reasons not to release stuff. when you're working against apple, whose only goal with respect to us is to patch up any vulnerabilities that are found, documenting those vulnerabilities is just making it easier for them to fix them. we don't really care if it makes us unpopular, but it means that more people can reap the benefits of the vulnerabilities for longer. a few legitimately curious people such as yourself will not have the source code, but honestly, is it that important?

:If you clearly communicate - and I interprete your statement now as having done so - this is okay. There is a tradeoff between releasing information and let people participate and keeping things closed to not let Apple know to much. Everybody understands that. But it's exactly the last phrase, which pisses people off. Was this really necessary? Who do you think you are? -caique2001-

::Pumpkin is a nice vegetable, and IMHO he just meant that having the source code isn't that important. Not that you are important, but I don't think anyone around is, so don't take it in a personal way. Zf

== throwing it out there ==

I like what Zf said. I would like to branch off one of his last statements by saying, if I am ibterested in looking into this, then why criticize me for doing so...I don't understand, no offense, but why do you criticize people and not actually correct them? for example, on URC, I was laughed at for thinking that there was a hardware method for dumping the 3G booteom. I asked them to correct me? and they "didn't want to contribute to geohots ego boost"....I mean...that is like saying that someone is stupid because they don't know where the holy grail is but you won't say where it is, except in that case you would be being arrogant

No, that's just saying that my contributions here will be limited to drama & troll, because that place was biaised against the dev team from day one (see initial blog post, Constitution and subsequent revisions), so I don't see why I should feel welcome here, nor be useful.
- Zf
:From a more 'outside' point of view: I did never feel this placed was biased against the dev team. It was just about letting people know what's going on and what's behind the scene. Something which was missing on dev teams site. Again: Clear communication is people's friend. You could have said, ''this'' is what we give you and ''the other stuff'' we are keeping secret, for ''these'' reasons. But looking on your blog was often looking on a mystified place. Giving a feeling of people self-praising themselves. And exactly this has been stopped by theiphonewiki. So it was not ''biased'' against dev team, but furthermore a correction of misled communication policies. To give an another example: Even now, your progress concerning 3G software unlock is not quite clear. What's wrong in communicating you could not run patched code? Do you fear disappointing people? You should focus on people that could work at the same level like you if they would belong to the ''inner circle''. Clearly communicate to them. They are not just 'curious', they could speed up progress. You don't want this, that's fine. But don't think you're better than the ordinary world. -caique2001-
:: Well it is biaised. See how the blog post began "I see a real problem with the iPhone hacking community. Most of the knowledge about the iPhone is somewhere within the dev team". How can you get more biaised than that, and why is it a problem btw ? To refer to your previous sentence, who do you think you are to dictate our agenda and the how and when people should document their work ? I have no problem to work with many people - note that coming around yelling "ohai, that's the the way you should work kthx" isn't the best way to be integrated in any team though (works well IRL too). Oh, and we can run patched code. But the question was flawed. Zf
:::I didn't dictate how anybody should work. Work as you like and as you belong to. I just tried to explain to you, why there could be some problems in the way you communicate. You do good work, btw. If I should have gone too far with my statements, I apologize. Have fun. -caique2001-
:::Hope the question isn't flawed ;-) : You can take 1.45.00 (or at least 1.43.00), patch it somewhere, flash this file and it's run? Yes or no?
::::No(t yet as easy as that, but be sure we're on it) :p Zf
::The stuff we keep secret, we keep secret for a reason. Other posts from you seem to indicate you understand why. The stuff we release, we release when it's nice and tested. Rather than document the how's and why's of what we've done, we'd rather move to the next challenge (and there are plenty of them). It's really that simple. Nothing sinister or dramatic. It's as simple as "it's fun to do, not fun to document". - MuscleNerd

to whomever came before this last Zf comment: we criticize because it feels like a waste of time. sure, you're welcome to do whatever you like with your time, but we're criticizing your choice of what to do with your time, as we feel it's useless to have you reverse what we reversed when we eventually plan on just writing it up. the most we can do to "correct" with that form of criticism is try to justify why we think you're wasting your time, when you could very well be doing things that are more helpful to the community. For example, everyone and their mother has been asking me for a Safari file:// url patch, but I simply haven't had the time recently. Why must it be me? Surely someone else who is spending their time reversing our hacks has the skills to patch a couple of bytes here and there to make life easier for many people? note that if you were reversing some secret hack that someone had leaked from the devteam I would feel differently, but pwnage is out and available at no cost to everyone, so the only product of your work is going to be improved understanding of our technique (a noble goal). We tend to be pragmatists, though, and as much as I'd love to be able to poke around at inane frameworks on the phone, for example, I prefer to use the little free time I have to do something generally useful to the public.
- pumpkin

Wow! I can't believe I woke up this morning and found this! Looks like me and Chronic's decision to post something about the patches has generated quite some interest to the Dev Team. According to my 1337 observation, there can be roughly 3 types of iPhone users:
1) Hackers ( roughly equal to Dev Team and some)
2) Enthusiasts (1% according to pumpkin :) )
3) Ordinary users

The hackers are on top of the hierarchy, they have the skillz and experience, they dictate what the rest of the users get after Apple. The enthusiasts on the other hand, posses some skillz but not quite the level of those from the category 1) folks and they refuse to sit back and happily jailbreak/unlock their device by clicking a feel buttons. They are a curious bunch. They usually have some time on their hands but unfortunately too inept to contribute anything useful to the community.
Category (3) is quite self explanatory.

You can tell the #2 guys they are wasting their time, you can discourage them for reverse the reverse-engineered, but I don't think they will barge an inch. Why? because they are simply category (2). Is the reverse the reverse-engineered effort futile? Maybe. Are they having more fun than simply pressing a few jailbreak option buttons? Definitely. Are the postage of the findings on this "biased" Wiki harmful to the community? Definitely not. Are we concern about Dev Team's lack of documentation? I personally couldn't care less. Even if they have the best documentation in the world, I will still try and reproduce the documented simply because I am #2.

So, if you fine folks in #1 sympathize with the #2 guys and somehow moved by their passion, do feel free to drop us a few hints here and there. We will appreciate greatly. And, if you feel offended because we posted on this "biased" Wiki, please don't be, we still love you to death. </sincere>

Oh shit! Who said I do not contribute to the community? I help building the 3G network so that you can surf the web twice the speed! -- CPICH

== a few things... ==

Zf, if you do not feel welcomed here because of the devteam bias, why not prove geohot and the rest of us wrong by contributing to the wiki :)

: because I usually do not fall for cheap manipulation tricks. Zf

My real problem is people In the devteam criticizing me because I say something incorrect, and I am just laughed at but when I ask for them to correct me they come up with the excuse that they don't want to post on the wiki...saying it right there in the channel would have sufficed, or even just PMing me...

I can't stress this enough. Apple can just easily read the .patch files, I really don't know how else to say this...Apple changing something to make stuff harder will happen, all the time. Remember when IMG3 was released? Nobody documented any patches, except for Apple. These things can not be avoided...

I would like to restate, doing something like a Safari patch just is not as ibteresting to me. Pwnage has and always has seemed mysterious, and interested me and others. I still don't see the issue with that. You may think it is a waste of time, but does it REALLY matter to you? :)

: Not at all, but as time and resources are usually a finite (and quite small) number, I'm still convinced it's best to optimize how they're used. Your call though. Think I trolled enough on that topic :) Zf

== welp. ==

every man to his own then. if you think sincerely asking you to contribute is manipulation, then I am afraid I literally don't know what to say to that...

== DRAMA ACHEIVED ==

Drama has officially been achieved on this wiki. I'm sure it will help us all. Thanks everyone for contributing, it's been a team effort!

In the end, no, the devteam won't be socially engineered/pwned/tricked/blogged/yiphoned/wiki'd/guilted into releasing info before it's ready. Love it or hate it, it's your choice. In the end, it benefits most of us.

Not sure if you noticed, but devteam doesn't take donations (unlike chronic, geohot, zibri, and the others). We don't do google ads (unlike geohot...etc). We're here to have fun for ourselves, and as side-benefit to help others. We have learned all about the drama queens. Yay for them. In any case, we are having fun battling Apple, drama queens notwithstanding.

== uhhhhh ==

MN you really seem to have a beef with me and I don't get it

on topic, are you on CRACK? dude, I have no other way to put this! this page has NOTHING to do with releasing pwnage early...where did you even get that idea man?

Ok, let's stop this, everybody please calm down.

Chronic, my advice to you stop posting anything in this page. Don't let anyone of us here including yourself being used as a proxy in the run-in between certain obvious parties. -- CPICH

Talk:Research: Pwnage Patches

2008-08-03T15:03:28Z

Wsxijn: /* throwing it out there */

What is more important, is the code before 1800587C.

Compilers translate actions like

:if (condition is good)
::then

into conditional jumps. What you can see with the MOV and NEG is most probably the result of a failed condition (-1) (or failed function result). Afterwards it depends on the compiler, how it further treats the result.

Maybe the original pseudo code is as follows:

sig_check_result = do_check(important args);
...
if (sig_check_result == 0)
everything goes fine ...
...
a.s.o

So the question is, why it goes to the branch where R0 is set to -1 (patch 0) and what conditional branches lead to this code position? And the even more important question is, what is the underlying pseudo code?

And the even more important question is, why is it really necessary to do reverse engineering of reverse engineering?? Could be much more simple the questions are answered by some people that tend to mystify some things... </sarcasm>

said people would like to document, but most of the they're too busy using the little free time they have actually getting stuff done that people need done rather than documentation that 1% wants

If it's really like this, then I retract my statement. But then I hope 'said people' catch up on everything... Missing documentation and rare information (policies) were the main causes of the foundation of this wiki.

== seriously? ==

so wait, if you don't have the time to document it, why are you getting mad that others are? some people are interested in it...is something wrong with that? if you aren't interested, you don't have to look at this page if you don't want to. Pwnage, especially Pwnage 2.0, is especially mystifying to some people. Pumpkin, I have personally asked you if I may take a look at the individual patches to understand ARM better and to see how Pwnage works, but you politely declined my offer. I mean...if I am curious about something, and I cannot find out about it via the official creators, is it a sin for me to want to find out anyway? I really don't see what the big deal is...Apple can just as easily extract and diff the files. They would especially want to do this, come to think of it. It is only the developers that might want to find out how Pwnage really works that are in the dark.

I must say, I really like what you have done. The concept of your "Simple Unlock", it seems, you have applied to activation, and Pwnage itself. I'm not even being sarcastic. I really think it is pretty awesome.

Peace,
[[User:ChronicDev|ChronicDev]]

This is not about me wanting to keep this stuff secret, it's about what's efficient. I've already said that we don't have time to document them, but that we'll probably eventually get around to it. It just seems like a waste of resources to have anyone who is capable of reversing what we've done actually doing so, when there are so many other things that need looking at that the devteam could never even think of having the time to do. Why reverse something that will eventually be documented when Apple's stuff is sitting there and we all know it will never be documented?
--pumpkin

I strongly disagree. Let's take the example of zero-g, this little application, which unlocks at least 2G capabilities for a couple of people. Several people asked for the source code. Including me. With the effect of not even getting an answer. Oh, no, there is an answer, which IMHO is extremely arrogant, something like ''if you know what's going on, it's not much different from lamesaft''. Oh, yeah, funny, funny. Lamesaft with size of ~400 bytes not much different to zero-g having ~1000 bytes. To go further, I would have to reverse the code of zero-g. Not that this is difficult, but I don't have the time and I am not amused about being forced doing so. To sum it up: A lot of people are pissed off of the dev team. And it is not, that there are no reasons for. And it's not, that the dev teams work would not be really cool. It's just behavior and communication, which is inappropiate and partially premature.
-caique2001-

Bladox asked specifically to keep that code private. They (and we) do not wish to see more chinese crap coming out, thinking they have the ultimate solution because it worked for 2 minutes on their phone, resulting in more scams and legal risks. That network attack will be throughly documented, in due time (i.e. when it's not worth making a scam out of it any longer). And no, the previous comment wasn't really funny, it's actually very true. So rather than trying to understand how that thing works (as we stated previously, it doesn't), you should focus on other more interesting issues, such as issues that can be solved.
-Zf

to caique2001:
we realize that from the outside it must look like we're secrecy-loving clock-and-dagger assholes basking in our own knowledge, but there really are good reasons not to release stuff. when you're working against apple, whose only goal with respect to us is to patch up any vulnerabilities that are found, documenting those vulnerabilities is just making it easier for them to fix them. we don't really care if it makes us unpopular, but it means that more people can reap the benefits of the vulnerabilities for longer. a few legitimately curious people such as yourself will not have the source code, but honestly, is it that important?

:If you clearly communicate - and I interprete your statement now as having done so - this is okay. There is a tradeoff between releasing information and let people participate and keeping things closed to not let Apple know to much. Everybody understands that. But it's exactly the last phrase, which pisses people off. Was this really necessary? Who do you think you are? -caique2001-

::Pumpkin is a nice vegetable, and IMHO he just meant that having the source code isn't that important. Not that you are important, but I don't think anyone around is, so don't take it in a personal way. Zf

== throwing it out there ==

I like what Zf said. I would like to branch off one of his last statements by saying, if I am ibterested in looking into this, then why criticize me for doing so...I don't understand, no offense, but why do you criticize people and not actually correct them? for example, on URC, I was laughed at for thinking that there was a hardware method for dumping the 3G booteom. I asked them to correct me? and they "didn't want to contribute to geohots ego boost"....I mean...that is like saying that someone is stupid because they don't know where the holy grail is but you won't say where it is, except in that case you would be being arrogant

No, that's just saying that my contributions here will be limited to drama & troll, because that place was biaised against the dev team from day one (see initial blog post, Constitution and subsequent revisions), so I don't see why I should feel welcome here, nor be useful.
- Zf
:From a more 'outside' point of view: I did never feel this placed was biased against the dev team. It was just about letting people know what's going on and what's behind the scene. Something which was missing on dev teams site. Again: Clear communication is people's friend. You could have said, ''this'' is what we give you and ''the other stuff'' we are keeping secret, for ''these'' reasons. But looking on your blog was often looking on a mystified place. Giving a feeling of people self-praising themselves. And exactly this has been stopped by theiphonewiki. So it was not ''biased'' against dev team, but furthermore a correction of misled communication policies. To give an another example: Even now, your progress concerning 3G software unlock is not quite clear. What's wrong in communicating you could not run patched code? Do you fear disappointing people? You should focus on people that could work at the same level like you if they would belong to the ''inner circle''. Clearly communicate to them. They are not just 'curious', they could speed up progress. You don't want this, that's fine. But don't think you're better than the ordinary world. -caique2001-
:: Well it is biaised. See how the blog post began "I see a real problem with the iPhone hacking community. Most of the knowledge about the iPhone is somewhere within the dev team". How can you get more biaised than that, and why is it a problem btw ? To refer to your previous sentence, who do you think you are to dictate our agenda and the how and when people should document their work ? I have no problem to work with many people - note that coming around yelling "ohai, that's the the way you should work kthx" isn't the best way to be integrated in any team though (works well IRL too). Oh, and we can run patched code. But the question was flawed. Zf
:::I didn't dictate how anybody should work. Work as you like and as you belong to. I just tried to explain to you, why there could be some problems in the way you communicate. You do good work, btw. If I should have gone too far with my statements, I apologize. Have fun. -caique2001-
:::Hope the question isn't flawed ;-) : You can take 1.45.00 (or at least 1.43.00), patch it somewhere, flash this file and it's run? Yes or no?
::The stuff we keep secret, we keep secret for a reason. Other posts from you seem to indicate you understand why. The stuff we release, we release when it's nice and tested. Rather than document the how's and why's of what we've done, we'd rather move to the next challenge (and there are plenty of them). It's really that simple. Nothing sinister or dramatic. It's as simple as "it's fun to do, not fun to document". - MuscleNerd

to whomever came before this last Zf comment: we criticize because it feels like a waste of time. sure, you're welcome to do whatever you like with your time, but we're criticizing your choice of what to do with your time, as we feel it's useless to have you reverse what we reversed when we eventually plan on just writing it up. the most we can do to "correct" with that form of criticism is try to justify why we think you're wasting your time, when you could very well be doing things that are more helpful to the community. For example, everyone and their mother has been asking me for a Safari file:// url patch, but I simply haven't had the time recently. Why must it be me? Surely someone else who is spending their time reversing our hacks has the skills to patch a couple of bytes here and there to make life easier for many people? note that if you were reversing some secret hack that someone had leaked from the devteam I would feel differently, but pwnage is out and available at no cost to everyone, so the only product of your work is going to be improved understanding of our technique (a noble goal). We tend to be pragmatists, though, and as much as I'd love to be able to poke around at inane frameworks on the phone, for example, I prefer to use the little free time I have to do something generally useful to the public.
- pumpkin

Wow! I can't believe I woke up this morning and found this! Looks like me and Chronic's decision to post something about the patches has generated quite some interest to the Dev Team. According to my 1337 observation, there can be roughly 3 types of iPhone users:
1) Hackers ( roughly equal to Dev Team and some)
2) Enthusiasts (1% according to pumpkin :) )
3) Ordinary users

The hackers are on top of the hierarchy, they have the skillz and experience, they dictate what the rest of the users get after Apple. The enthusiasts on the other hand, posses some skillz but not quite the level of those from the category 1) folks and they refuse to sit back and happily jailbreak/unlock their device by clicking a feel buttons. They are a curious bunch. They usually have some time on their hands but unfortunately too inept to contribute anything useful to the community.
Category (3) is quite self explanatory.

You can tell the #2 guys they are wasting their time, you can discourage them for reverse the reverse-engineered, but I don't think they will barge an inch. Why? because they are simply category (2). Is the reverse the reverse-engineered effort futile? Maybe. Are they having more fun than simply pressing a few jailbreak option buttons? Definitely. Are the postage of the findings on this "biased" Wiki harmful to the community? Definitely not. Are we concern about Dev Team's lack of documentation? I personally couldn't care less. Even if they have the best documentation in the world, I will still try and reproduce the documented simply because I am #2.

So, if you fine folks in #1 sympathize with the #2 guys and somehow moved by their passion, do feel free to drop us a few hints here and there. We will appreciate greatly. And, if you feel offended because we posted on this "biased" Wiki, please don't be, we still love you to death. </sincere>

Oh shit! Who said I do not contribute to the community? I help building the 3G network so that you can surf the web twice the speed! -- CPICH

Talk:Research: Pwnage Patches

2008-08-03T15:02:53Z

Wsxijn: /* throwing it out there */

What is more important, is the code before 1800587C.

Compilers translate actions like

:if (condition is good)
::then

into conditional jumps. What you can see with the MOV and NEG is most probably the result of a failed condition (-1) (or failed function result). Afterwards it depends on the compiler, how it further treats the result.

Maybe the original pseudo code is as follows:

sig_check_result = do_check(important args);
...
if (sig_check_result == 0)
everything goes fine ...
...
a.s.o

So the question is, why it goes to the branch where R0 is set to -1 (patch 0) and what conditional branches lead to this code position? And the even more important question is, what is the underlying pseudo code?

And the even more important question is, why is it really necessary to do reverse engineering of reverse engineering?? Could be much more simple the questions are answered by some people that tend to mystify some things... </sarcasm>

said people would like to document, but most of the they're too busy using the little free time they have actually getting stuff done that people need done rather than documentation that 1% wants

If it's really like this, then I retract my statement. But then I hope 'said people' catch up on everything... Missing documentation and rare information (policies) were the main causes of the foundation of this wiki.

== seriously? ==

so wait, if you don't have the time to document it, why are you getting mad that others are? some people are interested in it...is something wrong with that? if you aren't interested, you don't have to look at this page if you don't want to. Pwnage, especially Pwnage 2.0, is especially mystifying to some people. Pumpkin, I have personally asked you if I may take a look at the individual patches to understand ARM better and to see how Pwnage works, but you politely declined my offer. I mean...if I am curious about something, and I cannot find out about it via the official creators, is it a sin for me to want to find out anyway? I really don't see what the big deal is...Apple can just as easily extract and diff the files. They would especially want to do this, come to think of it. It is only the developers that might want to find out how Pwnage really works that are in the dark.

I must say, I really like what you have done. The concept of your "Simple Unlock", it seems, you have applied to activation, and Pwnage itself. I'm not even being sarcastic. I really think it is pretty awesome.

Peace,
[[User:ChronicDev|ChronicDev]]

This is not about me wanting to keep this stuff secret, it's about what's efficient. I've already said that we don't have time to document them, but that we'll probably eventually get around to it. It just seems like a waste of resources to have anyone who is capable of reversing what we've done actually doing so, when there are so many other things that need looking at that the devteam could never even think of having the time to do. Why reverse something that will eventually be documented when Apple's stuff is sitting there and we all know it will never be documented?
--pumpkin

I strongly disagree. Let's take the example of zero-g, this little application, which unlocks at least 2G capabilities for a couple of people. Several people asked for the source code. Including me. With the effect of not even getting an answer. Oh, no, there is an answer, which IMHO is extremely arrogant, something like ''if you know what's going on, it's not much different from lamesaft''. Oh, yeah, funny, funny. Lamesaft with size of ~400 bytes not much different to zero-g having ~1000 bytes. To go further, I would have to reverse the code of zero-g. Not that this is difficult, but I don't have the time and I am not amused about being forced doing so. To sum it up: A lot of people are pissed off of the dev team. And it is not, that there are no reasons for. And it's not, that the dev teams work would not be really cool. It's just behavior and communication, which is inappropiate and partially premature.
-caique2001-

Bladox asked specifically to keep that code private. They (and we) do not wish to see more chinese crap coming out, thinking they have the ultimate solution because it worked for 2 minutes on their phone, resulting in more scams and legal risks. That network attack will be throughly documented, in due time (i.e. when it's not worth making a scam out of it any longer). And no, the previous comment wasn't really funny, it's actually very true. So rather than trying to understand how that thing works (as we stated previously, it doesn't), you should focus on other more interesting issues, such as issues that can be solved.
-Zf

to caique2001:
we realize that from the outside it must look like we're secrecy-loving clock-and-dagger assholes basking in our own knowledge, but there really are good reasons not to release stuff. when you're working against apple, whose only goal with respect to us is to patch up any vulnerabilities that are found, documenting those vulnerabilities is just making it easier for them to fix them. we don't really care if it makes us unpopular, but it means that more people can reap the benefits of the vulnerabilities for longer. a few legitimately curious people such as yourself will not have the source code, but honestly, is it that important?

:If you clearly communicate - and I interprete your statement now as having done so - this is okay. There is a tradeoff between releasing information and let people participate and keeping things closed to not let Apple know to much. Everybody understands that. But it's exactly the last phrase, which pisses people off. Was this really necessary? Who do you think you are? -caique2001-

::Pumpkin is a nice vegetable, and IMHO he just meant that having the source code isn't that important. Not that you are important, but I don't think anyone around is, so don't take it in a personal way. Zf

== throwing it out there ==

I like what Zf said. I would like to branch off one of his last statements by saying, if I am ibterested in looking into this, then why criticize me for doing so...I don't understand, no offense, but why do you criticize people and not actually correct them? for example, on URC, I was laughed at for thinking that there was a hardware method for dumping the 3G booteom. I asked them to correct me? and they "didn't want to contribute to geohots ego boost"....I mean...that is like saying that someone is stupid because they don't know where the holy grail is but you won't say where it is, except in that case you would be being arrogant

No, that's just saying that my contributions here will be limited to drama & troll, because that place was biaised against the dev team from day one (see initial blog post, Constitution and subsequent revisions), so I don't see why I should feel welcome here, nor be useful.
- Zf
:From a more 'outside' point of view: I did never feel this placed was biased against the dev team. It was just about letting people know what's going on and what's behind the scene. Something which was missing on dev teams site. Again: Clear communication is people's friend. You could have said, ''this'' is what we give you and ''the other stuff'' we are keeping secret, for ''these'' reasons. But looking on your blog was often looking on a mystified place. Giving a feeling of people self-praising themselves. And exactly this has been stopped by theiphonewiki. So it was not ''biased'' against dev team, but furthermore a correction of misled communication policies. To give an another example: Even now, your progress concerning 3G software unlock is not quite clear. What's wrong in communicating you could not run patched code? Do you fear disappointing people? You should focus on people that could work at the same level like you if they would belong to the ''inner circle''. Clearly communicate to them. They are not just 'curious', they could speed up progress. You don't want this, that's fine. But don't think you're better than the ordinary world. -caique2001-
:: Well it is biaised. See how the blog post began "I see a real problem with the iPhone hacking community. Most of the knowledge about the iPhone is somewhere within the dev team". How can you get more biaised than that, and why is it a problem btw ? To refer to your previous sentence, who do you think you are to dictate our agenda and the how and when people should document their work ? I have no problem to work with many people - note that coming around yelling "ohai, that's the the way you should work kthx" isn't the best way to be integrated in any team though (works well IRL too). Oh, and we can run patched code. But the question was flawed. Zf
:::I didn't dictate how anybody should work. Work as you like and as you belong to. I just tried to explain to you, why there could be some problems in the way you communicate. You do good work, btw. If I should have gone too far with my statements, I apologize. Have fun. -caique2001-
:::Hope the question isn't flawed ;-) : You can take 1.45.00 (or at least 1.43.00), patch it somewhere, flash this file and it's run? Yes or no?
::The stuff we keep secret, we keep secret for a reason. Other posts from you seem to indicate you understand why. The stuff we release, we release when it's nice and tested. Rather than document the how's and why's of what we've done, we'd rather move to the next challenge (and there are plenty of them). It's really that simple. Nothing sinister or dramatic. It's as simple as "it's fun to do, not fun to document". - MuscleNerd

to whomever came before this last Zf comment: we criticize because it feels like a waste of time. sure, you're welcome to do whatever you like with your time, but we're criticizing your choice of what to do with your time, as we feel it's useless to have you reverse what we reversed when we eventually plan on just writing it up. the most we can do to "correct" with that form of criticism is try to justify why we think you're wasting your time, when you could very well be doing things that are more helpful to the community. For example, everyone and their mother has been asking me for a Safari file:// url patch, but I simply haven't had the time recently. Why must it be me? Surely someone else who is spending their time reversing our hacks has the skills to patch a couple of bytes here and there to make life easier for many people? note that if you were reversing some secret hack that someone had leaked from the devteam I would feel differently, but pwnage is out and available at no cost to everyone, so the only product of your work is going to be improved understanding of our technique (a noble goal). We tend to be pragmatists, though, and as much as I'd love to be able to poke around at inane frameworks on the phone, for example, I prefer to use the little free time I have to do something generally useful to the public.
- pumpkin

Wow! I can't believe I woke up this morning and found this! Looks like me and Chronic's decision to post something about the patches has generated quite some interest to the Dev Team. According to my 1337 observation, there can be roughly 3 types of iPhone users:
1) Hackers ( roughly equal to Dev Team and some)
2) Enthusiasts (1% according to pumpkin :) )
3) Ordinary users

The hackers are on top of the hierarchy, they have the skillz and experience, they dictate what the rest of the users get after Apple. The enthusiasts on the other hand, posses some skillz but not quite the level of those from the category 1) folks and they refuse to sit back and happily jailbreak/unlock their device by clicking a feel buttons. They are a curious bunch. They usually have some time on their hands but unfortunately too inept to contribute anything useful to the community.
Category (3) is quite self explanatory.

You can tell the #2 guys they are wasting their time, you can discourage them for reverse the reverse-engineered, but I don't think they will barge an inch. Why? because they are simply category (2). Is the reverse the reverse-engineered effort futile? Maybe. Are they having more fun than simply pressing a few jailbreak option buttons? Definitely. Are the postage of the findings on this "biased" Wiki harmful to the community? Definitely not. Are we concern about Dev Team's lack of documentation? I personally couldn't care less. Even if they have the best documentation in the world, I will still try and reproduce the documented simply because I am #2.

So, if you fine folks in #1 sympathize with the #2 guys and somehow moved by their passion, do feel free to drop us a few hints here and there. We will appreciate greatly. And, if you feel offended because we posted on this "biased" Wiki, please don't be, we still love you to death. </sincere>

Oh shit! Who said I do not contribute to the community? I help building the 3G network so that you can surf the web twice the speed! ----- CPICH

Research: Pwnage Patches

2008-08-03T00:55:04Z

Wsxijn: /* 2.0 (5A347) Lockdownd */

If you have IDA Pro and you are at least semi-handy with ARM please contribute :)

Thanks to CPICH for helping out!

== 2.0 (5A347) iBoot ==

=== Patched Area ===
There is only 1 patch made to the iBoot, iBEC, iBSS, and WTF.n82ap. They are all iBoots, pretty much, so I am going to assume that they all have this same patch for the same reason. Please feel free to correct this if this is not true.

Here is a snippet of it from IDA:

ROM:1800587C 01 20 MOVS R0, #1 ; R1 = 1
ROM:1800587E 40 42 NEGS R0, R0 ; PWNAGE PATCH
ROM:1800587E ; Change 40 42 > 00 20
ROM:1800587E ; That will make it:
ROM:1800587E ; MOVS R0 = #0
ROM:1800587E ;
ROM:1800587E ; R0 (unpatched) = -1
ROM:1800587E ; R0 (patched) = 0

=== Why does this help us? ===
ROM:18005D72 FF F7 D2 FC BL sub_1800571A ; Branch with Link

That jumps to 0x1800571A. Why does that matter? well, the above "Patched Area" is at the end of this routine, and then we come back with our modified R0. Right after this BL, we get this, which is where our new R0 comes into play:

ROM:18005D76 00 28 CMP R0, #0 ; Set cond. codes on Op1 - Op2
ROM:18005D78 00 D0 BEQ loc_18005D7C ; Branch
ROM:18005D7A 8A E0 B loc_18005E92 ; Branch

If R0 = 0, which is does, it will jump to 0x18005D7C. If not, it will go to 0x18005E92. I don't know the nitty gritty, but basically this is to make it so that we jump to an earlier part in the file that we were supposed to. A further analysis may be in order, I will definitely get to that later.
== 2.0 (5A347) [[Lockdownd]] ==
This may actually confuse some people. You see, there is 'technically' two patches, but in reality, there is only one. The second one is the rehashed signature done with ldid, because you must remember that this is a userland binary, not a lower level one like the [[iBoot]], which resides in the [[NOR]]. These files on the main filesystem must cohere to the demands of the [[kernel]], and according to a [[devteam]] member, the patches to not require this were to complex and it would just be much easier to use ldid to take care of it. So that is what they did here. They took the original file, then one with the one patch that they needed, rehashed the patched one, BsDiff'd them, and then as you can now tell, the .patch tile contains the actual patch + the new sig :)

(Be back in a little bit with actual snippets from IDA showing the actual patch done, I want to go through the actual low level stuff first)

I don't think the dev team is using ldid because ldid changes the file size (i.e. asr sig patch added 0x20 bytes using ldid). However the same ldid method may work as well.