!Hard-brick (qhsusb_dload) after OTA2014 reduced flash? back alive via RIFF-Box JTAG!

Search This thread

kimba99

Senior Member
Mar 17, 2013
291
104
yesterday when i tried to update the radio on my dinc4g (including rcdata=radio_data and rpm=radio-powermanagement, but somehow i thought it should be okay to also include boot.img (as this is reversible by TWRP recovery and tz=trusted_zone!!) ... before i compared to similar (but supposedly reversible!! partial firmware updates with their matching firmware downgrades ... all only suggested to remove at least hboot.img and stock-recovery if included) ... there was no new hboot in the new 2014 OTA firmware and stock-recovery (along with the 2ndary bootloaders) i had removed

everything also flashed just fine, no write failed, just all "OK / OKAY" and done, BUT ... after fastboot reboot ... the phone didn't come up anymore and is now STUCK on "QHSUSB_DLOAD" mode => bricked! damn ...

unfortunately the "regular" HTC unbrick tools do not support the Dinc4G ... now i'm hunting for solutions to recover my daily driver >.> already searched xda and elsewhere: tried at least brick-detect from HTC unbrick tools, but they are mainly looking if linux registers the "qhsusb_dload" _and_ adds the partitions of the phone to the running linux ... but mine only registers the serial-usb terminal from qhsusb_dload, but _not_ the phones partition(s) >_>

only thing i found is that the qualcomm QPST (oem preprogramming!) tool sees this device (albeit as said in download-mode only) and offers to flash certain things, but i do not have a QPST backup-file for the Dinc4G to compare to and/or use that to revive my phone.

i'm therefore looking for someone with a working (and at best similarly S-OFF'ed dinc4g phone to create such a QPST backup. :confused:

any help is highly welcome :(:rolleyes:
 
Last edited:

kimba99

Senior Member
Mar 17, 2013
291
104
further hunting the web and lots of reading here on XDA (for similarly bricked mobiles ... from almost every manufacturer!) ... the easiest (albeit not always working) idea comes down to the following:

getting a direct dump from the eMMC memory of a running/working system in a known good state:

Is anyone willing to dump the partition table/bootloader part from their working Dinc4G with FW 2.17.605.2 (the regular ICS4.0.4 without the most current 2014 OTA) for me?... best would be from an S-OFF device like mine i assume
, just to make sure it matches my situation, but S-ON should also work, as it's just for recovery-boot via microSD (if it work's on a Dinc4G)

in a busybox or other terminal as root (aka: su mode)
Code:
dd if=/dev/block/mmcblk0 of=/sdcard/backup.bin bs=1048576 count=256

this will dump the first 128MB of your own eMMC (internal memory) including your current and working partition table and some of the boot partitions

then just zip that "backup.bin" (which should greatly reduce its size!) ... uploaded it somewhere and forward me the link ...



thanks for your help!!! :fingers-crossed:
 
Last edited:

kimba99

Senior Member
Mar 17, 2013
291
104
thanks to j13smiley, who provided me with a eMMC dump from his Dinc4G ... i couldn't get my bricked fireball so far to failsafe-boot from the microSD with the dump he send me:

but I was able to reconstruct the filesystem-structure quite somewhat further than mdmower here http://xdaforums.com/showthread.php?t=2077608&page=7 with the descriptive help from this thread http://xdaforums.com/showthread.php?t=1959445 using the HOXL as a template for partition types on HTC devices

here is what i've come up with so far (analysing the /dev/mmcblk0 dump from j13smiley:
Code:
omitting empty partition (33)
Partition 33 is deleted

Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes                           =!size is wrong, due to using a 16GB uSD to dump the backup!=
1 heads, 16 sectors/track, 1944768 cylinders, total 31116288 sectors    =!same as above!=
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System			QCname
/dev/mmcblk0p1   *           1         256         128   4d  QNX4.x			SBL1(cfg_data)
/dev/mmcblk0p2             257         768         256   51  OnTrack DM6 Aux1		SBL2
/dev/mmcblk0p3             769      262110      130671   5d  Unknown
/dev/mmcblk0p4          262111    15269886     7503888    5  Extended			EXT
/dev/mmcblk0p5          262112      262143          16   5a  Unknown			(CID+IMEI)
/dev/mmcblk0p6          262145      262656         256   73  Unknown
/dev/mmcblk0p7          262658      293812       15577+  5b  Unknown
/dev/mmcblk0p8          293814      294325         256   5c  Priam Edisk
/dev/mmcblk0p9          294327      296374        1024   45  Unknown			SBL3(qscbl)
/dev/mmcblk0p10         296376      296887         256   47  Unknown			RPM(appsbl)
/dev/mmcblk0p11         296889      300984        2048   46  Unknown			TZ(oemsbl)
/dev/mmcblk0p12         300986      303033        1024   4c  Unknown			HBOOT(aboot/fota)
/dev/mmcblk0p13         303035      303098          32    0  Empty
/dev/mmcblk0p14         303100      315387        6144   34  Unknown			SPLASH
/dev/mmcblk0p15         315389      317436        1024   36  Unknown
/dev/mmcblk0p16         317438      319485        1024    0  Empty			(dsps)
/dev/mmcblk0p17         319487      411646       46080   77  Unknown			(radio)
/dev/mmcblk0p18         411648      432127       10240   7a  Unknown			(adsp/q6)
/dev/mmcblk0p19         432129      442368        5120    0  Empty			(wcnss)
/dev/mmcblk0p20         442370      458750        8190+  74  Unknown			(radio_config)
/dev/mmcblk0p21         458752      491519       16384   48  Unknown			BOOT(apps)
/dev/mmcblk0p22         491521      524287       16383+  71  Unknown			(recovery)
/dev/mmcblk0p23         524289      526333        1022+  76  Unknown			(misc)
/dev/mmcblk0p24         526335      534526        4096   4a  Unknown			MODEMST1
/dev/mmcblk0p25         534528      542719        4096   4b  Unknown			MODEMST2
/dev/mmcblk0p26         542721      583680       20480   19  Unknown			(devlog)
/dev/mmcblk0p27         583682      583689           4    0  Empty
/dev/mmcblk0p28         583691      584202         256   23  Unknown			(pdata)
/dev/mmcblk0p29         584204      584235          16    0  Empty
/dev/mmcblk0p30         584237      586797        1280+   0  Empty			(local)
/dev/mmcblk0p31         586799      586926          64    0  Empty
/dev/mmcblk0p32         586928      786431       99752    0  Empty			=!possibly wrong start/end&blocks!=
/dev/mmcblk0p33                                          83  EXT4			(system)
/dev/mmcblk0p34                                          83  EXT4			(cache)
/dev/mmcblk0p35                                          83  EXT4			(userdata)
/dev/mmcblk0p36                                           c  FAT32(LBA)			(fat)

not fully complete yet, but still much further improved over the previous partition layout details
 
Last edited:

mutterc

New member
Feb 10, 2014
2
0
Anything I can do to help?

I have qdload.pl, a MPRG8960.hex and 8960_msimage.mbn from some XDA thread or other (they don't seem to work though). My fireball is functional, rooted but S-ON (I got it early and htcdev still allowed me to unlock the bootloader). It does have the OTA update though.

I'm interested because my wife's fireball is stuck in QDL mode. She's migrated to a Rezound so it's not urgent.

I suspect it got that way because I used DirtyRacun S-OFF, then went to flash the OTA update. I suspect DR modifies hboot or one of the sbl's, and when I flashed the OTA it might have put me back S-ON.

(Got motivated to try to root her phone because even though it wasn't rooted, it kept trying and failing to download the OTA, killing the battery).

The DR website has an RUU.zip that has images of all the sbl's and an hboot, so working images isn't a problem, but getting them on there is.
 

kimba99

Senior Member
Mar 17, 2013
291
104
I have qdload.pl, a MPRG8960.hex and 8960_msimage.mbn from some XDA thread or other (they don't seem to work though). My fireball is functional, rooted but S-ON (I got it early and htcdev still allowed me to unlock the bootloader). It does have the OTA update though.
if you don't mind: plz attach your MPRG8960.hex and 8960_msimage.mbn files here ... so i could compare against those i have.

and well, if you are still S-ON _and_ the OTA-2014 is already applied then you are "out of luck" ... at least for the next couple of weeks or even months. no S-OFF method known for OTA-2014 applied fireballs!

I suspect it got that way because I used DirtyRacun S-OFF, then went to flash the OTA update. I suspect DR modifies hboot or one of the sbl's, and when I flashed the OTA it might have put me back S-ON.
afaik: DR "only" uses security holes in the firmware from 2.17.605.2 (from regular ICS4.0.4 RUU) to remove S-ON/write S-OFF flag ... and then add the engineering hboot of fireball (albeit modified) ... in the general section, several users with S-OFF (before the OTA-2014!) applied now the firmware from the OTA-2014 separately and confirmed that S-OFF stayed even after the OTA and since it doesn't include any new hboot, they still have their previous one

likewise, there are different qhsusb_dload modes, depending on WHEN they kicked in... in the sense of which stage fails (attaching your qdload-fireball to a linux system, there are at least 2 distinct possibilities: a) only qdload-mode or b) qdload-mode AND enumerating partitions ... the latter one is fairly easy to cure whereas the former (like mine) is much harder to come by unfortunately >_<

The DR website has an RUU.zip that has images of all the sbl's and an hboot, so working images isn't a problem, but getting them on there is.
they have a RUU.zip (for 2.17.605.2) and it has the firmware bit isolated and included, but that _won't help you at all_ with a bricked phone as you need a predefined partition-layout and -structure files _and_ then manage to get your brick to accept and all load those start-up settings at once. the RUU has only the files, but _not_ their structure!

i managed to already recreate most of the partition-structure of a fireball with the help from some other xda-members, but _still_ that wasn't enough for those software-tools i tried!! maybe my MPRG8960.hex isn't correct (193.692byte / md5sum: 2534fd61ebc7c8bdd9fe0dbb90c77fb0) ... i decided to buy another 2nd-hand fireball (hopefully it should still come W/O the OTA-2014 ;)) ... to create/dump what is on there to resurrect my bricked fireball, yet even that is still unclear if it will work. (need to wait a few more weeks until the other fireball arrives here: intl shipping & customs take quite a while unfortunately)
 
Last edited:

dcooterfrog

Senior Member
Dec 12, 2008
406
48
kimba.
first thanks for your help with the ota foirmare in theother tread. second HOW CAN I HELP YOU.

although I am on cm11 and have the firmware updated I think that is where you want to get to.

i am reasonable good with unix and adb with directions I am sure I can get anything you need off of my phone. let me know.
 
  • Like
Reactions: kimba99

mutterc

New member
Feb 10, 2014
2
0
if you don't mind: plz attach your MPRG8960.hex and 8960_msimage.mbn files here ... so i could compare against those i have.

likewise, there are different qhsusb_dload modes, depending on WHEN they kicked in... in the sense of which stage fails (attaching your qdload-fireball to a linux system, there are at least 2 distinct possibilities: a) only qdload-mode or b) qdload-mode AND enumerating partitions ... the latter one is fairly easy to cure whereas the former (like mine) is much harder to come by unfortunately >_<

[/i]

Attached as tar.gz, looks like from your size/md5sums that my MPRG8960.hex is the same.

Mine has only one device (qcserial) showing up in lsusb, which means it's not enumerating partitions, right? Which if I'm still S-OFF means one of the SBLs is scrod, right?
 

Attachments

  • 8960_progfiles.tar.gz
    449.5 KB · Views: 475
Last edited:

kimba99

Senior Member
Mar 17, 2013
291
104
Attached as tar.gz, looks like from your size/md5sums that my MPRG8960.hex is the same.

Mine has only one device (qcserial) showing up in lsusb, which means it's not enumerating partitions, right? Which if I'm still S-OFF means one of the SBLs is scrod, right?
don't just check lsusb ;) ... try the output of
Code:
dmesg | tail
BEFORE ... you attach the bricked fireball to your linux system & then right after attaching (about 10sec later or so should be enough) check again with the SAME
Code:
dmesg | tail
if it only attaches a "qualcomm usb-2-serial device on tty*" then you're in bad luck (as me) currently ... but if dmesg shows and lists some new "/dev/sdb1 /dev/sdb2 /dev/sdb3" devices and so on ... you can fairly easy fix it (at least as _now_ we/i had extracted or better said reconstructed the partition-layout and thereby we could flash any borked or unmatching partition directly).

as for S-OFF, that _should_ have nothing to do with the reason for the brick as there are already fellows here with properly updated OTA2014 firmware _working_ with properly retained S-OFF ... and secondly, it doesn't have to be one of your SBL2*'s as it could also be TZ or RPM not matching one another (as far as I understood the SecureBoot3.0-chain) ... so it depends WHICH file you (tried to) flash (and how) that leaded to your brick.


EDIT: as for your attached MSM8960-files ... identical to mine and thereby unfortunately NOT working (afaik) for recovery of a fireball T_T
 
Last edited:
  • Like
Reactions: itssunnyalii

Ngaihte04.16

New member
Dec 21, 2013
1
0
any improvements on this problem? I'm having the same problem with my phone so please let me know if you find a way to fix this problem....
 

kimba99

Senior Member
Mar 17, 2013
291
104
bought another Dinc4G ... in replacement for my bricked one. in my trail to revive my bricked one (and/or having another Dinc4g at least to use regularly with a ROM of my choice again)

after requested, the seller _confirmed_ that the 2014-OTA has __not__ yet been applied and the phone still runs fine on 2.17.605.2 ... and "guess what" i received yesterday in my mail:
his Dinc4G _WITH_ the 2014-OTA applied & of course it's stock/locked/s-on!!!
DAMN IT!!!
 

therreid

Senior Member
Nov 16, 2012
144
11
Wyoming
bought another Dinc4G ... in replacement for my bricked one. in my trail to revive my bricked one (and/or having another Dinc4g at least to use regularly with a ROM of my choice again)

after requested, the seller _confirmed_ that the 2014-OTA has __not__ yet been applied and the phone still runs fine on 2.17.605.2 ... and "guess what" i received yesterday in my mail:
his Dinc4G _WITH_ the 2014-OTA applied & of course it's stock/locked/s-on!!!
DAMN IT!!!

That sucks. Having this phone unrooted with the 2014 update is a little like being Sandra Bullock in the film Gravity. I sure hope there's someone smarter than me working on root for this thing with the 2014 update.
 

kimba99

Senior Member
Mar 17, 2013
291
104
not many users (or even devs!) left on our Dinc4G .... pretty unfortunate

i mean temp-root still work's (apparently) on the 2014-OTA ... and the hboot didn't change at all (it's still 1.15) ... i assume one needs to find a way to perm-root the new 2.19.605.2 stock-rom first & from there try the same (or at least similar) "s-off" attack to the 1.15-hboot as previously. it's just that the devs of the prev s-off methods don't tell WHERE or HOW they obtained write-permission to set the s-off flag

still: i managed to trigger the "tampered"-flag above my "*locked*"-flag ... *lol*
 

junkmail9

Senior Member
bought another Dinc4G ... in replacement for my bricked one. in my trail to revive my bricked one (and/or having another Dinc4g at least to use regularly with a ROM of my choice again)

after requested, the seller _confirmed_ that the 2014-OTA has __not__ yet been applied and the phone still runs fine on 2.17.605.2 ... and "guess what" i received yesterday in my mail:
his Dinc4G _WITH_ the 2014-OTA applied & of course it's stock/locked/s-on!!!
DAMN IT!!!

With the news of the new s-off method for the latest OTA, I was wondering if you were able to fix your phone. Looks like the answer is no, buuuut, you now have s-off with the latest OTA! :good: !
 

kimba99

Senior Member
Mar 17, 2013
291
104
With the news of the new s-off method for the latest OTA, I was wondering if you were able to fix your phone. Looks like the answer is no, buuuut, you now have s-off with the latest OTA! :good: !
unfortunately not (yet?) ... but at least, i'm near exactly where i was left on the new phone! real incredible that i could restore my nandroid from the borked phone directly to the new one (okay, after i figured out i need to rename the TWRP-backup folder to match ne new ADB-ID of the phone :p ... only missing a bunch of photos, that i didn't backup prior to the brick.

i'll try again later, but the brick still doesn't accept to be flashed either way by QPST as it says it is missing "its magical token" (whatever that means, but there are several posts about that specific QPST issue with qhsusb_dload bricked phones here on xda) :mad:
 

kimba99

Senior Member
Mar 17, 2013
291
104
finally solved ... but that SURE wasn't for the faint hearted => poor fireball had to strip completely (disassambled) ... JTAG pins are ___under___ the IMEI-battery sticker even (so that had to be removed as well) ... before the "solder party" could begin.

and then thanks to _huzein_ from "gsm-europe" (who provided the RIFF-box and soldering for some smaller money) ... and the famous _legija_ ... the developer of the RIFF-box himself! (who guided us and reflashed my brick via a remote RIFF-session) ... flashing a bricked "HTC fireball" via JTAG for the very FIRST time!! we used the dump from jsmiley13 (so thanks to him again for providing me with the dump) ... after that we needed to reflash the ENG-HBOOT (via RIFF JTAG interface again) though as it had the 1.15.1111 but showed S-OFF _locked_ ?!

now it's back alive ... after 2hrs of remote debugging, remote-flashing etc ... hopefully now, legija can implement a NEW ressurrector.dll for fireball (for the 1ST TIME) and add it as a by now newly supported device on his RIFF-box!



attached below is a small "photo-story" ... for those who are interested *lol* ... and NO it's not an optical illusion, the panels definitely appear to have some slightly different color-hue (esp the green looks not the same)
 

Attachments

  • IMAG0521s.jpg
    IMAG0521s.jpg
    128.5 KB · Views: 368
  • IMAG0528Ls.jpg
    IMAG0528Ls.jpg
    143.3 KB · Views: 347
  • IMAG0541s.jpg
    IMAG0541s.jpg
    132.1 KB · Views: 339
  • IMAG0542s.jpg
    IMAG0542s.jpg
    191 KB · Views: 336
  • P1050791s.JPG
    P1050791s.JPG
    155.8 KB · Views: 335
  • Like
Reactions: junkmail9

dmbtech

Senior Member
Mar 18, 2010
73
16
Morristown, New Jersey
finally solved ... but that SURE wasn't for the faint hearted => poor fireball had to strip completely (disassambled) ... JTAG pins are ___under___ the IMEI-battery sticker even (so that had to be removed as well) ... before the "solder party" could begin.

and then thanks to _huzein_ from "gsm-europe" (who provided the RIFF-box and soldering for some smaller money) ... and the famous _legija_ ... the developer of the RIFF-box himself! (who guided us and reflashed my brick via a remote RIFF-session) ... flashing a bricked "HTC fireball" via JTAG for the very FIRST time!! we used the dump from jsmiley13 (so thanks to him again for providing me with the dump) ... after that we needed to reflash the ENG-HBOOT (via RIFF JTAG interface again) though as it had the 1.15.1111 but showed S-OFF _locked_ ?!

now it's back alive ... after 2hrs of remote debugging, remote-flashing etc ... hopefully now, legija can implement a NEW ressurrector.dll for fireball (for the 1ST TIME) and add it as a by now newly supported device on his RIFF-box!



attached below is a small "photo-story" ... for those who are interested *lol* ... and NO it's not an optical illusion, the panels definitely appear to have some slightly different color-hue (esp the green looks not the same)
Looks like I am also having the same issue. Did an exchange remote wipe and came back to my phone completely bricked, Q Download mode. I am guessing the only way is to JTAG the device? Is there any other possibilities? I have qpst, and hpst etc. What is the hex and mbn image used for?
 

kimba99

Senior Member
Mar 17, 2013
291
104
Looks like I am also having the same issue. Did an exchange remote wipe and came back to my phone completely bricked, Q Download mode. I am guessing the only way is to JTAG the device? Is there any other possibilities? I have qpst, and hpst etc. What is the hex and mbn image used for?

depends on HOW your fireball was bricked ... but plain QPST or similar won't help as our CPU, the MSM8960, is toooo new and the unsigned usb-loader (like QPST) won't work ... at least if it's a firmware brick!!! (as legija explained to me)

only JTAG'ing via RIFF-box would help here, _but_ official support from RIFF is _NOT yet_ given (today using my brick was his trail run for "fireball") ... it should be implemented within the next days or a few weeks maybe.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    kimba.
    first thanks for your help with the ota foirmare in theother tread. second HOW CAN I HELP YOU.

    although I am on cm11 and have the firmware updated I think that is where you want to get to.

    i am reasonable good with unix and adb with directions I am sure I can get anything you need off of my phone. let me know.
    1
    Attached as tar.gz, looks like from your size/md5sums that my MPRG8960.hex is the same.

    Mine has only one device (qcserial) showing up in lsusb, which means it's not enumerating partitions, right? Which if I'm still S-OFF means one of the SBLs is scrod, right?
    don't just check lsusb ;) ... try the output of
    Code:
    dmesg | tail
    BEFORE ... you attach the bricked fireball to your linux system & then right after attaching (about 10sec later or so should be enough) check again with the SAME
    Code:
    dmesg | tail
    if it only attaches a "qualcomm usb-2-serial device on tty*" then you're in bad luck (as me) currently ... but if dmesg shows and lists some new "/dev/sdb1 /dev/sdb2 /dev/sdb3" devices and so on ... you can fairly easy fix it (at least as _now_ we/i had extracted or better said reconstructed the partition-layout and thereby we could flash any borked or unmatching partition directly).

    as for S-OFF, that _should_ have nothing to do with the reason for the brick as there are already fellows here with properly updated OTA2014 firmware _working_ with properly retained S-OFF ... and secondly, it doesn't have to be one of your SBL2*'s as it could also be TZ or RPM not matching one another (as far as I understood the SecureBoot3.0-chain) ... so it depends WHICH file you (tried to) flash (and how) that leaded to your brick.


    EDIT: as for your attached MSM8960-files ... identical to mine and thereby unfortunately NOT working (afaik) for recovery of a fireball T_T
    1
    finally solved ... but that SURE wasn't for the faint hearted => poor fireball had to strip completely (disassambled) ... JTAG pins are ___under___ the IMEI-battery sticker even (so that had to be removed as well) ... before the "solder party" could begin.

    and then thanks to _huzein_ from "gsm-europe" (who provided the RIFF-box and soldering for some smaller money) ... and the famous _legija_ ... the developer of the RIFF-box himself! (who guided us and reflashed my brick via a remote RIFF-session) ... flashing a bricked "HTC fireball" via JTAG for the very FIRST time!! we used the dump from jsmiley13 (so thanks to him again for providing me with the dump) ... after that we needed to reflash the ENG-HBOOT (via RIFF JTAG interface again) though as it had the 1.15.1111 but showed S-OFF _locked_ ?!

    now it's back alive ... after 2hrs of remote debugging, remote-flashing etc ... hopefully now, legija can implement a NEW ressurrector.dll for fireball (for the 1ST TIME) and add it as a by now newly supported device on his RIFF-box!



    attached below is a small "photo-story" ... for those who are interested *lol* ... and NO it's not an optical illusion, the panels definitely appear to have some slightly different color-hue (esp the green looks not the same)