0

Everyone complains about locked bootloaders on phones. From reading the bootloader seems to be code stored on the partition which /boot is mounted. Once the phone is rooted why couldn't one just delete what's on /boot and put their own stuff there. When you do an OTA and it update the boot loader I assume it just writes files to this partition.

In a Linux distro I can replace grub which is stored in boot with LILO or whatever by simply replace the files in /boot and write the PBR to the head of that partition to then boot into LILO. When the PC boots it looks at the MBR which tells it to look at the active partitin (persumably the one with /boot), chain into that and read the LILO code at the head which then does stuff with all the other files in /boot.

How do android devices boot differently that prevents that?

2
  • 1
    check this: android.stackexchange.com/questions/46186/…
    – wuodland
    Commented Mar 6, 2014 at 17:40
  • @KaranRajBaruah - Thanks I read that awhile ago. I still don't see why once you have a rooted device you can't replace the /boot partition. The bootloader isn't hard burned into the phone. It don't think it's comparable with rewriting the BIOS, more comparable to rewriting whats on that mountable partition. Commented Mar 6, 2014 at 18:06

1 Answer 1

6

The bootloader is not generally on the /boot partition, it's on a separate one, although that's not really the crux of the issue.

The problem occurs when the bootloader is cryptographically signed, which is intended to prevent you from replacing it with your own. The device will check the signature of the bootloader at startup and refuse to boot one with an invalid signature. After that, the bootloader checks the signature of whatever is in /boot, refusing to boot that if it's not signed validly. Therefore, you can't overwrite either partition without rendering the device unbootable.

When a bootloader is unlocked, it will not check the signature of the other partition images, which is why you are able to install custom ROMs. This means that you don't need to replace the bootloader in order to modify /boot, you just need to unlock it so that it skips the signature check on /boot. If the bootloader is locked and signed, then you're essentially stuck, barring an exploit that allows you to bypass one of the signature verification steps.

This also means that locked bootloaders, in and of themselves, are not necessarily a problem. The real problem is signed bootloaders that do not provide an unlocking mechanism.

The process is (more or less) analagous to UEFI Secure boot, although it's probably not exactly the same architectural implementation. Incidentally, going with your example of Linux, one of the primary criticisms of UEFI Secure boot is that it could potentially be used to prevent installation of alternative OSes on traditional PCs via the same signature checking scheme.

6
  • Let's take the GS4. There is what's hard burned into the phone. This is similar to EFI or BIOS and can NOT be changed. It is hard coded to check the signature on BL. At first Samsung was cool and provided a (signed?) BL that did not care what ROM it loaded on /boot (unlocked). Since Samsung has the keys they can update BL and sign it. They decided to update the BL OTA and enforce signature checking on the ROM. This essentially locked the bootloader. Locked or unlocked whatever is in the BL partition must be code-signed because the phone is hard coded to check and it can not be disabled Commented Mar 7, 2014 at 11:56
  • Is that correct? If so, why can't one simply put the old, unlocked code into the BL partition? Also is it possible to change what loads the BL, similar to flashing BIOS, or is it straight hard coded into the board. Thanks for the informative answer btw. Commented Mar 7, 2014 at 11:57
  • In theory, downgrading would be an option, and is the angle that most modders would probably investigate. In practice, it may not be entirely easy to do. I don't know about Samsung specifically, but other manufacturers have implemented software restrictions to prevent you from downgrading your bootloader via normal means. That may be the hangup in your example as well, and would require finding a way to write the bootloader outside supported methods. Commented Mar 7, 2014 at 14:47
  • With regards to modifying the the stage before the bootloader: again, it may be possible in theory. The Kindle Fire had a first stage loader that was writable. However, code for such a loader may not be available publicly (most bootloaders are proprietary for that matter), so modifying the first stage would probably be difficult. I'm also not sure if all phones use a first stage loader in the same way, or if it is read-only on those that do. It would probably be reasonable for it to live on read only memory, since needing to update it would be unlikely. Commented Mar 7, 2014 at 14:51
  • How wouldn't the BL be writable? Aren't these just partitions on the internal flash (a glorified internal SD card) Commented Mar 7, 2014 at 15:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .