The iPhone Wiki - User contributions [en]

IPhone Dev Team

2010-09-30T23:27:29Z

Pumpkin: update member list

{{DISPLAYTITLE:iPhone Dev Team}}
==Blog==
[http://blog.iphone-dev.org Dev Team blog]

==Current members==
* [[bgm]]
* [[bugout]]
* [[User:Bushing|bushing]]
* [[c1de0x]]
* [[chris]]
* [[User:Comex|comex]]
* [[CPICH]]
* [[ghost_000]]
* [[gray]]
* [[iZsh]]
* [[marcan]]
* [[User:MuscleNerd|MuscleNerd]]
* [[User:Planetbeing|planetbeing]]
* [[pumpkin]]
* [[pytey]]
* [[roxfan]]
* [[saurik]]
* [[Turbo]]
* [[w___]]
* [[wizdaz]]
* [[Zf]]

==Previous Members==
* [[asap18]]
* [[dinopio]]
* [[Fred_]]
* [[jim–]]
* [[netkas]]
* [[pr3d4t0r]]
* [[drudge]]
* [[User:Geohot|geohot]]
* [[gj]]
* [[kroo]]
* [[Nate True]]
* [[User:NerveGas|NerveGas]]
* [[sam]]
* [[Whiterat]]
* [[User:Zibri|Zibri]]

==See also==
* [[25C3 presentation Hacking the iPhone#Introduction (by pytey)|Self introduction at the 25C3 event]]
* [[PwnageTool]]
* [[pwnage]]
* [[pwnage 2.0]]
* [[yellowsn0w]]
* [[redsn0w]]
* [[ultrasn0w]]

[[Category:Hackers]]

Talk:Device Nodes

2008-08-28T17:22:47Z

Pumpkin: New page: Um, on any Mac OS block device diskXsY has a character device counterpart called rdiskXsY, so rdisk0* is just a character device for accessing the flash.

Um, on any Mac OS block device diskXsY has a character device counterpart called rdiskXsY, so rdisk0* is just a character device for accessing the flash.

Talk:GID Key

2008-08-05T12:39:35Z

Pumpkin: /* Vaumnou */

== drg ==

Would this be vulnerable to a [http://en.wikipedia.org/wiki/Cold_boot_attack cold boot attack]?

== geohot ==

I really doubt the AES key is ever in memory. This is an attack against drive encryption, not hardware coprocessors. Fault analysis or timing would be our best bet.

== Vaumnou ==

Unless you can cause read faults by browning out the chip or the ROM is external, you can't use fault analysis. And if the ROM is external, it would probably be easier to unsolder it and read it directly.

== pumpkin ==

it isn't external

Talk:Research: Pwnage Patches

2008-08-03T11:11:36Z

Pumpkin: /* seriously? */

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?

== 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

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

Talk:Research: Pwnage Patches

2008-08-03T11:00:33Z

Pumpkin: /* 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

== 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

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

Talk:Research: Pwnage Patches

2008-08-03T09:46:29Z

Pumpkin: /* seriously? */

Talk:Research: Pwnage Patches

2008-08-02T21:37:18Z

Pumpkin:

Talk:01.43.00

2008-08-02T10:37:46Z

Pumpkin:

== drg ==

This information was published by the dev team on the blog. I think it's fair game for the wiki :)

== geohot ==

Talk of beta versions is fair game. Just no download links :)

== pumpkin ==

the iphone baseband firmware was found on an ipod touch ramdisk? o.O

User talk:Shad0w

2008-08-02T10:30:43Z

Pumpkin: New page: please stop signing every page you write... it's not appropriate for a documentation wiki. the "credits" appear on the history page

please stop signing every page you write... it's not appropriate for a documentation wiki. the "credits" appear on the history page

The iPhone Wiki talk:Ground rules

2008-07-31T09:04:21Z

Pumpkin:

''clean up, clean up, everybody everywhere'' :-) I like the ground rules -caique2001-

Perhaps an idea to have a help redirect message to IRC on the main page, like the original wiki had?

Nice, I agree with most of them. Although I think tutorials are a good thing.

== added section ==

i added a small note about tutorials. just so we don't get overridden by these, we have already had 5 seperate pages for very exact topics with just a youtube link, god only knows what might have happened after our first month :P

== attribution ==

wouldn't it be good to mark pages taken verbatim from the old wiki as imported, maybe in the edit comment? otherwise one might expect to be able to ask the contributor to this wiki about contributions he simply copied and pasted from the old one.

A page like [[Activation token]] is identical, for example.

IPhone Dev Team

2008-07-30T23:59:30Z

Pumpkin: very funny, Chronic

==Homepage==
[http://iphone-dev.org Dev Team Homepage]

==Current members==
asap18, bgm, Bugout, bushing, c1de0x, chris, dinopio, drudge, Fred_, ghost_000, gray, iZsh, jim–, kroo, MuscleNerd, netkas, np101137, penisbird, planetbeing, pr3d4t0r, pumpkin, pytey, roxfan, sam, saurik, Turbo, w___, wizdaz, Zf

==Previous Members==
[[geohot]], [[Zibri]]

Talk:Software Update Service

2008-07-30T16:17:37Z

Pumpkin: New page: This is from the old iPhone Dev Wiki, but is not cached or saved anywhere else. I saw how in-depth it got and at the time I was thinking that it would get removed. I was right. Luckily, I ...

This is from the old iPhone Dev Wiki, but is not cached or saved anywhere else. I saw how in-depth it got and at the time I was thinking that it would get removed. I was right. Luckily, I saved it, and I have been holding on to it for when the time was right. Now that we have this open wiki, the time is right. This article details the old software updates, usually less than 10mb in size, that Apple used to update firmwares. They worked much better, and were based on good old .patch files. Please do not delete this preamble. And without further ado, here is the article.

PS: I have slightly editted it because of formatting reasons, as well as made it look neater.

--ChronicProductions

I'm not sure why people treat knowledge written by devteam members as the lost ark. The people who wrote this stuff are all still alive and most are still active in the community. If you wanted to know about this, you could've just asked Zf :P
Also, this service has been gone from the phone for ages now, so maybe we want to mention that on the main article?
--pumpkin

Software Update Service

2008-07-30T16:15:51Z

Pumpkin: Not relevant to article itself. "Do not delete" doesn't make sense, as this wiki keeps all histories, etc. The preamble is more suited to the talk page.

== Tasks: Applying updates on a jailbreaked system ==

Describing the update process: DONE

Understanding the BOM file format on the iPhone: IN PROGRESS (see the BOM framework)

Patch the pre/post BOM to only check the files that are patched: IN PROGRESS (compare BOM list with cpio'ed archive content)

Regenerating/signing the update files: IN PROGRESS (iZsh has some stuff)

== Update archive content ==

The update archive is a zip contains the following files.

=== archive.cpio.gz ===
The actual cpio patch archive (encrypted). Contains a list of BSDiff patches (*) and baseband firmware updates, if available, with the associated flashing tools (bbupdater/imeisv).

=== Info.plist ===
Description of the update and hashes of the update components (cleartext)

=== Info.plist.signature ===
Asymmetric signature of Info.plist validated against /System/Library/Lockdown/iPhoneSoftwareUpdate.pem

=== libupdate_brain.dylib ===
Stage 2 update process library (encrypted)

=== pre.bom ===
Bill Of Material stating the filesystem state before the update process (encrypted)

=== post.bom ===
Bill Of Material stating the filesystem state after the update process (encrypted)

(*) there is a different update file to go from 1.0 to 1.0.2 and from 1.0.1 to 1.0.2 since bsdiff does not apply partial patches.

The BOM files can be used to validate the CRC 32 checksums of the modified files. They can be browsed with lsbom on OS X.

== Update process ==

# Software_Update is invoked

# The files signatures are checked

# libupdate_brain.dylib, pre.bost and post.bom are decrypted

# gogo_software_update in libupdate_brain.dylib is called to perform the actual update process
Blocking automatic updates

=== A quick reversible way to disable automatic updates ===
Remove the executable permission on software_update

chmod a-x /usr/libexec/software_update

Since bbupdater is included in the updates, you must block all automatic updates to prevent baseband updates

== Debugging software_update ==

software_update fails when launched from SSH because it cannot connect to lockdownd (validated with weasel, the minimal debugger included in the toolchain)

Further investigation is needed to know why this happen. Probably because it must be spawned from a specific process. In this case weasel could probably be modified to accept remote commands in order to debug that kind of processes with minimal side effects.

== Decrypting the update files ==

The update files are AES-128 CBC encrypted with a key dependant of the software version.

To retrieve the key, compute a SHA-1 hash of /System/Library/Caches/com.apple.kernelcaches/kernelcache.s5l8900xrb from offset (size / 2 - 0x2000) for 0x4000 bytes (or used the utility described below)

To decrypt the update files from a desktop computer - funny facts: the IV is TheIphoneLovesU

openssl enc -d -aes-128-cbc -K hex_key_obtained_in_the_previous_step -iv 5468656950686F6E654C6F7665735500 -in encrypted_file -out decrypted_file

=== Another quick & dirty way to recover the decrypted files ===
Have software_update crash before running stage 2 and scavenge the files, for example by modifying the name of the function called in stage 2 (gogo_software_update) - the decrypted files are in /private/var/software_update/foo.pkg
Reversing BOM

=== BOM Framework ===
The BOM framework (located in /System/Library/PrivateFrameworks/Bom.framework/Bom) is not documented, but very easy to reverse.

Here is the .h used to implment the prototype checker

// BOM framework header - v0.1
// Zf for iPhone Developers Wiki
// Licensed under GPLv2
typedef void* BOM;
typedef void* BOMEnumerator;
typedef void* BOMFSObject;
typedef enum BOMObjectType {
BOMFile = 1,
BOMDirectory,
BOMLink
} BOMObjectType;
typedef struct BOMSize {
int low;
int high;
} BOMSize;
int BOMCRC32ForFile(char *path, unsigned int *crc, BOMSize *size);
BOM BOMBomOpen(char *path, int unk1); // 0 == error
// unk1 = 0
int BOMBomFree(BOM bom);
BOM BOMBomNew(char *path);
int BOMBomCommit(BOM bom);
int BOMBomInsertFSObject(BOM bom, BOMFSObject object, int unk1);
// unk1=0

BOMEnumerator BOMBomEnumeratorNewWithOptions(BOM bom, int unk1, int unk2);
// unk1=0 unk2=1
BOMFSObject BOMBomEnumeratorNext(BOMEnumerator enumerator); // 0 == last
int BOMEnumeratorFree(BOMEnumerator enumerator);
BOMObjectType BOMFSObjectType(BOMFSObject object);
char* BOMFSObjectPathName(BOMFSObject object);
unsigned int BOMFSObjectChecksum(BOMFSObject object);
unsigned int BOMFSObjectSize(BOMFSObject object);
int BOMFSObjectFree(BOMFSObject object);

== Sample patch checker ==

The following code (running on the iPhone to validate the checksums or on OS-X to modify the BOM), partially tested, creates a simplified BOM containing only references to the patched files. This does not work fully as expected because during the update process an error is generated if the file system contains more files than what is provided in the BOM. But the idea is still sound :)

Program arguments : pre.bom, directory containing the extract patches (cpio -i <archive.cpio), target.bom to be created and / if running on the iPhone

// Checkpatch - Sample update BOM cleaner - v0.1
// Zf for iPhone Developers Wiki
// Licensed under GPLv2

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include "bom.h"

int main(int argc, char **argv) {
BOM src, dst;
BOMEnumerator bomEnumerator;
BOMFSObject bomObject;
char *root_dir = NULL;
int count=0, errors=0;

if (argc < 4) {
printf("Usage: %s src_BOM patches_dir target_BOM [root_dir]\n",
argv[0]);
printf("\nCreate target_BOM a reduced version of src_BOM "
"containing only the references to patches_dir patches."
"\nChecksums are validated against root_dir if given\n");
return 1;
}

src = BOMBomOpen(argv[1], 0);
dst = BOMBomNew(argv[3]);
if (argc >= 4) {
root_dir = argv[4];
}

if (!src) {
printf("Couldn't open %s", argv[1]);
return 1;
}
bomEnumerator = BOMBomEnumeratorNewWithOptions(src, 0, 1);
if (!bomEnumerator) {
printf("Open enumerator failed\n");
return 1;
}
while ((bomObject = BOMBomEnumeratorNext(bomEnumerator))) {
BOMObjectType fsObjectType;
unsigned int expectedCRC;
char found = 0;

fsObjectType = BOMFSObjectType(bomObject);
if (fsObjectType == BOMFile) {
char patchPath[400];
sprintf(patchPath, "%s/%s.patch",
argv[2],
BOMFSObjectPathName(bomObject));
found = (access(patchPath, F_OK) == 0);
}
else
if (fsObjectType == BOMDirectory) {
char patchPath[400];
sprintf(patchPath, "%s/%s", argv[2],
BOMFSObjectPathName(bomObject));
found = (access(patchPath, F_OK) == 0);
}

expectedCRC = BOMFSObjectChecksum(bomObject);
if (found && root_dir != NULL && expectedCRC != 0) {
char rootPath[400];
unsigned int computedCRC;
sprintf(rootPath, "%s/%s", root_dir,
BOMFSObjectPathName(bomObject));
if (access(rootPath, R_OK) != 0) {
errors++;
fprintf(stderr, "%s not found\n",
rootPath);
found = 0;
}
BOMCRC32ForFile(rootPath, &computedCRC, NULL);
if (computedCRC != expectedCRC) {
errors++;
fprintf(stderr, "CRC mismatched for %s "
"expected %u got %u\n",
rootPath, expectedCRC, computedCRC);
found = 0;
}
}

if (found) {
count++;
BOMBomInsertFSObject(dst, bomObject, 0);
}
BOMFSObjectFree(bomObject);
}
BOMBomEnumeratorFree(bomEnumerator);
BOMBomFree(src);

BOMBomCommit(dst);

if (root_dir == NULL) {
printf("%d entries added. No consistency check done\n",
count);
}
else {
if (errors) {
printf("%d entries added, %d errors.\n"
"VALIDATE BEFORE PATCHING !\n",
count, errors);
}
else {
printf("%d entries added, good to go :)\n",
count);
}
}

return 0;
}

== Update utilities ==

A set of utilities to manipulate update files on the iPhone is provided - current version 0.1 available here http://dl.free.fr/aqIyfnGZU/iPhone-update-utilities-0.1.tar.gz

These utilities should be trivial to port to OS X.

=== Utilities currently provided ===

bspatch Port of bspatch used to apply specific update patches
extracted from the cpio archive
bspatch [original file] [patch file] [target file]
The original file and target file can be the same

getUpdateKey Retrieve the update key used to decrypt libupdate_brain.dylib
(and subsequent data files : boms and the main archive)
Run without parameters or with the path to a specific
kernelcache

listBOM Very simple lsbom - list the contents of a BOM file

checkBOM Validates BOM checksums against a list of files
checkBOM [BOM file] [path to root]
On the iPhone path to root will be /

reduceBOMPatch Create a reduced BOM limited to files matching a patch set
reduceBOMpatch [source BOM] [patch dir.] [target BOM] [path
to root (optional)]
If a root path is provided the BOM files checksum will be
checked against the local filesystem

== Early alpha: applying an update without wiping modified content ==

The following steps were used to update from 1.0.1 to 1.0.2 without wiping everything. It's still not user friendly, and buggy, but you can try to follow them and report your ideas to improve it

=== Pre-steps (to be performed once or once per update) ===

# Install your own Software Update certificate. This will block Apple automatic updates (interesting side effect :p) but more importantly allow you to install your own.

The file to replace is /System/Library/Lockdown/iPhoneSoftwareUpdate.pem

# Obtain your current update key according to your kernel cache version

Run getUpdateKey on the iPhone and copy the result

=== Preparing the update files ===

# Obtain your update file from iTunes, do not install it. The file name should be iPhone1,updateVersion_initialBuild_to_updateBuild_Update.ipsw

# Unzip it

# Decrypt archive.cpio.gz, libupdate_brain.dylib, pre.bom, post.bom with

openssl enc -d -aes-128-cbc -K update_key -iv 5468656950686F6E654C6F7665735500 -in encrypted_file -out decrypted_file

# Extract archive.cpio.gz with gzip -d archive.cpio.gz ; cpio -i < archive.cpio

(here you could choose specific patches to install, remove the baseband update, and so on ... but this first version is complicated enough :P)

=== Generating the modified BOMs ===

# Copy the obtaines patches/ directory, pre.bom, post.bom to the iPhone, for example in /tmp/upd

# Prepare the reduced pre BOM: from /tmp/upd run

reduceBOMPatch pre.bom patches/ pre.bom.reduced /

If you get a checksum warning - fix it (for example reinstall the original lockdownd if it was modified)

# Prepare the reduced post BOM : from /tmp/upd run

reduceBOMPatch post.bom patches/ post.bom.reduced

# Upload back pre.bom.reduced and post.bom.reduced to your computer

=== Patching libupdate_brain.dylib (temporary step, ugly hack, and so on) ===

Several controls are made on the BOM file that are not patched correctly - local supplementary files should be merged with the BOM in the visited directories.

For the moment patching libupdate_brain.dylib to remove the control (call to verify_uberbom) is faster :)

The following patch is valid for the for the 1.0.2 update and probably below

Comparing files libupdate_brain.dylib and LIBUPDATE_BRAIN.DYLIB.MODIF
000059CC: BE 00
000059CD: F2 00
000059CE: FF A0
000059CF: EB E3
00006670: 95 00
00006671: EF 00
00006672: FF A0
00006673: EB E3

=== Preparing the new update archive ===

# Rename pre.bom.reduced pre.bom and post.bom.reduced post.bom.

If you did some modifications to the patches, put them back in the gzipped cpio archive. Have the original Info.plist ready as well

# Edit Info.plist, set the Encrypted key to <false/> OR process to 2b)

# Encrypt pre.bom, post.bom, libupdate_brain.dylib and archive.cpio.gz with the following command

openssl enc -e -aes-128-cbc -K update_key -iv 5468656950686F6E654C6F7665735500 -in cleartext_file -out encrypted_file

# Edit Info.plist and update the base64 digests for each modified component. You'll obtain the new digest with

openssl sha1 -binary file_to_check | openssl base64 -e

# Generate Info.plist.signature with your own private key associated to the update certificate you replaced with

cat Info.plist | openssl dgst -sha1 -key /path/to/your/private/key > Info.plist.signature

# Zip back all files and replace iTunes ipsw

=== Running the update and checking all is fine ===

# Connect to iTunes and install the update. If you're prompted to restore, you lose :p

# Upload post.bom.reduced to /tmp/upd on the Iphone and run from /tmp/upd

checkBOM post.bom.reduced /

You should not see any checksum error. If you see some, report the problem, it means that some patches have not been applied.

# If some patches are missing, upload them on the iPhone in /tmp/upd and run

bspatch /file/to/patch /tmp/upd/patch_content /file/to/patch

# Revalidate with step 2)

If you still see checksum errors, go buy a Nokia :)

== Sample pre BOM list between 1.0 and 1.0.2 ==

See http://www.pastebin.ca/668944

The checksum is the last big number before the date. It's a typical CRC 32 checksum than can be checked with GNU cksum

Talk:Tutorial:Mounting the Ramdisk of IPSW in Betas 4-7

2008-07-29T14:47:04Z

Pumpkin: New page: How is this decrypting when there's no crypto involved? See satire at pumpkinpat.ch kthx

How is this decrypting when there's no crypto involved? See satire at pumpkinpat.ch kthx

Main Page

2008-07-28T09:10:01Z

Pumpkin: /* Boot Chain */

<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>
[[Disclaimer]]
</td>
</tr>
</table>

Welcome to the iPhone wiki. This is a conglomerate work of everything done by everyone on the iPhone. Anyone can post here, just create an account. This is needed to avoid spam.

Read the [[constitution]] to understand why this wiki was created.

Note: There are inaccuracies in the constitution, but that page is not editable ;(. Every page is editable in a "true" wiki.

Read [[Up to speed|this]] to get up to speed in the iPhone community. Read the [[timeline]] to see where we are.

If you have notes on something you did, post them here. Even if it isn't pretty.

If you have a fix for a problem people are having, post it here.

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

==App Processor(Jailbreak)==
* [[S5L8900]]

===Exploits===
* [[Restore Mode]]
* [[jailbreakme]]
* [[symlinks]]
* [[Ramdisk Hack]]
* [[pwnage]]
* [[diags]]
* [[pwnage 2.0]]

===Boot Chain===
[[VROM]]->[[LLB]]->[[iBoot]]->[[Kernel]]->[[System|System Software]]

===Upgrade Process===
[[VROM]]->[[DFU]]->[[WTF]]->[[iBoot]]->[[Kernel]]->[[Ramdisk]]->[[Restore Mode|Restore]]

==Baseband(Unlock)==
* [[S-Gold 2]]
* [[X-Gold 608]]

===Exploits===
* [[SIM hacks]]
* [[Fakeblank|Hardware Fakeblank]]
* [[IPSF]]
* [[Minus 0x400]]
* [[Jerrysim]]
* [[Minus 0x20000 with Back Extend Erase]]

===Theoretical Attacks===
* [[NCK Brute Force]]
* [[Baseband JTAG]]

===Boot Chain===
[[Baseband Bootrom|bootrom]]->[[Baseband Bootloader|bootloader]]->[[Baseband Firmware|firmware]]

==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]]

==Application Development==
* [[Toolchain]]
* [[Frameworks]]
* [[Apple Certification Process]]
* [[Distribution Methods]]

==Tutorials==
* [[Toolchain Tutorial]]

==Definitions==
* [[jailbreak]]
* [[activation]]
* [[unlock]]
* [[baseband]]
* [[bootloader]]