[One (M8) Android Development] Sneakyghost:
General Information​

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.

(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 three size flavors (16, 32 and 64 GB) and resemble the file structure of the /data partition. Depending on your 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 has 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 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 they weren't touched at all. In case of a ROM.zip from a RUU, it also needs to still have its encryption. Whenever you unzip and rezipor add/remove stuff, the package won't flash anymore with S-ON, no matter how hard you try.

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 be the version of the most current images, e.g if you combine older and newer files, add the MainVer from the newest. Format 2.22.401.5 (2= Base version always increases by 1 with each android base version rise, 22= Build version from HTC, 401= Regional/Customer identifier, 5= 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 revisions. Try to avoid a mismatch between ROM and Firmware and never mix firmware components.

- hboot pre-update line: usually says anything between 1 and 12. I think they determine if hboot-preflash is required (when you get “Error 90 - please flash image again immediately” this is when the hboot needs to be flashed separately first and then the rest... [Item subject to change]

- btype:1 not clear. [Item subject to change]

- aareport:1 Since HTC hboots come as "hboot_signedbyaa” i would read this as "aa" being htc ("hboot signed by aa") and aa report meaning report to htc if 1.

- Delcache means erase cache when rebooting. Simple. Some hboots 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.

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.

DD method bricking risk:

In 2013 there had been a series of TWRP recoveries that have had issues flashing ROMs on a few HTC devices, mainly Aroma based issues. It's possible though that the one brick i saw on the Ville from flashing a hboot in recovery was related to flashing it in recovery as i am not sure that the ROM flash fails are only Aroma based fails. I am rather sure that the method recovery zip’s most often uses 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, which equls a corrupted hboot. That will manifest in a full brick with the next reboot. While that isn't really that likely to happen (we had one on the Ville Forums within a year which happened while flashing a hboot in recovery), it still is a noticeably higher risk than RUUMode flashed hboots. 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/DD flashes.

Apparently the zip flash executed in RUUmode utilizes a different write technique and is safer (It most likely is the same as “write_image” in updater-script ;) ).

Please be aware though that this is an assumption. There is no real proof for this as we haven't gotten comprehensive documentations of HTC's stuff here. Anyway, this is the reason why i don't offer recovery zips. Even though it is perfectly possible to flash it in live android (using "dd if=/somedir/yourhboot of=/dev/block/mmcblk0p12") or recovery i prefer this method simply because i am sure it is safer.

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, [MENTION=4350887]Tecardo[/MENTION] for example can do such a thing, but its not very good for the board and cannot be done very often. At some stage 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://xdaforums.com/showthread.php?t=2116062

S-OFF: Firewater versus Sunshine

Firewater: it's free although the tools used to find the exploitable code and create software to actually exploit it are insanely expensive, so consider a donation towards the creators. They bought the tools from their private money and invested hundreds, if not thousands of (unpaid) hours. Firewater only works on a limited set of HTC One M8's but works on M7's and more.

HTC managed to close some open hole that Firewater needed to get to the exploitable code, so with the later M8's, Firewater doesn't work at all anymore.

Sunshine: costs $ 25 USD, is heavily automated and also, its secret ingredient is guarded well now so HTC might not close this hole in the rabbit fence as fast.Well, lets hope so. And DON'T moan about the money. As already stated for Firewater, the guys went to great expenses to get you this hack and currently, there is no one else capable of doing this. So, zip it. Period. Sunshine is nice and easy to use. I have very much respect for this method. Totally awesome to use.

Thanks to [MENTION=711482]beaups[/MENTION] and [MENTION=4519372]Fuses[/MENTION] - they done a brilliant job, we’d have nothing without them.

Notes on the currently available hboots

Currently nothing particular on the HTC One M8 Hboots. So far, they all have been doing the same, no differences noted. The GPE hboot is probably responsible for the System Partition reformatting, which is the most interesting bit i know. I know that Fuses will come up with some customized, engineering-style hboots at some point. So watch his space. They will probably appear on the Firewater-S-OFF site when available.

MID and CID and regional number in the software version

MID = Model Identification. It serves the purpose of identifying the Model of your HTC Phone and can, but does not necessarily, describe different hardware. T-Mobile US, Sprint and Verizon have their own Model ID's, also the china variants use different MID's. The international GSM phone and Tmobile share the same hardware though. Sprint seems to have identical hardware but strong software differences which don't allow for cross-flashing firmware. Verizon has a different partition layout and possibly different hardware. It is NOT compatible with international/GSM MID firmware.

CID = Customer ID, 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.

So, while the MID more like describes the hardware, the CID basically just describes the software set that comes delivered with it (features and bloatware). 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 even easier, boot to fastboot and write SuperCID to your chip (fastboot oem writecid 11111111). SuperCID will make any flash ignore both CID and MID.

SKU = This is the number in the Software Version number that describes for which market/customer combination the update is, i believe the combination of MID and CID gives the SKU. It's the 3-digit part right here: x.xx.401.x. I have a list of all CID's, MID's and SKU's in post #4.

They are not yet sorted according to which goes with which (nearly impossible task) but its a nice overview nonetheless.

Signature on the hboot and other partitions

In the Phones Firmware is a component that checks if certain partitions have a digital signature from HTC and deny read and 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.

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, as this partition is not vital for the boot process, it might just be skipped. System, recovery and boot do not have a signature at all. The HBOOT however does have it and i am sure Partition 3, which controls the Security flag, has it too and maybe some others like the secondary bootloader.

You guys have to understand that altering any of these partitions is 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” or when looking at the "OS" line in bootloader. 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 read 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 have the correct android-info.txt with them always and will always provide a correct entry.However, TWRP has a bug up till version 2.7.1.0 which deletes this info upon first and every consecutive boot, so you will NOT have this info at all when running that TWRP.

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 46 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.12, radio from 2.22 and ROM from 1.54) 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 1.54 but the android-info.txt is maybe still an old one from 1.12 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 1.12 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​

- to be updated

Related/ “Like” stuff

- to be updated

The original M7 thread