Samsung Galaxy S6 - Encryption with Android 10 ended in boot loop

A couple of days ago I tried to encrypt the hard drive of my Samsung Galaxy which runs with /e/ on Android 10 (build: e-0.15-q-20210220-UNOFFICIAL-zerofltexx). This ended up in a boot loop.
For all those who experience the same problem I would like to share my experience. May it be of help for you.

Luckily I was still able to access the TWRP menu by pressing the Volume up, Power and Home buttons simultaneously. From there I was even able to execute a backup of the current state of the system.

My technical knowledge is limited, but thanks to the help of a good friend of mine my device was rescued. Here I would like to share how I got out of this mess.

First of all I to wipe the data partition with TWRP. The formatting process was executed, nonetheless afterwards the system still was not able to boot without ending up in the boot loop, even though I

  • reinstalled the lastest build (mentioned above) and
  • restored my latest backup (I tried both the one I did on that day and an earlier one).

The likely reason for that needs to be sought after in the way in which encryption is realized on the data block, and what wiping does to it. The encryption, which at that point probably already had been started, is represented by some data at the beginning of the data block, which represent a container that is build „around‟ the data partition. The reason why TWRP’s wiping did not help is probably because TWRP recognized the „encryption container‟ and was intelligent enough to leave it untouched, but instead only carried out a formatting of its contents.

TWRP grants access to a shell under the menu item Advanced → Terminal.
There we tried to deactivate the encryption with:

recovery --wipe_data –set_filesystem_encryption=off

As this lead to no result, we had to bring in the big guns. We not only had to wipe the user data partition, but had to destroy the encryption container, which would not happen by mere wiping.
So we had to find out on which parition the user data partition is stored.
We had all partitions of the system listed using:

ls -l /dev/block/platform/*/by-name

sda18 was labelled with „USERDATA‟, so we had a look at how much memory space it has (just to make sure whether it is plausible that this was really the data partition):

fdisk /dev/block/sda18

and choosing „p‟ (print the partition table) to see how big it is.

28 GB seemed plausible, so we knew hat it was this partition where the data encryption needed to be destroyed. The idea was to perform a destruction of the encryption container by copying a string of 0‛s to the beginning of the partition, which were meant to overwrite the data that represent it:

dd if=/dev/zero of=/dev/block/sda18 bs=4096 count=512

dd = data duplicator
if = input file
of = output file
bs = block size
count = amount of blocks

The container is probably located at the beginning of the data system. The above numbers we recommended in some discussion with a similar problem on the internet. Afterwards, a new, empty block had to be created:

make_ext4fs /dev/block/sda18

I was able to restore an older backup on that block and was able to use my phone again.

1 Like

This is an excellent writeup @Forumsnutzer- thanks very much for taking time out to share. :beers:

TLDR: I think we can safely say that most users attempting to encrypt an S6 at this point should expect a certain amount of pain, stress and heartache. It is likely wise to accept that while it may be technically possible to do, it’s not working as of today and the prognosis (given the device’s age) that it will work in the future is not particularly good.

1 Like