A bootloader is a computer program that loads the main operating system or runtime environment for the computer after completion of self-tests. Manufacturers install this on their devices because they want that users can only run their OS

At its most basic level, your Android smartphone is like a hard drive, made of up several partitions. One of those partitions holds the Android system files, another holds all the app data you accumulate (which is how you're usually able to update without losing all your stuff), and others to do more behind-the scenes stuff. Think of the bootloader as a security checkpoint for all those partitions. Because if you're able to swap out what's on those partitions, you're able to break things if you don't know what you're doing. Or, with a little hackery, you're able to run custom ROMs.

When you turn on your Android device, the bootloader gets things going, then passes off control to the boot image (the part of the disk that holds the start-up files for your phone). The boot image loads the phone's Kernel, then loads Android, following instructions found in those files. You copy this boot image to a phone by flashing it to the phones internal system memory - not the RAM or running memory, but the physical flash storage in the phone. That's why there's a potential for danger. Screw this up, and you could really screw up your phone, turning it into a "brick." Depending on how you're hacking into it, that might be more than a mere possibility. It varies from phone to phone.

Very few people, once you put it in perspective. The majority of the 400,000 Android devices activated every day are users who have no idea (or would ever care) what a bootloader is. They are the young girl you see at the hairdresser, texting her friends. Or the guy in the hardware store, checking his notes to buy bolts for something. Android is now mainstream, and the simple fact that you're here, wanting to learn more about this bootloader stuff, means you're a more advanced user than most.

The people who do care (and often are loudly passionate about it) are the guys and gals who want to have complete control over what software goes on their Android phones. They are the coders, themers, developers and hackers who endlessly tinker and improve the system they were given, and turn it into something better. Or worse. Either way - it's theirs. You'll find those folks in huge numbers on the Internet, which makes us feel that we're in the majority of users, even though we're not.

If you have a locked bootloader, you can only flash boot images that have been digitally signed with a string of information direct from the manufacturer. You can't build your own and flash it to the phone. The recovery partition is the same way - it's checked for the right signature, and if it doesn't have it, you can't write a new one to the flash memory. This really only means one thing:

A bootloader lets you change all the software on your phone. By locking it, you are prevented from doing so. Why do manufacturers do this? Well, they try to never say directly, but you can guess the reasons:

  • they don't want customers accidentally uploading faulty software to their phone, bricking it, and coming crying back
  • they want to give as little attack surface as possible to hackers looking to meddle with the phone, for whatever security reasons
  • at the request of various third parties, such as carriers
  • they don't want custom software being put on that gives the device extra functionality or lifetime
android tool.png
But when you have a phone with an unlocked bootloader, the "hacker" type of development will come at a record pace. Root, custom ROMs, ports of other device software - all the things many of us love about Android. And to top it off, unlocked bootloaders mean custom kernels - overclocking, USB host, and all manner of other goodies that's pretty darn difficult to manage on phones with locked bootloaders, as well as an easy way to load it on your own phone.

android-reading1-292x300.png CRYPT(OGRAPH)IC TERMS
Symmetric encryption
This is the typical, familiar, scramble-your-data algorithm. You use one secret key, together with your data (called plaintext), and input them to the function. It spits out random-looking output (ciphertext). You put your ciphertext back into it with the same key, and you get your original data back again. With this, either exactly the same function does encryption and decryption, or one function does encryption and a similar, but different one does decryption. The most popular algorithm is called AES.

Asymmetric/public key encryption
This is slightly different from the above. This time, you have two keys. One is called the public one, and it is figured out from the private one. The private key cannot be figured out from the public key. They only work in a pair as well: If you do encryption with one, you can only decrypt with the other. This is why it is special. If you encrypt with the private key, you cannot decrypt with the private key again, only with the public (and visa-versa). The most popular algorithm is RSA.

Cryptographic hash
This is a one-way function. You can input as much data as you want into it, and it will come out with a fixed number of digits (usually in hex). The digits that come out do so in a very random, and mostly normalized way. A good property of a hash function is that changing 1 bit in your input, should have a 50% chance of changing every bit in the hash's output. This means hashes are fairly unique to any particular data, and can detect even the slightest changes in it by comparing two hash outputs together. The most popular hash function is SHA, the most well known is MD5.

Digital signature
This uses the last two above terms. You have a message, and you want to sign it. When they verify the signature, a receiving party can tell two things:

A) That the message came from you, and

B) That the message has come exactly as you intended it.

How? First, you make a private/public key pair, and publish your public key everywhere a while beforehand. People remember the public key and know that you made it. When you want to send a message, first you hash that message. The hash will let anyone know if someone has tampered with the message during sending. Then you encrypt the hash with your private key (you have now signed your message). You send off the encrypted hash with your message. To verify your message, the receiving party remembers the public key you sent out earlier. They use this to decrypt the hash, and then check this hash with one generated from hashing the message themselves. If they get a match, then they now know the two facts stated previously.

credits: Jerry Hildenbrand, Ivo
edited by arawn
Jul 21, 2012
T!v@K, comnam90 and Robbie Hood like this.