Related
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
Hello guys,
Although we now have one-click programs that root our Evos, I am simply the type of person/geek that needs to know the "In's and Out's" and the "why's and how's" of how something works.
I rooted my Evo back in June of 2010 when it was launched, using the then complicated and long process in adb shell. Although I did not stumble in the process at all, I did not know what was really involved and simply followed directions.
With that said:
One of the many Files (flash_image), (mtd-eng.img), (PC36IMG), (recovery.img), needed to root my Evo was the "mtd-eng.img" file.
Can anyone please explain what this file is and it's purpose.
Evidently nobody is going to answer this. I need to know this now too, that is why I bumped this dust bunny. I can't find much information on the system files and mounting points of the partitions. Specifically, mmcblk0p2. Can anyone explain to me any of this? Including what the mtd-eng img file is and what it does?
TheEvoNoob said:
Evidently nobody is going to answer this. I need to know this now too, that is why I bumped this dust bunny. I can't find much information on the system files and mounting points of the partitions. Specifically, mmcblk0p2. Can anyone explain to me any of this? Including what the mtd-eng img file is and what it does?
Click to expand...
Click to collapse
Some one else might know about the mmcblk0p2 block.
The best way to think of the mtd-eng.img is as follows:
The mtd-eng.img is an image of the phone's misc partition as it was on the Evo's initial pre-engineering software state around the time of it's release.
Everytime you run a RUU or flash anything, the misc partition is updated, in particular with the android.txt file. It updates the RUU number (3.70.651.1, 5.07.651.6, etc.) for the misc partition. This, the misc partition, is one of the places where the phone looks to determine whether the phone will accept or reject you trying to flash a RUU when the phone is S-ON. The phone is designed to reject any RUU number that is below that number that the misc partition is reading. That is why you cannot normally downgrade a S-ON phone, because the Software state that you are on, which is being read by the misc partition is greater than the software number of the RUU which you are attempting to flash (downgrade).
The mtd-eng.img is an image of the misc partition at its earliest state, with the lowest RUU number there is. All other RUU numbers are currently greater than this number and not less than, so this is why you need to flash this file if you are trying to downgrade a S-ON phone's software version. The software number which is being read by the misc partion after flashing the mtd-eng.img file is less than all the RUUs software numbers that exist for the Evo. The effect after flashing the mtd-eng.img file and then running a RUU is that you are actually tricking the phone into thinking that it is upgrading, which it is more than willing to do.
Sent from my SAMSUNG-SGH-I747 using xda premium
shortydoggg said:
Some one else might know about the mmcblk0p2 block.
The best way to think of the mtd-eng.img is as follows:
The mtd-eng.img is an image of the phone's misc partition as it was on the Evo's initial pre-engineering software state around the time of it's release.
Everytime you run a RUU or flash anything, the misc partition is updated, in particular with the android.txt file. It updates the RUU number (3.70.651.1, 5.07.651.6, etc.) for the misc partition. This, the misc partition, is one of the places where the phone looks to determine whether the phone will accept or reject you trying to flash a RUU when the phone is S-ON. The phone is designed to reject any RUU number that is below that number that the misc partition is reading. That is why you cannot normally downgrade a S-ON phone, because the Software state that you are on, which is being read by the misc partition is greater than the software number of the RUU which you are attempting to flash (downgrade).
The mtd-eng.img is an image of the misc partition at its earliest state, with the lowest RUU number there is. All other RUU numbers are currently greater than this number and not less than, so this is why you need to flash this file if you are trying to downgrade a S-ON phone's software version. The software number which is being read by the misc partion after flashing the mtd-eng.img file is less than all the RUUs software numbers that exist for the Evo. The effect after flashing the mtd-eng.img file and then running a RUU is that you are actually tricking the phone into thinking that it is upgrading, which it is more than willing to do.
Sent from my SAMSUNG-SGH-I747 using xda premium
Click to expand...
Click to collapse
I had Hboot 2.18 with the latest update, 5.07.651.6. When I first rooted it was hard to even find info for the newest system update. I tried every PC36IMG that I could find. All were rejected. Now I know why. Man, this was pretty awesome info. Thank you for taking the time. You're awesome bro.
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
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).
Hello everyone,
First I will apologize if this information has already been posted / asked, however my searches on google and the forums did not exactly answer my question.
I would like to know how to make a full backup of the phone. What I mean is to have an img file for each partition.
For those who might quickly shout "Nandroid...", been there done that. That is actually what prompted me to start looking into this, when I read (after reflashing the phone) that CWM does not backup things like the radio (again, np, I have grabbed the original imgs from the excellent threads, but it made me want to be able to do it myself in the future).
I have seen the posts regarding backing up the EFS partition with ADB and that the method can be applied to copy of the of the partitions, however it requires root access on the phone.
It seems odd to me however that with a tool like fastboot, that we can not back up the entire phone when in this state. The only thing I can think of as to why not, is that the fastboot mode only allows access to certain partitions w/ full permissions (read/write), or it only mounts certain partitions thus making the other ones unaccessible.
I would prefer to backup the phone without rooting it if possible. I am not opposed to the idea of rooting, however I have not really read up on it. As a linux user, I have np with the idea of it and honestly would have loved it if Android had a similar user structure right out of the box. My concern is (and possibly unfounded) that gaining root access could leave security holes in the OS to be exploited.
I also would prefer a "manual" method, not a fan of the idea of a toolkit.
Sorry if this is in the wrong section, however most of the search results yielded threads from this one.
Well, you could always just individually dump any partition with the dd command.
For example, to dump the entire contents of the radio partition to an .img file:
Code:
dd if="/dev/block/platform/omap/omap_hsmmc.0/by-name/radio" of="/sdcard/radio.img"
To restore that radio.img:
Code:
dd if="/sdcard/radio.img" of="/dev/block/platform/omap/omap_hsmmc.0/by-name/radio"
Simply run that through ADB Shell or a Terminal emulator from the Play Store. Of course, you will have to be rooted and have BusyBox installed. It's really not that difficult. Now you can unlock the bootloader without wiping /data, it's a simple matter of rooting and running the commands. If you wish, you can then unroot and relock the bootloader.
Mandatory Disclaimer: I've been awake for about thirty hours now, so you might want to get someone else to check over those commands before you give them a shot. Read up a bit on rooting in general, it will help you in the long run. Also, be careful. Just remember that if you accidentally flash a radio.img on the boot partition, or whatever, you're gonna have a bad time. I'm not responsible if you brick your phone, or if it explodes, or even if it boots into Apple's iOS.
Questions go in Q&A
Please read forum rules
Thread moved
Are you aware of a way to do it without rooting?
My boot loader is already unlocked and I have left it that way.
I have seen in fast boot documentation a "backup" command for fast boot. I am curious if it can be used to flash the radio, why can't it back it up.
Sent from my Galaxy Nexus using Tapatalk 2
Sorry, without root, this is the best you're going to get, and I'm pretty sure it's not what you're asking for:
http://forum.xda-developers.com/showthread.php?t=1420351