Okay, after some digging around I found out the following:
1) carrier bundle updates are performed by MobileInstallation, the same framework that is responsible for installing apps;
2) carrier bundles are installed to ~/Library/Carrier Bundles. This directory does not exist by default, but gets created by MobileInstallation automatically.
I tried installing my custom bundle to ~/Library/Carrier Bundles (full path: /private/var/mobile/Library/Carrier Bundles) instead of /System/Library/Carrier Bundles and it worked perfectly. The settings took effect immediately after restart, no sim card shuffle was required.
It appears that ~/Library gets scanned first, so it's great news for people who are on one of the officially supported carriers but want to customize their bundle and still be able to restore the original settings.
So, to sum it up:
1) shell script is not required, because we don't have to worry whether there's existing bundle or not;
2) everything else remains the same, including symlink, just replace /System/Library/Carrier Bundles with ~/Library/Carrier Bundles.
This does not work, if you are on one of the million other carriers. The reason is pretty simple: The bundle gets identifies by the MCC/MNC (the name of the symlink to the carrier bundle). On other carriers this symlink is missing - so it aint work. The symlink is created by the script that comes with my custom carrier bundles.
The solution was - on first - made for users on all carriers but mostly on carriers that are not supported by Apple. This is still the case. If you are on one of Apples partner carriers you can use my solution aswell of cause. But you can use the workaround aswell then.
That makes perfect sense. Thanks V.
From the point of view of CoreTelephony.framework (it is responsible for processing carrier bundles), there's no difference if the SIM card you inserted belongs to official carrier or not. It just does the following:
1) read the MCC/MNC
2) look in ~/Library/Carrier Bundles for symlink matching MCC/MNC
3) if it exists, read carrier bundle from the linked directory
4) if it doesn't exist, look in /System/Library/Carrier Bundles for matching symlink
5) if it exists, read carrier bundle from the linked directory
6) otherwise, read Unknown.bundle.
Let's take 2 scenarios.
1. Your carrier is one of the officially supported, such as T-Mobile DE (whether you actually have an iPhone plan doesn't matter).
In this case you upload the files to ~/Library/Carrier Bundles/TMobile_Germany.bundle and create two symlinks 26201 and 26206 in ~/Library/Carrier Bundles pointing to TMobile_Germany.bundle.
The original files in /System/Library/Carrier Bundles/TMobile_Germany.bundle remain untouched. In case you want to go back to the original version you just delete the folders/symlinks in ~/Library/Carrier Bundles.
Note that no file replacement or overwriting is required, hence the script that runs on startup and checks if the symlink already exists isn't necessary.
2. Your carrier is not officially supported by Apple, so there's no existing bundle.
In this case you can put the files/symlinks either in ~/Library/Carrier Bundles or /System/Library/Carrier Bundles. Both will have exactly the same effect. Though I'd prefer the former, because you won't lose your settings when upgrading, e.g. 2.0.1 -> 2.0.2.
blackboxxx, lets put this discussion to an end here please, it starts confusing readers.
On your solution - just using a different directory - users on a non supported carrier have to create a symlink via SSH on the iPhone and copy the bundle into, same for users on a supported carrier. There is no advantage to the standard bundle you can download from the webservice I use
For users not wanting to SSH or SFTP into the iPhone i have the pwnage compatible bundles, hasslefree but you have to create custom firmware and apply it. That way will also work on future updates as long as Apple does not completely change the model. When using this one the custom LaunchDaemon is absolutely necassary, otherwise you can't execute a script on the iPhone to create a symlink without SSHing into. It's the way the Dev Team uses on their own bundles.
Last not least, remember your post #14 in this thread "I hope we will discover a way to install carrier bundles via iTunes, because it's so much easier than ssh or re-pwning".
THAT would be an advantage and a way to go. Injecting a custom carrier bundle via iTunes including a script that automates the creation of the symlink if needed. I still dont know how-to.
If you want to follow on this topic please start another thread on this, we dont want to confuse users here.
volkspost, I don't want to get anyone confused too, but I want to remind you that I started this discussion with the suggestion about tar bundles.
I understand that the official PwnageTool on a Mac uses zip files with a plist inside, and that format doesn't allow symlinks and therefore script is necessary.
However, Winpwn and XPwn support .tar files, and QuickPwn uses gzipped tars. This format supports symlinks and preserves custom permissions.
Referring to your previous post,
So, again, thanks for your hard work on carrier bundle generator, it's an awesome tool, and I'm looking forward to see .tar bundle support as well.
My question is addressed to Vokspost.
After I pwned mu iphone 2G to 2.0.1 I am unable to select carrier partners manually in settings. It shows my default carrier as Vodafone however on manual network carrier selection I get just searching.... with spindle.
Can you help me . tks
Similar situation in Winpwn. If the symlink is not already on the iPhone cause you are not on Apple's partner carriers, you have to create the symlink - no matter where the bundle is sitting.
Remember: All the files, the bundle and the carrier logo are created on my webserver via PHP and GDlib. So I cant create a symlink on the server, that wont work. Thats why I choose to use the LaunchDemon and script 8.sh9 that is working on PwnageTool.
On the tar version for windows I do have another problem that does not apply to the PwnageTool version. With Winpwn the owner and group of files and script are not changed by the function that allows adding custom bundles. On the Mac version they are set to root:wheel, working for the iPhone. On Wonpwn they remain as produced by the webserver, something like 25999:nobody, no way to change that on the webserver, chown and chgrp are not allowed...
Anyway, I'll give you a link later via pm, you can play around with.