[00:05:50] *** KyleK_ has quit IRC
[00:06:54] *** kwinz2 has quit IRC
[00:13:23] *** stalled has joined #bittorrent
[00:30:25] *** rrr_ has quit IRC
[00:44:27] *** rrr has joined #bittorrent
[00:52:55] *** kwinz2 has joined #bittorrent
[00:54:05] *** cgreco has quit IRC
[00:58:14] *** cgreco has joined #bittorrent
[01:07:36] *** rrr has quit IRC
[01:10:36] *** andar2 has quit IRC
[01:15:26] *** cgreco has quit IRC
[01:33:50] *** rrr has joined #bittorrent
[01:33:57] *** rrr has quit IRC
[01:36:49] *** rrr has joined #bittorrent
[01:54:17] *** goussx has quit IRC
[01:56:55] *** Andrius has quit IRC
[01:57:18] *** rrr has quit IRC
[02:03:14] *** ryanprior has joined #bittorrent
[02:12:48] *** rrr_ has joined #bittorrent
[03:03:02] *** bittwist has quit IRC
[03:13:05] <Switeck> "Well the map said it'd be here!"  http://www.straightdope.com/columns/read/1058/do-maps-have-copyright-traps-to-permit-detection-of-unauthorized-copies
[03:13:39] <Switeck> In an attempt to prevent people from copying...maps in this case...fake locations are included on it.
[03:14:44] <Switeck> Makes me wonder if there been any examples of something designed specifically to foil BitTorrent by containing nonsense.
[03:20:03] <DeHackEd> you can upload a junk file to $SITEOFYOURCHOICE and claim it's the new harry potter movie
[03:22:09] <Switeck> I was thinking more like a certain byte combination might be mistaken as BitTorrent protocol traffic
[03:22:39] <Switeck> ...though that'd likely only affect buggy BT clients, as such sequences could only appear in places reserved for data
[03:35:55] <chelz> swarm poisoning
[03:36:33] <chelz> i don't know the details but after a certain amount of times of sending bad data most clients will ban that peer
[03:37:39] <Switeck> This is different...this is a file that passes hash check that does it
[03:37:57] <TheSHAD0W> \
[03:42:47] *** bittwist has joined #BitTorrent
[03:56:38] *** The_8472 has quit IRC
[03:56:59] *** wadim has joined #bittorrent
[03:57:01] *** wadim is now known as The_8472
[04:01:58] *** init0 has quit IRC
[04:05:25] *** init0 has joined #bittorrent
[04:19:01] <DeHackEd> Switeck: to the best of my knowledge SHA1 collisions don't exist (yet), which leaves you with the garbage upload scenario I described
[04:19:22] <Switeck> This isn't a case of SHA1 collisions
[04:20:04] <Switeck> this is data pre-made to be "resistant" as it were to becoming a bittorrent torrent, because it might (somehow?) cause weirdness in BT clients mistaking the data for BT protocol
[04:20:23] <Switeck> purely hypothetical of course. :P
[04:20:37] <DeHackEd> ...no
[04:21:29] <Switeck> No?!
[04:21:32] <Nolar> protocol and file are pretty well separated
[04:21:58] <Switeck> BitComet's x-byte padding files for instance XD
[04:22:14] <DeHackEd> you make it sound like bittorrent reads bytes recieved searching anywhere for where the protocol begins. doesn't work that way
[04:22:44] <Switeck> of course it doesn't
[04:22:46] <DeHackEd> the protocol begins at byte 0. the protocol will say "here's 16K of file, from chuck #44 starting at 128K in:  <omitted for brevity>"
[04:22:54] <Switeck> I'm *ASKING* if such is even REMOTELY possible
[04:23:35] <DeHackEd> someone could write a seriously buggy client that acts up on the data stream. but I'm going to say no.
[04:23:55] <Nolar> agreed
[04:23:58] <Switeck> From what I have seen just in the last week, I think someone might exploit bugs in existing clients
[04:24:19] <Nolar> good clients do integrity checks on the protocol data that comes across
[04:24:29] <Switeck> ha ha ha ha!
[04:24:37] <Switeck> um...they're failing pretty miserably at that
[04:24:39] <DeHackEd> I run a python client. it's basically immune to buffer overruns
[04:24:41] <Nolar> but file data is just a bunch of ones and zeros, clients dont care what's inside
[04:25:10] <Nolar> <Switeck> From what I have seen just in the last week, I think someone might exploit bugs in existing clients  << such as?
[04:25:19] <Switeck> When my torrent client was trying to connect to a "peer" at 0.0.0.0 and then later another on 255.255.255.255
[04:25:23] <Switeck> ...something's wrong
[04:25:44] <DeHackEd> oh, someone just poisoned DHT or PEX.
[04:25:44] <Nolar> means your client doesnt check for valid ips
[04:25:59] <Switeck> last week was a case of just me and 1 other person on a torrent, yet we kept getting a 3rd ip which ended in .0
[04:26:05] <Switeck> Nolar, correct
[04:26:45] <Nolar> i'm sure there a lots of clients out there that dont check such
[04:26:57] <Switeck> The other one was I was constantly getting disconnected when trying to seed to the peer...because the peer kept returning the error message "disconnect: not downloading"
[04:27:13] <Switeck> (Of course I wasn't downloading! I was the seed!)
[04:27:46] <Nolar> these are cases of bad behavior more than any kind of real attack
[04:28:06] <Switeck> neither of us were trying to do bad behavior
[04:28:40] <Nolar> my point is, you're not going to poison the swarm with anything like that
[04:29:24] <Switeck> not a pre-existing swarm, no
[04:29:59] <Nolar> anybody coding up a client could do an off-by-one error and read in an extra byte when decoding headers, causing the rest of the stream to bork
[04:30:12] <Switeck> but what sort of trouble does BitComet's padded torrents cause? (padded with fake files so every "real" file begins on a hash start)
[04:30:21] <Nolar> but that doesnt mean you can break my client :)
[04:31:07] <Nolar> worst case is the seeder borkes the byte offsets and spews bad data
[04:32:11] <Nolar> (although usually i just hear folks complaining about not being able to read the existing data when the switch to a better client ;)
[04:32:21] <Switeck> another one recently was multi-file torrent web seed being silently self-banned due to a bug
[04:33:16] <Switeck> well, self-banned is the wrong words...but banned by the downloading client
[04:33:42] <Nolar> all it takes is one byte off
[04:33:58] <Switeck> probably selects a piece that overlaps 2 files and tries to download it by calling the wrong file
[04:34:19] <Nolar> sounds reasonable
[04:34:39] <Nolar> file vs piece boundaries can be real tricky
[04:36:40] <Switeck> Or for more fun, combine the 2
[04:36:59] <Switeck> a web seed on a .torrent that was made using BitComet that added padding files.
[04:38:23] <Switeck> (The web seed of course would be lacking the padding files)
[04:45:29] <DeHackEd> there is no (legal) cure for stupid
[04:47:03] <Switeck> I only bring up that as an unlikely scenario
[04:47:40] <Switeck> If it was likely, I've probably already seen it
[05:02:09] <Switeck> http://www.utorrent.com/forum/viewtopic.php?id=36664
[05:02:31] <Switeck> not quite the web seed + BitComet padded file scenario...but closest found
[05:03:08] <Switeck> "a bug that hasn't been resolved yet caused by data at the file boundarys"
[05:25:41] *** andar has quit IRC
[05:40:34] *** deltab has quit IRC
[05:40:56] *** deltab has joined #bittorrent
[05:44:06] *** ryanprior_ has joined #bittorrent
[05:50:46] *** ryanprior has quit IRC
[06:06:57] *** GTHKn has joined #bittorrent
[06:06:57] *** GTHK has quit IRC
[06:10:33] *** andar has joined #bittorrent
[06:12:07] *** MassaRoddel has quit IRC
[06:19:50] *** ryanprior_ has quit IRC
[06:48:51] *** Pharticus has joined #bittorrent
[06:55:58] *** GTHKn has quit IRC
[06:59:25] *** goussx has joined #bittorrent
[07:09:49] *** auntieNeo has left #bittorrent
[07:36:01] *** chelz has quit IRC
[07:39:29] *** Switeck has quit IRC
[08:03:14] *** andar has quit IRC
[08:03:52] *** andar has joined #bittorrent
[08:54:27] *** MassaRoddel has joined #bittorrent
[09:56:18] *** kwinz2_ has joined #bittorrent
[09:57:58] *** KyleK_ has joined #bittorrent
[10:01:16] *** kwinz2 has quit IRC
[10:33:29] *** kwinz__ has joined #bittorrent
[10:38:46] *** kwinz2_ has quit IRC
[10:59:51] *** kwinz__ has quit IRC
[11:00:31] *** kwinz2 has joined #bittorrent
[11:04:27] *** cgreco has joined #bittorrent
[11:38:44] *** kwinz2 has quit IRC
[11:47:26] *** KyleK_ has quit IRC
[11:54:47] *** kwinz2 has joined #bittorrent
[12:00:51] *** Guest776 has joined #bittorrent
[12:01:40] <Guest776> Morning all! Does anyone know what outbound ports I would need to open to get bittorrent to work through a firewall that has all outbound connections blocked by default?
[12:02:36] <alus> Guest776: which client are you using?
[12:02:59] <Guest776> Hiya, at the moment Vuze, but open to other options
[12:03:14] <alus> most clients use ephemeral outbound ports, but some let you set the bind port. you should just open the port you chose to bind to in the client
[12:03:32] <alus> I'm not familiar with Vuze's options here, but you could ask in #azureus
[12:04:27] <Guest776> I have one port specified for incoming TCP/UDP to allow NAT, but I currently have all outbound connections allowed. I think this will break horribly if i start to use a "proper" firewall and block everythign by default
[12:05:04] <Guest776> But yeah, I'll have a wander over to the Azureus room also. Cheers
[12:20:16] *** Guest776 has quit IRC
[12:31:26] *** MassaRoddel has quit IRC
[12:55:01] *** Andrius has joined #bittorrent
[15:15:32] *** ChoyKloun has joined #bittorrent
[15:15:58] <ChoyKloun> hey what software does router.bittorrent.com run .. ? i crashed it accidentally with a valid dht packet a while ago and it'd be good to report
[15:16:13] <ChoyKloun> i'd guess some utorrent based but cant repeat it with normal utorrent
[15:24:49] <The_8472> poke alus, he might know
[15:30:37] <ChoyKloun> ok so lets see what happens if i do 1 curve25519 exchange per peer discovered while announcing a torrent
[15:30:41] <ChoyKloun> on my crappy laptop
[15:30:46] <ChoyKloun> and store the resulting keys
[16:22:11] *** Andrius has quit IRC
[16:30:28] * TheSHAD0W suspects ChoyKloun is trying to turn BitTorrent into a distributed brute-force engine
[16:53:03] <ChoyKloun> hahahhah
[16:53:10] <ChoyKloun> would be fun
[16:53:16] <ChoyKloun> although curve25519 isnt exactly widely in use
[16:53:46] <ChoyKloun> maybe someone good at math can figure out a way to use it for that though :PPP
[16:54:15] <ChoyKloun> im not good enough at elliptic curve math
[16:54:36] <ChoyKloun> but with unsigned diffie-hellman, wouldnt it be possible to use it for a distributed attack on some DH exchange ?
[16:57:27] *** Andrius has joined #bittorrent
[17:04:02] <ChoyKloun> btw my dht implementation is named jchgout.. get a dictionary if you want to know the meaning in khmer :P
[17:06:34] *** GTHK has joined #bittorrent
[17:07:41] <ChoyKloun> (its a mix of a certain persons nickname and the word for idiot/retard/madman :P)
[17:30:29] *** andar2 has joined #bittorrent
[17:42:04] <ChoyKloun> btw
[17:42:13] <ChoyKloun> what is the "normal"/"average" distance in dht nowadays
[17:42:22] <ChoyKloun> with simple stupid routing i get quite low values
[17:43:55] <The_8472> v4 is about 20-23 buckets deep
[17:48:23] <ChoyKloun> from latest quick test run: s 1261665732 Node 187.60.98.248:45894 distance 0x00131f70 best 0x00000181 worst 0xe2a553d9 nodeID C9022F7B44EB171576A3211E3077EADC5427136D00
[17:48:27] <ChoyKloun> s 1261665732 Node 60.52.127.81:17720 distance 0x000ba78c best 0x00000181 worst 0xe2a553d9 nodeID C91A97871F97241EEC89077921F0CB58BFA7942500
[17:48:30] <ChoyKloun> s 1261665732 Node 114.128.178.205:13511 distance 0x000ae735 best 0x00000181 worst 0xe2a553d9 nodeID C91BD73EF5221AA2FFC8C3C2B463CDB28FF770ED00
[17:48:34] <ChoyKloun> with like 2k clients learned
[17:48:51] *** Andrius has quit IRC
[17:48:55] <The_8472> idk how you calculate your distances
[17:49:06] <ChoyKloun> like the dht spec says... xor? :P
[17:49:08] <ChoyKloun> distance metric
[17:49:49] <The_8472> yeah, but that's 20 bytes. you have to convert it into a bignum and then take the logarithm to get a reasonable measure
[17:49:58] <The_8472> or count the leading zero bytes
[17:50:02] <The_8472> *bits
[17:50:05] <ChoyKloun> afaik the standard is to just use the first 32 bits
[17:50:11] <ChoyKloun> its totally randomly distributed anyways
[17:50:23] <The_8472> not for distances
[17:50:40] <The_8472> since neighbored nodes share a prefix of several bytes
[17:50:44] <ChoyKloun> has the guilty person been shot yet?
[17:50:51] <The_8472> huh?
[17:50:55] <ChoyKloun> :PP
[17:51:01] <ChoyKloun> i mean
[17:51:01] <The_8472> oh
[17:51:02] <ChoyKloun> bignum
[17:51:02] <ChoyKloun> come on
[17:51:04] <ChoyKloun> must be a better way
[17:51:05] * The_8472 shoots ChoyKloun
[17:51:13] <ChoyKloun> not guilty of THAT
[17:51:22] <ChoyKloun> guilty of screwing up dht so it needs bignums!
[17:51:43] <The_8472> bignum is only necessary if you want to do some precise math on distances. otherwise just xor on the 20-byte-arrays is good enough
[17:51:50] <ChoyKloun> ah k
[17:52:00] <ChoyKloun> could write some optimized compare functions
[17:52:06] <ChoyKloun> very simple
[17:52:14] <The_8472> xor for routing, bignum and bitcounting for human representation, node density estimates etc.
[17:52:20] <ChoyKloun> the value with the most significant bit set is bigger
[17:52:29] <ChoyKloun> ya thats araw dump
[17:52:55] <ChoyKloun> what is the proper protocol to follow when extending dht?
[17:53:11] <ChoyKloun> free to just add a new query for example ?
[17:53:29] <The_8472> won't work since 99.9% of the nodes won't support it
[17:53:34] <ChoyKloun> ya but still
[17:53:40] <ChoyKloun> im not thaaaat stupid
[17:53:41] <ChoyKloun> crazy yes
[17:53:42] <ChoyKloun> stupid no
[17:54:14] <The_8472> so you basically have to write up a proposal, it gets discussed and then a BEP draft is written + people do experimental implementations
[17:54:18] <The_8472> see the BEP32 process
[17:54:28] <ChoyKloun> or i can just include the kex data in the ping query/resp
[17:54:31] <ChoyKloun> ya
[17:54:35] <ChoyKloun> i just wanna do a quick test
[17:54:42] <ChoyKloun> to see if its at all feasable performance wise
[17:54:53] <The_8472> well, then there's no need to deploy anything
[17:54:58] <The_8472> you can do what you want locally ^^
[17:55:11] <ChoyKloun> i want some real traffic etc.
[17:55:42] <The_8472> well, then you need an implementation compatible with the rest out there
[17:55:56] <ChoyKloun> what i need to do currently is just
[17:56:02] <The_8472> adding additional values to existing requests/responses should work since bencoding just ignores unknown keys
[17:56:13] <ChoyKloun> 1. see how much data overhead it generates when sending and how it actually affects my poor cambo dsl connection
[17:56:38] <ChoyKloun> 2. how much cpu time is spent calculating a shared key (well the other end wont supply a public value obviously so it'll be bogus)
[17:56:41] <ChoyKloun> ok
[17:59:00] <The_8472> well, the CPU time can be done completely locally, without sending anything
[17:59:11] <ChoyKloun> but not full reallife timing etc
[17:59:31] <The_8472> as for the bandwidth, it's more complicated than that because you'd have to do 3-way communication instead of ping and pong.
[17:59:51] <The_8472> well, you can just invoke one everytime you send a packet
[17:59:53] <ChoyKloun> not for a simple KEX
[18:00:03] <ChoyKloun> i use a local store of current key
[18:00:09] <ChoyKloun> and if they get out of sync i re-kex
[18:00:20] <The_8472> useless. 90% of the nodes you visit you'll never see again during lookups.
[18:00:32] <ChoyKloun> its exactly stuff like that i wanna see for myself
[18:16:32] <ChoyKloun> ok now itsgetting peers
[18:16:42] <ChoyKloun> and doing the first half of the key exchange
[18:16:49] <ChoyKloun> (and sending the resulting pub value in each ping packet :P)
[18:22:29] *** ChoyKlou1 has joined #bittorrent
[18:26:16] *** ChoyKloun has quit IRC
[18:33:33] <ChoyKlou1> hmmmm.. is there any max len to trans id ?!
[18:34:36] <ChoyKlou1> hmmmm.. is there any max len to trans id ?!
[18:34:58] <ChoyKlou1> or maybe its just my plastic pieceof shit chinese router acting up
[18:37:32] *** The_8472 has quit IRC
[18:37:52] *** wadim has joined #bittorrent
[18:37:54] *** wadim is now known as The_8472
[18:39:35] <ChoyKlou1> argh
[18:39:47] <ChoyKlou1> i wanted to include a lot of shit in the transid
[18:39:52] <ChoyKlou1> but longer than about 4 bytes and no responses
[18:39:53] <ChoyKlou1> !#!@!
[18:43:23] <ChoyKlou1> anyway.
[18:43:31] <ChoyKlou1> one key exchange per trans is definitely doable for any dht client
[18:43:44] *** ChoyKlou1 is now known as choykloun
[18:45:34] <The_8472> consider embedded systems.
[18:45:41] <The_8472> and you also have to consider incoming traffic
[18:46:15] <choykloun> ya
[18:46:22] <choykloun> just saying its within the realistic realm
[18:46:39] <choykloun> will be implementing this kex algorithm on hundreds of embedded systems soon actually
[18:46:43] <choykloun> although for another purpose entirely :)
[20:08:23] *** goussx has quit IRC
[20:13:23] *** BentMyWookie has quit IRC
[20:34:37] *** Miller` has quit IRC
[20:35:38] <alus> choykloun: how do you know you crashed it?
[20:41:13] <choykloun> when i sent a package it stoppe responding to udp
[20:41:19] <choykloun> and when i sent the same packet to the other host it also stopped
[20:41:20] <choykloun> ..
[20:42:41] <choykloun> will see if i still have the code to reproduce
[20:43:19] <choykloun> think it had to do with the transid iirc
[20:45:58] <choykloun> seems that most clients get a bit upset if you send a transid longer than 4 or so bytes..
[21:45:15] *** Switeck has joined #bittorrent
[21:52:31] <burris> ha ha isohunt
[21:53:26] <burris> "the Fung websites have honorary ranking systems for those who posted a certain number of forum users messages; ranks include titles such as ?I pir4te, therefore I am? and ?All Day I Dream About W4rez.?"
[21:55:38] <burris> "In a post on the website Podtropolis, moderator ?NewAgePirate? responded to a user who posted a list with films such as The Godfather, Clockwork Orange, and One Flew Over the Cuckoo?s Nest, with a post that stated ?Great list by the way man. Great to have you here.?"
[22:59:18] *** kwinz2_ has joined #bittorrent
[22:59:18] *** kwinz2 has quit IRC
[23:01:51] *** _rafi_ has quit IRC
[23:52:26] *** goussx has joined #bittorrent
[23:59:59] *** BentMyWookie has joined #bittorrent





top