Are there known programs or methods to reverse engineer small sets of missing data from a torrent? For example, say I'm at 99.9% complete and I'm missing a notepad file with a single word written on it. Would it be possible to somehow generate the missing notepad file so that it matches the original 1:1 and then force recheck and complete the stalled torrent?
Reverse engineering missing torrent files
Other urls found in this thread:
security.stackexchange.com
stackoverflow.com
twitter.com
No because there are no unique solution
Yea, just find all the people who originally built it and pay them to do it again while also finding the right technology that lets them do it from the past.
That jerk needs to stop leaning on those monitors.
What you described can be achieved with parity files. For example, in the old days, warez posters would post several parts of an archive and also include parity archives, which can be used to replace a single other archive.
This doesn't have anything to do with torrents though.
Actually yeah there is. Due to how the checksum works, there is exactly one solution.
Theoretically you could generate random files until you find one that matches the hash, but this process will be incredibly slow. May not be feasible in practice, tho
not really, depends on the hash
if it's literally one bit then sure
but past a certain point there will be multiple solutions as there are more possible files than there are possible hashes, which means multiple files hash the same
Modern hashing functions are designed to not have any collisions at all. If they did then computer security would not work.
it's simply impossible that there can't be, there are more possible files than possible hashes
If that were true then a malicious attacker could shit up a torrent by hosting bad data that passes checksum matching. I'd like to think that isn't possible
it is theoretically possible, in practice it doesn't really work with sha256 and co, computing random data that's the same size that matches the checksum would take too long, it's just a matter of computing power, not theoretical complete security
for reconstructing an incomplete file, you'd need a certain amount of data already, and I'm not sure if that's something like 70% or 99.9%, that's what I was getting at really, it would be interesting to know though, maybe I can one-up those people who seed at 1kb/s until I'm nearly done
Not gonna lie, I'd like to know too. I found this stackoverflow.com
huh, I never knew there was a name for this
it's pretty fitting
> Lemme know if u find out anything
yeah idk anything about the maths behind it really
Is that a Supreme Commander map on the top left?
That game was awesome
The moment you manage to do it, the hash algo becomes unsecure.
It you manage to do it, feel free to show it to the hashing algorithm creators and NIST and make it into the tech news
I finally found an user who thinks like I do. I love parchive.
Update: there must be collisions, but I'm assuming that they're so rare and require too much computation to find, so it just hasn't happened yet. This should be indicative that it's not practical to use reverse hashing to find the key.
In fact, this is what the entirety of computer security is based on : it's unfeasible to crack due to the work required
riddle me this:
1) how many different files can be expressed with SHA-256 hash
2) how many different files you can create that are exactly 256 bit in size
I revise my statement. As long as the input size is
aesthetic