EPTNot sure if this guy is hacking, but his win ratio looked suspicious and he was kind of terrible, had 0/0 upgrades when I had 3/3 yet he has 300 wins and 230 losses.
omg dude! hahahahahahaha this made my day...
Lag hack on NA ladder - Page 43
| Forum Index > SC2 General |
|
AngelusDeLetum
United States98 Posts
Not sure if this guy is hacking, but his win ratio looked suspicious and he was kind of terrible, had 0/0 upgrades when I had 3/3 yet he has 300 wins and 230 losses. omg dude! hahahahahahaha this made my day... | ||
|
TheRabidDeer
United States3806 Posts
I dont play too much, but this guy seemed suspicious enough... you guys think he was map hacking (he is the T, I am the Z)? http://drop.sc/18274 I am pretty new with zerg and only plat with them, first game using muta/ling/bane but either this guy has ee han timing or I think he was hacking. Who stims their marines when defending before he even sees the mutalisks? EDIT: Things that I think are odd 1) 9:30 he dodges my overlords with his banshees 2) 11:50 he has no outside turrets along the edge, then I move towards the left side of the base and he begins building one 3) 13:40 he waits to attack my 3rd (which he didnt scout at all) until my drones transfer there 4) 14:30 he glances at my army through the darkness and falls back before he sees anything, he still hasnt seen my main army 5) 16:40 he moves his army to the right of his natural where my mutas are coming, before he sees them 6) 17:15 he stims his marines towards my mutas heading towards his main before he sees them 7) 26 he mobilizes to take out my 4th from the cliff without seeing it 8) 33:45 he moves his entire army to protect his 4th from my mutas, again without seeing them and yea, done watching it... anybody else agree that those actions are not exactly something you would do without a map hack? | ||
|
VPCursed
1044 Posts
| ||
|
Carush
United States356 Posts
On July 04 2011 03:51 VPCursed wrote: i rly wanted to try and get GM before the reset. Can't now. they hogged 3 spots and every 5 games u find a drophacker this | ||
|
Jakkerr
Netherlands2549 Posts
On July 04 2011 03:51 VPCursed wrote: i rly wanted to try and get GM before the reset. Can't now. they hogged 3 spots and every 5 games u find a drophacker Well let's just hope blizzard can effectively fix this so there will still be a proper ladder. | ||
|
KazKamasa
Sweden186 Posts
On July 04 2011 03:45 TheRabidDeer wrote: + Show Spoiler + Seems maybe people that dont want to quite sink low enough to free wins are using map hack in these last few days? I dont play too much, but this guy seemed suspicious enough... you guys think he was map hacking (he is the T, I am the Z)? http://drop.sc/18274 I am pretty new with zerg and only plat with them, first game using muta/ling/bane but either this guy has ee han timing or I think he was hacking. Who stims their marines when defending before he even sees the mutalisks? EDIT: Things that I think are odd 1) 9:30 he dodges my overlords with his banshees 2) 11:50 he has no outside turrets along the edge, then I move towards the left side of the base and he begins building one 3) 13:40 he waits to attack my 3rd (which he didnt scout at all) until my drones transfer there 4) 14:30 he glances at my army through the darkness and falls back before he sees anything, he still hasnt seen my main army 5) 16:40 he moves his army to the right of his natural where my mutas are coming, before he sees them 6) 17:15 he stims his marines towards my mutas heading towards his main before he sees them 7) 26 he mobilizes to take out my 4th from the cliff without seeing it 8) 33:45 he moves his entire army to protect his 4th from my mutas, again without seeing them and yea, done watching it... anybody else agree that those actions are not exactly something you would do without a map hack? Look at 8:48 - 8:46. He's looking at your expand and your main when it's in the fog of war ? Got to say thats really weird. But only thing you can do is to report him. . . | ||
|
mark05
Canada807 Posts
| ||
|
Furlqt
United States23 Posts
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. | ||
|
dangerjoe
Denmark1866 Posts
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. Great post. Hire this guy Bliz! I havent been dropped yet, but I have experienced some major lags in some games, and I could also see the lag in the replay. I guess they were trying to drop me but somehow it didnt work? Either that or maybe my computer is going down the drain lol | ||
|
ObliviousNA
United States535 Posts
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. Thank you for posting this. I'm a programmer and I was somewhat curious what exploit the drop hack was using. It seems like it would be fairly simple to use a checksum to validate event IDs. The real trouble would be determining whether those IDs make sense, I.E. Player 1 templar no 012 cast storm centered at (x,y). (I'm assuming events look something like this). The server would have no reasonable way to determine whether that is a valid move without doing HUGE amounts of error checking. I guess my question is, once the drophack learns what event IDs are 'valid' (meaning the checksum says it corresponds to an actual event and isn't just a trash value) it seems rather difficult to determine whether the ID has been tampered with in a timely manner. Thoughts? | ||
|
Caphe
Vietnam10817 Posts
Love how Blizzard let this NowGTthefuckup be number one on ladder... EDIT: 2nd time in a row now...how hard we get a Korean to stream and he got fucked by this... | ||
|
Furlqt
United States23 Posts
On July 04 2011 04:40 ObliviousNA wrote: Thank you for posting this. I'm a programmer and I was somewhat curious what exploit the drop hack was using. It seems like it would be fairly simple to use a checksum to validate event IDs. The real trouble would be determining whether those IDs make sense, I.E. Player 1 templar no 012 cast storm centered at (x,y). (I'm assuming events look something like this). The server would have no reasonable way to determine whether that is a valid move without doing HUGE amounts of error checking. I guess my question is, once the drophack learns what event IDs are 'valid' (meaning the checksum says it corresponds to an actual event and isn't just a trash value) it seems rather difficult to determine whether the ID has been tampered with in a timely manner. Thoughts? Well, the current drop-hack was a leak of a private hack developed by somebody who doesn't seem to be identifiable. So, the person with the knowledge to create this hack doesn't seem to be available to create a new one, and even if he is, I doubt it would get republished quickly. To filter this particular hack would be simple since the event IDs are just generated by cycling two bytes of the event ID through a ~10000 value range (just a guess in that range, but it's definitely not filling up 0xFFFF). It seems also to skip over any valid events in that range, probably on purpose. So, yeah, filtering out a small range of IDs would be a quick fix, but it would probably be all that's needed until a client patch can be deployed that would neutralize the attack vector entirely. And the fastest implementation would be something like if (hashmap[(eventId >> 2) % 1024]) removePlayer(); | ||
|
ForeverSleep
Canada920 Posts
On July 04 2011 04:43 Caphe wrote: I am watching Startale_Rainbow, yeah the Korean Rainbow, runner up of GSL open season got drop hacking by the rank 1 GM drophacker right now on his stream. Love how Blizzard let this NowGTthefuckup be number one on ladder... EDIT: 2nd time in a row now...how hard we get a Korean to stream and he got fucked by this... was he playing on Korean server? | ||
|
TheRabidDeer
United States3806 Posts
NA server | ||
|
Saicam
262 Posts
| ||
|
ForeverSleep
Canada920 Posts
Ok then thats why he switched to Korean server. I saw him switch right as I opened his stream | ||
|
ZiegFeld
351 Posts
CombatEZ He will cheese you, if it fails, he'll pull out the map hack. Smarter than the other hackers I suppose. | ||
|
Caphe
Vietnam10817 Posts
On July 04 2011 04:55 ForeverSleep wrote: Ok then thats why he switched to Korean server. I saw him switch right as I opened his stream yeah, after my post, Rainbow got drop hack from the same guy for the 3rd time. He waited around 10 mins after he got the 2nd drop, but still end up with the same guy. After that he just switch to Korea server and end up against MKP, very funny game :D | ||
|
Musketeer
142 Posts
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. | ||
|
Furlqt
United States23 Posts
I couldn't defend it with a Phenom X6 and 8 MB down. Well, either my huge guesses are wrong (likely), or it's someone with a larger upload. I'd figure the amount of damage scales exponentially with upload bandwidth, too (since that's the nature of CPU-level DoSing)--maybe at 384kB it's indefensible, who knows. Regardless, this is something pretty easy to fix on Blizzard's end, and that kills me x-x. Not to mention that NowGtTheFkUp guy has yet to be banned--really? I blame WoW. | ||
| ||
