Some problems:
- Newlines, tabs, spaces, and any other whitespace will hash the same. That can introduce collisions.
- Multiple spaces beside each other won't affect it. So that's another way to introduct a collision.
- Your ending data is only 4 bytes, so it's extremely easy to bruteforce the entire keyspace. 232 possibilities, at say 15000 tries/second (not unrealistic, especially with such a simple algorithm), means you can force a collision in about 3 days. That makes it useless for verification.
- It's being xor'd by predictable values, so the xor'ing is completely useless.
- If it's a short string (so it doesn't overflow), you could probably get the original string back by finding out which letter evenly divides into the resulting number. You could easily work backwards like that.
- The last characters in the string have more effect than the first characters.
- NULL characters or \x01 characters won't hash properly, so ths is pretty useless for hashing binary data.
Why do you try to invent your own hashing/encryption algorithms, anyway? You realize that the current ones used were derived by mathematical geniuses, and tested for a significant amount of time with every known attack before becoming a standard? I'm pretty sure you don't know a lot about math, or about cryptographic theory, so there really isn't a point in trying to invent your own. Why don't you find the outline of the SHA1 or MD5 (or even MD2) standard and try to implement that on your own? One of our assignments in school was to implement MD2.
Oh, and by the way, .o is for object files, not for the final output. If you really feel like you need an extension, use .bin or .out. But you shouldn't need an extnesion at all.