Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Networking IT

Ratio Vulnerability in BitTorrent Discovered 252

Posted by CmdrTaco from the well-thats-always-annoying dept.
An anonymous reader writes "The "vulnerability" has been tested on all the major torrent trackers that use the torrentbits source code. The idea is that you will sniff your torrent info using the HTTP Analyzer and with Firefox you will update your stats to the tracker being identified as a client."
This discussion has been archived. No new comments can be posted.

Ratio Vulnerability in BitTorrent Discovered More

Ratio Vulnerability in BitTorrent Discovered

Comments Filter:
  • Was it really a good thing to make this public?
    Won't this cause a new wave of leechers?
    A lot of trackers are built on torrentbits.

    • Re:Was it good to publicise this? (Score:5, Insightful)

      by zegebbers ( 751020 ) on Sunday September 18, 2005 @09:09AM (#13589310) Homepage
      According to the IE7 thread, the only way to force fixes is by disclosing vulnerabilities. Goose, gander etc I suppose
      • Yes, it's amazing how opinions on that sort of thing changes for so many people when the product in question isn't "their's" but "ours".

        I would say that it's hypocritical but... ..I caa't think of a but. It's just hypocritical.
        • Yes, it's amazing how opinions on that sort of thing changes for so many people when the product in question isn't "their's" but "ours".
          I would say that it's hypocritical but... ..I caa't think of a but. It's just hypocritical.

          False. It is only hypocritical if you can dig up a post where the SAME PERSON was saying that things like IE vulnerabilities should be published.

          -
      • This isn't a vulnerability; it's simply the way the protocol works. It doesn't take a client to act like one and send syntacically correct requests to a tracker. (In fact, that's how I test tracker code... with telnet and/or nc)

        I will warning those wanting to "cheat" using this method... if you follow his instructions to the letter, you will be detectable like a road flare in a movie theater. (if anyone is actually looking.)

    • Re:Was it good to publicise this? (Score:5, Insightful)

      by Anonymous Coward on Sunday September 18, 2005 @10:58AM (#13589752)
      I'm going to be a bit vitriolic, but you deseve it.

      Was it really a good thing to make this public?

      Yes, it was. This way, all people will know about the vulnerability, and we can get around to design something better - instead of it spreading among leachers and not to the general population.

      Won't this cause a new wave of leechers?

      That's part of the idea. Bittorrent is an open protocol, and when everyone knows about the vulnerability - it's a tad more pressure on various developers to remove the design flaws.

      A lot of trackers are built on torrentbits.

      So fucking what? Do you want to tell mother nature not to send a hurricane against New Orleans, because it will be a disaster? No, you won't.

      What you will do, on the other hand, is try to design something that works. If it doesn't work, it's back to the drawing board. Keeping silent is what companies such as microsoft think is a good idea. It is not. It's a hellish bad idea. You'll have various scum abusing the vulnerability without everyone knowing about it. You'll have admins having these kind of thing biting them in the ass without being prepared for it.

      Publishing this kind of information, even though when it's a deep design flaw in the trackers such as this, makes it easier to cooperate and eliminate the fuckups. Keeping silent about it doesn't do any good at all.

      Did you know that various worms abused sendmails "debug" command in eariler years? And that it gave you a root-shell on the mailserver? No? Well, it wasn't very smart - and a lot of people knew about it, without giving it much publicity. It was way larger than this idiotic flaw, but it was your idiotic idea about 'shutting up about it' that caused the havoc.

      One should always disclose security flaws. No exception. Even though if hundreds of millions will be caught in the middle. It's the only way to ensure that it'll be fixed, and that everyone will know about it - at least everyone that cares enough to follow the news.

      Now onto an idea on how to fix this garbage. It's not a bug in the bittorrent protocol, as it won't affect how much various people send to eachother. It'll mainly affect statistics on various sites, and whether you will be banned or not. Personally I think the solution is for every client to upload how much their peers have sent them - and for the peers to check that amount. Think of it as 'trusted third party'. If any of the peers disagree too much about the amount over time, they discontinue talking to each other - and the client that disagrees logs an 'objection' with the torrent-server. If we're talking several gigabytes of data, it should be very easy to spot by the administrators. Especially if it's the same peer that gets flak all the time.

      Of course, this will be problematic when you think about NAT's, as various computers behind NAT-devices will check their internal IP, and not the external one. That, however, is not the responsibility of the trusted third party, but the responsibility of the peer. Unfortunately this will make things more difficult, but hell, it's a tradeoff in any case. This might be solved through in-band communication with peers telling each other who they think the other party is.

      Ahwell. Enough ranting.
    • I thought EVERYONE IN THE WORLD new about this? People have been doing this since Brahm first released Bittorrent, hacking the Python source code to increase their rate of upload and total upload. It's litterally a * 2 stuck in the correct place.

      A few of the good trackers are aware of this and if their are large anomolies with a specific torrent (ideally the up/down ratio for each torrent should be around 1) it gets flagged for the admin to look out.
    • Closed trackers are freakin' annoying anyway. I get almost all my stuff from open trackers and get decent download speeds all the time.

      If people really are doing nothing but leech, they aren't causing much harm. Besides, the way BitTorrent works, you don't receive much data if you don't contribute, so it's hard to simply "leech" in the first place.

      -Z

  • First IE (Score:5, Funny)

    by zegebbers ( 751020 ) on Sunday September 18, 2005 @09:03AM (#13589288) Homepage
    now this. I can't believe it, my world is falling apart!

  • This is really gonna help (Score:5, Funny)

    by knightrdr ( 685033 ) on Sunday September 18, 2005 @09:03AM (#13589290) Homepage
    I can't wait to see my pornbits ratios go through the roof! j/k

  • Mirror (Score:3, Informative)

    by Anonymous Coward on Sunday September 18, 2005 @09:04AM (#13589294)
    http://xyflar.blogspot.com.nyud.net:8090/ [nyud.net]

  • damnit.... (Score:5, Funny)

    by El_Muerte_TDS ( 592157 ) on Sunday September 18, 2005 @09:05AM (#13589295) Homepage
    Guess now I really have to start seeding files. Thank you for spoiling it for me.

  • I can see the headlines now (Score:5, Insightful)

    by overshoot ( 39700 ) on Sunday September 18, 2005 @09:05AM (#13589297)
    There are any number of parties who will headline "Vulnerability in BitTorrent!" and cound on most readers never bothering to get the facts.

  • Neccessary Exposure (Score:5, Insightful)

    by Sv-Manowar ( 772313 ) on Sunday September 18, 2005 @09:06AM (#13589299) Homepage Journal
    As much as many people will ask if disclosure was a good idea in this case, it's important to remember that if one person can find this vulnerability and make it public, an unknown number of people could have found it and be making use of it in the background. The functionality of BitTorrent depends on clients seeding copies of the file back into the network after having downloaded, and a vulnerability like this in a significant amount of trackers could easily cause serious damage to the operation of many torrents.

    • Re:Neccessary Exposure (Score:3, Informative)

      by fabs64 ( 657132 )
      indeed, and in fact this "vulnerability" was always a well known flaw in any of the groups that run trackers i've been involved with. Saw someone exploiting it a good 8-9 months ago.
    • BitTorrent also relies on numbers. One or two leechers isn't going to break the system; 70% of clients being leechers is.

    • obviousness, and where the vulnerability really is (Score:5, Informative)

      by SuperBanana ( 662181 ) on Sunday September 18, 2005 @09:46AM (#13589433)
      As much as many people will ask if disclosure was a good idea in this case, it's important to remember that if one person can find this vulnerability and make it public, an unknown number of people could have found it and be making use of it in the background.

      Anyone who has even so much as glanced at the protocol specification can see that the client is trusted to return an accurate count for how much it has uploaded. This wasn't a "disclosure" or a "vulnerability announcement"- it was a statement of the patently obvious.

      The problem is not with BitTorrent. The problem is with BitTorrent trackers and sites which trust that value returned by the client. There are dozens of open-source clients, including the original- and all it takes is adding one operation that multiplies the real upload by whatever number you desire.

      The functionality of BitTorrent depends on clients seeding copies of the file back into the network after having downloaded, and a vulnerability like this in a significant amount of trackers could easily cause serious damage to the operation of many torrents.

      How did this pseudo-intellectual first-post get modded insightful? You clearly don't understand how the BitTorrent network is designed. Clients evaluate only how much data they receive directly from another client, and how fast. Nothing else factors into their decisions of who to upload. There is absolutely NO mechanism for the client to query the server to see how much you've uploaded, nor is there even a way to ask other clients. Why? Because both sources would be unreliable. Each client CAN only rely on direct "experience", unless they're engaging in a reputation system of their own hacking- if they are, best of luck to them, Bram wasn't an idiot for not trying that.

      The "vulnerability" only affects trackers which "enforce" an upload ratio, and only to the extent of letting people bypass that ratio. Ratios is a concept that is pretty stupid with BitTorrent. The more you push back, the more you get, unless there is plenty of bandwidth. About the only "benefit" I see to ratios is that it might keep files available with seeds longer.

      I hear a lot of crying about leechers on BitTorrent, but the network is self-regulating. Don't upload? You won't get much back. I think the perceived problem is also because reporting of the stats is unreliable- in the case of Azureus, for example, I can download a big file, upload 3x as much, and then if I get a connection error when my client stops, I "loose" all that uploading. I then look like a leecher, when it is exactly the opposite.

      • Ratios is a concept that is pretty stupid with BitTorrent.

        Right, stupid as in "people routinely saturate their downstream when ratio is enforced because everyone keeps seeding after having downloaded" and as opposed to smart, non-ratio trackers as in "people often get crappy speeds especially when they're on asymmetric connections because everyone kills the client after having downloaded the file".

        BT is kind of self-regulating, upload more and you download more. But the self-regulation only goes so far and offers no incentive whatsoever to actually seeding files. Since a vast majority of the peers are on asymmetric links (e.g. ADSL), there obviously is a need for pure seeds to keep network speed at a high level, because otherwise the maximum network speed would be limited by the total upload speed of the asymmetric links.
        • The problem with the 'you share with me and I'll share with you' concept that bittorrent is based on is that it doesn't fit well with the commercial reality of ISP plans these days.

          For example, here in New Zealand, the fastest speed you can get is 2mbps ADSL, and depending on the plan you choose, when you hit 10GB of traffic (that's traffic in both directions added together), you either start paying excessive data charges designed to be so high as to force you to stop, or your bandwidth is reduced to 64kb

    • Re:Neccessary Exposure (Score:5, Informative)

      by OverlordQ ( 264228 ) on Sunday September 18, 2005 @09:49AM (#13589442) Journal
      This only effects sites that use ratios for things like "VIP Status" or Auto-Bans, without hacking the client as well you wont be able to fool the other clients to send you data if you dont send them data.
    • I don't think it would affect the actual operation of the torrents at all. If I understand this correctly, it would only screw with sites that keep track of ratios, and then it would only affect the reported upload/download info. This doesn't cause clients to try to get data/chunks from you that you don't have.

  • Not such a big deal? (Score:5, Interesting)

    by AC-x ( 735297 ) on Sunday September 18, 2005 @09:07AM (#13589302)
    The way I look at it is this:

    Step 1. Load site logs
    Step 2. Do a search for these entries
    Step 3. Ban any cheaters

    I'm sure this it should be pretty easy to tell fake entries from real ones as I'm guessing that the tracker software, with a known IP address, is the only thing that should be accessing that url.

    • Re:Not such a big deal? (Score:4, Interesting)

      by KPU ( 118762 ) on Sunday September 18, 2005 @10:01AM (#13589493) Homepage
      RTFA. They copy what the bittorrent client (running on their computer from their IP address) reports to the tracker. Then all they do is send a falsified version. The logs would show both spoofing and legitimate clients accessing the same url.

      What one could do is search the logs for jumps in upload rate. For example, a user might be going 10 kb/s upload for a long time (while getting the file). Then all of a sudden it went to 10 Gb/s and nobody joined the torrent. Further if the sum of all downloads during that period is less than the sum of all uploads then somebody is probably cheating.

      • Re:Not such a big deal? (Score:3, Informative)

        by Qzukk ( 229616 )
        This kind of thing has been known for a long, long time now, though usually it's modified clients that simply lie about their stats, rather than some convoluted protocol sniffing thing. Many torrent sites that care about their ratios already check for obviously spoofed values.

  • BT protocol flaw? (Score:3, Interesting)

    by dancallaghan ( 890674 ) <djc@djc.id.au> on Sunday September 18, 2005 @09:07AM (#13589304) Homepage

    Seems kinda dumb that BT trackers rely on the clients to honestly report their ratios/upload amounts. Is it just this tracker implementation, or does the BT protocol work that way?

    IIRC the ed2k network had a similar issue in its infancy, nowadays (with eMule anyway) "upload credit" is maintained as a relationship between each client (i.e. I know how much a person has sent to me, so I know how much I should reward them in my upload queue) -- no potential for abuse that way.

    • The article doesn't go into much detail, but I believe the vunerability is caused by how trackers report back to the website's database, which manages all the ratio recording.

      The tracker itsself is self contained and keeps track of the ratios internally, but the website's gonna be running on a proper webserver and to keep a list of all the users and their ratio the 2 need to talk to each other, I guess they chose REST to do it.

      I'm pretty sure this isn't a big deal as it should be simple to find fake entries

      • Re:BT protocol flaw? (Score:5, Insightful)

        by justforaday ( 560408 ) on Sunday September 18, 2005 @09:19AM (#13589342)
        I would imagine that setting up a small script that bumps up your uploaded amount by a few hundred MB every now and then would be very hard to detect. Certainly more difficult than spotting someone who just uploaded 10GB out of nowhere (as in the example).
        • Or you just do the smart thing and mod your client so that Announces(what ratio sites use to track up/down) always return
          (down*(desired ratio)+random number)/down

          Then there aren't any "massive jumps" and there isn't a blatently obvious set ratio.

          I'd be suprised if anyone with even the smallest bit of curiosity didn't go looking through the code the first time they hit a ratio site that had a "users with less than X ratio and Y gigs uploaded have to wait 48 hours to join the swarm".

  • A devious plan! (Score:5, Funny)

    by roman_mir ( 125474 ) on Sunday September 18, 2005 @09:09AM (#13589311) Homepage Journal
    for promoting FF, but one of the steps in that list should be: set FF as the default browser ;)

  • Nothing new (Score:5, Informative)

    by gagge ( 808932 ) on Sunday September 18, 2005 @09:12AM (#13589323)
    Seriously, I thought this was already widely known. All info from the client to the tracker is sent with basic HTTP GET requests. You could fake your ratio with a simple php script. Well, maybe even by just typing the info in your web browser, however I think the urlencoding would be a problem.

    • If it's just a GET request, users wouldn't need to go so far, they'd just need to type something into their web browser title bar, or make a bookmarklet with a proper javascript snippet.

      I.E. Try typing

      javascript:document.location=
      "http://www.google. com/search?q="+escape(prompt("Text:"))+"&btnG=1"

      Into your URL bar, all on one line.

      Note, that in IE and Firefox, this would open a dialog box and fetch search results. URL escaping is already a possibility built into the browser side scripting langua

      • Correct me if i'm wrong, but cant you also do simple GET requests using telnet? I used to have a simple script for surfing websites using telnet. pretty wierd, but worked. It would be very easy to make a telnet script in windows with cygwin or even perl installed. Obviously super easy with Linux.

  • This is not a vulnerability.. (Score:5, Informative)

    by kryptkpr ( 180196 ) on Sunday September 18, 2005 @09:19AM (#13589344) Homepage
    This is not a vulnerability .. it's by design.

    The statistics reported to the tracker by the client were never meant to be used for things like enforcing ratios because they TRUST THE CLIENT. But there's simply no other way to collect statistics such as amount uploaded.. if the client lies to you (which is what this "vulerability" is exposing), there is little you can do to protect yourself.

    It's TRIVIAL (a 1 line change, or if you want to make it a parameter, a 4 line change) to modify any python open source client such that it 'amplifies' the ammount you upload by 10x or 100x. Then you don't need to do any HTTP sniffing, your client can just lie for you.

    Now, there is a way to block this author's method because he doesn't amplify the upload, he creates a step-change in the upload ammount (which can be caught on the server side.. if it's been the same ammount of time since the last check-in, but suddenly his cumulative upload ammounts tripled, you're likely being abused). However, using my 'amplifying' trick from above, this is much trickier to detect. Perhaps you measure the client's upload speed on the website and record it to the database, maybe even double it just to be safe.. so you KNOW this client can only do 60 k/sec or whatever. Then when the client reports in stats, you take the time since the last check-in and you calculate his approxomate 'instantenous' rate. If this rate is higher then the upload rate you previously decided was this client's ceiling, then he's lying to you.

    The above method is not foolproof, but it would likely be better then the nothing we have now. It was really only a matter of time this surfaced.. and I'm amazed it took this long.

    --kRYPT
    (author of burst! and MakeTorrent)

    • Re:This is not a vulnerability.. (Score:2, Interesting)

      by Anonymous Coward
      But there's simply no other way to collect statistics such as amount uploaded.

      Why not ask the other peers?

      Instead of having every client tell the tracker how much it's uploaded, have each client tell the tracker how much it's downloaded from each of it's peers and extract the other peers upload rates from that data.

      At least that way you need a conspiracy of multiple clients to fake a high upload rate. Combined with only allowing one client per torrent per IP, this could prevent a single machine from provid
      • Combined with only allowing one client per torrent per IP, this could prevent a single machine from providing false upload data.

        I see 3 problems with your proposal:

        1) I'm not sure if it's fair to impose a one client per torrent per IP rule.. sometimes NATs (I'm thinking unviersities here) can be pretty big, encompassing thousands of machines.

        2) The original problem (trusting the client) has not been solved. Instead of trusting the client to report it's own statistics, you now trust it to report someone els
        • Bittorrent doesn`t work very well with nat..
          Also, if multiple machines are behind the same nat and downloading the same file then bittorrent should be smart enough to only bring 1 copy of the file down through the natbox and distribute it throughout the local peers..
          • Also, if multiple machines are behind the same nat and downloading the same file then bittorrent should be smart enough to only bring 1 copy of the file down through the natbox and distribute it throughout the local peers..

            The problem here is discovery. How do you make it 'smart enough' to recognize that multiple people behind your NAT are transferring this file, when you cannot (for practical reasons) connect to every peer on a torrent and you usually only get to see an external IP when you do.

            There was s

            • If two clients connect to the same tracker from behind a NAT, they will have the same external ip address -- when a bittorrent client sees a peer with the same ip address on the tracker, they should know they're both behind the same NAT: they could then attempt a broadcast on their local subnet to attempt to discover other bittorrent clients to possibly coordinate private a private transfer or paired transfer option (I.E. each client would have the option of sharing every file piece received with the oth

              • Why wait until you get a peer with you external IP? In a large swarm this may never happen. If you could do this, then just broadcast right away at start-up. It's a good idea, it's just not backwards compatible.

                To really be effective, this is something that should be built on top of the current peer-discovery system, not beside it.
          • Also, if multiple machines are behind the same nat and downloading the same file then bittorrent should be smart enough to only bring 1 copy of the file down through the natbox and distribute it throughout the local peers..

            If I am hearing you correctly, you are saying that if two people are behind a NAT firewall and downloading the same file, the NAT (or bittorrent) should only download it once and give it to both clients? I am pretty sure this is NOT a function of either the bittorrent protocol, or any NA
            • Bittorrent is fine with NAT for one, maybe two machines, but on large networks won't work because you'll *never* persuade IT to port forward a different port for every machine on the network...

              It would be nice if BT clients broadcast for other local clients & allowed them to connect directly.. that wouldn't need much of a change to the protocol (since BT is already p2p, except for the tracker) and would achieve the benefits the OP wanted.
              • It would be nice if BT clients broadcast for other local clients & allowed them to connect directly.... that wouldn't need much of a change to the protocol (since BT is already p2p, except for the tracker) and would achieve the benefits the OP wanted.

                The client can't "just broadcast" magically. Since that is the tracker's job, you would need to install your own local tracker server, edit the primary client's torrent file to show both trackers, and then edit the torrent for each other client to only show
        • Nothing stops several (2 or 3) clients from corroberating.

          I can use two clients to abuse upload ratios even without hacking the clients or the data they send. All I have to do is find a reasonably small torrent (15-20 or so clients max) where I have a good chance of one client being requested to send data to the other, and put them on the same Ethernet segment, the faster the better, and turn off any bandwidth limits. They don't even have to have the same real IP address (I get five addresses on my DSL,

          • The problem with your multi-client hack is that you'll be limited by the size of the file. Once both clients have that file, they won't be uploading to each other any more. With a large enough file, this could still boost your ratio--but you have to download the file in the first place.
            • Uhhhh... once both clients have the file, they don't need to upload to each other any more... because now you've got the file, which is the whole point of leeching! (I never said it was a workaround for ratio quotas, did I?)
          • but the second client's download (from the first client) would count against it's ratio! so if the file is 200mb, client1 gets to improve it's upload by 200mb, but client2 now has a 200mb bigger download.. resulting in a net increase to your ratio of.... 0? and that's assuming that client2 ONLY downloads off you. if client 2 downloads 100mb off you and 100mb off other seeds, then your ratio will be worse by 100mb (downloaded 200mb on client2, uploaded 100mb on client)
    • The real fix is to have the clients tell the server what data they sent by sending it a list of hashes from each block. This could be a very weak / short hash and still be effective in mitigating cheaters. It would also help identify clients (*IAA) trying to poison the torrent (they would have to report their stats or be isolated from the main part of the torrent).
      • Sending a hash to a tracker only proves that the peer is in possession of a block; it doesn't prove that the peer actually sent the block to any other peer. Then a hacked peer can just tell the tracker that it uploaded 10 copies of one block instead of 1.

  • This Is Nothing New (Score:3, Insightful)

    by Terran Zwart ( 900093 ) on Sunday September 18, 2005 @09:38AM (#13589401)
    I've been studying BT for over a year now, and this problem is very obvious and well-known. So, anyone who claims that they shouldn't have posted this because it's going to kill BT is wrong. They shouldn't have posted it because it's obvious to anyone who reads the BT protocol. You can just modify the source code and send a random real from zero to one, plus one, times however much you've downloaded and you've got a share ration between 1 and 2. Simple.

    The simplest and best solution to this problem is the one that idiots (especially BT client developers like Bram Cohen and the Azureus dev team) tend to dislike the most: instead of forcing people to be cooperative by enforcing seeding requirements either in the client or at the trackers, simply recognize that swarming creates an inherently competetive environment, as everyone is really only concerned about their download and SHOULD only be concerned about their download, and let people use the most unscrupulous tactics they can think of to game the system. The way it will play out is that people will end up with a share ratio close to 1. The swarms become like little free markets: if you have a valuable piece, you can agree to trade for a lot of data. If someone breaks their agreement, you ban their IP address for a while. If you're willing to upload twice as much as you request from others, EVERYONE will want to trade with you.

    If you do the math and economic analysis, everyone ends up trading on a 1 for 1 ratio, seeds only have to upload when there's very few peers (they simply require 2 bits from you for every bit they upload, that way people will only rely on seeds if they can't get a piece any other way, specifically, if the availability of the piece is zero), and no one other than the individual or group publishing the data needs to seed. BT was never meant (whether Bram Cohen realizes this or not) to shift the responsibility of serving from the publisher to the clients, it was meant to reduce the amount of bandwidth needed to publish data.

    The current system is like socialism. It needs to become more like capitalism, and I'm not even a laissez-faire capitalist! Why no one realizes this is beyond me.

    • Re:This Is Nothing New (Score:4, Insightful)

      by mickwd ( 196449 ) on Sunday September 18, 2005 @10:27AM (#13589606)
      "BT was never meant (whether Bram Cohen realizes this or not) to....."

      Surely the inventor of BT knows better than you when his invention was meant to achieve.

      Now how well it actually achieves it may be a differnt matter.
    • Socialism? Have you not read the paper (pdf) [bittorrent.com] (google HTML version) [66.102.7.104] on tit-for-tat that uses economic models from game theory as a basis for the bit torrent protocol? It's pretty capitalistic in my opinion.
    • What you describe is exactly how bittorrent currently works, so apparently that year of studying was pretty much wasted. If you knew anything about Bram, you'd know that game theory is one of his abiding interests. Try reading his blog [livejournal.com], it can be pretty interesting.

    • Re:This Is Nothing New (Score:5, Insightful)

      by Spy Hunter ( 317220 ) * on Sunday September 18, 2005 @02:41PM (#13590811) Journal
      The simplest and best solution to this problem is the one that idiots (especially BT client developers like Bram Cohen and the Azureus dev team) tend to dislike the most [...] The current system is like socialism. It needs to become more like capitalism [...] Why no one realizes this is beyond me.

      What a wanking piece of haughty, uninformed bullshit! How this got modded up to +4 is beyond me. Bram Cohen has realized this from the beginning, and all client authors understand it as well. The design of the BitTorrent protocol is and always has been grounded in the economic principles of the free market. Seeding requirements are *not* enforced in the official client or tracker. Clients only upload to people who upload to them, and if people break their agreements they *do* get banned.

      Your suggestion requiring uploads to seeds is stupid, because people would be even *less* likely to seed if it wasted their download bandwidth as well as their upload bandwidth (and twice as much of it too!). If you want to discourage downloads from seeds, simply make the seeds slow.

      The idea of assigning economic values to individual pieces is already in the protocol implicitly; the economic value of a piece is inversely proportional to the number of clients who have it. If you have a piece nobody else does, you can upload it to anyone and get a piece in return, therefore that piece has high value. If everybody else has the piece, nobody will accept it in a trade. Therefore it's already in a client's best interest to grab the most rare pieces; additional incentive for this is not necessary.

      If you have such awesome ideas about how to build a BitTorrent client that no one else does, then why don't you build one yourself and change the world? It's not that difficult; the protocol is simple by design. Otherwise, shut your trap about how stupid the people actually working on clients are.

      The people who are not acting like a free market here are the writers of the *trackers* which trust reported uploads by clients (clients never trust these numbers for anything useful). Your entire rant is misguided and off-base; it should be aimed at the writers and users of ratio trackers, not the clients.

  • This is old old old old old (Score:5, Informative)

    by OverlordQ ( 264228 ) on Sunday September 18, 2005 @09:43AM (#13589421) Journal
    This is nothing new, there's been client hacks for this for quite a while (http://www.00de.com/ [00de.com]), there's also been ratio faking programs out for quite a while as well. So I really dont see anything additional that this 'xyflar' guy has added besides posting what's been known to pretty much every torrent user as well as pretty much every torrent site that uses ratios.

  • Non-Ratio Site (Score:3, Interesting)

    by SumDog ( 466607 ) on Sunday September 18, 2005 @09:47AM (#13589438) Homepage Journal
    I tend to use public sites that don't keep track of ratios of individuals--honor system an all that--and I still always try to keep at least a 1.0 on all torrents, many of them usually end up at 2.0 ~ 3.0 just because ratios build up very quickly on popular torrens overnight on broadband connections.

    It seems like from the posts the BT community has known about this for a while and it really doesn't seem to matter too much. Most downloaders who have at least a basic understanding of how torrents work will keep those downloads going caust it's just a nice thing to do.
    • It seems like from the posts the BT community has known about this for a while and it really doesn't seem to matter too much. Most downloaders who have at least a basic understanding of how torrents work will keep those downloads going caust it's just a nice thing to do.

      I agree completely, I don't see what the fuss is. The good side-effect is that it's mostly private sites that will suffer from this, and torrent action will hopefully move into the public sites where nobody's counting.

      In the project we

  • Exploiting Ratios is easy (Score:4, Interesting)

    by AngryScot ( 795131 ) on Sunday September 18, 2005 @09:50AM (#13589451)
    Easy way to get your ratio up is to join a site that only allows you two slots on the tracker at first. Either download two small files and seed them or upload two of your own torrents and stay connected to the tracker so you are using your two tracker slots.

    Using azeurus (or any client which stores peer IP's) stop on of your seeding files and connect to a large file you want to download, let your client pick up some IP's or until you are getting the file at a decent speed.

    Now stop your download and begin seeding again, when you restart your download you will connect to the clients and your download will be resumed but the tracker will not be updated with the data you are download. AFAIK users who you are leeching off will still be given credit for all the data you upload.

    Worked on elite torrents and some of the sites I use now.

  • Why Firefox? (Score:2, Interesting)

    by porneL ( 674499 )
    Since when Firefox is more appropriate term for HTTP than HTTP?

  • This is new? (Score:3, Informative)

    by Elad Alon ( 835764 ) on Sunday September 18, 2005 @09:58AM (#13589479)
    I've been using Bittornado and Rufus for some time now, and with both, I get away with uploading at 3KBps and downloading as fast as I can manage. I have ADSL, so this means about 60KBps short of my 180KBps upper limit for downloading. But I've been known to download at 180KBps. (It's not that I'm a prick by nature, it's just that with my connection, I can only upload at around 12KBps, and the faster I upload, the slower I download.)

  • Meh.. (Score:4, Interesting)

    by EiZei ( 848645 ) on Sunday September 18, 2005 @09:58AM (#13589482)
    Being a formet BT tracker admin we knew of this well over a year ago.

    Just download the original client and change the source code if you want to automate the process.
  • I just knew the Bittorrent protocol would somehow trust the clients for keeping statistics on downloads and thus be vulnerable to spoofing. The problem is that it's fundamentally impossible to gather statistics about processes on other machines are doing in a reliable way.

    What's more interesting to me is how other services (ed2k?) do it, and if this makes them more/less/equally vulnerable.

    A scheme I've thought of is where you submit packet length and a checksum (calculated from the packet contents) to the t

  • Easy to detect cheaters (Score:5, Interesting)

    by Anonymous Coward on Sunday September 18, 2005 @10:16AM (#13589562)
    It is very, very, very easy to detect cheaters on private torrent sites -- which are the only sites where ratios really matter anyway.

    Globally, across an entire torrent, the amount of data uploaded can't be greater than the amount downloaded. Think about it for more than three seconds and its rather obvious. Every single client reports their usage to the tracker. Every byte you upload must have been downloaded by another client, who also reports their usage.

    And hash fails are counted as downloads by the client, so thats not a factor.

    If the torrent admin looks through a torrent and sees Joe Cheater claiming to have uploaded 3.6GB, and it just so happens that the amount uploaded is 3.6GB more than that downloaded...its not hard to work out who's spoofing their stats.

    Granted, the situation becomes worse when multiple people are cheating, but it's not too hard to track users who are on multiple torrents and pick out usernames who always appear to be on the torrents with the discrepancies.

    I've seen it happen on private sites before, and it will happen again.

    The short answer is -- you can fudge your stats all you want. But unless you can find a way to fudge someone elses stats to minus the discrepancy, you'll get caught. And rightly so.

  • Here is my little crappy tool (Score:3, Interesting)

    by arcanumas ( 646807 ) on Sunday September 18, 2005 @10:21AM (#13589578) Homepage
    I discovered this "vulnerability" myself a few months ago and wrote a crappy Python tool to cheat automatically.
    You just give it the torrent, how much to "upload" and how much to wait between start and stop updates.
    it's in SVN in my home PC so, it may not stay there for long if you abuse my DSL.

    Just go where you want to install it and type:
    svn co svn://arcanum.homelinux.org/cheatbt cheatbt

    ./chtk.py is a TK GUI (no file selector, too bored for that)
    ./cheatingBastard.py is a PyQT GUI (with fileselector but a Threading issue)
    ./cheatbt.py is the "command line" tool. use it as such:

    ./cheatbt.py mytorrent.torrent seconds_to_wait bytes_to_upload

    Please, no complaints about the code... i know :)

  • Discredits RIAA/MPAA evidence (Score:4, Interesting)

    by cpu_fusion ( 705735 ) on Sunday September 18, 2005 @10:39AM (#13589660)
    If anyone gets hauled to court over their use of BT and these "amount shared" statistics are used as evidence against them, having the data be easily forged should help the defendent.
  • BitTorrent was designed as a data DISTRIBUTION system, not a data SHARING system. In taking the place of a non-P2P upload (http or ftp), any amount of upload is better than none, and clients that upload zero don't get as good performance downloading as clients that contribute.

    Trackers were never meant to try and enforce upload ratios; it's too easy for clients to lie about how much they've shared, and too complicated and exploit-prone to work out a system where peers report on each other.

  • A way for MPAA/RIAA to kill Bitorrent (Score:4, Informative)

    by Danathar ( 267989 ) on Sunday September 18, 2005 @10:41AM (#13589670) Journal
    I've always thought that the best way for the MPAA/RIAA to kill bittorrent would be to break the protocol such that cheaters could leach without giving much back.

    If you look at other systems where the amount leechers far outstrip people giving back the system pretty much gets bogged down.

    Bram had always said his system works because every client is out for it's own interest. Researchers who have tried to "improve" BT usually have done something to break this model.

    If I were the RIAA/MPAA I'd hire a bunch of crack programmers to try and create a "cheat" and then release the source code to that people would get to download with little or no uploading. That would effetively KILL many bittorrent swarms
    • This exploit twiddles tracker statistics, but the "self-interest" part of BitTorrent is built into the P2P protocol. Peers upload more to other peers that upload more to them, and there's no way around it. Most BitTorrent trackers don't try to enforce ratios, and I personally think it's stupid to try.
  • So what if you don't use trackers but connect exclusively via trackerless torrents?

    It would seem to me that the "vulnerability" only exists if you are sending data to a tracker.

  • Pretty simple cheat... (Score:3, Informative)

    by guardianfox ( 853748 ) * on Sunday September 18, 2005 @10:58AM (#13589751)
    This cheat DOES work... but it's rather suspicious to the admins when you do it. Like a thirty-second leap from a terrible download-upload ratio to a godlike ratio won't go unnoticed... That said, I had no problem TESTING it, but I contacted the admins of my favorite tracker and told them what I did, why, and got them to reverse it. They'll be watching for it now and banning anyone who tries it.

  • allready know about it. (Score:3, Informative)

    by indy_Muad'Dib ( 869913 ) on Sunday September 18, 2005 @11:04AM (#13589773) Homepage
    use it on boxtorrents and we will ban your entire ISP for a month. we know about it, we know how to monitor for it.

  • upload = download (nearly) (Score:2, Informative)

    by Anonymous Coward
    It's very easy to detect cheating in a swarm. If a client reports that it's uploaded ten megabytes, but the remainder of the swarm has only downloaded one megabyte, there's obviously something askew. Of course, not everybody will get their stats counted accurately, due to disconnection and tracker outages, but things should average out reasonably (*). If these community-based ratio-monitoring sites simply count the number of times a given member is part of a swarm with a mismatched overall upload:download
  • A fix that several of the larger trackers I've used have put in place is to track both upload and download stats for everyone on the torrent. It quickly becomes obvious that someone is cheating if the total amount of uploaded data is greater than the total amount of downloaded data. This makes it rather trivial for admins to track down and ban people who cheat in this manner.

    This system could certainly be broken by having clients intentionally amplify reporting of the amounts they upload, but there's no inc
    • It quickly becomes obvious that someone is cheating if the total amount of uploaded data is greater than the total amount of downloaded data. This makes it rather trivial for admins to track down and ban people who cheat in this manner.
      Um, it's called "seeding" after you finish downloading. Usually, that's considered a _good_ thing, because if nobody uploaded more than they download, the files couldn't be distributed.

  • The lazy way is the best way (Score:3, Insightful)

    by horza ( 87255 ) on Sunday September 18, 2005 @02:00PM (#13590525) Homepage
    You could try the exploits, which only damages the system and will get you eventually banned from your favourite torrent sites, or you could just get half a dozen downloading and go to bed.

    Phillip.
  • I don't see how this is a vulnerability. The bitTorrent protocol, as I understand, is based on a tit-for-tat principle which is worked out on a per-node basis (ie. if you upload to me, I'll be more willing to give you what you want).

    I don't see how global ratios play into this in the least.. (each of the other nodes would say something like yeah, you've uploaded 10GB. Good for you. But what have you done for me?
    • Some sites try to prevent users from taking advantage of excess bandwidth by enforcing a ratio across torrents or provide a better experience for people with high ratios by refusing to add low ratio users to the tracker until 48 hours after the start of the torrent.

      This isn't a vulnerabilty of the protocol, because the network will respond as it always has: people who upload get better speeds than leechers when download capacity is higher than upload capacity.

      It is a vulnerability of the tracker, but only i

Slashdot Top Deals

Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman

Close