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.
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, Saw the 0626 shamu download and installed. Others still cannot hear me now from shamu.
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]
@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.
@anon46495926
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.
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.
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.
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.
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).
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.
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.
Now, two months later it was updated - with the identical error as mentioned here.
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.
@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:
@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)
Yes, my SM-G900F “klte” boots now, but - divested-16.0-20200724-dos-klte-recovery is not working.
Divested-Recovery. I have tried six different variations of the installation. Starting point was TWRP 3.3.1-0.
the file “divested-16.0-20200724-dos-klte-recovery.img” was installed via TWRP and immediately booted into the recovery again.
ditto, - but battery removed, then tried to start the recovery by key combination.
the file “divested-16.0-20200724-dos-klte-recovery.img” was installed via TWRP and immediately booted into the system.
ditto, - - but battery removed, then tried to start the system by pressing the POWER key.
odin 3 (with uncheck auto-reboot) flashed the converted file “divested-16.0-20200724-dos-klte-recovery.img.tar”, removed the battery, then started the “klte” into the recovery.
the converted file “divested-16.0-20200724-dos-klte-recovery.img.tar” was flashed via Odin 3 (incl. auto-reboot), the battery was removed, and the “klte” rebooted into the system immediately.
1.-6. each time the identical result: Divested-Recovery was not installed. DivestOS Mobile did not start any more, i.e. in an endless boot loop the following order was displayed:
RECOVERY BOTTING… (blue font color)
Set Warranty Bit : recovery (yellow font color)
Samsung GALAXY S5 (white font color on black background)
With the installation of Divested-Recovery the DivestOS was paralyzed at the same time. As soon as I flashed TWRP 3.3.1-0.img.tar with Odin 3, no matter if with no battery removal, TWRP Rocovery started properly and also(!) DivestOS divested-16.0-20200510-dos-klte booted correctly.
The very first boot process showed a text based error message for less than two seconds in the lower left corner. It went too fast, on the other hand I was surprised and could only read: “A error has occurred … javascrpt”
This error message became fully visible twice more with the first homescreen. Again it went too fast to hold on to. But it must have been at least six to eight test lines. Any reproduction was not possible. I couldn’t take a picture until now. although I turned the S5 on and off several times.
