[HTC Wildfire S] Antagonist42:
I'm now in totally unfamiliar (that being 'it's not in some form of plain English') ground, as I'm not familiar with programming at this kinda level it may as well be dutch that i'm reading :laugh: although whilst going through all these .bin .hex files I am more coming to the conclusion that the only thing stopping us from writing what 'WE' want into the NAND chip is down to a (and most likely a single obscure or obvious code) probably single code that pulls down the WDOG_EN pin or the GPIO95 pin and nothing else and this is kinda the reason why....

Pulling apart the .hex files for my ACER, unless there is some lonely code somewhere in the FLEX part of the data called up prior to the EUU converting the .hex files for transfer, there is nothing in the files except an image header and the flex data. AMSS as far as I can tell only has the CCI Attestation files and Compal files with their (I think Sha1) relevant numbers and ID data etc, these appear in a couple of .bin files I extracted, each .hex for system and amss has 7 .bin files, pre.bin being RAW data image header or name, part1.bin being partition info, part2.bin I don not know but loaded into IDA picks up on ARM THUMB INSTRUCTIONS (if this is because I chose to load into ARM ram/rom not sure :confused: ) and part3.bin looks as though it's fastboot although both system and AMSS are different (the knowledgeable will know) and I suspect AMSS is flashed first followed by system going off the differences in the data.

Looking at both the files for the ACER and from RUU for WFS there are no CCI Attestation files or data at the end of fastboot or other files to be installed, one problem I have come across is that neither are flashed from the PC seemingly in the same way, WFS builds it's ROM from a rom.zip (may be raw data as 'broken' in 7zip and WinRar) and .ini files and to me anyway gives little away :( and the ACER uses .vdh files (essentially builds a ROM between specific sections and relevant .hex added) which is my next thing I'm going to look at (breaking down the Intel hex data addressing-recording) so I can see if I can 'build' the converted files that are transferred to the phone if my patience holds out :eek: that said the actual files seem to be so dissimilar in data and transfer that it must be something to a certain degree obvious we're missing :mad:

This to me points us back to maybe a 'switch' made whilst loading fastboot, essentially from what I can make out from what happens with an EUU/RUU (and probably the same for FOTA) and from the docs i've read ARM11 is held in a zero operating state up until around OEMSBL starts kicking in for handing over, until then the ARM9 has been setting up RAM/ROM/AMSS etc whilst it is doing this the WDOG is 'patted' so as not to kick in and reset or shutdown as ARM11 is not operational as yet (and can be told by AMSS to reset as with a FOTA will boot into fastboot to update without prompting from the user even if you disregard it when it comes in (I hate auto-syncing)) so finding out how the WDOG is 'patted' might be key to it :confused: and getting to that is out of my league seeing as I still haven't gotten around to writing a "hello world" thing that works :laugh: