[SM-G935/Exynos] CF-Auto-Root

CF-Auto-Root is now available from the repo - http://autoroot.chainfire.eu/

Before flashing, make sure you have enabled "OEM unlock" from "Developer Settings" !

Note that CFAR's display code isn't yet compatible with the S7, as such, there is no output on screen. This means that after flashing with ODIN, the device will only show you the S7 logo, and it seems like nothing happens. Just leave the device alone for 5 minutes. It'll reboot a few times, then boot into Android, but now you have root.

If it still doesn't do anything after 5 minutes, something has gone wrong, and you should probably reflash your stock boot.img and recovery.img.

Regarding encryption and root on the S7 variants on Nougat:

I've been playing around all day, and I think my conclusion is that the only really safe (from a bricking perspective) way to root on 7.0 is to format /data and fully disable encryption.

The encryption keys appear to be partially tied to boot and recovery signature, and thus 'full official' status. I've done some rather simple attempts at faking it from Linux/Android's point of view, but have so far not succeeded. As this part of the decryption stage involves hardware outside of our control, I doubt it is easily fooled, and even if it was, it would be fixed next update.

The main reason I do not feel like continuing trying, is because this appears dangerous. Twice today I ended up with an almost unrecoverable device, only to be revived by /data and /cache format from recovery, followed by firmware reset via Smart Switch (slow and cumbersome). ODIN would refuse to flash, (stock) recovery is not usable to flash, and the device would refuse to boot. This situation appears to be happening in certain 'invalid' combinations of encrypted data, custom boot/recovery images, and failed dm-verity. The latter is interesting because it seemingly comes out of nowhere, and prevents your device from booting even if you restore the stock boot and recovery which should allow the original /data to be decrypted again. I'm not yet completely clear on the exact triggers for each of these situations, but they seem to be situations better avoided.

Now, if you were to flash a custom recovery (CFAR, TWRP, etc), installed SuperSU (or something else which also customizes boot), and formatted /data while keeping encryption possible, the phone may re-encrypt the freshly formatted /data. This appears to be a good thing, until you flash back the stock kernel and/or recovery (either on purpose or by accident - including failed updates), and you possibly end up in this invalid and hard-to-recover-from state again.

This is not true for the firmware I've been testing with today on my S7, but I have been informed by other devs that various recent Samsung firmwares force re-encrypt /data even if you change the fstab from forceencrypt to encryptable (SuperSU's current default). The next SuperSU update will contain an option to completely disable encryption, and today's testing makes me consider enabling this by default (on Samsung, if detected that /data is currently unencrypted, so a format /data followed by a SuperSU install would automatically fully disable encryption).

Now, before everyone starts hating on Samsung, I would guess this new protection has been implemented to further prevent pulling data off a taken/stolen device. This way, /data cannot be decrypted if the boot/recovery image changes, which while inconvenient for users like us, is a good thing data-protection-wise, and something the average user will benefit from. This is analogous to the wipe that happens when OEM (un)locking a Google device.

What worries me most, is that I could not get my device in any sort of booting state without formatting /data and /cache in recovery (something that you would normally be able to do through ODIN by flashing empty images). This means that if you end up in this broken state and for any reason recovery isn't functional, your device may be unrecoverable and essentially bricked. It is certainly not unheard of to have a broken recovery, especially on Samsung devices. Combine the two, and it is a certainty that some users will eventually end up bricked.

This in turn is also analogous with Google's devices. If the device doesn't boot, the bootloader is in the locked state (for those familiar only with Samsung's always-unlocked bootloaders: on Google devices you can un- and re-lock the bootloader for flashing), the 'allow OEM unlock' switch is disabled, and for any reason recovery isn't functional, there is no way to recover the device and it's essentially bricked.

I could start a whole rant about how these firmware flashing systems are broken by design (as stock OEM firmware should always be flashable regardless of software state), how we the users are victims of lazy engineering, and how there really should be actual laws against this absurd practise (as better solutions are not just possible, but relatively easy to implement) on devices that costs hundreds of dollars, but that is for another post another time.

For the time being, I think on Samsung Nougat+ firmwares, those who wish to root (or otherwise mod their firmwares) have an important choice to make: is the security of their data worth more than the device itself? If you care more about your data being safe than the (still relatively) small chance of bricking, run rooted and encrypted. If you worry more about the device not becoming a brick, run rooted and unencrypted.

I do hope either my analysis is completely wrong, I overlooked something obvious, or this is some sort of bug in Samsung's bootloader that will soon be fixed, but I fear neither of those is the case, and this will be the way forward on Samsung.

@Chainfire You are the best! May you live 4 ever so that my kids, Grand kids and grand grand grand grand kids can enjoy the awesome work you do.

This CF-Auto-Root has been updated, re-download and let me know if it works.

_alexndr said:

I spent a lot of time on it, without noticeable success... If we are talking about /data encrypted by official Nougat (DPLT or newer) - from my experience it is not possible to boot if kernel AND/OR recovery has been modified.

The only scenario which allowed me boot succesfully with encrypted /data was as follow:

- Flashed TWRP and went directly to it
- Performed format /data
- Flashed SuperSU 2.79 beta3 (using external storage) with KEEPFORCEENCRYPT and FRP forced to "true" (via terminal > /cache/.supersu)
- Rebooted

During first boot device created new encrypted /data partition.

Device worked fine after I performed initial setup etc.. Unfortunately, when I flashed (for the test) original kernel & recovery - device was not able to boot (bootloop - double vibrate and nothing more). So.. using "such encryption" is not a good idea



Most likely you are right (my argument was only my first guess). But it would be very strange due to their hashes will differ every new update.

Anyway, I wonder if there is any workaround for this.. Maybe we just need to store a new "important part of kernel's raw data" while re-packing?

Click to expand...

Click to collapse

Interesting results. I'm done migrating the S7 to the S8, so the S7 is available for testing now. I'll see what I can dig up, if anything. This sort of thing is hellishly difficult to debug, though.