Binary partition 1 corrupt

[slickdick]

Hi,

I ran doctest on my prophet which ended up corrupting the doc. I managed to get the doc fixed except for binary partition 1. Now I have a prophet which boots into the OS, but has a corrupt CID, IMEI, SIMLOCK, GSMDATA, etc- which means my prophet is now a PDA without a phone...
In short, 0x0-0x44000 area on binary partition 1 is corrupt and I don't have a backup of it.
Can a dump of this block from another prophet be used directly on my device? What all would have to be reconstructed in this block to make it run successfully on my device?

Pls help!

[Jesterz]

Hi,

I ran doctest on my prophet which ended up corrupting the doc. I managed to get the doc fixed except for binary partition 1. Now I have a prophet which boots into the OS, but has a corrupt CID, IMEI, SIMLOCK, GSMDATA, etc- which means my prophet is now a PDA without a phone...
In short, 0x0-0x44000 area on binary partition 1 is corrupt and I don't have a backup of it.
Can a dump of this block from another prophet be used directly on my device? What all would have to be reconstructed in this block to make it run successfully on my device?

Pls help!

for people reading this, DO NOT RUN DOCTEST ! EVER !

for sidekick, what do you have ? G3/G4?
if you have a G3 it should be possible to fix with itsme tools if you know what you are doing.

[slickdick]

I have a G3 IPL 1.0 SPL 2.15.0000 (+gold card)
I have managed to get 0x00000-0x10000 from a wizard (cid locked/sim unlocked). Updated it with superCID using typhooncidedit.pl and flashed it on my doc using pdocwrite.
However, I am still getting a "GetDeviceCID: Error - InitDecoder" on running 'info 2', IMEI is still the default 44xxxx... and am getting Simlock.exe error-"Data error: contact service....." on inserting a SIM

I can think of the following three reasons why this hasn't worked for me:
1. wizard and prophet have different CID blocks and one from prophet might work
2. CID block contains a unique device specific identifier (docuniqueid maybe) apart from what is not mentioned in typhooncidedit.pl
# 0x0000-0x0004 - version
# 0x0010-0x0018 - checksum cryptkey
# 0x0140-0x0148 - imei
# 0x0160-0x0180 - cid
# 0x01a0-0x01a8 - keyindex at byte +3
# 0x1200-0x1a00 - cid cryptkey
# 0x1c80-0x1c88 - lockflag
# 0x1d00-0x1f00 - lockcodes
# 0x4000-0x4400 - mccmnc ??
# 0xfff8-0xffff - checksum of 0-0xfff8
3. the device looks at information in 0x10000-0x40000 at least for IMEI & simlock

Am I on the right track or are there any easier alternatives? Either ways, I think it is important for me to get 0x00000-0x44000 of a G3 prophet in order to investigate further.
It would of GREEEAAAT help if someone can provide me a dump of this area
pdocread -n 1 0 0x40000 cidblock.bin
pdocread -n 1 0x40000 0x4000 -b 0x4000 gsmdata.bin
(pls also mention your docuniqueid from 'pdocread -l')

[Jesterz]

I have a G3 IPL 1.0 SPL 2.15.0000 (+gold card)
I have managed to get 0x00000-0x10000 from a wizard (cid locked/sim unlocked). Updated it with superCID using typhooncidedit.pl and flashed it on my doc using pdocwrite.
However, I am still getting a "GetDeviceCID: Error - InitDecoder" on running 'info 2', IMEI is still the default 44xxxx... and am getting Simlock.exe error-"Data error: contact service....." on inserting a SIM

I can think of the following three reasons why this hasn't worked for me:
1. wizard and prophet have different CID blocks and one from prophet might work
2. CID block contains a unique device specific identifier (docuniqueid maybe) apart from what is not mentioned in typhooncidedit.pl
# 0x0000-0x0004 - version
# 0x0010-0x0018 - checksum cryptkey
# 0x0140-0x0148 - imei
# 0x0160-0x0180 - cid
# 0x01a0-0x01a8 - keyindex at byte +3
# 0x1200-0x1a00 - cid cryptkey
# 0x1c80-0x1c88 - lockflag
# 0x1d00-0x1f00 - lockcodes
# 0x4000-0x4400 - mccmnc ??
# 0xfff8-0xffff - checksum of 0-0xfff8
3. the device looks at information in 0x10000-0x40000 at least for IMEI & simlock

Am I on the right track or are there any easier alternatives? Either ways, I think it is important for me to get 0x00000-0x44000 of a G3 prophet in order to investigate further.
It would of GREEEAAAT help if someone can provide me a dump of this area
pdocread -n 1 0 0x40000 cidblock.bin
pdocread -n 1 0x40000 0x4000 -b 0x4000 gsmdata.bin
(pls also mention your docuniqueid from 'pdocread -l')

you are on the right track, as you have a G3 it should be possible to fix as pdocwrite can write a G3 DOC

as you can see from my signature, my G3 is bricked so I can't help at the moment
however, I see you have a gold card !? care to explain how you made it ?
Thanks

[slickdick]

I just followed the instructions in typhoonnbfdecode.pl with slight modifications to some checks in IPL & OS

you have a bricked G3.... stuck in bootloader I presume? There are two ways you can fix it with the help of a gold card.

1. Cardid is known and docuniqueid is not known

use tornado keys and xxx magic and '00' as first two chars in cardid to generate a securitylevel=0 non-flashable sd image.

>perl typhoonnbfdecode.pl -d prophet_gold.img -p magic=xxx -p cardid=00610032DF69A01947323044534D5402 -p keys=tornado -p seclevel=0

using this card I get a the normal bootloader screen but with a security level of 0

Cmd>set 32 0
+ SD Controller init
- SD Controller init
+StorageInit
***** user area size = 0x7AC00000 Bytes
Unlimited time!
GetDeviceCID: Error - InitDecoder <<<<< due to corrupt bin partition 1
g_cKeyCardSecurityLevel = 0 <<<<< Voila!

now use the l or lr command in bootloader!!!

2. both Cardid and and docuniqueid are known

use tornado keys and '00' as first two chars in cardid to generate a flashable sd image.

however, for this to work, comment out all the checks in validate_os and the BIPO check in validate_ipl in typhoonnbfdecode.pl

>perl typhoonnbfdecode.pl -d sd80.img -p cardid=00610032DF69A01947323044534D5402 -p keys=tornado -p seclevel=0 -p docuniqueid=00000000a440020420380318130b0571 -r os=OS.nb

no more "Not Allow Update" 's

[paradis_pal]

I'm so busy now in the college exams, this is my graduation year, and I only look at the posts like checking my mail without replying.
But at least I find a guy understand what he is doing, and has no ego, and polite, not like others in this very impolite, and the problem they are stupid, and think themselves understand, all what they do, reading and repeating without understanding or try to improve.

After this long story you don't have to read it, trying to help you if I can.

About the IMEI block => try to use IMEI wizard for changing the IMEI for prophet it will overwrite the old block. It uses pdocwrite.exe =pdocread.exe

About the other blocks I have a G3 prophet IPL 2.10 SPL 2.20 and I have back up with r2sd all and unlocked CID.
I'll pdocread any block you want but I'm going to send it by e-mail in parts, because I can't guarantee the net in big files, so just read your private messages.

[Jesterz]

I just followed the instructions in typhoonnbfdecode.pl with slight modifications to some checks in IPL & OS

you have a bricked G3.... stuck in bootloader I presume? There are two ways you can fix it with the help of a gold card.

1. Cardid is known and docuniqueid is not known

use tornado keys and xxx magic and '00' as first two chars in cardid to generate a securitylevel=0 non-flashable sd image.

>perl typhoonnbfdecode.pl -d prophet_gold.img -p magic=xxx -p cardid=00610032DF69A01947323044534D5402 -p keys=tornado -p seclevel=0

using this card I get a the normal bootloader screen but with a security level of 0

Cmd>set 32 0
+ SD Controller init
- SD Controller init
+StorageInit
***** user area size = 0x7AC00000 Bytes
Unlimited time!
GetDeviceCID: Error - InitDecoder <<<<< due to corrupt bin partition 1
g_cKeyCardSecurityLevel = 0 <<<<< Voila!

now use the l or lr command in bootloader!!!

2. both Cardid and and docuniqueid are known

use tornado keys and '00' as first two chars in cardid to generate a flashable sd image.

however, for this to work, comment out all the checks in validate_os and the BIPO check in validate_ipl in typhoonnbfdecode.pl

>perl typhoonnbfdecode.pl -d sd80.img -p cardid=00610032DF69A01947323044534D5402 -p keys=tornado -p seclevel=0 -p docuniqueid=00000000a440020420380318130b0571 -r os=OS.nb

no more "Not Allow Update" 's

Create, Let me try some things here, In my gold card thread I've started outlining this.
I used the same steps as you did, however I got stuck in getting the cardid, for some reason the memdump didnt contain the cardid.
which route did you use to get the cardid ?
(I used my second prophet to get that, but failed)
Thanks for the explaining so far.

[Jesterz]

I'm so busy now in the college exams, this is my graduation year, and I only look at the posts like checking my mail without replying.
But at least I find a guy understand what he is doing, and has no ego, and polite, not like others in this very impolite, and the problem they are stupid, and think themselves understand, all what they do, reading and repeating without understanding or try to improve.

After this long story you don't have to read it, trying to help you if I can.

About the IMEI block => try to use IMEI wizard for changing the IMEI for prophet it will overwrite the old block. It uses pdocwrite.exe =pdocread.exe

About the other blocks I have a G3 prophet IPL 2.10 SPL 2.20 and I have back up with r2sd all and unlocked CID.
I'll pdocread any block you want but I'm going to send it by e-mail in parts, because I can't guarantee the net in big files, so just read your private messages.

Nice to see you back on the board, I've read some of your early posts and they were a great help !
If you could help out that would be great, I know what it is like during exams ;)

[Jesterz]

Id would be great if you guys could help me find the cardid, I'm trying to get this, but im guessing i'm looking at the wrong section:

Using memmap on my G4 i've dumped the memory section of device.exe
pmemmap -s 0x06000000 -w deviceexe.mem -p 0x10000000-0x12000000
However when searching through it, I can't find the SBDS/ Memory Card section, only a RSDS section at 0x1101C.
Am I dumping the wrong section ?

[paradis_pal]

try to search for memory card using unicode character set ((winhex)), because it's writtin in unicode

I'm not sure, if you are using any other ROM but try to use original qteck s200 rom 2.20 without insalling anyother programs, and try again without installing the ext rom,
try any debuger manger to find out the memory section of device.exe cause it is not always 0x06000000

[Jesterz]

try to search for memory card using unicode character set ((winhex)), because it's writtin in unicode

I'm not sure, if you are using any other ROM but try to use original qteck s200 rom 2.20 without insalling anyother programs, and try again without installing the ext rom,
try any debuger manger to find out the memory section of device.exe cause it is not always 0x06000000

Thanks for the advice, I did use winhex in unicode, I will try with the qtek rom,I will post an update soon, getting my card reader at work now ;)
hope your exams are going ok !

[slickdick]

For CardID, on my G3, I did not find the SBDS signature in the memory dump of device.exe. However, there were two occurances of Unicode "Memory Card". 73 (0x49) bytes after one of them was what I could recognize as the cardid.

From what I can make of the codes (ASCII) mentioned in typoonnbfdecode.pl

'UE...c.U821DSDS.' for minisd
'?Q..S.@.BM821NI.' for kingston
'?<.e.Gd.821DSMT.' for daneelec

All three have 821, which is reverse of 128!!! size 128MB!!! Ring-a-bell?!? Can we interpret similar structure for all other cards < 1GB?
'DSMT' seems to be standard for Dane Elec cards. same can be interpreted for other types like DSDS looks to be standard(maybe somone can confirm this)

If you analyze the ASCII of card id of my 2GB Dane Elec- '%a.2ßi..G20DSMT.'
you will see 'G20' representing size (representation for size seems to be different for cards > 1G. Again, someone needs to confirm this observation) and 'DSMT' standard signature for Dane Elec.

All in all, if you are not able to find the 'Memory Card' pattern, depending upon card make and size, search for any of the CardID ASCII patterns in the memory dump.

(btw, To find the starting offset of CardId- third character of CardId seems to be 0x00. If you are familiar with using grep, finding cardid in the memory dump could be easier)

Let me know if this helps.

[slickdick]

Reverse of cardids is shown below:

minisd in typoonnbfdecode.pl
03 53 44 53 44 31 32 38 55 00 63 CF AC 00 45 55 SDSD128U cϬ EU
kingston in typoonnbfdecode.pl
18 49 4E 31 32 38 4D 42 03 40 1F 53 09 00 51 3F IN128MB @ S Q?
Dane Elec in typoonnbfdecode.pl
02 54 4D 53 44 31 32 38 07 64 47 BA 65 00 3C 3F TMSD128 dGºe <?
and finally my 2GB Dane elec
02 54 4D 53 44 30 32 47 19 A0 69 DF 32 00 61 25 TMSD02G *iß2 a%

Makes sense? I think you can directly search for the cardid pattern in the memory dump.

[Jesterz]

Reverse of cardids is shown below:

minisd in typoonnbfdecode.pl
03 53 44 53 44 31 32 38 55 00 63 CF AC 00 45 55 SDSD128U cϬ EU
kingston in typoonnbfdecode.pl
18 49 4E 31 32 38 4D 42 03 40 1F 53 09 00 51 3F IN128MB @ S Q?
Dane Elec in typoonnbfdecode.pl
02 54 4D 53 44 31 32 38 07 64 47 BA 65 00 3C 3F TMSD128 dGºe <?
and finally my 2GB Dane elec
02 54 4D 53 44 30 32 47 19 A0 69 DF 32 00 61 25 TMSD02G *iß2 a%

Makes sense? I think you can directly search for the cardid pattern in the memory dump.

Great ! thanks, I'm dumping right now, after looking for the memory adress of device.exe using pps
will update in a moment :)

[Jesterz]

uhmm, I think we have a winner ??

at 00729EC0
23 61 00 3D 92 68 10 80 32 31 35 52 53 44 53 03
#a.=’h.€215RSDS.

for a 512 MB sandisk sd card

created the image, I now have sec level 0.
I've downloaded mtty and want to upload a new SPL using the L or LR command, however I don't know what parameters L or LR takes ?

is it just L <filename>
or do I have to specify the memory adress or the SPL ?

[pof]

is it just L <filename>
or do I have to specify the memory adress or the SPL ?

l <path_name> <startAddr offset>

You have to specify the address of the SPL, if you don't specify it most probably will default to OS address.

[Jesterz]

l <path_name> <startAddr offset>

You have to specify the address of the SPL, if you don't specify it most probably will default to OS address.

ok thanks ! i'm going to give this a go

l spl.nb 0x91000000

fingers crossed, lol

[Jesterz]

Cmd>l spl.nb 91000000
clean up the image temp buffer at 0x8C100000 Length 0x03900000
BOOTLOAD_PAGE_TABLE_BASE_C_VIRTUAL= 0x8C080000
Clear image temp buffer done .
MTTYDownloadImage "spl.nb"
:F=spl.nb
start download

SAddress A0000000h Length 000C0000h, pszImageTempBuffer = 8C100H000h
OEMGetFlashIndex()- dwVaddr = 0xA0000000
OEMGetFlashIndex()- iIndex = 0xFFFFFFFF
Start flashing new image!!!
<CE-31><CE-1167><CE-995>


weird, the screen then goes all white, and I hear the usb disconnect, for the rest nothing happens.
which format does the spl file need to be ? i've used the "standard" nb file
i'm trying more stuff, but right now, i'm clueless :(

[pof]

BOOTLOAD_PAGE_TABLE_BASE_C_VIRTUAL= 0x8C080000

This seems good, as it is the virtual address from where the bootloader expects to be executed.

weird, the screen then goes all white, and I hear the usb disconnect, for the rest nothing happens.

Weird... I believe command "l" auto-launches code once downloaded, probably this is the reason.

which format does the spl file need to be ? i've used the "standard" nb file

I think it should be a BIN file with "l" command... maybe try "lnb" command? (I don't know if prophet has it, I don't have a prophet). Hope the previous "l" command hasn't screewed things more than they where.

Just out of curiosity, tell me how the story ends :)

[KTamas]

I think it should be a BIN file with "l" command... maybe try "lnb" command? (I don't know if prophet has it, I don't have a prophet). Hope the previous "l" command hasn't screewed things more than they where.

Just out of curiosity, tell me how the story ends :)
as far as i know, "l" is for .bin only (at least on wizard)... I hope Jesterz did not just nuke his bootloader.

[Jesterz]

as far as i know, "l" is for .bin only (at least on wizard)... I hope Jesterz did not just nuke his bootloader.

I can confirm i'm still in the bootloader (IPL)
in short what i'm trying to do is to replace the SPL, as due to a stupid mistake my G3 was flashed with a G4 spl and I have hopes I can flash it back to a G3 SPL and "unbrick" my phone before I try and hardward fixes (JTAG etc)

lnb is not in the prophet rom, only l or lr, the problem seems that it is not picking up the start address for the SPL part....

[KTamas]

I can confirm i'm still in the bootloader (IPL)
in short what i'm trying to do is to replace the SPL, as due to a stupid mistake my G3 was flashed with a G4 spl and I have hopes I can flash it back to a G3 SPL and "unbrick" my phone before I try and hardward fixes (JTAG etc)

lnb is not in the prophet rom, only l or lr, the problem seems that it is not picking up the start address for the SPL part....
So, if IPL is the actual device bootloader, is SPL the phone bootloader or what?

[pof]

So, if IPL is the actual device bootloader, is SPL the phone bootloader or what?

IPL is the initial program loader, it does a very minimal hardware setup and detects if device is on a wake up, or in a cold boot.

If it is a wakeup then it jumps to wince kernel (0xa0040000), otherwise it loads the SPL to 0xa0000000 and executes its code...

The SPL is what we usually refer to when we talk about "bootloader", and it has the command prompt you're probably used to see... it's much more complicated than the IPL.

The IPL is very small so it can be disassembled and followed easily by looking at the device CPU manual.

In HTC devices using Qualcomm chipsets for radio, there are two more bootloaders inside the radio chipset: HTC_BOOT and QC_BOOT.

HTC_BOOT is what we usually call "radio bootloader" and can be accessed with 'rtask a' command in normal bootloader.

[KTamas]

IPL is the initial program loader, it does a very minimal hardware setup and detects if device is on a wake up, or in a cold boot.

If it is a wakeup then it jumps to wince kernel (0xa0040000), otherwise it loads the SPL to 0xa0000000 and executes its code...

The SPL is what we usually refer to when we talk about "bootloader", and it has the command prompt you're probably used to see... it's much more complicated than the IPL.

The IPL is very small so it can be disassembled and followed easily by looking at the device CPU manual.

In HTC devices using Qualcomm chipsets for radio, there are two more bootloaders inside the radio chipset: HTC_BOOT and QC_BOOT.

HTC_BOOT is what we usually call "radio bootloader" and can be accessed with 'rtask a' command in normal bootloader.
Thanks for the info :)

[slickdick]

Finally got some time to work on the corrupt Binary partition on my prophet. Reconstructed the CID block using another prophets cidblock. updated gsm data, changed imei and voila! I finally have the prophet back after the DOCTEST disaster!
btw, reconstructing cid block was a the key part as each cidblock is unique to a device (generated with docid as previously assumed!)...

Thanks a ton to paradis for providing the cidblock and gsmdata from his device.

[Jesterz]

Finally got some time to work on the corrupt Binary partition on my prophet. Reconstructed the CID block using another prophets cidblock. updated gsm data, changed imei and voila! I finally have the prophet back after the DOCTEST disaster!
btw, reconstructing cid block was a the key part as each cidblock is unique to a device (generated with docid as previously assumed!)...

Thanks a ton to paradis for providing the cidblock and gsmdata from his device.

Nice one !
Did you create an SD GSM DATA image to update your corrupt partition ?

[paradis_pal]

thanks a ton to me, you are welcome I didn't see that

I think he used pdocwrite to write the data

[paradis_pal]

Dear Jester
I hope this is not late
Start address 0x80000800 Length 0xC0000 Checksum 0x05F46B88

or maybe Checksum=0x16E5CB15 the cheksum is not important for you now

try this

l r2sdG3spl 0x80000800

if didn't work add file EXT like bin, nbf or nb I don't know as you like

and if some please tell me why it is diffrenet byte at offset 1930 between my spl and the spl in nk.nbf, I'm worried, I flash it more and more, and there is the same diffrenet at offset 1930 this is the only diffrenet in all 786432 bytes
orginal nk.nbf offset 1930 the hex value is 6F
the SPL in my phone has hex value is 13

is there bad blocks in my DOC :( :mad:

I check only in OS and SPL
OS pass but there is that diffrenet in SPL

[paradis_pal]

forget the file:D :D :D




bad net, I tried almost more than 0xffffffffffffff times :D

I split the files use winrar

I didn't knew max 5 files the 6th above

[paradis_pal]

so Jeserz didn't try it yet?

[Jesterz]

Thanks a bunch ! I will try it tonight, I'm at work now, will post an update later :)

[paradis_pal]

so I think it didn't work right

[slickdick]

I think he used pdocwrite to write the data

AB-SO-LUTELY!

[paradis_pal]

AB-SO-LUTELY!
slickdick, you are my hero, hope that your dick is slick as mine:D :D
would you please test my ROM and tell me if it is working with you please :mad:

[Jesterz]

Cmd>l SPL.nb 0x80000800
clean up the image temp buffer at 0x8C100000 Length 0x03900000
BOOTLOAD_PAGE_TABLE_BASE_C_VIRTUAL= 0x8C080000
Clear image temp buffer done .
MTTYDownloadImage "SPL.nb"
:F=SPL.nb
start download
SSync bytes error(0) FE != 42Error : DownloadImage return error (code = 0xFFFFFFFF)

[Jesterz]

weird, either mtty is doing a funny (Request header timeout)

I've also tried to create a goldcard with an SPL part on it, it work, as in it starts to flash, but about 3/4rds done it stops and says: SPL flash failed.

?????????