Phone to phone flash copy -> hard brick. What went wrong?

Search This thread

ascendant512

Member
Aug 22, 2013
12
1
Sony Xperia Z3 Compact
Hi all,
It looks like questions about bricking tend not to get replies...
... but hey, it's just a post.

I copied the internal memory contents from one of my Z3Cs to another one and now the one that was overwritten does seems bricked.
The copy was done with basically:
Code:
new # dd if=/dev/block/mmcblk0 of=/external_sd/mmcblk0_new.dd
# backup
old # dd if=/dev/block/mmcblk0 of=/external_sd/mmcblk0_old.dd
# copy new:/external_sd/mmcblk0_new.dd to old:/external_sd/mmcblk0_new.dd
# overwrite
old # dd if=/external_sd/mmcblk0_new.dd of=/dev/block/mmcblk0
Power, Power + volume up or down, and camera buttons do nothing. If the phone is plugged in to charge off USB, the notification light slowly blinks red (it is in a pre-boot loop). If I hold the power button while it's plugged in, the notification light is solid red. Holding down other buttons doesn't change the behavior. I tried unplugging the battery and plugging it back in, but it made no difference. Plugging the phone into a PC doesn't show a USB device.

Why didn't it work? And, I guess, is it totally unrecoverable?
 

Kenora_I

Senior Member
Jun 12, 2021
1,352
3
333
Ireland
Redmi 7A
Samsung Galaxy A21s
Download an older version of flashtool (0.9.18.6) because I couldn't get the newer versions to work and I flashed a stock kitkat rom: http://xdaforums.com/z3-compact/general/list-stock-firmwares-d5803-d5833-t2906706 (Specifically the "23.0.A.2.93 - Unbranded - USA (1289-7524)" version - make sure you get the right version for your model). With this process, you don't need to turn your phone on. Just make sure you know how to use flashtool correctly.
 

ascendant512

Member
Aug 22, 2013
12
1
Sony Xperia Z3 Compact
Download an older version of flashtool (0.9.18.6) because I couldn't get the newer versions to work and I flashed a stock kitkat rom: http://xdaforums.com/z3-compact/general/list-stock-firmwares-d5803-d5833-t2906706 (Specifically the "23.0.A.2.93 - Unbranded - USA (1289-7524)" version - make sure you get the right version for your model). With this process, you don't need to turn your phone on. Just make sure you know how to use flashtool correctly.
Thanks, but flashtool requires a functioning USB interface on the phone, right?
Is there maybe some trick I haven't tried yet with the buttons that would make the phone present a USB interface to the host PC?
I'm on Linux using dmesg --follow so I'm certain that the host is not seeing a USB device appear. Nothing happens even if I hold the power button to get the solid red light behavior, but maybe I'm doing something out of order.
 

nlra

Senior Member
Sep 5, 2012
160
85
@ascendant512 Yes, what you did was foolish, and is totally unrecoverable (at least as far as anyone outside of Sony knows). The main flash chip itself that you entirely cloned bit-for-bit from one phone to another contains a bunch of data on it that is specific to that particular phone itself (not specific to just that model of phone, but specific to that unique, individual unit).

We don't 100% know exactly how it works, but that data is ciphered and is somehow tied to a serial# or IMEI# or something else that exists outside of the contents of main flash (probably somehow being used as the encryption key, or at least part of the key). If the two don't match up (the ciphered data stored on main flash and whatever it is being checked against outside of main flash), that data is indecipherable, the phone will not boot, and you are left with a brick. (The bootloader chain-of-trust is broken and it won't even kick over to a recovery mode.)

If you had instead cloned individual partitions (e.g., boot/kernel, system, userdata, etc.) rather than the entire flash chip, this could have been avoided. The specific partition that you cloned which ended up killing your target phone was the 'TA' partition. This is the one that has all of the critical, phone-specific data in it. If you overwrite/scramble/trash the contents of that partition (which would include taking a copy of TA from one phone and writing that copy to another phone of the same model), your phone is done for. We lack the knowledge or tools to re-generate the contents of that partition, and even if we didn't, you would likely need to de-solder the flash chip from the mainboard to write the corrected TA partition contents back to it.
 

ascendant512

Member
Aug 22, 2013
12
1
Sony Xperia Z3 Compact
@nira
I don't think it was that foolish since Google suggested that it does work for many Android phones, but thanks for the info about TA. It's much more helpful and informative than responding to "no dmesg" with "USB drivers"
I was trying to do this because the GPS doesn't work on one of the phones. I tried to clean the contacts of the antennae, but it made no difference, only ever picks up 0-3 satellites. Looks like I'm stuck buying a third Z3C to have working GPS.
 

nlra

Senior Member
Sep 5, 2012
160
85
I don't think it was that foolish since Google suggested that it does work for many Android phones, but thanks for the info about TA. It's much more helpful and informative than responding to "no dmesg" with "USB drivers"
I was trying to do this because the GPS doesn't work on one of the phones. I tried to clean the contacts of the antennae, but it made no difference, only ever picks up 0-3 satellites. Looks like I'm stuck buying a third Z3C to have working GPS.

TA is a Sony "innovation" that you won't really find on other Android handsets (at least by that particular name).

Given how diverse the Android manufacturing ecosystem is, it's very tricky to extrapolate to a bunch of models (or even vendors) what might be true for a few, and thus, I would by nature be very hesitant to ever do a full-clone of seemingly-identical devices until I had first read up on and understood all of the intricacies of the *specific* model I was working with, because you never know what is easily undo-able and what isn't.

If you compare partition tables between different models of handsets, about the only commonalities when it comes to Android fixed-storage partition structure is 'boot', 'system', 'cache', and '[user]data'. There are typically tons of other various vendor-specific partitions storing who-knows-what data often with who-knows-what filesystems that (as your unfortunate particular story bears out) can be vital to the operation of the device as a whole. (It does seem foolhardy to me that manufacturers would choose to store those bits on the same storage medium as the rest of the system and user data, rather than in a separate ROM chip, but this is aggravatingly common in the world of embedded systems, probably as a cost-cutting measure...)

I *am* sorry for your loss, though... :(
 
  • Love
Reactions: Kenora_I

ascendant512

Member
Aug 22, 2013
12
1
Sony Xperia Z3 Compact
So I've gone on adventure trying to prepare a new Z3C with working GPS and the adventure seems to have ended in failure.

I can describe some of the journey, and maybe there is advice on what bricked the phone or possibly a way to unbrick it as it is not in as poor condition as the previous one.

The phone arrived new in box with the Sony holographic stickers; I immediately followed the bootloader unlock procedure without any hiccups (to the best of my memory, it arrived with firmware 23.5.A.1.291).

The first failure was getting the phone to boot TWRP. For my previous z3c, this was the TWRP I used.
However, booting it with fastboot boot twrp-3.3.1-0.4-z3c.img
returns the error:
Code:
Booting                                            FAILED (remote: 'dtb not found')
    fastboot: error: Command failed

The device forums are sparse on this error, what it means, or how to fix it, but I'm used to TWRP being incredibly flaky. I did find that there is a combination of requirements from a kernel somewhere on the device which boots recovery requiring LZMA support, as it is the compression method for newer TWRPs.

The TWRP 3.2 from that post, as well as older TWRPs such as 3.1.1 were usable to boot, and led to the new phone's very brief peak operating state, in which I was able to flash and boot an old CarbonROM 5.1/Android 7 zip. However, TWRP 3.2 predates the phone's renaming from aries to z3c, and that version of TWRP would not flash the latest CarbonROM and Android 10.

From here, things only went downhill. Retrieving images from my Z3C which currently runs current CarbonROM, I overwrite the boot, FOTAKernel and userdata partitions from the old phone using a process like this:
Bash:
losetup --find --partscan --verbose backup.dd
dd if=/dev/loop0p14 of=backup_boot_14.dd
dd if=backup_boot_14.dd of=/dev/block/mmcblk0p14
Where backup.dd is a copy of mmcblk0 on the working phone and partition 14 is the one labeled "boot" in the GPT (16 is FOTAKernel and userdata is 25). The phone has never successfully booted into anything since, and these are some of the things I've tried to do to fix it:

Using Xperifirm 5.6.1 I downloaded firmware 3.5.A.1.291-R5D for US
Using flashtool 0.9.33.0 I assembled a ftf using the components "fotakernel.sin, kernel.sin and system.sin"
After flashing this group to the phone, it would boot loop the stock firmware (boot animation, freeze, reboot, do "optimizing apps", repeat). The stock firmware would also recognize my encrypted userdata and prompt to decrypt it until I used fastboot to clear the userdata partition.

That's the last time that flashtool worked, though. I later learned that there are preassembled ftfs that can be found, and got the one from this post:
Whenever flashing anything to anywhere using flashtool, it spits out these errors:
flashsystem.X10FlashException: ERR_SEVERITY="MINOR";ERR_CODE="0017";ERR_DYNAMIC="80080021";
I haven't found anything anywhere that explains what these mean, or how to solve them.

I've tried checking and unchecking the various boxes in flashtool's flash mode that cause it to skip steps in the flashing process like so:
  1. Flash the D5803_23.5.A.1.291_Customised_Nordic with default settings
  2. When the first step fails out, restart the flash process
  3. Uncheck the box for that step and let it start. It errors out on the next step
  4. Repeat until only system is left that failed.
However, this does not seem to have accomplished anything productive. I also tried
fastboot flash:raw boot backup_boot_14.dd
and
fastboot flash boot boot.img (from CarbonROM's zip)
As well as the above with recovery and FOTAKernel from various TWRPs.

The phone isn't hard bricked, it boots into fastboot mode with vol+ and flash recovery mode with vol-. fastboot boot twrp.img has a few different behaviors depending on the TWRP version:
Nailyk's twrp_z3c_2019-03-13 from https://www.reddit.com/r/LineageOS/comments/edwnzf will boot to a black screen. No adb available.
The previously successful TWRP 3.2.3-0 without LZMA compression from NeoArian boots to a SONY logo notably without the Xperia logo on the bottom.
Newer versions of TWRP (3.3+) or lineage-18.1-20210914-recovery-z3c continue to fail with the "dtb not found" error.

It seems almost certain that the path to a working phone will be through flashing it back to stock using flashtool, but I don't see a way to make flashtool work or what is causing the errors.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    I don't think it was that foolish since Google suggested that it does work for many Android phones, but thanks for the info about TA. It's much more helpful and informative than responding to "no dmesg" with "USB drivers"
    I was trying to do this because the GPS doesn't work on one of the phones. I tried to clean the contacts of the antennae, but it made no difference, only ever picks up 0-3 satellites. Looks like I'm stuck buying a third Z3C to have working GPS.

    TA is a Sony "innovation" that you won't really find on other Android handsets (at least by that particular name).

    Given how diverse the Android manufacturing ecosystem is, it's very tricky to extrapolate to a bunch of models (or even vendors) what might be true for a few, and thus, I would by nature be very hesitant to ever do a full-clone of seemingly-identical devices until I had first read up on and understood all of the intricacies of the *specific* model I was working with, because you never know what is easily undo-able and what isn't.

    If you compare partition tables between different models of handsets, about the only commonalities when it comes to Android fixed-storage partition structure is 'boot', 'system', 'cache', and '[user]data'. There are typically tons of other various vendor-specific partitions storing who-knows-what data often with who-knows-what filesystems that (as your unfortunate particular story bears out) can be vital to the operation of the device as a whole. (It does seem foolhardy to me that manufacturers would choose to store those bits on the same storage medium as the rest of the system and user data, rather than in a separate ROM chip, but this is aggravatingly common in the world of embedded systems, probably as a cost-cutting measure...)

    I *am* sorry for your loss, though... :(