Decrypt Android Pie File-Based Encryption? No success with "twrp decrypt 123" - Android Software/Hacking General [Developers Only]

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?

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.

OSPREY XT1541 encryption password change problem

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.

Reading dd dump to extract data from internal storage?

hi, i have a xiaomi mi mix 2s that was running los18. one morning i woke up before my alarm, checked my phone and went back to sleep. when i woke up again, i found the phone was on the splash screen and then started bootlooping. going into orangefox recovery, i was greeted with numerous /data mount errors, namely:
Code:
Could not mount /data and unable to find crypto footer.
Failed to mount '/data' (Invalid argument)
Unable to recreate /data/media folder.
Unable to mount storage
from what i can tell, the only way to get the device working again is to format the /data partition, which means losing all my data which im trying to avoid. i did manage to obtain a dd dump of /dev/block/bootdevice/by-name/userdata through usb otg, though ive been unable to read the img file, either through windows or ubuntu. is there any way to mount it and retrieve the data? i did specifically flash dfe from the start, so it should be unencrypted. the file system is ext4.
would also greatly appreciate other suggestions on how to recover the data.
bump, any input is appreciated!
You restore the data backed up with DD command as following
Code:
dd if=dump.img of=/dev/mmcblk0p29
assuming partition named userdata is block device named mmcblk0p29
check getprop ro.crypto.type and ro.crypto.state from adb shell. also check dump.img with xxd or hexdump has ext4 / f2fs magic 53.ef / 10.20.f5.f2 starting at 1080 / 1024 byte
apologies for the late reply, dont really check xda that often.
xXx yYy said:
You restore the data backed up with DD command as following
Code:
dd if=dump.img of=/dev/mmcblk0p29
assuming partition named userdata is block device named mmcblk0p29
Click to expand...
Click to collapse
is that after wiping? wouldnt that make the data partition unreadable again?
aIecxs said:
check getprop ro.crypto.type and ro.crypto.state from adb shell. also check dump.img with xxd or hexdump has ext4 / f2fs magic 53.ef / 10.20.f5.f2 starting at 1080 / 1024 byte
Click to expand...
Click to collapse
ro.crypto.type=file
ro.crypto.state=encrypted
as for checking the dump, are you referring to the commands:
Code:
xxd -l 1080 dump.img | grep 53ef
xxd -l 1024 dump.img | grep 1020.f5f2
if so, i did not receive any output. if they are wrong commands please let me know what i should enter.
looks like (FBE) file-based encryption. if dump is really encrypted there is nothing you can do on PC.
you can only restore + decrypt on device (as long as you did not factory reset)
aIecxs said:
looks like (FBE) file-based encryption. if dump is really encrypted there is nothing you can do on PC.
you can only restore + decrypt on device (as long as you did not factory reset)
Click to expand...
Click to collapse
i havent factory reset as i read some things about tee keys that would be wiped during data format, so i thought it would be handy to keep if i needed them. how would i go about trying to decrypt on device though?
also, what would have been the point of flashing dfe if in the end data is still encrypted?
right, encryption is bonded to TEE (which is flushed on factory reset). just restore and let orangefox or twrp decrypt (assuming it has well implemented encryption support). otherwise your only chance to decrypt is via regular booting into android (to at least stage with lockscreen or adb).
FBE data is encrypted with screen lock credentials, remember old pin, pattern, password used at time of dump.
"dfe" stands for disable force encryption (encryption will no longer forced after formatting) and there is a good chance this is the reason for failed decrypts. you can undo by restoring vendor partition.
aIecxs said:
just restore and let orangefox or twrp decrypt (assuming it has well implemented encryption support).
Click to expand...
Click to collapse
do you mean restore as in simply
Code:
dd if=/dump.img of=/dev/block/sda21
as @xXx yYy mentioned? would that make a difference? since the block device is fundamentally holding the same bits before and after doing so, at least to my understanding. im also quite apprehensive about making any modifications to the data partition as it is right now.
aIecxs said:
otherwise your only chance to decrypt is via regular booting into android (to at least stage with lockscreen or adb).
Click to expand...
Click to collapse
the phone doesnt get to lockscreen... i did enable usb debugging, but not sure if it is possible to access while bootlooping.
aIecxs said:
"dfe" stands for disable force encryption (encryption will no longer forced after formatting) and there is a good chance this is the reason for failed decrypts. you can undo by restoring vendor partition.
Click to expand...
Click to collapse
the thing is, i flash dfe right after flashing the rom with a data format, so i thought i would be safe from this kind of things happening. plus, i had been running this setup since the start of the year, and hadnt so much as changed any system settings recently, so its quite odd that the problem would just randomly manifest. it is not the first time it has happened either, in fact this happening the first time was what prompted me to start using dfe, so it is quite disappointing to see that it did not have its intended effect.
so to clarify, should i dd to the userdata block device and restore vendor (presumably from rom zip) or is dd enough?
yes, dd is fine (one could also use of=/dev/block/bootdevice/by-name/userdata)
and no, of course it doesn't make sense in that case.
I don't know what is the cause but I am afraid the only way to access that data is fix boot-loop.
It is unclear to me if encryption worked for a year or if you encrypted recently. Open dump with HxD and check first 1088 bytes for ext4 magic, or at least you should see many zeros on plain disk image.
Also check /vendor/etc/fstab* for flags in line /dev/block/bootdevice/by-name/userdata with notepad++ this could help to identify encryption is broken by dfe or healthy.
I checked two devices offhand, one was block encrypted, the other file encrypted.
I looked at the last 1M of the partitition of the file encrypted.
I thought that there was a footer there, there wasn't.
Your original message said that it couldn't find the footer.
I know some things use footers and they are usually a specific number of blocks before the end of the partition.
@Renate unable to find crypto footer - is misleading message from orangefox twrp recovery - it always check for any type of encryption but FBE encryption requires no crypto footer (only FDE or metadata encryption)
aIecxs said:
yes, dd is fine (one could also use of=/dev/block/bootdevice/by-name/userdata)
and no, of course it doesn't make sense in that case.
Click to expand...
Click to collapse
so should i still do it?
aIecxs said:
I don't know what is the cause but I am afraid the only way to access that data is fix boot-loop.
Click to expand...
Click to collapse
but it also seems that the bootloop is caused by the inability to mount data...
also it seems adb is not accessible while it bootloops.
aIecxs said:
It is unclear to me if encryption worked for a year or if you encrypted recently.
Click to expand...
Click to collapse
i flashed dfe along with the rom and magisk at the start of the year, havent flashed anything since. i also did not initiate any encryption process the whole time.
aIecxs said:
Open dump with HxD and check first 1088 bytes for ext4 magic, or at least you should see many zeros on plain disk image.
Click to expand...
Click to collapse
it is mostly 0000 or ffff, though there is mention of ext4 map blocks a little further down.
Spoiler: long image
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
aIecxs said:
Also check /vendor/etc/fstab* for flags in line /dev/block/bootdevice/by-name/userdata with notepad++ this could help to identify encryption is broken by dfe or healthy.
Click to expand...
Click to collapse
Code:
<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=0,noauto_da_alloc latemount,wait,check,=ice,quota
okay the good news it's probably not encrypted (at least no FDE) no need to decrypt disk image on phone.
the bad news it doesn't look like valid ext4 file system, you cannot mount it.
on linux pc, try fsck on dump2.img (make a copy first) then try to loop mount file. you can also try testdisk or photorec
the flag fileencryption=ice is broken by dfe (which is intended) so encryption/decryption won't work (as desired, not required on plain ext4)
aIecxs said:
on linux pc, try fsck on dump2.img (make a copy first) then try to loop mount file. you can also try testdisk or photorec
Click to expand...
Click to collapse
THANK YOU SO MUCH! my data is now readable on linux, will copy as much over before doing anything else. i was legitimately not expecting it to work.
should i also dd the repaired img to my userdata block device? i know twrp/ofox has e2fsck command, seems like it may be able to repair the partition on device in a similar manner.
didn't expect it's so easy lol.. yeah try e2fsck on /dev/block/bootdevice/by-name/userdata directly first.
NightRaven49 said:
ro.crypto.type=file
ro.crypto.state=encrypted
as for checking the dump, are you referring to the commands:
Code:
xxd -l 1080 dump.img | grep 53ef
xxd -l 1024 dump.img | grep 1020.f5f2
if so, i did not receive any output.
Click to expand...
Click to collapse
TWRP/Orangefox properties was bit misleading...
sometimes the solution is simpler than we think
aIecxs said:
didn't expect it's so easy lol..
Click to expand...
Click to collapse
same, actually the last time it happened (over 1.5 years ago) i also tried something similar, but didnt work because it was f2fs if i remember correctly. so i didnt think of trying e2fsck this time around. i suspect it may be a hardware flaw that caused it, since i am running a different rom now.
aIecxs said:
yeah try e2fsck on /dev/block/bootdevice/by-name/userdata directly first.
Click to expand...
Click to collapse
it works now, again thank you so much. funny how i was stuck without a phone for a month, went to so many data recovery specialists that told me that there was no hope and yet the fix was finished in mere seconds.

[SOLVED] Help to mount userdata in linux or repair userdata.img

After an Update of Two magisk modules, my Ulefone Armor 11 5G staied stucked on boot logo, I can only enter in recovery or fastboot.
I try to build a TWRP, but it is not able to mount userdata.
I was able to download with the help of mtkclient all the partition on my phone, even userdata , it took 7 hours.
I wanted to load the image in linux but using mount disk imag or using the command sudo mount -o loop userdata.img ~/Armor_11_5G doesn't do anything not even an error message.
I'm wondering if the filesystem was corrupted during the update.
Is it possible to repair the fylesystem like in Windows?
Thanks
did you previously disable encryption and factory reset long time before the modules updates failed?
what do you mean mount doesn't do anything not even an error message? either it give error message or it succeed.
I didn't disable encryption before updating the modules, I already updated this modules many times.
what do you mean mount doesn't do anything not even an error message? either it give error message or it succeed.
Click to expand...
Click to collapse
That is the problem, it doesn't succed and I don't have an error message. The file is 256 Gbyte big, I don't know if it plays a role. I'm using Ubuntu 22
if phone is encrypted that's just 256G garbage. post the output of
Code:
$ parted <file> unit B print
Here are the results of parted
Code:
Error: /home/*****/Public/userdata.bin.img: unrecognised disk label
Model: (file)
Disk /home/osboxes/Public/userdata.bin.img: 249208733696B
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Thanks
You may try https://www.cgsecurity.org/wiki/TestDisk_Download
I'd be glad for your feedback.
sorry thought it's whole disk, but it's only 232G file therefore parted won't print partition table
does apply to FDE only
assuming this file is dump of single userdata partition, open with HxD editor. if the partition image is not encrypted, you will see lot zeros within first 1024 bytes.
in that case you can check for file system type is ext4 or f2fs.
Code:
$ xxd -l 1080 dump.img | grep 53ef
$ xxd -l 1024 dump.img | grep 1020.f5f2
But most likely the userdata partition is encrypted, therefore no way to recover data offline.
The easiest way not to load Magisk modules is, not to load Magisk. Flashing stock boot.img will solve it.
Beware, in case you disabled encryption beforehand, booting stock boot.img will force encryption. This may take long time without notice.
I never disabled encryption, I don't know if Magisk do it without informing. I used this phone for an year without a problem.
After the update I left the phone on for one night but nothing happens. I tried to reflash the stock boot image, and again a whole night wait, but again nothing happens.
Reading the fstab the file system should be ext4.
The file is the dump of the whole userdata partition of my Ulefone Armor 11 5G.
I did a backup of the whole system before doing any experiment so if the partition table is corrupted maybe if I reflash back the userdata partition with a working partition table I have again access to the datas.
there is no partition table in userdata partition, I just gave you wrong advise. because the phones total storage is 256G, I made wrong assumptions (you can view partition table from file pgpt.bin)
full 1:1 backup is impossible for FBE encryption because encryption keys are stored in TEE. once you factory reset device backup of userdata + metadata becomes useless.
fstab doesn't tell you what file you just have dumped. if you can't find ext4 super magic (#7) it's impossible to loop mount that file (and impossible to decrypt on linux PC)
if you can't fix boot-loop by stock boot.img then it's unrelated to magisk modules. you can however enable adb in default.prop and capture adb logcat during boot-loop for further analysis. you could also inject own script that deletes some files (only DE encrypted files, CE encrypted files requires lock screen credentials aka pin/pattern)
boot this TWRP and get log from adb
Code:
$ fastboot boot recovery.img
$ adb shell twrp decrypt '1234'
$ adb pull /tmp/recovery.log
https://twrp.me/faq/openrecoveryscript.html
full 1:1 backup is impossible for FBE encryption because encryption keys are stored in TEE. once you factory reset device backup of userdata + metadata becomes useless.
Click to expand...
Click to collapse
With mtk client I was able to do the backup of tee1 and tee2 and also of gpt_backup and gpt_main.
$ xxd -l 1080 dump.img | grep 53ef
$ xxd -l 1024 dump.img | grep 1020.f5f2
Click to expand...
Click to collapse
Doesn't produce any results.
I have immediately the command prompt.
you can however enable adb in default.prop
Click to expand...
Click to collapse
How can I do that? Which value should I change in default.prop?
so your "backup" is encrypted. please note Trustonic Kinibi is TEE OS running in secure memory one can't access or backup with mtkclient. the tee partitions in phone storage do not contain any encryption key (none of the partitions does, secure memory is not even a partition). the only crypto related partition is metadata used for keydirectory of metadata encryption (on top of FBE encryption) but it is useless for backup purposes.
yes you can modify default.prop in boot.img, ro.secure=0 should give root access.
https://forum.xda-developers.com/t/...hone-with-broken-screen.2965462/post-85905033
Code:
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
in case the default.prop modification is not sufficient, you need additional command to be executed as root.
Code:
# settings put global adb_enabled 1
as you installed magisk, you could use magisk overlay.d/sbin/ for running startup script.
https://forum.xda-developers.com/t/...ithout-losing-your-data.4383255/post-86934375
aIecxs said:
boot this TWRP and get log from adb
Code:
$ fastboot boot recovery.img
$ adb shell twrp decrypt '1234'
$ adb pull /tmp/recovery.log
https://twrp.me/faq/openrecoveryscript.html
Click to expand...
Click to collapse
How about this TWRP? it should be able to decrypt userdata. if decryption failed, provide recovery.log
Until tomorrow I cannot do a logcat and I cannot find my view logcat on my laptop.
I unpacked boot.img with Carliv Image Kitchen and there is no default.prop, that is present in the recovery as prop.default.
Is there a way to backup secure memory of Trustonic?
How about this TWRP? it should be able to decrypt userdata. if decryption failed, provide recovery.log
Click to expand...
Click to collapse
I already tried that version but it cannot decrypt, that' why I'm trying to build my own version of TWRp with the help of the creator of that version of TWRP, but I'm stucked.
oh, you know how to build TWRP with proper FBE + metadata encryption support? have a look at other Oppo devices how they did... good luck.
regarding default.prop in boot.img (it's a symlink to system unfortunately) you can do it the other way
use magisk overlay.d/sbin/
create a boot script that does the thing with resetprop -n <prop_name> <prop_value>
don't use outdated Carliv Image Kitchen! use osm0sis AIK from link above.
oh, you know how to build TWRP with proper FBE + metadata encryption support? have a look at other Oppo devices how they did... good luck.
Click to expand...
Click to collapse
I'm learning.
I try to integrate the decryption service following the suggestion of ADeadTrouser on Github, but the service doesn't want to start and I don't understand why.
I never checked Oppo, I will take a look at them also, thanks for the suggestion.
I think I figured out now the adb logcat at least. hope that helps
https://forum.xda-developers.com/t/accessing-my-phone-with-a-dead-screen.4542763/post-88016019
I tried your script butr nothing happens, the telephone is not listed when I type
Code:
adb devices
and if I type
Code:
adb logcat
I receive the message waiting for device
you might follow the thread
wenyendev said:
You may try https://www.cgsecurity.org/wiki/TestDisk_Download
I'd be glad for your feedback.
Click to expand...
Click to collapse
I run the software on the image and it identify the contents and can read the encrypted and not encrypted part, that means that all the files are there, but I cannot mount in Linux or in TWRP
The fact that I cannot mount in Linux or TWRP the userdata image/partition can be that is corrupted the partition or the file index?
That would also explain why the script for Magisk provided by aIecxs is not able to copy the adb_key from the cache in the data partition.

Accessing my phone with a dead screen

So my phone screen connector was liquid damaged. No touch or display. It's an Essential Phone which supports HDMI output, however I can't unlock it because I don't see the lock screen on the monitor I just see a lock icon. I have fingerprint/pattern set up but I can't use fingerprint because it wants me to do the pattern first after a reboot. I do not have access to ADB since for whatever reason MTP is always enabled. I do have TWRP except the contents of the phone are encrypted so I can't get the data off that way. I am running an Android 12 custom rom. Any ideas on how I can access my files/unlock the phone?
we can enable adb in boot.img - please backup from adb while in TWRP recovery, share zip here so I will have a look.
Code:
adb pull /dev/block/bootdevice/by-name/boot boot.img
with adb enabled we can use scrcpy to mirror lock screen and unlock from PC.
aIecxs said:
we can enable adb in boot.img - please backup from adb while in TWRP recovery, share zip here so I will have a look.
Code:
adb pull /dev/block/bootdevice/by-name/boot boot.img
with adb enabled we can use scrcpy to mirror lock screen and unlock from PC.
Click to expand...
Click to collapse
Thanks for the response, I've got the boot image backed up.
Just for fun a built a digitizer emulator. It will work even when the ADB is turned off.
are you sure that is actually the boot.img dumped off your current boot partition? there is a twrp.fstab inside? However, I have modified prop.default and added custom.rc in overlay.d to enable adb. try this without flashing, then check adb. if it works, you can run scrcpy (link above)
Code:
fastboot devices
fastboot boot boot.img
adb devices
in case it does not work, you could also try to boot this TWRP (do not flash)
https://forum.xda-developers.com/t/official-twrp-3-2-3-0-for-essential-ph-1.3840931
you can decrypt pattern from adb too
https://twrp.me/faq/openrecoveryscript.html
(attachment removed)
aIecxs said:
are you sure that is actually the boot.img dumped off your current boot partition? there is a twrp.fstab inside? However, I have modified prop.default and added custom.rc in overlay.d to enable adb. try this without flashing, then check adb. if it works, you can run scrcpy (link above)
Code:
fastboot devices
fastboot boot boot.img
adb devices
in case it does not work, you could also try to boot this TWRP (do not flash)
https://forum.xda-developers.com/t/official-twrp-3-2-3-0-for-essential-ph-1.3840931
you can decrypt pattern from adb too
https://twrp.me/faq/openrecoveryscript.html
md5: 2baeb682f45ac1da8fcdbf75a60c99a4
Click to expand...
Click to collapse
Yeah it is, that is there probably because you need to install TWRP to the boot partition for the Essential Phone. Anyway, it didn't work sadly. I get the same result, all I got in device manager is "Essential MTP Device" and an inaccessible folder cause it's still locked. and it appears that twrp for the Essential Phone can't decrypt Android 12 data. I couldn't get it decrypted back when I could see my screen & used a pin either iirc
Renate said:
Just for fun a built a digitizer emulator. It will work even when the ADB is turned off.
Click to expand...
Click to collapse
How do I use it?
okay flash this boot.img to boot_a and boot_b and try again. I have added some flags for TWRP in recovery ramdisk too, maye it decrypts now. at least, it should enable adb. it may require ADB Interface Driver re-installed from device manager.
aIecxs said:
okay flash this boot.img to boot_a and boot_b and try again. I have added some flags for TWRP in recovery ramdisk too, maye it decrypts now. at least, it should enable adb. it may require ADB Interface Driver re-installed from device manager.
Click to expand...
Click to collapse
Unfortunately neither situation has changed, also reinstalled the ADB drivers
Zumbuh said:
Unfortunately neither situation has changed, also reinstalled the ADB drivers
Click to expand...
Click to collapse
can you please provide TWRP recovery.log after passing encoded pattern from cmd line?
Code:
adb shell twrp decrypt '12357'
adb pull /tmp/recovery.log
what custom ROM you are running?
maybe startup script requires u:r:init:0 secontext, or it is executed too early and just dropped before zygote? or maybe it is too late, as usually build.prop properties are triggers for init.rc so the resetprop is not working.
this is how I did
https://topjohnwu.github.io/Magisk/guides.html#root-directory-overlay-system
it will work, it's just a matter of right parameters. you can unpack boot.img your own and replace late-init with boot or post-fs-data or something different.
you can also try to write log to /cache partition and view from TWRP afterwards, so you will figure out script is even executed.
Zumbuh said:
How do I use it?
Click to expand...
Click to collapse
This was really just a proof of concept using a microcontroller that gets the swipe/click details from a desktop.
If you had a 2nd rooted Android that had HID USB Gadget built in (g_hid) it would be possible to write an app to do this.
You'd tether the two Androids together.
Edit: I did get it working with just the rooted Android and the target Android.
It's just a bit cumbersome to install. You need a custom USB config daemon and a udevd.
No design awards here, but it works.
I spend mostly 2 hours, I could change properties from overlay.d and also confirmed double check after boot. However, my Xiaomi denies any usb connection in case of modifications. So the default.prop trick did not work for me.
What worked is get a copy of %UserProfile%\.android\adbkey.pub rename it to adb_keys and copy to cache partition.
Code:
adb push %UserProfile%\.android\adbkey.pub /cache/adb_keys
adding these two files in boot.img overlay.d will copy /cache/adb_keys -> to /data/misc/adb/adb_keys. this worked for me, so give it one more shot.
aIecxs said:
I spend mostly 2 hours, I could change properties from overlay.d and also confirmed double check after boot. However, my Xiaomi denies any usb connection in case of modifications. So the default.prop trick did not work for me.
What worked is get a copy of %UserProfile%\.android\adbkey.pub rename it to adb_keys and copy to cache partition.
Code:
adb push %UserProfile%\.android\adbkey.pub /cache/adb_keys
adding these two files in boot.img overlay.d will copy /cache/adb_keys -> to /data/misc/adb/adb_keys. this worked for me, so give it one more shot. (edit: fixed)
Click to expand...
Click to collapse
I actually saw your earlier version of this reply so I was trying it myself, then when I went to reply I saw that you added a boot image and tried that as well. Though neither worked for me. I've attached my recovery.log though I assume the part you wanted to see was this.
I:operation_start: 'TWRP CLI Command'
Attempting to decrypt data partition via command line.
get_crypt_ftr_info crypto key location: ''
Unexpected value for crypto key location
Error getting crypt footer and key
Failed to decrypt data.
I:Done reading ORS command from command line
does phone have cache partition at all? you can check if /cache/adb_keys still exist. if you can see /cache/adb_keys.bak that is dump including all the existing keys. if not increase the timeout 60 seconds.
What ROM you are using? crypto-footer sounds more like FDE encryption, but I did only add flags FBE + metadata encryption.
kindly provide recovery.log. you can share via pastebin.com with expire date
aIecxs said:
does phone have cache partition at all? you can check if /cache/adb_keys still exist. if you can see /cache/adb_keys.bak that is dump including all the existing keys. if not increase the timeout 60 seconds.
What ROM you are using? crypto-footer sounds more like FDE encryption, but I did only add flags FBE + metadata encryption.
kindly provide recovery.log. you can share via pastebin.com with expire date
Click to expand...
Click to collapse
I'm using this Pixel Extended 12L rom. For whatever reason it wouldn't attach recovery.log to the last post, anyways here's the pastebin link
Starting TWRP 3.2.3-0-007de98f-dirty on Thu Jan 1 00:00:13 1970 (pid 601)I: - Pastebin.com
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
pastebin.com
the log is not from my (3) boot.img
I:Mount: Unable to find partition for path '/cache'
where did you place your adb_keys?
aIecxs said:
I:Mount: Unable to find partition for path '/cache'
where did you place your adb_keys?
Click to expand...
Click to collapse
In cache originally, but yeah I noticed that it didn't mount earlier as well. I did try placing them in a new directory I created and modifying the adbguard.sh file but it didn't work. The adb_keys file is still in that directory but there is no .bak file. Got anywhere else I could place it?
what directories can you access unencrypted on /data?
aIecxs said:
what directories can you access unencrypted on /data?
Click to expand...
Click to collapse
Seems the only one that isn't encrypted is /data/gsi
so you can place adbkey.pub there instead. change these lines in overlay.d/sbin/adbguard.sh. increase the timeout. you can also add some output to see if script is running at all.
Bash:
while [ ${i:-0} -le 60 ]; do
set_adbkey /data/gsi/adb_keys
echo "Hello World ($i)" >> /data/gsi/hello.txt
Code:
adb push adbkey.pub /data/gsi/adb_keys
according to the ROM you linked, that is just FBE encryption, I bet some dev can fix that TWRP.
/vendor/etc/fstab.mata
Code:
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/platform/soc/1da4000.ufshc/by-name/system / ext4 ro,barrier=1 wait,slotselect,verify
/dev/block/platform/soc/1da4000.ufshc/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc latemount,wait,check,formattable,fileencryption=ice,quota
/dev/block/platform/soc/1da4000.ufshc/by-name/misc /misc emmc defaults defaults
/dev/block/platform/soc/1da4000.ufshc/by-name/modem /vendor/firmware_mnt vfat ro,shortname=lower,uid=1000,gid=1000,dmask=222,fmask=333,context=u:object_r:firmware_file:s0 wait,slotselect
/dev/block/platform/soc/1da4000.ufshc/by-name/dsp /vendor/lib/dsp ext4 ro,nosuid,nodev,barrier=1,context=u:object_r:adsprpcd_file:s0 wait,slotselect
/devices/*/xhci-hcd.0.auto* auto auto defaults voldmanaged=usb:auto
/devices/*/0000:01:00.0* auto auto defaults voldmanaged=usb:auto
/dev/block/zram0 none swap defaults zramsize=2147483648,max_comp_streams=8
aIecxs said:
so you can place adbkey.pub there instead. change these lines in overlay.d/sbin/adbguard.sh. increase the timeout. you can also add some output to see if script is running at all.
Bash:
while [ ${i:-0} -le 60 ]; do
set_adbkey /data/gsi/adb_keys
echo "Hello World ($i)" >> /data/gsi/hello.txt
Code:
adb push adbkey.pub /data/gsi/adb_keys
according to the ROM you linked, that is just FBE encryption, I bet some dev can fix that TWRP.
/vendor/etc/fstab.mata
Code:
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/platform/soc/1da4000.ufshc/by-name/system / ext4 ro,barrier=1 wait,slotselect,verify
/dev/block/platform/soc/1da4000.ufshc/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc latemount,wait,check,formattable,fileencryption=ice,quota
/dev/block/platform/soc/1da4000.ufshc/by-name/misc /misc emmc defaults defaults
/dev/block/platform/soc/1da4000.ufshc/by-name/modem /vendor/firmware_mnt vfat ro,shortname=lower,uid=1000,gid=1000,dmask=222,fmask=333,context=u:object_r:firmware_file:s0 wait,slotselect
/dev/block/platform/soc/1da4000.ufshc/by-name/dsp /vendor/lib/dsp ext4 ro,nosuid,nodev,barrier=1,context=u:object_r:adsprpcd_file:s0 wait,slotselect
/devices/*/xhci-hcd.0.auto* auto auto defaults voldmanaged=usb:auto
/devices/*/0000:01:00.0* auto auto defaults voldmanaged=usb:auto
/dev/block/zram0 none swap defaults zramsize=2147483648,max_comp_streams=8
Click to expand...
Click to collapse
Alright I have replaced those lines and that file was never created, so it looks like it never runs the script

Categories

Resources