3 ms·

I stand corrected. Thanks for the explanation. Your next tweet was too cryptic for me to understand so I didn't realize you were explaining your jailbreak meth

I stand corrected. Thanks for the explanation. Your next tweet was too cryptic for me to understand so I didn't realize you were explaining your jailbreak method. If I'm understanding you right though, this technique sounds fairly universal. Does it affect any android device with an unlockable bootloader? Just devices running a newer version of the adb daemon?

saurik 14y ago
This exploit seems to affect almost every device running Android 4+ (I am not certain about lower ones: all of the comments I've seen about the exploit talk about 4.0/4.1, but it might be because 2.3 already had a pretty universal root: GingerBreak). The person who wrote the most common implementation is B1nary (but I don't think he came up with the exploit either; it wasn't clear if the people he credited as having helped him did either... so I just cited the exploit itself as that seemed sufficient), which may help you find the XDA developers thread (which, as is usual, doesn't explain the exploit, it just provides a wad of shell scripts you can download from a few random filelockers ;P). The exploit requires not just something in adb: it requires the device have the package for the backup service (I guess some don't, so B1nary's implementation tries to work around this as the most common alternative actually had a similar bug) and that there be a system package installed that 1) is not marked allowBackup="false" and 2) is marked with sharedUserId="android.uid.system". The normal Android Settings app has these properties, as does the Glass Logging service. It is thereby a trivial thing to mitigate, even without any extensive code changes: these packages don't need to be backed up anyway (backing up Settings, for example, results in an empty file... it has no data of its own, so it has no reason to avoid allowBackup"false"). The way it then works is that the backup service, in order to extract files with the right permissions, does a setuid to the owner of the package being restored (in this case that is root, so it continues to be root). It then extracts the restore image (which is a compressed tar file with a special header) to the package's data directory, and as it does so it honors the access flags of the files and directories. You then make a world-writable directory with numerous very large files, which slows down the process. As it extracts the files, you use adb shell access to add a symlink from a file in that folder to /data/local.prop. You have that file in the backup contain a /data/local.prop that forces adb to give you root access. (Note: with those modifications, which typically includes telling the system you are running in the qemu debugger, Glass actually doesn't work correctly due to an assumption it makes that Bluetooth will work, which the qemu debugger I guess doesn't normally support. However, it is then easy to drop a copy of su, mark it setuid, delete the local.prop, and reboot to a system that is now pristine except for the one modification of setuid su.)

saurik 14y ago

This exploit seems to affect almost every device running Android 4+ (I am not certain about lower ones: all of the comments I've seen about the exploit talk about 4.0/4.1, but it might be because 2.3 already had a pretty universal root: GingerBreak). The person who wrote the most common implementation is B1nary (but I don't think he came up with the exploit either; it wasn't clear if the people he credited as having helped him did either... so I just cited the exploit itself as that seemed sufficient), which may help you find the XDA developers thread (which, as is usual, doesn't explain the exploit, it just provides a wad of shell scripts you can download from a few random filelockers ;P). The exploit requires not just something in adb: it requires the device have the package for the backup service (I guess some don't, so B1nary's implementation tries to work around this as the most common alternative actually had a similar bug) and that there be a system package installed that 1) is not marked allowBackup="false" and 2) is marked with sharedUserId="android.uid.system". The normal Android Settings app has these properties, as does the Glass Logging service. It is thereby a trivial thing to mitigate, even without any extensive code changes: these packages don't need to be backed up anyway (backing up Settings, for example, results in an empty file... it has no data of its own, so it has no reason to avoid allowBackup"false"). The way it then works is that the backup service, in order to extract files with the right permissions, does a setuid to the owner of the package being restored (in this case that is root, so it continues to be root). It then extracts the restore image (which is a compressed tar file with a special header) to the package's data directory, and as it does so it honors the access flags of the files and directories. You then make a world-writable directory with numerous very large files, which slows down the process. As it extracts the files, you use adb shell access to add a symlink from a file in that folder to /data/local.prop. You have that file in the backup contain a /data/local.prop that forces adb to give you root access. (Note: with those modifications, which typically includes telling the system you are running in the qemu debugger, Glass actually doesn't work correctly due to an assumption it makes that Bluetooth will work, which the qemu debugger I guess doesn't normally support. However, it is then easy to drop a copy of su, mark it setuid, delete the local.prop, and reboot to a system that is now pristine except for the one modification of setuid su.)