Is there a way to stop the slot stealing exploit?
Moderator: Moderators
Is there a way to stop the slot stealing exploit?
There seems to be some kind of exploit where people can get a slot when your slots are full without you granting them one. Someone told me that it had something or other to do with getting your file list or a small file so that it sort of doesn't count it as a slot at first and then they can somehow get a large file right after. I'm hoping that if I ask here someone who is familiar with how this exploit is done could have ideas or at least details that could spark ideas. I did have one of my own though I'm not really sure how good it is. It seems to me that if your number of free slots goes negative (like it did last time someone somehow used this exploit on me) then the client could automatically close the upload in the upload list that was started at the latest time. The client could just store the ticks variable or something like that of when the upload was started and compare when it goes negative if the file is larger than, say 1MB or so.
Oh yeah, another idea just occured to me that might help. The client could automatically close each connection after a file is completed including the list. If the exploit does indeed rely on that connection still being open or something like that, then it will become impossible. Also, someone before mentioned that there was a problem with people who slot hog and download practically every file (if not every file) in a person's list and end up taking a long time. If the connection is closed after each file, it would give someone else half a chance to get in.
Oops... Uhm, does the open a slot automatically if speed goes below a certain amount option make the number of available slots go negative? If so, then I'm sorry. I had heard there was an exploit that would let people do that, and when I looked at my client the speed was well above that setting, but people were getting worse speeds since there was another person getting from me and I have a pretty limited upload. Leechers aren't known for thinking ahead anyway (as in the type of leecher who WOULD cheat, not just any leecher.) Anyway, I'll just disable that all the same since it doesn't seem to work the intended way in the long run.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Unfortunately, it turns out that there is. I disabled that option to open a new slot, and someone still managed to do it. I was talking and glanced at it one moment, then, next thing I know, there's four uploads running and it said slots -1/3. Unfortunately, I don't pay attention enough to know which one cheated. Since I'm just sick of the whole mess, I just had to close all four and let people get back in the proper way, watching for a while to see if the cheater pulled it again. Which they haven't while I've been watching so far at least. Probably not many people actually pull this exploit as it doesn't seem like it's terribly easy and if they had just a little common sense they'd realize they are just going to give themselves (and everyone else downloading from me) worse speeds that way.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Well, I think the burden of proof to show that there is an exploit is on you.Nazo wrote:Unfortunately, it turns out that there is.
I too thought that there was a bug in DC++, but I've yet to find an unexplained extra upload. This topic is relatively high visibility, if someone can step in with methods to reproduce it (or smarter yet, PM me or one of the other mods ), then I'll be happy to admit I'm wrong.
I was rather hoping to find someone who knew about it or at least knew enough of how DC++ works to figure out how they did it. Still, I'll try my best to keep a lookout to see if I can figure out exactly what it is that they do. So far all I have is the part that someone mentioned to me a long time ago where it had something or other to do with getting the small file first.
Ok, just asked around. So far I haven't found someone who actually knows how it's done, though I did see one other who said they'd seen it happen to them, but someone did have an idea. When they get the filelist, it opens the connection, but if you tell it to download, the client disconnects and waits for a bit before trying to get whatever you told it to download. Maybe, though, there are some modified clients that don't disconnect after getting the list and don't wait the 30 seconds or whatever it is dc++ waits before trying to get the next file.
Anyway, I'll keep looking. Someday I'll probably catch them in the act I hope and see what they did.
Ok, just asked around. So far I haven't found someone who actually knows how it's done, though I did see one other who said they'd seen it happen to them, but someone did have an idea. When they get the filelist, it opens the connection, but if you tell it to download, the client disconnects and waits for a bit before trying to get whatever you told it to download. Maybe, though, there are some modified clients that don't disconnect after getting the list and don't wait the 30 seconds or whatever it is dc++ waits before trying to get the next file.
Anyway, I'll keep looking. Someday I'll probably catch them in the act I hope and see what they did.
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
You did. If there's a REAL exploit GargoyleMT knows enought o find and help stomp it out. But, as he said, you'll have to provide some real evidence that an exploit exists.Nazo wrote:I was rather hoping to find someone who knew about it or at least knew enough of how DC++ works to figure out how they did it.
What you've suggested about small files first, won't do it. I have had extra slots opened too, but it always because someone re-connected within the 5-10 minutes after they got disconnected...
HaArD
-
- Posts: 202
- Joined: 2003-01-06 06:22
- Location: Salford, England.
- Contact:
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
correct me if i am wrong guys,
i have been using DC++ for quite some time and
the slots discreprency (-1/4), means that you have
4 ppl connected to you so all you slots are taken up
then at some time ago, you granted somebody a slot
so they come into the hub and a slot is automatically handed
to them, maybe someone you dont remember.
if this is the case i would say its correct,
the only complaint is that
DC++ has a grant a slot but not a ungrant a slot.
i have been using DC++ for quite some time and
the slots discreprency (-1/4), means that you have
4 ppl connected to you so all you slots are taken up
then at some time ago, you granted somebody a slot
so they come into the hub and a slot is automatically handed
to them, maybe someone you dont remember.
if this is the case i would say its correct,
the only complaint is that
DC++ has a grant a slot but not a ungrant a slot.
-
- Posts: 202
- Joined: 2003-01-06 06:22
- Location: Salford, England.
- Contact:
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
That's because DC++ gave that ability to Father Time. He automatically revokes granted slots after 10 minutes, or after the person conects and successfully gets a slot. This is only true for DC++, modifications (such as BCDC) can and have changed that.XmothX wrote:the only complaint is that DC++ has a grant a slot but not a ungrant a slot.
Am I wrong?
I've always thought it is because I use the function
"Automaticly disconnect users who leave the HUB."
If you check the Readme/Newbie help in the program, it says:
"* if a user leaves the hub DC++ will close his slots, if the user is back within 10 minutes DC++ will grant him a slot.
THIS CAN CAUSE YOUR UPLOAD GOING OVER MAXIMUM SET IN SETTINGS"
I've interpeted it like this.
If you got that automaticly disconnect thingy on, it will disconnect people leaving the HUB, but if they get back within 10 minutes, they get the slot back, even if all your slots are full. In case they were disconnected by ISP or some technical problem.
Am I totally wrong on this
"Automaticly disconnect users who leave the HUB."
If you check the Readme/Newbie help in the program, it says:
"* if a user leaves the hub DC++ will close his slots, if the user is back within 10 minutes DC++ will grant him a slot.
THIS CAN CAUSE YOUR UPLOAD GOING OVER MAXIMUM SET IN SETTINGS"
I've interpeted it like this.
If you got that automaticly disconnect thingy on, it will disconnect people leaving the HUB, but if they get back within 10 minutes, they get the slot back, even if all your slots are full. In case they were disconnected by ISP or some technical problem.
Am I totally wrong on this
You may be correct in this. It may explain how rare it is that this occurs since people have to get back on fast enough. I sure hope you are because if there is some little trick to steal slots, thogh it may not be well known and/or it may be complicated and hard to do, people will learn of it and gladly abuse it. And with slow connections like mine, one person abusing can hurt everyone.
-
- Posts: 202
- Joined: 2003-01-06 06:22
- Location: Salford, England.
- Contact:
"* if a user leaves the hub DC++ will close his slots, if the user is back within 10 minutes DC++ will grant him a slot.
THIS CAN CAUSE YOUR UPLOAD GOING OVER MAXIMUM SET IN SETTINGS"
He's right, you know... i seem to have over looked this. However it's not big deal.
...and how did you figure that this is abuseable?? Who, in the right mind, is going to disconnect from the hub, lose their slot, reconnect, only to get their slot back again, except at a slower speed. Only a fool would think like that!
THIS CAN CAUSE YOUR UPLOAD GOING OVER MAXIMUM SET IN SETTINGS"
He's right, you know... i seem to have over looked this. However it's not big deal.
...and how did you figure that this is abuseable?? Who, in the right mind, is going to disconnect from the hub, lose their slot, reconnect, only to get their slot back again, except at a slower speed. Only a fool would think like that!
I didn't say THAT was abusable. I said that if there was a way of abuse of slots, it would need to be found out because eventually a lot of people would figure out how to do it and use it. I don't consider this to be something that that user is going to do unless they purposefully want to decrease your bandwidth for everyone including themselves, which doesn't make sense unless they want to hurt someone else getting from you, which is still pretty silly.
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
hmm... you just made me think of a possibility....OLDoMiNiON wrote:"* if a user leaves the hub DC++ will close his slots, if the user is back within 10 minutes DC++ will grant him a slot.
THIS CAN CAUSE YOUR UPLOAD GOING OVER MAXIMUM SET IN SETTINGS"
He's right, you know... i seem to have over looked this. However it's not big deal.
...and how did you figure that this is abuseable?? Who, in the right mind, is going to disconnect from the hub, lose their slot, reconnect, only to get their slot back again, except at a slower speed. Only a fool would think like that!
I get a no slots available message
I go into the users filelist and find a nice small file, like 15k
While that's d/l I disconnect
Then I re-connect
Do I get my slot back?
Can I now use that slot for file > 16k?
HaArD
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Check the changelog again. I thought of this when I first thought there was a problem in DC++ handing out download slots.HaArD wrote:hmm... you just made me think of a possibility....
I get a no slots available message
I go into the users filelist and find a nice small file, like 15k
While that's d/l I disconnect
Then I re-connect
Like I originally said, "Auto-Open new slot if speed is under ..." and "Disconnect users who leave the hub" are responsible for 99% of the "too many uploads" problems that people think they have. (The remaining 1% is from manually granted slots.)Changelog for 0.231 wrote: -- 0.231 2003-02-04 --
* Fixed so that a user won't be granted a slot when using a "free" slot if disconnected because of the
autodisconnect feature (thanks Todd Pederzani)
It's all documented, perhaps it should be done better so people understand the consequences of their choices.
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Well, we can use all the ivul thinkers we can. That was just my contribution.HaArD wrote:OK I'll stick with my original position, which is the same as yours, what exploit? Please provide some evidence...
This "exploit" could be reduced a lot if the function of the Disconnect Offline Users was changed. I was thinking perhaps that the user could get a grace period (120 seconds?) after disconnecting to come back online. If they don't, they get nixed, with no granted slot.
Perhaps it needs to be more like 210 seconds, anything above the default time for DC++ to retry connecting to a disconnected hub (3 minutes?).
Show Me The Money
Why would this work better than the current 10 minute timeout? Just set temp ban to 11 minutes and it works great . There is no exploit here, if anyone is afraid of getting more uploaders than they have slots, just don't activate that option!?
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Your post seems to have the assumption that all of the extra downloaders people are seeing come from them getting kicked by the OPs. This might be true in .se for .se users, but on the hubs I'm on, people's internet connections (or routes to the hub) do drop out occasionally, causing them to lose connection with the hub. This will, of course, trigger a disconnection in those people who have the "Disconnect users who leave the hub" option on. There's no rule that says that reconnecting will take 10 minutes.cyberal wrote:Why would this work better than the current 10 minute timeout? Just set temp ban to 11 minutes and it works great . There is no exploit here, if anyone is afraid of getting more uploaders than they have slots, just don't activate that option!?
I hope my suggestion makes more sense to you now, cyberal.
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
How about changing the disconnect to happen 10 minutes AFTER they disconnect instead of giving them 10 free minutes to re-connect and regain the slot.
Problem solved....????
HaArD
P.S. This actually might work better at discouraging "pop in and leech" activity because after 10 minutes of downloading they will probably forget where they popped in......
Problem solved....????
HaArD
P.S. This actually might work better at discouraging "pop in and leech" activity because after 10 minutes of downloading they will probably forget where they popped in......