[Verizon Samsung Galaxy S 4] Loglud:
So I know everyone wants to get a boot loader hack, and as I read I notice a lack of guides on what is a boot loader, how it works, and a lot of references on learning.

Why am I posting this?​

That’s a very good question. There are two main reasons for me posting this. The first reason is that the developers are often times too busy to work on trying to explain and educate the public on the ins an outs of boot loaders. The second reason for this is that I am a firm believer in open transparency. When bounties and other incentives are offered to the community we loose site of what the goal is: To unlock the boot loader. People become so secretive and ideas are not shared, this makes it so people perceive a competition between devs, instead of a competition between the devs and the company’s. This is why I love providing this information, because in the end the money doesn’t matter, it’s the boot loader unlock. So for those two reasons I have created this thread.

So let us begin:

What is a boot loader?​

It is a common misconception that a boot loader boots up the OS. Yes this is a type of boot loader, but it is not necessarily what a boot loader is. A boot loader is a set of machine instructions that push a device from an off state to an on state. By looking at this definition we lean there are so many more boot loaders.

Low-Level boot loaders​

These are the boot loader that we usually don’t look at, or hear about. Most of the time these are what are referred to as chip firmware. An example of this is when we look at something like NVFLASH, or other programs that can fix a device regardless of how bricked the device is. With in these boot loaders often times contains the operations on how to start the device i.e. start up the power supply, and other very low level functions.

omappedia.org​

When we say a boot loader is locked this is usually where the security chain starts. Once this has issued the next stage boot loader, it checks to make sure the signature is correct. We will discuss how they do this in later sections.

omappedia.org​

High-Level boot loaders​

These are the boot loaders we are used to things such as Uboot, Aboot, rrboot, Hboot. These binaries are often located in an on chip memory bank. These are the boot loaders that check for buttons pressed, whether to boot into recovery or normal, and what we usually focus on hacking, as we have access to this subsystem through the USB.

omappedia.org​

Many of the on chip boot loaders such as the Low-Level boot loaders are not accessible unless directly connected to the chips leads, however these High-Level boot loaders can be accessed via SPI, I2C, or other inter chip communication.

omappedia.org​

Well that’s all fine and dandy but how the heck do they lock them, can’t we just disable it?

Well unfortunately they have already thought of this. This is where we get QFuses, Write Protect, and other “security” measures that prevent us from reading or writing new code on top. With these “On Chip” security measures, a company is able to start the chain of trust from the initial stage boot loader always making sure that the next stage has a valid signature.

Lets go over a couple of different types of Countermeasures:

eFuses

eFuses are the death of all hackers as these truly are one time write. The idea of an efuse is effectively to blow up a connection to change the value of a bit.

xda-developers.com​

When we look at the image above we can clearly see that one of them seems to be damaged. This one has been written too, and has actually destroyed the connection, making it impossible to reconnect it, unless you want to FIB it and deposit the metal.

Supervisory Code

Supervisory Code is actually more common then most people think. The idea of this is to have an SROM, which contains supervisory commands that are hardcoded commands. These commands are the only commands that can operate on SRAM that is on chip. Once these SROM codes can only be used from the chip level, and cannot be executed if the MMAP table in SRAM has write protection on it, if it does the entire boot loader is erased.

EEPROM

This is an older tech and really isn’t used that much. The basic principle of this is utilizing the idea the semiconductors can behave like ROM under given conditions, and erased given other conditions.

hitequest.com​

This is used in tech like NVRAM and such. It relies on being able to supply multiple voltages as seen above. Another old way of erasing was to flash with UV light as it allowed for all of them to reach the erase condition. The problem is that once programed, they cannot be changed because it requires higher voltages to change. These types are often programed off board and then placed on board, or have usage of something like JTAG to reprogram.

There are many more security measures and this list will continue to expand.

Okay well this all sucks how have we unlocked boot loaders in the past?

Wow now that one is a tough one as there are so many different ways. But lets try and get a list started

Buffer Overload

This method is probably one of the coolest methods out there. I utilizes the basic structure of how subroutines work and then exploits them. When subroutine or for that case a variable enters that stack it gets put there, and then the return address gets put on the end so that it will return to the designated location. The problem comes in when we don’t have sanity checking of variables, or we don’t catch overflowing them. The explanation of this is highly complicated so I’m going to sight some text from Wiki.

#include <string.h>

void foo (char *bar)
{
char c[12];

strcpy(c, bar); // no bounds checking...
}

int main (int argc, char **argv)
{
foo(argv[1]);
}

For some one whom sees this they can see that we can specify an array of char with a length longer then 10 and cause a collision into the return address of the stack read. This type of buffer overflow is often referred to as stack smashing. We utilized a technique like this when we built the stack smash for the nook tablet boot loader unlock. We relied on them not checking the header size before loading it into memory. By extending the header by 4 bytes we could smash our own custom return address onto the stack.

Overwriting Existing Code Calls

This is actually how loki worked. It relied on an idea of loading a ramdisk, over existing memory. In this case we utilized shell code that jumped us out of the signature check. By doing this we told the boot loaders to load a ramdisk into a location in memory where we know it will be called. There are three major things done here that we rely on.

The security check for the boot loader occurs when the boot loader is loaded from the ram, any code, which modifies it within the boot loader, will not return as a tampered device.

The boot loader loads the kernel and the ramdisk from memory. Once loaded, then functions are preformed on this. The locations of the ramdisk load are given in the boot header meaning that you can specify any where in code you want to load the ramdisk too.

The function that is being overwritten must be called.

When we look at loki we see that they are overwriting the check_sig function, and putting the custom written shell code there. Once loaded when that function is called it calls the custom code instead of the functional code for check_sig.

I've generated a very rudimentary animation showing how loki works.

​

This method is extremely tedious as there is no source for a lot of the boot loaders meaning that hole have to be discovered in assembly or a reference to other source codes.

Making a device S-Off or disabling boot loader checking.

This is the one thing that I’m least familiar with. It involves utilizing the boot loader parameters themselves to disable the boot security of primary boot loaders. I’m hopping that someone will be able to point me to more information on how we do this. I do know that doing this is the only true way to unlock a boot loader. Otherwise we rely on the boot loaders not being patched.

Bootstraping and 2nd init

This is actually the “easiest” (use that term lightly) way to overwrite the boot loader. This relies on the system booting up either partially or fully. Theres a really great article here cvpcs.org . The premises of this is that there is an order in which things get booted up. In motorola’s example they boot up the data in the init. They use a ptrace to attach it to the head of the stack, and then when the stack is fully loaded it loads another init, and ramdisk on top of it. This shuts down the entire previous system and allows a second system to be run on top of the current system. In this case the loads take longer as they wait for the complete boot and then boot again on top.

Security leaks and holes.

When we look at the history of hacking we can see that it has always been around and will always be around. For as long as there are new security measures there will be hackers trying. One of the greatest tools that we can get is when leaks occur or when we get holes discovered. One of the greatest examples I can think of was that of the SGNII.

One of the first boot loader hacks discovered with a hole in the boot chain. The Low-level boot loader called the high-level boot loader. The high level boot loader would then check the signature of the boot.img. However they did not check the recovery signature and as such we were able to load another boot loader into the recovery.

Another one of these came in the form of a leak was the SGS3 boot loader. Remember how I said earlier we develop a secure boot chain that goes starts at a Low-Level boot loader. Well in this case we were provided a new boot loader that broke the chain. This boot loader had a valid signature so that the first Low-Level boot loader could verify, and then from there on out there were no verifications.

This thread will continue to grow and evolve.

I WELCOME ALL CONTENT AND CRITICISM. PLEASE LET ME KNOW IF I'M MISSING SOMETHING.