|
aaaaaaaaaarggggguu i got drop hacked 6 times today
|
I'm legit so confused how blizzard is letting this happen so much @_@
|
We must band together to castrate these bastards!
But in all seriousness, blizz needs to act immediately.
|
If there's a way to cheat someone will use it. Pretty sad but that's how it is.
|
Some guy scouted cross-map directly into my main, lost his whole mineral line to banes, and drop hacked me when he had nothing left but 4 lings.
|
T.O.P.
Hong Kong4685 Posts
On July 04 2011 05:40 novabossa wrote:Show nested quote +On July 04 2011 05:13 Musketeer wrote:On July 04 2011 04:22 Furlqt wrote:
Made an account to try and clarify some thing about what exactly the Lag/Drop Hack is and how it works.
Essentially, the Battle.Net protocol is based around players sending events to the server and the server sending those events back to all the players in a match. These events all have unique IDs, and the codes for these events are relatively sparse (that is to say, if you pick a random number between 1 and 24 million, chances are it's not a valid event). However, the server does no filtering as to whether an event is valid--it sends the event down the pipe regardless of validity.
So, the drop hack works, essentially, by abusing this system to DoS your client. It spams the B.Net server with gibberish event IDs as fast as the Drop-Hacker's network can handle, and the B.Net server sends this back to your client, where your client is left confused trying to figure out why the server sent it a gibberish event. It looks up the event in all the game files and goes through all the rhetoric--but, these gibberish events are coming down the pipe so fast that the client locks itself up through this.
I think, also, but I'm not sure, that when a client encounters a gibberish event it tries to ask the server to resend the event, meaning one gibberish event might strike a chain of events that can't stop itself.
Now, this is also why when you're looking at a replay of these hackers that it slows down your client, since the replay is just a copy of the events that your client received during the match. A small test in a custom game showed that about 5 seconds of using one of these Drop-hacks on myself, through my very low bandwidth connection, produced a replay with an events file that was 917KB long (this gets compressed substantially, since the gibberish is produced in a very simple manner), compared to a normal replay which would be about 100KB of events uncompressed over 30 minutes.
All that would be required for Blizzard to fix this is to do a very simple filtering on events. I highly doubt this would slow down their server very much at all, if properly implemented, and it would take a 3-year-old about 2 minutes to implement. Why they have yet to patch their server, I have no idea.
[edit/addendum] The only limiting factor for the drop hacker is his upload bandwidth. The limiting factors for the person being drop hacked are his download bandwidth and his CPU speed. If the drop hacker has your average American cable connection, his upload bandwidth is maybe 384kBps. The person being drophacked would need something like a 1MBps download and something like an i7 to properly fend against it. Running SC2 from a SSD (hard drive) probably doesn't hurt, either. I couldn't defend it with a Phenom X6 and 8 MB down. Then the person drop-hacking you probably had a comparable or better upload/CPU....the point is that you need to have a far better CPU / download bandwidth to negate the hack.
I have Sandy Bridge quad core + 100Mbps download and I still can't defend it.
|
On July 04 2011 04:22 Furlqt wrote:
Made an account to try and clarify some thing about what exactly the Lag/Drop Hack is and how it works.
Essentially, the Battle.Net protocol is based around players sending events to the server and the server sending those events back to all the players in a match. These events all have unique IDs, and the codes for these events are relatively sparse (that is to say, if you pick a random number between 1 and 24 million, chances are it's not a valid event). However, the server does no filtering as to whether an event is valid--it sends the event down the pipe regardless of validity.
So, the drop hack works, essentially, by abusing this system to DoS your client. It spams the B.Net server with gibberish event IDs as fast as the Drop-Hacker's network can handle, and the B.Net server sends this back to your client, where your client is left confused trying to figure out why the server sent it a gibberish event. It looks up the event in all the game files and goes through all the rhetoric--but, these gibberish events are coming down the pipe so fast that the client locks itself up through this.
I think, also, but I'm not sure, that when a client encounters a gibberish event it tries to ask the server to resend the event, meaning one gibberish event might strike a chain of events that can't stop itself.
Now, this is also why when you're looking at a replay of these hackers that it slows down your client, since the replay is just a copy of the events that your client received during the match. A small test in a custom game showed that about 5 seconds of using one of these Drop-hacks on myself, through my very low bandwidth connection, produced a replay with an events file that was 917KB long (this gets compressed substantially, since the gibberish is produced in a very simple manner), compared to a normal replay which would be about 100KB of events uncompressed over 30 minutes.
All that would be required for Blizzard to fix this is to do a very simple filtering on events. I highly doubt this would slow down their server very much at all, if properly implemented, and it would take a 3-year-old about 2 minutes to implement. Why they have yet to patch their server, I have no idea.
[edit/addendum] The only limiting factor for the drop hacker is his upload bandwidth. The limiting factors for the person being drop hacked are his download bandwidth and his CPU speed. If the drop hacker has your average American cable connection, his upload bandwidth is maybe 384kBps. The person being drophacked would need something like a 1MBps download and something like an i7 to properly fend against it. Running SC2 from a SSD (hard drive) probably doesn't hurt, either.
Well, you're probably correct on how the hack is working. However, don't act as if it's such a simple thing to fix and that Blizzard is being stupid. A change, however simple, needs to be thoroughly tested before being released. What if their filter actually made the game worse for a lot of others? Also, have you proven that the "simple" filter will actually work?
|
ok im giving up at 8 discs;;
i swear to god if blizzard does a qualification tour for blizzcon with the top 16 players on the ladder imma be pissed
|
I'm assuming NowGtTheFkUp is one of these cheaters? I mean he is 206/6 on NA....
|
Fuck me man... i got like 6 ddrop hacked* today.
|
On July 04 2011 12:20 schmutttt wrote:
I'm assuming NowGtTheFkUp is one of these cheaters? I mean he is 206/6 on NA....
I heard reading last two pages of thread is hard.
|
The fact that blizzard hasn't done anything just further damages the legitimacy of the ladder.
Custom games/4v4 gogogogogo (no hackers here, so more fun experience)
|
On July 04 2011 12:12 Azzur wrote:Show nested quote +On July 04 2011 04:22 Furlqt wrote:
Made an account to try and clarify some thing about what exactly the Lag/Drop Hack is and how it works.
Essentially, the Battle.Net protocol is based around players sending events to the server and the server sending those events back to all the players in a match. These events all have unique IDs, and the codes for these events are relatively sparse (that is to say, if you pick a random number between 1 and 24 million, chances are it's not a valid event). However, the server does no filtering as to whether an event is valid--it sends the event down the pipe regardless of validity.
So, the drop hack works, essentially, by abusing this system to DoS your client. It spams the B.Net server with gibberish event IDs as fast as the Drop-Hacker's network can handle, and the B.Net server sends this back to your client, where your client is left confused trying to figure out why the server sent it a gibberish event. It looks up the event in all the game files and goes through all the rhetoric--but, these gibberish events are coming down the pipe so fast that the client locks itself up through this.
I think, also, but I'm not sure, that when a client encounters a gibberish event it tries to ask the server to resend the event, meaning one gibberish event might strike a chain of events that can't stop itself.
Now, this is also why when you're looking at a replay of these hackers that it slows down your client, since the replay is just a copy of the events that your client received during the match. A small test in a custom game showed that about 5 seconds of using one of these Drop-hacks on myself, through my very low bandwidth connection, produced a replay with an events file that was 917KB long (this gets compressed substantially, since the gibberish is produced in a very simple manner), compared to a normal replay which would be about 100KB of events uncompressed over 30 minutes.
All that would be required for Blizzard to fix this is to do a very simple filtering on events. I highly doubt this would slow down their server very much at all, if properly implemented, and it would take a 3-year-old about 2 minutes to implement. Why they have yet to patch their server, I have no idea.
[edit/addendum] The only limiting factor for the drop hacker is his upload bandwidth. The limiting factors for the person being drop hacked are his download bandwidth and his CPU speed. If the drop hacker has your average American cable connection, his upload bandwidth is maybe 384kBps. The person being drophacked would need something like a 1MBps download and something like an i7 to properly fend against it. Running SC2 from a SSD (hard drive) probably doesn't hurt, either. Well, you're probably correct on how the hack is working. However, don't act as if it's such a simple thing to fix and that Blizzard is being stupid. A change, however simple, needs to be thoroughly tested before being released. What if their filter actually made the game worse for a lot of others? Also, have you proven that the "simple" filter will actually work?
The simple filter would just be a boolean hashmap into a function call, nothing fancy, and yes, in the current game design, it would work. Now, yes, it would need to be properly tested, and you are right in that even if they were addressing the issue right now they wouldn't be able to patch their server so quickly. Nevertheless, there are no CS reps banning the hackers right now, no real action at all from Blizzard really.
And, as far as I can tell, I think the only path to immunity might be to throttle one's download to a really low rate like 5kBps so your client doesn't get flooded so easily--not the CPU/Network speed stuff I was spewing earlier 
|
Watching anybody stream NA ladder is just disgusting these days. Endless drophackers... Ladder is absolute garbage right now.
|
At least ban the people like CombatEZ, sixraxterran, and NowGtTheFckUp. how long does that take? jesus christ.
|
On July 04 2011 12:30 Furlqt wrote:Show nested quote +On July 04 2011 12:12 Azzur wrote:On July 04 2011 04:22 Furlqt wrote:
Made an account to try and clarify some thing about what exactly the Lag/Drop Hack is and how it works.
Essentially, the Battle.Net protocol is based around players sending events to the server and the server sending those events back to all the players in a match. These events all have unique IDs, and the codes for these events are relatively sparse (that is to say, if you pick a random number between 1 and 24 million, chances are it's not a valid event). However, the server does no filtering as to whether an event is valid--it sends the event down the pipe regardless of validity.
So, the drop hack works, essentially, by abusing this system to DoS your client. It spams the B.Net server with gibberish event IDs as fast as the Drop-Hacker's network can handle, and the B.Net server sends this back to your client, where your client is left confused trying to figure out why the server sent it a gibberish event. It looks up the event in all the game files and goes through all the rhetoric--but, these gibberish events are coming down the pipe so fast that the client locks itself up through this.
I think, also, but I'm not sure, that when a client encounters a gibberish event it tries to ask the server to resend the event, meaning one gibberish event might strike a chain of events that can't stop itself.
Now, this is also why when you're looking at a replay of these hackers that it slows down your client, since the replay is just a copy of the events that your client received during the match. A small test in a custom game showed that about 5 seconds of using one of these Drop-hacks on myself, through my very low bandwidth connection, produced a replay with an events file that was 917KB long (this gets compressed substantially, since the gibberish is produced in a very simple manner), compared to a normal replay which would be about 100KB of events uncompressed over 30 minutes.
All that would be required for Blizzard to fix this is to do a very simple filtering on events. I highly doubt this would slow down their server very much at all, if properly implemented, and it would take a 3-year-old about 2 minutes to implement. Why they have yet to patch their server, I have no idea.
[edit/addendum] The only limiting factor for the drop hacker is his upload bandwidth. The limiting factors for the person being drop hacked are his download bandwidth and his CPU speed. If the drop hacker has your average American cable connection, his upload bandwidth is maybe 384kBps. The person being drophacked would need something like a 1MBps download and something like an i7 to properly fend against it. Running SC2 from a SSD (hard drive) probably doesn't hurt, either. Well, you're probably correct on how the hack is working. However, don't act as if it's such a simple thing to fix and that Blizzard is being stupid. A change, however simple, needs to be thoroughly tested before being released. What if their filter actually made the game worse for a lot of others? Also, have you proven that the "simple" filter will actually work? The simple filter would just be a boolean hashmap into a function call, nothing fancy, and yes, in the current game design, it would work. Now, yes, it would need to be properly tested, and you are right in that even if they were addressing the issue right now they wouldn't be able to patch their server so quickly. Nevertheless, there are no CS reps banning the hackers right now, no real action at all from Blizzard really. And, as far as I can tell, I think the only path to immunity might be to throttle one's download to a really low rate like 5kBps so your client doesn't get flooded so easily--not the CPU/Network speed stuff I was spewing earlier
So, basically drop yourself before they can hack you?
|
On July 04 2011 12:30 Furlqt wrote:Show nested quote +On July 04 2011 12:12 Azzur wrote:On July 04 2011 04:22 Furlqt wrote:
Made an account to try and clarify some thing about what exactly the Lag/Drop Hack is and how it works.
Essentially, the Battle.Net protocol is based around players sending events to the server and the server sending those events back to all the players in a match. These events all have unique IDs, and the codes for these events are relatively sparse (that is to say, if you pick a random number between 1 and 24 million, chances are it's not a valid event). However, the server does no filtering as to whether an event is valid--it sends the event down the pipe regardless of validity.
So, the drop hack works, essentially, by abusing this system to DoS your client. It spams the B.Net server with gibberish event IDs as fast as the Drop-Hacker's network can handle, and the B.Net server sends this back to your client, where your client is left confused trying to figure out why the server sent it a gibberish event. It looks up the event in all the game files and goes through all the rhetoric--but, these gibberish events are coming down the pipe so fast that the client locks itself up through this.
I think, also, but I'm not sure, that when a client encounters a gibberish event it tries to ask the server to resend the event, meaning one gibberish event might strike a chain of events that can't stop itself.
Now, this is also why when you're looking at a replay of these hackers that it slows down your client, since the replay is just a copy of the events that your client received during the match. A small test in a custom game showed that about 5 seconds of using one of these Drop-hacks on myself, through my very low bandwidth connection, produced a replay with an events file that was 917KB long (this gets compressed substantially, since the gibberish is produced in a very simple manner), compared to a normal replay which would be about 100KB of events uncompressed over 30 minutes.
All that would be required for Blizzard to fix this is to do a very simple filtering on events. I highly doubt this would slow down their server very much at all, if properly implemented, and it would take a 3-year-old about 2 minutes to implement. Why they have yet to patch their server, I have no idea.
[edit/addendum] The only limiting factor for the drop hacker is his upload bandwidth. The limiting factors for the person being drop hacked are his download bandwidth and his CPU speed. If the drop hacker has your average American cable connection, his upload bandwidth is maybe 384kBps. The person being drophacked would need something like a 1MBps download and something like an i7 to properly fend against it. Running SC2 from a SSD (hard drive) probably doesn't hurt, either. Well, you're probably correct on how the hack is working. However, don't act as if it's such a simple thing to fix and that Blizzard is being stupid. A change, however simple, needs to be thoroughly tested before being released. What if their filter actually made the game worse for a lot of others? Also, have you proven that the "simple" filter will actually work? The simple filter would just be a boolean hashmap into a function call, nothing fancy, and yes, in the current game design, it would work. Now, yes, it would need to be properly tested, and you are right in that even if they were addressing the issue right now they wouldn't be able to patch their server so quickly. Nevertheless, there are no CS reps banning the hackers right now, no real action at all from Blizzard really. And, as far as I can tell, I think the only path to immunity might be to throttle one's download to a really low rate like 5kBps so your client doesn't get flooded so easily--not the CPU/Network speed stuff I was spewing earlier
How about they just ban guest accounts from laddering, which would solve everything.
|
Also a victim of oGsBisu... cheaters getting famous for cheating.
Backwards world we live in Blizzard!
|
On July 04 2011 12:52 Heavenly wrote:
At least ban the people like CombatEZ, sixraxterran, and NowGtTheFckUp. how long does that take? jesus christ.
SC2 isn't a service based game (like MMOs). The SC2 team is most likely off for the next day or 2.
|
On July 04 2011 13:00 aksfjh wrote:Show nested quote +On July 04 2011 12:52 Heavenly wrote:
At least ban the people like CombatEZ, sixraxterran, and NowGtTheFckUp. how long does that take? jesus christ. SC2 isn't a service based game (like MMOs). The SC2 team is most likely off for the next day or 2.
Yes it is. Except for vs. AI, the game is worthless without bnet working due to no LAN and no alternate servers.
|
|
|
|
|
|
EPT
