Galaxy S3 I9300 International stock with all last updates (seems to be 4.1.1).
I've just wanted to use one password for data encryption and separate pin for unlocking, so I followed http://forum.xda-developers.com/showpost.php?p=35514297&postcount=24
I've issued
Code:
vdc cryptfs enablecrypto inplace
yep.. with 21 character password, so it won't fit to password field on boot, because field was limited to 16 characters. I know I'm fool and wanted too much lol.
How I see future steps:
1. Attempt to flash CM (does CM have this stupid limit? I have no other device to try and that's why this question appear);
2. Decrypt data from CM;
3. Flash stock kernel.
Is it possible or I want to do some wrong steps? Or maybe main target (decrypt data back) can be achieved with some easier steps?
Thanks for reading and probably answer.
Related
Here are some questions about Android 4.3 and upper.
A pair of questions about unrooting/locking/unlocking/booting.
1) What are the benefits of rooting other than being able to a) set custom cpufrequency policies, b) being able to update your phone (to custom new ROMs like cyanogenmod) when your OEM has decided to stop supporting it, c) full filesystem access, d) tuning sysctl parameters?
I don't like the fact the rooting totally breaks Android's security model.
2) Do I understand correctly that a locked phone is the phone in which you cannot overwrite/replace/customize vmlinuz? or there are even stricter limitations?
3) Do I understand correctly that in order to change e.g. /etc files you don't really need a custom ROM, you can boot into TWRP and replace/edit/remove the needed files?
4) Why does unlock wipe all your data?
5) If the phone is locked, how bootloader/firmware understands that our bootloader is untempered? Does the bootloader have a digital signature? I have this question because let's imagine that I 1) unlock 2) change vmlinuz (allow superuser) 3) lock?
6) How does "oem lock" verifies that system data is genuine? Or it simply wipes everything clean? Does Android has some (RO) partition which always contains a genuine virgin ROM you cannot meddle with?
7) If I do "unlock" on my Nexus device, without changing anything or installing any 3d party bootloader (like TWRP), will I be able to update to new official ROMs via OTA updates?
8) Why every "lock" manual says that I need to upload a genuine official ROM - what if I've changed it and made it "rooted"?
Storage.
Why does Android has so many partitions?
What method is used to break the internal storage into partitions? Is it some kind of partition table (MS-DOS, GPT) or it's hardware based?
Thank you for answers.
Lovely. 4 years and zero answers.
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...
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
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.
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!