OSPREY XT1541 encryption password change problem - Moto G 2015 Q&A, Help & Troubleshooting

Hi.
I'm experiencing a weird problem with Moto G3, that is osprey XT1541 when trying to change encryption password.
Did tried several different combinations of ROM or kernel, searched with several engines and through this forum, but got almost nothing.
Platform is CM 12.1, because I couldn't successfully encrypt with CM13; "...Trebushet has stopped...". ADB is run with root.
Device can be encrypted inplace with GUI if PIN/password is defined; also inplace in ADB CLI
"vdc cryptfs enablecrypto inplace pin|password pin_or_password"
Different lock code && encryption password can be set only with 5.1.1 build of CM if 1st PIN or password is defined in GUI (Settings>Lock screen) then in ADB CLI
"vdc cryptfs enablecrypto inplace password password"
But, encryption password can be changed only with GUI (Settings>Lock screen), after what there is no difference between lock code and encryption password.
ADB CLI
"vdc cryptfs changepw password password"
respond with "200 0 1" error and GUI tools give display error with similar meaning.
Also, ADB CLI
"vdc cryptfs verifypw password"
respond with "200 0 0", but, after entering encryption password in bootstrap, there is infinite bootloop.
Does anybody have idea why different lock code and encryption password can't be set on this device, apart from scenario described above?
Also, why encryption is unsuccessful with CM13?

I have CM13 and encryption worked fine. Can you backup, completely wipe your phone and flash a clean version of CM on your device? Maybe that'll help.

xDantehh said:
I have CM13 and encryption worked fine. Can you backup, completely wipe your phone and flash a clean version of CM on your device? Maybe that'll help.
Click to expand...
Click to collapse
Already tried clean install of several CM13 builds, without success. Either bootloop or "...Trebushet has stopped...".
How did u do it; with what build?
Also, my primary problem isn't encrypting, cause that can be done without problem with CM12.1, but encryption pwd change with success.

pseudorng said:
Already tried clean install of several CM13 builds, without success. Either bootloop or "...Trebushet has stopped...".
How did u do it; with what build?
Also, my primary problem isn't encrypting, cause that can be done without problem with CM12.1, but encryption pwd change with success.
Click to expand...
Click to collapse
I downloaded the latest CM nightly from their repo (https://download.cyanogenmod.org/?device=osprey) then downloaded Gapps and Firekernel, flashed them and works fine with encryption.

Tried with cm-13.0-20160903-NIGHTLY-osprey and FireKernel-osprey-v5.6 without success. Got "Unfortunately, Trebushet has stopped." and "Unfortunately, Music has stopped."
Also tried with XOSP-5.4-OFFICIAL-20160512-osprey which resulted in bootloop.
I'm quite puzzled with both encryption process problems && failure of encryption pwd change.

Related

Workaround: how to use full device encryption with custom recovery and newer ROMs.

Starting with Android L/Lollipop/5.0, full device encryption will be enabled by default, and for good reason. However, we slightly more security-conscious/paranoid SGS3 users have had problems for a while with using custom ROMs and keeping our encryption, as the main custom recovery with support for encryption --- TWRP --- has some incorrect build flags and other problems that aren't considered a priority. However, thanks to the very same bug report and discussion on the issue on TWRP's pages, someone found a solution which I can confirm works for me as well: https://github.com/TeamWin/Team-Win-Recovery-Project/issues/247#issuecomment-52651670
One option would be to check whether CWM Recovery supports your device. Then you'll have access to MiniVold in recovery mode and you can mount encrypted partitions through adb. I prefer the TWR method of just typing in my password, but as long as that does not work on my Galaxy S3, this does:
adb shell
setprop ro.crypto.state encrypted
vdc cryptfs checkpw 'your passphrase here'
mount /dev/block/dm-0 /data
and when you're done backing up/installing a zip
umount /data
Click to expand...
Click to collapse
For Windows users, here's a batch file you can use to automate this process:
Code:
adb shell setprop ro.crypto.state encrypted
adb shell vdc cryptfs checkpw "%~1"
adb shell mount /dev/block/dm-0 /data
Save it under whateveryouwant.bat and then give it the password as a parameter (if the password contains spaces, enclose it in quotes).
Caveat: I've found some operations will unmount /data, which for some reason cannot then be re-mounted by any combination of these commands. Workaround is to just reboot Philz Touch Recovery / CWM Advanced Recovery, re-mount, and continue.

Messed up with 'vdc cryptfs changepw password' and entered hex values I can't type.

TL;DR I need an answer to one of the four questions at the bottom.
Preferably #1 or #3.
---------------------------------------------------------------
I have a Oneplus 3T running the latest Resurrectionremix (7.1.1) and TWRP recovery (3.0.4-1).
I use a pattern lock and device encryption, but I had separate passwords for the pattern and the encryption.
I tried to change my encryption password back to my pattern combo using 'vdc cryptfs changepw password' and entering numbers that correspond to the dots of the pattern. (E.g. in a 3x3, the dots are labeled 1-9)
Let's say the password I entered was '123456789'
I didn't realize that I needed to enter the HEX values in this command, (313233343536373839) so I just entered the ASCII values (123456789). The password I entered was all numbers so it corresponded to HEX values without giving an error.
Now, when I restart my phone, or boot into TWRP, I cannot enter the password I set. I cannot access adb or a terminal when booting android, and I cannot use 'vdc cryptfs' through TWRP. (I can use adb and terminal through TWRP)
The obvious solution is to convert the HEX values I entered to ASCII values and type them in, but I have two problems:
I use an odd number of dots for my pattern lock, and I entered an odd number of numbers for the HEX password. I don't know how that would break down into ASCII, because you need 2 HEX digits per ASCII character.
No matter how I convert the HEX to ASCII (either by prepending or appending a 0) there are characters that cannot be typed on a keyboard, and cannot be pasted into an adb shell.
---------------------------------------------------------------
I can think of a number of possible solutions to this problem:
How can I input my encryption password in hexadecimal rather than ASCII?
I think this would only be possible through TWRP/adb. It only needs to be temporary; I'll move my data out and format everything.
How can I backup the encrypted '/data' partition to my PC?
This way, I can freely format my phone while I try to decrypt the encrypted blob. Additionally, are there tools to help me decrypt the partition on a PC?
How can I use 'vdc cryptfs' in TWRP?
Right now, the problem is that it cannot find 'cryptd'. If I can get this to work, I can reset the password to something typeable.
How can I use 'vdc cryptfs' in Android without entering a password on boot?
As I said, my phone doesn't turn on adb before I enter the password, and I can't access Terminal or anything... or is there a way?
Or can I solve this any other way, without losing my data?
Alternatively, is there a way to inject hex into android's clipboard, and paste it during boot or in TWRP?

Decrypt Android Pie File-Based Encryption? No success with "twrp decrypt 123"

Decrypt Android Pie File-Based Encryption? No success with "twrp decrypt 123"
Hi,
during update of my Xiaomi A2 to Android Pie I corrupted my /data. The phone gets Android One, so my problem should be quite widespread. Phone is up and running again but had to factory reset at the end. I tried to recover some files but I wasn't able to decrypt /data within TWRP with
Code:
twrp decrypt <NumberSequence-from Lock Patern>
The phone was protected with a pattern, that was correctly converted to the number sequence described in the TWRP FAQ. From what I saw in the TWRP source this command is for Android Disk Encryption only. Currently TWRP can't open my encryption of the fresh install:
Code:
I:File Based Encryption is present
begin failed, code -62Upgrading key: /data/unencrypted/keyupgrade_key failed, code -38e4crypt_initialize_global_de returned fail
begin failed, code -62Upgrading key: /data/unencrypted/keyupgrade_key failed, code -38e4crypt_initialize_global_de returned fail
begin failed, code -62Upgrading key: /data/unencrypted/keyupgrade_key failed, code -38e4crypt_initialize_global_de returned fail
I've got a backup of the encrypted partition so I can try anytime again but I didn't find any good clue. File encryption seems to have changed with Pie but the keystore looks accessible:
Code:
/data/unencrypted/ref
/data/unencrypted/key/version
/data/unencrypted/key/keymaster_key_blob
/data/unencrypted/key/encrypted_key
/data/unencrypted/key/stretching
/data/unencrypted/key/secdiscardable
/data/unencrypted/mode
I've had a quick lock into the TWRP source but found no easy clue how to fix the error above.
Question: Does anybody know a easy solution? Before I waste hours reinventing the wheel?
I guess either your best bet is to reflash images from the fastboot. Twrp natively support format data. By "entering yes". This removed all sort of encryption on Oreo. But I have read somewhere things have changed in pie.
ljakob said:
Hi,
during update of my Xiaomi A2 to Android Pie I corrupted my /data. The phone gets Android One, so my problem should be quite widespread. Phone is up and running again but had to factory reset at the end. I tried to recover some files but I wasn't able to decrypt /data within TWRP with
Code:
twrp decrypt <NumberSequence-from Lock Patern>
The phone was protected with a pattern, that was correctly converted to the number sequence described in the TWRP FAQ. From what I saw in the TWRP source this command is for Android Disk Encryption only. Currently TWRP can't open my encryption of the fresh install:
Code:
I:File Based Encryption is present
begin failed, code -62Upgrading key: /data/unencrypted/keyupgrade_key failed, code -38e4crypt_initialize_global_de returned fail
begin failed, code -62Upgrading key: /data/unencrypted/keyupgrade_key failed, code -38e4crypt_initialize_global_de returned fail
begin failed, code -62Upgrading key: /data/unencrypted/keyupgrade_key failed, code -38e4crypt_initialize_global_de returned fail
I've got a backup of the encrypted partition so I can try anytime again but I didn't find any good clue. File encryption seems to have changed with Pie but the keystore looks accessible:
Code:
/data/unencrypted/ref
/data/unencrypted/key/version
/data/unencrypted/key/keymaster_key_blob
/data/unencrypted/key/encrypted_key
/data/unencrypted/key/stretching
/data/unencrypted/key/secdiscardable
/data/unencrypted/mode
I've had a quick lock into the TWRP source but found no easy clue how to fix the error above.
Question: Does anybody know a easy solution? Before I waste hours reinventing the wheel?
Click to expand...
Click to collapse
Hey man... i have the same issue... well not issue... but i agree with you... for some reason in pie it is not decrypting... even without any pattern or pin ( i mean factory wipe still is encrypted)
I heard from a XDA member that the reason is that TWRP is still not based in Pie and therefore decryption fails (which doesn't explain much).
data is mounted
/dev/block/mmcblk0p69 on /data type ext4 (rw,seclabel,relatime,resgid=1065,data=ordered)
/dev/block/mmcblk0p69 on /sdcard type ext4 (rw,seclabel,relatime,resgid=1065,data=ordered)
but totally encrypted
/data/property # ls
7ie0ntZL7gIdCVBtZIRikhzXYZFI1twW
/sdcard # ls
3oZYlgteNMPvlbx7i7N5SC HHPy3vFJBv09B20I2Im2iKrJvdBiPBfc ...
Since it was factory reseted, i thought i could try something like
twrp decrypt ' '
But, no success... tried to put a password and decrypt with the password, but dmesg returns me:
<4>[ 139.534400] SELinux: security_context_str_to_sid(ubject_r:firmware_file:s0) failed for (dev mmcblk0p58, type vfat) errno=-22
<6>[ 139.547889] binder: tried to use weak ref as strong ref
<6>[ 139.547909] binder: 559:667 Release 1 refcount change on invalid ref 0 ret -22
lrwxrwxrwx 1 root root 21 Jan 12 1970 modem_a -> /dev/block/mmcblk0p58
Do you have the source page where you checked the twrp decrypt command?

How to reset (or bruteforce) EMUI "App lock" PIN [ROOT]

What to do if you forgot a PIN/password for Huawei EMUI "App lock" feature? I couldn't find an existing solution, so I had to solve the problem for myself. I have a Huawei p20 pro phone, but this solution is also suitable for other devices running on EMUI Android OS.
In my case, my root rights helped me, but if you don’t have them, you can probably solve the problem by using the ADB console (see UPDATE below).
So, the PIN is stored in the file "/data/misc/hsm/databases/applock.db". If you have root rights, you can delete it (and other files like "applock.db-shm", "applock.db-wal", "applock.db-journal", etc), which will reset all the settings for "App lock". Or with using any sqlite-editor on PC you can open "applock.db" file, and erase the "encrypt_password_sha256_salt" and "encrypt_password_sha256" fields in the "applockpreference" table.
In both cases restart the phone, the PIN code should disappear.
If you do not have root rights (so you cannot delete/edit the file "applock.db"), but you can read it, then you may use this python3 code (you can use any online interpreter to run it) to bruteforce PIN in less than a minute:
Code:
import hashlib, binascii
encrypt_password_sha256_salt = '609605825498166908'
encrypt_password_sha256 = '1000:5b2d362c202d34332c202d32352c202d33332c2034392c2036322c202d38372c2032362c2031312c202d32312c2031352c202d35382c2034312c203132362c2031312c202d34325d:97f6fdf9a44a1f3fb21e2296'
pbkdf2_password = bytes.fromhex(encrypt_password_sha256.split(':')[1])
needed_hash = encrypt_password_sha256.split(':')[2][:24]
result = ''
for i in range(0, 10000):
pin_str = str(i).zfill(4)
pin_and_salt = pin_str + encrypt_password_sha256_salt
sha256_hash = hashlib.sha256(str.encode(pin_and_salt))
sha256_hash_str = sha256_hash.hexdigest()
dk = hashlib.pbkdf2_hmac('sha1', str.encode(sha256_hash_str), pbkdf2_password, 1000)
if binascii.hexlify(dk)[:24].decode("utf-8") == needed_hash:
result = pin_str
break
if (i + 1) % 1000 == 0:
print('{}% done'.format((i + 1) // 100))
if result != '':
print('found: "{}"!'.format(pin_str))
else:
print('hmm... nothing found :(')
UPD:
I tried to get "applock.db" file through ADB console, and failed. "/data/misc/hsm/databases" is not accessible, "HwSystemManager.apk" a.k.a. "com.huawei.systemmanager" does not support "run-as com.huawei.systemmanager" command, and it has a "android:allowBackup=false" param in it's manifest, so "adb backup -noapk com.huawei.systemmanager" doesn't work.
So I can summarize, that my solution doesn't work without root rights (but if you have it, everything will be fine!).
hioma said:
What to do if you forgot a PIN/password for Huawei EMUI "App lock" feature? I couldn't find an existing solution, so I had to solve the problem for myself. I have a Huawei p20 pro phone, but this solution is also suitable for other devices running on EMUI Android OS.
In my case, my root rights helped me, but if you don’t have them, you can probably solve the problem by using the ADB console or an advanced file manager.
So, the PIN is stored in the file "/data/misc/hsm/databases/applock.db". If you have root rights, you can delete it (and other files like "applock.db-shm", "applock.db-wal", "applock.db-journal", etc), which will reset all the settings for "App lock". Or with using any sqlite-editor on PC you can open "applock.db" file, and erase the "encrypt_password_sha256_salt" and "encrypt_password_sha256" fields in the "applockpreference" table.
In both cases restart the phone, the PIN code should disappear.
If you do not have root rights (so you cannot delete/edit the file "applock.db"), but you can read it, then you may use this python3 code (you can use any online interpreter to run it) to bruteforce PIN in less than a minute:
Click to expand...
Click to collapse
password stored in secured partition...
this metbod it would be too simple...
huawei is not stupid... try factory reseting.... before take factory reset,delete google account and logout huawei id...
spityu85hun said:
password stored in secured partition...
this metbod it would be too simple...
huawei is not stupid... try factory reseting.... before take factory reset,delete google account and logout huawei id...
Click to expand...
Click to collapse
This is not "guess", this is a working solution. "/data/misc/hsm/databases/" is secured directory, but (I think) it is accessible through ADB console (and if you have root rights, it 100% accessible and editable, so you can clear or "decipher" PIN, stored as pbkdf2 key). So you can solve problem without wiping, I think, it's a good solution.
hioma said:
This is not "guess", this is a working solution. "/data/misc/hsm/databases/" is secured directory, but (I think) it is accessible through ADB console (and if you have root rights, it 100% accessible and editable, so you can clear or "decipher" PIN, stored as pbkdf2 key). So you can solve problem without wiping, I think, it's a good solution.
Click to expand...
Click to collapse
grat...now helped for thief for hack applocker pin...

Fix for Wifi not working after flashing custom ROM

Hello
As some users, I experienced a not working Wifi after flashing a custom ROM (LineageOS in my case) and wiping /data. The Wifi MAC address shows as
02:00:00:00:00.
After investigating, it turns out that libwcnss_qmi.so is unable to write to /data/opponvitems/4678. It's a small binary file containing the MAC address in reverse order binary.
To fix this problem:
Flash your custom ROM (wipe data if you want)
Boot the custom ROM at least one time and check that your Wifi is not working
Reboot to recovery (TWRP in my case)
Open an adb shell
Enter the following commands:
touch /data/opponvitems/4678
chcon -t wcnss_service /data/opponvitems/4678
This will create the destination file and set proper permissions so that libwcnss_qmi.so can write into it.
Reboot your phone.
Your Wifi should be working.
Please note that we manually change the SELinux context on /data/opponvitems/4678, so if you use restorecon or use TWRP's Fix context feature, the library won't be able to write to the file and your Wifi won't work.

Categories

Resources