MySpace Private Pictures Leak

Martin writes "We all heard about the MySpace vulnerability that allowed everyone to access pictures that have been set to private at MySpace. That vulnerability got closed down pretty fast. Unfortunately though (for MySpace) someone did use an automated script to run over 44,000 profiles that downloaded all private pictures which resulted in a 17 Gigabyte zip file with more than 560,000 pictures. The zip file is now showing up on popular torrent sites across the net."

Comments

You know what to do...

[grub]

fetch!

Re:You know what to do...

[JeepFanatic]

If you read the wired interview, it says:

DMaul: The script that I wrote uses the myspaceprivateprofile.com interface to find the images. Therefore, it uses the same criteria. From my own testing, it appeared that myspaceprivateprofile.com did not return public images from public profiles. It only returned public images from private profiles. It did not return private images from either public or private profiles.

So ... I'm guessing the really good stuff isn't there.

I've looked. Yaaaaawn.

[jridley]

I downloaded the first zip, which is the first GB of images. I unzipped it, and I looked at the first 4500 images before falling asleep. 999 out of 1000 are crappy cellphone pics of ugly people drinking a beer and flipping off the camera, or vacation pics, or pics of someone's crappy car, or just simply snapshots of people (the vast majority).
So far out of 4500 images, I found exactly zero images that I think anyone would give a crap about. I'm not even sure why the vast majority of them are even bothered marking private; nobody would care about them at all.

Re:Dueling compression algorithms

[_xeno_]

In case you're new at this: a torrent file can contain more than one file, organized unto subdirectories. There's no need for any encapsulation.

Sure there is. Ignoring the way BitTorrent actually encodes the information, and assuming that somehow every file name could be stored as one byte (ignoring the obvious flaw with that), by keeping all of them at the torrent level you'd require "more than 560,000" bytes just devoted to file names. Since the general rule of thumb is to keep the actual .torrent file around 100KB, give or take, that's right out.

Now, throwing in the way the .torrent file actually stores the list of file names, you're looking at at least 21 bytes per file. Assuming 560,000 files, that bloats the .torrent file to over 11.2MB - and that's still not realistic, because it requires every file to be less than 10 bytes in size and all of them to have empty path names. (Which is obviously not valid.)

Throw in realistic constraints, and you're adding another 15 bytes, bringing us to a total of 36 bytes per file - bloating the .torrent to 19.2MB, just for file names.

So, in short, the reason to place them in a ZIP file and not use the multi-file feature is because using the multiple file feature would massively bloat the .torrent file. Now the final .ZIP file has similar requirements per file in the ZIP file, but that becomes payload as part of the BitTorrent download and not something that has to be downloaded via non-BitTorrent means first.

Finally, for an explanation of where those numbers above come from, the "smallest possible" form for a file would be:

"d6:lengthi0e4:pathlee" (21 bytes)

The "more realistic constraints" brings that to:

"d6:lengthi100000e4:pathl8:0000.JPGee" (36 bytes)

Yes, the .torrent file is essentially "plain text" although the piece hashes are stored as binary strings. It's encoded using "Bencoding" - which isn't the most compact of formats.