The original string is not in any way part of the image that's generated. The fuzzer notices that the initial codepath being triggered with the "hello" file would be different if the first byte were 0xff, instead of 0x68. So it changes the file and tries it. The 'h' has gone - it wouldn't matter what it was originally, the fuzzer would always have chosen 0xff.

All the fuzzer is doing is exploring the possible codepaths through the application trying to exercise all the code; many of the codepaths end up with the executable outputting an error message and terminating. Some maybe put it into an infinite loop. Some end up with it completing a JPEG data parse and terminating - so in amongst all the possible paths it explores, of course it will eventually seek out input sequences which bring that about.

thank you very much for explaining that! So it is really quasi-random image generator with the initial string being a seed?

no, the original string is not really a seed, and it's not really quasi-random. It's highly deterministic based on the structure of the program under test, and to a far lesser extent the original seed. In this case, I would be very surprised whether the original bytes of 'hello' have any impact whatsoever on the first valid JPEG image it finds.

Along similar lines, I wonder if this fuzzer can be used to bruteforce passwords for applications. Would it do any better than standard "try all the combinations" method?

If the password is generated with a sane KDF - bcrypt/scrypt/pbdkf2, no.

If it's not, better attacks exist than trying every single password.

If you're trying to crack the application - not the password - maybe, but I kinda doubt it.

Not really, because it depends on collecting traces from the target, and if you can do that you can usually just read the password out of memory.

On the flip side, it could probably be used as a really slow universal keygen for naive license-key implementations :)