I was rather disappointed by the fact that ZTE does not let us use encryption properly on stock ROM.
However, all the stuff is in place in the ROM in principle: I flashed B06 over a data partition encrypted on CM13 and lo and behold, stock ROM asks for password and proceeds to boot up normally.
So if we can find a way to get key handling sorted on stock (which I guess is simply using dm-crypt), we can use proper encryption.
https://source.android.com/security/encryption/full-disk.html says the key used should already be random, so we just need to reencrypt the key with a new password to get proper encryption for which the process is the following
When a user elects to change or remove their password in settings, the UI sends the command cryptfs changepw to vold, and vold re-encrypts the disk master key with the new password.
Click to expand...
Click to collapse
I can´t test it (as I use cm13 as daily), but I assume the following command would set a proper password (obviously needs root):
Code:
su
vdc cryptfs changepw super-secure-long-password
If anyone wants to try, be my guest but I take absolutely no responsibility. Might be helpful to have twrp on your device in case something goes wrong, too.
Loader009 said:
It looks like I've triggered something in the bootloader so that this "SystemImage" (that's how it's named in TWRP) seems to be "activated" and running.
[…]
What I did?
I tried to change the encryptionPW with Cryptfs Password. It failed for some reason (or at least it said so).
After a reboot it showed me the corrupt data screen, in TWRP I entered my password and it was correct.
So I had to format userdata (no prob because of backup) but that's it.
I tried to restore the backup and noticed after a few tries that it always does not boot into my backup but instead into this SystemImage.
Click to expand...
Click to collapse
I was not able to do that...
nupi said:
I was rather disappointed by the fact that ZTE does not let us use encryption properly on stock ROM.
However, all the stuff is in place in the ROM in principle: I flashed B06 over a data partition encrypted on CM13 and lo and behold, stock ROM asks for password and proceeds to boot up normally.
So if we can find a way to get key handling sorted on stock (which I guess is simply using dm-crypt), we can use proper encryption.
https://source.android.com/security/encryption/full-disk.html says the key used should already be random, so we just need to reencrypt the key with a new password to get proper encryption for which the process is the following
Click to expand...
Click to collapse
Interesting, and you had the data properly mounted on boot with functioning lockscreen or FP?
When I tried changing the cryptfs password on stock rom (and @jcadduono did this as well) the phone did ask for boot password, but would not decrypt and mount /userdata
does this return a code 200 if you try it with your current password
vdc cryptfs verifypw <yourpass>
I had, worked perfectly with the previously set password
Not running stock I am not sure trying vdc will be useful. If I can find the time I will try over Xmas
https://community.zteusa.com/thread/12482?start=255&tstart=0
Related
I've been running SHOstock3 for a few days to get comfortable with it. Tonight, I decided to encrypt the device. It rebooted, encrypted itself, then rebooted again and asked me for the password. For over half an hour now, it's been playing the SHOstock3 boot animation over and over again. The SAMSUNG screen doesn't show up between loops.
Is that normal behavior? Should I just give it more time?
The power button was able to turn it off. After restarting, it would ask for the password and do the same thing. I should point out that entering the wrong password would make it ask again, so it was working "properly". I decided it was toast and tried wiping it. However, it still asked for the password. Repeatedly entering the wrong password to force a wipe didn't work properly either. It still remembered that it had a password, but forgot what it was.
To fix it, I had to go back to stock Jelly Bean (flash stock Gingerbread then use Kies to upgrade; Gingerbread doesn't know about encryption). When the newly flashed Jelly Bean asked for a password, but as soon as I entered something, it rebooted. I presume that it wiped whatever encryption information was left because it rebooted properly.
I'm still trying to decide where to go from here. I keep work stuff on my phone, so encryption is fairly important to me.
I found this information regarding encryption on Android:
http://source.android.com/tech/encryption/android_crypto_implementation.html
It's for Honeycomb, but I'm going to assume that it hasn't changed significantly. It looks like all the encryption information is stored at the end of the /data partition. However, it's not part of the filesystem itself. If init can't mount /data, it assumes that it's encrypted and takes appropriate action.
As such, I would assume that completely erasing the entire /data partition would take care of it. Note that the /data partition needs to be erased, not just the filesystem. Based on what I've read, I think that the /data partition needs to be wiped/erased/formatted in such a way that the last 16KB of the partition is erased. After that, a new filesystem would need to be created to keep it from asking for a non-existent password.
So, does anyone know what the wipes actually do in recovery?
A couple of observations.
I don't think it is advisable to work at this level of the file system while making assumptions. In my view, you make two very questionable assumptions in your remarks.
I don't have any information on the workings of wipe and format in recovery. You can, however, work with eMMC blocks using Linux commands. For instance, if you use the dd command to make a copy of the data partition, you will get the whole partition, not just the file system. You could then use reverse engineering to see what is contained in the last 16 kb of the partition. This would require a skill set that is certainly way beyond me, and I suspect beyond you. You could also use dd to write to just the last 16 kb as well.
Well, at this point, I'm not really trying to find a "solution", I'm just trying to understand why it's so hard to wipe the phone after it's been encrypted. The only reliable method I've found is to put on the stock firmware, then repeatedly enter the wrong password until it wipes itself.
I was poking around in the jeboo github (SHOstock3 uses the jeboo kernel) to see if I could figure out what's going on. I found the following line in fstab.smdk4210:
Code:
/dev/block/mmcblk0p10 /data ext4 noatime,nosuid,nodev,discard,noauto_da_alloc,journal_async_commit,errors=panic wait,check,encryptable=/efs/metadata
I'm currently running stock 4.1.2 and I found the same file with that line. After doing some research, I found that the encryptable flag tells the system to allow encryption for that particular filesystem. Its argument says were to keep the encryption metadata. In this case, it's kept in /efs/metadata. That file exists on my encrypted stock JB system and the file happens to be exactly 16KB. The first part of the file is plain-text and it appears to be encryption related. After further research, I found that "footer" is an acceptable value for encryptable. In that case, it stores the metadata in the last 16KB of the partition (but the filesystem can't extend into it for obvious reasons).
Given the behavior I've seen, my guess is that if init sees /efs/metadata, it asks for the password. This would explain how wiping /data would cause the system to still remember the password. Even if you were to erase everything in /data, /efs/metadata would still exist. I also suspect that certain methods of "wiping" /data don't actually do so because they attempt a check before doing the wipe. I'm far from an Android expert, most standard methods of checking a filesystem in linux would fail if said filesystem were encrypted.
So, I think I've figured out why wiping an encrypted phone is so hard, but I still haven't figured out why SHOstock3 doesn't boot after it encrypts the phone.
Jebo knows a lot about the kernel. You could probably get into a meaningful discussion with him on encryption. I don't know if he has a chat channel of his own, but he is probably in Shoman94's chat channel quite a lot. You can find that in the OP of the SHOstock3 thread.
Hi there,
Ok so now Lollipop is shipped encrypted by default, good thing. But what's the point of encrypting it if it doesn't even ask for a passphrase at boot time ?
I noticed it gives the user an integrity protection if the bootloader was tampered with but it's not enough.
I tried what was indicated on the torproject's blog, in the "Mission Impossible: Hardening Android" but it's oriented toward 4.x roms. The command was (as root) :
Code:
vdc cryptfs enablecrypto inplace NewMoreSecurePassword
Then I rebooted but there was no passphrase prompt and the device decrypted itself automatically.
Did someone managed to activate this ?
OK found this : https://source.android.com/devices/tech/encryption/
It seems it's syncing the schema/pin/password with the encryption password.
Since I've put a schema my device asks for it at each boot.
It's not what I' d like to have. I'd like to be able to change boottime schema with a passphrase and keep my schema for the screenlock...
Context
Android uses the same PIN (or pattern) that is used to unlock the screen to decrypt the disk. However the actual decryption key is bound to the device via some internal device key. So ideally you can only decrypt the disk on the device itself, and the device can delay the process and ultimately delete any data if too many failed attempts are made. This is the same concept that's used e.g. on ATM cards, which lock themselves after a couple of failed attempts, so a 4 digit PIN is enough.
Except that's not true, at least not for Qualcomm chipsets, where you can extract the device key, than brute-force the PIN externally, which shouldn't take too long for a 4 digit PIN. See [1]
So I want a strong password for disk encryption, but still a 4 digit PIN for unlocking. I tried the Cryptfs-app, but that crashed, so I used the "vdc cryptfs changepw ..." command on the commandline to set the disk encryption key. On the next reboot, the phone asked for my password, but didn't accept it. So reset everything, and try again. I did this a couple of times with the same result but ultimately got it work by making data not encrypted and then encrypt it using "vdc cryptfs enablecrypto ...".
Not sure exactly what went wrong there, but I saw a couple of QSEECOM errors in the log (QSEECOM is the component that communicates with Qualcomms "secure" execution environment).
This is on a BQ Aquaris X with TWRP and SuperSU but otherwise stock firmware (Android 7.1.1).
The worrying part
Now here is, what worries me: Whenever the phone didn't accept my (correct) password, I rebooted into TWRP. TWRP then asked for my password to decrypt data, and did so successfully. Except it also worked with the wrong password! Apparently during the boot process, when Android asked for my password, it actually decrypted the key and kept it decrypted over a full reboot! Some component didn't get properly reset. I checked by entering the wrong password during boot. When I then rebooted into TWRP I actually had to enter the correct password for it to work.
Now, that the system is working (i.e. it actually continues to boot after I enter the correct password), I cannot reproduce that behaviour. A reboot seems to always clear the key. But who knows, maybe with some trickery it is still possible to keep data decrypted over a reboot. Given how buggy the implementation seems to be.
Question
Is anyone aware of a known bug where the disk encryption key is kept decrypted over a reboot? I couldn't find anything about this.
Conclusion
Use a strong password for disk encryption
Even if you do, don't trust your phone and don't keep real sensitive data on your phone
harry
[1] (can't post links, so google for: Extracting Qualcomm's KeyMaster Keys - Breaking Android Full Disk Encryption blogspot)
3 years later on Android 10 it seems like this issue still exists? And I wondering why encryption is even enabled because it offers basically not protection.
The only workaround in Android 10 that I could think of:
I can use faceunlock for the lockscreen and for the decryption after a boot up. So basically I never really ever have to enter my PIN or pattern.
That means I could use a really strong and complicated PIN or pattern and there for increase the security of the encryption.
How ever, even a 12 digit numerical PIN or pattern (a pattern is basically just a numerical PIN) won't take long to bruteforce.
Hi all,
I have a question about encryption on Android 9. I recently fixed up my old Nexus 5 to use as a test device and set it up with the newest Unlegacy Android (Pie) ROM (OpenGAPPS Mini, Magisk 17.1) and enabled encryption on it. So far so good and everything works perfectly without any Problem.
As I was always curious about changing the encryption password on my current daily driver (Nexus 6) because I use a fairly short passcode to not make it annoying to get into the phone, I searched a little and came across the App SnooperStopper, which would do everything I wanted: Make it able to use different passwords for encryption and the lock screen, but also secure the lock screen in a way that after some failed unlock attempts the phone would reboot, requiring the full encryption password again.
After testing on my Nexus 5 I found out that the way the app changes the password does not work on the newer Android OSes anymore. (I also tested the method mentioned on this XDA Blog post without success)
So my question is if there is an updated way to change encryption password or if there is any other way to achieve my goal of having different passwords for encryption and lock screen as well as making the phone reboot on too many retries.
Thanks a bunch!
~Joe
Maybe a bit late, but it might help someone else, as I was looking for a way in Oreo or later the last 2 days too.
bastei said:
As a workaround on Android Pie, you can do the following (on your own risk):
set the desired password for the screen lock
backup lockscreen files:
all files under /data/system_de/0/spblob/
files containing "_synthetic_password_" in /data/misc/keystore/user_0/
/data/system/locksettings.db
set the desired password for the device encryption
restore / replace all lockscreen files
If something went wrong, sqlite into /data/system/locksettings.db and set the values of sp-handle and lockscreen.password_type to 0 to reset the screen lock.
Click to expand...
Click to collapse
For me this did not work and just made the phone hang for a while and then reboot after entering the encryption password.
An alternative way I found was to set a password normally (the one you want for the disk encryption) and then just delete all these files and restart the process of setting a new lockscreen password while denying to turn on the boot protection. This might work on some devices, but according to the following link, this doesn't work for example on LineageOS 16.
Also it seems like LineageOS 17 and possibly other Roms reenabled the old way of changing the password in the Terminal. See: https://github.com/nelenkov/cryptfs-password-manager/issues/25
I wished I could do it without installing any apps, but I am not knowledgeable enough to proceed further. For me the only solution was this modified version of the cryptfs App. The normal install process is explained there as well: https://github.com/thedroidgeek/cryptfs-password-manager/releases
Here is how I installed it:
1) Install the App
2) Get the 'App Systemizer' module through the Magisk Manager (https://forum.xda-developers.com/apps/magisk/module-terminal-app-systemizer-ui-t3585851)
3) Install Cryptfs App normally
4) Run 'systemize' as root in a Terminal app (I got a busybox error and ignored it)
5) Choose 'Systemize Installed Apps (Listed)' and find 'Cryptfs Password'
6) install into '/system/priv-app'
7) For me it errored out saying that the app already exists, ignore it.
8) reboot
9) Start Cryptfs App. If the process of making it a system app failed, then the app shuts down with an error message about needing to be systemized.
10) set your encryption password in the app.
11) Reboot, check if it works
12) Disable cryptfs App and the App systemizer module, no need to keep them running until next use.
The difference to snooper Stopper is that you can't set any actions to take if the password is entered incorrectly a few times. However if that functionality is needed, you can install snooper Stopper afterwards and just ignore the password change options and just set the behaviors.
Assume that one has a device that:
Running a version of Android that is either Nougat, Oreo, or Pie.
The device uses not full disk encryption but rather file-based encryption.
Has a password, pattern, or PIN set.
Say that the user has booted into TWRP or something like and deletes each of these files if they exist:
gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db
locksetting.db-shm
locksettings.db-wal
Here are my questions:
Upon booting into stock Android, will Android be able to load correctly? If not, what should it be expected to do?
I've seen on here and other websites users who did something similar to what I described and were unable to get to their applications/files BUT were able to access Settings. If this is what should be expected to happen, then what will happen if one sets another lock code through Settings? Will it erase the blob data connected to the old lock code that plays a role in deriving the decryption key? Will it crash instead?
Master Melab said:
Assume that one has a device that:
Running a version of Android that is either Nougat, Oreo, or Pie.
The device uses not full disk encryption but rather file-based encryption.
Has a password, pattern, or PIN set.
Say that the user has booted into TWRP or something like and deletes each of these files if they exist:
gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db
locksetting.db-shm
locksettings.db-wal
Here are my questions:
Upon booting into stock Android, will Android be able to load correctly? If not, what should it be expected to do?
I've seen on here and other websites users who did something similar to what I described and were unable to get to their applications/files BUT were able to access Settings. If this is what should be expected to happen, then what will happen if one sets another lock code through Settings? Will it erase the blob data connected to the old lock code that plays a role in deriving the decryption key? Will it crash instead?
Click to expand...
Click to collapse
How about you set the conditions and try it out yourself
([emoji3590]09-09-18[emoji3590])
PoochyX said:
How about you set the conditions and try it out yourself
([emoji3590]09-09-18[emoji3590])
Click to expand...
Click to collapse
Because I don't have a functioning Android device that meets the requirements I outlined.
I am bumping this thread.
Bump.
**DONT**
did the same thing "accidently " a while ago, had to format /data (internal storage is gone!)
My device was struck on "Wait a second" forever.
It worked before file-based-encryption, but now I think the android system (Gatekeeper maybe?) checks for locksettings.db file during the bootup and doesn't start if not found or something
PS: Don't delete any of these files if your system uses file-based-encryption
locksettings.db
locksettings.db-shm
locksettings.db-wal.
file-based-encryption actually requires your PIN (used to encrypt) to decrypt the file-system, in addition it requires a lot of other ce/de key files, my advice would be not to delete stuff without making a proper backup!