I know this particular thread is (mostly, when it's on topic) about the locked bootloader on the US versions of the Galaxy S7 and S7 Edge; but maybe there's a problem with "forest because of the trees" viewpoints.
Mobile phones are - basically - small computers with radio transceivers integrated into them. Computers *can* be programmed; but to do that one has to understand how the particular computer works.
Now, when one of these phones powers up; there's obviously a sequence of events. None of the pieces are completely independent; they interact.
First of all; a caveat. I'm not an Android expert; nor; for that matter; a mobile phone expert; but I have worked with computers for over 50 years now. And in general; computers tend to follow the same logical steps. The hardware powers on; the initial boot sequence (usually a hardware function) loads a "bootstrap" (which in the case of a mobile phone is probably the bootloader firmware section; or a portion of it) ; and then passes control to the code just loaded. So the question then becomes; how do we make use of this?
I wonder if the answer isn't in how the engineering boot image "works". Obviously, the boot loader continues to manage to load it; *even though* folks root it. Now; signing usually involves keys. But realistically the only way to verify that the key actually matches the code is if some "checksum" methodology is used to ensure that code itself hasn't been altered. Yet in the case of the engineering boot image; once rooted; it *has* been altered. Yet it still passes the signing check from the bootloader each time the phone is power cycled. How?
Another question is about the bootloader itself. Does it remain in memory (and have a function) after the basic phone firmware is loaded? Or is it "overlaid" by the code it loads and thus disappears once the phone software is initialized? If so; why couldn't one of those "engineering boot images" perform a similar function *after* it gets loaded? IE; read a custom rom image from device or extermal storage (maybe from a SD card?) and load it on top of it's code originally loaded by the bootloader; and then transfer control to it? Just like the bootloader itself does; but without the signing checks? *IF* you can root an engineering boot image; then it seems like you could add this functionality to it. Yes; it might take longer for a phone to completely initialize after power on; but is that a significant concern?
There's also the question as to whether there are any *other* Snapdragon-based (QC) phones using this same chip *outside* the US that don't have locked bootloaders; but are still signed (if the initial bootloader image is forced to be signed by the Snapdragon chip itself)? If so; could one of their images be flashed in place of the ones used in the US?
And one more. Just why can't a bootloader be "down rev'ed" once it's "upgraded"? It's just code. What does installing a "new" version actually *do* that can't be "undone" if you totally replace that code with a previous version? I understand that this might make the boot image that it would then try to load incompatible; but that can be re-written as well.
Just a few "outside of the box" questions.
Mobile phones are - basically - small computers with radio transceivers integrated into them. Computers *can* be programmed; but to do that one has to understand how the particular computer works.
Now, when one of these phones powers up; there's obviously a sequence of events. None of the pieces are completely independent; they interact.
First of all; a caveat. I'm not an Android expert; nor; for that matter; a mobile phone expert; but I have worked with computers for over 50 years now. And in general; computers tend to follow the same logical steps. The hardware powers on; the initial boot sequence (usually a hardware function) loads a "bootstrap" (which in the case of a mobile phone is probably the bootloader firmware section; or a portion of it) ; and then passes control to the code just loaded. So the question then becomes; how do we make use of this?
I wonder if the answer isn't in how the engineering boot image "works". Obviously, the boot loader continues to manage to load it; *even though* folks root it. Now; signing usually involves keys. But realistically the only way to verify that the key actually matches the code is if some "checksum" methodology is used to ensure that code itself hasn't been altered. Yet in the case of the engineering boot image; once rooted; it *has* been altered. Yet it still passes the signing check from the bootloader each time the phone is power cycled. How?
Another question is about the bootloader itself. Does it remain in memory (and have a function) after the basic phone firmware is loaded? Or is it "overlaid" by the code it loads and thus disappears once the phone software is initialized? If so; why couldn't one of those "engineering boot images" perform a similar function *after* it gets loaded? IE; read a custom rom image from device or extermal storage (maybe from a SD card?) and load it on top of it's code originally loaded by the bootloader; and then transfer control to it? Just like the bootloader itself does; but without the signing checks? *IF* you can root an engineering boot image; then it seems like you could add this functionality to it. Yes; it might take longer for a phone to completely initialize after power on; but is that a significant concern?
There's also the question as to whether there are any *other* Snapdragon-based (QC) phones using this same chip *outside* the US that don't have locked bootloaders; but are still signed (if the initial bootloader image is forced to be signed by the Snapdragon chip itself)? If so; could one of their images be flashed in place of the ones used in the US?
And one more. Just why can't a bootloader be "down rev'ed" once it's "upgraded"? It's just code. What does installing a "new" version actually *do* that can't be "undone" if you totally replace that code with a previous version? I understand that this might make the boot image that it would then try to load incompatible; but that can be re-written as well.
Just a few "outside of the box" questions.
