The iPhone Dev-Team has updated the UltraSn0w unlock to use some of the good ideas from PurpleSn0w. They have also provided a very detailed explanation of how PurpleSn0w and UltraSn0w work.
-----
The day before yesterday, some fellow named geohot released a program called "purplesn0w" which claims to be a better unlock than our ultrasn0w solution. He was kind enough to provide source, which we naturally took apart to try to validate his claims. ;) We've found he had come up with some pretty neat ideas, including patching the actual text of the baseband code by copying it over to RAM and then using the MMU and page tables to have the baseband pretend it is part of the original bootrom. Of course, like yellowsn0w and ultrasn0w, this code has to be reloaded with every reboot of the baseband. However, the advantage of this is that developing unlocking payloads is a lot simpler - in fact, geohot used the same payload in AnySim and BootNeuter. We kicked around this idea ourselves before, but eventually found a work-around for the same problem with the yellowsn0w/ultrasn0w payload. The two pieces of code have the exact same effect on the baseband - with the difference that geohot's exploit overwrites an arbitrary block of memory one megabyte in size. The baseband has a total of eight megabytes of memory and every bit of it is earmarked for use (except for 485212 bytes of it which we haven't accounted for yet, but that's still less than 1 MB). This means that eventually the area of memory geohot is using will be corrupted and 1 MB of baseband code will be corrupted (until the next reboot). How soon will this happen? Will it even matter in day-to-day use? We don't know, because we haven't spent much time looking. However, why take the risk when the yellowsn0w/ultrasn0w payload accomplishes the same job with no corruption?
The second new idea he had was to patch CommCenter rather than use a daemon. At first, this idea seemed pretty distasteful to us. Binary patches are messy and difficult to maintain (we figure it's partly why he only made a version for 3G S and not 3G as well). In addition, the stated reason of reduced battery life with a daemon is factually incorrect, since any computer science student who's taken a course in operating systems will tell you that a sleeping task takes up exactly NO CPU resources and NO power (it's merely skipped over during context switches). That's right: not "only a little" power, but absolutely NO power. However, ultrasn0w 0.6 did have a problem where the STK refresh command it used crashed the baseband in 3G S. This caused the baseband to continually come up and then restart. That DOES take power and so may explain the issues that people have been seeing. ultrasn0w 0.8 was supposed to have fixed this issue, but perhaps not completely. This is because the STK refreshes we used are inherently unreliable - but we thought they were necessary to avoid people having to reinsert their SIM. Turns out we were wrong on that score. geohot's method shows that we can perform the unlock before CommCenter polls for lock state. When we do it before (instead of after), the STK refreshs are no longer necessary! The only way to do it before the polling, however, is to modify CommCenter. We've tried to make the best of a bad situation by using MobileSubstrate to perform the modification. This lets us modify the behavior of CommCenter without touching the actual binary. We also used a method to dynamically locate the patch location so that it should work on both 3G and 3G S (and should need to be updated less frequently). We also do it in a different way so that hactivated phones will work with the unlock (unlike purplesn0w). You'll find that this update is now available through Cydia as ultrasn0w 0.9 We thank geohot for contributing to the scene once again. We don't think purplesn0w is the right path, but it has certainly helped us improve ultrasn0w!
P.S. geohot, seriously, stop dicking around and look at the bootrom instead kthx. =P
-----
You can find instructions on how to unlock your iPhone using UltraSn0w here.
-----
The day before yesterday, some fellow named geohot released a program called "purplesn0w" which claims to be a better unlock than our ultrasn0w solution. He was kind enough to provide source, which we naturally took apart to try to validate his claims. ;) We've found he had come up with some pretty neat ideas, including patching the actual text of the baseband code by copying it over to RAM and then using the MMU and page tables to have the baseband pretend it is part of the original bootrom. Of course, like yellowsn0w and ultrasn0w, this code has to be reloaded with every reboot of the baseband. However, the advantage of this is that developing unlocking payloads is a lot simpler - in fact, geohot used the same payload in AnySim and BootNeuter. We kicked around this idea ourselves before, but eventually found a work-around for the same problem with the yellowsn0w/ultrasn0w payload. The two pieces of code have the exact same effect on the baseband - with the difference that geohot's exploit overwrites an arbitrary block of memory one megabyte in size. The baseband has a total of eight megabytes of memory and every bit of it is earmarked for use (except for 485212 bytes of it which we haven't accounted for yet, but that's still less than 1 MB). This means that eventually the area of memory geohot is using will be corrupted and 1 MB of baseband code will be corrupted (until the next reboot). How soon will this happen? Will it even matter in day-to-day use? We don't know, because we haven't spent much time looking. However, why take the risk when the yellowsn0w/ultrasn0w payload accomplishes the same job with no corruption?
The second new idea he had was to patch CommCenter rather than use a daemon. At first, this idea seemed pretty distasteful to us. Binary patches are messy and difficult to maintain (we figure it's partly why he only made a version for 3G S and not 3G as well). In addition, the stated reason of reduced battery life with a daemon is factually incorrect, since any computer science student who's taken a course in operating systems will tell you that a sleeping task takes up exactly NO CPU resources and NO power (it's merely skipped over during context switches). That's right: not "only a little" power, but absolutely NO power. However, ultrasn0w 0.6 did have a problem where the STK refresh command it used crashed the baseband in 3G S. This caused the baseband to continually come up and then restart. That DOES take power and so may explain the issues that people have been seeing. ultrasn0w 0.8 was supposed to have fixed this issue, but perhaps not completely. This is because the STK refreshes we used are inherently unreliable - but we thought they were necessary to avoid people having to reinsert their SIM. Turns out we were wrong on that score. geohot's method shows that we can perform the unlock before CommCenter polls for lock state. When we do it before (instead of after), the STK refreshs are no longer necessary! The only way to do it before the polling, however, is to modify CommCenter. We've tried to make the best of a bad situation by using MobileSubstrate to perform the modification. This lets us modify the behavior of CommCenter without touching the actual binary. We also used a method to dynamically locate the patch location so that it should work on both 3G and 3G S (and should need to be updated less frequently). We also do it in a different way so that hactivated phones will work with the unlock (unlike purplesn0w). You'll find that this update is now available through Cydia as ultrasn0w 0.9 We thank geohot for contributing to the scene once again. We don't think purplesn0w is the right path, but it has certainly helped us improve ultrasn0w!
P.S. geohot, seriously, stop dicking around and look at the bootrom instead kthx. =P
-----
You can find instructions on how to unlock your iPhone using UltraSn0w here.