Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi there,
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest
UltraSn0w 0.9 is out
-
16-07-2009 9:10am#1Appears to resolve power issues some people are experiencing, so if your getting poor battery life after unlocking it would be worth upgrading to this version..
From Iphone dev Blog
Short version:
ultrasn0w version 0.9 is out! We believe it solves pretty much all of the various random issues that have been reported. Its features include:
•Works on both 3G and 3GS
•Works on hacktivated devices
•Works regardless of how you jailbroke your device
•Doesn’t patch any mach-o binary whatsoever. (Doesn’t require a separate patch as each new firmware comes out).
•Doesn’t install any additional daemon
•Has no race conditions, no popups about “Missing SIM”, no network issues
•Is almost 7000 times smaller than its nearest competition
•Is available now via Cydia. Source repo is http://repo666.ultrasn0w.com (that last “0” in ultrasn0w is a zero!)
Long version:
The day before yesterday, some fellow named geohot released a program called “purplesn0w” which claims to be a better unlock than our ultrasn0w unlock released last month, and our yellowsn0w unlock released 7 months ago. 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 two pretty neat ideas, one more pragmatic than the other for the iPhone. The first is a way of 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?
To put it into perspective, ultrasn0w uses 152 bytes of properly malloc’d baseband RAM, which is 0.015% of what purplesn0w uses. Put another way, purplesn0w uses 6900 times more RAM than ultrasn0w (and doesn’t let the O/S know that it’s using it, so the O/S still thinks it’s free to use. When it does use it, the baseband will crash).
Now, 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!2
Comments
-
-
-
Appears to resolve power issues some people are experiencing, so if your getting poor battery life after unlocking it would be worth upgrading to this version..
From Iphone dev Blog
Short version:
ultrasn0w version 0.9 is out! We believe it solves pretty much all of the various random issues that have been reported. Its features include:
•Works on both 3G and 3GS
•Works on hacktivated devices
•Works regardless of how you jailbroke your device
•Doesn’t patch any mach-o binary whatsoever. (Doesn’t require a separate patch as each new firmware comes out).
•Doesn’t install any additional daemon
•Has no race conditions, no popups about “Missing SIM”, no network issues
•Is almost 7000 times smaller than its nearest competition
•Is available now via Cydia. Source repo is http://repo666.ultrasn0w.com (that last “0” in ultrasn0w is a zero!)
Long version:
The day before yesterday, some fellow named geohot released a program called “purplesn0w” which claims to be a better unlock than our ultrasn0w unlock released last month, and our yellowsn0w unlock released 7 months ago. 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 two pretty neat ideas, one more pragmatic than the other for the iPhone. The first is a way of 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?
To put it into perspective, ultrasn0w uses 152 bytes of properly malloc’d baseband RAM, which is 0.015% of what purplesn0w uses. Put another way, purplesn0w uses 6900 times more RAM than ultrasn0w (and doesn’t let the O/S know that it’s using it, so the O/S still thinks it’s free to use. When it does use it, the baseband will crash).
Now, 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!
I don't get this. Ultrasn0W is an unlock solution, purplera1n is not, its just a jailbreak solution, why are they being compared?
edit: ups, just realised its purplesn0w they are talking about, not purplera1n,sorry.0 -
-
-
Advertisement
-
-
-
-
-
-
Advertisement
-
-
-
-
Advertisement