Working Model
iLiberty+ and iPlus use the same working model:
GUI or CLI uploads payloads to device, then boots a customized ramdisk, the ramdisk does jailbreak and setup AFC for iPHUC/iBrickr, then setup a master script for later operations, when device is rebooted, master script takes control and executes the payloads one by one to finish the other operations. This model is called “2-pass procedure”.
This model offers the most reliability and flexibility.
On the other hand, ZiPhone uses a different working model:
CLI boots a customized ramdisk, the ramdisk does all jobs. There’s no payload concept in ZiPhone because all stuffs are on the ramdisk. This is a “1-pass procedure”.
Difference Between Two Models
As you have seen, there’re 2 models here: 1-pass and 2-pass. I’ll try to describe the cons and pros of the two models.
1-Pass Model
In 1-pass model, all stuffs are stored in the ramdisk, so ramdisk has to finish all the jobs by itself. If the operating system is stable, this will not be a problem. But two reasons limit this model and makes it un-extensible:
Ramdisk Size
You may have already known the ramdisk size cannot exceed 32MB, this is a hard line that you can’t cross, no matter what you want to do with ramdisk, you can’t make it exceed 32MB, this makes it impossible to do some jobs.
Memory Corruption
According to the technique used in booting customized ramdisk, the memory will corrupt if you try to allocate alot of memory during the operations. This can be easily re-produced by trying to extract some large files.
With the above two restrictions, the 1-pass model is obviously a dead-end. With the new firmwares / baseband updates coming, more and more files need to be added into ramdisk, and it’ll eventually reach the 32MB limit. Even all the files can be arranged into the ramdisk, the memory will eventually be used up due to the large request of memory.
2-Pass Model
The 2-pass model also uses the ramdisk, but in a smarter manner which solves the 2 problems in 1-pass model.
Ramdisk Size
In 2-pass model, ramdisk does little (almost nothing) jobs so it doesn’t have to contain many files, actually, if nvram is not required, the ramdisk size can be as small as 5MB or so.
Memory
In 2-pass model, all the real jobs are done through payloads in the real working operating system, so there’ll be no memory corruption issue. The payload can allocate as much memory as it needs without worrying about the corruption as the operating system memory management will deal with it.
Conclusion
From the above comparison it’s easy to tell that 2-pass model is better than 1-pass model. But the 1-pass model can be used in other situations, for example, it’s possible to create a small emergency ramdisk to fix the potential failure during the 2-pass model execution. So iLiberty+ and iPlus win this turn.
Unlocking Methods
Although the theory behind unlocking methods are the same in all three tools. The implementations are different. Technically, there’s no difference when unlocking a phone with bootloader 3.9, but for unlocking a phone with bootloader 4.6, things are different.
ZiPhone
When ZiPhone sees bootloader 4.6, it downgrades it to 3.9 stock version automatically. As far as I can tell, there’s no way to raise your bootloader 3.9 stock to 4.6 at the time of this article is written. So when you have used ZiPhone on a bootloader 4.6 phone, your phone will stay in 3.9 forever unless new method is found.
iPlus
iPlus takes advantages of the bootloader 3.9FakeBlank (by DevTeam), when it sees bootloader 4.6, it downgrades it to 3.9FB automatically. Since this operations is reversable, you may later upgrade to 4.6 or 4.6FB (also by DevTeam) with special software utility.
iLiberty+
iLiberty+ goes further than ZiPhone and iPlus, it utilizes the advantages of 3.9FB as well as gunlock, it can unlock a phone with bootloaders 3.9, 3.9FB, 4.6, and 4.6FB.
For bootloader 4.6 and 4.6FB, iLiberty+ doesn’t automatically downgrade it, it lets user make his/her own decision. If the user doesn’t check “Downgrade bootloader” option, then phone will still be unlocked, baseband will be changed to 04.02.13 after unlock. If the user does check the “Downgrade bootloader” option, then bootloader will be downgraded to 3.9FB first then unlock, and baseband version will not change after unlock. iLiberty+ also uses 3.9FB to downgrade bootloader when asked so it’s reversable as well.
Conclusion
Since iLiberty+ and iPlus gives user a chance to revert back to bootloader 4.6, they both are the winner in this turn.
2-Pass Models In iLiberty+ and iPlus
Although 2-pass models and payloads are used both in iLiberty+ and iPlus, they are arranged in a different manner.
iPlus
In iPlus, all payloads are packed into a ZIP file, there’s only one script to control all the payloads execution, this makes the whole thing tightened together. But if you want to add payload into it, you have to do it in such a way:
1. Prepare the new payloads
2. Modify the master script to process the new payload
3. Repack the payload to add new payloads and update the modified master script
When you want to distribute your modified (update) version, you have to offer the new ZIP file, since all payloads are packed into this single ZIP, its size will be huge when many payloads are bundled. So for a user that only needs some of the functions, the other parts of the payload is simply useless. For example, AT&T users tend to use only jailbreak and Installer, but they still have to download the whole thing even if most of the contents are not necessary to them.
When this comes to online-update system, there’s another problem. Some people (like me
iLiberty+
Now let’s turn to iLiberty+, it tries to utilize the flexibility of iPlus but overcome the disadvantages that the single payload brings. iLiberty+ is designed with the theory:
Make the package as small as possible, and let user choose to download what they want
To achieve the above goal, iLiberty+ is constructed with 2 totally independant parts: the GUI and the payload.
The GUI offers an interface for user to choose what they want, then pack the selected contents into a single ZIP and upload, then boots the ramdisk, its job is done after this.
The payload does the real magic, to make it more flexible, each payload is specifically designed to do only one particular job. So if you want to activate, unlock, and have Installer settled, you have to choose three payloads.
For example, as an AT&T user who wants to jailbreak and install Installer, all he needs to do is selecting Installer and clicking Go (because jailbreak is implied in ramdisk), and he doesn’t need to download anything irrelevant to his purpose.
In fact, if iLiberty+ is distributed without any bundled payload, its size can be reduced to as small as 2MB (without ramdisk) or so. But since most people who uses iLiberty+ are tend to use Jailbreak, Activation, Unlock, Installer, etc. I have packaged these most common payloads into the Setup which raises the size to some 20MB.
The payload distribution in iLiberty+ is relatively easy:
1. Prepare the new payload and its script
2. Put the payload and its script into payload folder under installation folder
As you can see, it has nothing to do with those already-made payloads. You don’t have to distribute a huge modified payload, you just need to add the new payload. This makes the online update easier and more efficient.
source http://george.insideiphone.com/index.php/2...us-and-ziphone/
May 10 2008, 07:58 AM, updated 18y ago
Quote
0.0168sec
0.22
5 queries
GZIP Disabled