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

Deleted member 3665957 · Jan 27, 2013

any current qualcomm chipset with blown secure fuses require valid signature in order to execute loader from flash ( emmc,nor,nand ) or from peripheral boot ( emergency loader )

every phone producer ( sony, htc, nokia, zte, etc ) have own OEM ID number, which is blown on hardware level, so every phone model can have specific loader ( but usually manufacturers using same OEM ID for all phones on same chipset )

some manufacturer for unknown reasons use unsecure chipsets ( which accept unsigned loaders ) - perfect example nokia lumia series until 9xx

newbit · Jan 28, 2013

Hoi together,

as darkspr1te recommend me, i am placing my questions/issues here.

My cell phone is Samsung I547C Rugby Pro with MSM8960 in QDL Mode.
Its softbricked because i crossflashed it with some files from ATT Version.
sbl2.mbn,sbl3.mbn,aboot.mbn,rpm.mbn and tz.mbn. NOT the SBL1.mbn

I have a driver for Win7 x86/x64 and its "run" in QPST Download Mode or rather
in linux ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode).

I tried the perl scripts which are posted here. With the initial version its doing as its writing something
to my flash but it doesnt. Nothing changed. With the current qdload.pl the output is:

Code:

perl qdload.pl --pfile hex.bin --lfile hex2.bin

Requesting SoftwareVersion...
Version: PBL_DloadVER2.0
Requesting Params...
Params: 08 01 06 00 90 00 00
Uploading file 'hex.bin' to QDLOAD...
Writing 1024 bytes to 0x2a000000; 69384 bytes left.
...
Writing 776 bytes to 0x2a011000; 0 bytes left.
Executing file...
Failed to get response.
Sending MAGIC...
Response: 03 00 03
Invalid MAGIC response.

Whats the meaning of:

Params: 08 01 06 00 90 00 00
Executing file...
Failed to get response.
Sending MAGIC...
Response: 03 00 03
Invalid MAGIC response.

and with the initial version it shows at the end

Code:

Writing 1024 bytes to 0x04d8cc00; 2880 bytes left.
Got response: 08 08 01 06 00 90 00 00
Writing 1024 bytes to 0x04d8d000; 1856 bytes left.
Got response: 08 08 01 06 00 90 00 00
Writing 1024 bytes to 0x04d8d400; 832 bytes left.
Got response: 08 08 01 06 00 90 00 00
Writing 832 bytes to 0x04d8d800; 0 bytes left.
Got response: 08 08 01 06 00 90 00 00
Got response: 08 08 01 06 00 90 00 00
Sending CloseFlush...
closeFlush send ok
Response: 03 00 06
Requesting Reset...
doReset send ok
Response: 03 00 06

What means all the time the response:
Got response: 08 08 01 06 00 90 00 00

All the time it says Got response: 08 08 01 06 00 90 00 00
But the Params: 08 01 06 00 90 00 00 are almost the same!!
Which means for me, there is not really a communication to the chip!?

Any ideas or suggestions?

SouL Shadow said:
Full Documentation:

DMSS Download Protocol: DCN 80-39912-1 Revision E
Describes in detail the commands used with QHSUSB_DLOAD (both SBL and PBL)

Streaming Download Protocol: DCN 80-V5348-1 Revision J
Describes in detail the commands used with the Flash Programmer (MPRGxxxx.hex)

CDMA DMSS Serial Data: DCN 80-V1294-1 Revision YP
Describes in detail the basic commands used with the modem Diagnostic mode. This protocol supports a MASSIVE amount of extentions covered in numerous other specialized documents. There is no current plan to implement these extensions.

I cant download this documents. And i cant find them in the internet. Except the DMSS Download Protocol. I found it on a chinese board.
Could you please share it?

BTW: Who is the programmer of the qdload.pl? -> Nice Work and BIG THX for this!!

Kind Regards

NewBit

SouL Shadow · Jan 28, 2013

Status update

newbit said:
Hoi together,

as darkspr1te recommend me, i am placing my questions/issues here.

My cell phone is Samsung I547C Rugby Pro with MSM8960 in QDL Mode.
Its softbricked because i crossflashed it with some files from ATT Version.
sbl2.mbn,sbl3.mbn,aboot.mbn,rpm.mbn and tz.mbn. NOT the SBL1.mbn

I have a driver for Win7 x86/x64 and its "run" in QPST Download Mode or rather
in linux ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode).

I tried the perl scripts which are posted here. With the initial version its doing as its writing something
to my flash but it doesnt. Nothing changed. With the current qdload.pl the output is:

Code:

perl qdload.pl --pfile hex.bin --lfile hex2.bin Requesting SoftwareVersion... Version: PBL_DloadVER2.0 Requesting Params... Params: 08 01 06 00 90 00 00 Uploading file 'hex.bin' to QDLOAD... Writing 1024 bytes to 0x2a000000; 69384 bytes left. ... Writing 776 bytes to 0x2a011000; 0 bytes left. Executing file... Failed to get response. Sending MAGIC... Response: 03 00 03 Invalid MAGIC response.

Whats the meaning of:

Params: 08 01 06 00 90 00 00

Executing file...
Failed to get response.

Sending MAGIC...
Response: 03 00 03
Invalid MAGIC response.

and with the initial version it shows at the end

Code:

Writing 1024 bytes to 0x04d8cc00; 2880 bytes left. Got response: 08 08 01 06 00 90 00 00 Writing 1024 bytes to 0x04d8d000; 1856 bytes left. Got response: 08 08 01 06 00 90 00 00 Writing 1024 bytes to 0x04d8d400; 832 bytes left. Got response: 08 08 01 06 00 90 00 00 Writing 832 bytes to 0x04d8d800; 0 bytes left. Got response: 08 08 01 06 00 90 00 00 Got response: 08 08 01 06 00 90 00 00 Sending CloseFlush... closeFlush send ok Response: 03 00 06 Requesting Reset... doReset send ok Response: 03 00 06

What means all the time the response:
Got response: 08 08 01 06 00 90 00 00

All the time it says Got response: 08 08 01 06 00 90 00 00
But the Params: 08 01 06 00 90 00 00 are almost the same!!
Which means for me, there is not really a communication to the chip!?

Any ideas or suggestions?

I cant download this documents. And i cant find them in the internet. Except the DMSS Download Protocol. I found it on a chinese board.
Could you please share it?

BTW: Who is the programmer of the qdload.pl? -> Nice Work and BIG THX for this!!

Kind Regards

NewBit

Thanks for your post. While we are not able to help fix your phone at this time, the information in your post provides a good reference for further discussion. Those PARAMS/RESPONSE messages in the output are the DMSS Download Protocol commands. All info is in hexidecimal:

Code:

0x08 - Parameter Response command
0x08 - Protocol Version
0x01 - Minimum protocol version supported by the phone
0x0600 - Maximum write size
0x90 - Phone hardware model number
0x00 - Flash size code (ignore, code not supported)
0x00 - Flash type code (ignore, code not supported)

Code:

0x03 - NAK Response command
0x0006 - Reason code: "Unknown/Invalid command"

First, I'd just like to remind everyone that this is a Research and Development thread, NOT a help thread.
Second, after a discussion on IRC with Ralekdev, I reexamined the script's output from another person. It's nearly identical to what you posted. Unfortunately I had originally misread the output. The mprg8960.hex is NOT being executed. Instead the phone reboots back in to QDL mode in the PBL.
Third, that script (qdload.pl) needs more work, bug fixes, and additional error checking. I have had no involvement writing that script (my perl skills need a complete refresher). I am working on a C++ program that will support all features of the DMSS Download protocol, Streaming Download protocol and (at first) partital support for the DM diagnostic protocol. This program is still in the early stages of development and as soon as i get the basic structure nailed down i will add it to my github.

newbit · Jan 29, 2013

SouL Shadow said:
Thanks for your post. While we are not able to help fix your phone at this time, the information in your post provides a good reference for further discussion.

Thank you too, i appreciate your help and informations from the past, and also in the future!! :fingers-crossed:

SouL Shadow said:
Those PARAMS/RESPONSE messages in the output are the DMSS Download Protocol commands. All info is in hexidecimal:

Code:

0x08 - Parameter Response command 0x08 - Protocol Version 0x01 - Minimum protocol version supported by the phone 0x0600 - Maximum write size 0x90 - Phone hardware model number 0x00 - Flash size code (ignore, code not supported) 0x00 - Flash type code (ignore, code not supported)

Code:

0x03 - NAK Response command 0x0006 - Reason code: "Unknown/Invalid command"

Yes right, thats the same what the DMSS spec. said.

SouL Shadow said:
First, I'd just like to remind everyone that this is a Research and Development thread, NOT a help thread.

If that is true, you also shall provide your primary reference first! Otherwhise people like me cant do the Research and Development!!
The DMSS issnt that bad, but I cant go further without the Streaming Download Protocol.

SouL Shadow said:
Second, after a discussion on IRC with Ralekdev, I reexamined the script's output from another person. It's nearly identical to what you posted. Unfortunately I had originally misread the output. The mprg8960.hex is NOT being executed. Instead the phone reboots back in to QDL mode in the PBL.

Yes i think so too, because the DMSS spec. said also, that after the GO Command the phone shall send ACK!! (0x02)
But the qdload.pl script says Failed to get response.

The DMSS spec. descripes the GO Command, to send the "execute" address in form with Segment : Offset with each in 2 bytes.
But in qdload.pl script, it just send the 32bit address direct behind after the go command.
sub execute

Code:

line 330: sendPacket($fd, deserialize( "05 " . serial32($address)))

Is the address 0x2A000000 the same like 2A00:0000 ?

Whats the reason to send as "MAGIC" the text "QCOM fast download protocol host" to the phone? What does this
mean?

In qdload.pl script, in sub writeChunk2 is this code:

Code:

line 112:  "07 " . serial32le($address) . " " . serialize($chunk)

In the DMSS spec. is written, that the 07 is the parameter request. AND thats the reason why the phone always said
Got response: 08 08 01 06 00 90 00 00 !!

If I correct it to a write command, the phone says, 0x0002 -> invalid destination adress!

I can only guess, that the real reason is that the mprg8960.hex or rather the mprg8x60.hex is NOT being executed.

I also guess that is maybe a write command if it s executed!? I still need this documents!!

Is it possible that you also give it to me via PM? Or just the sources from the internet?

SouL Shadow said:
Third, that script (qdload.pl) needs more work, bug fixes, and additional error checking. I have had no involvement writing that script (my perl skills need a complete refresher). I am working on a C++ program that will support all features of the DMSS Download protocol, Streaming Download protocol and (at first) partital support for the DM diagnostic protocol. This program is still in the early stages of development and as soon as i get the basic structure nailed down i will add it to my github.

Oh thanks that you said it before I did, this script is very buggy, like we say, Quick & Dirty :silly: :highfive:

SouL Shadow said:
Finally, I spent a large portion of my free time from the past few days writing, testing and bug fixing a bash script to remove watermarks from Qualcomm docs so that i can share them with everyone. The script is now stable and will be added to my github shortly. I'm currently checking each pdf cleaned with this script before uploading to my website. I hope to have all of them uploaded before the end of the day.

Sounds great, but i dont realy understand what it means: remove watermarks from Qualcomm docs

Please dont missunderstand me, I dont realy ask yours for helping me to repair my stuff or do my work.
I wanna give something back to XDA and all of its fellows.
If everything runs fine, my posts count is equal to zero!! I prefer to work in background.

Yours respectfully

NewBit

SouL Shadow · Jan 29, 2013

newbit said:
Thank you too, i appreciate your help and informations from the past, and also in the future!! :fingers-crossed:

Yes right, thats the same what the DMSS spec. said.

If that is true, you also shall provide your primary reference first! Otherwhise people like me cant do the Research and Development!!
The DMSS issnt that bad, but I cant go further without the Streaming Download Protocol.

The references are listed in either the OP or the 2nd post. The DMSS Download Protocol covers all the commands available in QDL mode. The Streaming Download Protocol is ONLY applicable after control is transferred to the flash programmer.

newbit said:
Yes i think so too, because the DMSS spec. said also, that after the GO Command the phone shall send ACK!! (0x02)
But the qdload.pl script says Failed to get response.

The DMSS spec. descripes the GO Command, to send the "execute" address in form with Segment : Offset with each in 2 bytes.
But in qdload.pl script, it just send the 32bit address direct behind after the go command.
sub execute

Code:

line 330: sendPacket($fd, deserialize( "05 " . serial32($address)))

Is the address 0x2A000000 the same like 2A00:0000 ?

Whats the reason to send as "MAGIC" the text "QCOM fast download protocol host" to the phone? What does this
mean?

The answer to that is provided in the DMSS document. It is the handshake message used to establish a "connection" with the phone. After the host sends that "magic", if the phone is in QDL mode it replies with a similar "magic" reply.

newbit said:
In qdload.pl script, in sub writeChunk2 is this code:

Code:

line 112: "07 " . serial32le($address) . " " . serialize($chunk)

In the DMSS spec. is written, that the 07 is the parameter request. AND thats the reason why the phone always said
Got response: 08 08 01 06 00 90 00 00 !!

If I correct it to a write command, the phone says, 0x0002 -> invalid destination adress!

I can only guess, that the real reason is that the mprg8960.hex or rather the mprg8x60.hex is NOT being executed.
I also guess that is maybe a write command if it s executed!? I still need this documents!!

Is it possible that you also give it to me via PM? Or just the sources from the internet?

Oh thanks that you said it before I did, this script is very buggy, like we say, Quick & Dirty :silly: :highfive:

Sounds great, but i dont realy understand what it means: remove watermarks from Qualcomm docs

The reminder was not directed at you. Rather anyone visiting here that is exclusively looking for help and not attempting to further the community understanding. The protocols discussed here and the program I'm working on are not focused on one particular device. To successfully use these tools to revive an actual device will require additional specific files that are beyond the scope of this thread. I recognized your desire to learn and help, which is why I went on to explain/answer questions from your post. I want this thread to be an active discussion so everyone, including myself, can continue to learn more about these Qualcomm technologies.

newbit said:
Please dont missunderstand me, I dont realy ask yours for helping me to repair my stuff or do my work.
I wanna give something back to XDA and all of its fellows.
If everything runs fine, my posts count is equal to zero!! I prefer to work in background.

Yours respectfully

NewBit

SouL Shadow · Jan 29, 2013

Added some goodies to posts 1 and 2.
Enjoy

newbit · Jan 30, 2013

SouL Shadow said:
Added some goodies to posts 1 and 2.
Enjoy

VERY NICE!! 1000 times THX

There is also a lot of other usefull docs on your page. WOW man, really nice collection.

I ve read them all, no i didnt, but almost.

SouL Shadow said:
To protect my source I couldn't repost these documents, until i removed their personal information.

You were right! It was the right decision. -> My apologize for that!!

Ok i try to do this short.
I sniffed in RAW what QPST (2.7.378) eMMC Software Download is doing. - just for confirmation.
One of the "many" programmers hex files i found in the internet and my manual created 8960_msimage.mbn plus
the right path is filled in correct. Connection is established. Phone is in Download Mode.

How to sniff?
USBLyzer is very usefull and for some days free for use.
I would prefer Advanced Serial Port Monitor by AGG Soft but it is limited to 1024 bytes

OUT = HOST
IN = PHONE

It stays in permanent handshake with the device. Let us call this pair "idle cycle" between HOST and PHONE

OUT: 7E 06 4E 95 7E (NO-OP)
IN: 7E 02 6A D3 7E (ACK)

Pushing Download Button:

OUT: 7E 0C 14 3A 7E (Parameter Request)
IN: 7E 0D 0F 50 42 4C 5F 44 6C 6F 61 64 56 45 52 32 2E 30 53 AE 7E (Parameters)

As you descriped some posts above...

Now it starts the actual download process of the programmers hex file:
(Write data to memory using 32-bit address) (32 Bit address 0x2A000000) (Data length 0x03F9 -> 1017 bytes)

7E 0F 2A 00 00 00 03 F9 D1 DC 4B 84 34 10 D7 73 0D 00 00 00 FF FF FF FF FF FF FF
FF 50 00 00 00 50 00 00 2A 04 D1 00 00 04 D1 00 00 54 D1 00 2A 00 00 00 00 54 D1
00 2A 00 00 00 00 01 00 00 00 01 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF BA 2D 00 EA 98 B5 00 2A 98 B5 00 2A 98 B5 00 2A 98 B5 00 2A
98 B5 00 2A 98 B5 00 2A 98 B5 00 2A 98 B5 00 2A 78 47 C0 46 64 00 51 E3 A1 2B 00
0A 00 00 B0 E3 1E FF 2F E1 30 B4 8E 4A 08 29 0F D3 8D 4C 05 78 13 0A 12 02 6B 40
5B 00 E3 5A 53 40 1A 04 12 0C 08 39 09 04 09 0C 40 1C 08 29 F0 D2 00 29 17 D0 00
78 03 02 49 1E 08 04 83 49 00 0C 14 00 5C 40 24 04 03 D5 52 04 12 0C 4A 40 01 E0
52 04 12 0C 5B 04 1B 0C 04 00 40 1E 00 04 00 0C 00 2C ED D1 D0 43 30 BC 00 04 00
0C 70 47 10 B4 74 4A 08 29 0D D3 76 4B 04 78 54 40 24 06 E4 0D 1C 5B 12 0A 62 40
08 39 09 04 09 0C 40 1C 08 29 F2 D2 00 29 14 D0 00 78 03 02 49 1E 08 04 6D 49 00
0C 14 00 5C 40 E4 07 02 D0 52 08 4A 40 00 E0 52 08 5B 08 04 00 40 1E 00 04 00 0C
00 2C F0 D1 D0 43 10 BC 00 04 00 0C 70 47 30 B4 62 4A 08 29 0E D3 62 4B 05 78 94
0D 6C 40 24 06 A4 0D 1C 59 12 02 62 40 08 39 09 04 09 0C 40 1C 08 29 F1 D2 00 29
14 D0 00 78 83 05 49 1E 08 04 58 49 00 0C 14 00 5C 40 A4 00 02 D5 52 00 4A 40 00
E0 52 00 5B 00 04 00 40 1E 00 04 00 0C 00 2C F0 D1 D0 43 30 BC 80 00 80 08 70 47
30 B4 4B 4B 83 43 08 2A 0E D3 4A 48 0D 78 9C 0D 6C 40 24 06 A4 0D 04 59 1B 02 63
40 08 3A 12 04 12 0C 49 1C 08 2A F1 D2 00 2A 14 D0 08 78 81 05 52 1E 10 04 40 4A
00 0C 1C 00 4C 40 A4 00 02 D5 5B 00 53 40 00 E0 5B 00 49 00 04 00 40 1E 00 04 00
0C 00 2C F0 D1 D8 43 30 BC 80 00 80 08 70 47 30 B4 C0 43 00 04 00 0C 00 2A 0F D0
2C 4C 0D 78 03 0A 00 02 6B 40 5B 00 E3 5A 43 40 18 04 00 0C 52 1E 12 04 12 0C 49
1C 00 2A F0 D1 C0 43 30 BC 00 04 00 0C 70 47 10 B4 C0 43 00 04 00 0C 00 2A 0B D0
21 4B 0C 78 44 40 24 06 E4 0D 1C 5B 00 0A 60 40 52 1E 49 1C 00 2A F4 D1 C0 43 10
BC 00 04 00 0C 70 47 03 00 30 B4 10 00 08 29 0D D3 1B 4A 1D 78 04 0E 6C 40 A4 00
14 59 00 02 60 40 08 39 09 04 09 0C 5B 1C 08 29 F2 D2 00 29 13 D0 1A 78 12 06 49
1E 12 4B 09 04 09 0C 04 00 54 40 02 D5 40 00 58 40 00 E0 40 00 52 00 0C 00 49 1E
09 04 09 0C 00 2C F1 D1 30 BC 70 47 00 00 FF FF 00 00 74 BF 00 2A 21 10 00 00 74
C1 00 2A 08 84 00 00 FF FF FF 3F 74 BB 00 2A C7 B9 30 60 74 C3 00 2A B7 1D C1 04
00 21 01 60 41 60 70 47 10 B5 25 4C 20 68 0B F0 8D FA 01 28 0D D1 60 68 0B F0 88
FA 00 28 06 D1 00 F0 E6 F8 60 68 0B F0 81 FA 00 28 F8 D0 1D 48 04 61 10 BC 08 BC
18 47 FF F7 E6 FF 00 F0 53 F9 19 48 18 4C 20 60 60 60 A0 60 E0 60 17 48 FF F7 D7
FF 17 48 61 68 0B F0 6A FA 16 48 A1 68 0B F0 66 FA 15 48 E1 68 0B F0 62 FA 01 F0
8B F9 13 4C 20 00 00 F0 C4 F8 FB E7 00 20 70 47 00 20 70 47 10 B5 64 21 48 43 00
F0 BA F8 10 BC 08 BC 18 47 70 47 00 20 0A 49 40 1C 88 42 FC DB 70 47 00 00 F0 CD
00 2A BC CD 00 2A ED 02 00 2A 64 11 01 2A 6C 11 01 2A 74 11 01 2A 7C 11 01 2A 10
27 00 00 E8 03 00 00 10 B5 31 48 00 68 02 F0 0D FC 10 BC 08 BC 18 47 10 B5 01 F0
D4 FF 10 BC 08 BC 18 47 10 B5 02 F0 19 F8 00 28 07 D0 28 4C 20 68 02 F0 FB FB 02
F0 11 F8 00 28 F8 D1 10 BC 08 BC 18 47 01 20 70 47 10 B5 04 00 60 68 02 28 06 5A
AE 7E
IN: 7E 02 6A D3 7E (ACK)

Do this a few times...
...and the last bytes

OUT: 7E 0F 2A 01 1A 0F 00 6D 00 00 00 00 00 38 10 01
2A 09 04 03 00 90 3F 00 2A CC 3F 00 2A 44 3E 00
2A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 01 02 03 00 00 00 00 00 00 00 00 14 00 00
00 0A 00 00 00 00 00 00 00 00 00 50 12 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00
00 00 00 00 00 00 00 00 00 00 02 00 02 00 00 00
00 00 00 00 00 A4 86 7E
IN: 7E 02 6A D3 7E (ACK)

Here it comes the GO Command!
BTW: It is similar to the qdload.pl script

OUT: 7E 05 2A 00 00 00 DE BA 7E
IN: -- nothing -- phone is rebooting and windows is playing unplug/plug sounds

Phone is back in Download Mode

(After feeled 20sec it popups the cookie error window)

In the meanwhile...
The host sends a Parameter Request again:

OUT: 7E 0C 14 3A 7E (Parameter Request)
IN: 7E 0D 0F 50 42 4C 5F 44 6C 6F 61 64 56 45 52 32 2E 30 53 AE 7E (Parameters)

perform one idle cycle

OUT: 7E 06 4E 95 7E (NO-OP)
IN: 7E 02 6A D3 7E (ACK)

And now the ACTION i dont understand!?!

OUT: 7E 19 38 7D 5D 7E
IN: 7E 03 00 06 9E 4C 7E (NAK) (Unknown/invalid command)

1. Case its expecting the hex is executed or test it:
QPST it trying to send the partition table.
According to 80-V5348-1_J_Streaming_DLoad_Protocol.pdf page 13 and 29

19 Partition table Host Y 3.00 Send partition table to use for programming images

2. Case it wants the Cookie: who not?! :silly:
QPST it's trying to send a cookie request
According to 80-39912-1_E_DMSS_Download_Protocol.pdf page 14 and 32

19 QPST™ Cookie Read Request Host Y 9 Request to read QPST Cookie

In both cases there is no explanation for the 38. Any idea?

More things to discuss:

I thought all the time, that the devices MSM8660 and MSM8960 are in princip the same. BUT
i looks like now, that they have fundamental differences. And we cant use the MSM8660.HEX
for flash our MSM8960. Can you confirm this?

In the 80-N5009-1_B_MSM8960_Boot_Architecture_Overview.pdf there are a lot of comparisms between this
both. For example the MSM8960 charges the battery if it is dead.

Another hint for me is, that the HEX files we have, are not executable. That means we still need the MPRG8960.HEX
as it's descriped in the 80-VN930-4_C_AMSS_8960_LA_Programming_Guide_Test_Mobile.pdf
If the HEX file is executed, i would expect it will popup a "new" device to write my image on it!?

Maybe another chance that we can test?! It's just an idea.
Back to Boot_Architecture_Overview page 10.

There is a table with some execution addresses. Maybe we can download some files in binary and than
execute them with GO Command to run into another download mode. Like in odin download mode?!

What do you think about it?

BTW: On the RIFF JTAG BOX page is still no support for the MSM8960 reported !!

Regards

NewBit

SouL Shadow · Jan 30, 2013

newbit said:
You were right! It was the right decision. -> My apologize for that!!

Ok i try to do this short.
I sniffed in RAW what QPST (2.7.378) eMMC Software Download is doing. - just for confirmation.
One of the "many" programmers hex files i found in the internet and my manual created 8960_msimage.mbn plus
the right path is filled in correct. Connection is established. Phone is in Download Mode.

How to sniff?
USBLyzer is very usefull and for some days free for use.
I would prefer Advanced Serial Port Monitor by AGG Soft but it is limited to 1024 bytes

OUT = HOST
IN = PHONE

It stays in permanent handshake with the device. Let us call this pair "idle cycle" between HOST and PHONE

Pushing Download Button:

As you descriped some posts above...

Now it starts the actual download process of the programmers hex file:
(Write data to memory using 32-bit address) (32 Bit address 0x2A000000) (Data length 0x03F9 -> 1017 bytes)

Do this a few times...
...and the last bytes

Here it comes the GO Command!
BTW: It is similar to the qdload.pl script

Yes, that script (badly) emulates the same steps that QPST goes through.

newbit said:
Phone is back in Download Mode

(After feeled 20sec it popups the cookie error window)

In the meanwhile...
The host sends a Parameter Request again:

perform one idle cycle

And now the ACTION i dont understand!?!

1. Case its expecting the hex is executed or test it:
QPST it trying to send the partition table.
According to 80-V5348-1_J_Streaming_DLoad_Protocol.pdf page 13 and 29

2. Case it wants the Cookie: who not?! :silly:
QPST it's trying to send a cookie request
According to 80-39912-1_E_DMSS_Download_Protocol.pdf page 14 and 32

In both cases there is no explanation for the 38. Any idea?

More things to discuss:

I thought all the time, that the devices MSM8660 and MSM8960 are in princip the same. BUT
i looks like now, that they have fundamental differences. And we cant use the MSM8660.HEX
for flash our MSM8960. Can you confirm this?

Yes, the MSM8660 and MSM8960 are in the same family, but the 8960 is the newer generation. The HEX files only work on their corresponding processor.

newbit said:
In the 80-N5009-1_B_MSM8960_Boot_Architecture_Overview.pdf there are a lot of comparisms between this
both. For example the MSM8960 charges the battery if it is dead.

Another hint for me is, that the HEX files we have, are not executable. That means we still need the MPRG8960.HEX
as it's descriped in the 80-VN930-4_C_AMSS_8960_LA_Programming_Guide_Test_Mobile.pdf
If the HEX file is executed, i would expect it will popup a "new" device to write my image on it!?

Just a quick note but the "LA" refers to "Linux Android". You'll see this abbreviation used in other docs.

newbit said:
Maybe another chance that we can test?! It's just an idea.
Back to Boot_Architecture_Overview page 10.

There is a table with some execution addresses. Maybe we can download some files in binary and than
execute them with GO Command to run into another download mode. Like in odin download mode?!

What do you think about it?

BTW: On the RIFF JTAG BOX page is still no support for the MSM8960 reported !!

Regards

NewBit

Ralekdev showed me a message from a US SGS3 (it's an msm8960 device). It does check OEM signatures on the HEX file (if qfuse is blown enabling security). It also does a number of other checks on the HEX before transferring execution. So, in short, only a signed program with a valid structure will be executed. The actual memory address (0x2A000000) can be changed slightly, as long as it falls in the proper stack space. But that really makes no difference and there's no reason to change that address.
.
.
.
On a side note, I'm not very familiar with cryptography (I understand the basics), but perhaps it's possible to extract the OEM hash from the qfuse and use it to sign the HEX? Or maybe given all the released files that are OEM signed, perhaps it'd be possible to crack the private key needed? I know it's probably a long shot, but I figured I should throw it out for discussion. Anyone have any thoughts?

newbit · Jan 30, 2013

SouL Shadow said:
Ralekdev showed me a decompiled PBL from a US SGS3 (it's an msm8960 device).

How has he get it? I have a complete backup of my phone. But let me guess. Its not in there!?
Which ways exist to dump the PBL?

SouL Shadow said:
only a signed program with a valid structure will be executed

I have the original signed sbl1, sbl2 and sbl3 from my backup. I thought to upload one of these and execute them.
Or set the pointer to the one which are in still in the phones memory.

But i cant still confirm the "theory" of the check signature. Because the phone doesnt give any ACK or NAK after the
execution. How can we proof it?

SouL Shadow said:
On a side note, I'm not very familiar with cryptography (I understand the basics), but perhaps it's possible to extract the OEM hash from the qfuse and use it to sign the HEX? Or maybe given all the released files that are OEM signed, perhaps it'd be possible to crack the private key needed? I know it's probably a long shot, but I figured I should throw it out for discussion. Anyone have any thoughts?

Thats not my business, sry.

darkspr1te · Jan 30, 2013

newbit said:
How has he get it? I have a complete backup of my phone. But let me guess. Its not in there!?
Which ways exist to dump the PBL?

I have the original signed sbl1, sbl2 and sbl3 from my backup. I thought to upload one of these and execute them.
Or set the pointer to the one which are in still in the phones memory.

But i cant still confirm the "theory" of the check signature. Because the phone doesnt give any ACK or NAK after the
execution. How can we proof it?

Thats not my business, sry.

Although I won't have full access to my full set of docs for a little while I can how ever confirm the CPU will reset to PBL if the hex fails the check, the Qualcomm built hex is not signed, its a dev tool and therefore not meant to be used in the wild, I am assuming OEMS will have their own but I bets it's well guarded. This will explain the boot back to dmss protocol for any damage to the boot chain.
the qdload script that's been posted it a basic hack, the latest dev to work on it made most of the extra functions work in less that 8 hours, up until then he knew nothing of the protocol nor codes, I gave him some tuition via irc and he did the rest, he did not have a single Qualcomm doc to work from.
My point is that it's a dev tool to show examples of how the protocol work between the two stages of the main protocol, from there it's up to us to continue the research and add to it, like hiemdall. The testing is most important, keeping on topic too is important.

Back on topic.
What's important is the chain of trust to the PBL, and where is loaded into the system, e:v:a posted a document to cover the memory regions of the msm8960 and its boot process, which part of the CPU executes what.
The hex set's up memory and provides a hack for USB SD card to emmc, the documentation states that this is also in the boot chain of OEM's so in theory uploading the boot chain to it's various memory regions could provide us with a signed boot chain, the issue is when we start loading items in memory regions that require setup (external ram) as the boot chain does not just come back and wait for us to execute the next section or upload another boot loader.
We do have a nice possibility here though. During the GO command the PBL checks signature of the sbl1 if correct it runs the code, sbl1 loads and checks sbl2 if good it runs it, if not it's back to PBL, the data in memory how ever is not erased, we might be able to upload to memory the damaged parts and jump to them or get as far as the ability to trigger the SD card option or streaming download protocol using the factory OEM loaders. That's if the external ram stays intact and the each sbl stage does not over write the stage we need in memory each time it loads,
Possible uses for this is emmcrecover, if we can load absolute base files from the OEM boot loaders into memory, execute and get streaming protocol.

now execution of the above theory would also prove signing is involved I think.
Now also for other devices where this theory has need used, msm based, the execute address for loading a raw .mbn file into memory is not the same, the mbn files have a header which define what they do and execute region for I think as well. but as I cant browse my docs for a while I cant bee hundreds sure yet. Now if we need to skip this header we need to change the exec address from 0x2A000000 to 0x2A000050 as a example, if memory serves me correct each sbX reads that and stores it in a readable table in memory, I think the warm boot makes use of this , unknown if each sbX is reloaded from emmc in this particular warm boot, I know JTAG will allow you to do this, most bin files I've looked at from in encrypted jtag sessions is the memory snap shot up to a known stable point, C64 datel cartridge used the same trick, stop CPU, upload code to memory, jump to known good point.

The dmss protocol allows reading from memory, I suggest read the PBL memory location, a very quick patch to the qdload script would confirm the failure to execute reason . You can also dump the PBL as well , refer to the boot loaders thread for the PDF of memory regions.
Expansion of the read memory would be to dump the memory on each execute, compare the diff's, we will expect some diff's but it should hint at confirming some theories, I known a PBL dump via this method does work, I have the dump of my device and a msm8960 device via revskills, but I have zer0 idea on reversing it.
Please correct if anything above proves false.

Darkspr1te
Edit: thread on boot loaders http://xdaforums.com/showthread.php?t=1856327

Sent from my A210 using Tapatalk 2

SouL Shadow · Jan 30, 2013

newbit said:
How has he get it? I have a complete backup of my phone. But let me guess. Its not in there!?
Which ways exist to dump the PBL?

PBL is stored on chip (ROM). How to pull it from memory is beyond my knowledge.

newbit said:
I have the original signed sbl1, sbl2 and sbl3 from my backup. I thought to upload one of these and execute them.
Or set the pointer to the one which are in still in the phones memory.

I've considered trying to load sbl1. It *might* actually work, however the usefulness of doing that is questionable.
Consider that the address where the HEX is loaded is the same address in to where sbl1 is loaded. Again, it's an idea, but I've no idea it it would work.

newbit said:
But i cant still confirm the "theory" of the check signature. Because the phone doesnt give any ACK or NAK after the
execution. How can we proof it?

Thats not my business, sry.

I originally couldn't confirm the signature checking either. Many people had assumed it, but I couldn't say for sure until I saw proof one way or the other. Now it appears that it is indeed the case. Is this the end of the road for the msm8960? Absolutely not. But it does mean we need to step back and reevaluate our approach.

E:V:A · Jan 30, 2013

newbit said:
How has he get it? I have a complete backup of my phone. But let me guess. Its not in there!?Which ways exist to dump the PBL?
I have the original signed sbl1, sbl2 and sbl3 from my backup. I thought to upload one of these and execute them.Or set the pointer to the one which are in still in the phones memory.But i cant still confirm the "theory" of the check signature. Because the phone doesnt give any ACK or NAK after the
execution. How can we proof it?

Please stop asking questions that have already been answered a year ago and hundreds of times afterwards! Just use the search box on top of the page. Or if you really have no clue, start your own thread.

It's not helpful for the R&D of this (or any other) thread to keep answering questions that make us run around in circles.

newbit · Jan 31, 2013

E:V:A said:
Please stop asking questions that have already been answered a year ago and hundreds of times afterwards! Just use the search box on top of the page. Or if you really have no clue, start your own thread.

It's not helpful for the R&D of this (or any other) thread to keep answering questions that make us run around in circles.

Unfortunately, you're right

In the MSM8960™ Boot Architecture Overview page 24 is it written:

Once PBL error occurs, it goes to error handler

PBL will log the necessary log information into the RPM code RAM
PBL will go to Emergency Download mode if it is not disabled by fuse
PBL will try SDC port3 recovery first
If failed, PBL will go to HS-USB Emergency Download mode
In Emergency Download mode, PBL will enumerate the HS-USB and wait
for the packet from HOST
PBL will retrieve eMMC Flash programmer and authenticate it
Once load and authentication are passed, system will jump to the Flash
programmer start address
Flash programmer will execute and download the necessary boot images
from host side
In HS-USB Emergency Download mode, the serial number/MSM
hardware ID/OEM_PK_HASH read are supported in MSM8960

BTW: That is still no explanation why we dont get any ACK or NAK from the phone after GO!

But what else can we do? Any suggestions?
Whats about the Boot_config [6] for the Fastboot? Maybe its possible
to pull it down via soldering!? Can we identify it on the board?

So in short, we still need the right HEX file!? The signed one...

In AMSS 8960 Linux Android™ Programming Guide for Test Mobile Customers PDF

is very details described how to reflash it with QPST and the programmers HEX File.
AND where we can get it, from the tech server. How high are the chances to get an access?

Maybe over an official development Company? Maybe from that one i am working at?

Whats about the Snapdragon SDK? Is it possible to get this SDK Tool Kit, and in there are
the files we need?

Regards

NewBit

darkspr1te · Jan 31, 2013

newbit said:
Unfortunately, you're right

In the MSM8960™ Boot Architecture Overview page 24 is it written:

Once PBL error occurs, it goes to error handler

PBL will log the necessary log information into the RPM code RAM

PBL will go to Emergency Download mode if it is not disabled by fuse

PBL will try SDC port3 recovery first
If failed, PBL will go to HS-USB Emergency Download mode

In Emergency Download mode, PBL will enumerate the HS-USB and wait
for the packet from HOST

PBL will retrieve eMMC Flash programmer and authenticate it

Once load and authentication are passed, system will jump to the Flash
programmer start address

Flash programmer will execute and download the necessary boot images
from host side

In HS-USB Emergency Download mode, the serial number/MSM
hardware ID/OEM_PK_HASH read are supported in MSM8960

BTW: That is still no explanation why we dont get any ACK or NAK from the phone after GO!

But what else can we do? Any suggestions?
Whats about the Boot_config [6] for the Fastboot? Maybe its possible
to pull it down via soldering!? Can we identify it on the board?

So in short, we still need the right HEX file!? The signed one...

In AMSS 8960 Linux Android™ Programming Guide for Test Mobile Customers PDF

is very details described how to reflash it with QPST and the programmers HEX File.
AND where we can get it, from the tech server. How high are the chances to get an access?

Maybe over an official development Company? Maybe from that one i am working at?

Whats about the Snapdragon SDK? Is it possible to get this SDK Tool Kit, and in there are
the files we need?

Regards

NewBit

We don't get a ACK from the GO command as the system is rebooted to PBL due to sign failure. Any ACK would come on acceptance of the signing, as the sign fails it reboots to PBL right away thus negating possible overflow attacks by placing new code at the point of executing the code of ACK.

the SDK only has standard android files and no boot loader or sbl source, I've confirmed this with a few snapdragon dev kit owners.
Even if you got the right bootconfig resistor it won't matter, the qfuse will still require a signed hex/flash programmer and also fast boot may not be implemented in the same way, some OEMS change this, Samsung as a example.

Sent from my A210 using Tapatalk 2

SouL Shadow · Feb 1, 2013

I'd like to address a few general points:

On topic conversation
This thread is for the discussion and development of Qualcomm's HDLC based protocols and programs capable of utilizing those protocols.
Off topic conversation
This is NOT the place to discuss the recovery of specific devices. Some device specific discussion IS necessary for development and testing purposes, as long as it relates to the actual topic.
(For example: the above discussion about the msm8960 is GOOD. It was new to this thread and pertained to utilizing the protocols. However, all the points have been addressed. Further discussion about the 8960 should include different or new information. Wiring and hardware mods are outside the scope of this thread.)
Repetitive questions/answers
With so much information scattered around various threads on XDA it's often difficult to find all the relevant information. In that light I have a few simple guidelines for this thread:

- If it has not been posted or answered here AND it pertains to the topic, then by all means share it within this thread.

- If it has already been posted in this thread then please refer people to the previous post.

- Corrections to existing content are always welcome.

- Please cite your source(s) of information.

- Please read the thread before asking a question.
Moderation
I do NOT want to aggressively moderate this thread. I hope that off topic and repetitive conversation can be kept to a minimum. Sometimes the best ideas come from the least likely places and allowing people to speak freely can hopefully lead to better overall understanding and development. If something is off topic but you think it could be beneficial then go ahead and post it.

-----

As this thread continues to grow I will begin linking to the important posts from the OP. If you're looking for something, check there first.

Thank you.

-SLS-

jcsullins · Feb 1, 2013

newbit said:
I tried the perl scripts which are posted here. With the initial version its doing as its writing something
to my flash but it doesnt. Nothing changed. With the current qdload.pl the output is:

Code:

perl qdload.pl --pfile hex.bin --lfile hex2.bin Requesting SoftwareVersion... Version: PBL_DloadVER2.0 Requesting Params... Params: 08 01 06 00 90 00 00 Uploading file 'hex.bin' to QDLOAD... Writing 1024 bytes to 0x2a000000; 69384 bytes left. ... Writing 776 bytes to 0x2a011000; 0 bytes left. Executing file... Failed to get response. Sending MAGIC... Response: 03 00 03 Invalid MAGIC response.

BTW: Who is the programmer of the qdload.pl? -> Nice Work and BIG THX for this!!

NewBit

I am the programmer. You're welcome.

Note that, as was mentioned in post #4 of this thread, I did not write this from scratch.
My primary reason for writing it is for use in tpdebrick (my HP Touchpad debricker) and it has been working really well for that.

In the output above, it should have never tried the "Sending MAGIC" part since it didn't receive a correct response to the "execute" (or go) command. I have added a check for that and it is now available on github.

http://github.com/jcsullins/qdloader

If you can identify any other bugs, please let me know.

- James

Fuses · Feb 5, 2013

SouL Shadow said:
Fuses for his emmc_recover program, which gave me my first glimpse of using HDLC to communicate with a Qualcomm based phone. Also for his typically brief and discouraging posts, which in turn drives my desire to prove him wrong

Deleted member 3665957 · Feb 5, 2013

@SouL Shadow:

RPM bootrom can be read by jtag, it starting from address 0x0 and length ~20 kb
most of htc/samsung/etc do not turn off jtag for RPM, so once you have some jtag box ( riff box for example ) you can connect to RPM (arm7 ) processor, halt it and dump memory.

darkspr1te · Feb 12, 2013

the_laser said:
@SouL Shadow:

RPM bootrom can be read by jtag, it starting from address 0x0 and length ~20 kb
most of htc/samsung/etc do not turn off jtag for RPM, so once you have some jtag box ( riff box for example ) you can connect to RPM (arm7 ) processor, halt it and dump memory.

Here is the PBL dump from MSM8660 / SHV-E160L
i dumped first 134MB of mem so just cut it at the first 20kb to only have the pbl.
actual zip size is only 500kb

Deleted member 3665957 · Feb 14, 2013

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;

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

Deleted member 3665957

Guest

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Inactive Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Inactive Recognized Developer

Deleted member 3665957

Guest

Senior Member

Attachments

Deleted member 3665957

Guest

Similar threads

Top Liked Posts