Database Users

[DEV Needed] Found way to write to local.prop, need help getting root

I found a way to write arbritary data to local.prop
Right now my local.prop (after reboot) looks like this
Code:
ro.sys.atvc_allow_netmon_usb=0
ro.sys.atvc_allow_netmon_usb=0
ro.sys.atvc_allow_netmon_ih=0
ro.sys.atvc_allow_res_core=0
ro.sys.atvc_allow_res_panic=0
ro.sys.atvc_allow_all_adb=0
ro.sys.atvc_allow_all_core=0
ro.sys.atvc_allow_efem=0
ro.sys.atvc_allow_bp_log=0
ro.sys.atvc_allow_ap_mot_log=0
ro.sys.atvc_allow_gki_log=0
#: comparing /system/preinstall/md5/#.md5 and /data/preinstall_md5/#.md5
#: install skipped, file unchanged
#: comparing /system/preinstall/md5/#.md5 and /data/preinstall_md5/#.md5
#: install skipped, file unchanged
ro.sys.atvc_allow_all_adb=1#: comparing /system/preinstall/md5/ro.sys.atvc_allow_all_adb=1#.md5 and /data/preinstall_md5/ro.sys.atvc_allow_all_adb=1#.md5
ro.sys.atvc_allow_all_adb=1#: install attempt 1 of 5 failed
ro.sys.atvc_allow_all_adb=1#: install attempt 2 of 5 failed
ro.sys.atvc_allow_all_adb=1#: install attempt 3 of 5 failed
ro.sys.atvc_allow_all_adb=1#: install attempt 4 of 5 failed
ro.sys.atvc_allow_all_adb=1#: install attempt 5 of 5 failed
preinstall finished, setting preinstall.done to 1
preinstall exiting...
I've tried a few variants, but adb keeps droping its root privileges. "adb root" and "adb remount" don't work either.
I'm guessing that either the local.prop gets parsed before the script runs, or that the garbage at the end prevents it from loading.
My knowledge of android died there, so if someone has any idea what can be tried, i'll give it a go.
How did i get there (in case someone wants to do the same):
I found out that on boot a script is run by the root user (/system/bin/installpreloads.sh) that writes /data/preinstall_md5/log.txt
/data/preinstall is world-writable, so i just deleted log.txt, and replaced it with a (soft) symbolic link to /data/local.prop.
Rebooted the phone and checked local.prop, and there was the output of the script.
Now, what it was writing at that point was no good (it was checking whether adobe flash app was installed), but there was a sign of hope:
The lines started with the app name (com.adobe.flashplayer, or something like that)
I took a look at the script and it checks for the apps in /preload (which is only readable by system so no chance to change that) and writes to the log file the names of the files it finds there.
A couple of days later, i realized (toying with sbf_flash) that the preinstall partition, isn't signed.
So i can change whatever i want on it, flash it with sbf_flash, and get the data i want into local.prop.
So i downloaded the Personal GB sbf and extracted it with the motorola depacker.
Luckily the preinstall patition is ext3, so i just mounted it changed the adobe package for one called "ro.sys.atvc_allow_all_adb=1#", unmounted it, flashed it and on next boot, my local.prop looked like that.

Please, anyone?
I know most of milestones 2 around the world are running rootable ROM's, but here in Argentina and Brasil, we are stuck with an unrootable 2.3.6 ROM.
I'd just like a tip on what to try next, or at least know whether it's not posible.
I feel I'm just a tweak away of rooting this ROMs, but I don't know what to do next.
Anything, any idea is welcomed.
Please...

Try to PM the devs e.g. tezet, sfc3001, --UFO--, Endless7, r2beta0 etc. Or may be even someone from Defy Devs like Quarkx n Epsylon3

Has there been any more progress with this?

Error -bad way
ADB shell write: permission denied!!!!! = ro.sys.atvc_allow_netmon_usb=0
nicofff said:
I found a way to write arbritary data to local.prop
Right now my local.prop (after reboot) looks like this
Code:
ro.sys.atvc_allow_netmon_usb=0
ro.sys.atvc_allow_netmon_usb=0
ro.sys.atvc_allow_netmon_ih=0
ro.sys.atvc_allow_res_core=0
ro.sys.atvc_allow_res_panic=0
ro.sys.atvc_allow_all_adb=0
ro.sys.atvc_allow_all_core=0
ro.sys.atvc_allow_efem=0
ro.sys.atvc_allow_bp_log=0
ro.sys.atvc_allow_ap_mot_log=0
ro.sys.atvc_allow_gki_log=0
#: comparing /system/preinstall/md5/#.md5 and /data/preinstall_md5/#.md5
#: install skipped, file unchanged
#: comparing /system/preinstall/md5/#.md5 and /data/preinstall_md5/#.md5
#: install skipped, file unchanged
ro.sys.atvc_allow_all_adb=1#: comparing /system/preinstall/md5/ro.sys.atvc_allow_all_adb=1#.md5 and /data/preinstall_md5/ro.sys.atvc_allow_all_adb=1#.md5
ro.sys.atvc_allow_all_adb=1#: install attempt 1 of 5 failed
ro.sys.atvc_allow_all_adb=1#: install attempt 2 of 5 failed
ro.sys.atvc_allow_all_adb=1#: install attempt 3 of 5 failed
ro.sys.atvc_allow_all_adb=1#: install attempt 4 of 5 failed
ro.sys.atvc_allow_all_adb=1#: install attempt 5 of 5 failed
preinstall finished, setting preinstall.done to 1
preinstall exiting...
I've tried a few variants, but adb keeps droping its root privileges. "adb root" and "adb remount" don't work either.
I'm guessing that either the local.prop gets parsed before the script runs, or that the garbage at the end prevents it from loading.
My knowledge of android died there, so if someone has any idea what can be tried, i'll give it a go.
How did i get there (in case someone wants to do the same):
I found out that on boot a script is run by the root user (/system/bin/installpreloads.sh) that writes /data/preinstall_md5/log.txt
/data/preinstall is world-writable, so i just deleted log.txt, and replaced it with a (soft) symbolic link to /data/local.prop.
Rebooted the phone and checked local.prop, and there was the output of the script.
Now, what it was writing at that point was no good (it was checking whether adobe flash app was installed), but there was a sign of hope:
The lines started with the app name (com.adobe.flashplayer, or something like that)
I took a look at the script and it checks for the apps in /preload (which is only readable by system so no chance to change that) and writes to the log file the names of the files it finds there.
A couple of days later, i realized (toying with sbf_flash) that the preinstall partition, isn't signed.
So i can change whatever i want on it, flash it with sbf_flash, and get the data i want into local.prop.
So i downloaded the Personal GB sbf and extracted it with the motorola depacker.
Luckily the preinstall patition is ext3, so i just mounted it changed the adobe package for one called "ro.sys.atvc_allow_all_adb=1#", unmounted it, flashed it and on next boot, my local.prop looked like that.
Click to expand...
Click to collapse

[GUIDE] Fix "assert failed: apply_patch_check" error

Overview:
This thread is a guide on how to fix the apply_patch_check error message experienced during an upgrade of the Android OS. Specifically, this will detail the steps for an upgrade of Jelly Bean from 4.1.1 to 4.1.2 on the Nexus 7 with CWM Recovery for a user of Windows. I'm sure similar steps will work for other recoveries/upgrades/devices and PC OSes.
You should only bother with this if you don't want to flash the entire system.img file to your phone, which is way easier.
Here is an example of the error message I'm talking about:
Code:
assert failed: apply_patch_check("/system/app/Chrome.apk", "819b34b66335c6faec86404d736a002b8871600", "9d6b55e63b0bf20bea433fb1ee7089f88ab73fb6")
E: Error in /sdcard/03a4eaf95f73.signed-nakasi-JZO54K-from-JRO03D.03a4eaf9.zip
(Status 7)
Installation aborted.
A few notes about the error:
This doesn't have to happen with the Chrome.apk specifically -- it could happen with any app in /system/app or .so in /system/lib.
Those random strings of numbers/letters are SHA-1 hashes of the apk.
The first one is the hash of the apk installed on your device. In my example, this happens to be the version of Chrome that comes with JB 4.1.2.
The second one is the expected hash of the apk that comes with JB 4.1.1.
Cause of the problem:
The reason this error occurs is because the file was somehow modified from its original state. In my case -- and most likely your case -- this was done by Titanium Backup. TB has an option to "Integrate updates of system apps into ROM", which will cause the apk in /system/app (and associated library files in /system/lib, if needed) to be overwritten with the updated apk.
Solution:
Download this zip file which contains the full /system/app and /system/lib directory from the JB 4.1.1 factory image. *
Extract the zip to a location of your choosing on your PC.
In the extracted folder, locate the .apk or .so file referenced in the error message on your device.
Copy this file to your device via your preferred method (USB cable works fine). I put my file in /sdcard/Download.
On your device, use a root file explorer to move the file from /sdcard/Download to /system/app (or /system/lib).
If you don't have a program that can do this, I use ES File Explorer. Be sure to go to Settings > Root Settings and turn on Root Explorer, Up to Root, and Mount File System.
Reboot into your Recovery and try to install the update again.
Repeat steps 3-6 for each subsequent file that produces an error. You will basically need to do this for each app you integrated using TB and maybe a few library files, too. **
* Future updates (above 4.1.2):
Since I won't be keeping the zip file from step #1 up-to-date, here's how to get the directories that I included in the zip for yourself:
Obtain a factory image for your device's current Android version (the version you're updating from).
For JB 4.1.1, this file is called nakasi-jro03d-factory-e102ba72.tgz.
If you're reading this guide at a later date, the JB 4.1.2 file is called nakasi-jzo54k-factory-973f190e.tgz.
You can try your luck at the official Google site, but they seem to only provide the version you're trying to update to, not from.
Extract the .tgz file somewhere on your PC.
Locate the image-naksi-jro03d.zip file and extract that, as well.
In the folder you just extracted from the previous step, located the system.img file.
Download and use a program called sgs2toext4 (View attachment 645320) to convert the system.img to system.ext4.img. ***
Download and use a program called Linux Reader to open system.ext4.img.
Do this by going to Drives > Mount Image > Next > select your file.
It will then be listed under the Hard Disk Drives section in red as "Linux Ext Volume 1".
Navigate to: Linux Ext Volume 1/system.
Right-click on the app (or lib) directory and pick Save > Next > Output to dir of your choice.
You now have the directories that were included with the zip file from Solution step #1, so just follow those steps now.
** How to avoid repeating steps:
If you'd rather not have to try to reinstall after updating only one file, just to find another file that needs updating, try this:
Obtain the /system/app and /system/lib folders from the factory image and save them to your PC.
For the sake of this guide, let's say you save them to C:\factory_app and C:\factory_lib.
Copy the /system/app and /system/lib directories from your phone to your PC.
For the sake of this guide, let's say you saved them to C:\phone_app and C:\phone_lib.
Download the File Checksum Integrity Verifier utility from Microsoft.
Start > Run > cmd
fciv.exe -sha1 -xml factory_app.xml -wp C:\factory_app
fciv.exe -sha1 -xml factory_app.xml -v -bp C:\phone_app
Don't ask me why, but you need to use -bp instead of -wp for the second command.
Don't forget the -v on the second command.
The output of the last command will show you the list of files that are different. These are the files you need to take from C:\factory_app and put into the /system/app directory on your phone.
Do the same for the lib directories (just replace all instances of "_app" with "_lib" in the previous commands).
Summary:
I hope that this post helped some of you who really didn't want to have to flash the system.img or wipe your device just to update. In the future, use TB to back up the original.
I wouldn't normally bother writing up a guide like this (it took almost as long to write as it did to figure out how to do this) but I couldn't find this solution anywhere even though I saw that I wasn't the only person with the problem. Sorry for not posting this guide sooner (update has been out for a while now), but the forum required me to make a bunch of useless spam posts before I could include any links in my guide and I didn't get around to making those posts right away.
*** I would like to thank balamu96m for his guide on extracting data from the system.img file and drphrozen for making the sgs2toext4 program.

Thanks for this. Will try now.
Worked great. Had to copy the apk and odex file.

Good job! It's great to see the steps for Windows users!

Just a heads up that I simply extracted the files I needed from and on my N7 using Root Explorer, without using my PC at all.

Great guide! Method worked perfectly on my Nexus 7 going from 4.1.2 to 4.2, thanks

Please... is there some other way to update the files w/o installing Java on my Windoze PeeCee? I accidentally messed up my YouTube.apk with Titanium Backup... now I can't update from 4.1.2 --> 4.2 JB.
EDIT: JavaPortable FTW... updating (fingers crossed)
EDIT: SUCCESS TY OP!

For anyone who flashed the 4.2 clock/keyboard already
Hey, for anyone who flashed the 4.2 clock and keyboard on their Nexus 7 already and need to roll back to do the 4.2 update, I used OP's method to make a flashable zip that puts the 4.1.2 clock and keyboard back.
Worked perfectly for my Nexus 7 to get me up and running. Hope it helps anyone!
cantthinkofa.com/files/RestoreClockKeyboard.zip

galaxy nexus
Hi can you post a guide for galaxy nexus? Or if it is the same, can you post the link of JB factory image for galaxy nexus? Sorry, I can't find any thread for galaxy nexus, and I don't want to complete flash the stock image since I don't want to wipe my phone.
Thanks in advance!

Nice Guide
perfect, the guide works just fine. Now finally running 4.2.

Awesome guide... Thanks... Happily running 4.2 now aften beeing stuck at libutils.so...
Sent from my Nexus 7 using xda premium

damagno said:
Hi can you post a guide for galaxy nexus? Or if it is the same, can you post the link of JB factory image for galaxy nexus? Sorry, I can't find any thread for galaxy nexus, and I don't want to complete flash the stock image since I don't want to wipe my phone.
Thanks in advance!
Click to expand...
Click to collapse
I don't have a Galazy Nexus, but I think the steps should be the same. Here is a link to the factory images: https://developers.google.com/android/nexus/images#takju . It looks like they now have links for older versions, rather than just the newest images (which is how it was when I made my guide). So that's pretty sweet.

Thanks a lot man, i succeeded to "patch" my system files to update from 4.2 to 4.2.1. I first check what files didn't correspond with fciv (9 files counting both apks and odex) and then replaced them in system/app. In fact they were the apps I previously integrated with tb (learned lesson: never do it if you want to remain stock and receive OTAs). I also noticed many not-matching files in system/lib but i didn't touch them and the update went smooth the same.
Another thing: when in the OP you say it's way easier just to reflash the system.img you mean just run from bootloader "fastboot flash system system.img" (taken from the factory image as usual) or there's some other thing to do in order to fix the system partition in the right way?

GallStones said:
Thanks a lot man, i succeeded to "patch" my system files to update from 4.2 to 4.2.1.
Click to expand...
Click to collapse
I was wondering if you could tell me how you did it? I'm searching a way to install 4.2.1 with no avail as of yet :crying:

GallStones said:
Thanks a lot man, i succeeded to "patch" my system files to update from 4.2 to 4.2.1. I first check what files didn't correspond with fciv (9 files counting both apks and odex) and then replaced them in system/app. In fact they were the apps I previously integrated with tb (learned lesson: never do it if you want to remain stock and receive OTAs). I also noticed many not-matching files in system/lib but i didn't touch them and the update went smooth the same.
Another thing: when in the OP you say it's way easier just to reflash the system.img you mean just run from bootloader "fastboot flash system system.img" (taken from the factory image as usual) or there's some other thing to do in order to fix the system partition in the right way?
Click to expand...
Click to collapse
Yes. I am having the same issue. I cannot update mine from 4.2 to 4.2.1. I wonder to know which original stock image you have used. Can you list a detail procedure?
Thank you very much.
Ric

dev/block/param
legom said:
Overview:
This thread is a guide on how to fix the apply_patch_check error message experienced during an upgrade of the Android OS. Specifically, this will detail the steps for an upgrade of Jelly Bean from 4.1.1 to 4.1.2 on the Nexus 7 with CWM Recovery for a user of Windows. I'm sure similar steps will work for other recoveries/upgrades/devices and PC OSes.
You should only bother with this if you don't want to flash the entire system.img file to your phone, which is way easier.
Here is an example of the error message I'm talking about:
Code:
assert failed: apply_patch_check("/system/app/Chrome.apk", "819b34b66335c6faec86404d736a002b8871600", "9d6b55e63b0bf20bea433fb1ee7089f88ab73fb6")
E: Error in /sdcard/03a4eaf95f73.signed-nakasi-JZO54K-from-JRO03D.03a4eaf9.zip
(Status 7)
Installation aborted.
A few notes about the error:
This doesn't have to happen with the Chrome.apk specifically -- it could happen with any app in /system/app or .so in /system/lib.
Those random strings of numbers/letters are SHA-1 hashes of the apk.
The first one is the hash of the apk installed on your device. In my example, this happens to be the version of Chrome that comes with JB 4.1.2.
The second one is the expected hash of the apk that comes with JB 4.1.1.
Cause of the problem:
The reason this error occurs is because the file was somehow modified from its original state. In my case -- and most likely your case -- this was done by Titanium Backup. TB has an option to "Integrate updates of system apps into ROM", which will cause the apk in /system/app (and associated library files in /system/lib, if needed) to be overwritten with the updated apk.
Solution:
Download this zip file which contains the full /system/app and /system/lib directory from the JB 4.1.1 factory image. *
Extract the zip to a location of your choosing on your PC.
In the extracted folder, locate the .apk or .so file referenced in the error message on your device.
Copy this file to your device via your preferred method (USB cable works fine). I put my file in /sdcard/Download.
On your device, use a root file explorer to move the file from /sdcard/Download to /system/app (or /system/lib).
If you don't have a program that can do this, I use ES File Explorer. Be sure to go to Settings > Root Settings and turn on Root Explorer, Up to Root, and Mount File System.
Reboot into your Recovery and try to install the update again.
Repeat steps 3-6 for each subsequent file that produces an error. You will basically need to do this for each app you integrated using TB and maybe a few library files, too. **
* Future updates (above 4.1.2):
Since I won't be keeping the zip file from step #1 up-to-date, here's how to get the directories that I included in the zip for yourself:
Obtain a factory image for your device's current Android version (the version you're updating from).
For JB 4.1.1, this file is called nakasi-jro03d-factory-e102ba72.tgz.
If you're reading this guide at a later date, the JB 4.1.2 file is called nakasi-jzo54k-factory-973f190e.tgz.
You can try your luck at the official Google site, but they seem to only provide the version you're trying to update to, not from.
Extract the .tgz file somewhere on your PC.
Locate the image-naksi-jro03d.zip file and extract that, as well.
In the folder you just extracted from the previous step, located the system.img file.
Download and use a program called sgs2toext4 (View attachment 645320) to convert the system.img to system.ext4.img. ***
Download and use a program called Linux Reader to open system.ext4.img.
Do this by going to Drives > Mount Image > Next > select your file.
It will then be listed under the Hard Disk Drives section in red as "Linux Ext Volume 1".
Navigate to: Linux Ext Volume 1/system.
Right-click on the app (or lib) directory and pick Save > Next > Output to dir of your choice.
You now have the directories that were included with the zip file from Solution step #1, so just follow those steps now.
** How to avoid repeating steps:
If you'd rather not have to try to reinstall after updating only one file, just to find another file that needs updating, try this:
Obtain the /system/app and /system/lib folders from the factory image and save them to your PC.
For the sake of this guide, let's say you save them to C:\factory_app and C:\factory_lib.
Copy the /system/app and /system/lib directories from your phone to your PC.
For the sake of this guide, let's say you saved them to C:\phone_app and C:\phone_lib.
Download the File Checksum Integrity Verifier utility from Microsoft.
Start > Run > cmd
fciv.exe -sha1 -xml factory_app.xml -wp C:\factory_app
fciv.exe -sha1 -xml factory_app.xml -v -bp C:\phone_app
Don't ask me why, but you need to use -bp instead of -wp for the second command.
Don't forget the -v on the second command.
The output of the last command will show you the list of files that are different. These are the files you need to take from C:\factory_app and put into the /system/app directory on your phone.
Do the same for the lib directories (just replace all instances of "_app" with "_lib" in the previous commands).
Summary:
I hope that this post helped some of you who really didn't want to have to flash the system.img or wipe your device just to update. In the future, use TB to back up the original.
I wouldn't normally bother writing up a guide like this (it took almost as long to write as it did to figure out how to do this) but I couldn't find this solution anywhere even though I saw that I wasn't the only person with the problem. Sorry for not posting this guide sooner (update has been out for a while now), but the forum required me to make a bunch of useless spam posts before I could include any links in my guide and I didn't get around to making those posts right away.
*** I would like to thank balamu96m for his guide on extracting data from the system.img file and drphrozen for making the sgs2toext4 program.
Click to expand...
Click to collapse
my error 7 was generated by emmc: dev/block/mmdblk0p7 (the file is "param" any suggestions?

Thanks. After searching for a lot of time, this post helped me updating my SGS3.:victory: I previously tried to integrate youtube update into rom using titanium backup.

GallStones said:
Another thing: when in the OP you say it's way easier just to reflash the system.img you mean just run from bootloader "fastboot flash system system.img" (taken from the factory image as usual)
Click to expand...
Click to collapse
Yes, that's what I mean. The reason I didn't want to do this on my device is because I had modified some other system files that I wanted to keep the modifications for.

Wow, thanks a lot OP! Your guide helped me fixing an error during the update to 4.2.2 on my Nexus 4.

please include a video ,im getting lost in the details

solved.

Can't restore TWRP backup

I have two N4s with broken screens, one of which has USB debugging enabled etc.
I created a TWRP backup of boot, system & data on the one with USB enabled and transferred it over to the other one.
I now can't restore that backup. I have to use TWRP's open recovery script in an ADB shell because the screens are broken. I am using:
Code:
adb shell twrp restore /data/media/0/TWRP/BACKUPS/"serial no"/
but which initially works, then says "no partitions selected for restore".
If I put "SDBM" after the path, it says "setting restore options: SDBM" then the same thing - "no partitions selected for restore".
If I put "SDBM" after "restore" i.e. before the path name it says "Restoring SDBM... Unable to locate backup 'SDBM'"
I can't find any help via google and I'm stuck now - how can I restore a backup with adb shell twrp?

mrmrchoice said:
I have two N4s with broken screens, one of which has USB debugging enabled etc.
I created a TWRP backup of boot, system & data on the one with USB enabled and transferred it over to the other one.
I now can't restore that backup. I have to use TWRP's open recovery script in an ADB shell because the screens are broken. I am using:
Code:
adb shell twrp restore /data/media/0/TWRP/BACKUPS/"serial no"/
but which initially works, then says "no partitions selected for restore".
If I put "SDBM" after the path, it says "setting restore options: SDBM" then the same thing - "no partitions selected for restore".
If I put "SDBM" after "restore" i.e. before the path name it says "Restoring SDBM... Unable to locate backup 'SDBM'"
I can't find any help via google and I'm stuck now - how can I restore a backup with adb shell twrp?
Click to expand...
Click to collapse
From what you wrote, I see that you provided the path to the backup directory instead of to the specific backup directory.
Your path is too short because it does not contain the name of the directory that was created during the backup.
If possible, always try to paste a significant piece of text from the terminal where you performed the action, it really makes it easier to find a solution.

ze7zez said:
From what you wrote, I see that you provided the path to the backup directory instead of to the specific backup directory.
Your path is too short because it does not contain the name of the directory that was created during the backup.
If possible, always try to paste a significant piece of text from the terminal where you performed the action, it really makes it easier to find a solution.
Click to expand...
Click to collapse
Hi, thanks, I got there not long after I posted this HOWEVER adding the specific backup directory now gives me an error about digest verification (I didn't generate an MD5 hash when I made the backup). This is when trying to restore using the same flag that I used to skip MD5 generation when I made the backup.
It asks me to deselect digest verification but I can't do that on the touch screen (as it's broken) and don't know if it's possible to do this via abd?
Thanks!

OP 5T - FBE /dev/block/sda13 or /data partition - file restoration / residues scan

Hello,
unfortunately, my Google Keep app had just decided to wipe its db file up. (/data/data/com.google.android.keep/databases/keep.db)
It is not (and never was) synchronized to Google.
When it happened I just copied (dd'ed over adb) /dev/block/sda13.
From mount command output, I could recognized /dev/block/sda13 as /data backing block device.
Then I did some searches in the output image file and noticed it actually encrypted per file.
I learned from it OP uses FBE (file-based-encryption). I wanted to try and run some ext4 recovery tools (autopsy, undelete ...).
FBE encrypts also filenames so I can't use the generated image as is.
I checked what caused FBE on /data partition and it's the encryption setting. I read it uses the fingerprint/pattern/password to decrypt the encrypted /data.
I didn't power-off the phone since then to avoid any more losses.
My questions:
1. Given /dev/block/sda13 as an image file, how can one decrypt it and use forensics/restoration tools on it?
2. Another option - how to acquire the unencrypted /dev/block/sda13 from the running device?
3. Maybe there is some backup partition for files in /data?
4. Can I run the mentioned tools straight on some unencrypted device file? (Assuming cross-compilation to android)
5. Any caches/other places I can search for residues? (I tried dumping CursorWindow ashmem the Keep app used but the app has restarted since then)
6. OP compiled the kernel without DEVMEM. Maybe there is other option to acquire the whole RAM to try to scan for residues?
More side-notes:
- I tried other files in the Keep app directory to try to recover some residues, pictures where saved outside the db file so I was able to restore them (but what is important are the notes stored in the db itself(
- I was able to notice keep.db was replaced with an empty sqlite3 db file (for some strange reason ...). My guess was it didn't overridden the original db file so if I had the ext4 /data partition, I will be able to scan it with the tools mentioned above.
References:
* https://forum.xda-developers.com/t/...-encrypt-data-partition-on-oneplus-5.3642144/
* https://www.cs1.tf.fau.de/research/system-security-group/one-key-to-rule/
If some details are missing, please let me know!

https://www.cs1.tf.fau.de/research/system-security-group/one-key-to-rule/ is really interesting.
The problem now is how to get a full memory dump without /proc/mem and signed kernel modules.

Any help? I'm out of ideas but it seems like a solvable problem.

[SOLVED] Restore decrypted nandroid backup of FBE

Tried restoring a nandroid backup of the data partition with twrp.
also copied the /data/media partition back from an external copy.
when booting up the phone immediately reboots back into twrp with an error message:
Android Rescue Party...
The reported problem is:
'--reason=set_policy_failed_:/data/vendor'
the vendor partition seems to be intact and i do have a backup of it taken at the same time as the data backup, restoring it doesn't yield results..
i'm wondering if FBE is throwing it off, as the backup was taken when the phone was decrypted (within twrp) however the data on the partitions is referencing some sort of encryption key?

you may also exhibit the following error upon bootup of a restored nandroid backup.
immediately after booting, the phone reboots back into recovery.
viewing the log in twrp will show:
Android Rescue Party...
The reported problem is:
'--reason=set_policy_failed_:/data/bootchart'
1. the solution to this is editing fstab.​​under twrp or other recovery​mount /vendor from the mount icon.​​in twrp: Advanced > File Manager > /vendor/etc/fstab.qcom​select edit file under userdata, find where it says fileencryption=ice​rename fileencryption to encryptable.​​Original​
Code:
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,fileencryption=ice,quota,reservedsize=512M
​​Modified​
Code:
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=ice,quota,reservedsize=512M
​save file.​
2. next delete the following directories:​
/data/unencrypted
/data/misc/vold/user_keys
3. Lastly delete any of the existing files from /data/system/ :​
locksettings.db
Gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db-shm
locksettings.db-wal
recoverablekeystore.db
password.key
pattern.key
4. Reboot and re-encrypt​​
At this point rebooting from recovery will result in a running and successfully recovery backup.
one thing to note is the data and data/media partitions are at this point unencrypted
TRYING TO REINCRYPT NOW WILL FAIL to reencrypt got to settings > security > re set your pin or password for the phone
(optional) then select encryption and there will be an orange button to encrypt device.
the encryption process will take quite a while as it will reencrypt your entire phone.
The above doesn't work as it's trying to accomplish FDE, and the fstab line for encryptable=ice, isn't compatible with this.
i could not find an fstab string to follow the same option but for FBE.
​

Thanks for sharing, nice guide to disable forced FBE encryption! I think this applies to Android 12+ in general, not just OnePlus devices.
I ended up with the same problem on my Mi 10 Ultra with MIUI 13 after a /data partition restore and it was a real pain to solve ("set_policy_failed:..." rescue party error for different directories). It's strange though why it fails to set the fscrypt policy for existing directories with no policy, correct permissions and SELinux context...
(Btw: whether a fscrypt policy is applied to a directory ("is this directory encrypted?") can be checked with fscryptpolicyget in terminal.)
Unfortunately, this didn't directly solve my TWRP backup restore problem and I still had to do a manual restore, but now I can at least disable FBE and it's always nice to have actual control over the device you paid money for (you should really have control by default, but oh well...)
(Some of) the troubleshooting I did:
Like I mentioned, I first thought the issue might be with the SE linux context, so I tried running restorecon, but this didn't help - I eventually found that in init.rc, restorecon is usually already automatically run during each boot for directories under /data/... so running it manually makes no difference.
To edit /vendor/etc/fstab.qcom (or /system) on my device, I had to first disable the shared blocks EXT4 optional feature. I followed this nice guide to unpack/repack super.img. But this is missing the step for disabling shared blocks: when I tried to mount any of the unpacked images (e.g. vendor.img) as R/W, it failed with the useless generic error:
wrong fs type, bad option, bad superblock on ...
Click to expand...
Click to collapse
Then dmesg gave me another clue, but at the same time was still cryptic and not immediately helpful:
EXT4-fs (loop*): couldn't mount RDWR because of unsupported optional features (4000)`.
Click to expand...
Click to collapse
So I guess 4000 is the code for shared blocks and you can disable these with e2fsck -E unshare_blocks <your .img file or loop device> (and probably need a filesystem check with e2fsck -yf <file>). Again very annoying that these numerical feature codes are not mentioned anywhere in the e2fsck manual pages for example.
Anyway, I was finally able to either:
1. mount vendor.img on my PC (mount -o loop vendor.img /mnt/vendor) and edit the /mnt/vendor/etc/fstab.qcom right there before repacking the .img and flashing the new edited super.img to my device
or
2. just repacking the vendor.img with shared blocks disabled and size increased (resize2fs vendor.img <new size>) and flashing the new super.img without other modifications - this way /vendor can also be mounted as r/w in Android and changes made later (mount -o remount,rw /vendor).
The worst part is that in the end, even with decryption disabled and the keys deleted, the device still wouldn't boot after a /data restore from TWRP (and after multiple days spent on debugging )... I still had to manually extract the TWRP backup and move directories/files individually - thankfully no issues with app/ or data/ - I think the problem was with some files in either system/ or misc/, but idk for sure. I just manually went through and kept only what seemed important (saved wifi APs, BT devices, SMSs etc, but not saved accounts). And after this it finally booted with all my apps and (most of) my settings!
(Btw2: a TWRP/nandroid backup is apparently just a bunch of separate tar.gz files, not a split archive, so you can just extract them with for file in ../data.f2fs.win*; do echo "extracting $file..."; busybox tar -xzf $file; done)