[HTC Wildfire S] no.human.being:
It means that the exploit failed to detect the jump to the entry point, with which all HBOOT images start. Are you sure that your "mtd7" is mapped correctly while running the exploit on it (or while creating the HBOOT image in case you run the exploit on an image file)?

The exploit expects the partition/image to contain exactly the HBOOT. The device/image appears to have the correct size, since otherwise it would have claimed "[ERROR] HBOOT partition has incorrect size!" and not gone on to the HBOOT analysis part. Please verify that the image or device you try running the exploit on does indeed contain the complete HBOOT image. All images I have seen so far start with the "big endian" word 0x120000ea, which is an unconditional jump instruction. If yours starts with something else, you most likely had incorrect mtd mapping while dumping the HBOOT. Remember that HBOOT can start at either 0x02b00000 or 0x02400000 physical and you have to supply where it starts as a kernel parameter while loading CWM via Fastboot. If you get this error with the one value, try with the other and see if it gets through or at least shows a different error.

This is not entirely true. It will patch an HBOOT image in file that has been dumped before, it just won't write to NAND. In case he tries to obtain a patched HBOOT image for him to flash via JTAG, the exploit will "work". I advise mapping HBOOT as mtd7 as described, then performing a dump into a file on the SD card using "cat /dev/mtd/mtd7 > /sdcard/hboot.img", then let that dump be patched using "./inject --disengage-the-safety /sdcard/hboot.img". This should work with the exploit claiming "[ OK ] Done!" in the end and the file being modified (if you want to verify, make an "md5sum" before and after the procedure and see that it will change). If not, please report back with more detail (if possible including the HBOOT dump) so we can check whether this is an error in our exploit and fix it.

Are you sure that they are just plain hashes and not digital signatures? If it were just plain hashes, these could be easily bypassed by computing the hashes for the modified HBOOT. However, HBOOT has RSA keys embedded into it and we thought it would use public key cryptography (signatures) for verifying authenticity of NBH images.

No, it's not what everyone gets. People have run this exploit on their own phone and gone until "[ OK ] Done!". If done correctly, there will be no permissions error. The Radio will just silently drop our write requests but claim that writes succeeded so if you read from the "mtd7" before and after running the exploit, it will still have the original contents, but the exploit won't notice that writes have been discarded and thus report success. If you dump HBOOT to a file in the file system, then run the exploit on it, the HBOOT will get patched like it should. The "incorrect base signature" means that the exploit could not find an entry point to the code in the file/device handle that was supplied to it.

Basically the exploit is a bit "intelligent" and has a heuristic that enables it to "guess" the right function to patch. I built this algorithm so it will "adopt" to slight changes in the HBOOT image. However, the heuristic is quite "cautious" and will abort when certain parts of the HBOOT doesn't look like we thought they were "supposed to look". One of the most elemental checks is that every HBOOT should start with a jump instruction. When I saw this instruction first, I thought this was some kind of "magic number" identifying that HBOOT starts here, since it's the first 32 bit word and it's the same for every HBOOT version, so I called it the "base signature". However, later someone mentioned that this is actually a jump instruction towards the "entry point" of the HBOOT. So I should change the message towards "entry point not found", since that's by what it is actually triggered. Don't ask me why the "base signature" message has "stuck". I'm going to change it with the next release, but I won't make a new release just to change that message. So for now just remember that "base signature not found" = "the exploit can't find the entry point for the code that is contained within the file handle you supplied". :D