How to sideload an OTA update??

missing-root

GrapheneOS publishes OTA update archives with every release.

These should be possible to install. A use case could be minimizing downloads when using many devices over a metered connection.

The problem is, that even when unlocking the bootloader and enabling ADB, I cannot use the normal method:

restart to bootloader
use "adb sideload ota-update.zip"

As ADB connection is disabled in the stock bootloader.

Booting (not flashing) TWRP didnt work either because my device is locked. Maybe I forgot when to unlock it? I would also like to avoid TWRP.

My specific use case is on an EOL device, which I dont use for anything sensitive. So please spare me with advices, I dont use that device for anything really.

In this case, I need to extract some protected files from an app, which seems to not be possible without root. It is quite a pain to achieve good modern root with avbroot and this is the last step.

This is not about a production phone, but it is important to get that data, there are no other methods. I need the database of an app.

de0u

missing-root I have personally sideloaded an OTA update, albeit not recently. So I don't think this function is disabled in a global sense.

However, the OTA sideload function checks that the ostensible update is signed by the same key as the currently-installed system. It also checks that the version of the ostensible update is greater than (or equal to, I think) the version number of the installed system.

Edit: note that sideloading does not use "regular adb". Recovery must be in "accepting sideload" mode, see: https://grapheneos.org/usage#updates-sideloading

raccoondad

missing-root

TWRP isn't supported or needed on Pixel devices. You can't boot any custom env. on a pixel device if its locked, thats what locked means. Its locked, it doesn't boot custom images anymore. Unlock (and wipe) the device to do that

You need to enter recovery -> load update from ADB (I forgot the specific text), it only works with OTA updates that are signed by GrapheneOS and only by GrapheneOS

Root is not supported by GrapheneOS, you would need to wipe your device and create a custom operating system to achieve root.

ADB is not supported by fastboot, only recovery can do it, and recovery will also deny unsigned OTA updates. You can flash a custom key and build GOS with a root addition and then sign it but that's it. Its not GOS at that point

yore

missing-root

Not to hijack the thread but:

Are there any advantages of sideloading an update? I saw somewhere it mentioned the update size is smaller; is that the size of the download or the installed update? I know regular OTA updates are delta updates and increment.

missing-root

raccoondad

Okay thanks, the different key would be the problem here.

If there is a different way to dump the entire storage of an app, that would be fine.

locked

Also clarifying, that bootloader does not need to be unlocked to sideload updates.

missing-root

locked I searched and could only find guides that were pretty insecure.

If anyone could post a way to sideload valid OTA updates, that would be great

The root tool I use (as I seem to need to) even has custom keys to sign everything, so verified boot works

locked

missing-root You should only be using official documentation to install GoS or any OTA updates. As far as sideloading is concerned. You'll have to first make sure that standalone platform tools is installed then you should follow the sideloading instructions. You do this through recovery. How to boot into recovery is explained in CLI install guide.

As far as TWRP? You don't need it, and can't load it with GoS. You don't need to root either, any specific reason why you are trying to do so? You should follow the steps above, if you already have GoS installed. Don't unlock the bootloader either, otherwise you probably won't be able to update.

raccoondad

missing-root We don't know what app you are using, but if it needs root, its not possible to get root privileges on GOS.

missing-root

raccoondad I might need to use something else then, which isnt nice... maybe waydroid works for that purpuse

missing-root

locked

Thanks I will check that again. I used the CLI method a lot of times, am pretty familiar with the method as a previous LineageOS user.

I even tried to fix the CLI guide but that had some issues. Should do that again.

I need root to extract a key from a shady proprietary app. Here it is a Xiami Fitness app, the key is needed so that I can connect the smartband with Gadgetbridge.

They seem to have patched a leak of the key in the app logs, but for some reason even on really old versions of that app.

So the only way is to get it from the internal app database, and to access that I need root, because the AOSP filemanager is so restricted (afaik it would have the permissions to view those contents)

de0u

missing-root I need root to extract a key from a shady proprietary app.

To be clear, sideloading a regular GrapheneOS OTA image will not root the device. And sideloading a tweaked official OTA image, or an image you build and sign, will result in the sideloader rejecting the image due to a signature mismatch.

...Unless your bootloader is already unlocked, or you have discovered a way to sign edited GrapheneOS images (in which case you're on the verge of being rich).

missing-root

Anyways, the concerned app still leaks the key in the logfile, so this is currently not needed.

It would still be useful to know how to root GrapheneOS or otherwise get access to apps' internal storage.

With local device access, unlocked, etc. There should be no security problem as at that point you are already in?

But if still not possible, this would of course be nice for apps like Signal, not encrypting the data in the container.

missing-root

yore

Android uses A/B partitions for updating. You have 2 system slots, and you always switch between them on updates.

Afaik:

You are in Slot A. Slot B has the same content as Slot A.
You do an update, the system updater downloads only the differences between the new image and slot A (I think. @GrapheneOS It could also use slot B but more on that later)
The system updater has downloaded the update and now writes the complete (local + diff) system to the inactive slot B
The checksums of the update are verified to be correct
Maybe more steps I skipped
You get a reboot prompt

If you reboot, the bootloader automatically boots into slot B. This contains the new system.

In an early boot stage, system apps (afaik) are optimized. Afaik this means they are re-precompiled onto the new libraries.

Android apps are mostly Java, which can be dynamically compiled or precompiled. Precompilation takes more time once, but should be faster afterwards.

This avoids the Javascript JIT compilation at runtime, which is a security benefit because JIT is a major attack vector for exploits.

So the system apps are recompiled and you can login.

Afterwards the user apps are recompiled the same, on a typical "gotta try everything" setup this takes quite a while.

You get prompted to restart all those apps, which kills the processes so you need to restart them.

After the new system runs for some time, it is proven to work. Now, afaik, it is copied to the inactive slot A, possibly to prevent malicious rollbacks.

Then the whole cycle repeats once a new update is pushed.

Afaik this is different from stock Android in many cases:

Playstore precompiles only often used areas of apps, for speed purposes. There is no precompilation of everything, so JIT could be exploited
the system apps may also not be precompiled that extensively, but I could be wrong here
there is no "kill running apps" prompt to make sure apps are using the latest libraries

de0u

missing-root After the new system runs for some time, it is proven to work. Now, afaik, it is copied to the inactive slot A, possibly to prevent malicious rollbacks.

No copying: the "which slot is primary" switch is flipped from A to B, or else B to A.

Also, the "some time" is pretty brief. I think by the time you can unlock, it's already flipped.

yore

missing-root Thanks for the detailed explanation!

But is there still an advantage of installing via sideloading over standard OTA?

de0u

yore But is there still an advantage of installing via sideloading over standard OTA?

Not for most users, which is why the system is set up to automatically fetch and install updates. Sideloading is for various special use cases.

As one example, if something has gone horribly wrong with the system partition but Recovery still works, depending on what went wrong sideloading an OTA update might fix the problem.

OTA sideloading uses adb, which regular users are not expected to use during regular Android use.