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.