FBE vs FDE: Enforce FDE despite FBE - General Questions and Answers

FBE vs FDE: Enforce FDE despite FBE - General Questions and Answers

Hello,
the proper section for my question was a bit tricky for me, so I will put it in General Q&A:
I use a device that comes with File based Encryption - namely Samsung Knox.
(But its not a Samsung Knox specific question)
For that I use some AOSP based ROM - namely LineageOS
(Im not too sure if thats some LOS specific question ... )
Now: File based Encryption comes as default.
But I want some Full Disk Encryption for personal preference.
The GUI of my ROM does not allow me to change the encryption method.
Neither can I deactivate FBE in my ROM, nor can I manually put a second layer with FDE ontop.
So: How to enforce FDE?
I guess with building my own ROM it could be achieved - but obviously I look for some easier way, like shell commands to get rid of FBE first and later use regular ROM capabilities to just use the AOSP internal FDE feature.
Anyone with any experience in this field?
Thanks

IMO you had better asked for help here:
Android Q&A, Help & Troubleshooting
This forum is for all of your questions about Android Development and Hacking. If you need help troubleshooting a problem, please be as specific as possible by describing your software configuration, including the ROM, kernel, and any modifications you've done.
forum.xda-developers.com

It's simply not a choice, you have to live with whatever the ROM provides. Of course you can disable encryption and format userdata at wish unencrypted.
May I ask what's the benefit of FDE compared to FBE?
(btw Samsung encryption is unrelated to Samsung Knox)

aIecxs said:
May I ask what's the benefit of FDE compared to FBE?
Click to expand...
Click to collapse
File Based Encryption (FBE)
Note: That's became default with the release of Android 10 in 2019.
Cold Device – contains a stock background image, user data is locked, and needs bruteforce to access.
Hot Device – background image is visible, the camera is accessible, so data collection can be performed on the phone with the proper tools without knowing the passcode.
Full Disc Encryption with Secure Start-Up (FDE)
Note: That's default encryption since Android 6.
Cold Device (Samsung) – must enter the user’s password before the device will even start
Cold Device (LG) – the operating system is not fully booted without the password
Understanding how to differentiate between cold and hot devices while collecting data will help ensure you use the proper tools.
BTW:
If on device USB-Debugging is enabled - most users do so to have an emergency entrance - a hacker can use ADB to easily intrude in device's Android and deduct data even if they are FBE encrypted, whereas on a FDE encrypted device a hacker stands in front of a closed door, IMO, although ADB may be fully functional.

If you use a screen lock on your Android smartphone, full-disk encryption is enabled by default.

jwoegerbauer said:
If on device USB-Debugging is enabled - most users do so to have an emergency entrance - a hacker can use ADB to easily intrude in device's Android and deduct data even if they are FBE encrypted, whereas on a FDE encrypted device a hacker stands in front of a closed door, IMO.
Click to expand...
Click to collapse
Thx but I asked OP.
adbd is running only after userdata is decrypted, as adb_keys is located /data/misc/adb. therefore that would make no difference (btw hacker would need adbkey.pub of victims PC) despites most user don't have enabled usb debugging at all.
There is no difference between FBE and FDE on "Hot Device" after first unlock (decrypt), except that FBE is more secure before first unlock, as the moment android lock screen appears, FDE whole disk is already decrypted, while FBE is splitted in (ce) credential encrypted + (de) device encrypted storage.
the so called secure start-up is optional. most stock FDE encrypted devices are simply encrypted with default_password and are easier to break (I have done many times). In such case it's even possible to bypass screen lock by simply deleting locksettings.db, while the same would for sure destroy FBE and make files unrecoverable.
But even on secure start-up it's easier to bruteforce passphrase online, as the (encrypted) DEK is saved in userspace (crypto-footer) only, which (in theory) allows attacker to backup & restore status quo to cheat gatekeeper timeout and it's even possible to reset failed decrypts counter, while on FBE encryption key is stored in TEE only which makes it impossible to backup (and therefore harder to cheat gatekeeper).
Furthermore, once decrypted, on FDE it's (hard but) possible to recover deleted files, while on FBE it's impossible to recover deleted files per design.
I see no reason to believe FBE is less secure than FDE and don't see the benefit.
btw Samsung devices provide (FBE) "Strong protection" which is successor to (FDE) Secure startup:
-> Settings -> Biometrics and security -> Other security settings -> Strong protection
jwoegerbauer said:
If you use a screen lock on your Android smartphone, full-disk encryption is enabled by default.
Click to expand...
Click to collapse
Completely unrelated to each other. Two cases:
1) I personally prefer unlocked bootloader and use no encryption at all (I have disabled forcefully), but still I am using pin as screen lock. (there is no private data on phone, that's my decision)
2) stock devices are encrypted on first boot, even before user reaches initial setup. user can decide to just swipe with no pin at all, still device itself is encrypted, despites it has no screen lock.
This applies to both FDE and FBE.

aIecxs said:
Thx but I asked OP.
adbd is running only after userdata is decrypted, as adb_keys located /data/misc/adb. therefore that would make no difference (btw hacker would need adbkey.pub of victims PC) despites most user don't have enabled usb debugging at all.
Click to expand...
Click to collapse
Only allowed me to do you often do.
If you could boot a device into recovery mode - what method used ever - then ADB is accessible and fully functional, AFAIK.

jwoegerbauer said:
If you could boot a device into recovery mode - what method used ever - then ADB is accessible and fully functional, AFAIK.
Click to expand...
Click to collapse
Right, if you can boot into custom recovery, which avb/dm-verity prevents on locked bootloader, at least it should
Still it makes no difference to bruteforce FDE or FBE then, assuming TWRP magically bypasses gatekeeper timeout.
btw Cellebrite, isn't that the company that got hacked by signal founder after false claim they could crack signal?
https://arstechnica.com/information...turns-the-tables-on-forensics-firm-cellebrite

Related

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.

Question Many questions from a total Android newbie

Hi,
Although I passed my 40 I just bought my first smartphone a few week ago. It’s a Doogee S96Pro. As somebody who like to understand how it works, I already learn a few thing on the Android ecosystem.
I’ve been able to activate the developer mode and to use adb to uninstall some apps. I also managed to boot in fastboot mode to unlock the phone.
My first attempt at flashing was a fail, the phone was rebooting in a loop, indicating "Red state". I guess I should have never "fastboot flash boot/recovery foo.img" if "fastboot boot foo.img" didn’t work? What’s your opinion on this?
The Doogee support sent me a link to the files for my phone. In fact someone on this forum has had already posted it. The two archives are named :
S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.1130.V3.02.zip
S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04.zip
To make the phone boot again I flashed the boot partition with the boot.img file I found in the second archive. If I understood what I read, the file with "EEA" in it’s name is the "European version" while the other one is the "Global version".
Although I flashed with the boot.img that was in S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04.zip, if I go to the update info (About the phone > Update), I can see the string S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.0128.V3.03_20210128-1612. I don’t understand why this difference (v3.03 vs. v3.04).
Then I used the Magisk Manager to patch this boot.img file and flash it again. I now have root access on the phone which is nice.
Now the questions!
When booting the phone says: “Orange state, your phone’s unlocked”, then it boots normally. What’s the implication of this? I’m not sure but I think I tried to lock it again (fastboot flashing lock) but the message remains. Does it sound possible to you? I should check again this point…
In the Magisk Manager I also tried the "SafetyNet" check, which is refused. Is it OK? What does it imply? Why would I need to pass this SafetyNet test for?
I’m not sure I understood how the recovery thing works… I understand it’s another partition than "boot", and I know I can boot on it using the boot menu (pressing volume up when turning on the phone). What I don’t know is if it starts a recovering of the system automatically when booting on this partition (then erasing all data on the phone), or not.
Let’s say I flash the boot.img on the recovery partition (fastboot flash recovery boot.img). If I do a normal boot it should boot as usual, but if I boot on recovery it would boot on a virgin system. Am I right? Let says I configure nothing and reboot again, a normal boot this time. I then should get back to my usual, already configured system, as the "boot" partition hasn’t been modified. Is this also right?
Before doing anymore tests I would like to be able to backup an image with the phone already configured, with data and root access and applications. One (or maybe two or three?) file I can keep on my computer, and in case I break the boot on the phone, I could just fastboot flash boot my_custom_image.img to recover my phone configured. Oy maybe also flashing a "userdata" partition? Would I need some other partition? Is it more complicated than that?
It seems I have to identify the right partition(s) and carefully use dd to dump the partition to an image file… Before trying to do so I’d like to have some advice, hence this post!
Also. I read about a software called TWPR. Should I use it, and why ? I understand it’s a system aimed to be flashed on the recovery partition, is it right? What’s its use?
Finally I read about LineageOS which is the ultimate customization for the phone, it’s a “pure” Android, which is totally opensource (but it has to uses a lot of proprietary blob for devices AFAIK). I don’t think I’ll get there anyway. If I’m not mistaken it’s hard to do, especially with new phones nobody has ran LineageOS on, and there is something like no probability all the devices would work anyway.
Have a nice day.

there's no implication when you see "Orange state, your phone’s unlocked” unless you didn't the one who did it that means your device is tampered ..
also on SafetyNet is broad topic you can learn what it is here https://www.didgeridoohan.com/magisk/MagiskHideSafetyNet also
"Why would I need to pass this SafetyNet test for?" there are multiple reason such as you can't install banking apps,netflix, ...etc nor download them via playstore
moving on it is not recommend to backup userdata partition since it just contain all contains evidence of user activity. It contains call and SMS records, contacts, user-installed apps, app data, settings, and so-on-and-so-forth. In most newer phones, it also is likely to contain photos and videos and other user-generated files unless an external SD card is present. Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
this prevent rooted application crawling on other application data such as paypal just stealing your login info and money
TWRP is like recovery mode but more feature packed (you can backup partition with it not available on stock recovery)
also experience is the best teacher you must experience failure to improve

ineedroot69 said:
Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
this prevent rooted application crawling on other application data such as paypal just stealing your login info and money
Click to expand...
Click to collapse
With a simple ADB command you can decrypt Android partitions:
Code:
adb shell "recovery --set_encrypted_filesystem=on|off" <- enables / diasables encrypted fs

Hi,
Many thx for your answers.
also experience is the best teacher you must experience failure to improve
Click to expand...
Click to collapse
I can confirm that. I accidentally uninstalled the stock launcher with ADB. I’ve been able to install another launcher (I think I’ll keep on Nova Launcher). I tested a few (Launcher<3 and KISS Launcher), although they work fine none of them support switching between running apps. It’s a little bit annoying but I have another way to stop running apps (with App Manager). I guess the only way to get this functionality back is to flash again the boot partition with the Magisk patched image I already used, and to re-configure all the phone again (this is good to learn and luckily I don’t have important data in the phone yet).
Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
Click to expand...
Click to collapse
Couldn’t be possible to dump both boot and userdata partitions and then flash them back both “at once”. The key for encrypting/decrypting the user data being contains in the boot (system ?) partition?
I realize Android has a bunch of security configuration you rarely find on a Linux server. Also the hardware is full of devices which require close-source firmware to operate. This is definitively not a good platform for hacking, like most PC are or a Rasberry Pi is . And I bet Windows and Apple phones are evermore closed…
About encrypting, I have a file called "googlekey/kb_0000000000.bin", which is the same in two archives the support sent me
$ md5sum S9S88A7.DGE.DOOGEE.*/googlekey/kb*
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.1130.V3.02/googlekey/kb_0000000000.bin
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04/googlekey/kb_0000000000.bin
Click to expand...
Click to collapse
This file is not “per device” knowing every S96Pro users get the same archives. What’s its purpose?
I wonder the same for many files in this archive but I won’t bother you, I’ll make some search.
The one thing I’d like to understand is why the archive is labelled "1203.V3.04" and the system on my phone (after I flashed the boot partition with (a Magisk patched made from) the boot.img in this archive says : "0128.V3.03_20210128". Could it be related to the Magisk patching? (I didn’t check what I had with the stock boot.img). Or I have been downgraded by Google during install?
With a simple ADB command you can decrypt Android partitions:
Click to expand...
Click to collapse
Thx for this. What does it imply to do so? Will the Android system run with this unencrypted data partition? Is there a way to encrypt it again? (With ADB or directly in the phone?)
I’ve seen there are dozens of partitions on a running Android. So far this is what I understood (is this correct?) : There are three important partitions : boot, recovery and userdata. "boot" et "recovery" are the only ones the device can boot on (except booting from an image in fastboot mode using "fastboot boot boot.img"?). Are they some other important partitions this is important to be aware of?
Having a bootable "boot" and a bootable "recovery" partitions, it should be possible to install two different Android OS? I guess this is not possible and the "recovery" partition is dedicated to recovering (ie: reinstall the system) but I don’t understand how and why exactly. The encrypting thing maybe? The system must have a userdata partition and this one can’t be shared between to system…
I think I should buy an older Android smartphone to make all that kind of test, especially knowing I don’t have any other phone I can use for everyday use… Do you have some advice on brands and models which are more friendly with customization of the system?
Apart of ADB and fastboot, what are the other important tools to know about?
For Android development (I mean development of apps for Android), does everyone use an emulator? What’s the best option for such an emulator on Linux?
Have a nice day.

Marotte said:
For Android development (I mean development of apps for Android), does everyone use an emulator? What’s the best option for such an emulator on Linux?
Click to expand...
Click to collapse
My recommendation is GenyMotion for Linux. This emulator requires VirtualBox for Linux gets installed before.
Install GenyMotion
How To Install GenyMotion (Android Emulator) On Linux | 2DayGeek
2daygeek.com Linux Tips, Tricks & News today :- How to Install GenyMotion (Android Emulator) on Ubuntu, Debian, Linux Mint, openSUSE, Arch Linux, Fedora, CentOS, RHEL, Mageia, Manjaro
www.2daygeek.com
DL VirtualBox
Linux_Downloads – Oracle VM VirtualBox
www.virtualbox.org

Marotte said:
Having a bootable "boot" and a bootable "recovery" partitions, it should be possible to install two different Android OS? I guess this is not possible and the "recovery" partition is dedicated to recovering (ie: reinstall the system) but I don’t understand how and why exactly. The encrypting thing maybe?
Click to expand...
Click to collapse
Partitions /boot & /recovery explained:
/boot
This is the partition that enables the phone to boot, as the name suggests. It includes the kernel and the ramdisk. Without this partition, the device will simply not be able to boot.
/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.
That's what you can do from within the recovery console:
Reboot system now
Install ZIP from SD-card
Install ZIP from Sideload
Wipe data / factory reset
Wipe cache partition
Backup and restore

Secure Startup encryption for Samsung Bootloader

Hi !
Is "Secure start-up" encryption for bootloader strong enough to keep all my data safe from the thief? Basically , all the data stored in the Emmc memory is encrypted , so , even if they swap (hot swap) the Emmc chip out of the phone's PCB into a Emmc programmer/reader , they can't read the data without the magic encryption key . It's strong enough this feature to keep the sensitive data , as an example (credit card credentials) , safe against any intruder ? So , there isn't an exploit for that , and the encryption level should be AES128 if I'm not wrong ? It's 100% safe ?

Boot encryption has NOTHING to do with Android's data ( disk-based / file-based ) encryption: Secure boot is a process that validates firmware images on devices before they are allowed to execute, secure boot helps to ensure that only authorized code can execute before the operating system loads.
Means: Secure boot cryptographically validates the digital signature of all boot components and finally the main OS and all components that run in it ( such as drivers and system apps ).

jwoegerbauer said:
Boot encryption has NOTHING to do with Android's data ( disk-based / file-based ) encryption: Secure boot is a process that validates firmware images on devices before they are allowed to execute, secure boot helps to ensure that only authorized code can execute before the operating system loads.
Means: Secure boot cryptographically validates the digital signature of all boot components and finally the main OS and all components that run in it ( such as drivers and system apps ).
Click to expand...
Click to collapse
but Android encryption? Can I leave there my data ? You didn't answer to it ...

I referred to this thread's title.
Android's symmetric disk-based encryption ( Android 5 up to Android 9 ) and/or file-based encrpytion ( Android 10 and higher ) works as follows: 1st step is Android creates an AES-128 key what is called Masterkey - stored in Android's system. 2nd step is Android creates from user PIN / Password an additional AES-128 key what is used to encrypt the Masterkey - also stored in Android's system.
Knowing this I personally don't think you can crack the doubly encrypted key. But who knows ...

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.

[HELP]Restoring a decrypted backup file using twrp

So I have encrypted a phone, Lineage OS 14.1 UNOFFICIAL. DIDNT WORK. i couldnt boot to os
I went into twrp made backup of everything except EFS partition,, transfered to my PC. Formatted data then even tried new OS install it does work. So i just went and tried restoring the data partition only and it restored it succesfully, when I try booting, It takes some time and encryption starts, automatically.
Is there a way to not start encryption process? Are there some files in data partition that are causing encryption process to start on boot which I can remove? Help
NOTE: TWRP did ask for my password when I was making my backup, so I entered correctly and It worked. I made a backup of that partition. My guess is that something is initiating the encryption process on boot

Encrypting is default behavior: since Android 4 it was FDE ( full-disk encryption ) , since Android 9 it's FBE ( file-based encryption ). Since Android 10 FBE is mandatory.
Encryption takes place when device gets booted if in Android's FSTAB file this flag is set.

jwoegerbauer said:
Encrypting is default behavior: since Android 4 it was FDE ( full-disk encryption ) , since Android 9 it's FBE ( file-based encryption ). Since Android 10 FBE is mandatory.
Encryption takes place when device gets booted if in Android's FSTAB file this flag is set.
Click to expand...
Click to collapse
First of all, thank you for your reply. Can I open and change that flag inside the fstab file?

android?boy said:
First of all, thank you for your reply. Can I open and change that flag inside the fstab file?
Click to expand...
Click to collapse
jwoegerbauer said:
Encrypting is default behavior: since Android 4 it was FDE ( full-disk encryption ) , since Android 9 it's FBE ( file-based encryption ). Since Android 10 FBE is mandatory.
Encryption takes place when device gets booted if in Android's FSTAB file this flag is set.
Click to expand...
Click to collapse
Also, Where is the fstab file located. I saw it in /etc/fstab, but I didnt change that partition when I restored only Data, so it must be there. Am I wrong?

To answer your question "Can I open and change that flag inside the fstab file?":
Even if fstab file is present - it's present in several locations, you cannot simply edit it and be done. You'd have to rebuild the boot image instead – a task that goes beyond the scope of this thread ( which is end-user orientated, and creating/rebuilding a boot image rather is in the domain of developers ).

first, determine encryption type.
Code:
adb shell getprop ro.crypto.type
adb shell getprop ro.crypto.state
next find the fstab. for older devices it is in boot ramdisk (needs un-/repacking boot.img with AIK)
https://forum.xda-developers.com/t/...-kernel-ramdisk-win-android-linux-mac.2073775
for (SAR) system-as-root devices it is in /vendor/etc.
assuming dm-verity is disabled and in TWRP system/vendor is mountable rw, for (FDE) full disk encryption you can replace the forceencrypt= flag with encryptable=
https://forum.xda-developers.com/t/4061571/post-82849947
for (FBE) file based encryption it is not possible to disable the first boot behaviour. either keep encryption as is (recommended) or destroy encryption completely by removing the fileencryption= flag and formatting /data.
there exist flashable zips for this
https://forum.xda-developers.com/t/...encrypt-disk-quota-disabler-11-2-2020.3817389

Database Info

welcome