[HTC Wildfire S] no.human.being:
Breaking the hash function (which would require bruteforcing) is probably "easier" than breaking the RSA signing algorithm (which would require factoring, which is also "difficult", but for which there are much more efficient methods than trying every possible combination). This is because the key space of the hash function is much smaller than that of the signature algorithm.

I think you misunderstand how signatures work. A signature is basically a hash of the data to be signed (so e. g. of the HBOOT image in your file/RUU/whatever) encrypted with a (private, asymmetric) signature key. The verifier (HBOOT) has the (public, asymmetric) verification key to decrypt the original hash from the signature.

So HBOOT does not simply compare a value that is appended to the file to a fixed known value, as this would not provide actual security. All you'd have to do is figure out how the value is generated and then generate it for your modified data.

Instead, HBOOT hashes the "payload" data of the image to be flashed and "decrypts" the appended signature using its public key, then compares this against the hash it has generated from the payload. If both hashes match, the image stems (very likely) from someone who is in posession of the private key, since only he can "RSA encrypt" the hash with it so that it matches when "RSA decrypted" again.

So you have your message "m", which is the actual HBOOT code and you have your (private) signature key "ks" as well as your (public) verification key "kv". Then we have "RSA encrypt" function "encrypt(<message>, <key>)" and decryption function "decrypt(<message>, <key>)", as well as a hash function "hash(message)". What HTC does now is the following.

1. Take "m", the code of an HBOOT.

2. Calculate the signature "s" as "encrypt(hash(m), ks)".

3. Put "m" and "s" in a file "image" and distribute.

When the user flashes the file, HBOOT does the following.

4. Split "image" again to obtain "m" and "s".

5. Decrypt the signature "s" using the verification key "kv" as "val_a = decrypt(s, kv)".

6. Hash the HBOOT image that was split off in step 4 as "val_b = hash(m)".

7. Check if the values obtained in step 5 and 6 match.

if (val_a == val_b)
{
unlock_all_pages();
write_to_nand(image);
}
else
printf("Signature error!\n");

reboot();

So it's not that you only got to append a fixed value to the image that HBOOT then checks to be present. You have to generate the signature for the specific image you want to install using the private key, otherwise they won't match. That's the purpose of a signature. Proving that the message does in fact originate from the person in posession of the private key to which the verifier has the corresponding public key and that the message has not been tampered with after it has been signed by the originator.

Deriving the private "ks" from the public "kv" is possible, since there is a mathematical relationship between them. However, it requires you to factor "kv", which is a very large integer and integer-factorization is currently classified as an NP-intermediate problem (I say "currently" since up to today, there hasn't been a proof that either P != NP or P == NP so this claim is not proven in the mathematical sense and may become irrelevant should P == NP be proven one day :D ), at least for digital computers (integer factorization can be done in polynomial time using exotic probabilistic algorithms on certain analogue computers, but these machines are still far too noisy to handle the large amount of discrete states that's required for representing integers with a length of several thousand bits exactly over the course of the computation, so they are not yet a threat for the key-sizes used in practice). So it's not that it can't be done, but it takes so much time that the data to be protected can be considered worthless after the signature has been broken. Basically that's the entire purpose of cryptography. Protecting data until it's not worth being protected any more. EVENTUALLY every cryptographic method will be broken (apart from the "one-time-pad", which is absolutely secure without knowledge about the key due to information-theoretical constraints :D ).

2048-bit RSA is currently considered to take about 15 years to break (this estimation does not take into account that within the next 15 years someone could manage to build an analogue computer that is accurate enough to break it - if someone does, this will be a MAJOR change in cryptography, since it will basically break all asymmetric methods - possibly so far that BREAKING A SIGNATURE can be done faster than signing itself, which would be quite funny :D ). So as long as the message you are protecting with this cryptographic method and key length can be considered "worthless" in 15 years (which software for the MSM7227 certainly will be by then :D ), it's ok to use RSA-2048.

Btw, have you already tried this? Is probably easier than breaking RSA. :D