music
The Pirate Bay un-SSL
Theory
Recently, the world saw The Pirate Bay offering SSL encryption on their server.
This means that your ISP won't know anymore which torrent you are
downloading, right? Wrong.
HTTPS is quite useless for
protecting static and
public content. By static,
I do mean the .torrent file itself. It is
always the same. By public,
I do mean than one doesn't need any kind of authentication to pick up
the content. It's always the same, for everyone. For crawlers,
too.
So, one could easily index (a portion of) The Pirate Bay
torrent database by the Content-Length. Then, one could
intercept some encrypted traffic between some machine(s) within his/her
network and the torrents.thepiratebay.org
server. Knowing both (encrypted) request and response lengths, it is
possible to get a quite reliable list of matches from the previously
indexed torrent list.
Practice
Don't try this at work, or you might hurt yourself 
- Use Wireshark to capture some torrent
downloads. Torrents are hosted on a separate server, which makes the
task easier yet. Just use the following capture filter:
"tcp and port 443 and host torrents.thepiratebay.org" - Now, just go with the stream
("Follow TCP Stream"
for the packet you suspect belongs to the torrent download. This will
create another filter, just like "(ip.addr eq 192.168.0.10 and ip.addr eq 83.140.176.156) and (tcp.port eq 2157 and tcp.port eq 443)") - Just save the displayed stream anywhere else (
pcap1.pcapsounds nice) - Now, use my quick&dirty TPB-TLSlen.pl Perl script to get
the request/response lengths:
Yeah, I know, it is nasty. It only supports the TLS cypher. And it simply calls the
perl TPB-TLSlen.pl pcap1.pcap
tshark(the command line version of Wireshark) to parse it's output. - Now, just paste the REQ
and RES
values below

(note that the REQ value is optional, setting it to 0 simply ignores the request size for matching)

Precision
The following size distribution chart was generated using the database with ~165K torrents:

There's also a major peak for the 454 bytes torrents. However, bigger torrents are less common, thus, the size detection technique becomes more precise. Now, the average "distance" between torrent sizes is ~44 bytes (at least for the sample I've collected). So, adding a cookie with the random size up to 128 bytes will disrupt the size matching detection a lot. The request size disruption is even easier: the largest torrent URI I've found was 150 bytes-wide. Thus, padding every request URI to match 150 characters is enough to make the requests completely indistinguishable. Joining the pieces (the padding add-on strings are bold):
GET /4319199/[a4e]Ghost_in_the_Shell_TV_01-26.4319199.TPB.torrent?nVM2UGfcG533un4ym70eT2
9r0WwBLYdmFCNN+UTV/hiJ7EAXdFU5KfdWHpkB5lXaCmITsACKOPVyjmpbaOB+CrI5 HTTP/1.1 Host: torrents.thepiratebay.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208
Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://thepiratebay.org/recent Cookie: language=pt_BR; country=BR; PHPSESSID=ad6cb7e414c8dc88e0c2444f6215165a HTTP/1.1 200 OK Content-Type: application/x-bittorrent Etag: "2198642509" Last-Modified: Mon, 28 Jul 2008 22:28:59 GMT Server: lighttpd Content-Length: 91601 Date: Mon, 28 Jul 2008 22:37:56 GMT X-Varnish: 108010229 107999438 Age: 253 Via: 1.1 varnish Connection: keep-alive Set-Cookie: p=68eOfxOC7JwBYcMe1RJWC4Z5PV/lJzqJORW8KROPMH9zQhszSjFnRp2tsNWEoyabWAloneUaoz
MxYtx4hoM9MZUKE/7wGzC3ZKLEZdppG4og3W; expires=Mon, 28-Jul-2008 22:37:56 GMT; path=/;
domain=torrents.thepiratebay.org (binary torrent data)
Solution
- Use a constant padding in the
.torrentfiles. This messes things a bit, but stills ineffective. The only advantage is not messing up with the server
- Patch the lighttpd server so it sends a non-lasting cookie with a random size.
Thanks
- MEGA Hospedagem, for the network
resources provided for this tiny research

- http://www.warchalking.com.br/,
for the inspiration

Encrypted session data
Possible matches
| The Pirate Bay URL | strlen(URI) | torrent size |
| 0 matches | ||
| Torrents indexed: 961988 | ||
|
stas » July 31, 2008 » 11:05
attachment » 8 comments » 12217 reads
|
my ring tones

A collection of the ring tones I made for my Sony Ericsson T68i mobile phone. All of them (except As The Worm Turns, which notes my brother gave to me!) were converted from a Google-gathered MIDI file using the excellent Ringtone Tools software. Why?! Just because I like these melodies; and because I think they are pretty distinctive ringtones!
P.S. - and yes, I didn't respected the tempo, for several reasons!
|
stas » January 3, 2007 » 22:12
|
Diamond Rio PMP300 FS-plugin

Diamond Rio PMP300, with only 32 MB of flash memory, was the second portable MP3 player ever released, in 1998. Unfortunately, such a revolutionary piece of hardware is very painful to interface with: as it is connected through parallel port, highest transfer rates achieved were around 80 KB/s. And the software bundled with it was too primitive. To the luck of thousands of (un)happy Rio owners, The Snowblind Alliance released their Open-Source RIO utility, which became a starting point of several alternative Rio manager interfaces. Mine is just one of them

First of all, there's absolutely no need to write the entire file manager. Total Commander (TC for short) is one of the most feature-rich file managers ever made, and it supports a very extensible plugin API. As a result, one could use TC to manage files directly on the flash memory of his/her Rio! Actually, my plugin supports listing, uploading, downloading & deleting files from Diamond Rio PMP300 internal memory. It also displays the transfer speed and the total/remaining space. Take a look at this screenshot to see it in action. Behind the GUI, my plugin uses the source of the "RIO utility v1.07" by The Snowblind Alliance.
Installation:
Just the same as for many other FS-plugins:- Unzip
rio.wfx&rio.cfgfiles to Total Commander directory - Choose "Configuration => Options => Operation => FS-Plugins"
- Choose
rio.wfx - Click OK.
- You can now access the plugin in the "Network Neighborhood"
- Open
rio.cfgfile and set the correct LPT port address (see below for more details)
Configuration:
In the majority of cases, the plugin may work fine "out-of-the-box". If it doesn't work at all, probably you'll need to discover and specify your PC's parallel port hardware address. Open your system's "Device Manager" (on Windows XP, open the context menu for "My Computer", click "Properties", go to the "Hardware" tab, and click the "Device Manager"). Go straight to "Ports (COM & LPT)". Now locate the port that your Rio device is attached. On my case, it's LPT1. Double-click "Printer port (LPT1)", and go to the "Resources" tab. You need the first one of "I/O Range" numbers:
378 is what you need. Note that this number is in a hexadecimal format. Thus, many programs (like my plugin) may accept it as 0x378. Now, open the
rio.cfg file. It looks like this, by default:# Assume that Rio is connected to LPT1
IOPort 0x378
# default
IODelayInit 20000
IODelayTx 100
IODelayRx 2
# "turbo" mode (UNSAFE!!!)
#IODelayInit 5000
#IODelayTx 1
#IODelayRx 1
IOPort parameter to the value you discovered.Note all that
IODelay* parameters. For the safety reasons,
the delays are high by default, and, consequently, the file transfer is
slow. If you comment out the default values and uncomment the turbo
mode ones, you'll get a great increase in performance! But remember to
only use it when your Rio battery is 100% charged, and when your Rio is
turned on. It may corrupt some bits, through.|
stas » May 6, 2006 » 00:26
5 attachments » add new comment » 9406 reads
|
rockin' PC speaker
. Thus, it is perfect for
communicating critical states. But the default system beep is quite
boring, and makes difficult to distinguish different events that are
being communicated. So, here's my humble attempt to make a highly
portable function that is able to play simple non-polyphonic music on
the PC speaker. I used it originally to advise when someone tried to
log in to my system through SSH daemon (thus the name "daemoniac" - demoniac
. It was tested (and worked fine!) under:
- DOS (DJGPP, Turbo C)
- Windows 9x/NT/2K/XP (Borland C, Microsoft Visual C, MinGW)
- Linux (gcc)
- FreeBSD (gcc)
demoniac will play Iron Maiden - Fear Of The Dark beginning. You can also compile it to play the simple "A#4 D#5 G5 A#5 G5 A#5" melody. Note that on UN*X systems, demoniac accesses hardware directly, and thus requires to run as root user. It's safe, through: it
won't accept any command line arguments and neither process environment
variables, so, at least, it can't be exploited with some buffer
overflow technique. For detailed instructions about compiling demoniac on
different compilers/systems, read the comments at the start of the
source. Note that my package provides all the binaries generated on
compilers/systems listed above.|
stas » April 20, 2006 » 02:06
attachment » add new comment » 5810 reads
|





