[ROOT] SuperSU 2.74-2 With ForceEncrypt Set to Default

[topjohnwu]

Update (May 20): Update to latest version 2.74-2
All versions after SuperSU 2.72 has force encrypt support built in. However it will still disable force encryption by default, you have to set flags manually.
I only modified the default value of the force encrypt flag in the flashing script, so no need to worry that this might break things
If your OCD forces you to use the official version, please look here for instructions to set the flag manually by yourself.

Hi, many people have their hands on the HTC 10, and you may found out that wiping data after rooted with SuperSU, your signal will be broken.
This is caused by the fact that by default, SuperSU's flashing script will change the data encryption flag from "forceencrypt" to "encryptable". If you wiped data after the flag is set to "encryptable", your data partition will be decrypted. In many times, decrypted data is good, but on the HTC 10, for some unknown reason the signal will break with data decrypted.
More info here:
[PSA][MUST SEE] New HTC Policy : Things You Should Know Before Unlocking Bootloader

This issue has caught more attention after an S-OFF method is available. You're required to have root and wipe data after gaining S-OFF. The developer of the S-OFF tool has created a tutorial for this particular problem, you can find it here:
[Guide] Root (Optionally s-off) and Keep your radio working

I slightly modified the SuperSU flashing script, so now it won't change the encryption flag.
This zip will remain useful until we find a way to decrypt our data partition with working signal.

 

[starbase64]

Hi,

this works without problems, big tanks. Device is rooted now.

regards

starbase64

 

[MNoisy]

Big thanks. I wish I would have had this yesterday afternoon!

Now I just need to get a stock 1.21.617.3 image to start again with my US unlocked. If anyone has it, please let me know.

Is there a way to manually change the flag back to forceencrypt?

 

[datafoo]

Big thanks. I wish I would have had this yesterday afternoon!

Now I just need to get a stock 1.21.617.3 image to start again with my US unlocked. If anyone has it, please let me know.

Is there a way to manually change the flag back to forceencrypt?

I have TWRP images for system_image and boot if you need them to fix broken signal as per @jcase. We're both 1.21.617.3

 

[MNoisy]

I have TWRP images for system_image and boot if you need them to fix broken signal as per @jcase. We're both 1.21.617.3

Yes yes yes please! THANK YOU!

Where can I find them?

 

[LeeDroid]

Nice buddy, will update the method used in my build, makes life a lot easier.

I had considered making similar modifications but you appear to have beaten me too it

 

[jcase]

Hi, many people have their hands on the HTC 10, and you may found out that wiping data after rooted with SuperSU, your signal will be broken.
This is caused by the fact that by default, SuperSU's flashing script will change the data encryption flag from "forceencrypt" to "encryptable". If you wiped data after the flag is set to "encryptable", your data partition will be decrypted. In many times, decrypted data is good, but on the HTC 10, for some unknown reason the signal will break with data decrypted.
More info here:
[PSA][MUST SEE] New HTC Policy : Things You Should Know Before Unlocking Bootloader

This issue has caught more attention after an S-OFF method is available. You're required to have root and wipe data after gaining S-OFF. The developer of the S-OFF tool has created a tutorial for this particular problem, you can find it here:
[Guide] Root (Optionally s-off) and Keep your radio working

Here I come up with a more elegant solution. I slightly modified the SuperSU flashing script, so now it won't change the encryption flag, and also won't remove dm-verify.
NOTE: If your boot image is already modified, it will not reset the flag back to forceencrypt. You have to restore to the stock boot image, then flash this zip. The way I accomplished this is reverting a few modification from the previous ramdisk, so the ramdisk itself has to be stock.
Devs can include this zip into their rom, so users can wipe their whole data with your rom installed.
This zip will be useful until we find a way to decrypt our data partition with working signal.

I would NOT use this zip to root the HTC 10, you really need to remove verity, this is going to cause many many many issues, its going to softbrick a huge number of phones, anything from a lot of root apps, to restoring a twrp backup is going to trip dm-verity

 

[Chainfire]

SuperSU v2.72 has all of this built in via KEEPVERITY and KEEPFORCEENCRYPT flags. It's not publicly released yet but will be within a few days.

 

[Captain_Throwback]

SuperSU v2.72 has all of this built in via KEEPVERITY and KEEPFORCEENCRYPT flags. It's not publicly released yet but will be within a few days.

Out of curiosity, where will we put those flags? /data/.supersu isn't an option, because /data is encrypted and unmountable, and /system/.supersu isn't an option if /system is read-only and we want to preserve dm-verity.

 

[topjohnwu]

I would NOT use this zip to root the HTC 10, you really need to remove verity, this is going to cause many many many issues, its going to softbrick a huge number of phones, anything from a lot of root apps, to restoring a twrp backup is going to trip dm-verity

My system is modified, but everything is working fine. I'm using this without a problem so I shared it.
Is it because my device is S-OFF? If this is the case, then I'll remove the link. Thanks for the kind remind.

 

[jcase]

My system is modified, but everything is working fine. I'm using this without a problem so I shared it.
Is it because my device is S-OFF? If this is the case, then I'll remove the link. Thanks for the kind remind.

I'd have to look at the zip and test to see why. It could be that your particular firmware isn't actually enforcing dm-verity (I believe google mandates this on 6.0+), that HTC disables enforcing when s-off or the zip isn't properly enforcing verity.

Best advice is not to enforce verity on system if you are rooted.

What should (and did for my phone) happen if you have dm-verity enabled on system and a modified system is the phone shouldn't successfully boot.

 

[Chainfire]

Out of curiosity, where will we put those flags? /data/.supersu isn't an option, because /data is encrypted and unmountable, and /system/.supersu isn't an option if /system is read-only and we want to preserve dm-verity.

I've added /cache/.supersu as location specifically for those devices with a TWRP that can't read encrypted /data.

Still, you can echo to /data/.supersu even if /data isn't mounted and that'll still work. It just will not persist between boots.

Custom ROM devs should put it in /system/.supersu, though, or set the variable in shell and export that variable (important!) before running the SuperSU ZIP.

 

[dottat]

I've added /cache/.supersu as location specifically for those devices with a TWRP that can't read encrypted /data.

Still, you can echo to /data/.supersu even if /data isn't mounted and that'll still work. It just will not persist between boots.

Custom ROM devs should put it in /system/.supersu, though, or set the variable in shell and export that variable (important!) before running the SuperSU ZIP.

Will that cause complications for users who wipe cache often?

 

[topjohnwu]

Sorry everyone, didn't though much about the dm_verity.
Re-uploaded one with dm_verity removed.
Everyone should re-flash this zip if you've used the old one, thanks a lot.
@LeeDroid, could you please test if this works on your rom?

 

[LeeDroid]

Sorry everyone, didn't though much about the dm_verity.
Re-uploaded one with dm_verity removed.
Everyone should re-flash this zip if you've used the old one, thanks a lot.

@LeeDroid, could you please test if this works on your rom?

Will have a bash tonight mate

 

[LeeDroid]

Sorry everyone, didn't though much about the dm_verity.
Re-uploaded one with dm_verity removed.
Everyone should re-flash this zip if you've used the old one, thanks a lot.

@LeeDroid, could you please test if this works on your rom?

still no go on boot

 

[topjohnwu]

still no go on boot

Yeah... Just tested myself and it won't boot.
It's weird though, it can boot on my modified system
I might need more investigation, or just wait for Chainfire to release the new update.

 

[chazall1]

Is it OK to use SYSTEMLESS with your current build?
Thanks

 

[nkk71]

ah, perhaps encountered a blarf

you wanna stick with blarp ... he's much nicer

 

[topjohnwu]

Yeah... Just tested myself and it won't boot.
It's weird though, it can boot on my modified system
I might need more investigation, or just wait for Chainfire to release the new update.

Ahh, I knew why.
I cannot separate the forceencrypt flag patch and verify flag by modifying the script.
Had to wait for Chainfire to release new version, or we have to manually modify the boot image.