It applies to just the 3GS, so far anyway. ECID is still relevant, even if you have a jailbreak, because you cannot downgrade if you are on a stock firmware and do not have a decrypted copy of the images. A bad example would be if you were jailbroken, which may rely on an exploit in the 3.0 7A341 iBoot. If your phone came stock 3.0.1 or you updated to a stock 3.0.1, you would (in theory) not be able to downgrade to 3.0 again without a decrypted copy of your images. So, if your phone came 3.0 stock and you jailbroke it, then updated to stock 3.0.1 without a dump of your images, you're potentially stuck. If you bought a phone with 3.0.1 on it and the bug was fixed (this is of course, assuming it only exists in the 3.0 7A341 iBoot), you were done when you purchased the phone. Other potentially dangerous stuff is SEPO, which Apple could potentially use in tandem with different batches of devices. Say from week X to week Y have a vulnerability (because they shipped with a vulnerable firmware), the next batch, week Z and week A, could be altered to have an updated epoch. If a vulnerable image (say an image from the current firmware, 7A341) has a different epoch (one older than the epoch defined on the phone), the image won't run. Nothing else has to be updated really, just the epoch needs to be changed. This means no new bootrom has to be shipped. I do not know where the epoch information is stored (I assume in the NOR), but it should be easy to update, since there are already two different values for the iPod 2G. Remember the whole 2.1.1 iBSS not liking newer devices? I believe that whole fiasco may have been caused by the new epoch, but this hasn't been explicitly stated by any Dev Team member. I don't know if brute force is really an acceptable route, since I assume Apple would not be dumb enough to use a key that weak. The whole server thing kind of seems weird to me, because that means the phone relies on Apple's servers, which is somewhat dumb. It would make a lot more sense if the process was done on-device and the image was modified by iTunes, but there are little details on the whole process. Hopefully we'll see more details emerge soon enough.
We could start a distributed computing project like seti@home to crack Apple's key. They need to sign the modified img3 somehow. If they do it on-device they have to somehow store their precious key on the device. And they are probably too afraid that someone might find a way to get to this key.
Well, by your logic, we would have already extracted both the GID and UID keys from each device. However, we haven't and probably won't ever. They cannot be brute forced and they haven't be obtained from the phone through any type of attack so far, so they probably won't be any time soon.
wow they already did this? in a couple days? it took the ipod touch 2g like 5 months to get a tethered jailbreak haha. C'mon apple learn from your mistakes!
Just because it has not been done yet, does not mean it is impossible. Dunno what the GID and UID keys are for (and I am too lazy to search), but I guess Apple's signing key would be a tad more important and thus someone might be motivated enough to try even if it means trashing your iPhone by hardware modding it.
Well, they aren't stored in memory and aren't exactly lying there on a chip, ready to be dumped. The situation is comparable to consoles; they use lots of different encryption keys, but they aren't all dumped because most of them aren't possible to dump by feasible means. And, maybe you should do some research. The GID and UID keys aren't just some stupid keys that are barely used; they GID key is a universal key (well, universally the same for each processor) used to encrypt various things, namely images. Now, if there are three processors and they each have a GID key, why hasn't each been dumped so there is no need to use the AES engine anymore? Oh yeah, because it's not exactly easy (and likely impossible altogether). The UID key is used to encrypt things on the NOR and is unique to your device. Obviously, this isn't published anywhere because it's unique. There are other encryption keys, like the NCK, which haven't been brute forced either. The NCK is used to encrypt an unlock token, which is then sent by Apple through iTunes to perform a valid unlock. Now, you'd think this would be brute forced, since it's only 15 characters? Wrong. Instead, vulnerabilities are found within the baseband as a workaround, because the NCK cannot be brute forced, just like many other encryption keys.
