Android versions of TestDisk & Photorec or finding a way to use them on a partition dump that uses file based encryption

[refreezePlacard]

Years ago, there was an Android version, is it published somewhere?

viewtopic.php?p=6007&sid=ce00b41e30467e ... c79f#p6007
> I have a command-line (No GUI and no text interface!) version that you can use on a rooted android.

--------------------


Back to the beginning in case it's the wrong approach.
On a phone with Android 13 that was installed from the same version. Like any not too old Android version, the install encrypts the partition with the File Based Encryption (FBE) method. Which for data recovery is not as nice as Full Disk Encryption. Also the partition is ext4.

An app had video data saved in Android/data/the.app.package.name
When uninstalling the app to downgrade it because the latest version crashes, I got a bitter reminder that Android/data/the.app.package.name is wiped on uninstall.
So concretely, I got many 2MB video files grouped in directories that got rm-ed.

IIUC without going to a data recovery company, among all the known publicly available tools, my best bet would be TestDisk's undelete feature that might be able to restore the directory structure. And PhotoRec if that fails.
So hence trying to find an Android build.

Another approach is to do that from a PC with a partition dump. Since the phone if rooted, I got a dump of the data partition (from /dev/block/mmcblk0pblablabla)
But there is still FBE in the way.
Does anyone know if there still any way to exploit such a partition dump with TestDisk or PhotoRec? Since if have the unlock code, there must be a way to get the key.
Hmm, even when installing TestDisk on the phone, it would still face the issue of FDE because IIUC, TestDisk/PhotoRec can only work on a raw partition or drive, so /dev/block/mmcblk0pblablabla. It would need specific code to handle the case of Android's FBE.

Or is there any other way with any tool to have some hope?

[recuperation]

Years ago, there was an Android version, is it published somewhere?

viewtopic.php?p=6007&sid=ce00b41e30467e ... c79f#p6007
> I have a command-line (No GUI and no text interface!) version that you can use on a rooted android.

--------------------


Back to the beginning in case it's the wrong approach.
On a phone with Android 13 that was installed from the same version. Like any not too old Android version, the install encrypts the partition with the File Based Encryption (FBE) method. Which for data recovery is not as nice as Full Disk Encryption. Also the partition is ext4.

An app had video data saved in Android/data/the.app.package.name
When uninstalling the app to downgrade it because the latest version crashes, I got a bitter reminder that Android/data/the.app.package.name is wiped on uninstall.
So concretely, I got many 2MB video files grouped in directories that got rm-ed.

IIUC

Please use full words instead of gamer type abbreviations that I refuse to look up somewhere. Thank you! The FBE term above was used correctly as it was explained.

without going to a data recovery company, among all the known publicly available tools, my best bet would be TestDisk's undelete feature that might be able to restore the directory structure. And PhotoRec if that fails.

File-based encryption will make file signatures disappear that PhotoRec relies upon. Therefore PhotoRec is unusable in your case.

So hence trying to find an Android build.

Another approach is to do that from a PC with a partition dump. Since the phone if rooted, I got a dump of the data partition (from /dev/block/mmcblk0pblablabla)
But there is still FBE in the way.
Does anyone know if there still any way to exploit such a partition dump with TestDisk or PhotoRec? Since if have the unlock code, there must be a way to get the key.

Photorec will fail (see reason above). TestDisk does not modify a possible encrypted file content - it works as designed.

Hmm, even when installing TestDisk

TestDisk does not need an installation. If so you might overwrite the content of deleted files when "installing" TestDisk. You should only run the TestDisk executable from a partition that does not contain the files you would like restore.

on the phone, it would still face the issue of FDE because IIUC, TestDisk/PhotoRec can only work on a raw partition or drive, so /dev/block/mmcblk0pblablabla. It would need specific code to handle the case of Android's FBE.

Or is there any other way with any tool to have some hope?

I am not familiar with Android, the details of Android-type file-based encryption and rarely use a smart phone. Maybe installing the Android operating system on a desktop PC would allow you to decrypt the formerly recovered files.

[refreezePlacard]

Hello thanks for your time for the various clarification you made,

[...]
So concretely, I got many 2MB video files grouped in directories that got rm-ed.

IIUC

Please use full words instead of gamer type abbreviations that I refuse to look up somewhere. Thank you! The FBE term above was used correctly as it was explained.

Just to be sure, it's only about IIUC or also rm-ed? Because rm-ed is the word that I had to improvise to mean "being subjected to the rm command" and I wasn't sure it was clear enough.
Sorry for using IIUC to mean If I understand Correctly which seemed to be very common in semi formal online discussions. So now I'll know it's not widely usable as I though, noted.
And it's not at all a "gamer type abbreviation" I don't think I've seen it in that context because IIUC/"If I understand Correctly" is semi formal.

without going to a data recovery company, among all the known publicly available tools, my best bet would be TestDisk's undelete feature that might be able to restore the directory structure. And PhotoRec if that fails.

File-based encryption will make file signatures disappear that PhotoRec relies upon. Therefore PhotoRec is unusable in your case.

Indeed that's the base issue. It was in case somebody heard of a tool that would be fed the encryption keys and that would map the encrypted partition to a decrypted abstraction.
Like how we unlock LUKS(Linux Unified Key Setup) partitions and have them appear in /dev/mapper and we can use TestDisk&PhotoRec there transparently.
But that Android encryption setup seems way more complex

So hence trying to find an Android build.

Another approach is to do that from a PC with a partition dump. Since the phone if rooted, I got a dump of the data partition (from /dev/block/mmcblk0pblablabla)
But there is still FBE in the way.
Does anyone know if there still any way to exploit such a partition dump with TestDisk or PhotoRec? Since if have the unlock code, there must be a way to get the key.

Photorec will fail (see reason above). TestDisk does not modify a possible encrypted file content - it works as designed.

Ah, indeed, TestDisk doesn't care about file based encryption and can do it's job.
Unfortunately as I've read since (and tried) it can't on ext4 (even when forcing to read the partition as ext2 as desperate attempt)
It sees the delete directory but can't do anything from it. (with even the right timestamp of the deletion date )

In case someone wonders how to navigate the directories with all the names encrypted:
- mount (read only) the partition image on the PC:

Code: Select all

sudo mount -o ro ./data.img /mnt

- via directory size and file count it's possible to find the target directory (here Android/media), compare with the size and item count on the phone, assuming it didn't change much on the phone since the dump
- then on the mounted image on the PC you can see the last modified dates that can be used in the TestDisk partition browser. You can't directly use the name of the directory that you found on the mounted partition because the encoding isn't the same so the names don't match (there is likely a way around this)
- then tediously you should end up finding the parent of the deleted directory/file
- (would be happy to hear if you managed to go further or if your case was different and allowed you get a sucess)

Hmm, even when installing TestDisk

TestDisk does not need an installation. If so you might overwrite the content of deleted files when "installing" TestDisk. You should only run the TestDisk executable from a partition that does not contain the files you would like restore.

Correct, it's more about dropping the binaries somewhere than a proper install. And good to insist on doing that on another partition, I should have detailed that to avoid raising the alarms on that important data recovery rule.

on the phone, it would still face the issue of FDE because IIUC, TestDisk/PhotoRec can only work on a raw partition or drive, so /dev/block/mmcblk0pblablabla. It would need specific code to handle the case of Android's FBE.

Or is there any other way with any tool to have some hope?

I am not familiar with Android, the details of Android-type file-based encryption and rarely use a smart phone. Maybe installing the Android operating system on a desktop PC would allow you to decrypt the formerly recovered files.

If I understand correctly, it uses fscrypt (from the linux kernel to be used on top of ext4 and f2fs) and there is something about the actual keys being decrypted by the chip when being fed the lock screen code.
https://source.android.com/docs/securit ... on-details
That's quite the setup to be able to have various level of security and multiple users sharing the same data partition.
I'll keep reading to find out if there is a per file key or if there is a common key for /data/media/0/Android Then, theoretically, it could be possible to make a layer that decrypts the raw data and make it exploitable by PhotoRec.
But without having the file metadata to know where a file starts and ends it might be doomed due to not being possible to correctly align the data before decrypting it.
Much of that is new to me so I'm really not sure.