[R&D][QUALCOMM] Using QDL, EHostDL and DIAG interfaces & features

SouL Shadow · Feb 14, 2013

the_laser said:
for information, dump is not raw dump from memory.
it "processed" by HDLC packet escape and need to be cleaned with something like this:

Code:

iCount:=0; oCount:=0; while iCount<=FileSize-1 do begin if input[iCount]=$7D then begin output[oCount]:=input[iCount+1] xor $20; inc(iCount); end else output[oCount]:=input[iCount+1]; inc(iCount); inc(oCount); end;

Thanks. What language is that?

-SLS-

darkspr1te · Feb 15, 2013

SouL Shadow said:
Thanks. What language is that?

-SLS-

Looks pseudo code. But its good to know that revskills does not fully support hdlc as it's meant to remove the 0x7d 0x5a end frames and didn't

sent from the Darkspr1te's lair

sjravi · Feb 19, 2013

This might be of some help http://www.mediafire.com/?3ppihsw8j3y9vbd

newbit · Feb 19, 2013

sjravi said:
This might be of some help http://www.mediafire.com/?3ppihsw8j3y9vbd

Didnt work with QPST_2.7_378 and Samsung Rugby Pro I847C MSM8690
-> Cookie not Present Error :crying:

But anyway, very BIG THX :fingers-crossed:

SecUpwN · Feb 19, 2013

AW: [R&D][QUALCOMM] Using QDL, EHostDL and DIAG interfaces & features

Anyone wanting to help coding a Security App?

SouL Shadow · Feb 19, 2013

newbit said:
Didnt work with QPST_2.7_378 and Samsung Rugby Pro I847C MSM8690
-> Cookie not Present Error :crying:

But anyway, very BIG THX :fingers-crossed:

Short answer:

The "Cookie not Present Error" means you're phone is not in the PBL's EhostDL.

Long answer:

Because the same qhsusb_dload (aka download mode) is built in to each stage of the boot process (pbl, sbl1, sbl2, sbl3) and different features are only available at certain stages, the "boot cookie" is used to help identify to QPST when you're in the pbl.

Think of it this way, download mode is a type of fatal error handler. If during the boot process an error is encountered preventing further boot up, that error is logged to memory and control is transfered to the download mode built in to the highest successfully loaded bootloader.

Turn phone on -> Load PBL from SoC
PBL does very basic hardware init and loads SBL1 from emmc
SBL1 does more hardware init and loads SBL2 from emmc
SBL2 does other hardware init and eventually loads SBL3 from emmc
SBL3 does final hardware init and loads APSBL (aka OEMSBL: aboot, hboot, etc...)

At any stage above, if a fatal error is encountered, then download mode in the corresponding bootloader is entered. EhostDL (aka Emergency Host Download or Emergency Download) is ONLY available from the PBL and is only used to load the corresponding .hex file which will do just enough basic hardware init to allow the rest of the bootloaders (and the emmc partition table) to be downloaded and flashed to the phone.

This is just a quick overview. For a more in depth look at the entire boot process, please look at the documents linked from E:V:A's msm8960 thread (there's a link to his thread in the OP). In particular, there is a 30-40 page pdf which details the boot process, including memory addresses, and has some nice flow charts which help to visualize what I briefly touched upon.

-SLS-

saketh91 · Feb 20, 2013

SouL Shadow said:
Short answer:

The "Cookie not Present Error" means you're phone is not in the PBL's EhostDL.

Long answer:

Because the same qhsusb_dload (aka download mode) is built in to each stage of the boot process (pbl, sbl1, sbl2, sbl3) and different features are only available at certain stages, the "boot cookie" is used to help identify to QPST when you're in the pbl.

Think of it this way, download mode is a type of fatal error handler. If during the boot process an error is encountered preventing further boot up, that error is logged to memory and control is transfered to the download mode built in to the highest successfully loaded bootloader.

Turn phone on -> Load PBL from SoC

PBL does very basic hardware init and loads SBL1 from emmc

SBL1 does more hardware init and loads SBL2 from emmc

SBL2 does other hardware init and eventually loads SBL3 from emmc

SBL3 does final hardware init and loads APSBL (aka OEMSBL: aboot, hboot, etc...)

At any stage above, if a fatal error is encountered, then download mode in the corresponding bootloader is entered. EhostDL (aka Emergency Host Download or Emergency Download) is ONLY available from the PBL and is only used to load the corresponding .hex file which will do just enough basic hardware init to allow the rest of the bootloaders (and the emmc partition table) to be downloaded and flashed to the phone.

This is just a quick overview. For a more in depth look at the entire boot process, please look at the documents linked from E:V:A's msm8960 thread (there's a link to his thread in the OP). In particular, there is a 30-40 page pdf which details the boot process, including memory addresses, and has some nice flow charts which help to visualize what I briefly touched upon.

-SLS-

hi soulshadow thanks for you keen interest in helping others with this.I am still waiting for the solution for my problem.can I expect any solution for unbricking my phone in a few days.(sorry lost hope).
thank you

darkspr1te · Feb 20, 2013

saketh91 said:
hi soulshadow thanks for you keen interest in helping others with this.I am still waiting for the solution for my problem.can I expect any solution for unbricking my phone in a few days.(sorry lost hope).
thank you

I doubt SLS will have chance to come up with a solution in the next few days, if he is half as busy as me he little to no time to spare, devs tend to 'just' have a bit of time and its not planned time either, its not our main source of income and we often have wife's/kids/husbands/parents all also seeking our time. I am lucky if I get a hour every two days to do development, and often a bit of that time is taken up by getting into the mind set.
What I am saying is don't be too disappointed if you hear nothing, progress often goes in jumps.

sent from the Darkspr1te's lair

SouL Shadow · Feb 20, 2013

saketh91 said:
hi soulshadow thanks for you keen interest in helping others with this.I am still waiting for the solution for my problem.can I expect any solution for unbricking my phone in a few days.(sorry lost hope).
thank you

No. Your phone requires an HTC signed hex file to enable repair of your partition table. Without the signed file we have no way of fixing your phone (and many other ppl's phones).

-SLS-

RussianBear · Feb 20, 2013

saketh91 said:
hi soulshadow thanks for you keen interest in helping others with this.I am still waiting for the solution for my problem.can I expect any solution for unbricking my phone in a few days.(sorry lost hope).
thank you

Find somebody with a jtag.

afkfurby · Feb 22, 2013

found this on the internet, it's an older revision but might be helpful.

starteam · Apr 30, 2013

my phone is LG Optimus G Pro and korean F240L;it is bricked ,when connected PC,apear "QHSUSB_Dload",after installed its driver,become “QualcommHS-USB QDLoader 9008 (COMx)”
I want use QPST emmcswdownload fix it,but how can I get the HEX file of APQ8064T(SnapDragon 600), MPRG8064?.hex .
Who can Tell me ?

E:V:A · Aug 16, 2013

SouL Shadow said:
To provide a partial Open Source (Linux) replacement for QPST and QXDM

Are we getting any closer to this? (Or are there already some other free software out there we can use? [Unfortunately I've been out of the loop for a while, so I'm not well updated on what people are doing...] I'd love to see an open source QXDM prototype...

darkspr1te · Aug 19, 2013

E:V:A said:
[/LIST]
Are we getting any closer to this? (Or are there already some other free software out there we can use? [Unfortunately I've been out of the loop for a while, so I'm not well updated on what people are doing...] I'd love to see an open source QXDM prototype...

I am not currently working on anything due to not having a Qualcomm device at the moment.
But I am will to assist anyone who does continue the work.

Sent from my A210 using Tapatalk HD

rafael_mfr · Aug 22, 2013

I've 3 Padfone 2 devices. Two of them are with qhsusb_dload state and don't turn on. But there is one in properly conditions, how can I fix the others? Can I use QPST EMMCSOFTWAREDOWNLOAD to repair them? I tried already without successfull. Thanks!

Sent from my PadFone 2 using Tapatalk 2

SouL Shadow · Aug 22, 2013

E:V:A said:
[/LIST]
Are we getting any closer to this? (Or are there already some other free software out there we can use? [Unfortunately I've been out of the loop for a while, so I'm not well updated on what people are doing...] I'd love to see an open source QXDM prototype...

I've been busy with other real life events. I also under estimated both the massive scope of such a project and the limited interest others have shown in it. The original goal was to create an app that could be used instead of QPST to help recover bricked phones. To do that in a forward thinking way, I wanted to implement the core protocols that underlie both QPST and QXDM. With the changes to Qualcomm's security (ex: sec boot 3), such a program seems less useful, until it supports a lot of QXDM-like features, which would take a while to implement (tens of thousands). Despite being out of work since May, I've actually had less free time as I have been taking many classes to update and expand my computer skills.

I've been so busy that I've only flashed 2 different ROMs in the past 6 months!

For anyone interested, the Gobi3000 source contains most of the needed backend written in C++. The trick is to further separate the Gobi features from the protocol implementations, fill in the blanks and begin adding higher level services using these protocols. That is what I was planning to do. It's faster and easier than starting from scratch, but you'll need a good understanding of C++ namespaces, classes and templates.

Anyway, I'll continue to watch this thread and others for ~~miracles~~ news. Anyone who wants to actively work on this is free to use this thread. Being an R&D thread, active and on-topic discussion is always encouraged! I get email notifications of thread and private messages so I can update the OP or answer a question if needed. Anyone asking for unbricking help or qualcomm docs will be ignored.

insink71 · Nov 19, 2013

interested

darkspr1te said:
I am not currently working on anything due to not having a Qualcomm device at the moment.
But I am will to assist anyone who does continue the work.

Sent from my A210 using Tapatalk HD

I would be interested in such and have a few qualcomm devices. Also, I have my stand-by riff box

Good news I suppose is I could disassemble resurrect dll's [riffbox also uses windows] to see what critical portions of radio are rewritten to debrick [for target devices]. Translating it to python might be a learning experience. Might could help w/ providing a hosting mirror as well ref: https://teamblueridge.org/projects/files

Rob

PS more interested in per device unbricking [like you did] [perhaps adding other service options like sim unlock, supercid but probably not off-s] since I have a comparative tool; developing open source qpst beyond my skill set.

Heathcliff74 · Nov 28, 2013

Qualcomm msm8960 on Windows Phone 8 devices

Hi,

I'm from the Windows Phone camp. In the past I've been working on a lot of Windows Phone 7 devices. Currently I'm working on 2 Windows Phone 8 devices: Samsung Ativ S (I8750) and Nokia Lumia 920 (RM-821). The Samsung device is an R&D device which has non-blown fuses, which means that QPST and other goodies are available on this device. The Nokia device is a retail device, which is fully secured. Both have the Qualcomm msm8960 chipset.

I'm quite new to hardware-hacking. I've been reading in this forum and other docs to catch up a little. But I'm still in the dark on some things. This thread seems to be the most appropriate one to ask my question.

For my current research I'm interested in one thing specifically: I want to read the OEM_PK_HASH from the QFuse of the devices. The Nokia has its fuses blown, so that won't be possible. But I'd like to be able to read the QFuse data from the Samsung.

I know how to put the Samsung in Qualcomm COM mode and Qualcomm DLOAD mode. In both cases I can connect QPST. In COM mode I can use the normal Software Downloader (to make a backup of NV) and other tools. In DLOAD mode, I can run the eMMC Software Download app. In the eMMC Software Download app, a QFuse button is available. There I can add addresses and then press the Read button. I'm not able to get this working correctly. First of all, I do know the address where OEM_PK_KEY should be, but I don't know the values for LSB and MSB. When I try to read an address, I always get this error:

Code:

Fuse blowing - QfpromRead - response command field (0x3) not equal to 0x35
Fuse read completed

I read that it might be necessary to send a Flash Programmer image to the chip first. It will be loaded in RAM and then communicate with the client on the PC. So I tried that. I selected MPRG8960.hex, but when I try to send it to the chip, the eMMC Software Download app just becomes unresponsive.

When I forcibly restart the eMMC Software Download app, nothing is changed; same error when I try to read the QFuse data.

My questions are:
- Why do I get the error message and how do I get around that?
- Which LSB and MSB values do I need to have, to be able to read the OEM_PK_HASH?

Any other information that could help me in the good direction is welcome.

Thanks a lot all, for posting all this info on XDA.

Ciao,
Heathcliff74

darkspr1te · Nov 28, 2013

Have a look at cdmatools and rev, I cover the usage of them plus other Qualcomm tools in my debrick of shv-e160, Qpst also has companion progs like qdart and qdm

Sent from my a210 using Tapatalk

stepw · Dec 4, 2013

Heathcliff74 said:
- Why do I get the error message and how do I get around that?
- Which LSB and MSB values do I need to have, to be able to read the OEM_PK_HASH?

Any other information that could help me in the good direction is welcome.

Thanks a lot all, for posting all this info on XDA.

Ciao,
Heathcliff74

According to DMSS Download Protocol specs (attached to this thread) Command (0x03) = NAK response packet. This must be the response you receive when command 0x35 is sent to the phone to read QFPROM. The phone doesn't seem to support this command, or command parameters were not accepted.

Perhaps if you sniff the entire packet with a USB sniffer, you can get extended NAK reason and if it's listed in Table 3-5 NAK reason codes in the same document, that should give you an idea why phone rejects command 0x35.

LSB/MSB values are likely OEM specific. Some OEMs include backdoors in their ROMs or bootloaders that can be used to read QFPROM and map QFuses to MSB/LSB.

PS Have you reviewed http://xdaforums.com/showthread.php?t=1856327? Plenty of useful info over there, MSM8960 in general and QFuses in particular, specifically for LG handsets...

[R&D][QUALCOMM] Using QDL, EHostDL and DIAG interfaces & features

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Recognized Contributor

Member

Attachments

Member

Inactive Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Inactive Recognized Developer

Senior Member

Senior Member

Similar threads

Top Liked Posts