Boot Loaders

Bootloader-based acquisition is only available for devices with unlocked bootloaders (few) as well as devices for which a bootloader-level exploit is available (which includes many Qualcomm-based devices running Android and Windows Phone 8.x).

Developing a bootloader exploit is extremely time and labor consuming. Considering your current level of expertise with this matter, you may be better off by using a ready-made solution. The only forensic tool that I know of that is able to do bootloader-level acquisition is UFED.

One more thing. Kingo root is known to install quite a load of unwanted things onto the phone; there is no consensus on what exactly this tool does when rooting the phone in terms of transmitting information from the device onto its own servers (and it does transmit quite a lot, at least the desktop version does). Using Kingo app to root Android devices with the purpose of forensic acquisition is probably not the most sound idea. You may want to try one of the commercial tools (e.g. Oxygen Forensic Suite or UFED), or just read the Free Android Forensics guide at http//freeandroidforensics.blogspot.de/2014/08/introduction.html

Victor,

Thanks for the links.

(Disclosure I own several Elcomsoft products and use them regularly because they are excellent from my personal experience).

I also own licenses to

Cellebrite
Lantern
Mobiledit Forensic
Internet Evidence Finder
Andriller
iPhoneBackupExtractor

However, my question was specifically related to the concept of "Boot Loading".

A quick Google search turned up the following from Kingo's website

"What is Hboot/Bootloader?

Hboot, or we may call it Bootloader, is like BIOS to windows. It is the first thing that runs when you boot up your Android device. It packages the instructions to boot operating system kernel and most of them are specifically designed to run their own debugging or modification environment. Basically, Android device is like a hard drive that has several partitions, which holds the Android system file in one and all the app data in another. And for all these partitions, Bootloader (or Hboot) serves as a security checkpoint that is responsible for checking and initializing the hardware and starting software. It can also be used for flashing official software releases.

Lock & Unlock

Most bootloaders are locked, as well as encrypted, including the developer-friendly Nexus devices. Manufacturers usually lock the bootloader to make sure you stick to their Android OS version specifically designed for the device. With a locked bootloader, it is virtually impossible to flash a custom ROM and other forced attempts, which would void warranty as well as end up in bricks.

Nexus devices and a couple tablets can be easily unlocked with a single command. Others, however, couldn't be unlocked with just "fastboot oem unlock" command. HTC, as we know, has provided an official tool that will unlock the bootloaders on its devices. Other manufacturers have done or try to do the same thing.

Note Unlocking bootloader voids your warranty and also completely wipes out the internal memory including contacts, messages, applications, etc."

** So, I am curious to see what files are left from the "boot loading" process as I would simply like to be able to account for any such changes made by Kingo or Cellebrite or whomever.

I work on this sort of stuff at MSAB and will try to explain boot loaders, why they're used, how they're used and any artifacts left behind. I'll then try to answer specific questions in this thread.

The boot loader method usually involves a lengthy and expensive process due to the need for reverse engineering the platform in great detail in order to not rely on any manufacturer code. However this extensive reverse engineering means that we can provide a method which runs a known set of code. This allows us better control of what is actually happening.

Boot loaders are sometimes sent to the device using manufacturer built in functionality for debugging or testing the device. Similar to the protocol method it may require the user to know some secret sequence of key presses or to use a special cable. It's common for manufacturers to provide debug functionality which allows you to interrupt the boot sequence of the device and provide your own next stage boot loader. This is where the term boot loader comes from.

Sometimes the device does not have this functionality but there may be a security vulnerability in the code communicating with our products. This vulnerability may allow us to send send our own code to the device and have it executed. This is also referred to as a boot loader even though it's a bit of a misnomer and would correctly be referred to as an exploit payload. If the manufacturer has made an effort to secure the device and its data then there is almost always a need for a security vulnerability in order to bypass unlock code restrictions and get full read outs of non-volatile memory. To what extent manufacturers try to secure their device varies greatly.

Independently of whether the device is designed to accept our code or if we use a security vulnerability in order to deploy our code both methods result in a similar outcome; we can deploy code which is controlled by us and we can do a complete read out of all non-volatile memory of the device.

The amount of changes that happen to non-volatile memory will depend on two factors, the point at which we deploy our loader and the memory type. A typical device may boot in a sequence such as ROM, SBL1, SBL2, SBLn and finally kernel.
• ROM (Read Only Memory) is usually permanently programmed into the chip at the factory and is usually the first boot stage. Some people call the firmware image ROM but that's usually because the image is mounted read only by the operating system. There's nothing physically preventing writing to that memory.
• SBL (Secondary Boot Loader) is usually stored in non-volatile memory and is loaded and executed by the ROM when the ROM is finished. Naming of these loaders varies by manufacturer and stage. These loaders perform initialization of hardware. They usually bring up and test more and more complex hardware as the processor continues through the boot chain. Once SBL1 is done, it loads and passes control to SBL2, which upon completion of its duties, loads and passes control to the next stage loader. Eventually the kernel is loaded and executed.
• Kernel is usually the final stage in the boot chain and is the component responsible for managing the operating system the user sees and interacts with.
This means that if we deploy our code while communicating with the ROM, there is very likely no changes to the non-volatile memory at all. Deploying the code to one of the loaders in the SBL chain increases to odds of there being changes done to the non-volatile memory. When our code is deployed to the kernel there is almost always changes made to the non-volatile memory. So likelihood of changes to non-volatile memory is correlated to how late the device is in its boot chain when we deploy our code. Therefore we always try to deploy our code as early as possible in the boot chain.

The other factor which influences likelihood of changes to non-volatile memory is the memory type. Some memory types are managed memory. This means that the software on the device is not responsible for managing memory wear leveling. Wear leveling is the process used by the device in order to guarantee that the memory does not break, or wear out. A memory can wear out due to flash memory only being able to perform a certain number of erase cycles on a sector before it starts to read incorrectly.

If a memory chip is not managed it's the responsibility of the software on the device to ensure it does not erase regions of the chip too frequently and to manage blocks that have become bad. If a memory chip is managed it's the responsibility of the chip itself to ensure regions of the memory does not get erased too frequently and to manage regions that have become bad. A chip that is managed therefore contains logic which alters the state of the non-volatile memory independently of device software. This means that we can not control things such as garbage collection passes happening on the chip when it is powered on. Therefore data may change in the underlying non-volatile memory outside of our control. It also means that access to deleted data may be limited due to the underlying memory chip hiding erased data from view. Examples of managed memory types would be eMMC, SD and UFS. Examples of unmanaged memory types would be raw NOR and NAND. Most smartphones today, one exception being several models of iPhone, are equipped with managed memory such as eMMC. It's common for modern feature phones to have either SPI NOR or NAND to keep costs down.

It's also important to note that memory technologies that are managed often provide an idealized view of the underlying storage to the device software. It hides the messiness of wear leveling and allows the device software to pretend the memory is a simple linear sequence of blocks. This means that the memory chip does not expose all of its data to the device software or to our code.

When it comes to artifacts left behind by this sort of method there's generally very little. We almost always load our code into RAM, either SRAM or DRAM depending on the code we're communicating with on the device and depending on availability. We generally don't load an application onto permanent storage. There could be some exceptions to this case depending on where a security vulnerability lies if we're using one and at what stage we load our custom boot loaders. For instance some devices may make modifications to NVRAM when booted in flash, debug or engineering modes. I can't think of any example which uses this method that would leave anything permanent behind right now. If I did know of any artifacts I also couldn't enumerate them on an open forum such as this.

iOS Security Guide - September Version also has some details on the boot process that is useful to read.

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Pxtxr

Thanks for your detailed response!

Your statement below (as well as the rest of your post) was very helpful "We almost always load our code into RAM, either SRAM or DRAM depending on the code we're communicating with on the device and depending on availability. We generally don't load an application onto permanent storage"

This concept sounds like what my limited understanding of how Linux Live USB distributions work on workstations the Linux OS is all loaded to RAM and nothing is loaded to the workstation's internal hard drive. Live Linux USB distributions will work on computers with no internal hard drives whatsoever, but obviously once the computer is turned off, then all Linux data goes away (unless there was some virus installed to the workstation's BIOS memory storage chip.)

So "free" rooting applications such as Kingo DO appear to "load an application onto permanent storage" \SYSTEM (EFI 14)\app\KingoUser.apk.

I also appreciate your response can only be so detailed as I assume the knowledge of what exploits exist and how to exploit them represent a true trade secret; clearly there are many software companies constantly spending time and resources to identify exploits so that they can offer "free rooting" such as Kingo, or paid forensic applications such as XRY.

The "free" tools must be recouping their R&D costs by uploading and selling information to marketing companies from the devices that are rooted using their tools.

Thanks again!