Switching to file based encryption (FBE) on old devices with custom ROM

Switching to file based encryption (FBE) on old devices with custom ROM - General Questions and Answers

Hi all,
I'm using a Samsung Galaxy S5 which is now >8 years out and was officially shipped with Android versions 4-6. Luckily, in the age of custom ROMs, you can use such devices for much longer than the manufacturer had intended.
I recently upgraded my phone to an Android 11 based ROM (in my case LineageOS 18.1, but I guess the question applies to other ROMs as well). I wiped the phone completely and expected that, after flashing the ROM and encrypting, I would end up with FBE. To my surprise, however, encryption was FDE instead.
I then spent a lot of time trying to dig down to fstab.qcom, forcing FBE, trying to retrieve a valid contexts file and repackaging the whole thing (which may seem trivial to some, but if you've never done it before felt like a rather complicated operation). I guess I never succeeded - the repackaged ROM always ended up smaller than the original and wouldn't flash - but after several hours, it dawned upon me that I've probably been misunderstanding the problem in the first place.
Android 11 (and any ROMs based on it) will default to FBE anyway, so if encryption takes the path of FDE instead, I suppose there's a really good reason for this (in a sense that you're not facing a choice but a necessity). I tried to find some definitive answers on the Net, but most of the info I found seems misleading. I keep reading that older phones which came out with earlier versions of Android (versions <7 respectively <9) are ALLOWED to retain FDE is that's what they were originally encrypted with. The information of what you can do if you don't want this "privilege" are rather scarce, however.
So is my hunch correct that the actual reason why I can't get FBE isn't some tweakable configuration setting, but something more fundamental, like the kernel being unable to handle it, or maybe hardware limitations? Or am I getting it wrong again?

This might seem like a really obvious solution but have you tried this?:
Make sure the phone is encrypted normally first (Settings > Security)
Then make sure developer options are enabled.
Settings > System > Developer Options > Convert to file encryption > Wipe and convert
It shows a page that reads:
"Convert data partition to file based encryption !!Warning!! This will erase all your data. This feature is alpha and may not work correctly. Press 'wipe and convert' to continue."
I see that on both my LG Nexus 5X and my Lenovo Tab M10 FHD Plus, both running stock ROM, both using FDE by default, both messages look exactly the same on both devices and this option was also present on Lineage and AOSP based ROMs too so this should be in any ROM.

It's actually one of the first things I tried, but oddly, that function doesn't exist in my developer options. Originally, I misinterpreted this assuming that LineageOS might be configured this way, but after doing a bit of homework I 100% agree that this option should be in any such ROM (including Lineage).
So at this point I'm taking it as another hint that my phone may just not be capable of FBE - but if that's indeed the case, I would be happy to understand why.
The fact that the LG Nexus 5X has this option doesn't contradict my assumptions, because it's a newer phone ("only" 7 years old and shipped with Android 6-8, which is already in the range of FBE-capable Android versions).

Look inside here:
https://www.reddit.com/r/LineageOS/comments/lgy53j

I came across that thread as well, but don't think it answers the question. If you omit the irrelevant (restoring userdata, which doesn't apply to me), what he basically did is started with a clean device and set fileencrypt=ice in fstab.qcom to make sure he gets FBE instead of FDE.
According to Google's Android documentation (https://source.android.com/security/encryption/file-based), however, fileencrypt=ice has been deprecated with Android 11, because FBE is the only choice now (if you can't opt out, there's no need to opt in).

Related

Garminfone ro.secure=0!

I cracked the img format for Garminfones... started out by looking at the format of the file and it turns out the only difference is the loader addresses.
Took the stock recovery and disabled security, which worked. Then modified the boot.img to disable security and had the filesystems mount rw by default and flashed it to the recovery partition. Booted into recovery mode and viola... security disabled. Now it is time to flash it to the boot partition and cross fingers.
Now I just need to figure out how to compile a working recovery mode... preferrably one that can be activated by keypress. Not sure how to do that part. I can only get to recovery and bootloader mode after booting into the os.
I should have a working mkbooting soon so I don't have to hex edit the generated img files.

Well done!
I look forward to any progress reports that you make.
Are you using the official or leaked version of the 2.1 Eclair?

The official and leaked versions are equal.
And I did find out that we do have fastboot It's the blue screen that you get when you hold UP+POWER, or do adb reboot bootloader... two different messages on the screen. I can get fastboot to accept a reboot-bootloader command, but I'm having some issues actually getting any information out of it or flashing something like a boot image.
To get it to respond, you do:
fastboot -i 0x091E <command>
the -i makes it specify the Vendor ID, since fastboot only accepts a few vendors by default.
I also found out that I don't have to rebuild the mkbootimg program... if you add --base 0x1AC00000, then the load addresses match up in the resulting img file.

If someone is willing to host it, I can share the modified boot.img that sets ro.secure=0 and mounts the filesystems RW by default.

Hey, just joined to reply to this thread. Is it possible for you to upload to a file-sharing site such as megaupload, fileserve, etc.
I'm just getting into this whole rooting/modifying stuff. I used z4root to root my A50 and have installed superuser. I have deleted some of the carrier .apks but am thinking I should have made a back-up before doing so. I also bought setcpu from the market before finding out the Qualcomm chip does not allow overclocking.
Can I ask what the point of modifying the boot image is? Is this the first step in being able to install custom roms to the phone?
Anyway, appreciate the effort you guys have put in to modifying the phone.

You get a higher level of access, along with things like being able to customize parts of the phone, in my case enabling read/write by default. I also am planning on playing a bit, like remapping partitions... the instructions are in the init.rc file.
Always take a dump_image (or remount all mtd partitions as read only and just use cat to dump the mtd partitions). Also tar up each of the root folders (and files) in case you need quick access to any files you may have deleted. If you need a system app back and you don't have a backup, you have to reflash 2.1 again. Very important... if you care about the Garmin map software, make sure to get the /storage folder, including the one in it named .System... you can recover the maps, vehicles, etc by using two different Garmin web update windows programs-- one for the system stuff and one for the maps. Better safe than sorry.

any news on this
What would we need to be able to overclock?

I spent a good portion of the day yesterday rooting and installing CyanogenMod on my fiance's MyTouch Slide, and I have to say, it was amazing. It's a lot more than just a throwing around some custom default apps, cleaning up bloatware, even adding some kernel modules... I can do all of that on my rooted Garminfone just fine. It also had the Android 2.3 base, and it has polish and refinements that just can't be done without a custom built ROM.
I bought my Garminfone on purpose, even knowing that it shipped with Android 1.6, even knowing that the interface was awful, even knowing that the device wasn't going to sell as well as I wished it would. I bought it for it's offline maps, and for it's fantastic GPS. Things have improved since I bought my device... Android 2.1 was released, an improved user interface arrived, I gained root access and was able to clean up some stuff, etc. etc. But none of that prevented me from being jealous yesterday after seeing CyanogenMod. Further, Cyanogen has experience with preserving apps through the process of installing his mod for the first time; He did it when Google first sent him the Cease and Desist letter barring him from packaging CyanogenMod with Google Apps. I'm not sure HOW he did it, and I don't care, but I do think that it's very possible for him to do just that again with our Garmin Maps and the associated apps.
For these reasons, I suggest that we could have our cake, and we could eat it too: Have a modern OS (Based on Android 2.3), have a clean, unified interface, with no bloatware AND our maps... Cyanogen is not known for making his mod for phones he doesnt own. Further, as we all know, ours was possibly the worst selling and least popular android device ever released to market. While I consider myself versed in the ways of Linux, I am not a developer. I run Gentoo, and have the associated skills, and I will contribute in any way I know how, but hacking is not my forte. I can't expect brilliant minds to work for any project for nothing. Therefore, I am putting my money where my mouth is... I'm going to take all the money from my weekly paycheck that I can afford, and I'm going to donate it to that project. It won't be much... I am a starving college kid, after all... but it will be generous within my means. I am also going to post a reference to this thread everywhere I know how... My contribution might be small, but the community might be able to get something together that is mighty.
Visit topic 5864-garminfone on their forums to add your support.
(Edit: They moved my post, I have corrected this with the correct forum topic)

Is there any Android device that supports hardware accelerated encryption?

Just bought a new Galaxy Tab S 10.5 Wifi and I have been debating whether to enable full disk encryption. I know that the stock android implementation of encryption is entirely software based, but Samsung mentioned in their documentation that their ODE (On Device Encryption) system supports hardware accelerated encryption. However, information on the topic is scarce, and I cannot confirm which models actually support acceleration.
Does anyone know of a list of android devices that supports hardware accelerated encryption?

snapper.fishes said:
Just bought a new Galaxy Tab S 10.5 Wifi and I have been debating whether to enable full disk encryption. I know that the stock android implementation of encryption is entirely software based, but Samsung mentioned in their documentation that their ODE (On Risk Encryption) system supports hardware accelerated encryption. However, information on the topic is scarce, and I cannot confirm which models actually support acceleration.
Does anyone know of a list of android devices that supports hardware accelerated encryption?
Click to expand...
Click to collapse
Go to Settings/Security and if it says Storage Type-Hadrware Backed, then your device has crypto module. However, big warning here: if your master encryption key sits in hardware (like in Iphones), there is nothing easier for a sophisticated attacker to get the key directly from there. If, like in Lollipop, the master key is salted on hard drive and crypto module holds another key used to sign the master key, that provides an additional layer of protection against brute force attack. In other words, someone can take an image of your entire hard drive and then brute force your password offline or in the case of Iphone, just get the key from hardware. In lollipop, it is impossible. So, sometimes google does good things (by mistake)...

In lollipop, it is impossible.
Click to expand...
Click to collapse
Android disk encryption is based on dm-crypt, which means it's at the block device layer. The encryption algorithm used is AES-128 with cipher-block chaining (CBC) and ESSIV:SHA256. The master key is encrypted with 128-bit AES via calls to the OpenSSL library. New Lollipop devices encrypted at first boot cannot be returned to an unencrypted state.
The unlock PIN/password is used to derive the AES disk encryption key which is stored in the volume header. As from 4.4, scrypt is used to derive the keys in order to make brute force attacks a little harder, but using a strong password instead of a stupid PIN remains highly recommended. On certain Nexus devices, the key is hardware-protected (likely TEE).
Nothing is impossible but's harder:
http://www.bbc.com/news/technology-31765672
http://www.washingtonpost.com/blogs...-apple-and-google-users-researchers-discover/
http://www.bbc.com/news/technology-31729305

CHEF-KOCH said:
Nothing is impossible but's harder:
http://www.bbc.com/news/technology-31765672
http://www.washingtonpost.com/blogs...-apple-and-google-users-researchers-discover/
http://www.bbc.com/news/technology-31729305
Click to expand...
Click to collapse
What have these news to do with Android encryption?
Seriously, there was a clear question by the OP and you didn't even try to answer at all. Instead you copy and paste text fragments from other websites and post irrevelant links...

@bastei
And how your post helps here? I explained very well that FDE is vulnerable with several attacks. It isn't worth to use it, especially on such hardware, because it costs a lot of performance for nothing.
FDE isn't secure to use, especially if you have a mobile device which allows the attacker to get physical access to it + the mentioned attacks.
But to answer the question:
Hardware accelerated encryption is dependent on which hardware (needs to support special flags like AES/AES-NI/AVX) you use and if your os supports it (minimum Android 3.x) or not. And no there is no list, because all new hardware after (and some of them before) Android 3.x comes with support for it, the Tab S uses AES 256-Bit Encryption according to the specs.
ODE (On Risk Encryption)
Click to expand...
Click to collapse
It's Samsung On-Device Encryption (ODE) and not on Risk ...

Yup that's a typo. Going to check the settings when I get home today.

CHEF-KOCH said:
@bastei
I explained very well that FDE is vulnerable with several attacks. It isn't worth to use it, especially on such hardware, because it costs a lot of performance for nothing.
FDE isn't secure to use, especially if you have a mobile device which allows the attacker to get physical access to it + the mentioned attacks. .
Click to expand...
Click to collapse
With all due respect, but your explanation is wrong. If encryption is properly implemented, you reduce vulnerability to virtually none. Users just have to understand how encryption works and what it is designed for. Contrary to popular beliefs, disk encryption is not designed to protect the device that is live/running, it only prevents access to your data, when your phone is off. By the way, the term "full disk encryption" , as it applies to Android, is highly misleading, because unlike in Linux, Android only provides for data encryption.
However, Android allows to implement encryption in a way that it is virtually impossible to break. You can have separate passwords short for screen and long/strong for boot and encryption. In addition, Android Lollipop provides an extra layer of protection by putting a second key, which is used to sign the master key in crypto module (hardware). This is much better than in IOS (iphones) where the master key simply sits in hardware crypto module and therefore could be easily obtained by a sophisticated attacker (think back doors in crypto module and weak hardware assisted random number generation).
Let me give you an example with my Sony Xperia Z1 running custom lollipop. I have enabled 256 bit encryption; I have increased the length of various keys, as well as the number of iterations for random number generation; then I have disabled in kernel hardware based weakened random number generator and enabled all other methods inactive by default (thanks to google and sony for making it easier to break for spooks); I then disabled hardware overlay option, which causes slow down, so, now, there is no visible difference in performance with unencrypted device. And finally, I have encrypted the phone via adb shell by using a long pass phrase, so that screen pin was not used in encryption in any way, including its salted traces on the device. By the way, when you encrypt lollipop via adb shell, you don't input your raw passphrase, but rather its hexed version, and guess what, I hexed it on my computer, as opposed to the phone. So, when I turn my phone off, I know that no sophisticated spook can get access to my data even if they take an image of all my partitions and try to brutforce the password off the phone. They simply can't. No one can break properly implemented 256 bit AES encryption. That is why the spooks need backdoors in hardware and weak random number generation (the latter is disabled in kernel on my Z1).
So, properly implemented encryption (and Android Lollipop provides for that) does not visibly slow down the device and can make it impossible for spooks to break. .

With all due respect, but your explanation is wrong. If encryption is properly implemented, you reduce vulnerability to virtually none. Users just have to understand how encryption works and what it is designed for. Contrary to popular beliefs, disk encryption is not designed to protect the device that is live/running, it only prevents access to your data, when your phone is off. By the way, the term "full disk encryption" , as it applies to Android, is highly misleading, because unlike in Linux, Android only provides for data encryption.
Click to expand...
Click to collapse
But Android is not a Computer which is on the same place all the time which means that it is a lot of easier to get physical access to it. That means an attacker have all the time to crack it, which in fact is only a matter of time. With or without additional protection mechanism - it will be cracked soon or later, and if you asking me it's not worth to use FDE on a mobile device, it coasts performance (as said for nothing).
The focus should be to protect data, correct but these kind of protection not protect against usage data stealing if most aps need internet connection which never use any secure way to send and receive data - So the risk here is much higher that a attacker can collect all necassary data if your phone is unlocked and a app xyz is running in the background which logs all stuff, such as Pin, passwords for website logins or whatever.
However, Android allows to implement encryption in a way that it is virtually impossible to break. You can have separate passwords short for screen and long/strong for boot and encryption. In addition, Android Lollipop provides an extra layer of protection by putting a second key, which is used to sign the master key in crypto module (hardware). This is much better than in IOS (iphones) where the master key simply sits in hardware crypto module and therefore could be easily obtained by a sophisticated attacker (think back doors in crypto module and weak hardware assisted random number generation).
Click to expand...
Click to collapse
It's very easy breakable there a several tools out there, exploits and poc's - and why need to crack something if you better steal data that are necessary over internet? Which tactic is easier - sure the last. Yes, lollipop is the first secure os, but not all people use it right now or the oem rolls out the update for every device. But I generally agree in the aspect that lollipop fix most stuff which are vulnerable compared to Android 4.x.
There are several attacks which affects all Android versions even latest lollipop:
- First, the encryption doesn't help much if you haven't set a passcode!
- Limitations in lollipops encryption explained over here
- Only the /data partition and all stuff in there will be protected (only the sdcard is protected if it's non-removable)
- The attacker boot to recovery and factory reset the device.
- If your phone is rooted and booted up, they'll use adb to copy your unencrypted data (e.g. sdcard). If it's not booted, they're stuck.
- The attack can use a download mode from there they flash a custom recovery or custom kernel (rooted) image. Most custom recovery's allows root adb which is needed to bypass the lockscreen.
- The attacker can simply use some software holes to bypass the pin and of course several known tools to crack the image master password.
- Military-grade encryption just doesn’t matter if an attacker has access to the key already.
- Nobody use a strong password (eg 20 chars) since you can't use a hardware token + the fact it's too long to type on the phone (and this each time).
- Android just required you to use a strong password/passphrase when starting up the device, but for some absurd reason they also require that you use the same password as your screen lock password
So, properly implemented encryption (and Android Lollipop provides for that) does not visibly slow down the device and can make it impossible for spooks to break. .
Click to expand...
Click to collapse
Yes and no, you right if you say the stuff about the implementation but overall encryption always takes performance for e.g. if you use AES 256 encryption anything that needs to decrypt constantly during the read and write process will causes performance impacts examples are give over here and here. But AES is most common used which is already "optimized".
The conclusion is that the performance of your device will take a slight hit if you enable encryption (dependency which hardware you use and which encryption algo was used + possible bugs/implementation problems) but to fight with this only for a technique that will be cracked it the near feature is really not worth to use or recommend if you asking me. It's more like a placebo, nothing is really secure as long the user is to lazy to use a very strong passcode/password

CHEF-KOCH said:
But Android is not a Computer which is on the same place all the time which means that it is a lot of easier to get physical access to it. That means an attacker have all the time to crack it, which in fact is only a matter of time. With or without additional protection mechanism - it will be cracked soon or later, and if you asking me it's not worth to use FDE on a mobile device, it coasts performance (as said for nothing).
The focus should be to protect data, correct but these kind of protection not protect against usage data stealing if most aps need internet connection which never use any secure way to send and receive data - So the risk here is much higher that a attacker can collect all necassary data if your phone is unlocked and a app xyz is running in the background which logs all stuff, such as Pin, passwords for website logins or whatever.
It's very easy breakable there a several tools out there, exploits and poc's - and why need to crack something if you better steal data that are necessary over internet? Which tactic is easier - sure the last. Yes, lollipop is the first secure os, but not all people use it right now or the oem rolls out the update for every device. But I generally agree in the aspect that lollipop fix most stuff which are vulnerable compared to Android 4.x.
There are several attacks which affects all Android versions even latest lollipop:
- First, the encryption doesn't help much if you haven't set a passcode!
- Limitations in lollipops encryption explained over here
- Only the /data partition and all stuff in there will be protected (only the sdcard is protected if it's non-removable)
- The attacker boot to recovery and factory reset the device.
- If your phone is rooted and booted up, they'll use adb to copy your unencrypted data (e.g. sdcard). If it's not booted, they're stuck.
- The attack can use a download mode from there they flash a custom recovery or custom kernel (rooted) image. Most custom recovery's allows root adb which is needed to bypass the lockscreen.
- The attacker can simply use some software holes to bypass the pin and of course several known tools to crack the image master password.
- Military-grade encryption just doesn’t matter if an attacker has access to the key already.
- Nobody use a strong password (eg 20 chars) since you can't use a hardware token + the fact it's too long to type on the phone (and this each time).
- Android just required you to use a strong password/passphrase when starting up the device, but for some absurd reason they also require that you use the same password as your screen lock password
Yes and no, you right if you say the stuff about the implementation but overall encryption always takes performance for e.g. if you use AES 256 encryption anything that needs to decrypt constantly during the read and write process will causes performance impacts examples are give over here and here. But AES is most common used which is already "optimized".
The conclusion is that the performance of your device will take a slight hit if you enable encryption (dependency which hardware you use and which encryption algo was used + possible bugs/implementation problems) but to fight with this only for a technique that will be cracked it the near feature is really not worth to use or recommend if you asking me. It's more like a placebo, nothing is really secure as long the user is to lazy to use a very strong passcode/password
Click to expand...
Click to collapse
I agree with you regarding weaknesses, but they all are rellated to improperly implemented encryption or user's misunderstanding. You have acknowledged that if the phone is off "they are stuck." That's what I call properly implemented encryption, and no tool can help including their super fast computers. By the way, if they do it on the device, in lollipop, data will be erased after 10 attempts, not to mention that there is a slowdown mechanism to prevent brutforce. Stealing online: yes, this is true, but again, it is possible to restrict any app from contacting the internet (afwall that was recently updated for lollipop and Xprivacy). On my phone, only web browser, mail client and sip client (all non google) have access to the internet; and since I have no Gapps, there is no "phoning home" Google's servers. Performance: it is true that encryption degrades performance somewhat, but again, if it is properly implemented, human's eye wouldn't notice. By the way, I think the reason Google is back pedalling on default encryption is that they have realized they really created something that is difficult to crack. Hence, they'll "modify" it soon to help their sponsoring spooks.
"Nobody use a strong password (eg 20 chars) " I use a boot pass phrase that has over 60 characters. This one was used for encryption, as opposed to a screen pin. You can only do it via adb shell.... Again, it is all about implementation. And by the way, most of the time I use soft reboot, which does not require me to use the long phrase at all.
A lot of people over-estimate spook's abilities. Despite the recent revelations: they can't do magic, meaning breaking encryption and they know it. That's why they are colluding with everyting that "moves" to put backdoors, weaken number generation, force weaker ciphers and so on.

May I ask you if using an xposed module is a risk for the whole system itself? It shouldn't be too hard to abuse it and to bypass xprivacy itself and the Android firewall.

Funny stuff, you not use gapps but you trust goggles encryption even if they already worked together in the past with GCHQ/NSA ...
Stealing online: yes, this is true, but again, it is possible to restrict any app from contacting the internet (afwall that was recently updated for lollipop and Xprivacy)
Click to expand...
Click to collapse
Again apps are not the first line of defense, they are the last. Xprivacy can't protect/or fake mac address, ID's or your imei/phone number (please read the whole FAQ) and on Lollipop there are a lot of more restrictions generally and they are not all implemented yet.
Since Xprivacy needs root (or should I say the Xposed framework) this is also a possible security risk, the attacker can use adb (which can be rescricted by an app) to disable/uninstall/freeze XPrivacy or any other app even if you use them as admin (the app will once crash and not restart).
...and no tool can help including their super fast computers
... data will be erased after 10 attempts
Click to expand...
Click to collapse
Erased? Are you sure? I don't think so I guess the os will just shutdown but to erase something would be horrible.
On my phone, only web browser, mail client and sip client (all non google) have access to the internet; and since I have no Gapps, there is no "phoning home" Google's servers.
Click to expand...
Click to collapse
Yes, and this is a mistake here in this thread, people forgett that most users are not experts, they not even know about XPrivacy/AFWall+ or root. The benefit of encryption should that all people even without bigger knowledge can handle it without disadvantages or other hints. So that already failed, google now reverted there own statement which means the encryption will not default enabled for all (see my links for there statement: In short - OEM complaining about performance!).
So security isn't activated from the beginning which is also a possible risk.
Performance: it is true that encryption degrades performance somewhat, but again, if it is properly implemented, human's eye wouldn't notice.
Click to expand...
Click to collapse
No it's not and you not understand it the I/O performance is slower, that can be a little bit different from device to device (due other hardware) but it's definitely noticeable (and not only in benchmarks) - please read the links. Not every use high end devices, never forget it -> again security should be available for all and the fact google reverted it clearly shows that we are not ready yet.
By the way, I think the reason Google is back pedalling on default encryption is that they have realized they really created something that is difficult to crack. Hence, they'll "modify" it soon to help their sponsoring spooks.
Click to expand...
Click to collapse
It's a matter of time anyone found a solution, the only thing we can do is to upgrade the OS to fix the possible holes asap - but that won't protect anyone who not update direct after each new release. And oem's usally needs aslo time to update there stuff, if they not already gave up due the massive fragmentation.
I use a boot pass phrase that has over 60 characters. This one was used for encryption, as opposed to a screen pin. You can only do it via adb shell.... Again, it is all about implementation.
Click to expand...
Click to collapse
Yes and because of implementation there are always security holes, possible risk and negative side-effects and because of this there will always a way to crack thinks as long if you're rooted.
And again because you use that it not means the mass use this - I'm not the only one who complains about that several known security experts and on several sites a lot of people saying that the length of the password is always a problem. Sure there are a lot of tools, but in our case they only works after a login and again ... mostly only experts using them.
A lot of people over-estimate spook's abilities. Despite the recent revelations: they can't do magic, meaning breaking encryption and they know it. That's why they are colluding with everyting that "moves" to put backdoors, weaken number generation, force weaker ciphers and so on.
Click to expand...
Click to collapse
Maybe, maybe not. Maybe NSA already have the ability to crack it with some exploits, maybe not - but we can bet on it they are working on it right know we talking about it. But why holidng on stuff that is placebo? There are already problems which can't be denied.
So we are now a bit off-topic, but if you believe the myth that it can't be bypassed you must be naive it was done in the past and it will be soon or later with lollipop with tools every script kiddy can use (like on 4.x). That's not what I call implementation related, it's also not encryption related it's the fact that as long users can side-load stuff or execute root it's only a matter of time - that was and ever will a possible security risk (not only on Android).

pikatchu said:
May I ask you if using an xposed module is a risk for the whole system itself? It shouldn't be too hard to abuse it and to bypass xprivacy itself and the Android firewall.
Click to expand...
Click to collapse
Don't use any xposed module that is not open source
Use Afwall built in iptables binaries, as opposed to system ones or better move builtin iptables into your system
Prevent any xposed module including xprivacy and xposed framework from internet access
---------- Post added at 04:39 PM ---------- Previous post was at 03:50 PM ----------
CHEF-KOCH said:
Funny stuff, you not use gapps but you trust goggles encryption even if they already worked together in the past with GCHQ/NSA ...
Again apps are not the first line of defense, they are the last. Xprivacy can't protect/or fake mac address, ID's or your imei/phone number (please read the whole FAQ) and on Lollipop there are a lot of more restrictions generally and they are not all implemented yet.
Since Xprivacy needs root (or should I say the Xposed framework) this is also a possible security risk, the attacker can use adb (which can be rescricted by an app) to disable/uninstall/freeze XPrivacy or any other app even if you use them as admin (the app will once crash and not restart).
Erased? Are you sure? I don't think so I guess the os will just shutdown but to erase something would be horrible.
Yes, and this is a mistake here in this thread, people forgett that most users are not experts, they not even know about XPrivacy/AFWall+ or root. The benefit of encryption should that all people even without bigger knowledge can handle it without disadvantages or other hints. So that already failed, google now reverted there own statement which means the encryption will not default enabled for all (see my links for there statement: In short - OEM complaining about performance!).
So security isn't activated from the beginning which is also a possible risk.
No it's not and you not understand it the I/O performance is slower, that can be a little bit different from device to device (due other hardware) but it's definitely noticeable (and not only in benchmarks) - please read the links. Not every use high end devices, never forget it -> again security should be available for all and the fact google reverted it clearly shows that we are not ready yet.
It's a matter of time anyone found a solution, the only thing we can do is to upgrade the OS to fix the possible holes asap - but that won't protect anyone who not update direct after each new release. And oem's usally needs aslo time to update there stuff, if they not already gave up due the massive fragmentation.
Yes and because of implementation there are always security holes, possible risk and negative side-effects and because of this there will always a way to crack thinks as long if you're rooted.
And again because you use that it not means the mass use this - I'm not the only one who complains about that several known security experts and on several sites a lot of people saying that the length of the password is always a problem. Sure there are a lot of tools, but in our case they only works after a login and again ... mostly only experts using them.
Maybe, maybe not. Maybe NSA already have the ability to crack it with some exploits, maybe not - but we can bet on it they are working on it right know we talking about it. But why holidng on stuff that is placebo? There are already problems which can't be denied.
So we are now a bit off-topic, but if you believe the myth that it can't be bypassed you must be naive it was done in the past and it will be soon or later with lollipop with tools every script kiddy can use (like on 4.x). That's not what I call implementation related, it's also not encryption related it's the fact that as long users can side-load stuff or execute root it's only a matter of time - that was and ever will a possible security risk (not only on Android).
Click to expand...
Click to collapse
GAPPS vs. Google encryption: I can't examine or modify GAPPS, but I can Google encryption, which is open source
Xposed modules: Xposed framework needs root once only during installation. After that you can revoke root permission
Attacker use of ADB: no matter what attacker does, he can't mount Data. Even on a live device, if pings are disabled, as well as all incoming connections, there is no way to reach the system over the internet. Now, I am not talking about baseband or simcard exploits, but if you face that kind of an attacker, then you don't use cell phones at all. The point stands: if your phone is off and it is properly encrypted, there is virtually no way to get the data. And I say virtually only because of baseband/simcard exploits.
Erasing data: If you look at lollipop's /system/vold/cryptfs.c and .h, you will see that erasing data is implemented after 10 unsuccessful attempts (the number could be reduced).
Low end devices vs. high end; regular user vs. advanced: you can't have a product that will satisfy all. You can't lower safety standards to satisfy the low end regular user. 2015 Mercedes is safer on the road than 1976 Honda. If you have advanced knowledge, you'll benefit more than a regular user. And if that user refuses to help himself, he will have to face the consequences.. That's the way Linux (and Android is its ugly daughter) is built...

GAPPS vs. Google encryption: I can't examine or modify GAPPS, but I can Google encryption, which is open source
Click to expand...
Click to collapse
Open source isn't a guarantee for security. I'm tired to saying this over and over again here on xda and in other forums. And no, it's not open source since most devices comes with own stock android builds which may use other hardware/drivers and maybe other or touched encryptions. There is also no guarntee that it hold what it promise as long nobody can proof or deny it.
Xposed modules: Xposed framework needs root once only during installation. After that you can revoke root permission
Click to expand...
Click to collapse
Once is more than enough, to get infected by faked Xposed Installers or other possible attacks. You scenarios are very unrealistic, nobody only use root only for one single module - You can't tell me that. Attackers don't need to mount data if you installed apps on external sdcard which isn't encrypted.
as well as all incoming connections, there is no way to reach the system over the internet.
Click to expand...
Click to collapse
Incoming connections are not necessary, outgoing is more important to send data to a eg. C&C.
The point stands: if your phone is off and it is properly encrypted, there is virtually no way to get the data. And I say virtually only because of baseband/simcard exploits.
Click to expand...
Click to collapse
Sure but it's unrealistic too, I will use the phone and not use encryption which can be attacked or bypassed except the phone is offline.
Erasing data: If you look at lollipop's /system/vold/cryptfs.c and .h, you will see that erasing data is implemented after 10 unsuccessful attempts (the number could be reduced).
Click to expand...
Click to collapse
Please give me the source, thanks. According to this normal userdata not getting any wipe on encryption fail and on other systems then EXT4 or F2FS nothing will be done (no access). And as long /data is not mounted there is also no access, that's the reason android temporary mount /data each time to promt for passwords, other processes and such (for more look in the documents)
I didn't know that but nvm it's unimportant since the master key is still on the device itself - which will definitely not erased and as said it not protect against privacy data stealing which is more important, nobody want you android files, only you passwords etc ...
Use Afwall built in iptables binaries
Click to expand...
Click to collapse
Iptables are not installed on every system and not working anymore since Android 5 need some extra flags like -pie and to replace the system own or installing them needs root too - oh, and to fix possible startup data leaks also needs root for init.d.
Low end devices vs. high end; regular user vs. advanced: you can't have a product that will satisfy all.
Click to expand...
Click to collapse
I'm not saying other stuff but you are the one which said that the performance impact is minimal and I'm the one which said encryption should work out of the box for all on any device - sure it's definitly an implementation thing, but as a workaround older devices may just simple lower the encryption e.g. 256 -> 128 Bit.
You can't lower safety standards to satisfy the low end regular user. 2015 Mercedes is safer on the road than 1976 Honda. If you have advanced knowledge, you'll benefit more than a clueless user who refuses to help himself....
Click to expand...
Click to collapse
I'm not comparing cars I only compare the encryption algos which haven't much changed over the years (just some fixes here and there but under the hood the car still needs 4 wheels).
We talked about encryption and possible attacks and you still can't deny them all. You try to find some excuses but under the line it will be cracked - and not in 10 years, this or next year I promise because of this reasons:
- Cracking the pins normally takes only seconds: they are simply to short or follow patterns due to being the same as the lock screen password. Practically speaking, the security of this entire story depends on the passphrase the user sets. If it is very long, it makes brute forcing difficult. But most people would set a 4/6/8 digit PIN, because who would want to enter a 20 digit password with alphabets and special characters every time you want to make a call or send a message?!
- Cracking Encryption in general -> Encrypted Master Key + Salt stored in footer and they are usually stored at the end of the partition or in a footer file on other partitions
- OEM's may use a different key management module
- Some forensic boot images are available which makes it possible to start early in the boot chain before the whole system loads ->
- Keyloggers or memory catcher allowing the attacker to capture unencrypted data -> including encryption keys and passwords for non encrypted content
- If the device is already compromised with malware it will be possible send things into the internet
- Some root kits already breaking most of all hard disk encryption such as the "Stoned" bootkit on TrueCrypt
- A factory reset also resets the master key

optimumpro said:
I have enabled 256 bit encryption; I have increased the length of various keys, as well as the number of iterations for random number generation; then I have disabled in kernel hardware based weakened random number generator and enabled all other methods inactive by default (thanks to google and sony for making it easier to break for spooks); I then disabled hardware overlay option, which causes slow down, so, now, there is no visible difference in performance with unencrypted device.
Click to expand...
Click to collapse
You already mentioned some of these things over at unclefab's "How To Secure Your Phone"-thread. Any chance to get some more detailed steps or even diffs of your changes?
Thanks!

CHEF-KOCH said:
Open source isn't a guarantee for security. I'm tired to saying this over and over again here on xda and in other forums. And no, it's not open source since most devices comes with own stock android builds which may use other hardware/drivers and maybe other or touched encryptions. There is also no guarntee that it hold what it promise as long nobody can proof or deny it.
Once is more than enough, to get infected by faked Xposed Installers or other possible attacks. You scenarios are very unrealistic, nobody only use root only for one single module - You can't tell me that. Attackers don't need to mount data if you installed apps on external sdcard which isn't encrypted.
Incoming connections are not necessary, outgoing is more important to send data to a eg. C&C.
Sure but it's unrealistic too, I will use the phone and not use encryption which can be attacked or bypassed except the phone is offline.
Please give me the source, thanks. According to this normal userdata not getting any wipe on encryption fail and on other systems then EXT4 or F2FS nothing will be done (no access). And as long /data is not mounted there is also no access, that's the reason android temporary mount /data each time to promt for passwords, other processes and such (for more look in the documents)
I didn't know that but nvm it's unimportant since the master key is still on the device itself - which will definitely not erased and as said it not protect against privacy data stealing which is more important, nobody want you android files, only you passwords etc ...
Iptables are not installed on every system and not working anymore since Android 5 need some extra flags like -pie and to replace the system own or installing them needs root too - oh, and to fix possible startup data leaks also needs root for init.d.
I'm not saying other stuff but you are the one which said that the performance impact is minimal and I'm the one which said encryption should work out of the box for all on any device - sure it's definitly an implementation thing, but as a workaround older devices may just simple lower the encryption e.g. 256 -> 128 Bit.
I'm not comparing cars I only compare the encryption algos which haven't much changed over the years (just some fixes here and there but under the hood the car still needs 4 wheels).
We talked about encryption and possible attacks and you still can't deny them all. You try to find some excuses but under the line it will be cracked - and not in 10 years, this or next year I promise because of this reasons:
- Cracking the pins normally takes only seconds: they are simply to short or follow patterns due to being the same as the lock screen password. Practically speaking, the security of this entire story depends on the passphrase the user sets. If it is very long, it makes brute forcing difficult. But most people would set a 4/6/8 digit PIN, because who would want to enter a 20 digit password with alphabets and special characters every time you want to make a call or send a message?!
- Cracking Encryption in general -> Encrypted Master Key + Salt stored in footer and they are usually stored at the end of the partition or in a footer file on other partitions
- OEM's may use a different key management module
- Some forensic boot images are available which makes it possible to start early in the boot chain before the whole system loads ->
- Keyloggers or memory catcher allowing the attacker to capture unencrypted data -> including encryption keys and passwords for non encrypted content
- If the device is already compromised with malware it will be possible send things into the internet
- Some root kits already breaking most of all hard disk encryption such as the "Stoned" bootkit on TrueCrypt
- A factory reset also resets the master key
Click to expand...
Click to collapse
Wipe after 10 attempts, see here https://github.com/CyanogenMod/android_device_qcom_common/blob/cm-12.0/cryptfs_hw/cryptfs_hw.c
A factory reset wipes data, so whatever happens to master key is not significant. But even if the master key is reset, there is no use of it in terms of trying to get previously encrypted data. And by the way, the term reset is not correct: if you do a regular reset, the master key is not touched, as it is not sitting on data partition and if you wipe system and data, your master key is gone and the new one will be generated only when you enable encryption again.
I don't understand your consistent point that users won't bother with long passwords, when Android provides for separate passwords one for boot/encrption and another for screen (which is not used for encryption). As I have already said, I use an over 60 character boot password and a short screen pin. If I need to reboot the device, I use soft reboot, which does not require the password at all. So, having a long password does not create any undue burden.
Again, data/disk encryption is valuable, because it protects your device when it is off, meaning, no one can access your data... I have close to personal experience with "sophisticated attackers": they can do nothing with properly encrypted device that is turned off...
Closed source vs. open source. I am not saying open source is secure. I am saying that open source could be examined unlike proprietary one.

My last words on this:
Well in the source nothing to user data gets wiped, only stuff that protects android system related files which proofs that the user data aren't safe if someone use forensic image and cloned everything.
Short screen pins can be cracked in minutes so as long we can sideloading anything before or after a boot especially if not all stuff is mounted it is still a risk.
Fastboot/softboot or whatever you want to call it isn't available on every device so you whole argumentation about complex passwords are useless (for example a friend of mine recently got the LG G3 which had fastboot deactivated). And of course if you got an error like kernel panic or other crash you can't fast reboot which also required that complicated and complex password - especially on mobile devices this is pretty annoying.
Again FDE on Android is placebo that's all, as long the user can dump the whole system and crack it on a PC which is powerful enouth it will be always useless. Apple use a unique key (if we can believe it) which can't be extracted with any tool or read out during the boot (maybe some day but I don't know any tool yet) so everything like brute force must be directly on the device which takes a lot of more time compared to a computer with an external powerful nvidia card and tools like hashkill/hashcat.
About explaining closed source, if you are good enouth you can reverse engineering most of the code - you don't even need to deobfuscate all stuff but in most time if you know the basics you know which weakness e.g. the encryption may have.
As long you not understand that sideloading is the biggest problem in android you not understand that all can be cracked soon or later and because you use xyz do not means that millions of stock users doing such complicated steps too to "secure" the phone which do not protect all stuff except the os itself. Android has defenses yes, but it is more to protect itself and not the private data that's the conclusion. It's a good step what was made with lollipop but there are still attacks which can't be that easily blocked, especially if the user doesn't know how or most if the mechanism are deactivated or simply to complex.

CHEF-KOCH said:
My last words on this:
Well in the source nothing to user data gets wiped, only stuff that protects android system related files which proofs that the user data aren't safe if someone use forensic image and cloned everything.
Short screen pins can be cracked in minutes so as long we can sideloading anything before or after a boot especially if not all stuff is mounted it is still a risk.
Fastboot/softboot or whatever you want to call it isn't available on every device so you whole argumentation about complex passwords are useless (for example a friend of mine recently got the LG G3 which had fastboot deactivated). And of course if you got an error like kernel panic or other crash you can't fast reboot which also required that complicated and complex password - especially on mobile devices this is pretty annoying.
Again FDE on Android is placebo that's all, as long the user can dump the whole system and crack it on a PC which is powerful enouth it will be always useless. Apple use a unique key (if we can believe it) which can't be extracted with any tool or read out during the boot (maybe some day but I don't know any tool yet) so everything like brute force must be directly on the device which takes a lot of more time compared to a computer with an external powerful nvidia card and tools like hashkill/hashcat.
About explaining closed source, if you are good enouth you can reverse engineering most of the code - you don't even need to deobfuscate all stuff but in most time if you know the basics you know which weakness e.g. the encryption may have.
As long you not understand that sideloading is the biggest problem in android you not understand that all can be cracked soon or later and because you use xyz do not means that millions of stock users doing such complicated steps too to "secure" the phone which do not protect all stuff except the os itself. Android has defenses yes, but it is more to protect itself and not the private data that's the conclusion. It's a good step what was made with lollipop but there are still attacks which can't be that easily blocked, especially if the user doesn't know how or most if the mechanism are deactivated or simply to complex.
Click to expand...
Click to collapse
And here are my last words. Click the link in the previous post and you will see code to wipe user data. There is annotation that says we will wipe everything related to encryption followed by the code itself that contains the words "wipe user data":
} else {
if(ERR_MAX_PASSWORD_ATTEMPTS == err)
wipe_userdata();
With regard to cracking everything soon, this is just your opinion that is not based on known facts. And one of the facts is that if spooks could break the encryption, they wouldn't need back doors and weakening.
Again, I fail to understand your point about users not using long screen passwords. You don't need long ones for your screen. But let's leave it there and agree to disagree.

bastei said:
You already mentioned some of these things over at unclefab's "How To Secure Your Phone"-thread. Any chance to get some more detailed steps or even diffs of your changes?
Thanks!
Click to expand...
Click to collapse
Look here for kernel changes:
https://github.com/AOSP-Argon/android_kernel_sony_msm8974/commit/29d918c1f11247602c58096a62084811bccc328f

// When device comes up or when user tries to change the password, user can
// try wrong password upto a certain number of times. If user enters wrong
// password further, HW would wipe all disk encryption related crypto data
// and would return an error ERR_MAX_PASSWORD_ATTEMPTS to VOLD. VOLD would
// wipe userdata partition once this error is received.
#define ERR_MAX_PASSWORD_ATTEMPTS -10
#define QSEECOM_DISK_ENCRYPTION 1
#define MAX_PASSWORD_LEN 32
Click to expand...
Click to collapse
It won't touch userdata at all, it wipes only (as written) disk encryption related data stuff but I'm talking about sideloading user data and this will never be wiped since this will destroy other stuff too - so this prevents only some attacks if you just start you're phone. - Or if you dump the data without - in a locked state - the master key.
The stuff you linked is also different from my link from AOSP project since it's CM, also a mistake, because CM isn't stock or based on OEM's firmware. So all you're stuff may applies only to custom firmwares - I'm talking again about stuff which use the mass and not only certain "expert" people.
Look here for kernel changes:
Click to expand...
Click to collapse
This is also from CyanogenMod which also only affects /cache/recovery which doesn't matter if the system was already booted success and (as shown) some stuff was already compromised or running in the background.
With regard to cracking everything soon, this is just your opinion that is not based on known facts. And one of the facts is that if spooks could break the encryption, they wouldn't need back doors and weakening.
Click to expand...
Click to collapse
Yes and your wrong opinion is that it isn't crackable, same was said years ago about TrueCrypt which now is labeled as unsafe and I already mentioned tools which break it.
Seems you're to ignorant to understand which possible negative effects may comes with side-loading. As long you not understand this we can stop the entire discussion here (I already gave up because you don't know s much as I do which tools can break stuff) - it will be cracked and the the dm-crypt stuff was already cracked in Android 4. because of some fixes that doesn't mean anything. Again, because you use xyz that doesn't mean all use the same stuff you already ignored this several times now and I already said that - but okay.

CHEF-KOCH said:
It won't touch userdata at all, it wipes only (as written) disk encryption related data stuff but I'm talking about sideloading user data and this will never be wiped since this will destroy other stuff too - so this prevents only some attacks if you just start you're phone. - Or if you dump the data without - in a locked state - the master key.
The stuff you linked is also different from my link from AOSP project since it's CM, also a mistake, because CM isn't stock or based on OEM's firmware. So all you're stuff may applies only to custom firmwares - I'm talking again about stuff which use the mass and not only certain "expert" people.
This is also from CyanogenMod which also only affects /cache/recovery which doesn't matter if the system was already booted success and (as shown) some stuff was already compromised or running in the background.
Yes and your wrong opinion is that it isn't crackable, same was said years ago about TrueCrypt which now is labeled as unsafe and I already mentioned tools which break it.
Seems you're to ignorant to understand which possible negative effects may comes with side-loading. As long you not understand this we can stop the entire discussion here (I already gave up because you don't know s much as I do which tools can break stuff) - it will be cracked and the the dm-crypt stuff was already cracked in Android 4. because of some fixes that doesn't mean anything. Again, because you use xyz that doesn't mean all use the same stuff you already ignored this several times now and I already said that - but okay.
Click to expand...
Click to collapse
I guess we speak different languages. My point is (and it stands) that if encryption is properly implemented, there is no way to get data from unmounted encrypted partition. Let's forget about wiping, any sophisticated attacker will take an image of the device and then try to break a copy. However, to mount data, he will have to bruteforce my 60 character password that will unlock master key or break 256 bit AES. Good luck on either front. And I am not talking about stock, aosp or Cm roms. It makes no difference, the bottom line is he won't be able to do either of the above. I also don't care about careless users. They have a right to be ignorant and most enjoy it very much. Linux (on which Android is based) was not created for ignorant users...

Marshmallow & Nougat (AOSP/CM/Lineage) for Nook HD/HD+ (& Tablet)

This thread, and Marshmallow/Nougat porting in general, are a continuation of the previous KitKat and Lollipop development; the general installation steps are more or less the same. If you need a very detailed guide, PeteInSequim's is a good resource, especially if moving from stock. Read/search through the previous threads for any missing information (CM12.1 OP). That being said, I'm uploading personal builds of AOSP 6.0/7.1, CM 13.0/14.1, TWRP, etc, here.
Some of the important device-specific changes from KitKat/CM11 are described in Hashcode's thread. The goal is to remain fairly close to CM or AOSP upstream, and integrate whatever fixes and enhancements in unified device trees. More progress information will be added here gradually, as I have time. A lot of useful discussion happened on the previous CM11, CM12.[01] threads, and the status of things is available to anyone willing to search. I am not a developer, mostly a hobbyist, and the usual disclaimers apply.
AOSP vs CM
Initially, AOSP builds happened out of curiosity, but also necessity, since CM13 needs some time to stabilize. As expected, an AOSP ROM is a lot more barebones than CM, and there are pros and cons for each flavor. Now that initial porting is done following the previous philosophy of reusing and common-izing the device trees, it seems feasible to maintain both AOSP and CM ROMs (whenever 13 is usable), although nothing is promised.
In truth, the current builds are more accurately described as AOSP-ish; at the very least, a few core components need to be modified for our HALs, proprietary blobs, etc. On top of that, I've been adding features and fixes that seemed essential to me. Still, major differences remain compared to CM, and before people deem them as bugs, here are a few:
Wake with Home button: not an AOSP feature; I took the CM code to make it work in these builds.
The Advanced reboot menu: also a custom feature; may be ported at some point.
Mounting exFAT or NTFS media: not AOSP-supported filesystems, but a priority for me.
BusyBox was a CM extra, but I'm including it starting with the November 8th builds.
Etc, etc.
Because we have a reasonably flexible build system, other ROM flavors could happen in the future. A custom ROM like CM is actually easier to maintain than AOSP given all the fixes and enhancements that need separate maintenance with the latter.
The major difference with the first November builds is having SELinux enabled (albeit Permissive). It had to be kept completely disabled during the initial porting, due to a kernel bug/missing feature that took more than a week to track down. Thus, logs contain lots of AVC denials now, as sepolicy has not been fully updated for MM; no need to report or worry about these yet.
On a personal note, posting on my threads is pretty tricky business... My builds were never intended for general consumption, but rather a way to move porting and development forward, and I often debate only keeping the GitHub repositories for people to build themselves. Obviously, that would upset hundreds of people at this point, so I make an effort to upload reasonably bug-free builds, as well as help even with trivial non-problems whenever I can. Nevertheless, low quality, or badly written posts (and I don't mean bad English) are a sure way to get ignored, and my memory is pretty long term Basically, I won't police content here, but I also don't want to deal with the the kind of stupidity and entitlement so prevalent in real life.
In conclusion, no need to thank (unless you really want to), or ask about donating, etc, but do reassess the limits of your current understanding before making bold claims, as I do too. Nothing worse than having to fix a trail of misinformation... Also, comparisons to other people's work (unless constructive), complains about the state of things, or simply starting with "no offense" and such, will make your problem much less likely to be solved by me.
XDA:DevDB Information
AOSP 6.0/7.1; CM 13.0/14.1, ROM for the Barnes & Noble Nook HD, HD
Contributors
amaces, Hashcode, verygreen
Source Code: https://github.com/airend/android
ROM OS Version: 7.x Nougat
ROM Kernel: Linux 3.0.x
Version Information
Status: Nightly
Created 2015-11-02
Last Updated 2018-07-29

GApps & Partitioning Info
With unusual issues, especially if connected to Play Services, I recommend testing the ROMs without GApps before reporting bugs.
Currently, pico Open GApps should work on all AOSP, CM, or Lineage builds (M & N), although initial flashing should to be done before first boot (wiped data). With CM/Lineage 14, system space is barely enough, yet I still think we're fine with the current partitioning scheme. Changing it can introduce other complications, and haven't found an absolute reason for doing so. Nevertheless, it is possible to alter the partition sizes after installation, and thus increase available system space; @Lanchon prepared a pretty nice guide specifically for the Nook HDs.
About including GApps directly into the ROMs, I had tested this approach using the Open GApps manifests. While things can work better that way, legally, it wouldn't be a good idea to distribute these builds (for the same reasons CM had to stop including them). Also, I think there are a few people who wan't nothing to do with Google's proprietary services, so a likely deal breaker for them. We'll have to wait for the established packagers to decide how to deal with the MM changes, although my manifests are available, and one can include anything in personal builds.
Manifests & GitHub Branches
For people making their own builds, the customized manifests including my forked branches, and other changes, are kept more or less up to date at github.com/airend/android. There are currently three main branch pairs: cm-12/lolli, cm-13/marsh, and cm-14/nougat, the latter two being most updated. As the name implies, these manifests are based (and actually constantly rebased) on the corresponding upstream branch, either AOSP or CM/Lineage. Theoretically, once these manifests are stable, there is no need for local additions, but corrections might be needed nonetheless.
No need to repo init more than once, unless you're switching manifest branches (e.g., LP to MM, CM to AOSP, etc); repo sync will pull all manifest changes.
About naming conventions for my branches, I try to reuse as much as possible between CM/Lineage and AOSP, and when that's possible, branches are named lp-12, mm-13, etc. Otherwise, branches are named lolli, marsh, nougat, or cm-1*, depending on their base and specificity.
Upstream Lineage branch names haven't changed from old CM, and no current branch will be renamed here either (despite rebase).
The kernel repo contains additional feature branches named base/[subsystem], on top of Hashcode's last CM12.0 kernel. The main stable kernel is roughly equivalent to merging all these feature branches, although the history is different.
Recovery Information
We do have official TWRP images (https://twrp.me/Devices). While they don't work with CM12.1 anymore (for reasons described in that thread), they should be usable with all current Marshmallow builds.
More up to date eMMC TWRP images are included in the respective device folders. Personally, I've had a good experience with TWRP, and do not plan on looking at other recovery distributions. Now, there have been (very) sporadic reports of broken partition tables, soft-bricked devices, etc, blamed on recovery. Although recovery is usually not the actual culprit, here are some ways you can rescue a completely unresponsive device:
The instructions below are generic, and were meant for CWM. TWRP has all these image flashing features in the GUI, so CLI/shell is not strictly needed.
It's a good idea to keep a microSD card around, with my external recovery image, or verygreen's.
Once booted off the external recovery, you can easily fix whatever is broken (ADB is your friend here). There's no need to re-install CM11, as re-flashing recovery and/or boot will most likely fix your issue.
Recovery partition: dd if=<path to recovery image> of=/dev/block/platform/omap/omap_hsmmc.1/by-name/recovery
Boot partition: dd if=<path to boot/kernel image> of=/dev/block/platform/omap/omap_hsmmc.1/by-name/boot
Afterwards, you should at the very least have a working internal recovery. I don't recall any instance where /system and/or /data became corrupted because of recovery, but you can certainly fix them now.
I've never tested this part, but I believe that you may be able to install an eMMC CM12 ZIP with verygreen's external CWM, even if /data and /cache are F2FS (assuming you copied all ZIPs onto the external card). My understanding is that only /dev/block/platform/omap/omap_hsmmc.1/by-name/system (always ext4, mountable by any recovery) is touched during installation, so you may even bypass TWRP completely.
P.S. If you broke you bootloader by flashing the wrong recovery flavor, despite all images being clearly labeled as hummingbird or ovation, well, no sympathy for you… Still, you can bring your device back to life within minutes as described above.

Selected FAQs
Should I use AOSP or CM/Lineage?
Depends entirely upon personal preference, which requires testing, and some amount of research into what makes a ROM different. There are substantial core differences between the two flavors, which are not obvious immediately. If installing for the first time, flip a coin (and avoid builds in experimental, of course).
How do I get root back?
Until recently, some type of SU binary was included with all ROMs (WITH_SU=true on CM/Lineage, or using this repo on AOSP). This was needed because third-party system-less solutions don't work with our quirky bootimages, and system-mode installers have other issues on N. As builds mature, I'm separating the SU backend from main OTAs, roughly like CM/Lineage did. On my Nougat builds, there are currently two system-mode options:
On AOSP, I adapted phh's OSS backend for system-mode install (addonsu-phh-arm.zip). You need the matching manager to control access. Later on, I ported CM/Lineage's AppOps-based SU to AOSP, so that addon works here as well (see next item). These binaries need to be flashed after every ROM update, same as GApps.
On CM/Lineage, you can install their official add-on (addonsu-arm-signed.zip); it will use the baked-in manager, so no extra APK required. Or, you can install phh's SU and manager, like on AOSP. Neither needs to be flashed more than once here given the existing addon.d support.
Why no official CM/Lineage builds since 12.0?
The answer involves both technical complications, and some amount of politics. Getting changes accepted for non-mainstream/deprecated platforms like ours has been an uphill battle. Over time, many OMAP4 improvements have been developed outside CM, formerly by OMAP4-AOSP, now the Unlegacy-Android project. Those common hardware improvements have made it into 13.0/14.1 only recently, due to other people's perseverance. Although we're much closer to upstream Lineage compatibility, the hundreds of device tree, and more than a thousand kernel changes would still need to go through review. Given how long that takes for each item, and occasional opposition from non-OMAP4 reviewers, I decided to allocate my resources towards bettering these devices rather than official status. The downside is that people may feel dependent on my builds, which shouldn't be the case; I constantly rebase and maintain complete manifests, optimized for these devices. All the relevant changes are open and available in public GitHub repositories, which means anyone can submit them/try to work with upstream Lineage. However, for the above reasons, it's unlikely that I will make that effort.
What's the current status of full screen casting, Miracast, HDMI, etc?
Full screen casting to a Chromecast sink (either real, or emulated) works on all current Nougat builds. CM13 builds may have issues there, but AOSP M was fixes. Chrome casting from apps (the preferred way, if available) was never broken. Miracast in AOSP is pretty much legacy tech now. It also requires more hardware support compared to Chromecast-ing, and it probably doesn't work on any recent builds. Fixing HDMI is still a goal; it got broken on our devices after some Marshmallow revision. Until HDMI can be fixed, I disabled it completely to recover its unused VRAM allocation.

Will this (continue to) be based off AOSP, or CM?

belfastraven said:
@amaces, I am currently running with the 11/01 hummingbird build from experimental, which I installed yesterday. It doesn't work as well for me as the 10/29. It is laggier, and for some reason right now, I can't log into from the kindle app. I also note that on rebooting, it will go through the boot cycle more than once, optimizing various apps each time. Of course, since it just numbers the apps, you can't actually tell what it is doing. . I think there are olicy/permission issues since trickster mod can't install busybox into the system partition and, as stated before, system won't boot into to revery, soft boot, or shutdown, without use of power,home keys. Do you wan't logs?
thanks again.
Click to expand...
Click to collapse
On Ovation it is the same: 10/29 is far better than 11/01.
Graphics problems on 11/01: the screen shows some green lines sometimes and it feels laggier.
---------- Post added at 11:42 PM ---------- Previous post was at 11:40 PM ----------
twiztid_ said:
Will this (continue to) be based off AOSP, or CM?
Click to expand...
Click to collapse
I would prefer AOSP: less customization means less resources needed.
...and for Ovation every MB of ram free can be fundamental.
Or maybe both versions

For some happy news, multi-window mode (enable in developer options) seems to work pretty well (on my HD) It's probably even more useful on the HD+ where you have more real estate.

Thank you @amaces for M!
Questions:
Are your repos in a state that I can start trying to build it?
Is this your (local) manifest https://github.com/airend/android/blob/marsh/default.xml
I saw the above manifest and tried to build a couple of days ago and got many errors just updating my local repo. I'm reckoning that the manifest has such a mishmash of projects that I should probably delete my entire repo and download it all again. Is this likely the case?
Again, thanks. I'm so excited!

Things are still busy till probably tomorrow afternoon, but I will add proper replies here, and on the CM12 thread soon. As of now, there must be a few dozen posts I need to go through, plus lots of other updates.

amaces said:
Things are still busy till probably tomorrow afternoon, but I will add proper replies here, and on the CM12 thread soon. As of now, there must be a few dozen posts I need to go through, plus lots of other updates.
Click to expand...
Click to collapse
Is gapps for 6.0 available? If so, which one do you recommend?

js290 said:
Is gapps for 6.0 available? If so, which one do you recommend?
Click to expand...
Click to collapse
OP has only two paragraphs. Try reading it again.

I have 2 HD+ and wanted to dedicate one to Marshmallow. I spent time with this build and it just became too frustrating.
I did find a gapps benzo-gapps-M-20151011-signed-chroma-r3.zip that did get rid of the nag messages with settings in settings-apps. I'll get links if others are interested. AdaWay 2.2 did give some strange messages about BusyBox scripts but it turns out there is a Mars working version of AdaWay, AdAway-release_Build-Oct.09.2015.apk that I haven't tried yet.
Very frustrating not really being able to use the ExtSdcard. Installation of apps is not that simple without using a third party browser.
First efforst here are great. If you look at first efforts on phones, disaster and pre=alpha is what is going on.

And for those of you who, like I, have been looking to find where the external sd carded is mounted if you want to keep it as an external sd card, on 11/1 build ,it is at /mnt/media_rw/FFF9-7EC0 on my HD-I think that that actual hex address part may vary. I was able to manipulate the files on it with the root explorer app. I think other apps will work as well--they just don't know where to find the external sd card... .
Root Explorer lets you set that path.
Also, I was able to enable and use the Sytem UI Tuner setting...

belfastraven said:
And for those of you who, like I, have been looking to find where the external sd carded is mounted if you want to keep it as an external sd card, on 11/1 build ,it is at /mnt/media_rw/FFF9-7EC0
Click to expand...
Click to collapse
Couldn't you use a script to mount(or link?) the folder to its "proper" location at start up?
I thought that's what the system did anyway.

twiztid_ said:
Couldn't you use a script to mount(or link?) the folder to its "proper" location at start up?
I thought that's what the system did anyway.
Click to expand...
Click to collapse
I think the issue is that it's "proper" location for Marshmallow (the system locates the card with no problem) is different from where older apps are looking for it. I'm sure one could add a link or links I was just happy to locate it

sephiroth2k said:
Got a working keyboard by flashing attached, Google Play Services crashes constantly and the screen randomly flashes garbled graphics, then locked up. Not exactly a daily driver, but cool nonetheless!
Click to expand...
Click to collapse
That's a problem with whatever GApps package you flashed; there are many crappy ones floating around. Either way, a clean AOSP installation has none of those issues.
games906 said:
What gapps do I need to use for the 6.0? One was too big, another wouldn't flash, one flashed but all of the Google apps crashed. Help!!
Click to expand...
Click to collapse
Read post #3.
Monfro said:
Other bugs I have found: SD is not recognized, home button is not mapped to wake the device.
AOSP keyboard crashes, but we can flash others. Google Play services crashed in the first minutes...I don't know if it started working well maybe after a silent update or it was not starting again.
Click to expand...
Click to collapse
Read OP about the distinction between AOSP and custom ROMs such as CM. Also, the AOSP keyboard is fine unless you flash GApps (see post #3.)
asakurato said:
It's not for daily use. Performace is quite good, if not better, but there are many bugs, like computer can't recognize both Internal and external sd (in mtp), file managers can't recognize external sd, constant keyboard crashes (you can use any other) and many other which I have forgotten or haven't found yet.
Click to expand...
Click to collapse
Monfro said:
So the only important bug I found is SD card not accessible: only built in file browser can correctly access it.
Click to expand...
Click to collapse
There are significant changes to storage management in Marshmallow, and I suspect those basic AOSP apps were once-again left behind, and are not using the newer APIs.
belfastraven said:
On Hummingbird, same as above re sdcard. Also location services seem not to be working properly. Accuweather, google maps don't seem to be able to access the services even though they have permission.
Click to expand...
Click to collapse
It's probably a missing location provider issue, like we had in the early days of CM12.0 (and which CM fixed). I'll need to track that down.
belfastraven said:
I've noticed a bit of what seems to be a memory management problem... once you have been using several apps for a while, (for me, NYTimes, kindle, Chrome_dev, settings, gmail, e.g. ) apps become rather laggy and you get the application not responding message. I am going to attempt to keep using this as my daily driver, however. Is there a way to do a soft reboot in this rom--previously you could do it from the power menu.
Click to expand...
Click to collapse
Although I haven't noticed that, all is possible; I haven't used my device for more than a few hours before having to work on fixing stuff, followed be reboot. The reboot options you're familiar with were a CM feature as described in the OP, but I plan to adapt their code. Beyond that, soft/reboot/recovery/power off don't seem to work at all, root or no root. It's possible CM was setting those in a legacy fashion for our devices (and even then, they were falling apart as you know).
toplist said:
Reboot to recovery isn't working for me. Currently, I'm running the latest experimental marshmallow build. I've been running op's cm12.1 build even before this thread was created. I didn't have recovery or power off problem like some users until the last cm12.1 10/18 build. When I saw the marshmallow build and decided to try it, that's when I found out that reboot to recovery and complete power off are not working properly. The way I access recovery now is manually pressing power button to shut it off and do power+home to boot to recovery. I tried flashing twrp 2.8.7.4 from amaces's folder and also twrp 2.8.7.0 using flashify. It doesn't fix the problem. I can't access fastboot from computer. When I use adb reboot bootloader command, it loads to cyanoboot and few seconds later shows android boot window. How can I get reboot recovery and power off working again?
Click to expand...
Click to collapse
The devices never had reboot to bootloader or fastboot support, and TWRP doesn't have much to do with reboot/power off within the ROM. Otherwise, read above; currently, if you need to power off, hold the power button for a few seconds to force shutdown.
belfastraven said:
@amaces, I am currently running with the 11/01 hummingbird build from experimental, which I installed yesterday. It doesn't work as well for me as the 10/29. It is laggier, and for some reason right now, I can't log into from the kindle app. I also note that on rebooting, it will go through the boot cycle more than once, optimizing various apps each time. Of course, since it just numbers the apps, you can't actually tell what it is doing. . I think there are olicy/permission issues since trickster mod can't install busybox into the system partition and, as stated before, system won't boot into to revery, soft boot, or shutdown, without use of power,home keys. Do you wan't logs? […] Have trickster mod running now--needed to install busybox through recovery. If there is anything you want looked at, let me know. I note that the system is "idling" a bit warmer than it was onlast Lollipop build--at a little over 30 degrees C. "miscellaneous" is using 22% of battery.
Click to expand...
Click to collapse
Didn't notice new lags on non-GApps install, but again, I must've tested a dozen builds since last week. The only major difference with 11/01 was turning SELinux on (albeit Permissive, see OP), after a week-long bug hunt. In the meantime, the repos jumped to r26 (MDB08M, same as latest Nexus 6P builds), which represents about two months of development upstream, so hopefully the next builds will be better. AOSP doesn't include busybox as you discovered, but you can easily install the package once you have root (Trickster MOD's dev publishes a good installer, so no need to flash stuff in recovery, although that works too).
Logs won't help much at this point since I can see all these issues on my device as well; I'm tackling them sequentially, but all these take a lot of time, so it'll be a while until decent ROMs happen.
Tschumi said:
In the experimental folder are the Marshmallow builds, did you flash over Lollipop? There are still a lot of kinks.
Click to expand...
Click to collapse
Definitely factory reset before installing Marshmallow.
belfastraven said:
no--I had been running the 10/29 Marshmallow--. I know that these are very early, but I think the 10/29 was working better for me. I'm sure some of this is not the rom, but the apps. I do note a lot of avc permission problems in the logs, as well as Choreographer complaining about missed frames..., I am excited that this is running at all.
Click to expand...
Click to collapse
The AVC denial messages finally show up after I fixed SELinux, and Permissive shouldn't negatively impact performance, but yeah, sepolicy needs to be updated for MM soonish. The missing frame issue is troubling, and I'll definitely investigate if it persists into what I deem as stable builds.
Monfro said:
On Ovation it is the same: 10/29 is far better than 11/01. Graphics problems on 11/01: the screen shows some green lines sometimes and it feels laggier […] I would prefer AOSP: less customization means less resources needed. ...and for Ovation every MB of ram free can be fundamental. Or maybe both versions
Click to expand...
Click to collapse
Same as above, and do let me know if these issues happen on a clean GApps-free installation.
twiztid_ said:
Will this (continue to) be based off AOSP, or CM?
Click to expand...
Click to collapse
OP updated with relevant info, but yeah, ideally both will be maintained side-by-side. Of course, CM13 is in huge flux right now.
Zippy Dufus said:
Are your repos in a state that I can start trying to build it?
Is this your (local) manifest https://github.com/airend/android/blob/marsh/default.xml
I saw the above manifest and tried to build a couple of days ago and got many errors just updating my local repo. I'm reckoning that the manifest has such a mishmash of projects that I should probably delete my entire repo and download it all again. Is this likely the case?
Click to expand...
Click to collapse
I've be trying to keep everything on GiHub up-to-date and reasonably stable. As you noticed, I've been crafting a de-bloated manifest that will make it even easier to replicate my builds (details in post #2).
Now, you can repo init on top of the CM12 sources, but you'll need to --force-sync since many repos are overwritten. That would only matter if you made local commits, especially if you didn't upload them, because you'd likely lose them. Better yet, I suggest keeping the CM folder separate, then initialize another one for AOSP with the --reference option. By referencing the CM folder, repo will attempt to reuse common repositories, which is the majority of Git objects. The checkout will still consume space, but the hidden .repo folder will be much smaller. Of course, referencing is not needed if you have enough space. Conversely, if you delete everything (that is including .repo) and initialize anew, you avoid all these issues, but going back will be a hassle.
Otherwise, I'm using a 4.9 EABI for kernel, but Google may insist on 4.8. If that creates issues (it'll be obvious, missing compiler type errors), you can either remove those prebuilts in your local manifest additions plus bring in a 4.9 kernel toolchain, or simply create a symbolic link (ln -s arm-eabi-4.8 arm-eabi-4.9) in platform/prebuilts/gcc/linux-x86/arm.
king200 said:
I have 2 HD+ and wanted to dedicate one to Marshmallow. I spent time with this build and it just became too frustrating. I did find a gapps benzo-gapps-M-20151011-signed-chroma-r3.zip that did get rid of the nag messages with settings in settings-apps. I'll get links if others are interested. AdaWay 2.2 did give some strange messages about BusyBox scripts but it turns out there is a Mars working version of AdaWay, AdAway-release_Build-Oct.09.2015.apk that I haven't tried yet.
Very frustrating not really being able to use the ExtSdcard. Installation of apps is not that simple without using a third party browser.
First efforst here are great. If you look at first efforts on phones, disaster and pre=alpha is what is going on.
Click to expand...
Click to collapse
You gotta read the OP, especially the end of it... But yeah, I'm sure you did your research regarding GApps; the end of October packages were much better, albeit still very flawed (see post #3). AdAway works perfectly once you're rooted, even with versions older than 10/09 in the semiofficial thread, which should've been your first go to. There's no issue with SD card mounting, but you should be aware that fancy filesystems (e.g., exFAT, NTFS) are not supported by AOSP. Also, apps need to use the MM storage APIs. In conclusion, do your testing on a clean slate, before flashing any GApps; all are buggy currently, and that situation has nothing to do with these ROMs.
twiztid_ said:
Couldn't you use a script to mount(or link?) the folder to its "proper" location at start up?
I thought that's what the system did anyway.
Click to expand...
Click to collapse
That won't work well since that path is not constant or universal. I'm sure we'll learn more about these new storage APIs, but I'm only providing the hooks based on the official documentation at: https://source.android.com/devices/storage/config.html#android_6_0.
belfastraven said:
I think the issue is that it's "proper" location for Marshmallow (the system locates the card with no problem) is different from where older apps are looking for it. I'm sure one could add a link or links I was just happy to locate it
Click to expand...
Click to collapse

Has anyone tried BaNKs MM gapps? People seem to be using them on the N4 with MM builds without any issues.

I'm doing much better with the 0129 build than the 1101. The 1101 build is unresponsive. Also, something like opening an SMB tab doesn't work.
I did this to solve the Google Play Services fc http://www.ibtimes.co.uk/android-6-0-marshmallow-gapps-how-fix-google-play-services-force-close-error-1524431
------------------------------------------------------------------------
With aosp_ovation-ota-MRA58K.151029.zip:
Avoided many hangs and reboots. Developer options->background processes limit->3 max has to be reset on each boot.
Green streaks on screen: developer options_>disable HW overlays. Select but after reboot, will reset to off.
Could browse to MicroSD card with Root Explorer, mnt/media_rw/147E-92D1, was not able to set the path for external card to that value.
Was able to set Home to card with Root Browser https://play.google.com/store/apps/details?id=com.jrummy.root.browserfree
Moon Reader could find the card but not see any files in the root folder.
AnTuTu starts test but then closes.
Google Text-tospeech Engine give error messages. Pico TTS works but has to be set to very slow speech rate to be intelligible. Voice search works but, again, difficult to understand.
Kodi ran well. A big battery eater and video intensive.
Use Swype keyboard and freeze Android Keyboard.
Adaway, even the AdAway-release_Build-Oct.09.2015.apk would not install. Placed a working Hosts from another device file in /system/etc and it works fine.
Adb is more reliable with WiFi than cable.

king200 said:
I'm doing much better with the 0129 build than the 1101. The 1101 build is unresponsive. Also, something like opening an SMB tab doesn't work.
I did this to solve the Google Play Services fc http://www.ibtimes.co.uk/android-6-0-marshmallow-gapps-how-fix-google-play-services-force-close-error-1524431
------------------------------------------------------------------------
With aosp_ovation-ota-MRA58K.151029.zip:
Avoided many hangs and reboots. Developer options->background processes limit->3 max has to be reset on each boot.
Green streaks on screen: developer options_>disable HW overlays. Select but after reboot, will reset to off.
Could browse to MicroSD card with Root Explorer, mnt/media_rw/147E-92D1, was not able to set the path for external card to that value.
Was able to set Home to card with Root Browser https://play.google.com/store/apps/details?id=com.jrummy.root.browserfree
Moon Reader could find the card but not see any files in the root folder.
AnTuTu starts test but then closes.
Google Text-tospeech Engine give error messages. Pico TTS works but has to be set to very slow speech rate to be intelligible. Voice search works but, again, difficult to understand.
Kodi ran well. A big battery eater and video intensive.
Use Swype keyboard and freeze Android Keyboard.
Adaway, even the AdAway-release_Build-Oct.09.2015.apk would not install. Placed a working Hosts from another device file in /system/etc and it works fine.
Adb is more reliable with WiFi than cable.
Click to expand...
Click to collapse
On the 11/05 hummingbird rom, rooted, but without gapps or any additional app loaded, I have no sound
or video . Loading a couple of apps from APKs, no location services, Amazon Kindle not responding, same as earlier.
This was a clean flash--wiped system, data, cache, dalvik...
I'll try playing with this a bit more.

belfastraven said:
On the 11/05 hummingbird rom, rooted, but without gapps or any additional app loaded, I have no sound
or video . Loading a couple of apps from APKs, no location services, Amazon Kindle not responding, same as earlier.
This was a clean flash--wiped system, data, cache, dalvik...
Click to expand...
Click to collapse
Hmm, the A/V stuff may be due to the inclusion of media_codecs_ffmpeg.xml, which is present only in CM. Since you're rooted, you could test this by deleting the <Include href="media_codecs_ffmpeg.xml" /> line at the end of /system/etc/media_codecs.xml.
The Amazon Kindle issue is intriguing; do you remember if you had it on the last CM12.1 builds? There could be several reasons, including a heap change that I made about a month ago. Either way, can you describe in more details what happens, and possibly capture a log?

amaces said:
Hmm, the A/V stuff may be due to the inclusion of media_codecs_ffmpeg.xml, which is present only in CM. Since you're rooted, you could test this by deleting the <Include href="media_codecs_ffmpeg.xml" /> line at the end of /system/etc/media_codecs.xml.
The Amazon Kindle issue is intriguing; do you remember if you had it on the last CM12.1 builds? There could be several reasons, including a heap change that I made about a month ago. Either way, can you describe in more details what happens, and possibly capture a log?
Click to expand...
Click to collapse
Deleting the line from /system/etc/media_codecs.xml fixed the sound and video problems.
Amazon definitely was fine on lollipop builds--it may have even worked on 10/29 Marshmallow, but I was so excited about that build I can't remember now It's one of my 3 or 4 most used apps.
What happens is that the application will start and if you are not logged into it already, will allow you to click on "start reading" and will bring up a log in page. Sometimes I have had the page come up, sometimes the application seems to freeze and then quit, sometimes I will get the "xxxx application is not responding..." message, sometimes it appears to restart on its own. I managed to log in once on the 11/01 rom, and then the application would die/freeze/etc when synching content so it never was usable. I could make no sense of the messages in the logs because I'm not experienced enough with this.
thanks for your help.
p.s. I cannot get the "file manager" app root access...

Phone Encryption on Android 8 (oreo) on Huawei Mate 10 Lite

Hello,
I have a rather interesting question, if someone (expert only please) can help, it would be very much appreciated
I have bought a new phone (Huawei Mate 10 Lite) which already has the preinstalled Android 7 OS.
After I turned it on, I've upgraded it to Android 8 (and EMUI 8) via the Software Updater.
So now, I am running Android 8 on Huawei Mate 10 Lite.
Until here, everything works like charm
The problem starts here: I'm used to having my ENTIRE user data partition (phone/device, call it as you wish) ENCRYPTED.
I am using my phone very much in different environments and if I accidentally loose it or it gets stolen, I want to ensure that nobody can access my private data by any possible means.
So, when I go to the classical place for encrypting phones: Settings -> Security & Privacy, I noticed that the "Encrypt Phone" option is MISSING.
I have only "Encrypt SD Card", but I do not have an SD Card, nor do I use one. I use only the internal flashdisk memory.
I even turned on the Developer mode and searched for that specific setting, but I cannot find it.
I googled about this problem and what I found even deepens the mystery, as there are some contradicting information and it doesn't paint a clear picture on how the hell encryption works on Android 7/8...
- In one place, it says that starting with Android 6 phones, the option of encrypting the entire phone is no longer available, as all phones with Android 6+ preinstalled are already encrypted !
Bump ! Really ?
- Somewhere else, someone says that the Full Disk Encryption (FDE) has been replaced with File Encryption and Google is slowly marking full disk encryption as obsolete...
I found the File Encryption on my phone and I have the possibility to create a file encryption "folder" or "vault" or what is that, but I do NOT want that, as I want the entire partition to be encrypted !
I am using VPNs, SSH keys, Pictures, E-mail accounts, Web browsers with stored passwords, basically the entire user partition contains secrets ! I cannot move everything to a secure container... maybe I forget something, and that something remains unencrypted ?
I cannot move everything to a secure SD Card or to put it in that encrypted "folder", because some secrets are files, some secrets are particular app settings or credentials.
Yes, I read about the fact that in Full Disk Encryption mode, a PIN is required for startup (as I had with my previous phone, which was great for me, by the way), and that PIN can prevent the booting of some basic functions of the device or the functioning alarms or something like that.
To tell you honestly, I don't care about those functions. I only want ENTIRE device encryption with one single PIN code.
I have already changed my SIM PIN (which is another thing, it doesn't relate to this), and I generated a phone PIN & Fingerprint on my phone, and set my phone to Lock after 15 seconds.
For everyday usage, the PIN/Fingerprint is enough to keep others from accessing my content, but what about plain disk access (using some other tools that read the flash disk) if I loose my phone or if my phone gets stolen ?
I liked the previous encryption method.
So, basically, I want to encrypt ENTIRE partition (FDE encryption) with one PIN, not SD Card encryption, not other file encryption solutions, not special vaults, not other stuff... I want my classic encryption back !
Please explain me:
1. Are all the new phones starting from Android 6 already encrypted ?
1.1. If so, why is there a file encryption tool to further encrypt particular files if the user partition is already encrypted ?
1.2. If so, what is the encryption key ? or what kind of encryption is that which does not require a PIN or something ? that means that the key is stored in plain text ? (if I don't offer it a PIN, it means that it must read the key from other places in order to decrypt the data (key that can be read by a thief, too?))
2. If Android 6+ phones are not encrypted, how can I implement full device encryption, and why the hell does Google abandon this kind of full, quick and not-giving-extra-security-thoughts encryption ?
I would kindly ask only experts to reply me.
If you are an expert or you know these things for sure, please reply.
I need a correct, documented (if possible), answer, because the security of my phone depends on it !
Thank you !

Well... anyone ??? Is this really such a hard question ???

I was getting so excited when I read your question, because I am looking for the exact same answer. But then I saw there aren't any answers.
Please can someone who knows about this answer this for us?

Mar0615 said:
I was getting so excited when I read your question, because I am looking for the exact same answer. But then I saw there aren't any answers.
Please can someone who knows about this answer this for us?
Click to expand...
Click to collapse
I'm not an "expert" but I can tell you your data is safe & encrypted by default, that is why you can't find an encryption setting.
As I understand it
1. Yes (Google makes manufacturers sign agreement)
1.1 The data is encrypted on phone but you may choose not to lock it. Also you may allow some other people access to your phone even if you set screen lock or it's possible somebody may get your phone before it automatically locks, that is why here is a separate encryption system that some people may want ho use to encrypt certain files. (I'm assuming this is what you are referring to as I have never used Huawei)
1.2 Yes the system can generate it's own key from it's internal information automatically (note also, if you put in a simple passcode it is just one element the phone will use to generate a long key, so hackers can't crack a simple passkey to get into your phone as it also uses it's internal data to generate the key)
2, All your data is encrypted, ok maybe not all eg if you consider an alarm time your data, as some apps may be able to access limited data eg alarm times.
A quick search produced these two articles that are not overly technical & also show the numerous security improvements that all go to make your phone more secure. I hope it puts your mind at rest (though of course nothing can be guaranteed 100% secure if a well resourced group has physical access to your phone eg a government)
https://m.androidcentral.com/how-android-n-addresses-security
https://www.computerworld.com/article/3220446/android/android-8-oreo-security.html

[WIP] 100% Native Android 6.0 TMO ROM

Greetings,
I am currently working on a 100% Android Marshmallow v6.0.1 variant for the Samsung On5 SM-G550T/1 (T-Mobile).
THIS IS NOT A THREAD ON HOW TO ROOT YOUR PHONE
This thread assumes you have already rooted and installed TWRP on your phone and have basic understanding on to backup and recover your phone.
If you need that sort of help, please see my other thread:
https://goo.gl/jWNVNX
Reasons for Project:
I started this project for two reasons:
- Frustration for the lack of support for an otherwise great phone.
- Stumbling across the Samsung Factory Test Rom doing research for other projects.
This ROM has a a 100% Native Driver Set for Android v6.0.1 on the SM-G550T/1. The driver set is identical for the TMO or MetroPCS variants, but the EFS folder will remain different for each.
I'm going to outright confess that I am not a programmer and this is truthfully the first ROM I am trying to develop on my own. I'm a Project Manager and Software Designer by trade, but I rarely get this deep into ROM developments. I figured it was a good project to take on to learn the nitty griddy of what a truly pure Android Experience looks like. That being said, I'd greatly appreciate any help anyone can contribute and will make all my work freely available to anyone wanting to help provided that everyone participating goes into it with good faith that they have no intent on making substantial gains from this project.
Usage of these ROMs/Files/Programs are subject to the following licenses:
- Google's Android Open Source Project Licnese (AOSP):
https://source.android.com/setup/start/licenses
- Google's Individual Contributor License Agreement:
https://cla.developers.google.com/about/google-individual
- Apache Software License, Version 2.0
http://www.apache.org/licenses/LICENSE-2.0
- Samsung Open Source Release Center (OSRC) License:
http://opensource.samsung.com/reception/
That being said, I believe this remains a good enough device, IMHO, to transition people into Android or to provide to people not requiring a fully featured phone.
KNOX Status:
The Factory Test ROM is mostly clean having all the drivers intact and lacks most Samsung Bloatware "tampering". It *DOES* have some preliminary containers for KNOX installed, but none of it is active and takes up less then 1 MB of total space after cleaning passes to remove as many traces as could be removed without breaking things. It is currently being "managed" by an init.d script that generates the folders. I haven't been able to track down yet.
Known Issues:
- 100% Pure Android Menus.
- Rooted/Super User.
- Sound, Camera, GPS, TMO Modem, Wifi, Bluetooth 100% working.
- 100% Native Tethering.
- Adblocker pre-installed (for both Apps and Websites).
- The smallest amount of KNOX installations outside of Lineage. >1mb of KNOX is present with the only items being present are installer containers.
- I'm trying to track down Init.d files that loads with Android and automatically disables/flushes WIFI.
- By default, the power button is set a 100ms push time to turn off (not show power menu). I'm trying to figure out a work around for this.
- I'm trying to find a compatible Contacts Storage file.
- There is no shutdown menu.
Please note that any released versions of this ROM will have makeshift ways to get around these issues.
Downloads:
Please see the second post in this thread.
How to Install:
#01.) Backup your device.
#02.) Download the zip file for the TWRP backup.
#03.) Unzip the TWRP backup.
#04.) Load the downloaded restore into your TWRP Backup Directory.
#05.) Boot into TWRP Recovery.
#06.) Restore the ROM copied into your TWRP Backup Directory.
#07.) Reboot.
Note: No personal data has been configured.
References:
Update Log:
https://goo.gl/CEGCx9|
Required System Apps for Samsung Phones:
https://goo.gl/emTvgX
Things I Could Use Help On:
- A very good way to figure out what Init.d files are doing what without reading through them.
- A good way to change the PIT so we can move 2 gig from the System Rom into the User Rom space.
- Easy methods for changing key button presses.
- A shutdown menu setup.
- A way to make this into an installer.
Note that all those things I'm working on ALREADY, but suggestions would be helpful.
Thanks in advance for any help anyone offers.
Donations Welcomed:
Dev elopement of this ROM is timely, I appreciate any contributions you wish to provide.
https://goo.gl/esVVqA

DOWNLOAD LINKS:
[2019-03-11] Android (v6.0.1) Build #13 [RC] - Google
https://www.androidfilehost.com/?fid=1395089523397913770
- Note, due to Google Now being installed on this one, I can't configure the home long press as the restart menu.
[2019-03-11] Android (v6.0.1) Build #13 [RC] - Diagnostics
https://www.androidfilehost.com/?fid=1395089523397913771
[2019-03-02] Android [v6.0.0] Build #10F [RC]
https://www.androidfilehost.com/?fid=1395089523397908668

i would love to test this rom

Its been taking a little longer then I expected to get it working correctly --- I've been having trouble tracking down some bugs, but with a little luck, I'll post the Google variant tomorrow.

Here is a "working" version to look at:
https://www.androidfilehost.com/?fid=1395089523397901430
It's a restore for TWRP (not an install).
It has all the aforementioned bugs, but is pretty clean only with a few basic utilities installed on it.
I'm trying to track down a number of things:
How to change the Power Button function:
In my most current build, I have made the power button simply put the device to sleep with a long hold of the home button bringing up the power menu. I can't for the life of me figure out where the power button menu lives at or how to define it.
Normally, you'd go edit /system/usr/keylayout/Generic.kl, however, editing it button 116 (the power button) for "Power" only makes it turn off. I can remap it easily as sleep. I compared several other ROMs who use the exact same parameter.
My current version, I just use an app to remap several of those functions; but I don't feel like that's a "release worthy" fix.
Factory Mode:
I can't figure out how to get this version of the ROM to get out of factory mode. The only real problem this causes is, on bootup, it will display a message saying as such and then disable WIFI and turn off the sound. Both, of which, can be immediately be turned back on. It also disables power saver modes.
At first, I thought this was an Init.d file, but after doing some digging I determined this has to the /efs/factoryapp/factorymode file. I may need to swap elements from another EFS to get this fixed.
Contacts Storage:
This is another one I can't seem to track down, but I have a working idea how to fix it. At current, anything that uses Contact Storage won't work. I wonder if the contact storage I have on the system is simply incompatible for some reason. I'm going to try to pull over those system apps from another working rom.
Storage
I've mapped out all the partitions but am having trouble figuring out how to actually change the partitions. There is a whole 2 GB being wasted on the system partition. I'm actually very surprised that no one has ever released a rom with this fixed.
I've tried using parted, but my ADB Install is messed up something major and I cant track down that problem. Reinstalled ADB hasn't fixed it. Its largely a PC problem on my end; a problem I'm dragging my feat going and trying to fix. This is an issue I REALLY wish I could use PC tools for :-\. I've done these changes a thousand times on Windows based machines, but never on a Linux based OS.
Now that I think about it, maybe I should try doing this from the terminal prompt in TWRP. I just wish the keyboard in TWRP didn't suck :-\.
Other Thoughts:
Beyond those very vexing bugs, I have to honestly say that I feel like this experience on this rom is vastly superior to that of the stock Samsung Experience. Sure, these issues are vexing, but I'm also seeing much less system overhead (CPU usage, RAM usage) with this Rom then anything else outside of Lineage.

Update
Here's an update for everyone who might be interested:
The last couple of week's I spent an ENORMOUS amount of time trying to track down as much as I can to get this ROM to work as intended.
For those interested, I've developed a completely new spreadsheet describing everything that's bloatware versus needed items:
https://goo.gl/emTvgX
This spreadsheet will probably be handy for EVERYONE working on Samsung related devices. When its a little more clean, I'll throw it some place better; but since this is specific towards this device, I'll keep it here for now.
It describes everything in /system/app/ and /system/priv-app/ in Samsung's default install and which of those items are actually needed for a 100% clean Android Experience.
I've also rolled through the architecture and have cleaned a lot of "junk" out of the system. Overall, I've pulled it the system from around 1.3 gb installed all the way down to about 800 mb and still feel confident I can trim more out of it.
I've also made it a point to install as much updated system apps as possible. Its been a game of juggling Google, Samsung and other ROM apps to find what works. In general, there are only one major programs left that are Samsung based in any way and that's the Samsung Phone Service app; which seems like its required to interface with the specific hardware on the phone. I've tracked down a number of native Google teleservice.apk-s and none have worked to date.
I am, sadly, still having the aforementioned problems:
- Contacts won't sync despite being able to connect to the contact services and seeing what backups are available. Manual restores work and updating contacts TO the server works now.
- The Power Button turns off the device immediately. The problem resides in a configuration somewhere that's telling the "Power" function to not bring up the power menu. The power menu is in the system, but appears to be renamed or something. I'm having trouble tracking this down. For documentation sake, in theory you should be able to just go to /system/usr/keylayout/General.kl and edit button 116, but that doesn't work.
- The phone is still locked into "Factory Mode". Various documentation says that if you go to /efs/FactoryData/factorymode and edit the contents to "ON", it should resolve this issue, but it doesn't. I feel that the problem resides in the CSC folder and EFS folder, but I haven't gotten around to testing yet. I suspect if you swap the CSC and EFS folders out and set all the correct permissions it might fix that. As it stands now, however, its only a minor inconvenience.
Overall, there's a lot more junk to sift through on the last two problems. The first problem I am kind of stumped on.
If you want to download the ROM and look at it or run it, you can follow the below link. It's currently setup with my "trouble shooting environment" making key places to tinker with easily accessible.
DOWNLOAD HERE:
https://goo.gl/MuPqE3

@LighthammerX
Im very grateful for this site where we can come and learn from one another. I just wanted to say thanks for taking time to work on this device and then sharing your findings. I've been using my on5 for 2 months now after other device died. I'm in the process of moving now but once I'm done with that I'm going to scope out this bad boy and see if I can figure out a few things. Appreciate you sharing your information with us all. Cheers.
Sent from my on5ltemtr using XDA Labs

Thanks. I'm glad to see there's some interest here. IMHO, with the right setup, this little phone is actually a very nice device today.
I actually took a lot of what I learned from hack this ROM apart and applied it to Super Starz to get it running a lot cleaning as my daily runner until/if I get these few bugs figured out.
Personally, I think the most valuable thing I've been learning is just how bloated Samsung Devices truly are out of the box.

I'm going to go ahead and dump my progress log here too so you guys can see what I've been toiling with in hopes someone has some specific feedback on issues and if I am in the right place or not:
https://goo.gl/CEGCx9
As of the writing of this post, I'm virtually confident any problems I am experiencing has nothing to do with /efs/ or /system/csc/.
I've found some inconsistencies in /etc/ and in a few other directories in /system/.
I still wonder if there isn't a init.d file I haven't tracked down yet, but personally I find folder compares faster and easier to try to normalize then I do init.d files.
When it comes to folder compares, I can do a fast reboot and see if things break. When it comes to lines of code, I have to do a bulk of edits, reboot and hope for the best.
Just as an FYI, I plan on completely rewriting the OP when things are at a place where things work.

For anyone following the thread, the Downloads Section has been updated.

This seems really interesting ? I've been trying to find a good ROM for a while with little success, so hopefully this might be the one. I just have one question: what are the differences between the Google and Diagnostics versions of this ROM?

Database Info

welcome