SuperSU 2.77 beta

SuperSU 2.77 beta


Package Name: eu.chainfire.supersu


Version: 2.77 (277)
Uploaded: Monday, 29-Aug-16 01:35:43 UTC
File size: 6.48 MB (6482733 bytes)
Minimum Android version: 2.1 (Eclair, API 7)
MD5sum: b07297745af392bf3c37d51d295e70f9
SHA1sum: ac7bdd088c0e53c9161554637e2b6872e8cfad12

icon verified Safe verified to install

sad dog with adblocker


Seems like you are using AdBlock to hide banners... ADS are quite nice and don't take much space, you may consider disabling it on this website.
This is the only AD on the entire website.


It looks like you're using an ad blocker, so you'll have to wait 15 more seconds.
Please disable your ad blocker to skip the wait and help support the site.

Change logs / What's New

SuperSU v2.77 BETA – Note7 (Exynos) shenanigans

Unfortunately SuperSU did not work on the Note7 (Exynos) out-of-the-box. As its release has been delayed in my country, we’ve had to resort to remote debugging, which is slow and frustrating. But, thanks to the ever helpful Dr.Ketan and SeraphSephiroth we finally got it working.

New exploit protections
As isn’t uncommon with Samsung, they’ve built-in some new (and arguably ineffective to actual exploits) protections directly to the kernel code, that cannot be turned off by just modifying the boot image ramdisk.

This time, they’ve decided to kernel panic in case a ‘priviliged’ process (uid or gid below or equal to 1000, so this includes root and system processes) creates another process that isn’t stored in /system or rootfs. SuperSU itself does this, but so do a great many root apps. Any time this happens: immediate reboot.

I’m not going to elaborate why in my opinion this is a fairly useless protection exploit-wise, but needless to say it is fairly bothersome for the normal root user, which is probably a lot more relevant for the average reader here.

Unfortunately – unlike many of the security features developed by Google – this feature is not easily disabled by modifying initramfs (boot image ramdisk), and requires further trickery to bypass.

Maybe a better bypass is yet to by found, but for the time being, I have resorted to patching the check inside the kernel itself when the systemless SuperSU boot image is created. This prevents the user from needing a custom source-built kernel, but it’s questionable how long this hex patch will work. The code that performs this patch is fairly trivial – it may keep working the rest of the Note7’s lifetime, or stop working the next update.

In other words, this could end up being resource intensive to support, or not. We don’t know yet. We have to wait and see what Samsung is going to do.

Bearer of bad news
We know S and Note development are generally strongly related, so we should assume to see the same ‘protections’ appear in the S7 sooner or later as well. This is probably the (ugly) way forward.

Aside from the binary/hex patch SuperSU employs (see common/hexpatch inside the ZIP), there are some more ways to get around this protection.

If you’re compiling kernels from source, it seems that setting CONFIG_RKP_NS_PROT=n gets rid of these protections. You may want to disable other RKP and TIMA settings as well, but that is the one directly relating to this issue.

This protection also disables itself in recovery mode, so simply copying a boot image with these protections to the recovery partition and rebooting into recovery (which will then just launch Android) will work beautifully as well.

The test CFARs I have made so far for the Note7 have not worked, so since both TWRP and SuperSU ZIPs are already available for this device, I’m dropping CFAR development until I have a device in-hand.

SuperSU BETA thread:

TWRP flashable ZIP:

All Versions

SuperSU 2.79-SR4
SuperSU 2.79-SR3
SuperSU 2.79-SR2
SuperSU 2.79-SR1
SuperSU 2.79
SuperSU 2.78-SR5
SuperSU 2.78-SR4
SuperSU 2.78-SR3
SuperSU 2.78-SR2
SuperSU 2.78-SR1