Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,807,128 Members 40,502 Now Online
XDA Developers Android and Mobile Development Forum

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

Tip us?
 
the_laser
Old
#21  
Senior Member
Thanks Meter 775
Posts: 123
Join Date: Feb 2011
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
The Following User Says Thank You to the_laser For This Useful Post: [ Click to Expand ]
 
newbit
Old
(Last edited by newbit; 31st January 2013 at 09:29 AM.)
#22  
Junior Member
Thanks Meter 7
Posts: 23
Join Date: Nov 2008
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?

Quote:
Originally Posted by SouL Shadow View Post
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
Old
(Last edited by SouL Shadow; 2nd February 2013 at 11:47 AM.)
#23  
SouL Shadow's Avatar
Senior Member - OP
Thanks Meter 296
Posts: 460
Join Date: Jun 2010
Location: Stratford, CT
Default Status update

Quote:
Originally Posted by newbit View Post
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.
-SLS-
The Following User Says Thank You to SouL Shadow For This Useful Post: [ Click to Expand ]
 
newbit
Old
#24  
Junior Member
Thanks Meter 7
Posts: 23
Join Date: Nov 2008
Quote:
Originally Posted by SouL Shadow View Post
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!!

Quote:
Originally Posted by SouL Shadow View Post
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.

Quote:
Originally Posted by SouL Shadow View Post
  • 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.

Quote:
Originally Posted by SouL Shadow View Post
  • 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?

Quote:
Originally Posted by SouL Shadow View Post
  • 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

Quote:
Originally Posted by SouL Shadow View Post
  • 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
Old
(Last edited by SouL Shadow; 2nd February 2013 at 11:49 AM.)
#25  
SouL Shadow's Avatar
Senior Member - OP
Thanks Meter 296
Posts: 460
Join Date: Jun 2010
Location: Stratford, CT
Quote:
Originally Posted by newbit View Post
Thank you too, i appreciate your help and informations from the past, and also in the future!!



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.

Quote:
Originally Posted by newbit View Post
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.

Quote:
Originally Posted by newbit View Post
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



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.

Quote:
Originally Posted by newbit View Post
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
-SLS-
 
SouL Shadow
Old
#26  
SouL Shadow's Avatar
Senior Member - OP
Thanks Meter 296
Posts: 460
Join Date: Jun 2010
Location: Stratford, CT
Added some goodies to posts 1 and 2.
Enjoy
-SLS-
 
newbit
Old
#27  
Junior Member
Thanks Meter 7
Posts: 23
Join Date: Nov 2008
Quote:
Originally Posted by SouL Shadow View Post
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.

Quote:
Originally Posted by SouL Shadow View Post
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

Quote:
OUT: 7E 06 4E 95 7E (NO-OP)
IN: 7E 02 6A D3 7E (ACK)
Pushing Download Button:
Quote:
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)
Quote:
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

Quote:
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

Quote:
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:
Quote:
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
Quote:
OUT: 7E 06 4E 95 7E (NO-OP)
IN: 7E 02 6A D3 7E (ACK)
And now the ACTION i dont understand!?!

Quote:
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
Quote:
19 Partition table Host Y 3.00 Send partition table to use for programming images
2. Case it wants the Cookie: who not?!
QPST it's trying to send a cookie request
According to 80-39912-1_E_DMSS_Download_Protocol.pdf page 14 and 32
Quote:
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
The Following User Says Thank You to newbit For This Useful Post: [ Click to Expand ]
 
SouL Shadow
Old
(Last edited by SouL Shadow; 2nd February 2013 at 02:04 PM.)
#28  
SouL Shadow's Avatar
Senior Member - OP
Thanks Meter 296
Posts: 460
Join Date: Jun 2010
Location: Stratford, CT
Quote:
Originally Posted by newbit View Post
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.

Quote:
Originally Posted by newbit View Post
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?!
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.

Quote:
Originally Posted by newbit View Post
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.

Quote:
Originally Posted by newbit View Post
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?
-SLS-
 
newbit
Old
#29  
Junior Member
Thanks Meter 7
Posts: 23
Join Date: Nov 2008
Quote:
Originally Posted by SouL Shadow View Post
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?

Quote:
Originally Posted by SouL Shadow View Post
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?

Quote:
Originally Posted by SouL Shadow View Post
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
Old
(Last edited by darkspr1te; 30th January 2013 at 04:42 PM.)
#30  
darkspr1te's Avatar
Senior Member
Thanks Meter 447
Posts: 828
Join Date: Sep 2012
Default Re: [R&D][QUALCOMM] Using QDL, EHostDL and DIAG interfaces & features

Quote:
Originally Posted by newbit View Post
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://forum.xda-developers.com/show....php?t=1856327


Sent from my A210 using Tapatalk 2
New Debrick Tools, See Below:- (I no longer will respond to unsolicited PM's)

Goto Brixfix V2
My Documentation in debricking Qualcomm Device
[SHV-E160]Rooting & Rom info
Tegrak Clean Roms
Korean Galaxy Note Development/Root/ROMS

비밀의 dark
도화의 spr1te

The Following User Says Thank You to darkspr1te For This Useful Post: [ Click to Expand ]
Tags
qdl, qualcomm, r&d
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes