Re: [PLUG] Rooting Phone Experiences

[Rich Freeman <r-plug@thefreemanclan.net>]

On Thu, Jan 7, 2016 at 9:39 AM, Mike DePaulo <mikedep333@gmail.com> wrote:
> And above fastboot is your recovery environment.

I guess this is just definitions, but I'd say that recovery is BELOW fastboot.

>
> Your recovery environment lets you flash new ROMs. Sometimes people
> install new recovery environments, but in case you mess up your
> recovery environment, fastboot lets you recover your recovery
> environment.

Correct, many do choose do do their flashing from recovery.  Either
does work, though I tend to prefer using fastboot.

A bit more background.

The phone's ROM (and perhaps some flash that isn't normally touched)
loads the bootloader image and runs it.  I believe the bootloader
loads the radio image for the baseband CPU, which then runs
independently (I'm not 100% sure on that - the baseband CPU could very
well be bootstraped before the bootloader runs).

At that point the bootloader looks for keyboard input.  If there is
nothing going on it loads the boot image which is a standard linux
kernel+initramfs (linux in general supports embedding an initramfs in
the kernel).  If there is input the details are a bit
device-dependent, but you have an option of going into either fastboot
or recovery mode.

Fastboot is implemented purely in the bootloader, and it just accepts
images which are at most checksum/signature-verified and then loaded
into the appropriate partition.  The bootloader doesn't understand
anything about filesystems/etc.

If you tell the bootloader to go into recovery image it does the exact
same thing as a normal boot, except it loads the kernel+initramfs from
the recovery partition instead of the boot partition.  The recovery
initramfs typically is self-contained with all the userspace needed to
display the UI and let users do all their flashing.  At that point
you're running a full linux OS with userspace in the initramfs and it
can do anything your PC can do - like mount filesystems and edit
things at the file level and so on.  Heck, while nobody has
implemented this it could even configure the network and give you a
browser or mount sshfs shares or whatever.

Going back to the normal boot process - the boot kernel+initramfs
typically mounts the system partition and then transitions execution
over to it (I'd have to look up the details).  In this regard this is
fairly similar to a traditional linux distro, except that the
initramfs is combined with the kernel image in a raw boot partition
and not stored as separate files in a boot filesystem.

So, the two basic ways to go about flashing stuff on android are:
1.  Flash raw images using fastboot.  This would be a bit like a linux
distro where to install it you boot a CD and dd an image file to
/dev/sda or something like that.  Since phone images tend to be
one-size-fits-all anyway I find this to be the cleanest approach -
you're completely wiping what is there and ending up with a controlled
image.
2.  Run an install zip file from recovery.  These zip files contain a
bunch of files, a manifest with signatures/etc, and install scripts.
These can be used to everything from wiping the system partition and
reloading it to just verifying a known initial state and just updating
selected files (which is how over-the-air updates work).  They can be
also used to just make tweaks, such as installing supersu but not
otherwise touching the existing install.

Oh, and one more thing to keep in mind.  Android Pay is now being a
lot more particular about modifications to the system partition, which
means that it won't work on most third-party ROMs.  Right now it
doesn't look at the boot image, so a workaround is to use a
"systemless root" which is basically a modified kernel that adds some
kind of system call back-door and then you can run an app which
triggers it.  There won't be any files added to the system partition,
so the checks don't spot them.

I really see the whole Android Pay situation leading to an arms race.
Google will start checking the boot image.  Then the boot image kernel
will start intercepting reads of the boot image like a rootkit and
return vendor-signed data and not the real boot image, and so on.
Short of them going the full trusted computing route Google can't
really verify what is running on the phone.  (And if they ever do go
the trusted computing route get ready for the virus that resets the
TPM and permanently disables Android Pay on 90% of Android phones or
whatever, unless they use a TPM that can't be reset.  Whenever I read
about hardware fuses I just wonder when the first virus comes along
and permanently trips them all.)

Again, hopefully this is helpful.  The android boot process would
actually be a great short talk of its own.

--
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug