[General Questions and Answers] xXx yYy:
My last 2 cents here:

When a file is deleted/wiped on Android, the file system typically marks the storage space occupied by that file as "free" but doesn't necessarily erase the data itself immediately. New data can overwrite the deleted/wiped file, making it unrecoverable. The success of data recovery depends on how much of the deleted/wiped file has been overwritten.

Creating a dump

A: Using ADB Pull Method not Possible

ADB pull command typically doesn't work on deleted/wiped files because those files are no longer recognized by the system and wouldn't be accessible through ADB pull. Resume: ADB pull works by copying files from a specific source path on the device to a destination path on your computer. It doesn't have the capability to access and copy raw data from entire partitions as the Android shell dd command does.

B: Using Android Shell Command dd:

The Android shell dd command creates a raw ( means a bitwise 1:1 ) copy of the entire partition block by block. This includes deleted/wiped files that haven't been overwritten yet. This method requires root access!

A dd image created from a partition will contain a raw copy of all the data on that partition, including the encrypted files themselves. However, the individual files within the image won't be decrypted. To access the actual data within the files, you would need the decryption key (read: CE key) used for FBE. This key is typically stored securely on the device itself and not accessible without further methods. Take note that when FBE encrypts a file, its header is rewritten to indicate the encryption and contain additional information for decryption.

Some 3rd-party data recovery tools might be able to analyze the raw data in a dd image and potentially extract fragments of information even from encrypted files. However, this is a complex process with a low success rate and typically beyond the scope of basic data recovery.

Decrypting a dump

AFAIK the exact composition of the FBE's CE key on Android is not publicly available.

Here's what is known about the CE key:

It's generated during device setup.

It resides within a trusted execution environment (TEE) on the device for enhanced security.

It's derived from the user's chosen credentials (password or PIN) along with device-specific hardware identifier and random data.

While the specific details of the key derivation function are not revealed, it's likely a strong cryptographic function designed to resist brute-force attacks. This ensures that even if someone obtains the encrypted password, it would be computationally infeasible to crack it without the original user credentials.

Knowing the password or PIN doesn't help at all!

Adding Temporary Root

As already mentioned you have to search the Internet for a device's CPU-architecture ( ARM32, ARM64 ) matching SU binary, download / copy it to a location on phone that's writeable and whose content is persistent, make the binary executable, and set its Sticky-bit

Windows 11 batch example using ADB

bitsadmin /transfer <URL-OF-SU-Binary> %TEMP%\su >nul
if exist "%TEMP%\su" (
adb devices
adb push %TEMP%\su <LOCATION_ON_ANDROID_DEVICE> >nul
adb shell "chmod +x <LOCATION_ON_ANDROID_DEVICE>/su"
adb shell "chmod +s <LOCATION_ON_ANDROID_DEVICE>/su"
)