[HTC Wildfire S] Antagonist42:
Right.... to flash an image fastboot has to be loading (not specifically) another fastboot (or parts of) and that loads QCSBL, OEMSBL, and I suspect transferred as a single .img or at least written as a single image (each piece verified as it is written not prior!!!! [think they may be verified via EUU/RUU before TX to fastboot]) if security fails the NAND image to be written is dropped.

AMSSHD and AMSS are written as one image not as individual images.

SYSTEM is another matter, the partition table seems to be taken from AMSS .img initially (as I flashed in another partition table that didn't match in system.img - so it didn't get security checked?!?!), RECOVERY resides inside the SYSTEM partition (if you lose the system partition you lose recovery as well).

BOOT or BOOT.img is present in both AMSS and SYSTEM images (this was also flashed with incorrect boot.img when I flashed system and not verified or it passed what was checked?!?!).

If you do plan on flashing a whole system to alter parts of it (which can really spoil your week not just your day!) flash your system to a GEN SKU, these i've seen mentioned that they are able to flash over just about any other SKU as say EMEA_ORGFR or VFIT and CUS.

As I found with my ACER the EUU has a .hex file it uses to build an image of fastboot or a derivative, transfers this as 'LOADER' and fastboot on the phone essentially sits there as a transfer hub. I also tried other .hex for the fastboot file, they have created an image although failed security on transfer (possibly wrong address to transfer to or partition info [the .log file was unclear on specifically why]) and when it has passed the images have failed (because I have got a corrupt system probably).

Transfer was seemingly verified on a 'amount of data transferred' and 'amount of data with kernel' check so maybe not so much a security key/code in any image more that a certain amount of 'specifics' HAVE to match, I say this because I found I can flash in another partition if AMSS is not added to the flash image, once in the partition cannot be flashed over with a complete update (it has to be piece by piece) and if you use Header images from the same company it is highly likely you can use a different Header from the Data file that goes with it.

Essentially I had to do the following to get where I am:

1. flash phone without system - make sure all other files are ok.

2. flash system - edit partition file, then appsblhd, appsbl (to make them match), recovery, system.

3. flash phone with complete stock EUU = failed.

4. flashed with incorrect system.img (keeping original appsblhd/etc) and stock EUU = flashed

-----this had varying results from no screen, boot loops, running then crash-----

5. flashed with reduced files in stock system.img - eventually flashed 100%

---this gave boot crash/stuck or Download fail---

6. flashed with SD Update -- gave recovery boot loops if it booted at all --

7. flashed SD Update - pull Battery - flashed EUU without SYSTEM.img

------ Got the phone working to a degree ------

Phone is now working but limited, now have a phone that will boot up, run but still has a problem of either a page in NAND is corrupt/un-flashable or I have DDRRAM fail as it doesn't show using correct memory but tells in sys info you have 512Mb of RAM/ROM. Flash a complete EUU/SDUpdate and aSYSTEM Download fail happens immediately.

In doing this the only thing that seemed to come near security was the EUU once the fastboot.img had built the system images (essentially unpacks the .hex files to .bin images) the EUU sends a 'SecurityCheck command' then receives OTP status then CMD_HELLO then CMD_SECURITY_MODE..........Once that is done there seems no other time anything actually touches 'Security' and the only things that failed that were the fastboot.hex files I changed in the update, no changes to .img's failed this except to mismatch or invalid partition (so it just didn't match at all) and as it has to be done over USB the EUU has PID (they are specific) if this changes the update fails (had that happen)

As I have mentioned in earlier posting, SD Update certainly doesn't use the same 'Verification' to check on updating as it didn't match an image I flashed in but it still did 100% - but didn't work and still had the corrupt page :laugh:

Now i'm going to go away and mope about in a quiet corner as my head is now mashed from doing this for over a week :silly: :crying: :eek: