Difference between revisions of "Symlinks"

From The iPhone Wiki
Jump to: navigation, search
(Someone thought Symlink == OktoPrep. No. I'll write an OktoPrep page in a minute.)
Line 1: Line 1:
 
Before the discovery of the [[LibTiff]], this was used on 1.1.1 to jailbreak iPhones from 1.0.2. However, this only worked for iPhones, as the new iPod touch could not run 1.0.2 and therefore could not use this jailbreak method. The symlink method involved symlinking /private/var/root/Media, the directory that the AFC protocol can access access, to /, and then downloading, jailbreaking, and reuploading the entire system partition from /dev/rdisk0s1.
 
Before the discovery of the [[LibTiff]], this was used on 1.1.1 to jailbreak iPhones from 1.0.2. However, this only worked for iPhones, as the new iPod touch could not run 1.0.2 and therefore could not use this jailbreak method. The symlink method involved symlinking /private/var/root/Media, the directory that the AFC protocol can access access, to /, and then downloading, jailbreaking, and reuploading the entire system partition from /dev/rdisk0s1.
   
This exploit was fixed in 1.1.2, when Apple introduced a check in the update ramdisk that prevented this from happening. Note that this is not the 1.1.2 [[OktoPrep]] exploit.
+
This exploit was fixed in 1.1.2, when Apple introduced a check in the update ramdisk that prevented this from happening. Note that this is not the 1.1.2 [[mknod]] exploit.
   
 
[[Category:Jailbreaks]]
 
[[Category:Jailbreaks]]

Revision as of 14:22, 7 April 2009

Before the discovery of the LibTiff, this was used on 1.1.1 to jailbreak iPhones from 1.0.2. However, this only worked for iPhones, as the new iPod touch could not run 1.0.2 and therefore could not use this jailbreak method. The symlink method involved symlinking /private/var/root/Media, the directory that the AFC protocol can access access, to /, and then downloading, jailbreaking, and reuploading the entire system partition from /dev/rdisk0s1.

This exploit was fixed in 1.1.2, when Apple introduced a check in the update ramdisk that prevented this from happening. Note that this is not the 1.1.2 mknod exploit.