Evasi0n Help (Jailbreak FAQ's)

Why is Cydia suddenly tiny after rebooting (the quarter screen bug)? How do I fix it?
Here are examples of what this looks like: on iPad, on iPhone. This is caused by having a tweak incompatible with iOS 6 installed, and it only shows up after rebooting. Check your tweaks and uninstall any that might not be compatible - this list may help. To uninstall incompatible tweaks: first put your device into Safe Mode using SBSettings (tap the "Power" button in SBSettings for the Safe Mode option) or using a similar tweak, or if you don't have something like that installed, you can reboot your device while holding the volume up button to disable all tweaks. Then open up Cydia and uninstall any tweaks that you suspect are incompatible. You can reboot again to check, and repeat the process as necessary.
Known tweaks that cause this issue are the current versions of Deck and Binary Clock, and old versions of SubtleLock, Incarcerapp, NowListening, Transparency, and RetinaPad (please update them if you have them installed). Respringing is a temporary fix for this issue (it will make Cydia usable again), but unless you remove the incompatible tweak(s), you will get this problem again the next time you reboot your device. Winterboard and UIKit Tools do not cause this problem (they are fully compatible with iOS 6), but installing/updating them may cause you to reboot your device, which makes the incompatible tweak problem show up.

Why is the Weather app crashing?
This may happen if you have AppSync installed, due to bugs in AppSync. You can usually fix this by uninstalling AppSync and rebooting your device.

Why am I getting this weird "Wow" error message in Cydia?
If you get the "Wow, you exceeded the number of package names this APT is capable of" error, that means you have more than 65,535 packages available from your installed sources, and Cydia cannot handle this many. Please go to Manage -> Sources on iPhone and iPod touch (or Sources on iPad), tap "Edit" at top right, and remove several sources. It's best to keep the default repositories (BigBoss, Cydia/Telesphoreo, Dev Team, ModMyi and ZodTTD/MacCiti).

Why isn't Cydia displaying my SHSH blob versions at the top of the Cydia homepage?
Cydia is under such heavy load that saurik has to limit this feature for now. You can save them yourself by using TinyUmbrella - download it, install it, plug your device into your computer, and click the "Save SHSH" button. (See here for some background information from about the SHSH servers, if you're curious.)

Why aren't notifications showing up on my lockscreen with this HTML theme?
Winterboard has a bug preventing lockscreen notifications from being visible when a lockscreen HTML theme is enabled. saurik is aware of this issue and will look into it as soon as he can.

How should I prepare my device for jailbreaking with evasi0n?
If your device is currently on iOS 6.0, 6.0.1, 6.0.2, 6.1, or 6.1.1, make sure to back up your device with iTunes or iCloud before jailbreaking, temporarily disable your passcode (if you have one enabled), and that's all the preparation required. If your device is on an older iOS version, or if you want to be extra sure that the jailbreak will go smoothly, you can follow these steps:
Make a backup with iTunes (click "Back Up Now" in iTunes).
If your device is jailbroken, write down a list of your installed packages, because the next step (restoring) will remove the existing jailbreak. If not jailbroken, ignore this step.
Restore the device with iTunes, which will update your device to the latest iOS version, currently iOS 6.1 (or iOS 6.1.1 for iPhone 4S). (If you have an iPhone 4 or 3GS with an unofficial carrier unlock that depends on your device's baseband version, restore your device with custom firmware instead.)
Select "Set up as a new device" on the device itself during the setup process after the device is restored. Do not select "Set up as a new device" or "Restore from this backup" on iTunes yet.
Open evasi0n on your computer and jailbreak your device.
Open up Cydia for the first time to allow it to "prepare the filesystem". Wait for the respring to happen.
Start iTunes again and select "Restore from this backup" to put your data back (apps, music, etc.).
You're done. Feel free to open Cydia and install some packages. To access previously-purchased packages, tap "Manage Account" on the Cydia homepage and log in.

What is a jailbreak?
Jailbreaking your device means installing a small program that removes restrictions in the default software. A jailbroken device can run apps and extensions (themes and tweaks) not approved by Apple. Jailbreaking does not slow down your device or use extra battery, and you can still use all your existing apps and buy new ones from the App Store. Jailbreaking simply enables you to do more with your device; nothing is taken away.

Will evasi0n unlock my device? Does my device need to be activated before jailbreaking?
No, evasi0n does not provide a carrier unlock. (And if you're curious about the legality of unofficial carrier unlocks, see these explanations.) Yes, your device needs to be activated before using evasi0n.
What if I decide that I don't want the jailbreak anymore?
If you someday decide that you want to undo your jailbreak, you can plug your device into your computer, make a full backup with iTunes, click "Restore" in iTunes to wipe the device, and load your backup when prompted. All your App Store apps and the information in them will be preserved as usual.

Can jailbreaking "brick" my device?
Jailbreaking cannot put your device into an unusable state on its own. You will have full access to your jailbroken device, which gives you the power to modify it in ways that can put it in a state where you have to connect your device to iTunes and "restore" from a recently-synced backup. However, it should not be possible to render your device as permanently non-interactive as a brick, no matter what you choose to install.

Does jailbreaking cause instability or battery drain?
Jailbreaking itself generally does not cause stability problems. But you have full access to your jailbroken device, which gives you the power to install software that can cause instability and even battery drain. If you're careful to install well-reviewed, popularly-recommended packages by reputable developers from legitimate repositories, you probably won't run into much trouble with crashes or increased battery usage. You do have to be willing to do a bit of research and troubleshooting though, since you're taking control and responsibility for your device and can install things that cause issues.

Does jailbreaking make my device less secure?
Having a jailbroken device is similar to having administrator power on your desktop computer: you have full freedom to install bad stuff on your computer, but you already know to stay away from installing dubious browser toolbars and sketchy email attachments - instead, you choose to install legitimate software from reputable developers. Use the same reasonable caution when installing software on your jailbroken device. It's generally a good idea to stick to installing software from the default repositories in Cydia (BigBoss, Cydia/Telesphoreo, Dev Team, ModMyi, and ZodTTD/MacCiti), only adding additional repositories if you really trust those additional repositories. If you're interested in technical details, check out this conversation with saurik.

Note: This article is not composed by me, it's from JailbreakQA

Sn0wbreeze 2.9.10 Released With Support For Untethered iOS 6.1.2 Jailbreak

iH8sn0w has released the new Sn0wbreeze v2.9.10, which supports untethered jailbreak for iOS 6.1.2, which was released few days back.
It allow Windows users to jailbreak their older iOS devices such as iPhone 4, iPhone 3GS and iPod touch 4G on iOS 6.1.2 to iOS 6.0.

The new features in Sn0wbreeze are below;

• 2.9.10: Added Apple TV 2 iOS 5.2 sandbox fix. (thanks @nitoTV!)
• 2.9.10: Added iOS 6.1.2 support for 3GS/A4 devices (as usual).
• 2.9.9: Fixed issue with device not showing up in iTunes/xcode.
• 2.9.9: Fixed bug when building iPhone3,2 (iPhone 4 GSM-Rev2) IPSW.
• 2.9.9: Apple TV 2 bug fixes.
• 2.9.9: Now adds evasi0n untether directly to Cydia (for future updates).
• Added 5.2/6.0.x/6.1 untethers provided by evad3rs
• Added iOS 6.1 support for iPhone 3GS, and A4 devices.
• Fixed Hacktivation issues on 6.0.x.
• Fixed some iFaith mode bugs.

Download the latest version of Sn0wbreeze here

This Is How "evasi0n" Jailbreak For iOS 6.x Work

The latest jailbreak is out, and it’s time to dissect it and document all the exploits and techniques it contains. These days, jailbreaks are so well tested that it’s easy for people to forget all the complexity that goes into them. There are numerous exploit mitigation in iOS userland, such as sandboxing, ASLR, and code signature requirements that make jailbreaking incredibly difficult.

One important point to make is that unlike the previous jailbreakme.com exploits, which could be used against an unwitting victim, jailbreaks that require USB tethering have a lower security impact, and are usually only useful to the phone’s owner. Attackers are less interested because iPhones with a passcode set will refuse to communicate over USB if they are locked, unless they have previously paired with the connecting computer. So your phone is stolen and it’s locked, attackers won’t be able to jailbreak it. Therefore, only malicious code already running on your computer can leverage USB jailbreaks nefariously.

Evasi0n userland component

This blog post will focus on the evasi0n userland component. Evasi0n’s userland component is very unique, because it is entirely filesystem-based. It doesn’t require memory corruption to escalate privileges from mobile to root. Perhaps it was named evasi0n because it evades all the userland exploit defenses instead of attacking them head-on.

Evasi0n works in 3 stages that are described below. All of the stages use functionality on the phone exposed by MobileBackup, the daemon used to backup user data from the device, and restore backups back to the device. Since backups are created by the user’s device, and must be interchangeable between devices, they cannot be easily cryptographically signed, so they are essentially untrusted data.

MobileBackup uses both a domain, such as MediaDomain, and a relative path to identify every file. A static absolute path corresponding to the domain, joined with the file-specific relative path, determines the absolute path of every file. Evasi0n creates all its files in MediaDomain, so all of the files are within /var/mobile/Media.

Stage 1:

During stage 1, evasi0n creates a fresh backup to restore to the device, containing only the following files. All files are within the MediaDomain.
directory: Media/
directory: Media/Recordings/
symlink: Media/Recordings/.haxx -> /var/mobile
directory: Media/Recordings/.haxx/DemoApp.app/
file: Media/Recordings/.haxx/DemoApp.app/Info.plist
file: Media/Recordings/.haxx/DemoApp.app/DemoApp
file: Media/Recordings/.haxx/DemoApp.app/Icon.png
file: Media/Recordings/.haxx/DemoApp.app/Icon@2x.png
file: Media/Recordings/.haxx/DemoApp.app/Icon-72.png
file: Media/Recordings/.haxx/DemoApp.app/Icon-72@2x.png
file: Media/Recordings/.haxx/Library/Caches/com.apple.mobile.installation.plist

The symlink in .haxx to /var/mobile is created to escape the MobileBackup domain’s normal path restriction. That is, normally files in the MediaDomain must reside within /var/mobile/Media; however, with the symlink created any file that exists in .haxx is actually restored in /var/mobile. This technique has been used in past jailbreaks as well.

Next, DemoApp.app, an iOS app, is created in /var/mobile, complete with icons and other supporting collateral. The plist com.apple.mobile.installation.plist is updated so that Springboard knows where the app lives, and can display it on the home screen.

However, unlike a normal iOS app, this app contains a very peculiar main binary consisting of just the following:

#!/bin/launchctl submit -l remount -o /var/mobile/Media/mount.stdout -e /var/mobile/Media/mount.stderr -- /sbin/mount -v -t hfs -o rw /dev/disk0s1s1

For those unfamiliar with UNIX shell scripts, the kernel looks at the first line of text files to determine the interpreter for the script. The above file contents tell the kernel to execute launchctl with those specific arguments.

Additionally, com.apple.mobile.installation.plist contains a peculiar section for DemoApp.app, defining an environment variable to set when running it:

<key>EnvironmentVariables</key>
<dict>
<key>LAUNCHD_SOCKET</key>
<string>/private/var/tmp/launchd/sock</string>
</dict>

At this point, the device is rebooted so that the app is picked up by Springboard, and displayed to the user.

Stage 2.1:

Now that the previous files have been put into place, Stage 2 begins by creating a new empty backup, and restoring more files to the device.
directory: Media/
directory: Media/Recordings/
symlink: Media/Recordings/.haxx -> /var/db
symlink: Media/Recordings/.haxx/timezone -> /var/tmp/launchd

Essentially, this just creates a symlink called /var/db/timezone that points to /var/tmp/launchd. The normal permissions on /var/tmp/launchd are:

drwx------ 2 root wheel 102 Feb 4 12:17 launchd

These permissions normally prevent applications running as user mobile from descending into this directory. Next, evasi0n tells the user it is stroking lockdownd. What that actually means is evasi0n is sending a malformed PairRequest command to lockdownd. Lockdownd is the main daemon that operates on commands received over USB, and is used to start/stop other services, such as MobileBackup and AFC. Since lockdownd runs as root and the user can communicate to it, abusing it to perform unintended tasks has become common in recent jailbreaks.

Now we come to the first vulnerability exploited. Sending lockdownd a malformed PairRequest command, causes lockdownd to chmod 777 /var/db/timezone so that it is accessible to mobile (and all users). It isn’t clear whether this is a vulnerability in lockdownd or in an underlying library or framework.

Stage 2.2:

Stage 2.2 drills down further into /var/tmp/launchd. It modifies the permissions in the system so that the launchd socket is also accessible by the mobile user. Stage 2.2 changes the timezone symlink as follows:

Symlink: Media/Recordings/.haxx/timezone -> /var/tmp/launchd

To

Symlink: Media/Recordings/.haxx/timezone -> /var/tmp/launchd/sock

Then evasi0n sends another malformed PairRequest packet to lockdownd, causing /var/tmp/launchd/sock to become accessible to the mobile user.

Stage 2.3:

Stage 2.3 begins by uploading a Cydia and packagelist tarfile to the phone. This isn’t used immediately, but is uploaded for use after the jailbreak is complete.

Next, the user is instructed to run the Jailbreak app (actually DemoApp.app) on their phone. Recall what that app did:

#!/bin/launchctl submit -l remount -o /var/mobile/Media/mount.stdout -e /var/mobile/Media/mount.stderr -- /sbin/mount -v -t hfs -o rw /dev/disk0s1s1

With the environment variable

LAUNCHD_SOCKET = /private/var/tmp/launchd/sock

If you read man launchctl, you will see that the submit command is described as follows:

submit -l label [-p executable] [-o path] [-e path] -- command [args]
A simple way of submitting a program to run without a configuration file. This mechanism also tells launchd to keep the program alive in the event of failure.
-l label
What unique label to assign this job to launchd.
-p program
What program to really execute, regardless of what follows the -- in the submit sub-command.
-o path Where to send the stdout of the program.
-e path Where to send the stderr of the program.

If you look at the manpage for launchd, you will see:

ENVIRONMENTAL VARIABLES

LAUNCHD_SOCKET

This variable is exported when invoking a command via the launchd command line. It informs launchctl how to find the correct launchd socket for communications.

Unlike most other things on iOS, launchd’s IPC mechanism operates through unix domain sockets. There are also multiple launchd processes – one running as each user. On iOS, there is one running as root, and one running as mobile. So the user, as mobile, is executing launchctl via DemoApp.app. However, launchctl is not talking to the mobile user’s launchd. Instead, it is talking to the root user’s launchd, via the launchd socket that was exposed via UNIX permissions using the /var/db/timezone vulnerability.

Since the root user’s launchd runs as root, this job will be run as root. The job will remap the system partition as read-write, allowing the exploit to then make persistent changes on the system partition that will execute as root in the early boot environment.

Stage 3:

Next, the final stage of the jailbreak begins, again using MobileBackup, but this time with full access to the system partition.
directory: Media/
directory: Media/Recordings/
symlink: Media/Recordings/.haxx -> /
symlink: Media/Recordings/.haxx/private/etc/launchd.conf -> /private/var/evasi0n/launchd.conf
directory: Media/Recordings/.haxx/var/evasi0n
file: Media/Recordings/.haxx/var/evasi0n/evasi0n
file: Media/Recordings/.haxx/var/evasi0n/amfi.dylib
file: Media/Recordings/.haxx/var/evasi0n/udid
file: Media/Recordings/.haxx/var/evasi0n/launchd.conf

Things are getting a bit confusing due to extensive use of pushing files through symlinks, but essentially this creates a directory at /var/evasi0n containing an executable, a library, and a new launchd.conf. Launchd.conf is described by Apple (see man launchd.conf) as:

DESCRIPTION

launchd.conf contains a list of subcommands (load, unload, etc.) to run via launchctl(1) when launchd(8) starts.

The replacement launchd.conf, which will run at each boot, contains:

bsexec .. /sbin/mount -u -o rw,suid,dev /

setenv DYLD_INSERT_LIBRARIES /private/var/evasi0n/amfi.dylib

load /System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist

bsexec .. /private/var/evasi0n/evasi0n

unsetenv DYLD_INSERT_LIBRARIES

bsexec .. /bin/rm -f /private/var/evasi0n/sock

bsexec .. /bin/ln -f /var/tmp/launchd/sock /private/var/evasi0n/sock

Here’s what that does, line by line:

bsexec .. /sbin/mount -u -o rw,suid,dev /
Mount system partition read-write again

setenv DYLD_INSERT_LIBRARIES /private/var/evasi0n/amfi.dylib


Insert amfi.dylib into any executable that launches after this point

load /System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist


Load the MobileFileIntegrity daemon

bsexec .. /private/var/evasi0n/evasi0n


Execute the malicious code, previously dropped in /var/evasi0n/evasi0n

unsetenv DYLD_INSERT_LIBRARIES


Unset DYLD_INSERT_LIBRARIES, so that amfi.dylib will no longer be inserted into every executable after this point

bsexec .. /bin/rm -f /private/var/evasi0n/sock


Delete any pre-existing socket file at /private/var/evasi0n/sock

bsexec .. /bin/ln -f /var/tmp/launchd/sock /private/var/evasi0n/sock


Create a symlink from /var/tmp/launchd/sock to /private/var/evasi0n/sock, allowing other code direct access to the root launchd socket

Next, the exploit reboots the device, causing this configuration file to get run, line by line, on next boot. The interesting thing about amfi.dylib and evasi0n is that neither are code-signed. If you look at amfi.dylib with otool, you will see that it in fact has no TEXT/text section at all. No TEXT/text section means that there is nothing to sign, and therefore, it won't trip up the code-signing machinery. What it does have, is lazy binding information.
$ dyldinfo -export amfi.dylib
export information (from trie):
[re-export] _kMISValidationOptionValidateSignatureOnly (_kCFUserNotificationTokenKey from CoreFoundation)
[re-export] _kMISValidationOptionExpectedHash (_kCFUserNotificationTimeoutKey from CoreFoundation)
[re-export] _MISValidateSignature (_CFEqual from CoreFoundation)

This technique is described, at least, at http://networkpx.blogspot.com/2009/09/compiling-iphoneos-31-apps-with-xcode.html:

"If we can force MISValidateSignature() to always return 0, any binaries will pass the test. This function is part of libmis.dylib, which is now part of the shared cache, so you can't binary patch this file. Replacing the implementation of a function is a perfect job with MobileSubstrate, unfortunately, no matter how I tried MS can't be injected. Therefore I use a trick: create a "proxy dynamic library" that changes only the MISValidateSignature function, and let the rest pass through."

By clever usage of a codeless dynamic library, existing valid methods (such as CFEqual()) can be re-exported as different methods with the same method signature, such that MISValidateSignature will always return 0, allowing any unsigned binary to run.

Conclusion

Evasi0n is interesting because it escalates privileges and has full access to the system partition all without any memory corruption. It does this by exploiting the /var/db/timezone vulnerability to gain access to the root user’s launchd socket. It then abuses launchd to load MobileFileIntegrity with an inserted codeless library, which is overriding MISValidateSignature to always return 0.