Related
There are small differences between the OTA-2.1 and the Leak-V3. Tiny might be a better adjective.
This involves two files which are present (post install) in the OTA-2.1 which are not present in the Leak-V3 PB00IMG.ZIP file, and two files which are in the Leak-V3 PB00IMG.ZIP ROM file not present in OTA-2.1.
After a short background, I give my results. (For those with a high tolerance for boredom a complete description of the methodology I used follows that.)
Background
Back in mid-May, thenestor compared a significant fraction of the files in the OTA-2.1 http: download to the files unpacked from the Leak-V3 PB00IMG.ZIP.
Two days ago I extended that check to include all files, including those which undergo binary patching on the phone during the OTA-2.1 install. (This patching is performed by the HTC recovery boot as part of the OTA-2.1 install).
Summary of Results
The essential result is the strengthening of the conclusion that OTA-2.1 and Leak-V3 are identical. By file count, there are 4 differences among 813 files - a 99.5% match. There are no instances where there are two versions of the same file between the two installs.
The "system" partition of OTA-2.1 is essentially identical to Leak-V3, with the exception of 2 files which are present in OTA-2.1, and missing in Leak-V3.
The boot and recovery partitions are 100% identical.
The Leak-V3 install wipes clean the pre-existing /data mount point, and installs only two files into /data; these two files are not found post-install in the OTA-2.1.
Detailed Results
system partition ( /system mount point )
100% of files in the Leak-V3 /system partition identically match files in the post-install OTA-2.1 /system.
There are 2 files present in the /system folder of the OTA-2.1 which are not present in the Leak-V3 release:
/system/app/UpgradeSetup.apk
/system/xbin/modem_link
Based on name alone (rather than trying to decipher classs.dex within UpgradeSetup.apk by de-odexing) it seems reasonable that the OTA-2.1 upgrade only needs "partial" setup because it is an overlay rather than a wipe. Perhaps that is why this "app" is not present in Leak-V3.
The latter file - /system/xbin/modem_link ? I don't know what it does; it has some rather curious string data in it.
data partition ( /data mount point )
The OTA-2.1 process contains no files which are loaded into the /data partition, and only deletes unneeded cache and application parameter settings within the pre-existing /data partition; this is done under control of the update-script.
The leak-V3 ROM, which is a "wipe" or "factory reset" type of operation, drops only two files into the /data partition:
/data/app/PingTool.apk
/data/local/dmdata/00004
Neither of these files are found in a (clean MR2 to) OTA-2.1 phone's /data partition following completion of the OTA-2.1 upgrade. I do not know what role these files play - the classes.dex files and some of the .xml files in the .apk suggest an IP-layer network diagnostic capability (ping, traceroute), as well as IP route manipulation.
boot, recovery partitions
As mentioned previously - bit-by-bit identical between Leak-V3 and OTA-2.1
Conclusion
Are OTA-2.1 and Leak-V3 identical? Technically, NO. But as far as all the system executables, libraries, and pre-installed applications are concerned, YES. There are four small differences - which appear to be in areas where phone owners typically do not venture.
Methodology (Read at peril of boredom)
1) Write scriptware (*nix) to compare two complete filesystem trees, looking for match/mismatch in MD5 hashes, as well as reporting missing files. For completeness, the script works bijectively - it first examines all files found in TreeA relative to TreeB, and then reverses this (all files in TreeB relative to TreeA). This catches all missing files (which are in A, but not B; or alternatively are in B but not A). This script does not (presently) examine file modes, ownership, or timestamps, nor does it look at symlinks or directories; so differences of that nature are unexamined here.
2) Unpack partitions from the Leak-V3 PB00IMG.ZIP file using appropriate tools into separate directory (subtrees).
3) Perform a 1.5 full factory rollback on the phone, including bootloader and radio, followed by an OTA-2.1 update. Install 1.49 S-OFF bootloader (only, via battery pull trick), and then soft-load Amon_RA v1.6.2 via a fastboot "boot" operation ("fastboot boot recovery-RA-eris-v1.6.2.img")
4) Via adb (to the Amon_RA recovery soft-boot), perform:
- mkyaffs2image on system and data partitions (output goes to SD card)
- dump_image on recovery and boot partitions (again, output goes to SD card)
5) Pull all images to the PC and
- unpack the system and data images via "unyaffs"
- **unpack the boot and recovery images with split_bootimg.pl and then
- **unpack the ramdisk (gunzip -c bootimg-ramdisk.gz | cpio -i)
** For Leak-V3 vs. OTA-2.1, this step is superfluous, as both ship the contents of these partitions as monolithic ".img" files, which have the same MD5 has in both. (I did this step to set up comparisons against Leak-V2 and Leak-V1, which I am not reporting on here)
6) Run the analysis script to compare trees
bftb0
WOW
very informative
bftb0, thanks once again for such awesome information. I'd be interested in seeing the script you wrote, although I'd understand if you didn't share it.
nindoja said:
bftb0, thanks once again for such awesome information. I'd be interested in seeing the script you wrote, although I'd understand if you didn't share it.
Click to expand...
Click to collapse
Sent you a link to a pastebin in PM. It's cruftware, not lebenswerk. Don't take it too seriously.
Very intersting. I'm really trying to get into all this coding and dev. stuff. Thanks for the post. Always nice to learn new things.
I'm sorry, but I don't understand ANY of that. Are they really the same or are they different ? I have the v3 leak installed and I really want to install the "official" firmware. Should I ?
hallstevenson said:
I'm sorry, but I don't understand ANY of that. Are they really the same or are they different ? I have the v3 leak installed and I really want to install the "official" firmware. Should I ?
Click to expand...
Click to collapse
You need to install the "Official Leak-V8". It's identical to Leak-V3, but there is a picture of a bunch of carrots on the package it comes in. Waaaay better than V3.
Wow great post thanks!
-------------------------------------
Sent via the XDA Tapatalk App
Seriously though, excellent information. Myself and a number of others have been repeating endlessly that the last leak and the OTA were really the same but some just refused to believe it. Even after 'thenestor' did the MD5 comparison and "proved" it, it didn't seem to matter to some ("what's MD5 ?"). Now there's a 2nd backup to help prove it. Hopefully it works !
Thanks for the info. Basically the operation and functionality of the two versions are the same, just a couple of files in one that aren't in the other, but the end user won't notice a bit of difference.
-------------------------------------
Sent from my HTC Droid Eris using Swype
Hello all, I'm totally newb to flashing ROM so please take it easy if the question is redundant. I have flashed and got this Gingerbread ROM from MDJ (http://forum.xda-developers.com/showthread.php?t=877777) running perfectly fine. In his instruction, he uses the 250MB partition. So after installation of a lot of apps, my system storage is listed as:
Total: 250MB, Free: 123MB. (I got these numbers from Quick System Info)
I guess the ROM only used 127MB? I'm thinking changing the flash.cfg file like this,
From "system ya 250M" to "system ya 130M" so that would give me a few more MB in the userdata partition.
Is that gonna break something I don't know about?
erythrophilia said:
Hello all, I'm totally newb to flashing ROM so please take it easy if the question is redundant. I have flashed and got this Gingerbread ROM from MDJ (http://forum.xda-developers.com/showthread.php?t=877777) running perfectly fine. In his instruction, he uses the 250MB partition. So after installation of a lot of apps, my system storage is listed as:
Total: 250MB, Free: 123MB. (I got these numbers from Quick System Info)
I guess the ROM only used 127MB? I'm thinking changing the flash.cfg file like this,
From "system ya 250M" to "system ya 130M" so that would give me a few more MB in the userdata partition.
Is that gonna break something I don't know about?
Click to expand...
Click to collapse
First of all that will wipe your existing installation / data clean. Hope you understand that. Secondly, it should work fine but doesn't leave you much space at all on your system partition. I would add a little more- maybe 135M or 140M.
I see. I already have a CWM backup so the data won't be a problem. So that means the size specified in flash.cfg isn't directly linked to other things? I mean like if I change it, and the ROM boots up, it looks for the right size, and then if the original size isn't there, it will refuse to boot.
But anyway, I'll experiment with it later today. Thanks.
erythrophilia said:
From "system ya 250M" to "system ya 130M" so that would give me a few more MB in the userdata partition.
Is that gonna break something I don't know about?
Click to expand...
Click to collapse
I have been flashing Nand roms but until now i dont understand how to edit flash cfg. there is no choice in the clockwork recovery that has such option. I know it may sound silly.Thank you
jad71 said:
I have been flashing Nand roms but until now i dont understand how to edit flash cfg. there is no choice in the clockwork recovery that has such option. I know it may sound silly.Thank you
Click to expand...
Click to collapse
You have to edit the flash.cfg in notepad before you flash it on your phone
Cant find flash.cfg
acho07 said:
You have to edit the flash.cfg in notepad before you flash it on your phone
Click to expand...
Click to collapse
i also face similar issues, can u explain where to find the flash.cfg file.
azi43far said:
i also face similar issues, can u explain where to find the flash.cfg file.
Click to expand...
Click to collapse
When you download clockwork recovery on your computer, in the extracted folder there should be a file "flash.cfg" open that in notepad and change the values to whatever you require then flash it using the daf.exe via usb flasher in magldr.
Just adding this information if someone stumbles onto this article again :
Description of flash.cfg format
===============================
1. each line define one partition
2. maximum number of partitions is 16
3. order of partitions are same like lines in the file
4. line format: <partition name> <flags/type> <size> <data filename>
partition name - up to 15 chars, shown in MTD later
size - can be related to filesize: "filesize", "filesize+10M", "filesize+10b",
or have fixed size: "10M", "100b"
[M - means Megabytes, b - menas blocks (each NAND block is 128kbytes)]
can be "allsize" for auto size partition.
flags/type - can be different values:
types:
"ya" - YAFFS2 partition. MAGLDR can show root directory context or read kernel/initrd from it
"raw" - RAW data.
flags:
"ro" - disable add extra 5% to partition size and count bad blocks into size
"boot" - this partition contains zImage and initrd.gz for NAND boot (it must have YAFFS2 type)
"asize" - auto size. this partition will use all available space after other partitions. only one partition can have this type.
"nospr" - binary data have not spare data. (2048+0 format), otherwise 2048+64 format used.
"nors" - use exactly specified size for partition. no resize is done.
"hr" - this partition must be erased if user select "AD HardReset" in MAGLDR menu.
different flags and types separated via "|" symbol, like "boot|ya|ro"
bamit99 said:
Just adding this information if someone stumbles onto this article again :
Description of flash.cfg format
===============================
1. each line define one partition
2. maximum number of partitions is 16
3. order of partitions are same like lines in the file
4. line format: <partition name> <flags/type> <size> <data filename>
partition name - up to 15 chars, shown in MTD later
size - can be related to filesize: "filesize", "filesize+10M", "filesize+10b",
or have fixed size: "10M", "100b"
[M - means Megabytes, b - menas blocks (each NAND block is 128kbytes)]
can be "allsize" for auto size partition.
flags/type - can be different values:
types:
"ya" - YAFFS2 partition. MAGLDR can show root directory context or read kernel/initrd from it
"raw" - RAW data.
flags:
"ro" - disable add extra 5% to partition size and count bad blocks into size
"boot" - this partition contains zImage and initrd.gz for NAND boot (it must have YAFFS2 type)
"asize" - auto size. this partition will use all available space after other partitions. only one partition can have this type.
"nospr" - binary data have not spare data. (2048+0 format), otherwise 2048+64 format used.
"nors" - use exactly specified size for partition. no resize is done.
"hr" - this partition must be erased if user select "AD HardReset" in MAGLDR menu.
different flags and types separated via "|" symbol, like "boot|ya|ro"
Click to expand...
Click to collapse
This is what i get when I open flash.cfg. Where do I insert the values!
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
What exactly lies in the mmcblk0p7 partition?
MOVZX said:
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
Click to expand...
Click to collapse
PER - Per device provisioned data or per device calibration.
A cursory scout around XDA suggests this contains sensor calibration and such like.
http://forum.xda-developers.com/showthread.php?t=1739119
(edit: checkout the last posts by osm0sis - this guy knows his stuff when it comes to partitions).
I'm pretty sure it isn't the BOOTLOADER partition...
I would tentatively suggest you're OK for a reboot. I can't think of what else you can do, to be honest.
-----------
If you must flash a recovery using the dd command use the by-name syntax...
su
dd if=/sdcard/recovery.img of=/dev/block/platform/sdhci-tegra.3/by-name/SOS
Rgrds,
Ged.
@GedBlake
Thanks for the info. I was asking, because if it didn't vary from device to device I could probably dd up a backup of the partition and upload it here for the user to dd into his partition in his tablet.
That being said, I'll keep an eye on this thread for further consequences or the like.
@MOVZX
Please state whether you have a Grouper or Tilapia device, and the approximate manufacturing date, if known.
The PER partition is formatted as a FAT filesystem**. It seems to contain measurement data created during factory testing procedures. See here.
Note that there seem to be differences from device to device (compare the two posts in the above link). Here are the two critical questions:
1) What is the exact FAT format? (There are a couple of different FAT variants)
2) Does the bootloader read this partition during hardware initialization?
I seem to remember a thread here in the Nexus 7 forums where someone was claiming to adjust the ambient light sensor by altering a file in the PER partition. If that is correct, then indeed this partition *could* be critical to correct operation of the device.
I think you are being prudent about not rebooting. I also think that you should find someone to volunteer to give you a raw image dump (dd) from a device that is as close to yours as possible. Note that like many other devices, the N7 has hardware variants, and the PER partition seems to reflect that.
The calibration data for your device is now permanently lost, and you are the unfortunate experimenter who will find out the consequences of that.
**If you can not get someone to help you, the issue of the filesystem formatting can be solved by one of us by:
- raw dumping our PER partition, loopback mounting it, removing all files, unmounting it, and then giving that to you.
At least you would then have the correct filesystem formatting, but empty.
Also, please do a
dd bs=1024 of=/dev/null if=/dev/block/platform/sdhci-tegra.3/by-name/PER
to let us know what size your partition is.
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
bftb0 said:
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
Click to expand...
Click to collapse
Interesting stuff, bftb0, as always...
So what, in your opinion, is the worst case scenario?
If the bootloader is still accessible, couldn't the OP just fastboot flash back to stock?
(Assuming a simple reboot doesn't fix it).
Or does this not touch the PER partition? I would have thought that running the flash-all.* script would reset all partitions back to their default values.
I'm probably missing something here, so apologies - just a suggestion.
Rgrds,
Ged.
@GedBlake
The factory install procedure doesn't touch anything but the "usual suspects".
We sort of already know what the worst case is. As to whether to bootloader "needs" the PER partition or not, I don't really know. At this point my bet is that it does not, but that is purely an educated guess.
@MOVZX
I am attaching a "PER-empty.zip" file to this post. It is tiny because it is an almost empty FAT32 filesystem image (PER.img), so it compressed by nearly 100%. (When you unzip it, the "PER.img" image file should be 5,242,880 bytes, or 5120 kB) If you want to, feel free to un-zip it, and then flash the extracted "PER.img" file to the PER partition on your device.
Assuming you are using adb from your PC with the custom recovery still running:
Unzip PER-empty.zip, then
Code:
adb push PER.img /sdcard/PER.img
adb shell dd if=/sdcard/PER.img bs=1024 of=/dev/block/platform/sdhci-tegra.3/by-name/PER
What this will do is install an almost empty FAT32 filesystem which was created with the exact parameters used on my device. (I assume that your device also has a 5120 kB PER partition, but you have not replied.) The almost part is that I truncated every file in my image to zero length.
That's not much, but at least you will have a valid filesystem and most files of the correct name, even if they are zero length.
Note that once you have a filesystem in the PER partition, you are free to mount it using the custom recovery, and do whatever you please, e.g.:
Code:
adb shell mkdir /data/local/tmp/permount
adb shell mount -t vfat /dev/block/mmcblk0p7 /data/local/tmp/permount
adb shell
$ cd /data/local/tmp/permount
... do whatever you want in here...
$ sync
$ exit
adb shell umount /data/local/tmp/permount
adb shell rmdir /data/local/tmp/permount
good luck with your tablet - let us know how everything turns out.
.
I'm using Nexus 7 WiFi 16GB.
I almost have all the required files. The sensors and lightsensor directories were found mounted at /data/sensors and /data/lightsensor, so I copied it.
Here is the content of my sensors & lightsensore files:
lightsensor/AL3010_Config.ini
1476
Click to expand...
Click to collapse
sensors/AMI304_Config.ini
921368
2048 2048 2048
0 0 0
600 600 600
210 42 -256
0 0 0
0 0 0
103 100 101
0
Click to expand...
Click to collapse
sensors/KXTF9_Calibration.ini
1071 -1035 1034 -1030 -1097 1213
Click to expand...
Click to collapse
The FAT partitions is now Ok.
Now, I'm missing these files:
adc-rawdata.csv
ISN
KXTF9_Calibration.ini
prom-filter-rawdata.txt
rawdata.csv
rek-prom-rawdata.txt
SSN
Click to expand...
Click to collapse
I'm having no confidence to reboot this device yet
This thread is part of customizing the Windows Phone OS or ROM, which includes altering of the target files and no nothing else. Do not go sideways on this tutorial as you might brick your phone. PLEASE TAKE RESPONSIBILITY. I am not responsible to any damage caused by this tutorial. Also, do this if you want to personalize your device.
CUSTOMIZING THE OEM BOOT SPLASH IMAGE WITH SOMETHING HILARIOUS OR EPIC
What you need:
- Windows Phone Internals (for booting Windows Phone into Mass Storage Mode)
- Photo Editor <optional> (for editing the oem boot splash image. If you made one with as large as your phone's screen resolution, please disregard this)
- Administration Account (for DISKPART)
- CAUTIOUS MIND (of course)
- and a Windows Phone (obviously)
Procedure:
Getting Ready
1. Boot your Windows Phone into Mass Storage Mode. To do this, either shut down first your phone then boot it up whilst holding down the camera button (if any), or use Windows Phone Internals (https://wpinternals.org/) to boot into MSM manually. If you haven't unlocked the bootloader and enable root access yet, please do.
2. Using DISKPART, select the appropriate disk number from the list of disks (list disk) and do select partition 20 to select the target partition.
3. Then type in this command:
Code:
detail partition
This will show the default Partition Type ID. Save this GUID for a later step.
4. After saving to notepad or a sticky note, do:
Code:
set id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 (to make it read-and-write-able)
5. To assign the drive with a letter:
Code:
assign
Now your done with PART 1! Proceed for more.
The Main Thing
1. On the file explorer, go to PLAT Drive. Then edit the two files, namely: boot1.bmp, boot2.bmp. Make sure the photo is as big as the default screen resolution of your device. (e.g. Nokia Lumia 520 = Screen Resolution: 480x800) If you made custom ones already, replace them with no problems.
P.S.: Mostly recommended: 32-bit bmp image export setting (on Photoshop).
2. Once done, proceed to the next stage. Make sure no other files is altered. If the image format is different, a System File Integrity error may occur when you boot up the device after this procedure, causing it to display a black screen without letting you to boot it normally.
File Info:
Code:
******[BOOT1.BMP]******
This is displayed or splashed when the device is booted up from powered off state.
******[BOOT2.BMP]******
This is displayed right after the first one in 0.1 second delay. It is also shown after the "Charging on Low Battery" screen when it has enough minimal power to boot up normally.
Packing Things Up
1. Go back to Command Prompt. Set the Partition Type ID back to default by pasting in back the GUID code you copied in Stage 1 step 3.
2. After these steps, finally reboot your device to exit Mass Storage Mode.
3. You will eventually see the result when it boots up. Voila!
General Questions:
My device boots into black screen. What to do?
A: Make sure the Partition has these information:
Code:
File System: FAT12
Partition Type ID: <the default GUID, not the GUID given here>
Partition Size: 8 MB
If not, please fix those problems yourself.
Can I use an animated GIF instead?
A: Impossible. It only accepts bitmap-still images, not animated ones. This is because it is on a BIOS environment (maybe?).
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.