INTRODUCTION
I use my iPhone. I use it a lot. Not just a lot... I use it for everything. So when something happens to it, (like a boot failure) I am forced to use my nerd powers for good. First of all, there has been a lot of chatter in the jailbreak community lately, with the recent Spirit jailbreak, including info surrounding iPhone Firmware OS 4.0 Beta, and the recent ability to jailbreak version 3.1.3. However, to get around some problems to make this happen, Saurik made a lot of changes to Cydia and how it acts as a proxy to activate an unsigned jailbroken phone. But this didn’t, and hasn’t gone smoothly. In fact, a lot of people were left with unbootable iPhones after certain packages were pushed from Cydia and RockApp.
Mine was one of them. Including my wife’s iPhone. Now normally I don’t get involved with actively participating in the jailbreak community, dev-team, and/or forums. But not only being affected, personally, by a poorly tested package lacking oversight from both Cydia and Rockapp, I saw the damage it caused around the web for everybody else. And to make matters worse, nobody had a clue how to actually FIX the problem. Instead, the only advice ever offered was to do a restore and hopefully restore from your last backup. But many of you are just average joes where technology is concerned, and put a lot of trust in to the jailbreak community. Trust, that packages would be updated reliably, and you could feel comfortable taking pictures and videos without a backup. That TRUST was violated when an /sbin package was made available by Cydia and Rockapp. The real problem lies with the author/maintainer of said package. There are some other problems too. Seemingly, updates which affected how MobileSubstrate loads and handles Dynamic Libraries. (DYLIBs) Those who didn’t have a problem with the /sbin update, were most likely impacted by something related to MobileSubstrate. Luckily, I had both scenarios occur between my wife and myself. My phone had a problem with MobileSubstrate, and my wife had the dreaded “shut off” after 7 seconds during boot. This blog is focused on FIXING these problems without doing a full restore and wiping your data. In fact, I put together a little program which makes this whole process painless and “revives” the device to it’s exact working state before the /sbin update was applied to your phone. None of your settings, data, media, pictures, music, videos, jailbreak, or unlock is lost. Nada. Zip.
BACKGROUND
First and foremost, a little background. I am a full time I.T. Professional with 12 years of on-the-job Network Engineering/Administration and Software Development experience for a variety of different companies. I have been interested in technology since I was a child. Tearing things apart, figuring out how things worked. Writing my first software programs at age 13 and doing just about anything related to everything in technology. Now I’m married and have a happy baby boy and beautiful baby girl. So when my wife updated her phone with the latest packages over Mother’s Day weekend and it failed to boot thereafter, we had a real problem. There were over 1,080 picture and videos she took with her phone alone of our children. Itunes is annoying and frustrating at times, and we generally have no need to sync. There was no backup of this data. We could talk about the importance of backups until we were blue in the face, but it didn’t change the fact that an iPhone restore was simply not an option. I had my work cut out for me. I hope many of you can take solace in the fact that I too, had much to lose, and you can trust that I take this as serious as yourself. There is no ill-intent here. I am just like you. And where pictures are concerned............ Terrified.
WHAT CAUSED THIS BOOT FAILURE?
Now for an explanation. I find it always helps to provide as much information as possible so people can make informed decisions and/or form their own opinions. In this particular case, I believe it is important to understand what happened, what updated, what went wrong, why it’s broken, and the solutions to fix it. Knowledge is power my friends, and I would be doing you a disservice if I didn’t at least ATTEMPT to explain what caused this in the first place. With this knowledge, it will greatly assist with the success of applying a fix, so you will be able to (hopefully) make informed decisions in the event something needs your attention which I couldn’t possibly foresee or include in these instructions. Please take the time to read what I’m saying and process it. Trust me, you can’t go wrong here.
Over the last week or so, a package for /sbin was made available through Cydia/Rockapp. These packages are NOT “automatically downloaded” and patched in to the system. In most cases, people ignore the need for updates until the little circles with numbers bug them enough, or they are installing/fixing another package and download all. So this issue isn’t isolated to one particular moment in time per se, but rather when each individual got around to installing new updates. Furthermore, the “window” for this is during the time when the package was still available! Since a flood of problems were reported in, RockApp for example pulled the package. That’s great for the huge majority of you who dodged that bullet, but some of us weren’t so lucky.
Briefly, /sbin is a subfolder on the filesystem of your iPhone. It’s located on the root level (/) as “sbin”. This is a common unix based “standard” for storing critical operating system binaries. Unix, Linux, BSD, Macs, iPhones, you name it, use this folder in some fashion. For windows users, the best way for me to describe it in terms you will understand... It’s pretty much like your “C:WindowsSystem32” folder. Yeah, important right? Definitely. And it was patched for “some reason” by the maintainer of this package. I can’t say for sure what was changed, and why, but this much detail is irrelevant. Whatever it was, no matter how it was done, screwed up one of the most critical folders on your iPhone. The folder just so happens to contain binaries used by the iPhone in the first few seconds during boot time.
FIGURING OUT THE PROBLEM AND COMING UP WITH AN IDEA
It didn’t take me long to figure out something was horribly wrong with /sbin. Mostly, because I have over 560 apps on my iPhone (yes, all paid... It’s a bad habit, trust me.) and my phone takes EXCEPTIONALLY long to boot after a crash of some kind. Why? Because Apple keeps track of a clean boot and shutdown process. If there was an unexpected crash, the first thing they do before nearly ANYTHING, aside from loading the kernel and some memory runtime modules, is immediately run a File System Integrity Check on your data partitions before mounting them. This tool is a common tool in nix based distribution, almost always called “fsck”. And guess where the binary for “fsck_hfs” is located? Yep, /sbin.
My phone takes 5 minutes to boot after a crash. Mostly, due to the time it takes for fsck to finish it’s integrity check of all that information contained on the filesystem. When /sbin was screwed up by the maintainer, there was no way for the iPhone/Kernel to call the fsck binary. The iPhone has a “WTF?” moment and immediately shuts off. (Hey, wouldn’t you do the same?) This was a big “aha!” when even my iPhone would shut off between 5-7 seconds during boot time. I KNEW what it was SUPPOSED to be doing, but it wasn’t doing it. This little bit of information was all I needed to come up with a fix.
WE HAVE TWO OPTIONS AT THIS POINT:
A.) Forensics style. Create your own custom RAMdisk/Payload with all the required signature decryption, successfully transmit this payload to the iPhone with SSHD functionality, run ‘fsck_hfs –r /dev/disk02s’ to manually perform the integrity check, mount the partition, open an SSH session to the iPhone, listen for raw disk data on a receiving computer over wireless with ‘netcat’, and finally dump the raw image data on your phone using ‘dd’. A bit technical? Indeed. I don’t expect you to understand all of that. In fact, you’re not required to. It’s to the drive the point home.... That’s stuff for geeks like me. Especially those in law enforcement. A forensics division. And to be honest, I would rather not go through more work than necessary to fix my wife’s phone. (I do rather enjoy having a comfy bed to sleep in at night) Furthermore, going through all of this, you would then need to structure the ‘dd’ dump of the image in a format so it can be mounted and then the media (pictures,videos,music) data browsed to and extracted manually. Then what? Restore the device, start over, and transfer all of this back? I know what you’re thinking.... If that’s what I have to do to, then I’ll do it. However, I came up with a much more simple and clever solution...
B.) Oh, I get by with a little help from my friends. (Did you catch the beetles reference? Good song.) I guess I could give credit to the Beetles for solving this problem. Because with a little help from our friends in the dev community, they have already figured out all that nitty gritty forensics, hacking, magical, whatever you want to call it, trickery. Afterall, the same tools and process with a few exceptions is how jail breaking actually works. So why reinvent the wheel? I decided to borrow the technology from the good guys at redsn0w as my preferred choice of dependable tools I could trust. (Not available at Home Depot) Jokes aside, there is a good reason for this.
THE SOLUTION AND WHY
Redsn0w is yet, another variety of jailbreak software specifically designed to jailbreak an iPhone and/or unlock it for use with other GSM carriers. The reason I’m using redsn0w is due to the following:
1.) It allows a jailbreak without completely loading a full IPSW (iPhone Software) to the phone during the jailbreak. It creates a very special payload and kernel from a SUPPLIED IPSW and tosses everything else aside. It just needs enough information to create a “hole” for the jailbreak process. You already knew this, but what is important to know, is we can re-jailbreak all we want without affecting any of our data. No restore. No wipe.
2.) It supports both jailbreaking and unlock. If I was going to make a tool to help others, I needed to make sure those who unlocked their iPhone can retain that ability.
3.) It is compatible and re-jailbreaks an iPhone successfully, even if you used Blackra1n when you first jailbroke the device. And it properly communicates with a 3GS, with or without the new bootROM. This is very important because we SOMEHOW need a tool to WRITE data to the iPhone from DFU/Recovery. Because, obviously, booting up the normal way is not an option.
4.) My clever trickery. Since I knew /sbin was screwed up, I knew the only thing needed to solve this problem was to.... Well, fix /sbin. How? Simple. I grabbed my other iPhone, turned on Wi-Fi/SSH and used SCP to copy the entire /sbin directory off the phone and on to my MacBook Pro. Still don’t get it? Let me explain why redsn0w is our friend. Mac applications (like the iPhone) have apps stored in a format like “redsn0w.app”. While they look and respond like a standard windows EXE when you double click them, they are nothing more than a DIRECTORY containing the actual binaries, resources, plists, and configuration files. redsn0w was developed cleverly, because they wanted to make it easier on themselves by “packaging” jailbreak software, such as Cydia in to a compressed tar.gz. See what I’m getting at?
Inside the redsn0w.app there exists a file called “Cydia.tar.gz”. When you step through the redsn0w jailbreak process, you will see a checkbox labeled “Install Cydia”. Rather than hard coding path names and all sorts of other things inside the binary, they chose to deploy the package using the compressed archive. What does this mean for us? We can modify the archive and put anything we want in there. See where this is going? I now have a slick (and deployable) method for “patching” /sbin with a good copy from my other iPhone.
CONCERNS
The ONLY question which remains in my mind, is the difference in /sbin between iPhone OS versions. I don’t know how often these files were modified through subsequent generations, but it COULD be minimal. Most of these files are very standard OS binaries and generally don’t need to be changed. What I’m saying is, the only thing that I am aware of that could screw up this patching process is if the /sbin binaries (from my 3.1.2 iPhone) didn’t work properly with a different version loaded on your iPhone. So I guess we are going to find out and see! Don’t be timid on this either. The /sbin directory is already screwed up anyway, so we’ll get it fixed one way or another. In the worse case scenario, you will just need to find an /sbin matching your installed version. This is something I will help with for each version if this ends up being a problem. So don’t worry.
DO-IT-YOURSELF METHOD
I modified the compressed archive by adding the /sbin folder to it. For those of you watching at home and like to “do-it-yourself”, I need to mention something here. It is absolutely critical you MAINTAIN the permission ACL’s on all of these files. Generally when copying things around in Mac, or running command line tools to extract data from tars, the default is to rewrite the permissions for all extracted files with the currently logged in user. Meaning, if you added /sbin without fixing the permissions FIRST, the iPhone will not have permission to execute or access the /sbin folder and/or binaries. So make sure you set the owner using “chown root:wheel” on all of these files. MOST files will also have permissions “chmod 555” with exception to a few. Also, the last file listed, ‘umount’ is STICKY. It’s hard to see because it blends in, but make sure you set it to “chmod u+s umount” Also pay attention to the TOP-LEVEL permissions for the actual /sbin folder. From here, (assuming the /sbin folder is in the same folder as Cydia.tar.gz) you will execute the commands from the shell:
gunzip Cydia.tar.gz
tar —update —file=Cydia.tar sbin
gzip Cydia.tar
I don’t expect you to follow the above paragraph or do this yourself. But I want to explain what I did so you understood. You can see how this method allows you to create entirely custom jailbreak distributions with whatever you needed uploaded to the phone during the jailbreak. But you can also see how somebody with malicious intent could distribute redsn0w by linking to it, with custom tools or backdoors to steal your data. Remember this going forward.
Now, I accomplished this task using Mac OSX Leopard, and haven’t tackled a windows version. I need to boot in to my Windows 7 partition and play with it. I believe the redsn0w binary is a standard .exe with no installation. So if this is the case, the compressed archive is compiled in as a resource, or worse... Hard coded. This sort of throws a wrench in the works for Windows users, but I will see what I can do. Like I said, I haven’t looked at it yet.
DONATE
Out of the goodness of my heart, I uploaded the latest redsn0w 0.9.3 (0.9.4 is experimental for OS3.1.3, so i'm avoiding it) with a modified Cydia.tar.gz archive containing an /sbin folder from a 3.1.2 iPhone. I was hesitant about doing this because it’s a 15M file and there are a LOT of people with this problem. Web hosting is not cheap, but I wanted to do what I could to help all of those who were feeling pretty hopeless. If all of this works for you and you want to help me with the financial implications of hosting and time spent, you can send donations via paypal to bj@hahnlink.com. How much were all those pictures worth to you? Priceless I’m sure. A little bit goes a long way, and your support will help me and family going forward. With that said, you can download my modified redsn0w by clicking here.
THE STANDARD/EASY MAC INSTRUCTIONS FOR FIXING THE BOOT PROBLEM
THIS IS FOR MAC ONLY! I am currently working on a windows version of some kind to send this payload. I will update this blog and keep you posted. I have been spending a lot of my time in the *****i.com forums, and you can track this thread:
[SOLUTION] iPhone shut off during boot / Stuck Apple Logo
1.) Download my modified redsn0w.
2.) Download the CURRENT IPSW for the iPhone OS software loaded on your phone. The version number is the same for both 3G and 3GS. So make sure you pay attention when you download the IPSW and get the right one for your device. You can get those here NOTE TO SAFARI USERS: I had a problem download those directly inside safari, because it started loading the data in to the web browser instead of downloading the file. Right-click save-as doesn’t work for me either. So I just used Firefox.
2.) Plug your iPhone in to your Mac using the USB cable.
3.) The phone is probably off. Push the sleep button for 1 second to turn it on. Now hold down the sleep button + home button simultaneously for 6 seconds or so. When the phone shuts off, keep holding, until you see the Apple logo appear again. As SOON as you see the apple logo appear, release the sleep button while continuing to hold HOME. If done properly, your phone will enter in to Recovery Mode and you will see a picture of a USB cable and text indicating a connection to iTunes.
4.) Run my modified redsn0w.
5.) Browse for the IPSW file you downloaded and continue.
6.) If redsn0w asks you whether or not you have a “New Bootrom” 3GS, you will be on your own here. If you have one of the earlier first-batches of 3GS from Apple, you have the old bootroom. But somewhere around week 24 the 3GS was updated with a new bootrom. Make sure you answer that question correctly.. I have no idea what could/what/will happen if answered incorrectly. In my opinion, the safer option would be answering yes to the new bootrom. This will probably be the majority of cases out there.
7.) On the next screen, make sure “Install Cydia” is checked. Yes it will put cydia back on there, and you may have to update cydia again. Or remove it after your phone boots. Just make sure this is checked, because our fixed /sbin is inside the Cydia archive. There are probably better ways to do this, using the other archives. But I wanted to make sure it would be safe and work.
8.) Continue with the jailbreak. Don’t worry, it’s rejailbreaking, but it’s NOT restoring.
DONE!
When you see the pineapple and progress bar, there will be a point around 70% where it mentioned “synching filesystem”. If the phone shuts off immediately, the problem isn’t fixed and /sbin wasn’t patched in. This would only occur if you custom did this yourself. If you used my custom redsn0w, then the only explanation for this would be a difference in verions, and from this point I would take more steps to distribute version based redsn0w packages. I will keep an eye on your progress in the *****I.com forums.
Other than that, if it goes past 70% and reboots at 100%, your phone SHOULD boot normally.
WHAT TO EXPECT
A fully working phone, just as you left it. No restore necessary. No data retrieval necessary. No SSH necessary. The phone should be working perfectly. You can expect to see Cydia on there again if you had removed it in the past. It may also need an update if you wish to keep it. Other than that, there shouldn’t be any other problems. Even for those who unlocked. But if you see something odd, please feel free to contact me about it or post in the forums. I will work very hard to make sure this process is as painless and trouble-free as possible...... No thanks to the maintainer of the /sbin package.
WHAT TO DO IF IPHONE IS REBOOTING AFTER A FEW MINUTES
For those of you running in to problems AFTER boot, and a stuck Apple Logo (most likely with indefinite rebooting) you have yet, another problem to resolve. It’s most likely a substrate DYLIB problem. Standard procedure here:
1.) open a ping window and continually ping the iPhone IP to monitor when it’s up.
2.) Use SSH and connect as SOON as it replies from your pings
3.) Now do the following:
cd /Library/MobileSubstrate/DynamicLibraries
mkdir backup
mv *.dylib backup
If you have RockApp, you should probably do this too:
cd /Library/RockExtensions/DynamicLibraries
mkdir backup
mv *.dylib backup
Reboot the phone and it should boot up and finally make it to Springboard. Please only perform the above procedure if your phone is REBOOTING after sitting on the Apple Logo for quite some time. (Generally minutes) Upon reboot, you will find all of your jailbreak apps and rockapps are effectively disabled. Winterboard disabled, everything. From here, you need to manually move each DYLIB back down a level to the proper folder one at a time and a respring to check for a “culprit” DLL responsible for Springboard Load failures and timeouts, resulting in a reboot. Repeat this process until you narrow it down.
The above scenario related to substrate DYLIB was the problem with my own phone, and I have something screwed up with the RotationInhibitor SBSettings toggle. So if you’re reading this, and have this problem... You may want to try starting there and move that one out to the backup folder first, and try that before moving everything. I am extremely curious to find out your results.
THANK YOU!
I sincerely hope, these instructions have helped you and your families. I will monitor your progress and assist in any way. If this worked out for you, please consider donating to keep my site and equipment running. Your support is greatly appreciated!
Regards,
Shamim |
LinkBack URL
About LinkBacks
[SOLUTION] iPhone shut off during boot / Stuck Apple Logo
Bookmarks