DivestOS: long term device support with enhanced privacy and security

The installation of DivestOS Mobile on a Samsung Galaxy S4 GT-I9505 (jfltexx) was done via adb sideload without any special incidents.

Surprising was like for him as well as for me the automatic installation of “DivestOS Recovery” - a fork of “Lineage Recovery”.

Did I just overlook a corresponding hint about the automatic installation of “DivestOS Recovery”? At least the system was not also automatically encrypted like here with the LG G3.

Yes, in the “Developer Options” you will find a switch called "Update recovery ". This is a very handy feature of LineageOS 17.1, it can be used to update the build-in recovery with System OTA Updates. But - does this also work with “DivestOS Recovery”?


EDIT: Two pictures added
Note: The wallpaper for the home screen of the last two pictures was changed by me.


UPDATE:
“DivestOS Recovery” is extremely dominant and persistent. Flashing of TWRP Recovery via Heimdall and immediate rebooting (three times for security reasons) into TWRP Recovery worked, but TWRP remains only temporarily available. After a system start into DivestOS and subsequent booting into the device recovery “DivestOS Recovery” is present again.

Well, “TWRP Recovery” might not be perfectly adapted for LineageOS 17.1 yet, but it usually works well with the original LOS 17.1 as well as unofficial LOS 17.1 distributions. To eliminate “DivestOS Recovery” for good, I had to flash the Android Stock ROM.

Even if nobody thinks it is the truth, I would have liked to report positive aspects, but this is the end of my DivestOS exploration.


Device > Trust > Status:

SELinux - Enforcing
Encryption - Disabled

automatic installation

The recovery will be automatically installed/updated on boot of DivestOS.
To disable this you can flash via TWRP which will move the patch file out of the way.

was not also automatically encrypted

That is concerning.
All devices have forceencrypt set. There is no reason it wasn’t encrypted by default.
Strange.

Ah, jf-common uses encryptable=footer, which won’t be changed automatically as I observed many devices using footer have broken encryption. I will tweak that.

@SkewedZeppelin, Any idea when another try at a fix for the shamu phone problem will be available? Sorry in advance for asking for ETA.

How many cves do you think exist in out of tree drivers?

How many actual vulnerabilities are documented as CVEs?

Your voodoo patcher only targets what’s marked as CVEs which is obviously a very small percentage of vulnerabilities that are fixed every day

I have a neat article on why this happens https://forum.xda-developers.com/showpost.php?p=80176450&postcount=260

Happy reading

@SkewedZeppelin, Saw the 0626 shamu download and installed. Others still cannot hear me now from shamu. :frowning:

Another oddity: Time is set for network time zone, it shows correct time zone, but time shown is 2 hours too high/late.

Shown under Trust, Android security patches:

Platform: up to date
Vendor: out of date

I assume it’s because Motorola is no longer putting out updates?
Or should I go install the last Google image to make sure my firmware is “right?”

Feedback on the download file verifications. gpg verify wants a “detached signature”:

$ gpg --verify divested*sha512sum
gpg: not a detached signature

Checksums look OK, with warnings:

$ sha512sum -c divested*sha512sum
divested-17.1-20200626-dos-shamu-recovery.img: OK
sha512sum: WARNING: 10 lines are improperly formatted
divested-17.1-20200626-dos-shamu.zip: OK
sha512sum: WARNING: 10 lines are improperly formatted

So, edited sha512sum files to remove checksums and only leave signatures. Then,
got “BAD signature”:

$ gpg --verify divested-17.1-20200626-dos-shamu-recovery.img.asc
gpg: assuming signed data in ‘divested-17.1-20200626-dos-shamu-recovery.img’
gpg: can’t handle text lines longer than 19995 characters
gpg: Signature made Thu 25 Jun 2020 08:40:58 PM EDT
gpg: using EDDSA key B8744D67F9F1E14E145DFD8E7F627E920F316994
gpg: BAD signature from “DivestOS Release Signing (2020 #1) <support+releasesigning at divestos dot org>” [unknown]

$ gpg --verify divested-17.1-20200626-dos-shamu.zip.asc
gpg: assuming signed data in ‘divested-17.1-20200626-dos-shamu.zip’
gpg: Signature made Thu 25 Jun 2020 08:40:58 PM EDT
gpg: using EDDSA key B8744D67F9F1E14E145DFD8E7F627E920F316994
gpg: BAD signature from “DivestOS Release Signing (2020 #1) <support+releasesigning at divestos dot org>” [unknown]

@SkewedZeppelin I did a short test with DivestOS on a Samsung Galaxy S3 (i9300).
basically it works, maybe that’s a bit helpful for you.

Usually running LineageOS 17.1 on a rooted Fairphone 2.

Installed DivestOS and recovery version 20200607 on a Fairphone 2 and did a short test.
The OS itself including apps seems to work - that’s great!

The recovery unfortunately has some issues - maybe all for the same reason, I don’t know.
It starts with the error message “Failed to read max minors”.
The recovery does not recognize my SDcard, making it impossible to flash or install from there.
Also I could not replace it with another custom recovery (tried TWRP and LineageOS recovery).
To get back to LineageOS I had to install the Stock ROM (Fairphone OS), which wouldn’t boot, but at least let me install a custom recovery, i.e. LineageOS recovery, which let me then install LineageOS by flashing it from my SDcard.

(minor: Also I could not get Magisk installed by any available option.)

1 Like

@radical-dachshund
If you install DivestOS via TWRP, TWRP will not be replaced.
SD card likely doesn’t work due to LineageOS recovery being SELinux permissive in their builds and therefore broken when set enforcing in DivestOS.
Magisk/Xposed/root is not supported at all in DivestOS.

@justsomeguy
The vendor firmware is indeed out of date, it is a giant security hole.
The deblobber helps a small bit, but the giant modem blob can’t be patched.
It cannot be reasonably fixed.
The only option to fix this is to get hardware with open source firmware from top-to-bottom.

As for the signatures, they verify just fine.
I’m not sure what is wrong with your shell.
You shouldn’t try to edit them like that.

@anupritaisno1
Patching CVEs is just that, a patch.
I don’t claim to make these devices “magically” secure.
This entire project is just a short-term patch to get more life out of these devices instead of throwing them in the garbage.
Do I really think running Linux 3.4 with Android 7 is secure? No, I do not, it is AWFUL. But if the alternative is running a unsigned ROM with easy root access (most XDA ROMs) or running latest stock 5.0 for the device then I’ll take whatever I can get.
Heck even running say mata with Linux 4.4.228 and Android 10 this is all still insecure because the modem hasn’t been updated in months, LineageOS doesn’t use patches from the Pixel bulletins, there is no way to get many updated Qualcomm blobs, and the blobs we do have can’t be realistically be trusted as they can be tampered with by many (that one GitHub org).

Every single way you look at this, it is beyond broken.
We know this, we just don’t want to accept it.
So what do we do? We patch as much as we can and ignore the rest, right?
Is that not what we do?

This project will not last long.
All of these projects are doomed.
We need truly free hardware.
But that will never happen.

1 Like

@SkewedZeppelin

to get more life out of these devices instead of throwing them in the garbage.

A worthy goal.

I’m not sure what is wrong with your shell.

Nothing but some age: gpg (GnuPG) 2.2.12

You shouldn’t try to edit them like that.

The first shaxxxsum files needed edits to make -c work, for the lazy, so why not try. :slight_smile:

This project will not last long.
All of these projects are doomed.
We need truly free hardware.
But that will never happen.

That sounds pessimistic, but it’s understandable. A number of efforts have intersecting goals, but they argue more than cooperate. Truly free hardware can happen. Never give up. :slight_smile:

The vendor firmware is indeed out of date, it is a giant security hole.
The deblobber helps a small bit, but the giant modem blob can’t be patched.
It cannot be reasonably fixed.

@SkewedZeppelin,

Who can take advantage of these flaws? Someone who knows these blobs inner workings AND can identify my device as a target on the network AND have a way to deliver an exploit? Sounds like a nation state or The Phone Company level?

But bottom line, Is there a benefit to continuing to test new DivestOS versions on shamu? I.e. will you be trying to eventually fix the “can you hear me now” issue? Or should I be content with good ole LineageOS such as it is? I’ve found my older phones are still working well enough (but slower, and much smaller displays).

Who can take advantage of these flaws?

Anyone with enough time or money.
It really depends on your specific threat model to determine if that is relevant to you.

DivestOS versions on shamu

I spent an hour yesterday looking into this and trying things.
It does appear to be related to libmotaudioutils.so like I originally suspected.
I checked the other libraries to make sure I don’t remove any other dependencies but I found nothing amiss.
See also:


I will look into getting my hands on a Nexus 6, but they are still holding their value a bit ($80).

i am going to be buying a new smartphone.
i just stumbeled onto divestos.
i would like to try it.
i looked in faq for recommended devices.
the recommended pixel devices including
the new 4 series are very minimalistic.
i would like say a 12g 256g oneplus 7 pro.
are devices in this range doable. I dont mean
currently supported necessarily.

comments suggestions?

snd, is there a proper divestos forum?

@steveb

If you are buying a new phone and have the budget, get a Pixel 3 or a 4 and put GrapheneOS on it.

DivestOS has more of a goal to provide support to older devices in order to increase their lifespan.

LineageOS has good support for OnePlus devices, I will look into adding them to DivestOS.

Samsung Galaxy S5 (klte)
I tried three 9-pie ROMs and three Recovery on the S5 (klte): LineageOS 16.0 - divested-16.0 - /e/OS e-0.9-pie as well as TWRP Recovery 3.3.1-0 / 3.4.0-0 and divested-16.0-recovery

Except for the DivestOS Mobile files TWRP’s and ROM’s could be installed and operated without complications.

I tried to install DivestOS Mobile Recovery with TWRP (.img) and after conversion with ODIN 3 (.img.tar). After an immediate reboot into the recovery no Divest Recovery started, but the S5 (klte) showed in the boot loop only for a moment the Samsung S5 logo but no Divest Recovery.

I tried to install the DivestOS Mobile ROM divested-16.0-20200724-dos-klte.zip with TWRP 3.3.1-0 and 3.4.0-0. In vain. The S5 (klte) showed the Samsung S5 logo but no DivestOS ROM in the boot loop only for a moment.

Yes, I read it (in red color) Broken. But this hint was already on the website since end of May 2020.

klte_broken

Now, two months later it was updated - with the identical error as mentioned here.

divested-16.0-20200510-dos-klte-recovery.img
divested-16.0-20200510-dos-klte.zip

divested-16.0-20200724-dos-klte-recovery.img
divested-16.0-20200724-dos-klte.zip

What is the point of a new DivestOS build if the old one, and a serious bug, hasn’t been fixed?

i plan on purchasing a larger phone
than any of the phones listed as
supported. 12gb ram 256 or 512gb
storage. Will that work?

@SkewedZeppelin

Pixel 3

When tempted by used Pixels, I remember supporting the used hardware market indirectly supports the new market. I want more devices with replaceable battery and sd card, so Pixels are out.

@steveb

12gb ram

At least that takes advantage of 64 bit OS capability, but seems excessive for a tracking device. :smiley:

@fossys
Can you test something for me?
Extract the boot.img from a recent LineageOS 16.0 for klte.
Flash DivestOS to your klte.
Then flash the LineageOS boot.img.

Tell me if that boots.
Thanks.

also of note, there are many different klte variants.
This one is only for the following as detailed on the LineageOS wiki:

SM-G900AZ
SM-G900F
SM-G900M
SM-G900R4
SM-G900R7
SM-G900T
SM-G900V
SM-G900W8
SM-S902L

did you send this to the right persion?

@fossys
When recently installing an incremental update on my device, while plugged in, it restarted (vendor logo) several times before eventually starting properly. After 2-3 restarts I unplugged it. I don’t recall seeing this during first install, but I also usually go for coffee during first boots. Maybe these are something to try - disconnect from power, and coffee. (no logcats saved)