Backing up bricked phone...

[Joey 1]

I attempted to root my phone using these instructions...

https://community.fxtec.com/topic/2537-magisk-install-step-by-step-root/

This results in the phone asking for a password to unlock.

When I put in the password it says it's correct but the data is corrupt and the decryption was unsuccessful.

I put trwp on there and it can't see the normal mounts for internal storage so I can't even back it up.

From what I can gather there's probably some issue with the kernel version or something like that either not able to recognise all of internal storage due to drivers or using specific encryption settings.

My phone is a version that came with the unlocked bootloader. Where can I find the correct original boot.img to try to access internal storage?

[Joey 1]

I'm at least able to dd sd* into /external_storage/.

Why does the phone even ship with this self destruct option? I think when it fails to decrypt it gets stuck on that no matter what even if you change the boot image. It won't retry.

I believe this is because it must put a file somewhere. It's saving the number of password attempts *somewhere* so where?

It's also possible that twrp 3.4 maybe able to mount the directories as it appears to have additional support for encryption but no one seems to have made that version for this phone.

[Joey 1]

I don't know why it's so hard to find uptodate maintained instructions for rooting the phone or changing firmware. There really needs to be more support here. There should be a download section with usb drivers, stock firmware, etc. Then a wiki. I'm sure someone will help with SEO as well. There are so many scam sites in search result it's unbelievable let alone just out-of-date or plain wrong information. No one seems to know how to give simple instructions and explanations either.

[_DW_ 628]

There is possibly something newer but thats the original reset instructions from FXTec

[Joey 1]

I managed to get lineage OS on it and to root it. Restoring many different stock boot images didn't work. Now I just have a backup of the internal memory on an SD card. I have no idea how to recover that at this point. One option will be to mount it as a disk image in Virtual Box or mess around with the Android emulator. I could always put it back into the phone but need a bigger SD card to store it uncompressed so to mount, etc.

What I don't understand is why android loses all the data just flashing the boot partition. I've worked with Linux including building my own minimal distributions. I've also worked in security and the rule for encryption is often a big no. It's so easy for it to go wrong and to lose all of your data. If you do it then you do so very carefully and you inform the user.

I'm fairly certain Android is doing some idiotic things here in the name of security. To save me going down the rabbit hole, including downloading the Android source and searching for "Decrpytion unsuccessful" which I suspect is a lying message and that Android actually does cat /dev/urandom > /dev/block/datapartition if you enter the password wrong. I could be wrong but the way it behaves is as if it did that. I didn't ask for 007 Mosad/CIA/MI5 self destructing software.

Also when I backed up the drive then his reset it just went into a loop of saying that over and over. I might be being just suspicious on this point. Either way absolutely nothing I have done should have reasonably touched the data partition nor impacted it. Something isn't right here.

Is it possible someone has some something really stupid and enormously idiotic like put encryption keys in the boot partition? Is the encryption OEM locked such as based on the boot image which is a massive mistake as well? Both Android and TRWP lost the ability to see the partition, just showed as 0MB in Trwp. It also seems like some missing drivers or boot options or something gone wrong.

Edited July 15, 2022 by Joey

[brunoais 334]

On 7/15/2022 at 8:05 AM, Joey said:

What I don't understand is why android loses all the data just flashing the boot partition. I've worked with Linux including building my own minimal distributions. I've also worked in security and the rule for encryption is often a big no. It's so easy for it to go wrong and to lose all of your data. If you do it then you do so very carefully and you inform the user

On Android. The "subkey" which allows gathering the decryption keys is stored in the boot menu. Supposedly to ensure if the bootloader is unlocked, it's impossible to reach the keys.

On 7/15/2022 at 8:05 AM, Joey said:

I'm fairly certain Android is doing some idiotic things here in the name of security.

I'll help you with that. The answer is: Yes.

This is knowledge of Android 7 (AOSP), btw. But given how lazy they are. It might very well still be relevant:
Android stores keys to reach enough for booting in the bootloader. Usually just enough to reach the lock screen. However, if you have fingerprint unlock or face unlock (whatever those techs are called), there's no effective additional decryption step (the key is reused). However, if there's a code or pattern, that one plus the "bootloading key" (with some merging math) is the key to decrypt the encryption key for the rest of the phone.

On 7/15/2022 at 8:05 AM, Joey said:

enormously idiotic like put encryption keys in the boot partition

Yes. But should only be the keys to reach the booting to the OS enough to ask for authentication.

 

I've done a complete encryption setup for my linux system. Except, I have the "semi-automated" (TPM-stored keys) into lock screen and then automated to decrypt the rest of the PC using the password entered as an "entry point key". But I also have backup passwords which are asked if the TPM fails or whatnot. I've already launched my whole OS from a VM in a live environment to test and to prove the point, so I know it works.

Android doesn't have those backup ways of getting in, which is a very annoying predicament. If it's encrypted and the boot corrupts, the whole data is pretty much unrecoverable. This is as of Android... 9 was it? Encryption must be turned on by default (Oh... And once turned on, it can't be turned off without a full clean install).

Google, instead of fixing, tells users to use google drive to backup their data... Control, as expected...

[claude0001 1,321]

On 7/11/2022 at 4:31 AM, Joey said:

I put trwp on there and it can't see the normal mounts for internal storage so I can't even back it up.

As far as I know, the version of TWRP available for the Pro1 does not support decryption of data partitions and hence cannot be used for backups. In fact, the only purpose of that build of TWRP was to enable a clean install of SailfishOS. It is also known to mess up the existing data partition upon boot: https://forum.xda-developers.com/t/twrp.3976369/ , https://community.fxtec.com/topic/2479-team-win-recovery-project-twrp/

Edited July 20, 2022 by claude0001