Does this tool have to be used with avbroot?

[jeffpeng3]

Since the Pixel is no longer capable of OTA updates after rooting, I wanted to try to utilize this tool to accomplish this.
But I've been trying all day and the problem always occurs with the csig signature, but it's impossible for me to get google's private key to sign the csig, which confuses me, does this tool have to be used with avbroot?

[chenxiaolong]

Custota is meant to be used with OTAs signed by a private key you have. avbroot is one option (which re-signs OTAs and optionally roots them also). Some other folks also use Custota with open-source ROMs (eg. LineageOS) that they compiled themselves.

If you really want to use an unmodified stock Pixel OTA, you can use your own key to sign the .csig file, but the corresponding certificate for your key needs to be added into /system/etc/security/otacerts.zip (eg. with a Magisk module). I would not recommend this though.

[jeffpeng3]

Ok, so in my understanding, should csig be signed with the private key of ota too?

Because I was looking at the tool's parameters and noticed that he can accept -c and -C as parameters when generating csig, which seems to be used for csig and ota authentication respectively, and I ran it without any problems, but I got an error when checking for updates.

Maybe I should install the certificate for csig validation somewhere?

Or did I make a mistake somewhere?

03-24 20:36:17.874 17443 26054 D UpdaterThread: Starting new update because engine is idle
03-24 20:36:17.879 17443 17443 D UpdaterService: Updating foreground notification for state: ProgressState(type=INIT, current=0, max=0)
03-24 20:36:17.881 17443 17443 D UpdaterService: Updating foreground notification for state: ProgressState(type=CHECK, current=0, max=0)
03-24 20:36:17.884 17443 26054 D UpdaterThread: Update info URI: content://com.android.externalstorage.documents/tree/primary%3ADownload%2Fota/document/primary%3ADownload%2Fota%2Fhusky.json
03-24 20:36:17.904 17443 26054 D UpdaterThread: Update info: UpdateInfo(version=2, full=LocationInfo(locationOta=husky-ota-ap1a.240305.019.a1-f1130be5.zip, locationCsig=husky-ota-ap1a.240305.019.a1-f1130be5.zip.csig), incremental={})
03-24 20:36:17.910 17443 26054 D UpdaterThread: OTA URI: content://com.android.externalstorage.documents/tree/primary%3ADownload%2Fota/document/primary%3ADownload%2Fota%2Fhusky-ota-ap1a.240305.019.a1-f1130be5.zip
03-24 20:36:17.914 17443 26054 D UpdaterThread: csig URI: content://com.android.externalstorage.documents/tree/primary%3ADownload%2Fota/document/primary%3ADownload%2Fota%2Fhusky-ota-ap1a.240305.019.a1-f1130be5.zip.csig
03-24 20:36:17.933 17443 26054 E UpdaterThread: Failed to install update
03-24 20:36:17.933 17443 26054 E UpdaterThread: com.chiller3.custota.updater.UpdaterThread$BadFormatException: csig is not signed by a trusted key
03-24 20:36:17.933 17443 26054 E UpdaterThread: 	at com.chiller3.custota.updater.UpdaterThread.checkForUpdates(Unknown Source:2138)
03-24 20:36:17.933 17443 26054 E UpdaterThread: 	at com.chiller3.custota.updater.UpdaterThread.run(Unknown Source:259)
03-24 20:36:17.935 17443 26054 D UpdaterThread: Stopping log file
03-24 20:36:17.937 17443 17443 D UpdaterService: Trying to stop service if possible
03-24 20:36:17.937 17443 17443 D UpdaterService: Updater thread completed; stopping service

[chenxiaolong]

Yep, you'll have to grab the existing /system/etc/security/otacerts.zip and add your certificate in there for it to be trusted. Note that Android requires the certificate file extension to be .x509.pem inside the zip.

The easiest way to replace that zip after it has been updated is by creating a Magisk module.

[jeffpeng3]

Is this part of the validation done by Custota?

I was wondering if it would be possible to modify part of the source code so that it could skip validation or specify an external certificate in certain circumstances?

[jeffpeng3]

If modifying the code makes it work, then I'd like to add a "load trusted 3rd party certificates" feature to the debug options to make it compatible without installing additional modules.

[chenxiaolong]

Yeah, that's a good idea. I'll work on that today.

EDIT: To answer your question directly, the .csig validation is done entirely in Custota. update_engine isn't involved for this step. Normally, the certificates inside /system/etc/security/otacerts.zip are used. I'll add a debug option for installing additional certificates so that it'll trust both otacerts.zip + the installed certificates.

[chenxiaolong]

Could you give #48 a try?

[jeffpeng3]

It looks like the csig validation has been passed, but I'm facing some other problems on my device, which looks similar to what you mentioned here.

check.log

This should be due to kernelSU whitelisting, which I fixed by manually extracting the apk and "updating" it.

Now he's working perfectly, and I've successfully OTA'd and switched slots!

It might be possible to provide the apk in the release and mention in the Usage that KernelSU should manually update the app after installing the module and restarting it, so that it works properly.

Or just install a mini apk like magisk and let the user install the full apk the first time they run it, so that every rooting method can follow the same procedure!

[jeffpeng3]

After dozens of tests, I realized that some of the changes in post-fs-data.sh are detected by banking software and denied service...
Since this certificate issue is almost solved, should I open a new issue to solve this problem, or as an alternative solution, I'll just enable this module again every time I need to update it?

[chenxiaolong]

Now he's working perfectly, and I've successfully OTA'd and switched slots!

🎉

I want to find out why KernelSU causes that issue before adding any workarounds. It seems to happen with any module that installs a system app (not just Custota), but I haven't had the time to try and figure out why yet.

After dozens of tests, I realized that some of the changes in post-fs-data.sh are detected by banking software and denied service...

Darn. I don't try to hide root, so I'm a bit out of the loop with this stuff. If I had to guess, it's probably detecting some of the mount points. Does it work if you comment out this section of post-fs-data.sh?

Custota/app/module/post-fs-data.sh

Lines 40 to 64 in 132c23c

	header Linking CA store
	apex_store=/apex/com.android.conscrypt/cacerts
	system_store=/system/etc/security/cacerts
	google_store=${system_store}_google
	standard_store=${system_store}
	update_engine_store=${system_store}
	if [[ -d "${apex_store}" ]]; then
	standard_store=${apex_store}
	fi
	if [[ -d "${google_store}" ]]; then
	update_engine_store=${google_store}
	fi
	echo "Standard trust store: ${standard_store}"
	echo "update_engine trust store: ${update_engine_store}"
	rm -rf "${mod_dir}"/system/etc/security
	if [[ "${standard_store}" != "${update_engine_store}" ]]; then
	mkdir -p "${mod_dir}"/system/etc/security
	ln -sfn "${standard_store}" "${mod_dir}${update_engine_store}"
	fi

If you're on the March 2024 update or newer, this should not have much impact. (But on anything older, without this logic, the system only trusts a very small number of certificates for connecting to the OTA server over HTTPS.)

If that doesn't work, you're probably stuck with enabling/disabling the module when needed. The SELinux parts of post-fs-data.sh are required.

[jeffpeng3]

I want to find out why KernelSU causes that issue before adding any workarounds. It seems to happen with any module that installs a system app (not just Custota), but I haven't had the time to try and figure out why yet.

Okay, I understand, I'll try to go to the KernelSU community to try to understand the details of this part.

Then I do have the March 2024 update, but after I commented out this section, custota doesn't work properly and is still detected, so it looks like selinux is being detected.