[General Questions and Answers] Lanchon:
wrong. adb pull /dev/block/[...] will pull **the block device**, bit per bit, including free space, as an image, and u'd need to mount that to get to the files. unfortunately if the partition is mounted at the time of the pull, the image will be corrupt. you can only do this from recovery, and only after making sure /data is unmounted.

but adb pull is quite inefficient for this, as it doesn't compress the data, especially if not using usb3 5Gbps superspeed and stuck with 480Mbps. better to pipe the data thru some fast compress/decompress step. lzo is available in most recoveries and is quite good at this, but yes there are better algos.

adb pull of the mounted partition at the partition mountpoiunt will pull most files but lots of metadata and special files will be lost. to backup a linux partition at the file level you should use the tried and true backup methods such as tar with the proper options to preserve all things needed. search online or look at TWRP's source code. you can pipe tar thru compression to a local file, then pull the file, or pipe it thru adb directly to your host, which requires a bit more inventive but is easily done if needed (no space).

but...

pulling the disk image is typically useless because it is typically encrypted. the key used to be stored (encrypted) at a partition footer, but now is stored (encrypted) in a separate partition. backing up this key is typically useless as it is encrypted. the key to the key is stored in the trusted system outside of linux's control, and you are not supposed to be able to get to its storage under any method, unless you break ARM silicon, ARM's Trustzone, or google's implementation of the android trusted OS. with the help of TZ, and providing it with secrets such as the unlock pattern, you can decrypt the key and access the partition (or back it up), but for whatever reason TWRP is having trouble doing this.

i'm out of touch, dont care really, but it could be that TZ now requires some attestation of the OS running in addition to secrets to release the key, which TWRP will never be able to spoof (unless the firmware is broken). or it could simply be that TWRP needs be updated to provide secrets to TZ in an android 13-compatible way. and btw, it's the first time i read that TWRP is unable to mount; i'm out of touch.

> It should be obvious that a 1:1 copy ( bitwise )

this seems to imply that bit copying the entirety of the flash will revert state to current state. this is not in general true. for this to be true, flash should be the only stateful component in the phone and it's definitely not. for one, the SoC has efuses to prevent rollbacks of bootloaders and such. but a capable trusted system should have some sort of anti-rollback, or else it'd be vulnerable to rollback. say you have a system that lets you try 10 patterns and then wipes the key forever. you backup, try 9, restore, try 9, restore, try 9... until you brute force the pattern. this is not much better than having no trusted system at all. apple has the secure enclave processor for this. good android phones say "key storage: hardware backed", and i take this to mean anti-rollback protection is implemented or else it'd be a sham. i think google takes security seriously enough to have this done right, but i've no hard data.

rollback protection requires some sort of storage outside of unrestricted access (such as JTAG or bus driving) and is typically implemented physically withing a security processor, and with silicon anti-tamper methods. examples of this are all tiny chips in smart cards and credit cards. they cost cents, and i see no reason not to include them in phones.