Database Info

[Q] Boot Galaxy Tab 3 10.1 from USB

I create bootable USB flash drives based on Fedora Linux or UEFI that have special purpose applications on them. I am able to use these flash drives on Windows 8 tablets that have the capability to select USB as the boot device. Thus allowing the tablet to be booted from this USB flash drive.
I have a Samsung Tab 3 10.1, the device model is GT-P5210 with 4.2.2 OS. My thought is I could connect the micro USB to a USB hub that has one of my bootable flash drives plugged in and boot the tablet from the flash drive.
However, I have searched the forums and wiki for posts on this or related to it but I have not see any.
Can someone point to a post that addresses this?

metaylor said:
I create bootable USB flash drives based on Fedora Linux or UEFI that have special purpose applications on them. I am able to use these flash drives on Windows 8 tablets that have the capability to select USB as the boot device. Thus allowing the tablet to be booted from this USB flash drive.
I have a Samsung Tab 3 10.1, the device model is GT-P5210 with 4.2.2 OS. My thought is I could connect the micro USB to a USB hub that has one of my bootable flash drives plugged in and boot the tablet from the flash drive.
However, I have searched the forums and wiki for posts on this or related to it but I have not see any.
Can someone point to a post that addresses this?
Click to expand...
Click to collapse
The generic boot-loader (*which resides on the chip-set) has no knowledge of USB etc, as the lk (Little Kernel) is more concerned about trapping keystrokes in order to chain-load into recovery or to boot directly into Android environment (When holding Vol+Down key in this instance) - in pseudo-code (this is from the context/aspect of lk, and also, the memory addresses pertaining to how to read the partitions are hard-coded into this lk so it will know how to process the logic!)
The lk kernel is the de-facto standard by Qualcomm for MSM chipsets (Snapdragon) and adopted by manufacturers such as Sony, Motorola, LG, Samsung and can be found in the AOSP source under bootable/bootloader.
if (Is Volume Down key pressed?) then
chain-load kernel from /recovery partition into particular address in memory and jump to it and start execution, in bringing up the recovery environment
else
chain-load kernel from /system partition into particular address in memory and jump to it and start execution in bringing up the Android environment.
end if.
As the kernel within lk is pretty limited, considering that the binary image of the kernel is burned into the chip and therefore no way of modifying it. And also should be mentioned that lk contains the fastboot protocol in preparation for flashing /boot, /recovery, /system and /data partitions. There are two sequences to boot, primary boot and secondary boot as it is:
Primary Boot -> lk (depending on outcome of logic)
Go into Secondary Boot -> /boot or /recovery
Side note: Samsung is fond of the PBL/SBL (Which is Primary Boot Loader and Secondary Boot Loader respectively) in their jargon when it comes to modding. Thing about Samsung, is that, in some handsets, PBL and SBL may be encrypted (Samsung Wave GT-S8500 is one such example, where porting Android to it was nearly impossible to do because of the DRM within the boot loaders which was a nightmare to deal with and made modding it extremely difficult, nonetheless, it is sort of working via an exploit in the FOTA code!)
This is why there are no extra facilities such as OTG functionality or anything else such as serial communications, reading from SDCard, graphics etc as it would make the lk kernel bigger than is intended. In other words, it is the smallest possible size of kernel that is designated to do just the above pseudo-code happen.
Also, another way of looking at it is this, and this is dependent on the Android version - the USB OTG functionality is fully brought up within the Android environment, i.e when the familiar home screen appears, then OTG's functionality is enabled. Unfortunately not the case when looking at it from lk's perspective.
If you're curious, here's the Qualcomm entry on the above lk which is a part of the tiny C source that has ARM assembly included and found in JellyBean's AOSP source in bootable/bootloader/legacy/usbloader/main.c
Source

Does a phone's OS boot the phone or is it the boot loader?

I am currently taking a college class on Information Systems. In the class, the professor has asked the question
"Does the OS on a Smarphone boot the system? If it does, then why and how is it different from the PC Environment?"
Given the question, I automatically assumed that OS booted the phone. However, do to my time as an XDA member and my many attempts at flashing the boot loader to install custom ROMs, I think that this is not the case. Still, in a later post, he has revealed that the OS "on most new smartphones and tablets" does boot the System. Is he correct? I trust the members of XDA better than a college professor

I think bootloader
Sent from my Moto G using Tapatalk

Explain the boot process
I have searched the internet, textbooks, and people that I know, but cannot explain this. Can anyone explain the boot process? For instance, on my Galaxy S4? I really would like to understand the process better, and have a knowledgeable explanation for it. Any help would be beneficial. It is my understanding that the boot loader loads the kernel for the operating system, and then the operating system loads the remainder of the programs. This is exactly the same way that a computer boots. Correct??

SickPhone4X said:
I have searched the internet, textbooks, and people that I know, but cannot explain this. Can anyone explain the boot process? For instance, on my Galaxy S4? I really would like to understand the process better, and have a knowledgeable explanation for it. Any help would be beneficial. It is my understanding that the boot loader loads the kernel for the operating system, and then the operating system loads the remainder of the programs. This is exactly the same way that a computer boots. Correct??
Click to expand...
Click to collapse
That is correct to my knowledge, yes. I suppose you could say they all work together to boot the device, though. A smartphone or tablet is just a small computer. It has to go through the same process of booting as every other computer does.
Another note as well: I believe that the operating system includes both the kernel and core programs. The kernel isn't separate, but a part of it. As an example, Linux is the kernel, GNU provides the core programs, and GNU/Linux is the OS.

SickPhone4X said:
I have searched the internet, textbooks, and people that I know, but cannot explain this. Can anyone explain the boot process? For instance, on my Galaxy S4? I really would like to understand the process better, and have a knowledgeable explanation for it. Any help would be beneficial. It is my understanding that the boot loader loads the kernel for the operating system, and then the operating system loads the remainder of the programs. This is exactly the same way that a computer boots. Correct??
Click to expand...
Click to collapse
1. Power on and boot ROM code execution
At power on the CPU will be in a state where no initializations have been done. Internal clocks are not set up and the only memory available is the internal RAM. When power supplies are stable the execution will start with the Boot ROM code. This is a small piece of code that is hardwired in the CPU ASIC.
A. The Boot ROM code will detect the boot media using a system register that maps to some physical balls on the asic. This is to determine where to find the first stage of the boot loader.
B. Once the boot media sequence is established the boot ROM will try to load the first stage boot loader to internal RAM. Once the boot loader is in place the boot ROM code will perform a jump and execution continues in the boot loader.
2. The boot loader
The boot loader is a special program separate from the Linux kernel that is used to set up initial memories and load the kernel to RAM. On desktop systems the boot loaders are programs like GRUB and in embedded Linux uBoot is often the boot loader of choice. Device manufacturers often use their own proprietary boot loaders. The requirements on a boot loader for Linux running on an ARM system can be found in the Booting document under /Documentation/arm in the kernel source tree.
A. The first boot loader stage will detect and set up external RAM.
B. Once external RAM is available and the system is ready the to run something more significant the first stage will load the main boot loader and place it in external RAM.
C. The second stage of the boot loader is the first major program that will run. This may contain code to set up file systems, additional memory, network support and other things. On a mobile phone it may also be responsible for loading code for the modem CPU and setting up low level memory protections and security options.
D. Once the boot loader is done with any special tasks it will look for a Linux kernel to boot. It will load this from the boot media (or some other source depending on system configuration) and place it in the RAM. It will also place some boot parameters in memory for the kernel to read when it starts up.
E. Once the boot loader is done it will perform a jump to the Linux kernel, usually some decompression routine, and the kernel assumes system responsibility.
3. The Linux kernel
The Linux kernel starts up in a similar way on Android as on other systems. It will set up everything that is needed for the system to run. Initialize interrupt controllers, set up memory protections, caches and scheduling.
A. Once the memory management units and caches have been initialized the system will be able to use virtual memory and launch user space processes.
B. The kernel will look in the root file system for the init process (found under system/core/init in the Android open source tree) and launch it as the initial user space process.
4. The init process
The init process is the "grandmother" of all system processes. Every other process in the system will be launched from this process or one of its descendants.
A. The init process in Android will look for a file called init.rc. This is a script that describes the system services, file system and other parameters that need to be set up. The init.rc script is placed in system/core/rootdir in the Android open source project.
B. The init process will parse the init script and launch the system service processes.
5. Zygote and Dalvik
The Zygote is launched by the init process and will basically just start executing and and initialize the Dalvik VM.
6. The system server
The system server is the first java component to run in the system. It will start all the Android services such as telephony manager and bluetooth. Start up of each service is currently written directly into the run method of the system server. The system server source can be found in the file frameworks/base/services/java/com/android/server/SystemServer.java in the open source project.
7. Boot completed
Once the System Server is up and running and the system boot has completed there is a standard broadcast action called ACTION_BOOT_COMPLETED. To start your own service, register an alarm or otherwise make your application perform some action after boot you should register to receive this broadcast intent.

AFAIK, in a partition table, he boot partition contains the kernel and the ramdisk. This partition enables the phone to boot. On the other hand, the OS is loaded into the system partition. So its safe to say the OS does not boot the phone .

Thanks Fantassy123!
I appreciate your thorough explanation of the process. This is exactly the insight that I needed. So, basically the kernel is the beginning of the OS and the boot ROM MUST run prior to the OS? Is anyone aware of any "new" phones that do not require a boot ROM? For instance, where the kernel acts as the boot loader or is the first process to run?
Fantassy123 said:
1. Power on and boot ROM code execution
At power on the CPU will be in a state where no initializations have been done. Internal clocks are not set up and the only memory available is the internal RAM. When power supplies are stable the execution will start with the Boot ROM code. This is a small piece of code that is hardwired in the CPU ASIC.
A. The Boot ROM code will detect the boot media using a system register that maps to some physical balls on the asic. This is to determine where to find the first stage of the boot loader.
B. Once the boot media sequence is established the boot ROM will try to load the first stage boot loader to internal RAM. Once the boot loader is in place the boot ROM code will perform a jump and execution continues in the boot loader.
2. The boot loader
The boot loader is a special program separate from the Linux kernel that is used to set up initial memories and load the kernel to RAM. On desktop systems the boot loaders are programs like GRUB and in embedded Linux uBoot is often the boot loader of choice. Device manufacturers often use their own proprietary boot loaders. The requirements on a boot loader for Linux running on an ARM system can be found in the Booting document under /Documentation/arm in the kernel source tree.
A. The first boot loader stage will detect and set up external RAM.
B. Once external RAM is available and the system is ready the to run something more significant the first stage will load the main boot loader and place it in external RAM.
C. The second stage of the boot loader is the first major program that will run. This may contain code to set up file systems, additional memory, network support and other things. On a mobile phone it may also be responsible for loading code for the modem CPU and setting up low level memory protections and security options.
D. Once the boot loader is done with any special tasks it will look for a Linux kernel to boot. It will load this from the boot media (or some other source depending on system configuration) and place it in the RAM. It will also place some boot parameters in memory for the kernel to read when it starts up.
E. Once the boot loader is done it will perform a jump to the Linux kernel, usually some decompression routine, and the kernel assumes system responsibility.
3. The Linux kernel
The Linux kernel starts up in a similar way on Android as on other systems. It will set up everything that is needed for the system to run. Initialize interrupt controllers, set up memory protections, caches and scheduling.
A. Once the memory management units and caches have been initialized the system will be able to use virtual memory and launch user space processes.
B. The kernel will look in the root file system for the init process (found under system/core/init in the Android open source tree) and launch it as the initial user space process.
4. The init process
The init process is the "grandmother" of all system processes. Every other process in the system will be launched from this process or one of its descendants.
A. The init process in Android will look for a file called init.rc. This is a script that describes the system services, file system and other parameters that need to be set up. The init.rc script is placed in system/core/rootdir in the Android open source project.
B. The init process will parse the init script and launch the system service processes.
5. Zygote and Dalvik
The Zygote is launched by the init process and will basically just start executing and and initialize the Dalvik VM.
6. The system server
The system server is the first java component to run in the system. It will start all the Android services such as telephony manager and bluetooth. Start up of each service is currently written directly into the run method of the system server. The system server source can be found in the file frameworks/base/services/java/com/android/server/SystemServer.java in the open source project.
7. Boot completed
Once the System Server is up and running and the system boot has completed there is a standard broadcast action called ACTION_BOOT_COMPLETED. To start your own service, register an alarm or otherwise make your application perform some action after boot you should register to receive this broadcast intent.
Click to expand...
Click to collapse

Verified boot and Full Disk Encryption: Testings, explanations, consequences

Hello,
I've tested the full verified boot stack of Nexus 5X, to better understand the various implications, especially for my SuperUser project ( http://forum.xda-developers.com/android/software-hacking/wip-selinux-capable-superuser-t3216394/ ).
First of all, I'd like to say that they took time, but with this bootloader, Google did a really nice piece of security, without excluding alternate ROMs. (No doubt they got their inspiration from Chrome project, which are(were?) ahead on the matter).
This means that we can have alternate ROMs, even possibly roots, without compromising our devices! (of course assuming root/ROMs do their part of the job)
Everything is explained in https://source.android.com/security/verifiedboot/verified-boot.html and https://source.android.com/security/encryption/index.html
For users who haven't got their hand on a Nexus 5X/6P yet, here are the various screens you might see on boot when booting a non official ROM: https://source.android.com/security/verifiedboot/verified-boot.html#user_experience
The bootloader has two states: locked or unlocked, nothing new here. locked won't let you flash, unlocked will.
But then, there are 4 boot state that can be shown (or not to the user):
- Green boot state: the device is locked and running Google's ROM. It's the only boot state which is not displayed by bootloader
- Orange boot state: the device is unlocked.
- Yellow boot state: the device is locked, running an alternate ROM
- Red state: This shouldn't happen, it means the boot.img has been badly signed. Could mean an attack is undergoing.
Yellow state has two different possible screens depending on if the boot.img is signed. The difference is, if it is signed, an ID is displayed: this is the fingerprint of the public key used to signed the boot.img.
This means that we, the users, have a way to always be sure we booted the boot.img made by the ROM developer.
The same way we know we are on a Google ROM when there is no warning screen, we know that we are indeed on the ROM we are expecting.
But wait, there is more! The bootloader gives to the TEE/Trustzone the public key of the boot.img, and the TEE/Trustzone changes its answers based on the public key.
The TEE/Trustzone answers are used to generate the key of the /data encryption.
This means that in locked mode, with a signed boot.img, a trusted keystore-owner (doesn't have to be Google), full disk encryption enabled, and dm-verity enabled, even if an attacker is capable of overwriting any part of eMMC through either a privilege escalation, or physical attempt, trying to phish you to prompt your password, then the attacker won't get access to your data!
The TL;DR is, it is now possible to be as secure as original Google's ROM with a custom ROM (you still have to trust Google though) thanks to verified boot features.
Here are my advices to fully benefit from this feature:
- KEEP Full Disk Encryption (forceencrypt)
- KEEP keystore/keymaster/qseecomd
- Lock bootloader back
- Use custom security keys, including verity key, and keep them safe.
- Sign boot.img (this is default AOSP behaviour I think)
- Use a different security key for recovery (so recovery won't ever access to your userdata)
- Untick "OEM unlocking" if you feel safe about your ROM, to have Factory Reset Protection working (ie anti-theft feature)
For unknown quality ROMs:
- When first booting a new ROM/security key, try to memorize the fingerprint. If you don't memorize it all, try to memorize characters are random position, not the beginning.
- When the device asks for you deciphering password, check you booted the proper fingerprint. Do that especially if you have unexpected reboots.
Even though I consider this is a really great step forward to having secure alternate ROMs, there are some downsides:
- There is no "verified" mode where you can flash anything, but it does apply the security policy. This makes TWRP/Flashfire/CWM/a proper OTA system needed to be able to flash again without erasing all data
- The fingerprint is 6bytes/48bits, this is by far lower than most security standards. Also, some algorithms make ascii-art from fingerprints to help user recognize matching fingerprint.
- Changing ROM is complicated: you either need to resign all ROMs with your own key, to factory reset or "transmit" in clear the cipher key
Despite the the downsides, I hope to convince some ROM devs, and users to go to lock mode and check they implemented my various advices.
Please note that this security works only on Nexus 5X/6P, it doesn't work on N6 or N9.

Next step is to add ability for the end user to create a chain of trust in bootloader area.
User must have the way to blow it's own public key to the SoC Qfuses/Qfprom and to sign a chain of bootloaders and activate a Secure Boot after that.
---
Sony Xperia A2 SO-04F (Japan version of Z1 Compact)

Did someone check the second public key emplacement in Qfuses is locked?

New piece of information about this feature, this should become widespread amongst devices.
The Android comformity document for Android M ( https://static.googleusercontent.co...com/fr//compatibility/6.0/android-6.0-cdd.pdf section 9.10) states that verified boot is mandatory.
It is/was unclear whether this document refers to https://source.android.com/security/verifiedboot/verified-boot.html, or just requires any verified boot.
But a commit in Qualcomm's bootloader gives some signs:
https://www.codeaurora.org/cgit/qui...3&id=3b6a87e4556587b3cc0c652ada680b7284d2fae7
"platform: msm_shared: update for bootloader's requirements."
It could be some overthinking, but anyway this means that all Android M-native devices will have this feature (OR be fully locked, this is allowed as well :/)
This is IMO a really great news as this means we will be able to have secure ROMs on all devices!

How could you have a secure custom ROM if you don't have ability to blow your own key (with wich partition's hashes is signed) to a SoC Qfuses/Qfprom?
---
Sony Xperia A2 SO-04F (Japan version of Z1 Compact)

I said it in my post. The encryption of /data is computed by the TZ and based on the public key of boot.img
I even think FRP is kept, though I don't really want to play with that

phhusson said:
Hello,
I've tested the full verified boot stack of Nexus 5X, to better understand the various implications, especially for my SuperUser project on N6 or N9.
Click to expand...
Click to collapse
Thanks for this.
Just a few questions (with respect to the nexus 6P):
1. Do you upload a custom keystore via "fastboot flash keystore" (nexus 6P)?
2. Will changing the key store as per (1) affect the OEM keystore (i.e. is that separate)?
3. Would you mind sharing how you made your own keystore?
- edit: found your repo https://github.com/phhusson/super-bootimg/tree/master/scripts
4. After you relock the bootloader, how are you supposed to flash a custom recovery given that there is no verified mode? My undestanding is that the stock recovery has to be in place before locking the bootloader (for data wipe to occur). Or does the locked state also use the custom keystore?
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.

ceribik said:
1. Do you upload a custom keystore via "fastboot flash keystore" (nexus 6P)?
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
Click to expand...
Click to collapse
Although the keystore partition is flashable, it is useless.
The only thing checked is the public key with which is signed the boot.img
Thus the only red state possible is because of dm-verity.
The anti-signature change is provided by the fact that data are encrypted with a key based on the public key of the boot.img
2. Will changing the key store as per (1) affect the OEM keystore (i.e. is that separate)?
Click to expand...
Click to collapse
Nope. Even in CAF implementation which handles keystore, the state is different between OEM keystore and user keystore.
(Yellow in user keystore, green in oem keystore)
3. Would you mind sharing how you made your own keystore?
- edit: found your repo https://github.com/phhusson/super-bootimg/tree/master/scripts
Click to expand...
Click to collapse
Though it is mostly useless. The only use is for CAF devices, with verified mode.
4. After you relock the bootloader, how are you supposed to flash a custom recovery given that there is no verified mode? My undestanding is that the stock recovery has to be in place before locking the bootloader (for data wipe to occur). Or does the locked state also use the custom keystore?
Click to expand...
Click to collapse
I haven't checked that part yet, but I don't think you need original recovery.
But yes, the no-reflashing annoys me a lot, it means a custom ROM MUST provide an OTA system.
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
Click to expand...
Click to collapse
As mentioned earlier, I'm only aware of dm-verity-based red state, which can indeed be bypassed.
I hope this answers your questions, don't hesitate to ask for more

Dude I really wanna pick your brain on this. It's sad I arrive late to these parties Anyways I have a Pixel and believe this is more relevant than ever now because verified boot is strictly enforced. I want to have a modified phone with custom ROM & locked bootloader but after flashing super TWRP/SU/EX to kernel I'm positive it breaks signing.
So my question is how can I re-sign the kernel after it had been modified by SuperSU/TWRP/EX Kernel etc? I would like to flash my own keystore.img and sign the boot.img so my phone will boot with yellow warning. Can it only be done with a full build environment at compile time or can I grab some tools, generate the keystore & sign an image that pull with dd? This is something that is very new to me & there is really no step-by-step for this that I've found.
Please forgive me for my lack of knowledge on this subject but I am desperate to have a modified kernel /system and the ability to re-lock my boatloader. I can live without the dm-verity since I have a tendency to modify system files on a regular basis anyways. I sent you a PM cause I had lost this page. If I can figure out a step by-syep process to do this that didn't require a whole build env I can probably script a tool once I know necessary commands and tools.
So far I've generated my keystore keys
1.
Code:
/make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
now I am trying to figure out the keystore image.
2.
Code:
java -Xmx512M -jar BootKeystoreSigner.jar keystore.pk8 keystore.x509.pem keystore.img

Geofferey said:
Dude I really wanna pick your brain on this. It's sad I arrive late to these parties Anyways I have a Pixel and believe this is more relevant than ever now because verified boot is strictly enforced. I want to have a modified phone with custom ROM & locked bootloader but after flashing super TWRP/SU/EX to kernel I'm positive it breaks signing.
So my question is how can I re-sign the kernel after it had been modified by SuperSU/TWRP/EX Kernel etc? I would like to flash my own keystore.img and sign the boot.img so my phone will boot with yellow warning. Can it only be done with a full build environment at compile time or can I grab some tools, generate the keystore & sign an image that pull with dd? This is something that is very new to me & there is really no step-by-step for this that I've found.
Please forgive me for my lack of knowledge on this subject but I am desperate to have a modified kernel /system and the ability to re-lock my boatloader. I can live without the dm-verity since I have a tendency to modify system files on a regular basis anyways. I sent you a PM cause I had lost this page. If I can figure out a step by-syep process to do this that didn't require a whole build env I can probably script a tool once I know necessary commands and tools.
So far I've generated my keystore keys
1.
Code:
/make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
now I am trying to figure out the keystore image.
2.
Code:
java -Xmx512M -jar BootKeystoreSigner.jar keystore.pk8 keystore.x509.pem keystore.img
Click to expand...
Click to collapse
Off the top of my head, you have to add the public signing keys to the root directory of the ramdisk in the boot.img, and then sign the boot.img with the private keys.
I think the image is signed with the verity keys, and the public key has a special form for nougat/7.1/14.1, with some rounding. I think marshmallow was different. From the android build environment, you can use "make generate_verity_key". The actual source is here system/extras/verity if you just want to compile the pieces parts.. The script will be in the out/host directory if you use the make command. Use the convert option "generate_verity_key -convert <path-to-x509-pem> <path-to-key>" to convert the keystore.x509.pem cert that you made. This script will generate the public key in the just the right form that android is looking for. This is what goes into the root of the ramdisk. I think it has to be named verity_key. Yes, I know you aren't turning on dm-verity for the system image, but the boot is signed with the same key.
There is probably a script in one of the aosp repos that will make and sign the boot image. You want to find that and figure out what it is doing.
The finger print will be the first 6 words from the sha1 fingerprint:
Code:
openssl x509 -noout -in keystore.x509.pem -fingerprint -sha1
Hope that helps.
Edit: In the system/extra/verity dir, there is a boot_signer script that references a bootsignature.jar that might do what you are looking for. You'll probably have to build it since it will be in the out/host/ directory somewhere. or just hotwire the java yourself.

Off the top of my head, you have to add the public signing keys to the root directory of the ramdisk in the boot.img, and then sign the boot.img with the private keys.
I think the image is signed with the verity keys, and the public key has a special form for nougat/7.1/14.1, with some rounding. I think marshmallow was different.
There is probably a script in one of the aosp repos that will make and sign the boot image. You want to find that and figure out what it is doing.
The finger print will be the first 6 words from the sha1 fingerprint:
Hope that helps.
Click to expand...
Click to collapse
I'm slowly starting to figure this out, but I have one problem. On the Pixel there is no keystore partition so I can't flash my keystore.img. Do I need to flash a keystore for my signed images to boot? If not I will continue and sign but it was my understanding that I would need that. I suppose I should also grab the verity tools from a 7.0 tree instead of phhussons repo?

Geofferey said:
I'm slowly starting to figure this out, but I have one problem. On the Pixel there is no keystore partition so I can't flash my keystore.img. Do I need to flash a keystore for my signed images to boot? If not I will continue and sign but it was my understanding that I would need that. I suppose I should also grab the verity tools from a 7.0 tree instead of phhussons repo?
Click to expand...
Click to collapse
The pixel night be different, but I think the signature is appended to the boot.img. i don't think you need the keystore partition? I could be wrong. The fingerprint lets you know that it wasn't re-signed by a different key.
I think you want to use a nougat branch for sure.

Pixel Locked Bootloader Custom ROM / Kernel
Okay so I got this whole thing figured out. Just had to read stuff all over the place. Everything we need is in phhussons repo under the keystore_tools and the 6.0 CAF tree will suffice. I knew I was close.
BTW: I only recommend this for flawless ROMs with no major issues. Once re-locked DO NOT disable Allow OEM Unlock in the developer options menu unless you are 100% sure your phone will boot especially after /data wipes etc. Do not make modifications of any kind in a locked state with OEM unlock off. I learned the hard way with a 5X when I tried to dd a vendor.img via adb on a locked bootloader without TWRP. Don't do anything crazy! You have been warned!
Here is how you can re-sign after mods beofore re-locking a Pixel.
Grab boot images from android (needs root or twrp):
I actually used Android Terminal Emulator for this step
Code:
sailfish:/ # cd /dev/block/platform/soc/624000.ufshc/by-name
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_a of=/sdcard/boot_a.img
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_b of=/sdcard/boot_b.img
Generate Keystore:
Code:
./make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
openssl rsa -in keystore.pk8 -inform der -outform der -pubout -out keystore.pub.pk8
Sign the boot Images:
Code:
java -jar BootSignature.jar /boot boot_a..img keystore.pk8 keystore.x509.pem boot_a_signed.img
java -jar BootSignature.jar /boot boot_b..img keystore.pk8 keystore.x509.pem boot_b_signed.img
Reflash with fastboot:
Code:
fastboot flash boot_a boot_a_signed.img
fastboot flash boot_b boot_b_signed.img
Relock the bootloader (will erase device)
Code:
fastboot oem lock
One thing I have noticed is the fingerprint isn't displayed on boot, yet still starts up fine. Maybe it's because I didn't place the .pub key in ramdisk before signing? It could also be due to the use of CAF & not AOSP tools. In any case I got the pixel to boot yellow in a locked state after modifying the kernel.

I'm a newbie compared to you guys and I had problems running Java. I've unpacked the boot image and repacked it after modifications. I have also generated keys and I'm wondering if there is a script (Python?) that I can run to sign the boot image? Also, where should I copy the public key inside the ramdisk? This is for a 7.0.1 Nougat boot image of OnePlus 3. Thanks,

Unfortunately there is no other method that I have found to sign boot images with besides the BootSignature.jar in phhusson's repo. You could also setup a build environment but the method I described is magnitudes simpler. Both methods require java there is no python script to perform this. You put the .pub key at root of RAM disk renamed as verity_key. I think that's only required if you are using dm-verity and a generated tree for your system image.
What OS are you running? I did my signing in Ubuntu.

Was this tested on OnePlus 5 by anyone before?

Geofferey said:
Okay so I got this whole thing figured out. Just had to read stuff all over the place. Everything we need is in phhussons repo under the keystore_tools and the 6.0 CAF tree will suffice. I knew I was close.
BTW: I only recommend this for flawless ROMs with no major issues. Once re-locked DO NOT disable Allow OEM Unlock in the developer options menu unless you are 100% sure your phone will boot especially after /data wipes etc. Do not make modifications of any kind in a locked state with OEM unlock off. I learned the hard way with a 5X when I tried to dd a vendor.img via adb on a locked bootloader without TWRP. Don't do anything crazy! You have been warned!
Here is how you can re-sign after mods beofore re-locking a Pixel.
Grab boot images from android (needs root or twrp):
I actually used Android Terminal Emulator for this step
Code:
sailfish:/ # cd /dev/block/platform/soc/624000.ufshc/by-name
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_a of=/sdcard/boot_a.img
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_b of=/sdcard/boot_b.img
Generate Keystore:
Code:
./make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
openssl rsa -in keystore.pk8 -inform der -outform der -pubout -out keystore.pub.pk8
Sign the boot Images:
Code:
java -jar BootSignature.jar /boot boot_a..img keystore.pk8 keystore.x509.pem boot_a_signed.img
java -jar BootSignature.jar /boot boot_b..img keystore.pk8 keystore.x509.pem boot_b_signed.img
Reflash with fastboot:
Code:
fastboot flash boot_a boot_a_signed.img
fastboot flash boot_b boot_b_signed.img
Relock the bootloader (will erase device)
Code:
fastboot oem lock
One thing I have noticed is the fingerprint isn't displayed on boot, yet still starts up fine. Maybe it's because I didn't place the .pub key in ramdisk before signing? It could also be due to the use of CAF & not AOSP tools. In any case I got the pixel to boot yellow in a locked state after modifying the kernel.
Click to expand...
Click to collapse
Signing the boot image.
What does it actually do? From the semantics, it looks like it is signing the boot image with the generated private key.
How does the bootloader in the device know to trust the images(like recovery, system or roms) signed with this private key?

praveenkv1988 said:
Signing the boot image.
What does it actually do? From the semantics, it looks like it is signing the boot image with the generated private key.
How does the bootloader in the device know to trust the images(like recovery, system or roms) signed with this private key?
Click to expand...
Click to collapse
See the class B implementation of verified boot.
https://source.android.com/security/verifiedboot/verified-boot
The boot is signed with the key and it is verified against the included certificate. Yes, someone else could just sign the boot image with their key, but you can verify the fingerprint when the device boots to make sure it was signed with the correct key. This makes it tamper evident, not tamper proof.
The rom itself should use dm-verity to check the integrity at the block level. The boot image, which is signed, has the dm-verity public key so that the rom can be verified. Similar verification process can apply to recovery if it is signed and has dm-verity. Most don't, but it is certainly possible to do.

Since lineageos builds are signed by their private key, Can we just lock the bootloader after installing lineageos? Will it boot in yellow state?

praveenkv1988 said:
Since lineageos builds are signed by their private key, Can we just lock the bootloader after installing lineageos? Will it boot in yellow state?
Click to expand...
Click to collapse
On 14.1- the locked bootloader will show the yellow state and the LOS key fingerprint. But, if you don't lock down the recovery, there's little point in locking the bootloader. It also seems risky to lock the bootloader with a rom that is signed with a private key that you don't control. Depending on the phone, you night not be able to decrypt data in recovery (think backups).
On 15.1, I think things are more complex and this or related parts in LOS might not be working yet.
My bootloader is locked and I was trying to upgrade my n5x to 15.1 yesterday and all I got were bootloops. I reverted to 14.1 and recovered, but there are no guarantees.
Lastly, the way you asked the question makes me think you shouldn't lock you bootloader. Not trying to be mean or rude, but I am trying to prevent you from losing your data or being locked out of your phone. The hard part about locking the bootloader is that you can't use fastboot to flash things like radios, vendor images, etc.

[PX5][Android 10] Patched recovery

This is the Android 10 recovery image by HCT (version 10.3.1) patched to skip signature checking on .zip files
Tested on MTCE_LM (Eunavi). Use at your own risk
It can be flashed from a root shell (either adb or via terminal emulator) by performing the following steps
1. upload recovery via adb
Code:
adb push hct_recovery_patched.img /sdcard/
2. flash recovery
Code:
# backup current recovery
dd if=/dev/block/by-name/recovery of=/sdcard/recovery_backup.img
# write new recovery
dd if=/sdcard/hct_recovery_patched.img of=/dev/block/by-name/recovery
NOTE: If you do not disable the "flash_recovery" service in /init.rc, AND you have a stock kernel, recovery will be restored to the original version after rebooting.
There are 3 ways to avoid this:
- Flash magisk (or a modified kernel) while in recovery. The patch will then fail to apply and recovery won't be overwritten
- Disable "flash_recovery" by doing "adb remount" and editing /init.rc (comment out the following)
Code:
service flash_recovery /system/bin/install-recovery.sh
class main
oneshot
- Neuter the service by either:
- removing /system/bin/install-recovery.sh​- replacing /system/bin/install-recovery.sh with a dummy script​- removing /system/recovery-from-boot.p​

Woo-hoo, after hundreds of rubbish posts in the MTCD forums, we have a real development post!
Great work and thanks for sharing this, these forums need more like you.

Thanks for the kind comment!
I have to admit that it was frustrating to see the lack of information sharing on this forum, and the pervasive pay-per-use model.
I spent a lot of time just getting Android 10 installed (starting from Android 9), and i had to bring the head unit to my desk as working in the car was rather hard and all i achieved was a brick.
I unfortunately had to bring it back in the car now (can't sit on my desk forever) but, now that i figured out how to make bootable recoveries, i was wondering how hard it could be to have TWRP or at least a hassle-free recovery to install Android 10 from Android 9.
As a first step, this recovery makes it possible to install Magisk or other zip files without doing it manually within adb.
Cheers!

Your work is really good!
Thanks a lot for it.
Now you can also modify ROM's without signatur errors when installing.
Wouldn't it be good if we had an app like the ModInstaller ?
So a one click installation of the recovery without shell or adb.

I have now built an app.
And now need help.
Namely, in the app is the recovery and the script.
Unfortunately, the flash process is not started.
It always comes only the first message from the script.
The app is open source and the script and the recovery are in res/raw.
In the attach you will find the finished app and pictures.
If someone has a solution, he can write me or make a pull request on Github.
Source code:
GitHub - jamal2362/RK33XX-Custom-Recovery-Installer: Application for flashing custom recovery on Rockchip Android Head-Units.
Application for flashing custom recovery on Rockchip Android Head-Units. - GitHub - jamal2362/RK33XX-Custom-Recovery-Installer: Application for flashing custom recovery on Rockchip Android Head-Units.
github.com
The script:
RK33XX-Custom-Recovery-Installer/script at master · jamal2362/RK33XX-Custom-Recovery-Installer
Application for flashing custom recovery on Rockchip Android Head-Units. - RK33XX-Custom-Recovery-Installer/script at master · jamal2362/RK33XX-Custom-Recovery-Installer
github.com

First of all, congrats for the work!
DISCLAIMER:
I don't own ModInstaller, i have never bought a copy of it and i don't intend to do so.
Analysis is purely done from Youtube videos, open source code analysis and existing and openly available binary images.
I was working to figure out how to make a FLOSS alternative to ModInstaller.
The issues i found in all my attempts are the following:
- A6 recovery is the only one that can boot from SD Card (which can then be used to flash A9 -> A10 with the 2SD trick)
- (it took me a long time to pull these information together and unbrick my unit)​- The A6 recovery is unable to directly flash A10 RKAF/RKFW images (sdupdate.img) due to the code being too old
- a failure will be observed while writing super.img. This happens because the device needs to be repartitioned, and the A6 recovery is not doing it correctly​- A9 recovery is buggy. Booting it with no system installed will result in a black screen.
- it will only boot succesfully after being written by the A6 flash tool, which writes the "misc" partition with the recovery commands to run (the "hint" i get from this is that the misc partition is important)​- A10 recovery can't be loaded by the A6 recovery. I always got a black screen after flash. Is it a flash issue? is it an issue with the recovery itself? hard to know
Theory: maybe the recovery could be written over the kernel partition? ("boot")
This way, the recovery will always run after being flashed instead of requiring an explicit "enter recovery" trigger (buttons, misc partition, etc.)
Besides these experiments, in parallel, i did some bug fixing to this repository: https://github.com/liftoff-sr/rockchip-tool/commits/master (i'm "smx-smx")
That allows me to unpack nad repack "sdupdate.img" , "reduced recovery images" and "full IMG files".
With those tools. i tried to swap "recovery.img" in the A6 image, but i always got the black screen upon booting from SD.
Either A9/A10 breaks sdboot or the bootloader crashes before it gets there.
Since this also happens when being flashed, this could either be a bug in the flashing program or a bug in the boot stack (which fails to run recovery perhaps due to a dirty state of the internal flash). It's hard to know for sure without having a UART connection with the board.
BUT, we have an alternative, in the form of the recovery built-in ISP flash tool.
This is the code that reads "sdupdate.img" from the SD Card and flashes it
After reading the recovery source code, i realised that this code can only be triggered correctly when booting from the SD card.
It detects this state by reading /proc/cmdline and probing for specific values (https://github.com/rockchip-android...6f72b7d3123dab27135ac41d55029/sdboot.cpp#L206)
This means the bootloader can (and will) pass those arguments under specific conditions (https://github.com/rockchip-linux/u...c873f178c/arch/arm/mach-rockchip/board.c#L358)
If you check here https://github.com/rockchip-linux/u...3f178c/arch/arm/mach-rockchip/boot_mode.c#L47 you can see the magic word that needs to be written to the "misc" partition in order to trigger that code.
Note that, besides the well known "sdboot", "usbboot" is also possible.
I'm not sure if the ROM can physically boot from USB, but the bootloader and recovery do support (according to code) passing the flag to enable flashing from USB.
So, recapping, there are these ways we can try:
a - try to overwrite "boot" with "recovery" (but it might not work due to the partitioning layout, e.g. jumping from A6 -> A10)
- note: uboot might also need to be written when doing this.
b - making a modified "sdupdate.img" that flashes recovery on top of boot, and all the other core partitions like "misc", "uboot", "trust", "vbmeta"
c - writing "misc" from android in order to triggers the "rkfwupdate" mode
d - taking a dump of the first portion of the flash in various states (A6, A8, A9, A10), and having a "dd" that writes it back to the beginning of the flash (i suspect this is how ModInstaller does it)
Considering cases "b" and "c" depend on a recovery that can write them correctly (and the A6 one is buggy), this leaves us with "a" and "d"
Considering that ModInstaller does it in one shot, and doesn't seem to matter about the partitioning layout, i believe "d" might be the most viable option...
Using the "rockchip-tool" repository i linked from github, the partition table can be dumped from any .img file
You can observe "Image/parameter.txt" from the extracted firmware
This is the partition table from A6's recovery:
[email protected](uboot)
[email protected](trust)
[email protected](misc)
[email protected](resource)
[email protected](kernel)
[email protected](dtb)
[email protected](dtbo)
[email protected](vbmeta)
[email protected](boot)
[email protected](recovery)
[email protected](backup)
[email protected](security)
[email protected](cache)
[email protected](system)
[email protected](metadata)
[email protected](vendor)
[email protected](oem)
[email protected](frp)
[email protected](userdata)
And this is the partition table from A9's recovery
[email protected](uboot)
[email protected](trust)
[email protected](misc)
[email protected](resource)
[email protected](kernel)
[email protected](dtb)
[email protected](dtbo)
[email protected](vbmeta)
[email protected](boot)
[email protected](recovery)
[email protected](backup)
[email protected](security)
[email protected](cache)
[email protected](system)
[email protected](metadata)
[email protected](vendor)
[email protected](oem)
[email protected](frp)
[email protected](userdata)
Notice how uboot, trust, misc, resource, kernel, dtb, and others live in the same space. (2000, 4000, 6000, 8000, 10000, ...)
What we could do is create a raw blob that spans that address range, and "dd" it directly to /dev/mmcblk0 at the right offset.
So i would focus on converting recovery images to raw blobs, with recovery-as-kernel so it boots straight away on the first try.

Bump a real thread.

Is it possible to convert it to a file installed by SDDiskTool?

marchnz said:
Bump a real thread.
Click to expand...
Click to collapse
I created a flashing tool to flash recovery within Android, using Rockchip's own code: https://forum.xda-developers.com/t/...chip-firmware-flash-tool-for-android.4458299/

blala said:
I created a flashing tool to flash recovery within Android, using Rockchip's own code: https://forum.xda-developers.com/t/...chip-firmware-flash-tool-for-android.4458299/
Click to expand...
Click to collapse
This file hct_recovery.patched.img does not appear to be installed via rkupdate

sadaghiani said:
Is it possible to convert it to a file installed by SDDiskTool?
Click to expand...
Click to collapse
It needs to be converted, yes
I'll take a look this afternoon

blala said:
It needs to be converted, yes
I'll take a look this afternoon
Click to expand...
Click to collapse
Is it possible to create a boot image that includes moded recovery & magisk and moded kernel ?

If by image you mean firmware image then yes, it can be done with https://github.com/liftoff-sr/rockchip-tool
But what i would recommend is the modded recovery only, with the magisk .zip to use in Recovery
Otherwise you risk flashing a kernel that doesn't match with kernel modules or is otherwise not fully compatible with the installed system

blala said:
If by image you mean firmware image then yes, it can be done with https://github.com/liftoff-sr/rockchip-tool
But what i would recommend is the modded recovery only, with the magisk .zip to use in Recovery
Otherwise you risk flashing a kernel that doesn't match with kernel modules or is otherwise not fully compatible with the installed system
Click to expand...
Click to collapse
boot.img file included recovery+magisk+kernel

Flashing a boot.img (Kernel, for example) in an Android mobile phone via adb shell
Flashing a boot.img (Kernel, for example) in an Android mobile phone via adb shell - script.sh
gist.github.com

MTCD has separate boot and recovery partitions.
Perhaps you can adapt both recovery/kernel to be in the same image but the bootloader won't know about that (and will always boot from "recovery" partition)

Mobile/Android devices architecture

I'm having trouble understanding the architecture of mobile (and Android) devices. I compare it a lot to the design of PCs, laptops, etc, which I know quite well.
Here's my understanding on how PCs work when booting:
​The hardware has firmware stored in ROM (Read Only Memory). Actually, Flash memory is used nowadays, on which the stored content can of course be changed, unlike real ROM memories in the old days. Because the firmware is hardware-specific and its operation is very critical, its content is rarely updated or otherwise changed. Installing new firmware is called flashing. Firmware in a PC is most commonly BIOS or UEFI, the task of which is (briefly) to first run the POST tests, provide some interfaces and finally start the software in the mass storage. By mass storage, I mean memory separate from the firmware's Flash memory, which can also be Flash memory, such as an SSD disk, or a more traditional hard disk.​The BIOS (i.e. firmware) in the specified order (which first is the internal NVMe SSD or the external USB hard disk?) tries to load the software into the RAM memory for execution from mass storage MBR (Master Boot Record) part . Master boot record is a physical defined area in mass storage. Bootloader software is stored on this MBR part.​​When the bootloader (located on the MBR part) is loaded into RAM and run, it knows the contents of the end of the disk and starts the kernel from there.​​The kernel starts (in Linux) the init process, nowadays often Systemd, which starts the rest of the software.​--------------------
What kind of memories and storages are most commonly found in Android devices? One main memory (i.e. RAM)? One Flash memory for firmware (i.e ROM)? Another separate flash drive that acts as mass storage? Possibly SD card and USB stick as external mass storage?
What is firmware on Android devices?
What is the bootloader in (located in MBR part) on Android?
Linux is the kernel used by Android, which is started by the bootloader? After that, Android continues to boot, how?
A pile of terms, which I have ambiguities:
Bootloader; What's it like on Android? It is often characterized as hardware specific. So is it the case that the bootloader in Android is firmware? So in Android, the firmware runs the tasks of the PC world BIOS and bootloader (located in the MBR part), and then starts the Android located on the mass storage?
Recovery; What is this technically?
Android ROM; I can't understand this. As far as I know, Android is an operating system located mass storage, not Read-Only-Memory firmware.
Rooting; On a PC, we are used to the fact that the owner of the device has root rights. Is it just that the manufacturers have decided to set the default root password to some generated random string, and by default, the user only has access to the basic user account?
After the above has been answered, I would like someone to explain to me (separately) technically, starting from the hardware level (where and how), how do Android devices booting and work? Links to additional information are also welcome. hank you very much! If anyone can answer my questions, thank you very much!

Your questions should put you to shame.
Start reading yourself, building up your knowledge as you read.
Anyway, welcome to the forum. After a year of reading, you will laugh at your post.

ze7zez said:
Your questions should put you to shame.
Start reading yourself, building up your knowledge as you read.
Anyway, welcome to the forum. After a year of reading, you will laugh at your post.
Click to expand...
Click to collapse
I know my questions are stupid, but I'm impasse. It seems that there is much less information about designing for mobile devices than PCs. Could you link some articles on this? As the last article I read this, but it didn't help much, because I compare too much what I learned on PCs.

There are no stupid questions, there are only stupid answers.
Start with the basics based on information from google:
Architecture overview | Android Open Source Project
source.android.com

ze7zez said:
There are no stupid questions, there are only stupid answers.
Start with the basics based on information from google:
Architecture overview | Android Open Source Project
source.android.com
Click to expand...
Click to collapse
That is useful, but there is a reason why I asked about mobile/Android device design/architecture. Android itself is as far as I know (if I'm not mistaken) just an operating system, like the desktop operating systems Windows and Ubuntu, but mobile/Android devices are very different from PCs in terms of hardware and firmware. For example: https://www.quora.com/Is-there-anything-like-BIOS-in-mobiles-How-do-they-boot

How long is a huge ball of string?
No simple answer...
This is for those who are new to Android development and basically have NO understanding about the partition structure. I will give a high-level introductory explanation. PC GNU/Linux users: please note this is completely different from x86 (PC Linux) partition table. You will not come across partitions denoted as sda1, sda2, sdb1, sdb2, and so on. Instead, it will be structured as follows:
/boot
This is the partition that has all the data that is necessary for the phone to boot. It includes the kernel and the RAMDISK (these are the only components of the operating system that are stored in this partition. The remaining are stored in /System). Without this partition, the device will simply not be able to boot. Wiping this partition from recovery should only be done if absolutely required and once done, the device must NOT be rebooted before installing a new one, which can be done by installing a ROM that includes a /boot partition.
/system
This partition basically contains the entire operating system, except the kernel and the RAMDISK (as mentioned in /boot explanation). This includes the Android User Interface as well as all the system applications that come pre-installed on the device. Wiping this partition will remove Android from the device without rendering it unbootable, but you will still be able to boot into the /recovery partition to install a new ROM.
/recovery
The recovery partition can be considered as an alternative boot partition that lets you boot the device into a recovery console for performing advanced recovery and maintenance operations on it. Think of this like a proprietary recovery partition that PC companies put on prebuilt PCs. When you flash a custom recovery such as TWRP or CWM, you are overwriting this partition.
/data
Also called userdata, the data partition contains the user’s data – this is where your contacts, messages, settings and apps that you have installed go. Wiping this partition essentially performs a factory reset on your device, restoring it to the way it was when you first booted it, or the way it was after the last official or custom ROM installation. When you perform a wipe data/factory reset from recovery, it is this partition that you are wiping.
/cache
This is the partition where Android stores frequently accessed data and app components. Wiping the cache doesn’t effect your personal data but simply gets rid of the existing data there, which gets automatically rebuilt as you continue using the device.
/misc
This partition contains miscellaneous system settings in form of on/off switches. These settings may include CID (Carrier or Region ID), USB configuration and certain hardware settings etc. This is an important partition and if it is corrupt or missing, several of the device’s features will will not function normally.
/sdcard
This is not a partition on the internal memory of the device but rather the SD card. In terms of usage, this is your storage space to store your media, documents, downloads, pictures, videos, ROMs etc. on it. It is like the equivalent of the ' Users/[Username] ' folder in Windows and ' /home/~ ' folder in x86 Linux. Wiping it is perfectly safe as long as you backup all the data you require from it, to your computer first. Though several user-installed apps save their data and settings on the SD card and wiping this partition will make you lose all that data.
On devices with both an internal and an external SD card – devices like the Samsung Galaxy S and several tablets – the /sdcard partition is always used to refer to the internal SD card. For the external SD card – if present – an alternative partition is used, which differs from device to device. In case of Samsung Galaxy S series devices, it is /sdcard/sd while in many other devices, it is /sdcard2. Unlike /sdcard, no system or app data whatsoever is stored automatically on this external SD card and everything present on it has been added there by the user. You can safely wipe it after backing up any data from it that you need to save.
/sd-ext
This is not a standard Android partition, but has become popular in the custom ROM scene. It is basically an additional partition on your SD card that acts as the /data partition when used with certain ROMs that have special features called APP2SD+ or data2ext enabled. It is especially useful on devices with little internal memory allotted to the /data partition. Thus, users who want to install more programs than the internal memory allows can make this partition and use it with a custom ROM that supports this feature, to get additional storage for installing their apps. Wiping this partition is essentially the same as wiping the /data partition – you lose your contacts, SMS, market apps and settings.
/Boot (Is NOT viewable in Android)
/Recovery (Is NOT viewable in Android)
/Data (Userdata) (Is viewable in Android)
/Cache (Is viewable in Android)
/System (Is viewable in Android)
/Misc (Is NOT viewable in Android)
Ram
https://developer.android.com/topic/performance/memory-management
Understanding Firmware naming:
N986USQU1ATGM
N=Note
986U or F etc, the model of device
SQ, FX etc = CPU and model specific
U,S,E = Update, Security, Engineering, respectively
1,2,3,4,5 etc = bootloader revision (This is important! You cannot go to a previous revision)
A,B,C,D = Android version
T, U = Year (T=2020, U=2021 etc)
A,B,C etc = month (January A - December L)
1 - 9 and then A - Z =build compilation. This basically means how many builds there are in a month. They start at 1 and go to Z
So N986USQU1ATGM would be
N968-U-SQ-U-1-A-T-G-M
N968U (Note 20 Ultra Carrier version), SQ (Snapdragon), U (Update), 1 (Bootloader version), A (Build 10), T (2020), G (July), M (22nd build)
How to enter Download Mode:
Turn off the device.
Connect USB cable to your PC (Leave it disconnected from the phone)
Press and hold down the Volume Up and Volume Down buttons. While they are still pressed, plug in the USB cable into your phone.
The phone will go into download mode press volume up. In Odin you will see that phone is added.
Dirty Flash:
I would only do this if you are having to manually update to the newer firmware and would not do it if you are coming/going to U/U1 or from beta firmware or if you are on an old firmware. I'd also highly recommend doing a back up prior to the doing this
Load these into Odin
BL
AP
CP
HOME_CSC
Do NOT flash CSC or USERDATA, either of these WILL wipe your device
This is a "dirty flash" and these can sometimes cause issues. Keep in mind if things start going sideways and stuff starts not working right, your first step to a solution will be to wipe the device.
Tips on flashing U1 Firmware:
You will have to wipe, can NOT dirty Flash going between U and U1 firmware
Use the patched ODIN linked in post #2 or #3, Odin3_v3.13.3b (They are exactly the same)
Have an active US Carrier SIM installed to get carrier features
If you get your CSC Stuck on XAA/XAA/(Insert your carrier here), and can not get Carrier options back.
PIT files
https://ihax.io/samsung-pit-files-explained

plus_rlus said:
I know my questions are stupid, but I'm impasse. It seems that there is much less information about designing for mobile devices than PCs. Could you link some articles on this? As the last article I read this, but it didn't help much, because I compare too much what I learned on PCs.
Click to expand...
Click to collapse
The are no stupid questions.
Questions are asked when we do not understand something and want to learn.
There is nothing wrong or negative about asking questions.
Questions are a part of how we learn.
Cheers.

plus_rlus said:
<SNIP>
What kind of memories and storages are most commonly found in Android devices? One main memory (i.e. RAM)? One Flash memory for firmware (i.e ROM)? Another separate flash drive that acts as mass storage? Possibly SD card and USB stick as external mass storage?
What is firmware on Android devices?
What is the bootloader in (located in MBR part) on Android?
Linux is the kernel used by Android, which is started by the bootloader? After that, Android continues to boot, how?
A pile of terms, which I have ambiguities:
Bootloader; What's it like on Android? It is often characterized as hardware specific. So is it the case that the bootloader in Android is firmware? So in Android, the firmware runs the tasks of the PC world BIOS and bootloader (located in the MBR part), and then starts the Android located on the mass storage?
Recovery; What is this technically?
Android ROM; I can't understand this. As far as I know, Android is an operating system located mass storage, not Read-Only-Memory firmware.
Rooting; On a PC, we are used to the fact that the owner of the device has root rights. Is it just that the manufacturers have decided to set the default root password to some generated random string, and by default, the user only has access to the basic user account?
After the above has been answered, I would like someone to explain to me (separately) technically, starting from the hardware level (where and how), how do Android devices booting and work? Links to additional information are also welcome. hank you very much! If anyone can answer my questions, thank you very much!
Click to expand...
Click to collapse
Firmware is the hardware specific drivers, library files and other resources that are supplied by the manufacture(s) and are chipset specific.
The firmware is proprietary and normally closed source. Basically the parts that make the hardware work.
The bootloader is what actually boots the device.
This is supplied by the device manufacture(s) and is device specific.
It is separate from the system.​
Recovery is a mini Android environment.
- Factory (Stock) recoveries are restricted to the user but have unrestricted (root) access to the device.
- Custom recoveries (TWRP, OrangeFox, ..) allow the user unrestricted (root) access to the device.
Android ROM (rom) is the actual system (OS) and normally you would include the version that you are running.
Stock roms - Google 12L, AOSP xx, OOS 12, MIUI xx, ColorOS xx, ...
Custom roms - Lineage 19.1, crDroid 12.1, AospExtended 12.1, ...
In computer terms it would be..
Windows 7, Linux (Fedora 34), MacOS Monterey.​I am not sure what the current versions of MIUI and ColorOS are, hence the xx.​
Once the bootloader boots the device, a few things can happen.
- The system boot image (system kernel) takes over and boots the device into system (rom).
- The recovery boot image (recovery kernel) takes over and boots the device into recovery (mini Android environment).
- If system fails to boot, device reboots into recovery (Recovery Party) if recovery can boot.
- If no boot image takes over, you will stay in the bootloader, reboot into some special mode or just a good old fashion boot-loop.
There have been a lot of changes to Android though the years..
Each device, manufacture, Android version.. can be different from another.
The most common bootloader is (or supports) fastboot but, this is manufacture and device specific.
Not to be confused with fastboot_d (new story that started with Android 10/11?).​This has also changed though the years, some manufacture use their own variation of bootloader.
HTC had H-BOOT, Samsung does their own thing along with some other manufactures.
Rooting....
By default the substitute (switch) user su command is removed from Android.
This is what most refer to as superuser since it defaults to root user if you do not specify a substitute user.​
This has been a long and changing story in the Android world also.
Old but, well worth the read.
How-To SU - [chainfire.eu] - Link
The current most popular used root solution is Magisk.
It is a little more than just su. ​Magisk - [GitHub] - Link
---
It might be easier if you see an actual partition table.
Nexus 7 16 Gig WiFi - [PastBin] - Link
Might as well make it an ... interesting one.
In this example, userdata only has 1.2 Gigs since the rest is used by other partitions.
userdata is mounted as /sdcard.​
Save for boot, cache, system, misc, recovery and userdata.
The other partitions would be considered firmware.
When the device boots, the partitions get mounted to /dev/block.
Hope it helps more than confuse.
Cheers.