@alecxs I have TWRP installed and can decrypt the partition there, but how do I go from there if I want to restore a deleted file?

@alecxs Also I can't find any binary of extundelete for ARM to be run on my device

Does this answer your question? How to recover a deleted file from /data partition?

@IrfanLatif I am basically doing the same steps as described there. Although there it says that for encrypted devices the recovery creates an unencrypted block device at /dev/block/dm-0 which is not the case for my device/recovery (TWRP)

@alecxs for what? extundelete?

@bit151 from the contents of /data/media it looks it's FBE, not FDE (so no dm-0).

@IrfanLatif So FBE and the lack of dm-0 means there is no easy way to get to the unencrypted block data?

@alecxs Thanks for the reply, TWRP does state that the decryption was successful and I can browse the files normally using the builtin Explorer. What I observed is that the output of "ls /dev/block" doesn't change after the decryption by TWRP, so maybe the decryption is done somehow else?

@alecxs running extundelete on device is never necessarily required. Due to small processing power it would take long. Also running directly on flash storage would eat precious E/P cycles. Running on partition dump on PC is always advisable and more feasible. IIRC I tried once to build static binary and it failed for some reason. I'll check though. // Dumping sda13 (block device) using dd or adb pull would always dump encrypted filesystem contents (whether FDE or FBE). In order to dump decrypted contents after successful FBE decryption, dump contents of /data/ e.g. by tarring.

Since files are deleted with encrypted (i.e. unrecognizable) metadata, I don't think they'd be recoverable in any way. Neither the journal includes any information about the original decrypted file, nor the raw partition can be carved through to recognize a known file header/footer. With FDE however, both techniques may work if the decrypted block device is available (i.e. dm-0).

@IrfanLatif if there is no way to get a decrypted dump for FBE and extundelete is not purposeful, maybe testdisk can restore encrypted files and TWRP can decrypt afterwards?

@alecxs when file is encrypted in FBE, it's header and footer is not in a valid recognizable form. So any carving method (including testdisk) won't be able to figure out where the file starts and ends. And even if recoverable, it won't be possible to decrypt individual files afterwards. So this approach is definitely a no no.

@IrfanLatif thx today another lesson learned. seems like FBE is good choice for security - just deleting files is sufficient. then we don't need extundelete binary :)

@alecxs yes. I included that point here: How to make a complete factory reset, without anyone being able to retrieve my data?. Though not directly mentioning FBE, but generally any form of file level encryption.

Thanks @IrfanLatif for the detailed explanation. I wasn't aware that deleted files are identified using header analysis or the journal. But why doesn't the journal include any information about the original file in this case (you mention in your other post that ext4 is journaling) ? Wouldn't it at least contain information about the encrypted file?

@bit151 if journaling is enabled, journal might contain information about the inode of deleted encrypted file. However the way files and their names are encrypted in FBE, I don't think it'd be possible to decrypt those individual files.

But personally I don't have experimented much with FBE, neither I'm an expert in data recovery and all that. You can try running extundelete, debugfs and similar tools to recover some data if it works. And if you get some useful information, do share your experience and findings with us.