[DEV] Hboot 1.5 downgrade **UPDATE 3/14/2012** Success! Guide posted, READ CAREFULLY!

---

**This thread has been started to break away from the discussion started within the bounty thread in the EVO 3D general forum.**

For starters:
This thread will be for discussion purposes only, sharing of ideas, and methods tried or wanting tested in order to downgrade hboot 1.5. It has been agreed between the moderator and I that this thread will be for the purposes stated above only. It will NOT be for general questions on how to root, flash roms, or if its been cracked, etc. Once a solution... if a solution is found, it will properly be shared for everyone to use.

General purpose of this thread:
The people working on this do so in their free time, including myself. Sometimes we hit a wall or get stuck on trying one or two methods. It is helpful for others to suggest ideas or methods to help keep us from hitting a wall. We encourage anyone who has skills, ideas, or tools that can be of use to share their knowledge to keep progress in motion. Your help is greatly appreciated and any contributions will be recognized. Do not be afraid to post an idea or suggestion for fear of it being dismissed or ridiculed.

So please share what you have tried in order to downgrade, share your ideas, read what others have done and expound on them, offer suggestions and never be afraid to ask a question. No idea is dumb and can only help towards the overall goal.

I will post up shortly what methods I have tried and information I have gained and to help anyone I can. My knowledge and skill is limited, but two minds are greater than one, and so forth. I will try to keep this thread up to date for those parties interested in helping.

I will start by providing a few tools that are readily available on XDA (located at the bottom of this post). This is simply for convenience instead of searching all over. I will also update this post to include files, or links to files, that other users submit within this thread only. Just pm me the page they are on once you upload your file(s).

**Disclaimer - Following methods within this thread can or may result in a bricked phone. No one can be held responsible for any permanent damage you cause to your phone. It is your responsibility to know what you are doing and how to recover (if possible) from any modifications made. Please follow directions carefully while experimenting. If you do suddenly find yourself in a jam, people are willing to help, but do not clutter up the thread with single post's asking how to unbrick. Ask in another forum or send a PM asking for assistance.**

Here is a basic break down of what has recently been discussed in the bounty thread:
I have been working on finding a way to downgrade from hboot 1.5 to anything lower, so has user USSENTERNCC1701E. I know a few others have recently started to come up with some ideas and would like their continued thoughts and ideas.

Currently I have been looking over how wpthis power cycled the emmc to see if there is any way to modify it or the files it exploited to work once again. I have also been successful in getting the fre3vo method for temp root to work, but only once, I have not been able to duplicate what I did. Not that it matters much since ZergRush still works as a temp root solution. I have had some minor success getting certain commands in busybox to overwrite certain protected files and not others. Some of the files change, some partially change, others simply revert back or do not allow any form of manipulation whatsoever. I have a theory to get the emmc to power cycle, but I know it is a long shot and probably will not work.

I hope others will join the effort, no matter your experience.

-Crack

(The tools below contain: fastboot.exe, fre3vo, su-3.0-alpha7, Superuser3-beta1.apk, wpthis, zergRush, PG86IMG_eng-hboot, EPST.apk, busybox1.19, busybox1.18, busybox1.17, psneuter, clockworkmod_recovery_4.0.14)

*New link for wpthis source code build 25 - https://github.com/scotty2/thunderbolt-root
*New attachment - wpthis pre-compiled source experimental build for EVO 3D

**Update** 2/22/2012
Here is a little information regarding what has been worked on and done to wpthis by user Unknownforce. If anyone has experience or knowledge to help continue this work, it would be apreciated. You can find this post on page 14.

Originally Posted by Unknownforce

Got past this finally... Did I mention how much I hate linux paths/libraries... ugh... Anyways... I got it to compile and run on the phone... which obviously produced the same results as before, but now that I can actually alter the code and re-compile easily, I can easily debug and test with this... So, I got past the first issue with the mismatch of the version numbers. I made the version numbers match and it gets past that, but it's still saying the same exec format error...

The newest dmesg that I'm getting is unknown relocation: 27, and after looking this up, it's trying to make a call to R_ARM_PLT32 to relocate some memory... This is supposed to be defined in the modules.c file in the kernel source (which I've altered the wpthis code to work and build off of the shooter kernel source) but I'm not sure where this is happening in the actual code. It's also not even in the modules.c so looks like I might have to make it relocate the memory differently...

But, basically, I have to just dig some more, still haven't gotten it to even get to the part where it does (or tries to do) the reset... still seems to be simple program execution errors rather than actual command processing on the phone...

***UPDATE 2/23/2012***
Here is one more update regarding the modification of wpthis being done by user Unknownforce. If anyone can help further testing, it would be apreciated. You can find this on page 15 of the thread.

Originally Posted by Unknownforce

Got this a lot farther, Overlapped the code from the first source code you gave me onto the tbolt one that's posted on that git, and it compiled no problem, no more Exec Format Error, it loads the module properly now... but still hit a brick wall...

Here's the dmesg output:

[ 9588.488818] wpthis: Build: 47
[ 9588.489429] wpthis: block_dev: 0xcfdf5c58 (mmcblk0)
[ 9588.489947] wpthis: card_dev: 0xcfdf5808 (mmc0:0001)
[ 9588.490680] wpthis: host_dev: 0xcf152808 (mmc0)
[ 9588.491168] wpthis: sdcc_dev: 0xc0764ab8 (msm_sdcc.1)
[ 9588.491900] wpthis: platform_dev: 0xc07adbd8 (platform)
[ 9588.492389] wpthis: clk: 0xc07696d0 (48000000)
[ 9588.493121] wpthis: pclk: 0xc076a640 (0)
[ 9588.493640] wpthis: Allocating kernel buffer...
[ 9588.494189] wpthis: Testing...
[ 9588.495105] wpthis: RST_n is perminently enabled.
[ 9588.495624] wpthis: Block addressing mode, do not set block length.
[ 9588.496142] wpthis: Scanning...
[ 9588.500415] wpthis: Expected at 0x001017c0...
[ 9594.503423] wpthis: Scan complete. 0 hits found.

Here it's searching for(but can't find) a string of binary code in the mmc that matches the string ( 0x25, 0x00, 0xA5, 0x00, 0x03, 0x03, 0xE7, 0x03, 0x97, 0xE9, 0xF9, 0x00, 0x00, 0x00, 0x00, 0x00 ) I can only guess that that's our targeted "reset" command... or SOME kind of "starting point" to get to the rest of the MMC commands (like reset)

And here's the standard output from the adb shell:

Build: 47
Section header entry size: 40
Number of section headers: 36
Total section header table size: 1440
Section header file offset: 0x00016d04 (93444)
Section index for section name string table: 33
String table offset: 0x00016bb0 (93104)
Searching for .modinfo section...
 - Section[0]:
 - Section[1]: .text
 - Section[2]: .rel.text
 - Section[3]: .exit.text
 - Section[4]: .rel.exit.text
 - Section[5]: .init.text
 - Section[6]: .rel.init.text
 - Section[7]: .modinfo
 -- offset: 0x00001144 (4420)
 -- size: 0x000000c8 (200)
Kernel release: 2.6.35.13-g277012f
New .modinfo section size: 208
Loading module... OK.
Write protect disabled.
Searching for mmc_blk_issue_rq symbol...
 - Address: c035679c, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc0356000
Failed to open /dev/kmem: No such file or directory

The line directly above is definitely true, I don't see a /dev/kmem... which is odd, because that's virtual kernel memory... so either it's hidden or it's truly not there and is being stored elsewhere, but the dmesg stuff happens when the module loading happens... So it's processing the stuff you see in the dmesg before it's even showing the "write protect disabled" part, so the module is failing first, then the main app is also failing at the open of /dev/kmem...

Originally Posted by Crackanug

Here ya go, I ran into the exact same error you received. However, for ****s and gigs I put an empty or dummy file called "kmem" into that directory using the "dd" command. After running wpthis again, here is the output:

# /data/local/tmp/wpthis
/data/local/tmp/wpthis
Build: 47
Section header entry size: 40
Number of section headers: 36
Total section header table size: 1440
Section header file offset: 0x00016d04 (93444)
Section index for section name string table: 33
String table offset: 0x00016bb0 (93104)
Searching for .modinfo section...
 - Section[0]:
 - Section[1]: .text
 - Section[2]: .rel.text
 - Section[3]: .exit.text
 - Section[4]: .rel.exit.text
 - Section[5]: .init.text
 - Section[6]: .rel.init.text
 - Section[7]: .modinfo
 -- offset: 0x00001144 (4420)
 -- size: 0x000000c8 (200)
Kernel release: 2.6.35.13-g84f8edd
New .modinfo section size: 208
tmpBuffer = 1073811464 or ⌂ELF☺☺☺
tmpBuffer = 1073811464 or ⌂ELF☺☺☺
modInfoSection = 1073905188 or C
modInfoSection = 1073905188 or C
modInfoSection = 1073905188 or C
Loading module... OK.
Write protect disabled.
Searching for mmc_blk_issue_rq symbol...
 - Address: c0352e60, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc0352000
Kernel memory mapped to 0x40011000
Searching for brq filter...
[1]    Bus error                /data/local/tmp/wpthis
#

Let me know what I can do to help.

Sent from my blazing fast e3d using xda premium

this may sound stupid from the perspective of someone who knows more about this but has anyone tried to open a RUU and physically replase the hboot 1.50 files with a 1.40 for instance to see if running the ruu results in a 1.40 *downgrade* instead of upgrade for anyone else?

Originally Posted by aedon

this may sound stupid from the perspective of someone who knows more about this but has anyone tried to open a RUU and physically replase the hboot 1.50 files with a 1.40 for instance to see if running the ruu results in a 1.40 *downgrade* instead of upgrade for anyone else?

Breaks encryption I believe

Sent from my PC36100 using xda premium

Originally Posted by ckoadiyn

Breaks encryption I believe

Sent from my PC36100 using xda premium

But if someone were able to copy the encryption and then re-encrypt the RUU then that would be something. I'm not familiar with the coding of hboot, maybe some advanced rudimentary tricking would work. Such as changing the engineering hboot to read 1.6 with a packaged firmware update.

All that is just speculation, but isn't that how good things start?

Sent from my PG86100 using xda premium

Originally Posted by thedawn2009

But if someone were able to copy the encryption and then re-encrypt the RUU then that would be something. I'm not familiar with the coding of hboot, maybe some advanced rudimentary tricking would work. Such as changing the engineering hboot to read 1.6 with a packaged firmware update.

All that is just speculation, but isn't that how good things start?

Sent from my PG86100 using xda premium

True, but, I believe HTC uses 128 bit security keys, which could take somewhere in the hundreds of quadrillions of years to brute force hack. Were not likely to ever be able to copy their signature encryption.

Well in that case we need to get an inside dev with HTC haha. If I had a second device I'd be willing to pursue the method from the OP and try to get something going.

Sent from my PG86100 using xda premium

I was lucky enough to buy my phone through Sprint.com in late November and it came in with 1.30

I rooted it befor I even activated it LOL.
But I read hundreds of posts befor I.ordered my phone and was ready to never be rooted

Sent from my PG86100 using XDA App

Originally Posted by aedon

I was lucky enough to buy my phone through Sprint.com in late November and it came in with 1.30

I rooted it befor I even activated it LOL.
But I read hundreds of posts befor I.ordered my phone and was ready to never be rooted

Sent from my PG86100 using XDA App

I got mine in the store the Saturday after black Friday. Came with hboot 1.3, after I powered on the device it notified me of an update. Since having my OG EVO, I avoid OTA's like the plague

Sent from my PG86100 using xda premium

Wel as far as I've read ota won't affect.someone with s off already. But i can understand being casiouse about it.
But back to the issue,
How is the temp root working?

Originally Posted by thedawn2009

I got mine in the store the Saturday after black Friday. Came with hboot 1.3, after I powered on the device it notified me of an update. Since having my OG EVO, I avoid OTA's like the plague

Sent from my PG86100 using xda premium

Sent from my PG86100 using XDA App