Hard bricked Moto G8 Power by flashing TWRP to recovery slots

Search This thread

marc.2377

Member
Mar 20, 2018
17
6
I bricked my phone (XT2041-1 "sofiar") by flashing an unnoficial build of TWRP 3.5.0 downloaded from a Telegram channel by doing:

$ fastboot flash recovery_a twrp-3.5.0-0-rav-sofia.img $ fastboot flash recovery_b twrp-3.5.0-0-rav-sofia.img $ fastboot reboot recovery

Since then, my phone is hard bricked - won't boot, recognized on Linux in EDL Mode only (i.e. ID 05c6:9008).

I got the latest official stock firmware, named SOFIAR_RETAIL_11_RPES31.Q4U-47-35-12_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip, from lolinet, and in its contents there's boot.img and recovery.img (among others).

I have qdl on my Arch Linux, and am wondering whether I can use it to flash the stock recovery image back to both slots and get my phone booting again.

How should I approach it?

P.s. I also got a blankflash from https://forum.xda-developers.com/t/...equest-solicitud-blankflash-g8-power.4431193/ that is supposed to get the phone working again, but am unsure whether using it will cause loss of data.

I absolutely cannot lose any data from internal storage.

Any help appreciated. Thanks in advance.
 

Renate

Recognized Contributor / Inactive Recognized Dev
Ok, now we're rolling...

First things first. Motorola sucks because they only give you restricted Firehose loaders.
That means of the 70-odd partitions that you have you can only read/write about 1/3 of them using EDL.
If you post your Firehose loader I can tell you which ones you can read/write.

Second, are you sure that the only damage you did was by writing recovery_a and recovery_b?

And you're on Linux, *sad face*.

I was disassembling the Motorola Firehose for my Moto G (2021) and I discovered that they have more reboot options than stock.
There's reset-to-edl and reset-to-fastboot.
I've added those options to my edl.exe (in the sig) this morning. You need to download the very latest.

What may have happened is that you wrote a bad recovery which may have set the boot option in the BCB or misc.
Since the recovery is good enough to be recognized as an image but not good enough to reset this boot option you're stuck.
Your first recourse is flashing a proper recovery.

I'm not sure whether "blank flash" tries to wipe everything. In any case I wouldn't risk it.
Your first try should be to fix the broken things, not everything.

Yes, any edl client that supports ad-hoc xml should be able to get you to fastboot but I'll only answer for my code.
I've tested it.
Code:
C:\>edl /lwhatever.bin
C:\>edl /zf
C:\>fastboot flash recovery_a good_recovery.img
C:\>fastboot flash recovery_b good_recovery.img
C:\>fastboot reboot
 

marc.2377

Member
Mar 20, 2018
17
6
I admit to not properly understand what a firehose loader is. :x

Second, are you sure that the only damage you did was by writing recovery_a and recovery_b?
Yes, 100%.

So, for now, I should try booting Windows, installing the 9008 driver and following your instructions... Will let you know how it goes.

Thanks a lot.
 

Renate

Recognized Contributor / Inactive Recognized Dev
I admit to not properly understand what a firehose loader is. :x
A Firehose loader is a replacement xbl/sbl secondary loader that has special sauce added to it to make it interactive.
It is not to be confused with a Windows driver (which, in this case is Zadig, as per the instructions on my web page).

In this case, your Firehose loader is packed in singleimage.bin in the RPE here: https://mirrors.lolinet.com/firmware/motorola/sofiar/blankflash/
I extracted it for you. I renamed it sofiar.bin
The extension name does not matter.
Code:
C:\>edl /lsofiar.bin
That's slash-ell-sofiar.bin

Edit: And yes, your Firehose loader has the reset-to-fastboot.
 

Attachments

  • sofiar.bin
    599.5 KB · Views: 2
  • Like
Reactions: marc.2377

marc.2377

Member
Mar 20, 2018
17
6
Right, thanks for the explanation. I figured that was programmer.elf from my files.

Ok, I got as far as:

> edl /l Found EDL 9008 Serial: 69cccc95 HWID: 0010a0e102e80000, QC: 0010a0e1, OEM: 02e8, Model: 0000 Hash: 974359c4290cac7f-9f0dc9a802815b5e-2b376b7a7c1be92c-1e816b5287f18610 > edl /lsofiar.bin Found EDL 9008 Resetting Sahara Serial: 69cccc95 HWID: 0010a0e102e80000, QC: 0010a0e1, OEM: 02e8, Model: 0000 Hash: 974359c4290cac7f-9f0dc9a802815b5e-2b376b7a7c1be92c-1e816b5287f18610 Sending sofiar.bin 100% Ok Waiting for Firehose... Ok > edl.exe /zf Found EDL 9008 Requesting reset to fastboot... Ok

But it doesn't boot to fastboot.

It seems to me that your tool, edl could be used to write the recovery partition directly, no?
I tried this:

> edl /w /precovery_a recovery.img Found EDL 9008 Configuring... Ok Requesting GPT 0 header... Ok, receiving... Ok, requesting entries... Ok, receiving... Ok Requesting write recovery.img... <log value="ERROR: range restricted: lun=0, start_sector=1591552, num_sectors=131072" /> Nope

P.s. curiously, the file I downloaded from https://raw.githubusercontent.com/b...a/0010a0e102e80000_974359c4290cac7f_fhprg.bin wasn't accepted as a valid firehose loader file.
Edit: nevermind. Had to restart the phone.
I believe that's an older loader, anyway.

How shall I proceed?
 
Last edited:

Renate

Recognized Contributor / Inactive Recognized Dev
But it doesn't boot to fastboot.
Hmm, the screen stays black?
Is it still in EDL mode or some other mode?
Does Windows "bong" when you pull the USB cable?
It's possible that this goes to a fastboot without a screen?
Try holding various buttons, both by long power button reset and /zf

It seems to me that your tool, edl could be used to write the recovery partition directly, no?
Yes, it could if Motorola wasn't such a pain with the "range restricted".

They've really clamped down (that other file you mentioned is the same):
Code:
qcomview /r sofiar.bin
 Addr   LUN     Start     Count
------  ---  --------  --------
007f10   0          0       256
007f28   0        256     78336
007f40   0    1609948       512
007f58   0    1610496       512
007f70   1          1         1
You can do this to see which partitions this means:
Code:
C:\>edl /lsofiar.bin
C:\>edl /g
I have a feeling that the Motorola "Blankflash" stuff writes something to those 3 areas that allow it to write everything.
But it probably wipes the userdata.
I'm not an expert on their tools.
Tell me what the GPT says (you only need to quote stuff in the area of that table).

Edit: It looks like in the multi GB zip there are two "instruction" files, flashfile.xml and servicefile.xml
They are mostly the same except that flashfile will wipe userdata!
 
Last edited:
  • Like
Reactions: marc.2377

marc.2377

Member
Mar 20, 2018
17
6
Curious. The partition table is as follows:

Code:
Found EDL 9008
Configuring... Ok
Requesting GPT 0 header... Ok, receiving... Ok, requesting entries... Ok, receiving... Ok

 #  Name                   Start       Count  Type
--  ----------------  ----------  ----------  --------------------
 1  xbl_a                    256        9216  Inactive
 2  xbl_b                   9472        9216  Bootloader
 3  tz_a                   18688        8192  Inactive
 4  tz_b                   26880        8192  TrustZone
 5  rpm_a                  35072        1024  Inactive
 6  rpm_b                  36096        1024  Resource/power mgmt
 7  hyp_a                  37120        1024  Inactive
 8  hyp_b                  38144        1024  Hypervisor
 9  devcfg_a               39168         256  Inactive
10  devcfg_b               39424         256  Device config
11  xbl_config_a           39680         256  Inactive
12  xbl_config_b           39936         256  Boot config
13  abl_a                  40192        2048  Inactive
14  abl_b                  42240        2048  Android bootloader
15  uefisecapp_a           44288        4096  Inactive
16  uefisecapp_b           48384        4096    be8a7e08 
17  qupfw_a                52480         160  Inactive
18  qupfw_b                52736         160  QUP firmware
19  cmnlib_a               52992        1024  Inactive
20  cmnlib64_a             54016        1024  Inactive
21  cmnlib_b               55040        1024  Common lib
22  cmnlib64_b             56064        1024  Common lib64
23  keymaster_a            57088        1024  Inactive
24  keymaster_b            58112        1024  Key master
25  storsec_a              59136         256  Inactive
26  storsec_b              59392         256  Store secure
27  spunvm                 59648       16384  Spun VM
28  uefivarstore           76032        1024    165bd6bc 
29  multiimgoem_a          77056          64  Inactive
30  multiimgoem_b          77120          64    e126a436 
31  multiimgqti_a          77184          64  Inactive
32  multiimgqti_b          77248          64    846c6f05 
33  prov_a                 77312         512  Inactive
34  prov_b                 77824         512    d05e0fc0 
35  modem_a                78336      368640  Inactive
36  modem_b               446976      368640  FAT32
37  fsc                   815616         256  FSC
38  ssd                   815872          16  Secure SW download
39  dsp_a                 816128       65536  Inactive
40  dsp_b                 881664       65536  DSP
41  ddr                   947200        2048  DDR
42  utags                 949248        1024    1dd40d18 
43  utagsBackup           950272        1024    c490f39c 
44  modemst1              951296        8192  Modem ST1
45  modemst2              959488        8192  Modem ST2
46  fsg_a                 967680       49152  Inactive
47  fsg_b                1016832       49152  Modem storage
48  persist              1065984       65536  Persist
49  prodpersist          1131520       16384  Persist
50  frp                  1147904        1024  FRP
51  cid                  1148928         256    459abd04 
52  carrier              1149184       32768    c63d32d8 
53  metadata             1181952       32768    988a98c9 
54  kpan                 1214720       16384    56465e10 
55  boot_a               1231104      131072  Inactive
56  boot_b               1362176      131072  Boot
57  dtbo_a               1493248       49152  Inactive
58  dtbo_b               1542400       49152  DTBO
59  recovery_a           1591552      131072  Inactive
60  recovery_b           1722624      131072  Recovery
61  misc                 1853696        2048  Misc
62  logfs                1855744       16384  Log FS
63  apdp                 1872128         512  APDP
64  msadp                1872640         512  MSADP
65  dpo                  1873152           2  DPO
66  devinfo              1873160           8  Device info
67  bluetooth_a          1873168        9216  Inactive
68  bluetooth_b          1882384        9216  Bluetooth
69  logo_a               1891600       66848  Inactive
70  logo_b               1958448       66848  Splash
71  vbmeta_a             2025296         128  Inactive
72  vbmeta_b             2025424         128  Verified Boot meta
73  padA                 2025552        6064  Empty
74  hw                   2031616       16384    b2d77ec0 
75  padB                 2048000       16384  Empty
76  sp                   2064384       16384    40aef62a 
77  padC                 2080768       16384  Empty
78  padD                 2097152       32768  Empty
79  super                2129920    16973824  System
80  userdata            19103744   103038943  User data

Doesn't seem to match the output of qcomview.

Also, the file 0010a0e102e80000_974359c4290cac7f_fhprg.bin lists the following codenames:

Code:
QCA6390
QCS605
SA8150
SDA670
SDA845
SDA855
SDA855A
SDA865
SDC830
SDM450
SDM670
SDM830
SDM845
SDM855
SDM855A
SDM1000
SDX24
SDX24M
SDX55
SM6150
SM6150P
SM7150
SM7150P
SM_NICOBAR

While programmer.elf (same as sofiar.bin that you uploaded) lists, additionally, QCM_NICOBAR and QCS_NICOBAR.

I wonder whether this is actually the correct file for me...

Btw, before attempting any further writing strategies, I confess to being interested in pulling userdata. As I understand the real decryption key is stored in the TEE functionality of the chipset and such an image would be unreadable for me, except if I were to restore it later.

With your tool I got the "range restricted" for edl /r /puserdata parts\userdata.img /t too.
 

Renate

Recognized Contributor / Inactive Recognized Dev
Code:
 Addr   LUN     Start     Count
------  ---  --------  --------
007f10   0          0       256  -  GPT
007f28   0        256     78336  -  xbl_a to prov_b
007f40   0    1609948       512  -  ??? random spot in recovery_a
007f58   0    1610496       512  -  ??? random spot in recovery_a
007f70   1          1         1
So, basically, you have free read/write access to partions 1 to 34
Reading is always safe.
Also, you're on the B slot.

So why does reboot to fastboot fail?
  • It could be that it was never implemented correctly in this Firehose
  • It could be that this Firehose is not for your device
  • It could be that xbl and/or abl was damaged somehow

I'd do some checking, xbl_b and abl_b to start with.
Read 'em then compare them to the xbl and abl you have in your big packages.
Code:
C:\>edl /lsofiar.bin
C:\>edl /r /t /pxbl_b xblb.img
C:\>edl /r /t /pabl_b ablb.img
The /t will copy these ELF files only as big as they need to be (not all the blank space).
OTOH, they will enlarge to an exact number of 512 byte sector.
So they could be 511 bytes bigger than what comes out of that package.
If things are wacky, try without /t, but they'll be padded with all the zeroes in the partition.

If those files aren't in the big package, here's ones I extracted from the blankflash.
Check 'em all.
 

Attachments

  • sofiar-xbl.bin
    3.9 MB · Views: 1
  • sofiar-abl.bin
    332 KB · Views: 3
  • Like
Reactions: marc.2377

marc.2377

Member
Mar 20, 2018
17
6
Hey, thanks for the continued efforts to help me. Sorry for absence for the past days, real life caugh in ^^

I'm glad to report that, amidst some binary checking and all that, I managed to resuscitate my phone using the blankflash strategy, after carefully revising it.

Strangely, it seems that TWRP got installed in the boot partition, such as that "normal boot" kept entering TWRP, despite I having flashed the stock recovery images to both recovery slots. I'll detail this all later.

At this point my phone is on and I backed up what I needed, and have been using it. A few strange glitches are present, i.e. battery charging is acting weird. I plan on doing a clean flashing of the stock ROM soon. Maybe I should take the opportunity to study how to make a fully working port of the latest LineageOS for this device, too.

Will get back within a few days with a detailed report of the endeavour :)
 

ybea

Member
Jul 4, 2020
9
2
Will get back within a few days with a detailed report of the endeavour :)
I'm looking forward to hearing how you got EDL mode working.

I bricked XT2041-3 Sofiar (downgrade to A10) and am stuck trying the phone to succeed at qboot blank-flash, but it hangs (on linux):
Code:
< waiting for device >
Motorola qboot utility version 3.86
[  0.000] Opening device: /dev/ttyUSB0
[  0.000] Detecting device
[  0.002] ...cpu.id  = 266 (0x10a)
[  0.002] ...cpu.sn  = 3773339940 (0xe0e89924)
[  0.002] Opening singleimage
[  0.002] Loading package
[  0.004] ...filename = pkg.xml
[  0.005] Loading programmer
[  0.005] ...filename = programmer.elf
[  0.005] Sending programmer
[  0.178] Handling things over to programmer
[  0.178] Identifying CPU version
[  0.178] Waiting for firehose to get ready

With --debug=2 there can be seen some parsing errors in xmls being passed for about 13 more seconds. On Windows VM phone is recognized as a single QDLoader 9008 device, but qboot fails after half a minute with IO Errors. Is this even EDL mode?

A tried without luck Renate's edl tool. edl.exe /lsingleimage.bin:
Code:
Found EDL 9008
Could not open device

I was growing increasingly desperate, so I opened the phone and played with EDL points according to
MatiasLopezxD. No combination of vol-, power, shorting points, plugging usb seem to make a difference. I must be missing something simple.

Any help would be appreciated.
 
Last edited:

marc.2377

Member
Mar 20, 2018
17
6
@ybea: Quick answer for now - I got into EDL mode by holding down VolDown+Power for about 8-10 seconds. Let me know if it works for you. What's your output for lsusb?
 

ybea

Member
Jul 4, 2020
9
2
Same as yours - ID 05c6:9008 (Qualcomm, Inc. Gobi Wireless Modem (QDL mode)). It reconnects after pressing power for 9 seconds (with or without vol-), nothing new.
 

marc.2377

Member
Mar 20, 2018
17
6
Try restarting it into EDL mode while it's plugged. I found that to be necessary sometimes.

Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...
 
  • Like
Reactions: ybea

ybea

Member
Jul 4, 2020
9
2
Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...

That was it! I didn't event try it on the metal, because Motorola driver installer and uninstaller crash for me for some reason. Should be straightforward from now.

Thank you so much. You saved the day.
 
Last edited:
  • Like
Reactions: marc.2377

Renate

Recognized Contributor / Inactive Recognized Dev
A tried without luck Renate's edl tool. edl.exe /lsingleimage.bin
Sorry. edl.exe uses the generic Zadig (i.e. WinUsb) driver).
If you have the Qualcomm driver loaded it's stealing the poor WinUsb interface and forcing it into some bogus virtual com port.

Also, singleimage is Motorola's completely morally bankrupt idea of packing stuff in a file.
It is not a Firehose loader, although it contains one.

Add to all your miseries, Motorola is crap and releases only restricted Firehose loaders.

If you're still stuck, ship me the "single-and-totally-bogus.bin" and I'll extract the Firehose loader for you.
Better poke me or I won't see it.
 
  • Like
Reactions: marc.2377

ybea

Member
Jul 4, 2020
9
2
No longer stuck. The problem for me was neither VM USB passthrough nor blankflash tools for linux did work, although both showed proper EDL mode. It seems it only works on native Windows. Thanks for your interest.
 
  • Like
Reactions: marc.2377

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    I admit to not properly understand what a firehose loader is. :x
    A Firehose loader is a replacement xbl/sbl secondary loader that has special sauce added to it to make it interactive.
    It is not to be confused with a Windows driver (which, in this case is Zadig, as per the instructions on my web page).

    In this case, your Firehose loader is packed in singleimage.bin in the RPE here: https://mirrors.lolinet.com/firmware/motorola/sofiar/blankflash/
    I extracted it for you. I renamed it sofiar.bin
    The extension name does not matter.
    Code:
    C:\>edl /lsofiar.bin
    That's slash-ell-sofiar.bin

    Edit: And yes, your Firehose loader has the reset-to-fastboot.
    1
    But it doesn't boot to fastboot.
    Hmm, the screen stays black?
    Is it still in EDL mode or some other mode?
    Does Windows "bong" when you pull the USB cable?
    It's possible that this goes to a fastboot without a screen?
    Try holding various buttons, both by long power button reset and /zf

    It seems to me that your tool, edl could be used to write the recovery partition directly, no?
    Yes, it could if Motorola wasn't such a pain with the "range restricted".

    They've really clamped down (that other file you mentioned is the same):
    Code:
    qcomview /r sofiar.bin
     Addr   LUN     Start     Count
    ------  ---  --------  --------
    007f10   0          0       256
    007f28   0        256     78336
    007f40   0    1609948       512
    007f58   0    1610496       512
    007f70   1          1         1
    You can do this to see which partitions this means:
    Code:
    C:\>edl /lsofiar.bin
    C:\>edl /g
    I have a feeling that the Motorola "Blankflash" stuff writes something to those 3 areas that allow it to write everything.
    But it probably wipes the userdata.
    I'm not an expert on their tools.
    Tell me what the GPT says (you only need to quote stuff in the area of that table).

    Edit: It looks like in the multi GB zip there are two "instruction" files, flashfile.xml and servicefile.xml
    They are mostly the same except that flashfile will wipe userdata!
    1
    Code:
     Addr   LUN     Start     Count
    ------  ---  --------  --------
    007f10   0          0       256  -  GPT
    007f28   0        256     78336  -  xbl_a to prov_b
    007f40   0    1609948       512  -  ??? random spot in recovery_a
    007f58   0    1610496       512  -  ??? random spot in recovery_a
    007f70   1          1         1
    So, basically, you have free read/write access to partions 1 to 34
    Reading is always safe.
    Also, you're on the B slot.

    So why does reboot to fastboot fail?
    • It could be that it was never implemented correctly in this Firehose
    • It could be that this Firehose is not for your device
    • It could be that xbl and/or abl was damaged somehow

    I'd do some checking, xbl_b and abl_b to start with.
    Read 'em then compare them to the xbl and abl you have in your big packages.
    Code:
    C:\>edl /lsofiar.bin
    C:\>edl /r /t /pxbl_b xblb.img
    C:\>edl /r /t /pabl_b ablb.img
    The /t will copy these ELF files only as big as they need to be (not all the blank space).
    OTOH, they will enlarge to an exact number of 512 byte sector.
    So they could be 511 bytes bigger than what comes out of that package.
    If things are wacky, try without /t, but they'll be padded with all the zeroes in the partition.

    If those files aren't in the big package, here's ones I extracted from the blankflash.
    Check 'em all.
    1
    Try restarting it into EDL mode while it's plugged. I found that to be necessary sometimes.

    Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...
    1
    Edit: Btw, I don't remember why exactly, but I only had success running the blankflash from Windows. Linux didn't do the magic, nor a Windows VM with USB redirection...

    That was it! I didn't event try it on the metal, because Motorola driver installer and uninstaller crash for me for some reason. Should be straightforward from now.

    Thank you so much. You saved the day.