[Shield Android TV Android Development] Downunder35m:
What do you mean "going back"?

Right now the 7.2 is the official and latest firmware.

I was unable to get my hands in the 7.2.1 but guess it might have been a testversion for certain models only.

I wasted a few hours trying to fix the system image.

First stage was only to get the basic "features" back, like full ADB support, enabling the support to use SU and busybox....

Just what is required to actually allow these nice apps we like to gain root to work.

This backfired badly as right after the start the bootloader complained about the system being corrup and no override to get past this worked.

So of course I then removed the known restrictions from the bootloader...

As you guessed it the damn thing then did not even boot at all, just jumped right into the (locked) recovery mode.

A half decent comparision with my last manual root on a tv box that was a success showed I still did the right things...

If anyone wondered why we needed a new bootloader for the support of smart helpers an some codes stuff:

We didn't as all this could have been done with the 7.1 bootloader as well.

Since my root attempts so far all ended either in disaster or in a root access that failed shortly after/corrupted the system, I took a look of the general kernel changes that were published for other devices.

Before I could find anything meaningful I realised the 4.9 kernel is actually a requirement for Android Pie!

With that info sorted I started digging inti the new "security" features Pie can offer.

I will try to keep it simple and to the stuff that actually concerns us for rooting purposes:

The new boot process with Pie is aimed at being secure from the hardware level up and all the way into the system partion once the boot is completed.

So the hardware checks if the bootloader is actually usable - we had that for a long time, nothing new.

Once the bootloader starts and reaches the point of actually getting somewhere, all partitions required will be checks by either a hash check or a trusted certificate gererated at boot time that is compared to the previous certificate.

Only if that is fine the bootloader will call upon the system and vendor partitions.

The handover of control from bootloader to the system is made far more secure as well.

SELinux is called early on to ensure that only trusted apps and tasks can work but also to all a new control level.

System related apps no longer run as root or with special permissions.

Instead every single app and service runs as its own user!

And under SELinux conditions this means nothing can access anything that it is not entitled to unless included as a user for the other app.

And with that sorted the vendor stuff is called to ensure all hardware and vendor related stuff is still genuine - this include the required certs but also the recovery and bootloader hash codes and certs.

So if something is fishy either SELinux will stop us or the vendor stuff will just overwrite it all.

Once we finally reach the system stage the recovery is checked if called from within the system, if fully implemented it could mean that using an official update on a modded firmware will delete all data as the encryption from the old system is declared invalid.

Sadly it does not stop there because even with full rigths (faked or otherwise) to access the system partition with write access we still can not just change things.

If something belongs to a user (a secure app) than a change will corrupt the system.

To overcome all this without using vulnerabilities that so far no one has found, a compatible userdebug release has to be created from the official user firmware.

DM-Verity needs to be disabled as well as all partition encryption stuff.

The bootloader needs to be adjusted to reflect these changes and the required turst certificates generated and included in both system and boot images.

The only problem here is that the kernel won't allow these changes unless it itself is a userdebug kernel.

After that it is only the little efford to go through about 60 different scripts to remove or redirect the calls for all boot and system security related things.

If then by some chance all this actually boots up and goes all the way into a usable homescreen the entire stuff needs to be secured again.

This time so that the final system has a correct cert and checksum that matches those we need to include in the bootloader.

Anyone knows how to gain full access to the trusted keystore on the 4.9 kernel? LOL

For the moment I don't really care about all the stuff above.

I would be happy to figue out what to make out of these new fstab configurations without the vital partitions listed.

The real aprtitions used have not changed but it is impossible include them in the fastab, doing so causes the bootloader to fail.

Presumably because the kernel realised we try to get around the verification process.

This and some other minor things are also the reason TWRP fails so badly, same for the stock recovery by the way.

Since TWRP is toy a lot us like:

TWRP and 7.2....

Without a system partion in the bootloader fastab TWRP can not mount it.

Same for all other things TWRP needs to mount as it simply does not have the right to access these areas.

To make things worse, we need system access to even start TWRP through fastboot.

So, now matter if we flash or start it through fastboot: The bootloader and system will realise our recovery does not match the checksum.

What does al this now mean in terms a lot more people are able to understand?

Let me try...

Imagine the 7.2 in a running version would be just some encrypted file with a lot of folders in it.

And like PGP or other encryptions software we know there is a private and a public key.

With the public key you can see a lot and use most the encrypted file - but only to a level that is required, nothing above your low level clearance.

For every attempt to write into this file or to make changes we need the private key.

If you follow so far then lets just say the recovery (stock) and Fastboot can be, to some extent, used for this access.

But since every folder in the encrypted file also uses private and public keys it is like tracing a tree.

Although it is getting too long, let me give you the example of just adding SU to the sytem partition:

Adding SU into the system image is no big deal.

Singing this image to get a usable key and including this key into the keystore is.

Assume we would just be able to do it....

SU needs to be called quite early in the boot process.

It then elevates the access level for certain things and also intercepts all root related requests from apps and services.

Except of course those that already had these rights by default.

Problem here is that adding the scripts we need plus changing some others means violating the tree of trust on the device and we get locked out.

Finding a spot to add the required rights for SU might be still possible.

On the other hand it will be impossible to give SU any rights or access to "trusted user" owned parts, files, folders, partitions....

The entire concept of SU just fails.

I will have to check how much of the new features are active in the 7.2 kernel that hinder us.

If I find enough it might be possible it enough to call for a Magisk update.

But I guess it is of little use for just one set of devices, so maybe once more devices on the 4.9 kernel fail to work with Magisk it will be easier to spot a usable pattern.

In case someone else if already working ona mdified system: Please let me know how you made it boot after the changes ;)