Develop Bugs

A way of flashing the RUU rom extract

Because of my stupid mistakes of making my SD card failed the first time, I found a way to actually downgrade the system using HBoot mode even if you have a new HBoot system (i.e. Official Chinese version, Carrier Locked version, etc).
First thing to do, is to download the 2.73.405.5 official WWE RUU package (the exe);
Then, run that wizard, and while the wizard's program is running, search in your PC's %userprofile% folder, and look for "rom.zip"
Rename that rom.zip to HEROIMG.zip.
Put that file into your MicroSD card's root folder. Do not modify its contents.
put that SD card into your phone.
While the card is in, hboot the device (vol down + power).
it will pop up the HBOOT mode of the device. It will now check for a few files if they exist on your SD card. (HERODIAG.zip, etc)
in the last check, it will look for HEROIMG.zip, and tries to load it. Once the loading bar is complete on the top right side of the device, it will ask you to press home to continue the upgrade, or press other key to escape it. (i am not 100% sure if those are the keys, but you can read english so figure that part out).
Once the flashing is done (remember, this method will wipe everything. including radio, recovery, system, data, cache), you will now have a complete original ROM on your system. From there, use InstantRoot or any other rooting exploit, to root your device, put Cyanogen's recovery there, and start upgrading into custom roms!
Let me know if this method works or not. it worked on 3 of my friend's HTCs.
/* p.s. however i still have my unresolved issue about the SD card slot and USB device not recognized issue. */

Nope, I tried that before and it fails the CID check.

Guiness in a can? BRILLIANT!
yea, everyone has been jumping through their butts trying to figure out how to make goldcards and bypasses... why not just use hboot like htc probally uses it? Duh! Thanks for this!
edit..... oh snap....

does not work for me!
Once the loading bar is complete on the top right side of the device
go back to hboot...
and nothing to do

this won't work because the SPL is still checking the CID of the rom.zip you renamed to HEROIMG
for some people the flash will work, but thats because they have a hero with a CID thats in the range of the cid numbers (open the .zip file and check the android-info.txt to see the list.
changing topic is this is confusing people
nice try though

Otiginal IMG
Confirm ...works for me.After rooting...... and flashing couple images i try reflash back original rom - official ruu not want work ...stop on bootloader .....extracted rom not be a flashable trough sd card and amon ra loader....this way work like charm.Thnx.

Original IMG
Confirm ...works for me.After rooting...... and flashing couple images i try reflash back original rom - official ruu not want work ...stop on bootloader .....extracted rom not be a flashable trough sd card and amon ra loader....this way work like charm.Thnx.

Thank you, you are the man!
Thank you so much, i was about to eat my phone. it is htc hero and it worked. thank you so much...

since we have this thread i can ask as well...
is HEROIMG.ZIP signed, or why wouldn't one just alter the CID values in android-info.txt?

kendong2 said:
since we have this thread i can ask as well...
is HEROIMG.ZIP signed, or why wouldn't one just alter the CID values in android-info.txt?
Click to expand...
Click to collapse
I believe it is signed using HTC's own personal keys, preventing us changing the RUU extract.

anon2122 said:
I believe it is signed using HTC's own personal keys, preventing us changing the RUU extract.
Click to expand...
Click to collapse
Might be worth a test to do self signed ?

Jesterz said:
this won't work because the SPL is still checking the CID of the rom.zip you renamed to HEROIMG
for some people the flash will work, but thats because they have a hero with a CID thats in the range of the cid numbers (open the .zip file and check the android-info.txt to see the list.
changing topic is this is confusing people
nice try though
Click to expand...
Click to collapse
hi, i have the same problem and my cid is in in the list.
what could be the problem?

How the hell did you came up with that?
It worked perfectly! Cannot thank you enough.
You're the man.

been looking for this for nearly a week.
got my wife a new phone and want to store it original, but couldnt get back to stock,all cid fails.
with this version no cid fail and stock htc hero again.
thanks, you tha man.

[Q] Any chance of fixing USB Brick w/o root ?

Well I USB bricked my Desire last night.
To make things worse I was only able to apply the SD Card workaround via fastboot.
After flashing the update.zip from the modaco fix I instantly went back to the stock rom using the fastboot RUU process, without actually checking if it solved all the problems...
I know I had it coming...
Before I ship the phone out for repairs - maybe someone here knows if there is a chance to unbrick without root (nor having HBOOT version that allows to use any other method of rooting other than Unrevoked)
Code:
HBOOT 0.93
European 2.10.405 OTA
Thanks in advance

a more detailed description would help:
does your phone boot?
do you have running clockworkmod recovery?
did you do a nandroid backup before touching the system?
what modaco fix? give a link.
did you use unrevoked? thats the default root tool nowadays.
can you go to hboot/fastboot when pressing vol down while pressing power on?

Use a goldcard, it will enable you to put an unrooted Rom there. It's always a good reset option.
Sent from my HTC Desire using XDA App

mad-murdock said:
a more detailed description would help:
does your phone boot?
do you have running clockworkmod recovery?
did you do a nandroid backup before touching the system?
what modaco fix? give a link.
did you use unrevoked? thats the default root tool nowadays.
can you go to hboot/fastboot when pressing vol down while pressing power on?
Click to expand...
Click to collapse
Hi,
- the phone boots ok - It has most of the symptoms from All you need to know about USB-Bricks thread, the SD card started to work after issuing:
Code:
fastboot oem enableqxdm 0
This is the output from the fastboot oem boot command
Code:
$ fastboot-mac oem boot
... INFOsetup_tag addr=0xA0000100 cmdline add=0x8E07F9F0
INFOTAG:Ramdisk OK
INFOTAG:smi ok, size = 0
INFOTAG:hwid 0x0
INFOTAG:skuid 0x21F04
INFOTAG:hero panel = 0x0
INFOTAG:engineerid = 0x0
INFOMCP dual-die
INFOMCP dual-die
INFOTAG:mono-die = 0x0
INFODevice CID is not super CID
INFOCID is HTC__032
INFOsetting->cid::HTC__032
INFOserial number: HT057PL01634
INFOcommandline from head: no_console_suspend=1
INFOcommand line length =430
INFOactive commandline: board_bravo.disable_uart3=1 board_bravo.
INFOusb_h2w_sw=1 board_bravo.disable_sdcard=0 diag.enabled=0 boa
INFOrd_bravo.debug_uart=0 smisize=0 userdata_sel=0 androidboot.e
INFOmmc=false androidboot.baseband=5.09.05.30_2 androidboot.cid
INFO=HTC__032 androidboot.carrier=HTC-EastEurope androidboot.mid
INFO=PB9920000 androidboot.keycaps=qwerty androidboot.mode=norma
INFOl androidboot.serialno=HT057PL01634 androidboot.bootloader=0
INFO.93.0001 no_console_suspend=1
INFOaARM_Partion[0].name=misc
INFOaARM_Partion[1].name=recovery
INFOaARM_Partion[2].name=boot
INFOaARM_Partion[3].name=system
INFOaARM_Partion[4].name=cache
INFOaARM_Partion[5].name=userdata
INFOpartition number=6
INFOValid partition num=6
INFOmpu_nand_acpu_rw A1E 1000
INFOjump_to_kernel: machine_id(2457), tags_addr(0x20000100), ker
INFOnel_addr(0x20008000)
INFO-------------------hboot boot time:697447 msec
ERROR: usb_read failed with status e00002ed
FAILED (status read failed (No such file or directory))
- Sadly, I made a complete reflash using
Code:
fastboot rebootRUU;
fastboot flash zip rom.zip
... so no Clockwork recovery anymore
- Yes I have a nandroid backup but no means to put it back on the phone - the nandroid backup contains exactly the same rom I have now - just rooted
- As for the modaco fix I'm a new user I can't post external links, but it's the first link in this thread
- I did use the lastest Unrevoked3 (3.21) to root the phone
- I can use hboot / fastboot without problems but it's the stock 0.93.001 S-ON version.
Thanks

geejayoh said:
Use a goldcard, it will enable you to put an unrooted Rom there. It's always a good reset option.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
I have an unbranded Desire so no need to use a GoldCard if I'm not mistaken.
Anyway if memory serves me right using the GoldCard / HBOOT / PB99IMG flashing, won't allow me neither to downgrade, nor to flash an unsigned rom.
An unsigned rooted rom or HBOOT downgraded do 0.80 could help me fix my problem - but with HBOOT 0.93 - dowgrading doesn't seem to be an option. I get a "Main Version Older" error when trying to downgrade, and flashing an unsigned rom is a no-no for all stock bootloaders as far as I know (I tried both HBOOT and recovery, both as expected fail at signature verification).
But thanks anyway

Whats the exact problem now? You restored rom.zip via ruu. So you got a stock firmware with stock hboot and stock recovery which can be unrevoked again?
Seams i am missing a detail ^^
Sent from my HTC Desire using Tapatalk

mad-murdock said:
Whats the exact problem now? You restored rom.zip via ruu. So you got a stock firmware with stock hboot and stock recovery which can be unrevoked again?
Seams i am missing a detail ^^
Sent from my HTC Desire using Tapatalk
Click to expand...
Click to collapse
It seems to me you're missing the main issue not a detail
The main issue being a condition called "USB Brick" (well that's only half the truth, most of the main issue is me acting without thinking )
Please read the info thread on USB Bricks here, since you have a HTC Desire - it concerns you too. Good idea to backup the MISC partition if you plan to flash the phone again
Anyyyyway - as for my case:
I screwed up, flashed the stock firmware BEFORE checking if the applied USB brick fix solved my problems. So it's true I have stock firmware, stock hboot, stock recovery - but I also have no way to connect the phone to a computer via USB - because the flashing process updates the following partitions: system, recovery, boot but not the misc partition which is now corrupt, and its corruption is the cause of the USB brick...
USB Brick = no usb connection at all while booted to the Android OS
No usb connection = no usb debug mode
no usb debug mode = no unrevoked
The usb still works from HBOOT / FASTBOOT, so If you know of a way to start Unrevoked while the phone is in HBOOT / FASTBOOT - please enlighten me, because I couldn't do It.
Unrevoked only recognized the phone while it was in USB Debug mode, which it cannot enter now because of the USB Brick. When I connect the phone while in Fastboot USB mode or HBOOT USB mode Unrevoked just states "Waiting for device".
I don't think I am able to put this in any clearer way
Thanks

Ouch. Now i see. Didnt understand you at the start. Well, i had an usb brick myself after wiping the system. At least i had a modded hboot and recovery.
Now to your problem. Wierd situation, really. But if i remember right, flashing one of the ruu.Exe files should also fix misc. Then you have stock firmware with usb working. Cant link here in tapatalk, but those ruu file are a sticky in desire dev forum... tell me, if it worked...
Sent from my HTC Desire using Tapatalk

Solved!
I was able to successfully unbrick the phone
It wouldn't be possible without rageagainstthecage, All the people writing the tutorials on USB unbricking, QuickSSHd and the Terminal Emulator app. Thanks to the authors.
I'll try to sum things up for anyone interested:
The problem
Because of acting without thinking I ended up with a stock unrooted rom and a partial USB brick. To make things worse I accepted the OTA update, installing the oh so loved HBOOT 0.93.100 S-ON.
The Solution
After some reading about rageagainstthecage, PoC code on which the Unrevoked rooting solution is based I tried to run the exploit directly on the phone.
Without having access to adb I wasn't able to find a place to put the executable, as the /data/ directory is writable only by the system user and the system group, and most tutorials suggest to place the exploit somewhere inside that directory. But all the tutorials I found mentioned using adb push to put the file on the phone, which probably operates on the phone as system:system as it is capable of writing to the /data dir. I wasn't able to write there as I had the id of the Terminal Application
Since apps storing data seem to store er... data in /data/data I had a little breakthru. Becaue I couldn't find a free telnet solution I purchased the QuickSSHd from Android Market.
This allowed me to have write access to /data/data/<package_name>/home where I created a world readable (755) directory. I scp'd the rageagaintthecage, modified misc partition image and flash_image binary to the phones filesystem, and made them executable. I could've used the Terminal Apps <data dir>/shared_prefs directory (which would be a $$$ free solution, as the ssh was not free, but not expensive either) but I'm lazy and doing stuff from a PC keyboard is easier than from a touch keyboard.
Running the exploit and flash_image from inside a ssh session seemed like a good idea but the sshd died after running the exploit, and didn't want to start untill the phone was rebooted. So next time I just started the sshd and done the rest of the stuff from a Terminal Emulator (After preparing scripts for ease of execution, and dropboxing the paths for copy paste ). After running the exploit the Terminal Emulator app stopted working correctly (as expected) but after force closing it and running it again I was greeted with a # prompt
I flashed the misc partition with an image modified with my phones CID, rebooted and voila! USB brick gone
Now I just have to beat one thing into my empty head (in the manner of "stop, drop, and roll" firedrill mantra). STOP, READ and THINK - before flashing
g'night

mad-murdock said:
Ouch. Now i see. Didnt understand you at the start. Well, i had an usb brick myself after wiping the system. At least i had a modded hboot and recovery.
Now to your problem. Wierd situation, really. But if i remember right, flashing one of the ruu.Exe files should also fix misc. Then you have stock firmware with usb working. Cant link here in tapatalk, but those ruu file are a sticky in desire dev forum... tell me, if it worked...
Sent from my HTC Desire using Tapatalk
Click to expand...
Click to collapse
Hi,
Just fyi because I was able to resolve my problem in the meantime.
Because I was foolish enough to install the OTA upgrade before it occured to me that the USB is not working, installing any RRU either in the official way (by running the exe) or by extracting the rom.zip from inside of the exe didn't work. The latest RRU was older then the firmware with OTA upgrade on my phone, and it didn't seem to allow me to downgrade.
ZIP way = Main Version Older error
EXE way = You have to install the correct firmware version or some other bla bla bla
Anyway I took a look inside the rom.zip extracted from the RRU.exe - there are img files of every partition, radio and hboot but no misc.
But thanks again anyway

How did you solve your tricky situation then?
Sent from my HTC Desire using Tapatalk

quanchi said:
I was able to successfully unbrick the phone
It wouldn't be possible without rageagainstthecage, All the people writing the tutorials on USB unbricking, QuickSSHd and the Terminal Emulator app. Thanks to the authors.
I'll try to sum things up for anyone interested:
The problem
Because of acting without thinking I ended up with a stock unrooted rom and a partial USB brick. To make things worse I accepted the OTA update, installing the oh so loved HBOOT 0.93.100 S-ON.
The Solution
After some reading about rageagainstthecage, PoC code on which the Unrevoked rooting solution is based I tried to run the exploit directly on the phone.
Without having access to adb I wasn't able to find a place to put the executable, as the /data/ directory is writable only by the system user and the system group, and most tutorials suggest to place the exploit somewhere inside that directory. But all the tutorials I found mentioned using adb push to put the file on the phone, which probably operates on the phone as system:system as it is capable of writing to the /data dir. I wasn't able to write there as I had the id of the Terminal Application
Since apps storing data seem to store er... data in /data/data I had a little breakthru. Becaue I couldn't find a free telnet solution I purchased the QuickSSHd from Android Market.
This allowed me to have write access to /data/data/<package_name>/home where I created a world readable (755) directory. I scp'd the rageagaintthecage, modified misc partition image and flash_image binary to the phones filesystem, and made them executable. I could've used the Terminal Apps <data dir>/shared_prefs directory (which would be a $$$ free solution, as the ssh was not free, but not expensive either) but I'm lazy and doing stuff from a PC keyboard is easier than from a touch keyboard.
Running the exploit and flash_image from inside a ssh session seemed like a good idea but the sshd died after running the exploit, and didn't want to start untill the phone was rebooted. So next time I just started the sshd and done the rest of the stuff from a Terminal Emulator (After preparing scripts for ease of execution, and dropboxing the paths for copy paste ). After running the exploit the Terminal Emulator app stopted working correctly (as expected) but after force closing it and running it again I was greeted with a # prompt
I flashed the misc partition with an image modified with my phones CID, rebooted and voila! USB brick gone
Now I just have to beat one thing into my empty head (in the manner of "stop, drop, and roll" firedrill mantra). STOP, READ and THINK - before flashing
g'night
Click to expand...
Click to collapse
Any chance of adding some links or actual information?
I've got exactly the same problem and you seem to have the solution.
Any chance of sharing?

Usb Brick !? This is an OLD thing I have this some Months ago. Never heard of someone who got it again! YOU did something wrong ;-)

Sure, he did something wrong.I managed this, too, when playing with a partition tool not designed for my system. Misc partition damaged, so a nice usb brick...
About the requested links : just use forum search for usb brick. First hit is your sticky solution
Sent from my S-OFF'd brain using teh internetz

CyberTech71 said:
Any chance of adding some links or actual information?
I've got exactly the same problem and you seem to have the solution.
Any chance of sharing?
Click to expand...
Click to collapse
I couldn't post external links, forum limitation for new users... Now I see I can so:
This is a specific situation - usb brick and totally stock rom, recovery and hboot. It's not required for people who have a modified recovery and a rooted rom. It's easy like 1-2-3.
Before doing anything else enable the Debug Mode in the Applications / Dev menu
1. Download the rageagainstthecage exploit from the authors site:
http://c-skills.blogspot.com/2010/08/please-hold-line.html
2. Download the flash_image and misc (mtd0.img) partition image from this thread.
http://forum.xda-developers.com/showthread.php?t=691639&highlight=usb+brick
Modify the mtd0.img according to your phones CID (how to get the CID also explained in the thread)
2. Download Android Terminal Emulator from the Market
3. Copy the exploit binary (rageagainstthecage-arm5.bin), the flash_image and modifed mtd0.img to the sdcard via an external card reader
4. Start the Terminal
5. Copy the files to the Terminal app data directory (the only place on the data partition you will have write access while running the Terminal), and make the binaries executable
Code:
cat /sdcard/rageagainstthecage-arm5.bin > /data/data/jackpal.androidterm/shared_prefs/rageagainstthecage-arm5.bin
cat /sdcard/flash_image > /data/data/jackpal.androidterm/shared_prefs/flash_image
cat /sdcard/mtd0.img > /data/data/jackpal.androidterm/shared_prefs/mtd0.img
cd /data/data/jackpal.androidterm/shared_prefs/
chmod 755 rageagainstthecage-arm5.bin flash_image
6. Run the exploit
Code:
/data/data/jackpal.androidterm/shared_prefs/rageagainstthecage-arm5.bin
After the exploit exits/finishes there should be a short system freeze, followed by inablity to issue any command from the terminal (don't worry). Exit the Terminal by long pressing HOME and force close the Terminal app from the Application Manager
7. Start the terminal again, a root prompt should be visible
8. Flash the misc partition
Code:
cd /data/data/jackpal.androidterm/shared_prefs
./flash_image misc mtd0.img
9. Reboot
Done and done
Enjoy
PS. I suck at writing tutorials, but if the details are still hazy for you after reading this - better to service the phone, because you might end up bricking the device totally - cheers

quanchi said:
I was able to successfully unbrick the phone
It wouldn't be possible without rageagainstthecage, All the people writing the tutorials on USB unbricking, QuickSSHd and the Terminal Emulator app. Thanks to the authors.
I'll try to sum things up for anyone interested:
The problem
Because of acting without thinking I ended up with a stock unrooted rom and a partial USB brick. To make things worse I accepted the OTA update, installing the oh so loved HBOOT 0.93.100 S-ON.
The Solution
After some reading about rageagainstthecage, PoC code on which the Unrevoked rooting solution is based I tried to run the exploit directly on the phone.
Without having access to adb I wasn't able to find a place to put the executable, as the /data/ directory is writable only by the system user and the system group, and most tutorials suggest to place the exploit somewhere inside that directory. But all the tutorials I found mentioned using adb push to put the file on the phone, which probably operates on the phone as system:system as it is capable of writing to the /data dir. I wasn't able to write there as I had the id of the Terminal Application
Since apps storing data seem to store er... data in /data/data I had a little breakthru. Becaue I couldn't find a free telnet solution I purchased the QuickSSHd from Android Market.
This allowed me to have write access to /data/data/<package_name>/home where I created a world readable (755) directory. I scp'd the rageagaintthecage, modified misc partition image and flash_image binary to the phones filesystem, and made them executable. I could've used the Terminal Apps <data dir>/shared_prefs directory (which would be a $$$ free solution, as the ssh was not free, but not expensive either) but I'm lazy and doing stuff from a PC keyboard is easier than from a touch keyboard.
Running the exploit and flash_image from inside a ssh session seemed like a good idea but the sshd died after running the exploit, and didn't want to start untill the phone was rebooted. So next time I just started the sshd and done the rest of the stuff from a Terminal Emulator (After preparing scripts for ease of execution, and dropboxing the paths for copy paste ). After running the exploit the Terminal Emulator app stopted working correctly (as expected) but after force closing it and running it again I was greeted with a # prompt
I flashed the misc partition with an image modified with my phones CID, rebooted and voila! USB brick gone
Now I just have to beat one thing into my empty head (in the manner of "stop, drop, and roll" firedrill mantra). STOP, READ and THINK - before flashing
g'night
Click to expand...
Click to collapse
Hello
in you problem with USB bricks for unrooted HTC desire
I have the seam problem
please explain it to me
I copy the flash_image and mtd0.img to
\data\data in my device I only need to flash them to restore my device
when I try this command in terminal Eliminator
/data/data/flash_image misc /data/data/mtd0.img
It show me
error writing misc permission denied
help me please

I can't believe it, mate, finally this tutorial solved my usb (and bluetooth, and fm radio, and...) problem!!!!!
My Desire is unrooted, I've tried so many solution in the last 3 months but they all were useless.
I was starting to pack my phone for sending it to HTC Service when... tataaaa, I found your topic. Is on your if my wonderful Android powered phone got back fully functional.
Really, thank you for sharing your solution with us.
===========;-D
Francalberto

francalberto said:
I can't believe it, mate, finally this tutorial solved my usb (and bluetooth, and fm radio, and...) problem!!!!!
My Desire is unrooted, I've tried so many solution in the last 3 months but they all were useless.
I was starting to pack my phone for sending it to HTC Service when... tataaaa, I found your topic. Is on your if my wonderful Android powered phone got back fully functional.
Really, thank you for sharing your solution with us.
===========;-D
Francalberto
Click to expand...
Click to collapse
Good for you
All the credit goes to the people responsible for the tools used, I just put some things together.
Cheers

thank you very much
I really appreciate you effort you helped me so much
you are a brilliant man
thank you

Flashb, is your problem solved now?
Swyped with my S-OFF'd brain using teh internetz

New to Evo. Questions on internals

Hey,
I'm new to the Evo platform, coming from the Samsung Moment. I was able to successfully flash my Moment over to MetroPCS (full data) and plan to do the same with QPST\QXDM. That is not what I come to ask about however.
I was doing some reading on the various rooting guides for the evo, and it's internal structure seems very different from the Moment. I have several questions that aren't fully explained by the rooting guides. If anyone could answer these it would be very appreciated.
1) What exactly is HBoot? Yes, it's the bootloader but is it a partition on the disk or is it stored in non-flashable ROM?
2) Assuming Hboot is a partition what would happen if I were to delete it entirely, or if I were to pull the battery during an update?
3) Can the Evo actually be perma-bricked?
I ask the above three questions because with the moment it is IMPOSSIBLE to permanently brick it. The moment had something known as Download mode. This was a special boot program stored in unflashable ROM that would allow one to reformat and\or flash a ROM to main flash memory. I have corrupted the **** out of the moment to where I was unable to get into recovery or anything, but I was able to ALWAYS reapply a ROM from download mode (Sometimes I had to do a PDA format in ODIN). Is HBOOT similar to this?
4) I hear of people bricking their 4G when flashing ROMS. Apparently they lose their RSA keys. Where are these keys physically stored?
5) Why can't one simply ask sprint to generate a new key pair?
6) What are these keys "bound to"? Why can't one just take someone else's RSA keys. The phone can be sold, so they are not tied to an account. The MEID can be changed so they are obviously not bound to the MEID
7) What exactly is NAND protection and how does it prevent one from writing to cretin partitions
8) Back to the topic of HBOOT, I've read some older threads where people complained about updating and members have stated theres no way to downgrade (as of that time). Why can't one simply delete HBOOT of the flash memory and write the older copy.
I would like to understand my phone's system better. Thanks for any assistance

Finally some thought provoking questions!!!!!
This thread might get you started
http://forum.xda-developers.com/showthread.php?t=694034

[Q] Obscure problem with rooting

Hi everyone
The following summarises my quest to root my recently acquired HTC Desire/Bravo:
Key info:
Android 2.2
HBOOT 0.93
Build 2.12.110.4 CL274424 release-keys
Radio 32.49.00.32U_5.11.05.27
Kernel 2.6.32.15-gd96f2c0 - [email protected] #1
SIM Unlocked
T-Mobile branded
UK
I first try using Unrevoked. After a promising start, I get the 'Validation error: backup CID missing' message, for which I can find no solution for on the internet. I tried using a different computer booting a clean Slax image, wiping the phone, and using four different versions (3.32, 3.31, 3.21, 3.14) to no avail.
Next I try using the GoldCard method. I find a suitable memory card, and get cracking using this method: http://theunlockr.com/2010/03/10/how-to-create-a-goldcard/
I manage to get my CID: 0353445355303147804029a554007c08
However, it turns out that the website used to generate the goldcard boot sector is not working ('Page not found'). It appears to have been working until only recently.
No matter, I found a standalone solution here: http://www.mygsmforum.com/f15/all-htc-goldcard-generator-perl-script-free-standalone-unlimited-7255/
I grabbed the file, and I managed to get it working by compiling both of the perl modules it needs. I typed in the command:
perl ./goldcardgenerator.pl -d sd80.img -p magic=xxx -p cardid=0080c700455a9204087413035535443530
You might notice I haven't specified the security level or the key set, but I can assure you that not a byte of the output file changes when I use the defaults specified in the readme.
So I have a convincing looking header. I do as the instructions say and copy the first 0x170 bytes to the beginning of the card. It reads and writes to the FAT32 partition fine, so I assume the card's good. So I copy over a rom I got here: http://forum.xda-developers.com/showthread.php?t=741775
Rename it update.zip and boot into recovery. I try to flash, and I get the 'E:Signature verification failed' error, so obviously the goldcard's not working.
My contention is that when I made the image, I missed one or more vital parameters, keys, seclevel, cid etc. However I really have no idea where to start looking for them, since they're so obscure.
Help with anything to do with this (Including getting Unrevoked to work) would be much appreciated! Honestly, I've spent the entire day trying to get this to work.
Thanks,
Hamish Milne

screw unrevoked.
Go to www.revolutionary.io and follow the instructions
Go to my guide and flash recovery
Backup your ROM, and then push superuser with adb.
Done. Rooted.
All resources you need are there. Tutorials, links etc.

Yep, unrEVOked is obsolete. This should be mentioned in sticky thread.

Truly excellent! Thank you!
Flashed the Clockwork mod, and replaced the bootloader without breaking the OS.
However, I still don't have root. I know I could flash the ROM, but I'd rather not wipe my data again. How exactly would I go about 'flashing superuser with adb'? (I have the adb installed btw)
EDIT: Wait, found it

actually, i had hboot 1.06 on my stock cdma desire, and i had to use revolutionary's tool before running unrevoked. i tried 3 different desires with unrevoked before i discovered revolutionary, and after it unrevoked did its job just fine.

[CONCLUSIONS] S-OFF with Unlock/Lock Bootloader

Hi everyone!
What we need:
A kernel hacker!
Why?
Because of this:​
no.human.being said:
Yep this is great. This routine will definitely play a key part for our further investigation. The plan I have is the following ...
I'd like to dump the device's Flash memory (physically, via JTAG), disassemble its contents (e. g. with objdump, as I'm not familiar with IDA and it actually looks quite "advanced") and find where the ARM starts execution. This is probably a fixed address, might find it in the processor's datasheets. There are no datasheets available for the MSM7227, however, it is a replica of the ARM1136EJS for which there are no datasheets either, but there are extensive datasheets for the ARM1136JS, which is probably similar. Just search for the document "ARM DDI 0211K" on your favourite search engine. It's very extensive, so there's really not much that should be "undocumented" about this processor.
Once we know where execution starts, we should try to analyze the "initialization routine" of the processor's firmware, which initializes the uC, loads the vendor specific firmware (Radio, HBOOT) into memory and starts execution. This routine will load the firmware from persistent (Flash) into volatile (RAM) memory and it will probably "pull together" the RAM contents from different parts of the Flash. (Might it already set up some page tables for the MMU at this point?) This is probably why you don't see the "jump table" in the HBOOT image. It's probably not part of HBOOT at all, but from a section that just gets "loaded near HBOOT" into volatile memory during the controller's initialization. (Might it be part of the Radio?)
When we trace the code further through the "jump table" (I'd love to do this on the actual physical device so I really hope that the processor supports single-stepping), we'll hopefully find the actual physical address of the secu_flag. As soon as we have it, the most obvious thing to do is just flick it via JTAG and check whether the device is S-OFF afterwards.
Finally, when we know where the secu_flag resides on the WFS (which means we know its physical address), we can try to find a way to access it from within Android. There's almost certainly some more protection in place, possibly protection via MMU, so we might have to modify Android to set up different page tables during boot process, but once we got that far, this should not be what stops us.
If you have any questions/suggestions, just feel free to ask/propose them.
At least the...
Code:
fastboot -c "mtdparts=msm_nand:0x..." boot recovery.img
... works and it does not require S-OFF! However, the ...
Code:
fastboot oem listpartition
... fails ...
Code:
... INFO[ERR] Command error !!! OKAY [ 0.000s] finished. total time: 0.000s
So yes, we can change the mapping of memory to mtd devices, but we cannot find out how the partitions are laid out on the device (at least not via fastboot, can't we ask the operating system somehow?).
...
Now stop a moment and take a deep breath!
...
Wait! What have we just found out? We can load an arbitrary OS image (kernel + initrd) via fastboot into the device's RAM and execute it! This sounds like the key to total awesomeness, doesn't it? Can't we build an OS image that has just one purpose which is S-OFFing the device (either by asking the Radio to do it, remember it is OUR custom kernel we're executing here so WE can talk to the Radio, or by mapping the memory the way we need it, then doing it directly)?
This may turn out to be easier than we expected it to be. Any kernel hackers here that could aid us in building a kernel that maps the entire memory of the device (this will include the Radio where secu_flag resides) and sticking an initrd to it that does the S-OFF? Of course we'll still need to find the flag in memory, but at least we now have a concrete plan how we can map the memory in. This will also enable us to build a very "user friendly" utility for S-OFF. No more zergRush, no more privilege escalation. The S-OFF utility is a self-contained OS image. You boot it, it does all the work and reboots the phone when done. How cool is that?
Click to expand...
Click to collapse
​
You probably still remember me for my famous "S-OFF without XTC-Clip conclusions" thread. We all know that now, HTC has given us the privilege of unlocking our Bootloaders using HTC-Dev. This allows us to Root and flash Custom ROMS, and all that; so we're all happy with that. But there are others out there, like me, who want to take even more advantage of this, and still get S-OFF, just like before. Now, we have a deeper understanding of our WFSs, so S-OFF is now much, much easier. If we get S-OFF, then we will have many more privileges on our phones.
With S-OFF, we can get:
Our warranties back
The ability to resize our system partitions.
The ability to flash different HBOOTs.
And many other things!
Be sure to visit *se-nsei.'s campaign, click here!
no.human.being posts his latest findings there.
My thoughts on this is:
from another thread, I've seen that when the HTC-Dev RUU was flashing HBOOT, it froze, but it still managed to flash rom_01.zip. This means, that when flashing HBOOT, the phone needs to be made S-OFF, then, when rom_02.zip is flashed, it finishes flashing HBOOT, and finally changes the security flag on, again.
So, I did some experimenting of my own. I flashed rom_01.zip using many methods, but all my attempts miserably fail. Why? Because the file is not signed properly. This got me thinking, if it's an HTC ROM, then why won't it flash?!?! Probably, because HTC made it in such a way, that the phone rejects it, or it won't work properly without the other files, that maybe reside in the RUU.
Maybe, someone can look into it, and find the function that S-OFFs the phone.
Perhaps, it might flash if it's on a Goldcard, so we'll have to do some more experimenting.
There is a possibility though, that using no.human.being's C code that he made earlier, we could S-OFF the phone, as it will be able to access more "sections" of the phone. We'll just have to compile/convert it and run/flash it.
Like before, if you have any suggestions, please tell me (by posting in this thread, please only PM if you think it's a very close solution, or if it's very important)
Good Luck everyone!

Isn't anyone going to post here!
no.human.being, eoghan2t7, are you there!?!

I think you might want to try extracting the img file and use fastboot flash radio radio.img.

yjwong said:
I think you might want to try extracting the img file and use fastboot flash radio radio.img.
Click to expand...
Click to collapse
Thanks, I have tried this though, but I didn't rename it to radio.img. Perhaps I'll ry this if I got some time (I'm still in High School, and they give me way to much homework. They are so annoying!)

Ideas! Anyone!

Is there a similar way to boot into ENG-HBOOT(unsecured)
like fastboot -c "mtdparts=msm_nand:0x..." boot unsecuredhboot.img ?
Then if unsecuredhboot.img wil be on sdcard we have possibility to flash s-offed hboot.

Somebody help this guy....... This is not my level. I'm a bit lower. I doubt it will work though.
Sent from my HTC Wildfire S A510e using XDA

slavislavi said:
Is there a similar way to boot into ENG-HBOOT(unsecured)
like fastboot -c "mtdparts=msm_nand:0x..." boot unsecuredhboot.img ?
Then if unsecuredhboot.img wil be on sdcard we have possibility to flash s-offed hboot.
Click to expand...
Click to collapse
No, that won't work. The "boot" command takes an Android image, which consists of a kernel, an initrd and a special header. The header tells the bootloader of the phone where to load the kernel in memory, etc. It won't be present in an ENG-HBOOT image, so the phone's bootloader won't be able to boot it.
Furthermore, HBOOT expects the controller to be "uninitialized" and will then initialize it. When the kernel is executed via Fastboot, the controller has already been initialized by HBOOT, after all that's the actual purpose of a bootloader. The ENG-HBOOT probably won't behave correctly if it finds the controller already initialized by a "lower level" bootloader.
Last but not least, the "mtdparts=..." is a kernel parameter. Basically it's just a string (character sequence) that is passed to the kernel. What the kernel does with it is principally the kernel's thing. It's just that "mtdparts=..." can be used on an embedded Linux kernel to change the partition mapping. I doubt that HBOOT can take parameters, since it's not designed to be loaded by anything else (apart from possibly an extremely low-level processor-specific firmware that most likely won't have a facility for passing parameters).