Fortunately I have enough of the rar parts to extract the data I want but damn.
this post was submitted on 07 Sep 2026
317 points (99.4% liked)
Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ
70621 readers
689 users here now
⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.
Rules • Full Version
1. Posts must be related to the discussion of digital piracy
2. Don't request invites, trade, sell, or self-promote
3. Don't request or link to specific pirated titles, including DMs
4. Don't submit low-quality posts, be entitled, or harass others
Loot, Pillage, & Plunder
We heartily recommend visiting the free port of freemediaheckyeah (aka FMHY) while you sail the high seas, for all the freshest links the ocean has to offer.
📜 c/Piracy Wiki (Community Edition):
🏴☠️ Other communities
FUCK ADOBE!
Torrenting/P2P:
- !seedboxes@lemmy.dbzer0.com
- !trackers@lemmy.dbzer0.com
- !qbittorrent@lemmy.dbzer0.com
- !libretorrent@lemmy.dbzer0.com
- !soulseek@lemmy.dbzer0.com
Gaming:
- !steamdeckpirates@lemmy.dbzer0.com
- !newyuzupiracy@lemmy.dbzer0.com
- !switchpirates@lemmy.dbzer0.com
- !3dspiracy@lemmy.dbzer0.com
- !retropirates@lemmy.dbzer0.com
💰 Please help cover server costs.
 |
 |
|---|---|
| Ko-fi | Liberapay |
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's the file headers, right? Without those, they are unreadable. 🫠
It's never that .txt file that says where it was originally uploaded
I'm missing the NFO file, 250KB of one of the rar parts and 300KB of a video sample.
Ouch!
Often rars in torrents have a bit of redundancy so the source files can be recovered even if the rar isn't complete
I had one at 62% for years I watched peers come and go but never lost hope. Today it's at 99%. All I'm missing are some padding files so basically 100%.
There's me and one other peer who seems to be willing to seed until the end of time. My ratio keeps climbing so I assume someone somewhere is thankful
I’ve replied this to another comment already, but it is probably this:
I wonder how viable it would be to bruteforce it. Not a serious proposal but still fun to think about
It absolutely could be brute forced, we litrally have the hash of the chunk. I've thought about it before too, if one seeder is constantly giving, or refusing to even give, the chuck because of the hash mismatch, odds are it's only a bit flipped somewhere.
Another option that I've done before is find the file elsewhere, and switch it out. Seed for a long time then, you weren't the only person at 99.9%.
SHA1 has a fairly even distribution, it produces 160 bit digests, so each possible variation of a chunk will have a roughly 2^-160^ probability to hit your hash. Now assuming you have some insane computing device that can do an exahash per hour (that's 10^18^ hashes, a lot more than any modern hardware can do), finding one would take around 1.7E+26 years. Now the funniest part. Assuming your chunk is 32KiB large (practically nobody uses such small chunks today, so it's the best-case scenario), there are 2^(32×2^10^×2^3^)/2^160^ possible variations of the chunk that would produce your exact hash. That's roughly 1.1E+78865 fitting chunks with only one being correct. And it takes you 1.7E+26 years to get to just one of them.
Yea, I wouldn't say that.
This should be the next cryptocurrency proof of work algorithm
Bitcoin uses two rounds of SHA256 if I recall correctly.
This is why recovery info for archives is a boon - sadly it's pretty out of fashion.
The problem is there will be multiple solutions that result in the same hash (collisions), but only one of them will be correct
And it would take an extremely long time to find them all, I don't even think a modern GPU could do it in a lifetime
It looks like bittorent version 2 hashes with sha-256 at a 16kb resolution.
Seems like that should be easily parallelizable and can fit into thread memory on a modern GPU.
It would just depend on how many 16kb blocks are remaining in that 0.1%
Well the hashes are always much smaller than the actual data, otherwise downloading the hashes would take just as long as downloading the data lol.
So 16KB blocks means 131072 bits per block, subtract the 256 bit hash size and that means 2^130816 hash collisions
That's a lot lol, you'll never find which one is the correct one. Even if you instantly had a list of all values that match the desired hash, you'd have to check them all and somehow determine which one was correct.