I think i may have come up with a way to CID unlock the G4 version of HTC Prophet, but i need help to complete some gaps.
As far as i can tell (and please correct me if i'm wrong) the only reason why the "downgrade&unlockcid" procedure doesn't work is because "pdocwrite.exe" can't write back the unlocked file. So, if we could find a way to write that information the problem should be solved...
I think that by performing the following steps one could do the unlocking:
- create an ActiveSync connection;
- run "unlockcid.bat" to get the "acidunlocked.bin" file;
- get the checksum of the "acidunlocked.bin" file;
- restart Prophet in bootloader mode;
- run "Rom Update Utility" and cancel after a successful "Verifying information..." window;
- use a TTY program to connect to the PDA and issue the following commands:
>ruustart
>ruuformat ???? 10000
>wdata ???? 10000
>HTCS
>"acidunlocked.bin content"
>"4-byte acidunlocked.bin checksum"
>HTCE
>ruuflashdoc ???? 10000 "4-byte acidunlocked.bin checksum"
>ruurun 0
>ResetDevice
The knowledge i lack is the exact memory address to place the information.
Also, is the data retrieved by "pdocread" in a "raw" format? And can it be directly written to the DOC by this method?
I think i'm very close, but i really help with these few things before taking the last step... i don't want to end up with an expensive brick.
PS.: i would like to thank all the people in the xda-developers, modaco and spv-developers forums, and all the other guys who have been "burning their brains out" to find solutions, and without whom i could never have gone this far (if one can call THIS "far"... )
1. Run Debug Tool
2. Set [5]Debug flags to '435' as 0b110110011
3. Set [8]Radio Flags to '1795' as 0b11100000011
According to the help, it enables "Enable ATCMD Log", "Enable RIL Ioctl Log","MARM use UART","MARM use USB","MARM use SD", I don't know their meanings.
4. Reset device
then my diamond stuck on bootloader screen, i reflashed the rom and it doesn't help. I am sure at least the hardspl works.
can anyone help to unbrick it?
I'll repeat the same here as on MSN so it's useful for others maybe:
if you dont know the meanings why are you playing? I know you have MFG SPL, so warning here, if anyone wants to play like this, make sure you have MFG SPL installed first because then it is easy to fix the problem. (non MFG SPL : still possible to fix but then you'd have to flash a file via lnbs command, a bit more painful.)
basically, you have to set the flags back to get OS booting; in MFG SPL, using mtty or qmat, simply send the following command: eraseconfig
PS: "MARM use USB","MARM use SD" -> these two are not a problem, one of the rest is what ****ted OS (not sure which). and, when you set marm use USB / SD, windows mobile will not have access to them (but SPL will), so that is kind of pointless.
thanks a lot to cmonex.
I found i am not the first one play too much with htc debug tools.
here is another thread with similar problem that solved by cmonex too..
http://forum.xda-developers.com/showthread.php?p=2852488
I've been on this board a few years now and I have never even heard of htc debug tools. I also don't know its purpose so I wouldn't play with it, period.
I made a big mistake,
2. Set [5]Debug flags to '435' as Wrong:0b110110011Right:0b10000110101
3. Set [8]Radio Flags to '1795' as Wrong:0b11100000011 Right: 0b1011110010101
the field in debug tools is intepreted as in hex format.
BTW, I confirmed "MARM use UART"(Radio Flags to 1xx) may stick the mobile.
S720 / HTC LIBRA / HTC 5800 / Fusion / Boss
I'm happy to hear that somebody is working on a hard SPL for HTC S720. Here's the deal, I really want to change esn in this phone but I realized that for now it's not possible.
It's a MSM7500.
**I've tryied QPST but the version 2.7 only support MSN6500.
**I've tried QXDM 3.9.19 and still can't write the new esn. It says read only.
_________________________
How to put it not in read only?
Could I use a anykind of ready/writer to change info directly on the chip?
-----------------------------
**CDMA Workshop 2.7 all kind os ESN write doesn't work.
-----So, two options left:
1- either I desolder the esn chip and change it for a new one (to be honest, I haven't discovered yet if the esn is inside the MSM or on a different chip. If it's the case (on a diff. chip) it's a bit a pain in the but to do but it's still an option.
2 - I want to try shadowmite's method for writing the ESN into a PPC6800. Again it need to be done in high level via MTTY.
Concerning MTTY I cannot run commands because I can't put the phone on the boot loader screen.
I will try to run RUU wich will put the phone in bootloader screen. And then try mtty.
I tried the method of RUU to get into bootloader and then run MTTY but it doesn't work... I get the error ''Unable to load USB port''.
Any suggestion...? Or any help I could bring to create this hard spl?
And please, anybody that is gonna tell me that it's illegal to do and that is gonna write me the FBI phone number it's fine, just pass to the next thread!
I'd be more than happy to help anybody with what I can.
A lot of phones will only boot if the firmware has a valid signature. Does the Samsung Wave check the firmware's signature (if there is one)?
In case of Bootloader I can confirm Signature check.
Because bricked after changing text...
boot_loader.mbn ---> yes, sure
dbl.mbn ---> not tested, but I think yes, because Qualcomm part...
All other files have no valid/mandatory Signature check.
You can modify all files.
Accept MD5 Hash for Multiloader, but this you can disable.
Handset self not check.
Best Regards
Can you tell us what you want to do??
Well, what I really want to know is if the hardware performs signature verification. For example, the bootloader in most HTC phones checks the signature of the firmware and will proceed to boot if it is valid. Replace the bootloader with your own custom bootloader and know checks are performed and you can put anything you want on it because the hardware does not check the signature of the bootloader. I also might want to modify Bada firmware, too. It is a different operating system or platform or whatever you want to call it and it looks like it would be fun to play around with. I own a Motorola DROID 2 Global.
Does anyone understand what I'm talking about?
Read it
http://forum.xda-developers.com/showpost.php?p=12213290&postcount=21
I'm afraid that is not clear enough. Has anyone tried to flash an alternative bootloader. And please, read my terminology. When I say bootloader, I mean software not the etched boot rom.
Has anyone tried to flash an alternative bootloader.
Click to expand...
Click to collapse
In case of our Flash Tool Multiloader we have only 2 files:
boot_loader.mbn----> "Samsung part"
dbl.mbn------------> "Qualcomm part"
As we have 2 CPU inside, 1 from Qualcomm... Call Processor, the other from Samsung = Application Processor.
So in most cases dbl.mbn is complete untouched in my tests. But I've failed in:
---> changing to oldest "unprotected" Boot XXJB6
---> changing to S8530 Boot (dbl.mbn is 1:1 same)
---> changing to modified S8500 Boot = bricked, but reanimated with JTAG
You can see my attempts here:
http://forum.xda-developers.com/showthread.php?t=897468
Boot means boot_loader.mbn, but I was tooo lazy to write full.
Best Regards
Master Melab said:
Has anyone tried to flash an alternative bootloader.
Click to expand...
Click to collapse
Oleg succeed doing it with JTAG. It is sure that it's also possible to do through FOTA, but there is almost no way to succeed at first try, so JTAG is also required there for the first tries. And... why would we do that? ;d
Also, iROM seems to perform some checksum validation, but as we can see from oleg's example - even without correct checksum it starts altered bootloader from oneNAND.
OK, getting to formal terminology there are several cryptographic services implemented on Wave bootloader level:
- integrity - on each loader stage
- authentication - modules loaded are verified using hardcoded (in BL3) public key
- confidentiality - some modules are encrypted using symmetric key cryptography
You may as well find some access control (implicit coming from symmetric key confidentiality and loading protocol requiring proper unlock procedure) and non-repudiation elements (storing the history of loaded components).
In more general view:
When talking about bootloader level software, it makes no sense to differentiate between hardware and software verification. It all comes to completeness of the verification chain. In most cases bootloader provides the only designated interface (with the presumption of not intruding hardware components) that is available for writing executable components into non-volatile memory used in the booting process.
Bearing that in mind, I would add to the locked bootloader definition that it does not only verify kernel, but verifies all executable components that take part in the booting process (including bootloader, of course).
Rebellos said:
Oleg succeed doing it with JTAG. It is sure that it's also possible to do through FOTA, but there is almost no way to succeed at first try, so JTAG is also required there for the first tries. And... why would we do that? ;d
Also, iROM seems to perform some checksum validation, but as we can see from oleg's example - even without correct checksum it starts altered bootloader from oneNAND.
Click to expand...
Click to collapse
What is [the] "iROM"?
Sent from my DROID2 GLOBAL using XDA App
mijoma said:
OK, getting to formal terminology there are several cryptographic services implemented on Wave bootloader level:
- integrity - on each loader stage
- authentication - modules loaded are verified using hardcoded (in BL3) public key
- confidentiality - some modules are encrypted using symmetric key cryptography
You may as well find some access control (implicit coming from symmetric key confidentiality and loading protocol requiring proper unlock procedure) and non-repudiation elements (storing the history of loaded components).
In more general view:
When talking about bootloader level software, it makes no sense to differentiate between hardware and software verification. It all comes to completeness of the verification chain. In most cases bootloader provides the only designated interface (with the presumption of not intruding hardware components) that is available for writing executable components into non-volatile memory used in the booting process.
Bearing that in mind, I would add to the locked bootloader definition that it does not only verify kernel, but verifies all executable components that take part in the booting process (including bootloader, of course).
Click to expand...
Click to collapse
Please define "BL3". (A stage 3 bootloader?) Yes good point about my definitions, I will add your suggestion. Does the Wave's bootloader use RSA, El Gamal, etc.?
Edit: But, in my mind it does make sense to differentiate the hardware and software.
Sent from my DROID2 GLOBAL using XDA App
Master Melab said:
What is [the] "iROM"?
Sent from my DROID2 GLOBAL using XDA App
Click to expand...
Click to collapse
iROM is a chip that contains code to load the very first bootloader from NAND, it cannot be modified i believe.
Rebellos said:
Also, iROM seems to perform some checksum validation, but as we can see from oleg's example - even without correct checksum it starts altered bootloader from oneNAND.
Click to expand...
Click to collapse
Catching errors, maybe?
Master Melab said:
Please define "BL3". (A stage 3 bootloader?) Yes good point about my definitions, I will add your suggestion. Does the Eave's bootloader use RSA, El Gamal, etc.?
Click to expand...
Click to collapse
Yes, I mean stage 3 bootloader.
There are 3 hardcoded public RSA keys. All 512 bit with 2^16+1 exponent.
Master Melab said:
Edit: But, in my mind it does make sense to differentiate the hardware and software.
Click to expand...
Click to collapse
Please justify the differentiation and define what you understand by hardware as I'm not sure whether you are really serious about it or not.
mijoma said:
Yes, I mean stage 3 bootloader.
There are 3 hardcoded public RSA keys. All 512 bit with 2^16+1 exponent.
Please justify the differentiation and define what you understand by hardware as I'm not sure whether you are really serious about it or not.
Click to expand...
Click to collapse
When I say "bootloader" think GNU GRUB and Windows' NTLDR—that is software. The reason for the differentiation is that the bootloader as defined in the PC world, the iOS hacking community, and other parts of the mobile development community is replaceable/flashable. When I refer to "hardware-based verification" I am talking about instructions physically etched on the chip that will perform some sort of signature or hash check of the lowest level of the boot chain. The "low level bootloader" or "LLB" in iOS is checked by the iPad/iPhone/iPod touch's boot ROM. The public key that is used to verify the LLB's signature is represented as physical breaks in the silicon.
Master Melab said:
When I say "bootloader" think GNU GRUB and Windows' NTLDR—that is software. The reason for the differentiation is that the bootloader as defined in the PC world, the iOS hacking community, and other parts of the mobile development community is replaceable/flashable. When I refer to "hardware-based verification" I am talking about instructions physically etched on the chip that will perform some sort of signature or hash check of the lowest level of the boot chain. The "low level bootloader" or "LLB" in iOS is checked by the iPad/iPhone/iPod touch's boot ROM.
Click to expand...
Click to collapse
Sorry, but if the area is not programmable it does not mean it's not software.
When thinking about 'embedded' world, leave the PC world alone. The list of differences is longer than the list of similarities.
Have a point there, but even if the verification is not done by hardware it does not mean it's replaceable (without hardware intrusion). The formal logic would require to show exploitable vulnerability first and there isn't a generic one.
Master Melab said:
The public key that is used to verify the LLB's signature is represented as physical breaks in the silicon.
Click to expand...
Click to collapse
LOL. Sounds like written with blood. Maybe I'm not English native and that's the reason I didn't get it, but could you elaborate (you may go deep without worries) on the method of creating 'physical breaks in the silicon' as it does not seem to be scientific term? It does, however, seem just as a description of a form of 'non-volatile memory'.
What value does the strict lowest level protection policy have when higher level introduce (with increasing probability with each level) vulnerabilities easier to exploit?
Does the Wave's bootloader use RSA, El Gamal, etc.?
Click to expand...
Click to collapse
RSA I've seen.
El Gamal never heard.
etc. not sure...
Maybe if you have some time and you are willing to learn with us. For instance here:
http://forum.xda-developers.com/showpost.php?p=13522665&postcount=50
In Firmware files are many Certs included... few of them seems to have also private parts... but encrypted... example:
EncryptedDevcerttemplateFile
EncryptedPrivKeyFile
According to other Samsung handsets... folder Security is also available on other models... few Certs should be same...
No idea if all Certs are usefull... but maybe fun to train brain.
Best Regards
mijoma said:
Have a point there, but even if the verification is not done by hardware it does not mean it's replaceable (without hardware intrusion).
Click to expand...
Click to collapse
Please, explain.
mijoma said:
LOL. Sounds like written with blood. Maybe I'm not English native and that's the reason I didn't get it, but could you elaborate (you may go deep without worries) on the method of creating 'physical breaks in the silicon' as it does not seem to be scientific term? It does, however, seem just as a description of a form of 'non-volatile memory'.
Click to expand...
Click to collapse
Things like a BIOS or true read only memory have instructions or data encoded into the layout of the circuitry itself. Usually, fuses are either broken or left intact and this may either mean a 1 or a 0, depending on the manufacturers device works.
adfree said:
RSA I've seen.
El Gamal never heard.
etc. not sure...
Maybe if you have some time and you are willing to learn with us. For instance here:
http://forum.xda-developers.com/showpost.php?p=13522665&postcount=50
In Firmware files are many Certs included... few of them seems to have also private parts... but encrypted... example:
EncryptedDevcerttemplateFile
EncryptedPrivKeyFile
According to other Samsung handsets... folder Security is also available on other models... few Certs should be same...
No idea if all Certs are usefull... but maybe fun to train brain.
Best Regards
Click to expand...
Click to collapse
adfree, when I say "etc." I mean "et cetera", which in Latin means "and other things" or "and so forth". El Gamal is another asymmetric cryptosystem that relies on the difficulty of factoring a large composite number, just like RSA.
And thank you for the file.
Guys, I'm having kind of a situation here:
I installed Rogers HTC 621 - 1.30.631.2 (WM6)
http://www.mediafire.com/download.php?5xuh3jv2yg4
That I found here:
http://forum.xda-developers.com/showthread.php?t=381726
The problem is that, now, when I want to leave this ROM because I've been having some problems with it, it won't update. I've tried using SDA Unlock but it hasn't worked out. It always shows: unlockable phone, and right after this box it shows: phone unlocked. But it isn't. Could you guys help me solve this problem?!
Whenever I try installing any .cab files it shows the following message:
Installation was unsuccessful. The program or setting cannot be installed because it does not have sufficient system permissions.
If you could help me solve this only problem I wouldn't even need to update the ROM...
Try the attached HTC Unlock. It is a wrapped signed registry editor that is scripted to change the relevant Policy settings in the registry. Run the .exe on the PC, it will install the program on the device and you find it in Start -> Accessories -> HTC Unlock.
Basically you need to change the RAPI (Remote API) Policy to allow changes e.g. via SDA Unlock.
tobbbie said:
Try the attached HTC Unlock. It is a wrapped signed registry editor that is scripted to change the relevant Policy settings in the registry. Run the .exe on the PC, it will install the program on the device and you find it in Start -> Accessories -> HTC Unlock.
Basically you need to change the RAPI (Remote API) Policy to allow changes e.g. via SDA Unlock.
Click to expand...
Click to collapse
Well, I've tried what you suggested and I'm really thankful, but it didn't work out. I still can't install .cab files and I still can't ulock the cell phone with SDA Security Unlocker because it says "phone is not unlockable".
How I wish anyone could help me...
Did you finally also execute the HTC Unlocker from the Start -> Accessories folder? You should see the registry editor change some settings. For the RAPI part the x'1001 is the policy and it must be set to 1.
There is a more complicated method - doing this by the Microsoft Security Configuration Manager. Hard to find the link to download, look here: http://www.microsoft.com/download/en/details.aspx?id=998 This allows to apply dedicated security profiles (sets of Policies) to the device. If this works however also depends on the active settings in the device OS however. You may need to load the Development Certificates first via Menu "Device -> Add Dev..."
Would it not be the easiest case to just revert to the original ROM for the device? There the CID matches when updating and then you don't need the sequence of "old-OS application Unlock, load patched SPL, load new OS" - simply because the original SPL will pass the CID check. Get to http://www.shipped-roms.com/index.php?category=windows mobile&model=Excalibur and see if you find it.
Which was the original ROM you had on it?
Problem solved.
After looking in some other posts here on XDA I found many solutions and, by working out on them together, I could finally fix it.
I used SP Allow Certificate, SDK Certs, Exc USPL and, in the end, it really mattered.
Thanks to all you guys who keep up with feeding the forum.