Create 2 torrents with the same hash.
Release one into the wild.
Wait.
Infect.
Release one into the wild.
Wait.
Infect.
Probabilistically, the hashes of the parts would not match even if the top level hash matched.
Also, and more importantly, this isn't a preimage attack so replacing an existing torrent's SHA-1 hash with a malicious one isn't computational possible.
A hash collision can still be used as an attack if you create 2 torrents with the same hash and then distribute.
The "good" torrent would not be susceptible to attack via this receiving the entire torrent file directly (say over HTTPS) is fine.
[1] https://torrentfreak.com/the-pirate-bay-dumps-torrents-12022...
Then join the torrent with a client that doesn't download but only upload that block (there will be some that will pick it from you). Many legit copies, except for those that were so unlucky to fetch the block from you.
If you manage to build such a block based on one in recurring content (eg. a distributor's logo at the beginning of the file), it could be reused, too.
Except you can't do that as this isn't a preimage attack. You can't create an arbitrary bad file matching an existing SHA-1 with this.
No you can't do that either. Again, this is not a preimage attack: https://en.wikipedia.org/wiki/Preimage_attack
That means you can't use this to match an arbitrary SHA-1. That means you can't use it to generate bad parts of a larger file.
What you're describing is already possible by having clients connect to a swarm, pretend they have parts of a file, and send gibberish. The receiver won't know until they finished downloading the part and hence waste the part-size in download capacity (i.e. DOS). I bet with IPv6 it'd be really easy to have a single malicious client pretend to be a world of swarm members.
Like a third party binary driver?