[HOWTO] Root with Magisk - OTA updates, root cloaking and SafetyNet

[ChuckMorris]

This is a method to root Fairphone OS (with GMS) while keeping the ability to

• install OTA updates,
• run apps which usually don’t run on rooted devices,
• install and run apps which use Google’s SafetyNet to check devices for modifications.

None of this is my original work, I just put together bits and pieces of information, tested it on the FP2 and wrote it down.

Only the initial installation requires a PC, all subsequent updates can be done on-device. I will not explain every little detail so you should be familiar with tasks like using fastboot and TWRP.

Prerequisites

You have to start with an unmodified Fairphone OS. If you made any modifications (root, Xposed), undo them. A thorough way of doing this is to flash the latest manual update (this will not delete your apps and data). Also, uninstall apps like phh’s SuperUser or Xposed Installer.

Initial installation

• Download the latest TWRP image and flash it using fastboot. This is the only step which requires a PC.
• On your FP2:
• Download the latest Magisk installer zip.
• Reboot into TWRP and install the Magisk installer zip.
• Reboot into Android, download and install the latest Magisk Manager apk.
• Install FlashFire. You won’t need that right now, but it is required for performing OTA updates.

Root cloaking and SafetyNet

Magisk Manager allows hiding root from individual apps using its Magisk Hide feature. Also, Magisk doesn’t break SafetyNet! I tested several banking and healthcare apps (which didn’t work with other rooting and cloaking methods) and they all work well (tested with Magisk 14.0).

Performing an OTA update

While Magisk is systemless (meaning it doesn’t modify the system partition), it does patch the boot image. OTA updates for the FP2 use a differential patching method not only for the system partition, but also for the boot image. This means we have to restore the original boot image before applying an OTA update. Magisk Manager allows you to do that, but there is another problem: You have to reinstall Magisk after each OTA update, but the OTA update overwrites TWRP with stock recovery. You would have to reinstall TWRP after each OTA update (using a PC). Fortunately, there is a neat workaround:

• When Fairphone Updater notifies you about an OTA update, download it, but don’t restart to install (this would fail).
• Start FlashFire and:
• Tap +, then tap Flash ZIP or OTA and select the OTA update zip. You can find it in .../Android/data/com.fairphone.updater/files/ (either in Internal storage or on the SD card). Keep Restore boot and recovery images enabled.
• Add the Magisk installer zip the same way (don’t enable Restore boot and recovery images).
• Disable EverRoot (important!).
• If it looks like this: Flash!
  
  

FlashFire will now backup TWRP, restore the stock boot image and recovery, run the OTA update, reinstall Magisk, restore TWRP and reboot. Done!

Optional: Systemless Xposed

You can download and install a systemless version of the Xposed Framework from within Magisk Manager (select the SDK 23 version and follow the instructions regarding where to get the modified Xposed Installer app).
Unfortunately this breaks SafetyNet and can make OTA updates a little bit more complicated, so you should only do this if you really need Xposed modules.
If you occasionally need to use apps requiring SafetyNet, you can temporarily disable Xposed Framework in Magisk Manager (requires a reboot).
While the systemless Xposed Framework doesn’t modify the system partition, many Xposed modules do! This means we have to restore the stock system image before applying an OTA update. To do so, download the binary images zip corresponding with your current FPOS version and add it in FlashFire using the Flash firmware package option. Select System only. Then add the OTA update zip and Magisk installer zip (and disable EverRoot) as explained above. It should look like this:

[DjDas]

Thank you very much for this guide!
Do you know if there is a way to use AFWall+ and ADAway in systemless installations?
My “security setup” normally is compound of: AFWall+, ADAway and XPrivacy, but when I searched some time ago about the possibility to have this setup in systemless version I ended with no result.
Thank you in advance, bye!

[ChuckMorris]

I can’t tell for sure since I don’t use any of those apps / modules, but I don’t see why it wouldn’t work. All apps requiring root and all Xposed modules I’ve tried so far work just fine with Magisk and Systemless Xposed.

[DjDas]

Last time I read about problems with Magisk was because AFWall+ uses iptables to change firewall rules (honestly I don’t see why this could be a problem, but I didn’t investigate nor tried…) and AdAway modifies the /etc/hosts file by pointing all ads sites to 127.0.0.1 (this actually could be a problem if Magisk doens’t fake the hosts file, but also this is speculation by me because I didn’t try Magisk yet).
Anyway thank you for your answer

[ChuckMorris]

Magisk has a feature called systemless hosts (disabled by default) specifically for adblock apps which modify the hosts file. I installed the Magisk module Unified Hosts Adblock which uses this feature and it works great!

I haven’t tested the compatibility of other adblock apps and I don’t use a firewall app.

[dasSuperbanshee]

Hi! I am currently having problems updating to the latest FP OS update.

I’ve done it in the past and it worked perfectly, but when I do it now I get a message saying that “it has been detected that you may be trying to flash a block-level OTA, but your /system, /vendor, or /oem partition has been modified. This will likely cause the flash to fail!” I don’t recall ever getting this message before. Here’s a screenshot:

I tried it anyway. The first time my phone just rebooted as normal. The second time the screen went black for a long time and the phone didn’t respond anymore, before I took the battery out and restarted it.

Did I do anything wrong? Here’s a screenshot of FlashFire before I hit flash:

(Actually, as I am seeing just now, this is wrong because the Magisk Flash is before the OTA - I did that differently during my two update trials, I just recreated this screenshot for posting purposes.)

Am I the only one with this issue? Do you have any suggestions on how to go about it?

[ChuckMorris]

I often got this message, always ignored it and it never caused any trouble. It just means that the system verification performed by the OTA update will fail if the system partition is modified. That’s why we flash the original system image first.

However, FlashFire recently stopped working for me, too. It just reboots. I think this started after I swapped some modules (display and new cameras). There might be a compatibility issue with one of them. I have not found a solution yet and had to install the latest FPOS update manually using fastboot and ADB.

Did you recently swap the display or camera(s), too?

[dasSuperbanshee]

Yes! I did also swap modules, both the new camera modules. I still have the old ones. I might try putting them in again and see if I can use FlashFire then, sometime during the next few days. I’ll report back!

Am 15.01.18, 13:44, ChuckMorris noreply@fairphone.com schrieb:

[Hugo_Buddelmeijer]

Having trouble installing 18.02.0, currently using 17.11.2

The first time I tried FlashFire it just gave a black screen, the second time it gave the ‘modified partition’ warning and still the black screen (for several minutes). I have never used FlashFire before. I have replaced the microphone a while back, but not the camera or screen.

Trying to flash the OTA manually throug TWRP or ADB sideload gives errors. First the MD5 sum fails when trying to install from the internal memory:

Then, sideloading also gives the MD5 error. Then using TWRP directly and ignoring the MD5 checksum gives an error about the package fingerprint:

In particular in complains that I have “MOB30M/6:eng/test-keys”, see screenshot… No clue what they are.

Any advice on how to upgrade would be appreciated.

[AnotherElk]

In TWRP settings, you should disable the ZIP signature verification.
This is what fails first here … try installing in TWRP again without the verification and see whether the same error occurs.

[Hugo_Buddelmeijer]

Yeah, that’s when I got this last error about the build fingerprints. Sorry I wasn’t clear, there were three attempts in the two screenshots (TWRP w/ md5sum, adb sideload, TWRP w/o checksum).

There apparently is a newer TWRP, maybe that would help.

Hmm the fingerprint error is caused by the modified boot partition or not? So I should first put that back manually right? (Since that is what the FlashFire tool was planning to do.) But I don’t know how to do that yet, probably a feature in Magisk somewhere.

[ChuckMorris]

• As far as I know you can’t flash official OTA updates in TWRP at all. The fingerprint check will always fail. Correct me if I’m wrong.
• You can flash the OTA update using FlashFire, but only on unmodified devices. If you modified the boot partition, you have to flash the original boot image first. You can do that with FlashFire, too. See above howto.
• As discussed above, FlashFire currently does not work if the new camera module is installed.
• This has nothing to do with Magisk. Magisk does not modify the boot partition and is unrelated to FlashFire.

[Hugo_Buddelmeijer]

Thanks ChuckMorris.

In the end I simply flashed the full binary images for 18.02.0 with the official tool (just a fastboot wrapper it seems) and reinstalled TWRP and Magisk.

FlashFire didn’t work, even though I never replaced the camera. Similar symptoms, so maybe it was a similar issue. I don’t know where FlashFire would have gotten the original boot image from though, I didn’t have to specify a location. So I don’t really understand how this tool should work, but didn’t really dig into it either.

BTW, Magisk does modify the boot image. From the Magisk xda thread: “Magisk only modifies the boot image and install files to /data and /cache”. (It doesn’t modify the system image though.)

It’s not really clear to me where the fingerprint originates from; the first time I’ve encountered it. If the recovery image is part of the fingerprint, then it would indeed never match if TWRP is installed.