Where is the encyrption key?
I have a mobile phone image, it is physical forensics image.
User data partition is encryted but UFED PA is able to decrypt and decode as ExtX as this partition. I wonder where UFED PA gets the encyrption key from the image. I am asking because of my curiosity.
of note in the above link:
You can find the default password defined in the Android Open Source Project cryptfs.cpp file.
(Hint: look at line 276.)
Starting an encrypted device with default encryption
This is what happens when you boot up an encrypted device with no password. Because Android 5.0 devices are encrypted on first boot, there should be no set password and therefore this is the default encryption state.
Detect encrypted /data with no password
Detect that the Android device is encrypted because /data cannot be mounted and one of the flags encryptable or forceencrypt is set.
vold sets vold.decrypt to trigger_default_encryption, which starts the defaultcrypto service. trigger_default_encryption checks the encryption type to see if /data is encrypted with or without a password.
Creates the dm-crypt device over the block device so the device is ready for use.
vold then mounts the decrypted real /data partition and then prepares the new partition. It sets the property vold.post_fs_data_done to 0 and then sets vold.decrypt to trigger_post_fs_data. This causes init.rc to run its post-fs-data commands. They will create any necessary directories or links and then set vold.post_fs_data_done to 1.
Once vold sees the 1 in that property, it sets the property vold.decrypt to: trigger_restart_framework. This causes init.rc to start services in class main again and also start services in class late_start for the first time since boot.
Now the framework boots all its services using the decrypted /data, and the system is ready for use.
@diskveri you can't. Since this is device with FDE, unless secure startup is enabled it decrypts itself during bootup. The way it works in UFED and others, is that they use some exploits that allow them get unrestricted (let's say root) access ignoring FRP/OEM Lock, and use this "flaw" (or feature) of FDE to create decrypted image. It's important that the phone is working and able to fully boot into Android. Otherwise, this method won't work.