FORUMS
Remove All Ads from XDA

[2017.01.14] S-OFF Firmware flashing (Fastboot) (Current: 4.19.617.1)

7,994 posts
Thanks Meter: 13,012
 
Post Reply Email Thread

This thread is meant for S-OFF phones. People not having their security OFF please refer to HTC RUU methods or “Stock Backup and OTA” method.


Read from top to bottom. No skipping of stuff or you will be confused.


Notice:
Files posted in this thread, which are not added to the first 4 posts should be considered source-material for my work. Flashing them means you know what you do. I only accept some limited responsibility for the files i add to the first 4 posts, because that means they flashed fine on my phone or on trusted peoples phones. However, I encourage people to send me files to work with. I am not able to search all over the Internet for source files myself. If you want some NoWipe or FullWipe firmware package added, send me the original untouched HTC base files required.

This thread serves the purpose of providing both Firmware files and reliable information for safe flashing. The main aspect of this thread is information gathering, processing and presentation for you, the user, to learn how to work with firmware and establish a solid base knowledge, so you can act more independently.

Many custom ROM Teams cannot cope with supporting the entire firmware upgrading procedure. This is something the user usually needs to figure out himself. So, I also see my task as a Team Venom member to provide the information necessary to enable you to learn all this. Of course this is not only suitable for Venom ROM’s.. Its pretty general stuff.

The safest way is still HTC’s RUU and OTA system, yet HTC is not providing RUU’s for the international version, so my files are the best option here. Carrier Version RUU’s can be accessed via HTC’s US Support Site. Select your device and then click on “News and Alerts” at the top of your device’s site - usually, there will be a RUU for Dev/Unlocked (617), Sprint (651), AT&T (502) and T-Mobile US (531). RUU’s are superior to other flashing methods because they carry a tested combination of partition images and the method itself is also known to work well. Also, RUU’s do always reassure you that there is a guaranteed and safe way to go back (psychological advantage).

If you happen to get access to an international RUU, share it with Alex, or me please. RUU’s are hosted on androidruu.com by Alex from Androidfilehost.com within a short time after being made available to him. Hit him up on Twitter with a link and ask him to add it or send it to me and i will! I have a direct channel to AFH and can see to it quickly.

I consider this rather important because androidruu.com is only providing a plattform - it is only as good as our community based additions. There is no secret RUU leaker behind it. It has what we have and organizes that in one place and provides an archive to old stuff. So, we are in charge of looking after it.

Other than that, we are mostly stuck with RUU components, usually OTA packages. OTA’s usually depend on a certain Firmware version to be already installed, OTA’s only update parts - they are “incremental”. If you happen to skip an update, you might not get all partitions updated correctly and end up with incompatible partitions, which might (worst case scenario) lead to a brick. I am trying to circumvent this problem with my FULL ZIP packages - with these you can safely jump from a very old firmware right up to the newest.

There are several methods to flash Firmware. The “SDCard Method” can be considered the fastest and most suitable for people without a PC. However, I mistrust it because I mistrust SDCards (much experience). Then there is the “RUU Method” which I have altered to a “FUU Method” in the past - It is simple and safe. However, it kept people from learning how to use fastboot and I don’t condone that anymore. For ROM support I need users who are capable to deal with Fastboot and ADB. So, this thread will deal with the “Fastboot Method”. The “FUU” can still be had and used from my Batch Tool in Post #4 though. I just won’t fuss around with it much.


ZIP Variants provided here:


Full Stock WIPE ZIPs:

Nothing removed - Everything stock! This type of zip also re-flashes the /data partition with HTC’s DZDATA files (meaning you loose everything on your internal SDCARD). Also replaces the Kernel, Ramdisk, recovery and Splash1 with latest stock images! The /system partition will not be touched. (Else this would be a RUU.zip). It also includes the “Apppreload.img” with all the carrier-bloatware.
Be sure to put a ROM onto your EXTERNAL SD before proceeding with a Full WIPE ZIP! Else you can also ADB push a ROM in recovery mode after fastboot reflashing a recovery. The newer TWRP variants also support a normal MTP connection and might support USB mass storage at a later stage. Phone will NOT boot without ROM reflash after using this!

NoWipe ZIPs:

This package is modified. This type of ZIP updates basic Firmware partitions, does not touch the /data partition, leaves kernel, splash and ramdisk (in order to support custom ROM’s modifying ramdisk) alone. The “Apppreload.img is removed, the bloatware partition will remain unchanged (to remove bloat permanently flash Apppreload.img from International/WWE/401). Recovery will be replaced with the current TWRP. Phone will boot normally after using this.


And what you won’t get here (fine print):
Since this is a Firmware Update Thread and not a ROM thread, you do NOT EVER get a ROM (a.k.a “System.img” or plain: “System” here. You understand and agree that you cannot have this from me. You also acknowledge that I cannot be blamed for your non-booting phone due to you not reading or not understanding this.
I will cover GSM PHONES ONLY - no cdma / sprint firmware except when i wish to do otherwise


Firmware ZIP Flash HowTo


Prerequisites:

You need ADB and Fastboot on your PC. To get ADB and Fastboot up and running I strongly suggest you use my “Batch Tool” setup, because it contains an updated htc_fastboot, which is 100% working with the M9 . This is important: the generic Google fastboot from SDK API Level 22 (latest at time of writing) is NOT FULLY COMPATIBLE. Update December 2015: seems there still are problems with Google Fastboot from API Level 24. You’ll still need the htc_fastboot.exe.


The ZIPs provided here are also repackaged, meaning not compatible with HTC Security, meaning you need S-OFF. Like stated at the top already. However, the method itself can be applied to HTC signed zips too, those could then be flashed to S-ON phones when certain conditions are met.

Step-By-Step:
1. If device is booted into Android, reboot into download mode by running:
Code:
adb reboot download
NOTICE: adb reboot download is new on the M9 for those who come from earlier HTC devices - zips can be flashed in download mode or RUUMode, both work. The on-screen status report is more detailed in download mode. This making it the preferred flashing mode for now.

1.a Or else, if your device is in a different state or you just prefer the button method:
Press Power for 15 seconds and hold VolUP at the same time, when the screen and charging LED go dark immediately slide your finger down to VolDown until you see the bootloader screen. Notice: First VolUp, then VolDown as soon as the screen goes dark (and you hear the windows connection sound if your phone is hooked up). Then use the VolUp and VolDown buttons to navigate to “Download Mode” and then press Power to confirm.

2. Now place the Firmware_xx.zip into your adb/fastboot folder (which will be "C:Androidcom" if you use my Batch Tool).

2a. This is optional - see my notice above:
Type
Code:
fastboot oem rebootRUU
3. Followed by:
Code:
fastboot flash zip Firmware_xx.zip
(replace "Firmware_xx.zip" with the name of your zip)

4. Now check the console output. It should approximately look like this log:

NOTICE: this flash log is taken from a FULL RUU flash on my M9, when you repeat this process, there will be several images missing in your flash, like first and foremost System.img won’t turn up in your log, obviously, since we do not include System. New is also that the checking routine is way more sophisticated and Controller Firmware for e.g. the touch panel or the Infra Red Remote and the like do NOT get flashed if the checks determine that they are already up-to-date. Images that do not get flashed show “BYPASSED”.

Quote:

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

F:WorkfolderAndroid Taskercom>htc_fastboot oem rebootRUU
... OKAY
Execution time is 34(ms)

F:WorkfolderAndroid Taskercom>htc_fastboot flash zip rom.zip
sending 'zip'... (198996 KB) OKAY
sending time = 8.892 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) GPT is up-to-dated. [17408]
(bootloader) Perform pre-update
FAIL90 hboot pre-update! please flush image again immediate
FAILED (remote: FAIL90 hboot pre-update! please flush image again immediate)
For "hboot-preupdate" response, restart the same procedure for device FA539YJ06951...

sending 'zip'... (198996 KB) OKAY
sending time = 10.564 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) GPT is up-to-dated. [17408]
(bootloader) Perform pre-update
(bootloader) start@21
(bootloader) aboot_signed.img@100%
(bootloader) rcdata.img@BYPASS
(bootloader) splash1.nb0@BYPASS
(bootloader) adsp.img@BYPASS
(bootloader) modem_st1.img@BYPASS
(bootloader) modem_st2.img@BYPASS
(bootloader) pg2fs_ship_signkey.img@BYPASS
(bootloader) apppreload.img@BYPASS
(bootloader) sensor_hub.img@BYPASS
(bootloader) tp_MXM11876.img@BYPASS
(bootloader) sdi.img@100%
(bootloader) sbl1-8994-1.img@100%
(bootloader) tp_SYN3351.img@BYPASS
(bootloader) pmic-8994-1.img@100%
(bootloader) cpe.img@BYPASS
(bootloader) rpm-8994-1.img@100%
(bootloader) tz-8994-1.img@100%
(bootloader) hyp-8994-1.img@100%
(bootloader) recovery_signed.img@BYPASS
(bootloader) hosd_signed.img@100%
(bootloader) radio.img@BYPASS
FAILFAIL90 hboot pre-update! please flush image again immediate
FAILED (remote: FAIL90 hboot pre-update! please flush image again immediate)
For "hboot-preupdate" response, restart the same procedure for device FA539YJ06951...

sending 'zip'... (198996 KB) OKAY
sending time = 10.604 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) GPT is up-to-dated. [17408]
FAIL90 hboot pre-update! please flush image again immediate
FAILED (remote: FAIL90 hboot pre-update! please flush image again immediate)
For "hboot-preupdate" response, restart the same procedure for device FA539YJ06951...

sending 'zip'... (198996 KB) OKAY
sending time = 7.242 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) GPT is up-to-dated. [17408]
(bootloader) start@21
(bootloader) aboot_signed.img@100%
(bootloader) rcdata.img@100%
(bootloader) splash1.nb0@100%
(bootloader) adsp.img@100%
(bootloader) modem_st1.img@100%
(bootloader) modem_st2.img@100%
(bootloader) pg2fs_ship_signkey.img@100%
(bootloader) apppreload.img@33%
(bootloader) apppreload.img@66%
(bootloader) apppreload.img@99%
(bootloader) apppreload.img@100%
(bootloader) sdi.img@100%
(bootloader) sbl1-8994-1.img@100%
(bootloader) pmic-8994-1.img@100%
(bootloader) cpe.img@100%
(bootloader) rpm-8994-1.img@100%
(bootloader) tz-8994-1.img@100%
(bootloader) hyp-8994-1.img@100%
(bootloader) recovery_signed.img@100%
(bootloader) sensor_hub.img@BYPASS
(bootloader) tp_MXM11876.img@BYPASS
(bootloader) tp_SYN3351.img@BYPASS
(bootloader) hosd_signed.img@100%
(bootloader) radio.img@100%
(bootloader) Update zip file OK
(bootloader) end@Done
OKAY

sending 'zip'... (463093 KB) OKAY
sending time = 28.801 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) start@1
(bootloader) system.img_00@12%
(bootloader) system.img_00@24%
(bootloader) system.img_00@37%
(bootloader) system.img_00@49%
(bootloader) system.img_00@62%
(bootloader) system.img_00@74%
(bootloader) system.img_00@86%
(bootloader) system.img_00@99%
(bootloader) system.img_00@100%
(bootloader) Update zip file OK
(bootloader) end@Done
OKAY

sending 'zip'... (431122 KB) OKAY
sending time = 26.431 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) start@1
(bootloader) system.img_01@12%
(bootloader) system.img_01@24%
(bootloader) system.img_01@36%
(bootloader) system.img_01@48%
(bootloader) system.img_01@60%
(bootloader) system.img_01@72%
(bootloader) system.img_01@84%
(bootloader) system.img_01@96%
(bootloader) system.img_01@100%
(bootloader) Update zip file OK
(bootloader) end@Done
OKAY

sending 'zip'... (490966 KB) OKAY
sending time = 30.226 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) start@1
(bootloader) system.img_02@12%
(bootloader) system.img_02@24%
(bootloader) system.img_02@36%
(bootloader) system.img_02@48%
(bootloader) system.img_02@60%
(bootloader) system.img_02@72%
(bootloader) system.img_02@84%
(bootloader) system.img_02@96%
(bootloader) system.img_02@100%
(bootloader) Update zip file OK
(bootloader) end@Done
OKAY

sending 'zip'... (390788 KB) OKAY
sending time = 24.510 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) start@1
(bootloader) system.img_03@12%
(bootloader) system.img_03@25%
(bootloader) system.img_03@38%
(bootloader) system.img_03@50%
(bootloader) system.img_03@63%
(bootloader) system.img_03@76%
(bootloader) system.img_03@88%
(bootloader) system.img_03@100%
(bootloader) Update zip file OK
(bootloader) end@Done
OKAY

sending 'zip'... (200995 KB) OKAY
sending time = 13.855 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) start@1
(bootloader) system.img_04@22%
(bootloader) system.img_04@44%
(bootloader) system.img_04@67%
(bootloader) system.img_04@89%
(bootloader) system.img_04@100%
(bootloader) Update zip file OK
(bootloader) end@Done
OKAY

sending 'zip'... (10850 KB) OKAY
sending time = 1.703 secs
writing 'zip'... (bootloader) HOSD CL#506785
(bootloader) start@2
(bootloader) dzdata_32g.img@100%
(bootloader) boot_signed.img@100%
(bootloader) Update zip file OK
(bootloader) end@Done
OKAY
Flash Zip Complete
Execution time is 398(s)

F:WorkfolderAndroid Taskercom>



Important: When flashing in RUUMode, the flash process halts at around 90% on phone screen! This is normal and a safety precaution! The last few percent is the reboot, which is NOT happening automatically, so you get a chance to check the console output to make sure it is safe to reboot! The bar will only fill up to 100% once you type:

Important: This is not valid for Download Mode flashes - those finish at 100% on phone screen and in console and ask you to hit Power to return to Download Mode screen.

IF you encounter any errors which are not “FAIL90”, have a look into Post #3 or ask in the thread! DO NOT REBOOT THE DEVICE!

5.
Code:
fastboot reboot-bootloader
or press Power to return to Download Mode screen - depending on the mode you used to flash the zip.




Recent additions
I usually don't provide untested zips, still, you flash at your own risk. Not everything was tested by myself. You're writing to critical parts of your phone. If anything goes wrong along the way, your phone might be bricked.
Quote:

  • BatchTool_M9_1.3.2
  • M9_4.14.617.6_Unlocked_FullStock
  • M9_4.14.617.6_Unlocked_TWRP3030_NoWipe
  • M9_4.19.617.1_Unlocked_FullStock
  • M9_4.19.617.1_Unlocked_TWRP3030_NoWipe
  • M9_3.38.502.12_ATT_NoWipe_TWRP3020
  • M9_3.38.502.12_ATT_FullStock
  • M9_3.35.111.14_TMODE_NoWipe_TWRP3002
  • M9_3.35.111.14_TMODE_FullStock
  • M9_3.36.709.3_Asia-TW_NoWipe_TWRP3002
  • M9_3.36.709.3_Asia-TW_FullStock



Credits

Thanks @Herwegan, who has been supporting my thread on the M7 for a good year and sadly decided to withdraw from XDA short.
ly after starting here with the M9. Also i would like to express my deepest gratitude to Team Venom, who aren't only good friends but also let me use their graphical stuff as base for my own stuff. Thank you!
Lately, the biggest props go out to @nkk71 and @captainthrowback because of their fantastic script that makes running bruutveal and ruuveal so much easier. Thank you so much for saving me a ton of time and helping users do their own firmware packages! That is quite an example you set there for the community!



Disclaimer

You are aware that writing to the security protected partitions increases your risk to lose the device exponentially. You understand and agree that I cannot be held responsible for such or any other damages. The flash process is theoretically safe and tested on various phones once a file has been posted to the first page, however you are the brains behind the wheel and you are solely responsible for the execution of the process. I will not accept any responsibility. The method itself is developed by Google and HTC, I only provide access and information to it.

You understand that you should not do it if you are not willing to accept this risk.







XDA:DevDB Information
S-OFF Firmware flashing (Fastboot), Tool/Utility for the HTC One (M9)

Contributors
Sneakyghost, nkk71

Version Information
Status: Testing
Stable Release Date: 2016-12-27
Current Beta Version: 4.19.617.1 & 4.14.61
Beta Release Date: 2016-12-27

Created 2015-04-07
Last Updated 2017-01-14
The Following 88 Users Say Thank You to Sneakyghost For This Useful Post: [ View ] Gift Sneakyghost Ad-Free
 
 
30th March 2015, 07:30 PM |#2  
Sneakyghost's Avatar
OP Senior Member
Flag InMyHead
Thanks Meter: 13,012
 
Donate to Me
More
Prompt
...





Notice:
These links are all tested by at least someone. Nothing here will be completely untested. Most stuff I flash to my own phone. Exceptions might be some carrier zips which would require me to do a full backup and conversion and then restore, which is time consuming, so, simply put: 401's are always tested by me, the others sometimes but mostly by others.
Credits
I have long lost track of my firmware sources. I am sorry i cannot name you guys all personally. The most common source would be @LlabTooFeR, @djluisbento, @AndroidFileHost (androidruu.com) HTCDev and some occasional random sources that come and go. If you find your stuff here and want to be included in the credits please contact me. I am very grateful for everyone busy providing dumps and direct leaks.

Disclaimer
You are aware that writing to the security protected partitions increases your risk to lose the device exponentially. You understand and agree that i cannot be held responsible for such or any other damages. The flash process is theoretically safe and tested on various phones at time of posting, however you are the brains behind the wheel and you are solely responsible for the execution of the process. I will not accept any responsibility. The method itself is developed by Google and HTC, i only provide access and information to it and you execute it.

You understand that you should not do it if you are not willing to accept this risk.
The Following 43 Users Say Thank You to Sneakyghost For This Useful Post: [ View ] Gift Sneakyghost Ad-Free
30th March 2015, 07:31 PM |#3  
Sneakyghost's Avatar
OP Senior Member
Flag InMyHead
Thanks Meter: 13,012
 
Donate to Me
More
Prompt
....




Error Handling Strategies for RUUmode/Fastboot


IF IT SAYS "FAILED" do NOT immediately reboot the device If you reboot with a FAIL your device could brick! If no flash is being accepted you have to find out what is causing the malfunction before rebooting your phone. Keep it alive while trying to figure out the error. It might be your cable, your USB ports (don’t use hubs! Always direct-mainboard connections), it might be USB 3.0 which is not good yet, it might be bad configuration of your ADB and Fastboot...
The least dangerous FAILED messages are listed below and are safe to reboot (below this section you find CRITICAL errors, please observe):

Safe to reboot / Flash didn't happen Errors (if you encounter one of them, you can just reboot. Nothing changed):
- 10 RU_MODELID_FAIL (MID in android-info.txt does not match phone’s MID)
- 12 signature fail (unknown yet but safe to reboot)
- 23 parsing image fail (means something wrong with the image in the zip)
- 24 android-info fail (means something wrong with android-info.txt in the zip)
- 32 header error (means the zip couldn't be read and unzipped properly)
- 41 Wrong Model ID (means its not the right device)
- 42 Wrong Customer ID (wrong CID means you gotta swap CID first as explained below)
- 90 pre-update FAIL (means it only flashed aboot and you have to run the process again immediately to flash all other partitions). The new M9 htc_fastboot.exe now auto-reboots on Error 90! If it tries to boot to your Android System, force it back into download mode - the flashing process will continue again by itself. If it doesn't auto-commence, restart the flashing process as in Step 3.
- 99 UNKNOWN usually indicates you are S-ON, sometimes other Security related issues.
- 130 wrong model ID (seems its the same like 41, just that it shows in the FUU as 130.
- 155 seems to indicate different things. It can mean: 1.) You need to relock bootloader (If S-ON); 2.) You cannot run the RUU/FUU because the software versions of ROM, Firmware and RUU/FUU don’t match.
- 170 Check USB - FUU won’t run because of not working ADB.
In fact, if it aborts before the "(bootloader) start image[hboot] unzipping & flushing..." line it actually didn't write anything and you can probably just reboot. If you see it flashing stuff though (the stages after that line) and then it stops with a FAILED, chances are a little higher that something is now broken. In that case do NOT reboot but do as i said above.

For Error “10 RU_MODELID_FAIL” do:
- check that the Model ID in android-info.txt matches your phone’s Model ID.
Typically, making your phone “SuperCID” makes it ignore CID and MID mismatches alike. However, lately we have noticed HTC has changed that behavior. MID mismatches are not ignored by SuperCID anymore. You will need to unzip my firmware package, change the MID in there to your MID and rezip it. Or, alternatively, change your phone’s MID, which is a bit trickier.
To un- and re-zip, please refer to Post #5 of this thread for more information!)

For Error 12 “signature fail" do:
- might indicate that a signed firmware package is required. This would only happen with S-ON phones though.

For Error 23 "parsing image fail" do:
- change image names in the zip to stock image names like “hboot.img" or “radio.img" or whatever failed there....

For Error 24 "android-info fail" do:
- check that your ZIP isn’t some HTC OTA or anything thats got no android-info.txt - those cannot be flashed with fastboot flash zip nameof.zip command.
- check that your zip has a good MD5 and is not broken, check android-info.txt etc...

For Error 32 "header error" do:
- Sorry i haven’t found the exact cause yet and don’t know a definite solution.
- Make sure there is only one . (dot) in the filename, before the extension. fastboot reads anything after the first dot it sees as the extension. If that is not zip, it fails.
- If that doesn't help, you can also try: make the zip new with recommended settings, re-run the command, check your connections...

For Error 42 "Wrong Customer ID" and: 41 "Wrong Model ID" do:
Code:
fastboot getvar all
Read that output, take note of your CID and MID and then edit the "android-info.txt" in your firmware.zip accordingly (For Wrong MID change the MID in the text, for wrong CID add your CID to the text).

Alternative method for MID and CID errors:
go SuperCID. Do:
Code:
fastboot oem writecid 11111111
You can change back to any desired CID after a successful firmware flash. Notice: this command only works on S-OFF phones (which you have already of course or else you wouldn't be here).

For “pre-update FAIL 90 ..." do:
- Let the phone reboot itself into Download Mode. If it doesn't boot to download mode, force it back there (From Android with adb reboot download or with the button method, see "step 1").
- If the flash does not auto-resume, run the same flash command again which you just ran (press arrow up on your keyboard to get to the previous command in console)


For “Error 99 UNKNOWN" do:
- Check with other zip’s if they work!
- Check if your S-OFF is correct
- You are S-ON? Then almost definetely this means the ZIP is not signed - get an unmodified zip!

For “Error 130 wrong model ID" do:
- Please refer to Error Code 41/42.

For “Error 155 relock bootloader" do:
- Since my thread works only with S-OFF phones anyway, this error can be read as: you need to S-OFF first!
- Error 155 can mean that you need SuperCID. On a few occasions this was shown when the RUU/FUU refused to run because of a wrong region lock.
- Lately, Error 155 has occurred when a FUU was launched from within android. When encountering a FUU error 155 with the process stalling after the rebootRUU (stuck at black screen with silver HTC logo), please just restart the FUU and leave the phone in that mode, or reboot the phone, then reboot to bootloader, then do “fastboot oem rebootRUU” and then launch the FUU again (thanks @anarchychris for pointing it out).
- run the fastboot command “fastboot oem lock" - only applies to S-ON phones that want to update the firmware with a stock OTA package (not offered on this thread!!). Stock OTA files sometimes need a locked bootloader.

For “Error 170 Check USB" do:
- Sometimes shown when running a RUU or FUU. Indicates issues with drivers. One way to solve is to run the ARUWizard with the phone already in Fastboot mode. Else you will have to re-install HTC Sync manager. Also, avoid USB 3 ports (the blue ones) - they have a complete new driver stack and that doesn't work well currently.


NOT safe to reboot / Flash (partly) happened Errors (if you encounter one of them, DON’T reboot):

- 152 Image Error - Phone Screen shows a little triangle beside a full green bar

For “Error 152 Image Error" do:
- Error 152 is quite rare, have seen it only once with a friend’s phone and it aborted the flash nearly at the end. The flash was started by the FUU. We could resolve the matter by NOT rebooting the phone and flashing the zip again through a manual fastboot flash as outlined further up.
The Following 29 Users Say Thank You to Sneakyghost For This Useful Post: [ View ] Gift Sneakyghost Ad-Free
30th March 2015, 07:31 PM |#4  
Sneakyghost's Avatar
OP Senior Member
Flag InMyHead
Thanks Meter: 13,012
 
Donate to Me
More
Batch Tool updated to 1.3.2

The "Android_Tasker" Batch Tool - a thing i am using for myself since 2012 and which i am sharing just because i have it. It is neither good nor special, but its the way i work and people who follow the instructions here might find it easier to use the same setup as we do.
It also has the "FUU" method included - details on that method will be added at a later stage. We do not consider the FUU a good option to flash Firmware anymore because we realized that getting away from ADB and Fastboot with toolkits makes troubleshooting harder at a later stage - people relying entirely on toolkits and tools will mostly not understand what is happening and helping there is much harder.

Since everything i do basically works out of the C:\Android\com path, all my zipped-up stuff extracts to that location. The FUU and the Task-Batch-Script both work from that location. This is simply to enable easier and faster creation of new zip’s if they all use the same base structure.
If you prefer to work from a different location. you can specify a different path in the installer. However, the batch scripts do not adjust automatically, which means if you use another path, you might need to open up the scripts in an editor and adjust some paths manually.


Preview:
Android_Tasker Preview

DOWNLOAD
MD5:b25b24a5a7f2bc03dc68a411fb41fca4

The installer is just a simple WinRAR self extracting archive - there is NOTHING BAD in there i swear! Open it with WinRAR 5 and look inside. You will see if you don't trust me.

Changelog:
  • 1.3.2
  • Fixed Dump-Script - it wouldn't run properly anymore with newer ADB 1.0.32 for some odd reason.
  • Updated TWRP to 3.0.3-0
  • Updated stock recovery to 4.19.617.1 (Developer Edition, no Nougat on WWE yet)
    1.3.1
  • Updated TWRP to 3.0.2-0
    1.3.0
  • Updated stock recovery to 3.35.401.12 and TWRP to 3.0.0-2
    1.2.9
  • Updated ARUWizard to 3.0.4.2015 from HTC’s One M8 DevEd Marshmallow RUU.
  • Swapped out stock recovery for 3.35.401.10 (WWE Marshmallow release).
    1.2.8
  • Splash1 converter works now. Flashing Splash1 now needs a reboot to Bootloader - it's not working in Download Mode! (limited DD support on the M9 and general flashing system changes).
  • Swapped out recoveries for newer versions.
  • Finally added the complete file set from RUU 3.0.1.2015 - the newest M9 RUU. ADB and Fastboot are identical to the previous version from Llabtoofer though.
  • Screenrecord removed - can’t be bothered figuring out why it doesn’t work anymore. Probably SELinux and general Android 5.x security like with the screenshot function. Not really needed either. There are other solutions.
    1.2.7
  • Swapped out recoveries for newer versions.
  • Swapped out ADB and Fastboot for a newer pack (thanks @LlabTooFeR) - now this Tool is fully M9 compatible and even flashes large RUU.zips.
    1.2.6
  • Changed everything to M9 files and methods. I HOPE I didn't oversee anything. Please test carefully!
  • Added stock_recovery_1.32.401.8.img
  • Added TWRP Recovery 2.8.6.0 fixed version from Captain_Throwback SOURCE Post #2 Beta version
  • Added original HIMA Splash1 - S-OFF phones only!

Previous versions:
  • 1.2.5
  • Added TWRP Recovery 2.8.5.2 from Captain_Throwback (All M8 devices)
  • Fixed Recovery Screenshot option (20)
    1.2.4
  • Added newer RUU structure (2.0.16.2014 - from 4.16.1540.8 Dev Edition RUU)
  • Added Stock Recovery 4.16.401.10.img (WWE)
  • Changed the License and SFX texts again (Installer) - never happy with it.
    1.2.3
  • Fixed some serious crap nobody reported. I just found out myself.
  • Added Stock Recovery 4.16.1540.8 (sorry still don't have the WWE recovery, but i guess they are identical)
  • Added TWRP 2.8.4.0 from the M8 tree of Dees_Troy.
    1.2.2
  • Added Stock Recovery3.28.401.7
    1.2.1
  • Added Microsoft's vcredist_x86_2008_SP1.exe to the installer because the ARUWizard is build on the x86 Visual Studio 2008 runtime. This resolves the "side-by-side configuration" error.
  • Added 3.28.401.6 stock recovery and splash
  • Added newer RUU structure (doesn't do any difference though, just keeping it up to date)
  • Added TWRP 2.8.0.3 (it still has slight issues with MTP which will be fixed soon but for now, this is good enough)
  • Changed a few lines in the script (minor, cosmetical stuff)
  • Updated the INFO PDF (option 24)
Known Issues:
  • Kernel Flashing needs fixing - can only work in fastboot now due to SELinux and related crap.
  • The partition Dumper is not correctly working, probably also due to SELinux.
Anyone used to like @squabbi's fully GUI based toolkit? He's picked it up on the M9 as well - maybe you like GUI better than commandline. Then head over here: http://forum.xda-developers.com/show...72&postcount=1
The Following 41 Users Say Thank You to Sneakyghost For This Useful Post: [ View ] Gift Sneakyghost Ad-Free
30th March 2015, 07:31 PM |#5  
Sneakyghost's Avatar
OP Senior Member
Flag InMyHead
Thanks Meter: 13,012
 
Donate to Me
More

Flash Process Output:
There are a few steps in the flash process which are not really straightforward but i can maybe explain some of them here,so you can better understand what is happening:

sending 'zip' means: fastboot is sending zip over to client (here referred to as “remote”)
OKAY [ 2.839s] means status of sending was good. Transfer succeeded.
writing 'zip'... means the zip is being written to some location on the phone from the /temp location.
(bootloader) zip header checking... means the zip header is being checked for validity, see if it’s a real zip file and check for HTC’s signature, which often resides in the header part.
(bootloader) zip info parsing... means most likely a check on the file hashes in the zip (integrity check - if the zip is borked, it will fail here)
(bootloader) checking model ID... The bootloader checks if the android-info.txt contains the right MID. If it fails here you gotta swap out your model ID in the android-info.txt file.
(bootloader) checking custom ID... The bootloader checks if the android-info.txt contains the right CID. If it fails here you gotta swap out your Customer ID in the android-info.txt file.
(bootloader) start image[hboot] unzipping for pre-update check... means the bootloader is now unzipping the [hboot] image. This line will be repeated before every image that is to be flashed.
(bootloader) start image[hboot] flushing... means the bootlaoder is now beginning to flash the [hboot] image.
(bootloader) [RUU]WP,hboot,0
(bootloader) [RUU]WP,hboot,99
(bootloader) [RUU]WP,hboot,100 these three lines read [RUU] for what mode fastboot is in, WP for “Write Partition” for what is currently being done in RUUmode, “hboot” is the name of the currently flashed partition, number xx is a percent stage of the write process.
(bootloader) ...... Successful means the final status is successful.

Now, before the [RUU]WP,hboot,xx line we often see another line reading [RUU]UZ,radio,50 for example. That reads RUUmode is currently unzipping the Radio.img and at stage 50 percent. UZ means UNZIP.

If you see something like this:
(bootloader) start image[sbl1-1] unzipping & flushing...
(bootloader) [RUU]UZ,sbl1-1,0
(bootloader) [RUU]UZ,sbl1-1,100
(bootloader) signature checking... means it is checking the signature of the partition if it matches the expexted signature stored in the hboot.
(bootloader) verified fail means the signature in the image did not meet expectations.
(bootloader) ..... Bypassed means the image got skipped because its got the wrong signature.

This has to be interpreted like this: there are multiple “SBL” images, to be exact: type 1 has 3 variants and type 2 has only one variant. Of type 1 (“SBL1-x”), two get skipped, one gets flashed (see my log above), of type two (“SBLx”) both get flashed. I believe, SBL 2 and 3 are device independent, but SBL1 has three variants, of which only one fits the current device. So, depending on the device you have, you will see either SBL1-1, SBL1-2 or SBL1-3 being flashed and the other two subtypes being skipped (bypassed).
The same goes for the "dzdata" images in the firmware package. They come in two or three size flavors (16, 32 and 64 GB) and resemble the file structure of the /data partition. Depending on your device and model, only the one with the right size gets flashed, the others skipped.

Important to understand: nearly all FAILED messages that do NOT occur while [RUU]WP (write partition) should be considered harmless. Only a FAIL during a write operation will most likely result in a damaged partition. All other fails will probably leave the original partition intact and thus the device can be rebooted. So far my understanding.

General hints for RUUmode zips
- Opening a zip is best done with 7zip as WinRAR and other zipping tools have lead to flash fails in the past.
- Choose low compression, higher compressions often fail. Pick "save" or "normal" to be safe, anything higher could cause the unzip in Bootloader to fail.
- Adding and Removing images is not a problem. The naming of the partition images seems flexible, yet if you encounter an “Error 23: parsing image fail” you need to rename the relevant image to something stock as not all names seem to be recognizable. The Hboot/Aboot determines the right partition from the header inside the image.
- Additional Dots in zip file names are known to have caused issues for a few people.
- Spaces in names are a no-go!
- Custom Recoveries can be added to those zips as well as custom kernels or hboots. In fact, if your phone is S-OFF, you can hex edit any partition and flash it. Be sure you know what you do though lol. I am just pointing out the possibilities. I am NOT saying it is safe!
- With S-ON, those zips only flash if everything is totally stock, from the android-info.txt being right up to all images being the correct versions for that update package and all having the right signatures. Reads: no custom messing with firmware zips for S-ON phones.

General hints for android-info.txt
- Use an Editor that doesn't mess up linebreaks like Windows Notepad does. Use Notepad++
- MID’s can be added one per line. Also supports wildcards i think e.g.: 71******, but i’m not sure.
- CID's can easily be added or removed- one per line, definetely supports wildcards (used by HTC in DevEd phone)
- Mainver line: should hold the version of the most current images, e.g if you combine older and newer files, add the MainVer from the newest. Format 2.24.401.1 (2= Base version always increases by 1 with each android base version rise, 24= Build version from HTC, 401= Regional/Customer identifier, 1= Revision of the HTC Build). This line is being written to the /misc Partition and is thought to identify the whole phone firm/soft version - its not meant to only describe firmware or base alone. Those parts always belong together. My opinion: run Firm/Soft always from the same or very close revisions (eg. 4.06.1540.2 or .3 are no issue, whereas firmware from 1.20 with a ROM from 4.06 can already cause the one or other malfunction).
- hboot pre-update line: usually says "3" but i have seen different numbers. I think they determine if hboot-preflash is required (when you get “Error 90 - please flush image again immediately” this is when the hboot/aboot needs to be flashed separately first and then the rest. If you encounter this, you need to run the flash command you just did, again.
- btype:1 not clear. [Item subject to change]
- aareport:1 Since HTC hboots/aboots, boot and recovery images come as "hboot_signedbyaa” / “aboot_signedbyaa” / “boot_signedbyaa” and “recovery_signedbyaa” i would read this as "aa" representing htc ("hboot signed by aa"). It could possibly mean check on the signature in hboot/aboot/boot/recovery - all of those also come in unsigned flavors - in HTC OTA’s, those are usually without the “_signedbyaa” but in the RUU, they are carrying a signature). So, aareport: 1 can just mean check on signature yes or no.
- Delcache means erase cache when rebooting. Simple. Some firmwares seem to need it, some don't. Line is not present in every android-info.txt. If you mess with a zip that contains the line, leave it active. This is also not referring to the Android OS cache partition. It refers to the separate Kernel and Recovery Cache. Sometimes, not deleting Kernel or Recovery Cache after flashing those leads to malfunctions. If the Kernel is launching and there is an older conflicting copy cached, the phone won’t boot past Kernel stage (before the bootanimation starts), if Recovery is conflicting with a cached copy (usually after flashing a new/different recovery), it will lead to the recovery not booting or malfunction (like aborting an ongoing ROM flash or not being able to execute other functions).

RUUmode:
is the mode used for RUU flashes by HTC. It allows a few more things than the normal fastboot. You recognize it by looking at the phone’s screen. It will be black, showing only a silver HTC logo and if a command is being active, a green progress bar. New M9 RUUMode now shows a percentage counter below the bar.

Recovery flash risk:
It's possible that the one brick i saw on the HTC Ville back in 2012 after flashing a hboot in recovery was caused by flashing it in recovery. I am rather sure that the method used by recovery zip’s to write an image file to NAND is not 100% bit correct and can cause trouble (This is the “DD” method). Due to the nature of this DD method, it can happen that single bits are flipped (no check on the written bit), which results in corruptions in the flashed partition. That can manifest in a full brick or just in faulty operation, in blocked partitions (unwriteable partitions) and many more annoying things. While a full brick isn't really that likely to happen (we had one on the Ville Forums within a year likely caused by DD writing a hboot), a corruption of some sort is a little more likely. Since all types of corruptions can lead to severe problems it is desirable to have a safer method. There is a command for recovery, “write_image”, employed by HTC but i haven’t worked out how to use it and how it actually works and whether or not it is safer. So i decided to just stay away from recovery zips for firmware flashing.
The zip flash executed in RUUmode also utilizes a different write technique and is safer (It most likely is the same as “write_image” in stock HTC OTA zips and their updater-script ).
Please be aware though that this remains an assumption.
Anyway, this is the reason why i don't offer recovery zips. Even though it is perfectly possible to flash partitions in live android (using "dd if=/somedir/yourhboot of=/dev/block/mmcblk0pXX") or recovery i prefer the fastboot method simply because i am sure it is safer.
Plus, since the advent of SELinux, Android 5.xx and up, it has become much harder to write to partitions using DD in live Android. There is much working-around-SELinux to do to actually get it working. A simple rooting of your Android doesn’t suffice anymore, besides S-OFF.

JTAG with a RIFF Box
Every device of these days has so-called jtag test-points. Basically, these are points on the mainboards, where a direct connection to the main chip can be established and then that chip can be read and written to with an external device. Sometimes, these testpoints are hidden (like they are normal contacts of the chip) and no direct visible gold points on the board. It always takes a while after a device is released until the jtag layout is fully discovered but once that is done, companies like multi-com.pl start manufacturing small boards with pins that can be pressed onto the mainboard, so no soldering to the device is required. Once such a board exists, the mainboard can be hooked to the RIFF box which can rewrite a dead chip from the outside.
As long as there is no such small board (called a "JIG") the phone can still be revived but it is necessary to solder hair-thin wires to the test-points. That is perfectly possible, Tecardo can do such a thing, but its not very good for the board and cannot be done very often. At some point the solder points will degrade so much that the board is garbage then.
In case you really brick your device, you can contact Tecardo here: http://forum.xda-developers.com/show....php?t=2116062

MID and CID
MID = Model Identification. It serves the purpose of identifying the Model of the phone. There usually are several different ones. The ModelID in android-info.txt is CaSeSenSiTivE!
Some limited Data is here: https://docs.google.com/spreadsheets...gid=1606643937
CID = Customer ID and describes, for which customer HTC made this phone. HTC has a few own CID's for its regional stores. Then certain carriers decide to have their own CID. Some carriers even have their own Model ID’s.
So, while the MID more like describes the hardware, the CID basically just describes the software set that comes delivered with it. Both get checked on when flashing in RUUmode. How to trick this system? Fairly easy. Just add your respective MID or CID to the android-info.txt file inside the ZIP or make your phone SuperCID (My Batch Tool can do that automatically - but remember: all this only works on S-OFF phones).

S-OFF:
S-OFF refers to the NAND’s security lock. S is for security and OFF means the security is switched off. The factory state HTC’s phones ship with is ON, except for the userdata partition, which of course is always unlocked.
The key for that lock is the most heavily guarded secret in HTC’s software vaults. It cannot be extracted, bought or otherwise obtained from them. There is no official way to unlock the NAND partitions (approximately similar to what Apple fans do when they “jailbreak” their products, although technically not quite as similar). While the HTC Dev Unlock (available through htcdev.com) just unlocks 3 partitions (Boot, Recovery, System), the “S-OFF” hack we use unlocks all partitions, thus enabling the flashing of custom, modified or other devices firmware. This is what you want for this thread and you can get it from the famous reverse engineers Jcase and Beaups over at: http://theroot.ninja/ or alternatively purchase a “Java Card” and learn how to work it, from chinese sellers on Alibaba, sometimes Ebay. Then there is a way to do it with an XTC Clip. But SunShine S-OFF is by far the safest and fairest method. You will only be charged if it works and the guys over at sunshine are really helpful.


A more detailed look at how S-OFF works
[Subject to change - not a definite explanation, just how I think it works]
In the Phones Firmware is a component that checks if certain partitions have a digital signature from HTC and deny write access if the signature is wrong or missing. The checking component is known to be the Security, which can be set to OFF. Then we say the phone is
S-OFF.
System, recovery and boot do not get signature checked at all once you “unlocked” your phone on htcdev.com. The other partitions however do get checked as long as Security flag is set to ON. Partition 3 is where the Security flag is located and maybe also the checking routine that checks the other partions digital signatures,
The S-ON state is resembled by a 3 in the fastboot command to switch security on. It is: fastboot oem writesecurflag 3. You do NOT want to do that while any custom firmware is running. Only after a full RUU that removes any modifications.
Why? For some partitions like the splash screen, it might not lead to a brick if you set security to ON while a custom splash is installed (then failing the signature check), as this partition is not vital for the boot process, it might just be skipped and give you an error message (I have never tried obviously). Other partitions however, boot critical partitions like Hboot/Aboot.... You guys have to understand that altering any of these partitions can be deadly to your phone if you happen to leave them altered when switching security back on.

Determining your “Firmware Version”
I believe there is some wrong info circulating the HTC Fora. People keep saying when running fastboot getvar all it will report the Firmware Version in the line “Version-Main”. This is not always true though. Fastboot getvar all or alternatively getvar mainver pulls a version it finds in the MISC partition and relies on that to be correctly updated. Source
So how does that version string get updated? It is being taken from the android-info.txt file in any firmware zip that you flashed. The last zip you flashed determines what will be reported by the getvar function. So if you mess around with Firmware.zip’s and RUU’s a lot, chances are, that the version reported there is not equivalent to what you are already running. Often the android-info.txt has version entries not appropriate for the actual zip contents, for compatibility reasons, because it wasn’t done properly or whatever. My zips usually have the correct MainVer though.

The "Firmware" as a concept like we use it on XDA does not exist in HTC's terms. HTC does NOT differentiate between the /System Partition (what we know as "the ROM") and the other 36 partitions. Hence, if you run getvar all or getvar mainver on a stock phone, it will report correctly. It does not go looking for a fictitious place where it would find a separate "Firmware" version. That place it is looking at is the Misc Partition and that’s correct as long as you haven’t messed with lots of different Firmware zips... So, if you happen to run a hybrid system with a ROM from one base and the other partition images from another base or multiple bases (like hboot from 1.27, radio from 4.06 and ROM from 3.62) the getvar function will report as "Version-Main" what it finds in /misc/, precisely the last zip you flashed determines the string put there.

Example: you flashed a radio with a RUUmode zip from Base X.YY but the android-info.txt is maybe still an old one because the dude who made the zip, just dropped the new radio into an old existing zip, the getvar function will later report that old version as your mainver.

To check your firmware: boot to bootloader and look at the combination of hboot version and radio version - if you didn't flash those separate, the combination will let you know what base you are on (each OTA and RUU has the radioversion in its name).
Finding out your firmware is a game of guesses and knowing what you did to your device and where you are coming from.

If totally lost, best thing is to reflash some clean stock package to be sure you are on the same level with all partitions.

Long story short: you better know what you do because finding out your firmware is going to be difficult if you don't.

Further reading
OLD INFO REMOVED - NEEDS UPDATING
Some more useful threads with similar contents. Each has its own bits and pieces and re-wording that you don’t find here or understand here. So those threads might be helpful to you too.


Related/ “Like” stuff
-
- HTC ONE M9 Partition List
The Following 14 Users Say Thank You to Sneakyghost For This Useful Post: [ View ] Gift Sneakyghost Ad-Free
3rd April 2015, 08:13 PM |#6  
Senior Member
Thanks Meter: 3
 
More
Does it work with TMOB101 CID too or only HTC xxx CID?
3rd April 2015, 09:08 PM |#7  
Sneakyghost's Avatar
OP Senior Member
Flag InMyHead
Thanks Meter: 13,012
 
Donate to Me
More
Quote:
Originally Posted by fearomoon

Does it work with TMOB101 CID too or only HTC xxx CID?

TMUS has had different Radio requirements on the M8. This is still open to investigation. My buddy @Behold_this is getting his M9 shortly though and he is TMUS. We will work it out in no time.

Other than that, you are aware you will need S-OFF to flash any non-TMUS firmware, right?
The Following 4 Users Say Thank You to Sneakyghost For This Useful Post: [ View ] Gift Sneakyghost Ad-Free
3rd April 2015, 09:20 PM |#8  
Senior Member
Thanks Meter: 3
 
More
Ja but there is no soff yet for m9 isnt it
3rd April 2015, 09:30 PM |#9  
Behold_this's Avatar
Recognized Themer
Flag Las Vegas
Thanks Meter: 4,534
 
Donate to Me
More
Quote:
Originally Posted by Sneakyghost

Quote:
Originally Posted by fearomoon

Does it work with TMOB101 CID too or only HTC xxx CID?


TMUS has had different Radio requirements on the M8. This is still open to investigation. My buddy @Behold_this is getting his M9 shortly though and he is TMUS. We will work it out in no time.

Other than that, you are aware you will need S-OFF to flash any non-TMUS firmware, right?

Hey guys, just chiming in here. That is actually not T-Mobile USA. Going by his CID, that is T-Mobile Deutschland. T-Mobile USA's CID is T-MOB010. The two CID are very similar so easy mistake to make. Unfortunately I have no access to any firmware for T-Mobile Deutschland.
The Following 3 Users Say Thank You to Behold_this For This Useful Post: [ View ] Gift Behold_this Ad-Free
3rd April 2015, 09:41 PM |#10  
Sneakyghost's Avatar
OP Senior Member
Flag InMyHead
Thanks Meter: 13,012
 
Donate to Me
More
Quote:
Originally Posted by fearomoon

Ja but there is no soff yet for m9 isnt it

I expect it to arrive shortly. SunShine has already tweeted they managed to find a vulnerability and create an exploit, so all they have to do now is automate the process enough for Eejits. Guess it won't be long.

Quote:
Originally Posted by Behold_this

Hey guys, just chiming in here. That is actually not T-Mobile USA. Going by his CID, that is T-Mobile Deutschland. T-Mobile USA's CID is T-MOB010. The two CID are very similar so easy mistake to make. Unfortunately I have no access to any firmware for T-Mobile Deutschland.

Oops! Thanks for the correction. Looking into my sheet reveals you are spot-on once again. Eagle Eye friend!

In this case, fearomoon, you can flash 401 (WWE) firmware no problem. TmoDE uses international frequencies for GSM, UMTS, LTE and WiFi. But you will still need S-OFF.
The Following 3 Users Say Thank You to Sneakyghost For This Useful Post: [ View ] Gift Sneakyghost Ad-Free
3rd April 2015, 11:49 PM |#11  
Guest
Thanks Meter: 1,097
 
More
Quote:
Originally Posted by fearomoon

Ja but there is no soff yet for m9 isnt it

Apart from not having s-off at the moment i'd really recommend you to wait with firmware flashing until we made some testing (which also depends on when we will get s-off).
The Following User Says Thank You to herwegan For This Useful Post: [ View ] Gift herwegan Ad-Free
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes