English

Encrypt phone with FairPhone Open OS

Well, I need to enter the PIN to decrypt “userdata” before Android will boot. After booting, I enter the PIN for each SIM card. And then I once again need to enter the system PIN to unlock the device - this is standard behavior for an encrypted Android handset. I have to admit I did not try to hack it yet…

Ok, this doesn’t happen for me, so the encryption was indeed not successful. Though I have no idea why it didn’t work. :hushed:

I confirm: encryption did not work for me either with FP OSOS.

So it works with the regular ROM but not with FP-OSOS? I thought they were basically the same…

1 Like

Summary

I started to investigate the issue and got some debugging information and a possible solution. I think, the issue is a bug caused by wiping the userdata partition (more precisely by formatting it) and the solution is to do a factory reset or explicitly flash the userdata image in addition to the other images (see below for more details).

Cause of the issue

First of all, in adb logcat the following two lines are relevant for the erroneous encryption process:

E/Cryptfs (  236): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs (  236): Orig filesystem overlaps crypto footer region.  Cannot encrypt in place.

An internet search brought a blog post which linked to this xda forum topic. According to these sources, the problem probably is as follows: For the encryption to work, you need some free space at the end of the userdata partition right behind the userdata filesystem (the “crypto footer” from the adb error message, see this technical blog post for more information about it in general). However, when flashing another ROM, the userdata partition gets wiped, reformatted and equipped with a new filesystem. It seems that in this process no crypto footer is left and the filesystem fills the whole partition (i.e. it “overlaps crypto footer” as described in the adb error message).

:warning: CAUTION: The xda thread provides two zip files and suggests to flash them to solve the problem. I do not advice to flash these zips, as it’s not clear how trustworthy they are and they might contain malware/viruses. However, note that this is just precaution (due to the small amount of answers and userbase over there; also I don’t see the source code documented) - I have no evidence and do not claim that the zip files contain stuff they shouldn’t! If you like to try it out, go ahead, but do it on your own risk (as with all the other stuff you flash or install on your phone from some random source/website :wink:). Anyway, there is a more natural solution below.

Usual flashing methods don’t work - indeed they’re rather causing the problem

As wiping the userdata partition seems to cause the issue, I tried out different flashing scenarios. Essentially, there are two common flashing procedures (the -w in brackets means you can insert it or leave it out):

  1. Flash all images at once: fastboot [-w] flashall

  2. Flash boot, recovery and system image sequentially:

    fastboot flash boot boot.img
    fastboot flash recovery recovery.img
    fastboot [-w] flash system system.img
    fastboot flashall flashes the boot, recovery and system images (erasing the system image before). The -w option (in both cases) does the following with both the userdata and cache partition: it erases the image, then formats the partition and finally flashes the new image. And it seems as if this wiping process causes the problem. Don’t ask me why.

Note: Once the problem occurs, flashing a new ROM (more precisely: a new system image) without touching the userdata partition (i.e. without wiping or flashing a userdata image) won’t change anything concerning the issue. As in that case all user data is preserved, this behaviour completely makes sense - remember that encrypting the phone only encrypts the userdata partition! Therefore, to solve the issue one definitely needs to do something with the userdata partition.

Solution / Workaround

As wiping didn’t solve but rather cause the issue in the first place, I tried another variation and flashed the userdata image as well:

fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot [-w] flash system system.img
fastboot flash userdata userdata.img

And now it worked! Note that it didn’t matter whether I used the -w option or not before flashing the userdata image.

Moreover, if you don’t want to flash the whole ROM again, you can also just

  • do a factory reset via
    Settings --> Backup & reset --> Factory data reset
  • or only flash the userdata image
    fastboot flash userdata userdata.img

to solve the issue. But remember to carefully backup your apps and data before and to make a plan for restoring it!

I really cannot explain why this works in contrast to fastboot -w flash system system.img - I guess it’s the formatting and flashing process that is somehow responsible - but I don’t know why.

Anyway, it works this way, I can reproduce it and I hope it will help you as well!

11 Likes

Interesting, thanks for your research! Do you want to add something to the compilation guide? Is there something that could be added to the build scripts somewhere?

Well, it might be possible to fix this bug in the build scripts or somewhere else, but I’m not used to bash scripting and don’t know how to fix it. Nevertheless, I can add the workaround to the wiki.

1 Like

Cool input, thanks a lot. :grinning: But did not work for me. I found another solution that works for me.

Destroy the LUKS Header for Filesystem Encryption

  1. You need a running recovery (TWRP) which will allow you to drop to a shell as root.
  2. Locate the userdata partition by looking around in /dev/block/platform/*/by-name/userdata.
  3. Write out a ton of zeroes to the whole partition to wipe the LUKS header:

FP2# dd if=/dev/zero of=$PATH_TO_YOUR_USERDATA

  • Format /data partition with TWRP
  • Reboot and start encryption again.
  • Notice: fastboot erase did not help in this case.

The previous suggestions did not work for me. I was still getting the following error in adb logcat:

E/Cryptfs ( 237): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.

I had to reduce the size of the userdata partition, using this guide: https://forum.cyanogenmod.org/topic/82292-cm102-encryption-does-not-start-stuck-at-splash-screen/?do=findComment&comment=439000

UPDATE
You can also resize the userdata partition without losing your data:

  1. Boot into recovery
  2. Unmount data
  3. e2fsck -y -f /dev/block/mmcblk0p20
  4. resize2fs /dev/block/mmcblk0p20 6790139

The last number is the number of 4K blocks and makes sure that there is enough space for the encryption footer (appended at the end of the partition).

6 Likes

I received my Fairphone a couple of days before FPOS OS was released. I installed the officially available build from code.fairphone.com and could encrypt the smartphone without any problems. The phone rebooted and the encryption animation was shown. Maybe the problem has been fixed in the meantime?
Is there a way to verify that the encryption worked as expected? TWRP cannot mount /data, and I have to enter the passcode when booting, so I guess that the phone is indeed encrypted.
(It should be noted that this was actually the second time I encrypted the phone. I first installed FPOS OS, encrypted it and did some configuration. In the end, I resetted the phone in TWRP and re-encrypted it afterwards. I am not sure whether the encryption animation was shown during the first encryption, but /data could also not be accessed, and the passcode had also to be entered during boot.)

1 Like

I can confirm that. Data encryption of the official FPOSOS release works without problems.

3 Likes

Strange, the encryption did not work for me with the official FP OSOS release. @freibadschwimmer did you flash FP OSOS over the self-built OSOS or the proprietary version of the Fairphone OS (with Google services)? Could it be that the partitions are sized differently on our phones?

Neither.
I flashed it over Sailfish OS :smiley:

(which was flashed over 1.2.8)

2 Likes

Interesting :smiley:

My journey was as follows:

  1. User shipped (proprietary) FP2 OS
  2. Encrypt data partition
  3. Flash FP2 OSOS
  4. Encryption failed with error: E/Cryptfs ( 237): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.

Do you know if flashing changes the size of the userdata paritition if the userdata partition already exists?

This is a good question, though I don’t have an answer for that.
It would make sense if flashing a whole system also rewrites the partition table/scheme, but I don’t know if that is actually the case.

When you tried encrypting, how full was your data partition? I think that the system may first make a copy of your files before starting the encryption process, so it might be necessary (though I don’t know that) that you need at least as much free space as the data needs. But this is just an assumption. I usually always encrypted at the very beginning of using a new OS install, before pulling any backups on the phone.

I encrypted practically right after flashing FP OSOS.

The system does not make a copy of your files when encrypting but rather encrypts them on the fly. In order to encrypt a partition Android adds a crypto-footer (additional space after the partition) and this space was missing/not enough. So the problem was not that the filesystem was too full but that the size of the partition was too large and the crypto footer could not be added anymore.

EDIT
The relevant piece of code which causes the encryption to be aborted is located here:
https://android.googlesource.com/platform/system/vold/+/lollipop-mr1-release/cryptfs.c#2994

If less there are less than 32 (CRYPT_FOOTER_OFFSET / CRYPT_SECTOR_SIZE) sectors available after the filesystem, the encryption is aborted.
Now the question remains: Why are there less than 32 sectors available on some installations? How can the partition be different when the same image is used?

5 Likes

Unfortunately the update to the 16.05 version didn’t work for me, so I flashed the whole system. Then I ran also into the problem that I couldn’t encrypt the device anymore.
Anyhow, following @tphysm’s workaround I was able to encrypt the device again! So thanks for that tips. I can confirm now that this workaround also worked for me.

Hi there, this is indeed the lack of space after the userdata partition. I cured it with the following steps:

  1. Boot into twrp and open a terminal console
  2. Make sure that my userdata partition is /dev/block/mmcblk0p20 by running “fdisk -l /dev/block/mmcblk0” and inspecting the output.
  3. Run resize2fs /dev/block/mmcblk0p20 6798000 (I tried an insanely large number first, and it refused to resize telling me the current number of blocks (I think it was 6790139 but I am not sure).
  4. No wiping at all, simply reboot, and try to encrypt. Joy! :slight_smile:
2 Likes

@tphysm 's method worked for me as well on a fastboot installation for 16.06.
Anyway I experienced some weird behaviour with the decryption of the device: When switching the screen on and of multiple times while in the decryption PIN/Password entry screen at some point the SIM-Card unlock dialogue overrides the decryption dialog. After unlocking the SIM I can continue with entering the decryption PIN/Password.
At the time of the next shutdown and the following reboot the info icon “SIM cards have changed” appears.

Did anyone experience this behavior as well?

What really is important is to be able to mount /data in recovery to be able to make complete backups. I’ve not heard anything official that this prooblem is looked into!

1 Like