[HTC Wildfire S] no.human.being:
I'm not sure, I just think so. Like I said I had no chance of reading what was written to screen, but to me it looked as if "normal" HBOOT cycled through more file names before displaying menu than "chainloaded" HBOOT.

How would we get to the place where the revert happens? Search for strings, then try to backtrace? There are some "wildcard strings" like "----IMG.nbh" and "----DIAG.nbh" in HBOOT. HBOOT probably takes these and then replaces the first 4 characters with the first 4 "digits" of the board number - PG76100 - so that you get to the "PG76IMG.nbh", "PG76DIAG.nbh", etc. In HBOOT-1.09.0099 they're in the following places.

"----IMG.nbh" @0x693d0

"----DIAG.nbh" @0x693dc

"----IMG.zip" @0x693ec

"----DIAG.zip" @0x693f8

There are some more wildcards in HBOOT-1.09.0099.

"--------.---" (generic 8.3 wildcard) @0x693c0

"--------.nbh" (generic 8.nbh wildcard) @0x69408

"--------.dgn" (generic 8.dgn wildcard - who has seen this extension yet?) @0x69418

"--------.zip" (generic 8.zip wildcard) @0x69428

"--------.dgz" (generic 8.dgz wildcard - who has seen this extension yet?) @0x69438

All the strings are zero-terminated (C strings), so they are probably processed by the ANSI C string functions in <cstring>.

Nice theory. :fingers-crossed: I bet it reverts though. :D

Btw, preparing an NBH is not fun. It's an extremely complex multi-layer data structure. An NBH is a signed DBH (of course, when the bootloader has signature checks disabled, you don't have to generate valid values for the signatures, but at least you have to get the data structure right) and a DBH is a complex data structure of its own right.

This is the source code of a tool that decodes an NBH into a DBH (strips the signatures out) and this is the source code of a tool that decodes a DBH. It's Perl and uses lots of regular expressions and the like. Mind that this tool can only "decode", while we have to do the inverse operation.

I still have one that is known to work. Of course it doesn't contain "your" HBOOT, but an HBOOT-1.09.0099 from an RUU that was S-OFFed by "exploit inject". So it's "stock" HBOOT-1.09.0099, just S-OFF. I can't test it since I don't have the phone, but it "worked" (well .. phone became S-OFF but reverted to S-ON) while I still had the phone and the image is still untouched (not even recompiled) so this should really work. :D

Now what we need is a daredevil who's willing to risk bricking his phone. Reverting while flashing APSBL is probably not fun. It's unlikely that it reverts during flashing though, it probably does the check before (my guess) or after (that would be ideal since that might mean we got it ^^) writing to NAND. :fingers-crossed:

EDIT: Btw, there is a zip archive contained in the HBOOT. For HBOOT-1.09.0099 you can extract it using the following command.

dd if=hboot_109.img of=test.zip bs=1 skip=334996 count=27028

Contained in the archive is a single file called "spcustom.img" that's 372.736 bytes in size. It's a binary file that begins with the word "HTCCUSSP". It's probably the "green HTC logo on white background" splash screen that the phone shows while booting. Now as you remember, there are also splash screen partitions in the Radio (called "sp1" and "sp2" or something like that) and if I remember correctly, "sp1" contains the "actual" splash screen that is displayed. Now when the splash screen is already stored in the Radio, then why is it stored in the HBOOT as well?