|
You have to provide some kind of evidence/proof (screenshots/replays etc.) if you are going to accuse somebody.
Additionally, a supporting comment of what people should be looking for and when will be necessary if you are posting replays/evidence. |
On May 31 2012 00:43 BeeNu wrote:
Was that DSNiNETAiL guy determined to be a maphacker? I'm a bit suspicious since I see him spamming channels offering GM level coaching all the time and if he is a hacker he's likely scamming people out of money... I know I saw his name show up in this thread a while ago but idk if anything was decided about him.
he entered gm just to scam people for money by coaching them
|
On May 31 2012 00:43 BeeNu wrote:
Was that DSNiNETAiL guy determined to be a maphacker? I'm a bit suspicious since I see him spamming channels offering GM level coaching all the time and if he is a hacker he's likely scamming people out of money... I know I saw his name show up in this thread a while ago but idk if anything was decided about him.
The consensus seems to be that this replay proves he hacks:
http://drop.sc/188346
|
Trace maphacks,
follows army the entire game. but if you don't have time to look at everything just watch 21:32 he storms army when there burrowed and he does not see them burrow. I watched his camera view 3 times im 100% sure he did not see them burrow. so 21:32 for those who do not have time to see entire replay, even though there is evidence all throughout the game.
also if you were to say he assumed my army was burrowed there, watch his storms he storms the big patches on the left side rather than the middle and completely ignores right. he storms twice where the big patch of burrowed roaches are and ignores the other side where there is a few.
12:10~ he looks at my army with camera view in the dark and moves his entire army there, did not have any LOS for the attack
14:45~ looks at my army in the dark again and selects units to move them in place once he confirms where there going
22:42~ looks at army in the dark to check size
http://drop.sc/188736
please add Trace to front page of maphackers
|
"but if you don't have time to look at everything just watch 21:32 he storms army when there burrowed and he does not see them burrow. I watched his camera view 3 times im 100% sure he did not see them burrow. so 21:32 for those who do not have time to see entire replay"
Uuh cant you still see burrowed units, just like you can see cloaked units?
I thought the ground did look slightly different when there units burrowed.
He could have just seen the anomaly on the ground and storm?
Realy, like 99% of the evidence presented here is absolutely terrible.
In anny game you will sometimes see one army react perfectly to the movements of the other army, just by pure change!
Pros move their army all the time and There basicly only 3 movements possible lol, to the left or to the right, or hold position.
Anny movement towards the left, when the opponents army is aproaching from the left does look suspicious but the change to move somewhat in the right direction is actually like 33% >< now add in some gm game sense and people will move to the right place more often then they do not.
Just picking out thoose situations and ignoring all situations when there was no perfect reaction makes absolutely no sense.
100% proxying at the right spot on 4 player maps definatly is a clear tell though.
edit: well then i am wrong, i always have been under the impression that it is possible to "see" burrowed units (even when they not moving) just like you could see cloaked units.
If you realy cant see them then this should be a good evidence (though he could still preemptivly storm for burrowed banelings,though that seems unlikely)
I am maybe wrong here in wich case i like to apologise. (are you 100% sure you can not see non moving burrowed units?)
i stand by the rest of my post that the majority of the "evidence" here is realy terrible and hardly suspicious.
Also i definatly dont want to defend anny hacker (proxying 100% at the right spot is definnatly a clear tell). I hate hackers more then annyone here probably and i quit several games before because other people did hack.
I do think though that some of you are jumping to conclusions based on evidence wich is mostly circomstantial (sp?).
When looking at tournaments i often see pros move in the right direction without knowing whats to come.
Day 9 then says something like, "great gamesense from MC to intercept that drop, knowing it could come at this time"
I think you could pick out a few suspicious moments in EVERY grandmaster game if you did look hard enough.
|
you joking right? you can't see burrowed units if they are stationary, furthermore even if there is an idea that there are units burrowed there you wouldn't storm completely over the biggest chunks and ignore the smaller chunks to the side, makes no logical sense.
+ he is looking at the army in the dark THAN moving his army... it's so blatant I don't see how anyone with a reasonable IQ can defend him
|
On May 30 2012 17:19 Mendelfist wrote:Well, in that case it's even worse. Continuously sending the current game state (encrypted) over the net is no more viable than sending parts of it on demand. There are just too many units involved in SC2. The paper focuses a lot on solving the cryptographic problem of when to lift the fog of war, and goes to length to show how efficient their algorithm is, but it does not mention that it requires a completely different network architecture than SC2 currently uses, an architecture that is so inefficient that I don't think it would be possible to use. This blog discusses exactly this problem: http://www.altdevblogaday.com/2011/07/09/synchronous-rts-engines-and-a-tale-of-desyncs/
Again, this is addressed in the paper. Please don't blame the paper for my misinterpretation of it - you really should read it. They do discuss why sending the entire gamestate isn't feasible for RTS and go into detail that I can't go into because of space restrictions and the fact that I haven't spent enough time on the subject yet.
Like I said, my understanding is that you cannot have a fully synchronized client, i.e. have both clients simulate all movements of all units, simply because by design you will not want both clients to have full knowledge of the gamestate. If both clients have that information available to them in an unencrypted form, you cannot avoid the possibility of maphacks. However, I don't see why you couldn't simulate the movements of all units in the visibility of both players in lockstep.
However, you *can* communicate encrypted updates to the opponent and then only send the encryption keys as needed. This is done by communicating a list of what grid cells are visible to you (visibility map) as well as what units you have in each grid cell. To speed up computation, you do this hierarchically by splitting the map recursively into quadrants. You then send the changes to your opponent. In other words, you communicate your unit list and your visibility map, but do so in an encrypted fashion. Your opponent does the same to you. To avoid leaking information about the amount of units or how much of the map is available to you, you add chaff (fake data) to keep the amount of data sent constant.
Because of the encryption method used, players can decrypt V_a ^ V_b - that is, the union of the visibility map for player A as well as the union for the visibility map of player B. You cannot learn anything about the areas that aren't visible to both.
By design, this makes for the complete absence of passive attacks: i.e. maphacks and production hacks etc. However, it does nothing to prevent active attacks, such as blink hacks, burrow micro hacks, autoinject, auto-anything, adding extra units to your army, hacked build times, hacked unit stats, et cetera. Unlike maphacks however, these kinds of hacks are pretty trivial to detect post facto. That could even be made into an automatic process: i.e. to check the legality of your opponents moves after the game by uploading a signed copy of your replay after the game as well as periodically sending signed hashes of chunks of your action list to the other players during the game. That way, detecting disrepancies can be made automatic and completely traceable.
I can't answer as to how much difference this makes in lagginess off hand. In the paper, they did some analysis and came up with figures as follows: players usually only do a maximum of 2 game-state changing actions per second. The rest are camera-changes that don't change the game-state and thus don't need to be communicated. Calculating all of the encryption creates some overhead, to the tune of less than 20 microseconds per opponent in the worst case. Basically this means that you have to send in the worst case 2 encrypted state changes per second, each a few hundred bytes long, and each taking a few ten microseconds to encrypt.
As for what implications that has for the implementations of the netcode, I'm not really sure. My understanding is that you cannot send the mere input list, but rather that you have to communicate the delta of your gamestate at each simulation tick. You do not have to communicate changes that haven't happened.
It's an interesting topic, and I really don't do the researchers justice. Please don't attack my interpretation of what I've read., because I'm pretty certain I must have gotten a few things wrong when trying to relay the gist of the paper here. Instead, read the paper at http://crypto.stanford.edu/~dabo/pubs/papers/onlinegames.pdf and let me know what you think about it - also feel free to contact the researches themselves with your feedback.
---
The paper also cites another paper called "Battle of Botcraft" (available at http://www.cs.wm.edu/~hnw/paper/hop.pdf ) that proposes a method of bot detection based on machine learning methods. This is something we could already start doing right now, without any changes to any network code. By categorizing replays into "hacks" and "not hacks", and detecting common features for the hacked replays we could make hack detection automatic.
For instance, looking at the dsninetail replay, action sequences such as:
15:55 DSNiNETAiL Deselect all
15:55 DSNiNETAiL Blink (Stalker); target: x=32.3,y=46.7
15:55 DSNiNETAiL Attack; target: x=37.9,y=54.9
---
15:56 DSNiNETAiL Deselect all
15:56 DSNiNETAiL Blink (Stalker); target: x=57.8,y=45.5
15:56 DSNiNETAiL Attack; target: x=48.6,y=46.3
---
15:56 DSNiNETAiL Deselect all
15:56 DSNiNETAiL Blink (Stalker); target: x=57.8,y=45.5
15:56 DSNiNETAiL Attack; target: x=48.6,y=46.3
crop up, the same way every time. The time stamp here fails to indicate that the above sequences happen within a single frame.
Squirtle's blink micro on the other hand generates action sequences as follows:
13:59 StarTale Select Stalker x3 (10830,10834,1083c), Immortal (205ec), Deselect 2 units
13:59 StarTale Blink (Stalker); target: x=95.5,y=159.7
14:05 StarTale Select Stalker (10674), Deselect all
14:05 StarTale Blink (Stalker); target: x=97.6,y=155.2
14:06 StarTale Select Stalker x3 (306d4,206e4,10834), Deselect all
Again, the timestamp here fails to indicate that the lag between the actions is much higher: to the tune of several hundred milliseconds.
Machine learning tools could find other indicators too. Comparing the hacked replay to a pro replay you find the following split in the hack replay:
+ Show Spoiler +0:01 DSNiNETAiL Select Nexus (10298)
0:01 DSNiNETAiL Train Probe
0:01 DSNiNETAiL Select Probe x3 (102a0,102a8,102b0), Deselect all
0:01 DSNiNETAiL Right click; target: Mineral Field (101e0)
0:02 DSNiNETAiL Select Probe x3 (1029c,102a4,102ac), Deselect all
0:02 DSNiNETAiL Right click; target: Mineral Field (10144)
0:02 DSNiNETAiL Select Nexus (10298), Deselect all
0:02 DSNiNETAiL Right click; target: Mineral Field (101a4)
0:17 DSNiNETAiL Hotkey Assign 1
0:17 DSNiNETAiL Hotkey Assign 2
0:17 DSNiNETAiL Hotkey Assign 3
0:18 DSNiNETAiL Hotkey Assign 4
0:18 DSNiNETAiL Train Probe
Meanwhile, human players such as squirtle would have splits that generate actions as follows:
+ Show Spoiler +0:01 StarTale Select Nexus (10250)
0:01 StarTale Train Probe
0:01 StarTale Select Probe x6 (10254,10258,1025c,10260,10264,10268), Deselect all
0:01 StarTale Right click; target: Mineral Field (10114)
0:01 StarTale Right click; target: Mineral Field (10114)
0:02 StarTale Deselect 6 units
0:02 StarTale Right click; target: Mineral Field (10170)
0:02 StarTale Select Nexus (10250), Deselect all
0:02 StarTale Right click; target: x=129.9,y=162.7
0:03 StarTale Right click; target: x=129.9,y=162.7
0:03 StarTale Right click; target: Mineral Field (100bc)
0:03 StarTale Right click; target: Mineral Field (100bc)
0:03 StarTale Right click; target: Mineral Field (100bc)
0:04 StarTale Hotkey Assign 4
0:04 StarTale Select Probe (10258), Deselect all
0:05 StarTale Hotkey Select 4
0:05 StarTale Select Mineral Field (100bc), Deselect all
0:06 StarTale Select Probe (10258), Deselect all
0:06 StarTale Hotkey Assign 1
0:07 StarTale Hotkey Select 4
0:07 StarTale Right click; target: Mineral Field (10118)
0:07 StarTale Hotkey Select 1
0:07 StarTale Hotkey Select 4
0:07 StarTale Hotkey Select 1
0:07 StarTale Hotkey Select 4
0:14 StarTale Hotkey Select 1
0:14 StarTale Hotkey Select 4
0:14 StarTale Hotkey Select 1
0:15 StarTale Hotkey Select 4
0:15 StarTale Hotkey Select 1
0:16 StarTale Select Probe (10264)
0:16 StarTale Hotkey Select 4
0:16 StarTale Select Probe x3 (10254,1025c,10268), Deselect all
0:16 StarTale Hotkey Select 4
0:17 StarTale Hotkey Select 1
0:17 StarTale Hotkey Select 4
0:17 StarTale Select Probe x2 (10258,10264), Deselect all
0:17 StarTale Hotkey Select 4
0:17 StarTale Select Probe x4 (10254,1025c,10260,10268), Deselect all
0:17 StarTale Hotkey Select 4
0:17 StarTale Hotkey Select 1
0:18 StarTale Hotkey Select 4
0:18 StarTale Train Probe
There are loads of potential indicators out there to mine data from, such as click speed/accuracy etc. By comparing these sorts of action sequences and finding indicators, we could get somewhere with automatic hack detection. All we would need are corpuses of "known hack" replays as well as "known good" replays to start training.
|
On May 31 2012 01:15 kmh wrote:Show nested quote +On May 30 2012 17:19 Mendelfist wrote:Well, in that case it's even worse. Continuously sending the current game state (encrypted) over the net is no more viable than sending parts of it on demand. There are just too many units involved in SC2. The paper focuses a lot on solving the cryptographic problem of when to lift the fog of war, and goes to length to show how efficient their algorithm is, but it does not mention that it requires a completely different network architecture than SC2 currently uses, an architecture that is so inefficient that I don't think it would be possible to use. This blog discusses exactly this problem: Again, this is addressed in the paper. Please don't blame the paper for my misinterpretation of it - you really should read it. They do discuss why sending the entire gamestate isn't feasible for RTS and go into detail that I can't go into because of space restrictions and the fact that I haven't spent enough time on the subject yet. Like I said, my understanding is that you cannot have a fully synchronized client, i.e. have both clients simulate all movements of all units, simply because by design you will not want both clients to have full knowledge of the gamestate. If both clients have that information available to them in an unencrypted form, you cannot avoid the possibility of maphacks. However, I don't see why you couldn't simulate the movements of all units in the visibility of both players in lockstep. However, you *can* communicate encrypted updates to the opponent and then only send the encryption keys as needed. This is done by communicating a list of what grid cells are visible to you (visibility map) as well as what units you have in each grid cell. To speed up computation, you do this hierarchically by splitting the map recursively into quadrants. You then send the changes to your opponent. In other words, you communicate your unit list and your visibility map, but do so in an encrypted fashion. Your opponent does the same to you. To avoid leaking information about the amount of units or how much of the map is available to you, you add chaff (fake data) to keep the amount of data sent constant. Because of the encryption method used, players can decrypt V_a ^ V_b - that is, the union of the visibility map for player A as well as the union for the visibility map of player B. You cannot learn anything about the areas that aren't visible to both. By design, this makes for the complete absence of passive attacks: i.e. maphacks and production hacks etc. However, it does nothing to prevent active attacks, such as blink hacks, burrow micro hacks, autoinject, auto-anything, adding extra units to your army, hacked build times, hacked unit stats, et cetera. Unlike maphacks however, these kinds of hacks are pretty trivial to detect post facto. That could even be made into an automatic process: i.e. to check the legality of your opponents moves after the game by uploading a signed copy of your replay after the game as well as periodically sending signed hashes of chunks of your action list to the other players during the game. That way, detecting disrepancies can be made automatic and completely traceable. I can't answer as to how much difference this makes in lagginess off hand. In the paper, they did some analysis and came up with figures as follows: players usually only do a maximum of 2 game-state changing actions per second. The rest are camera-changes that don't change the game-state and thus don't need to be communicated. Calculating all of the encryption creates some overhead, to the tune of less than 20 microseconds per opponent in the worst case. Basically this means that you have to send in the worst case 2 encrypted state changes per second, each a few hundred bytes long, and each taking a few ten microseconds to encrypt. As for what implications that has for the implementations of the netcode, I'm not really sure. My understanding is that you cannot send the mere input list, but rather that you have to communicate the delta of your gamestate at each simulation tick. You do not have to communicate changes that haven't happened. It's an interesting topic, and I really don't do the researchers justice. Please don't attack my interpretation of what I've read., because I'm pretty certain I must have gotten a few things wrong when trying to relay the gist of the paper here. Instead, read the paper at http://crypto.stanford.edu/~dabo/pubs/papers/onlinegames.pdf and let me know what you think about it - also feel free to contact the researches themselves with your feedback. --- The paper also cites another paper called "Battle of Botcraft" (available at http://www.cs.wm.edu/~hnw/paper/hop.pdf) that proposes a method of bot detection based on machine learning methods. This is something we could already start doing right now, without any changes to any network code. By categorizing replays into "hacks" and "not hacks", and detecting common features for the hacked replays we could make hack detection automatic. For instance, looking at the dsninetail replay, action sequences such as: 15:55 DSNiNETAiL Deselect all 15:55 DSNiNETAiL Blink (Stalker); target: x=32.3,y=46.7 15:55 DSNiNETAiL Attack; target: x=37.9,y=54.9 --- 15:56 DSNiNETAiL Deselect all 15:56 DSNiNETAiL Blink (Stalker); target: x=57.8,y=45.5 15:56 DSNiNETAiL Attack; target: x=48.6,y=46.3 --- 15:56 DSNiNETAiL Deselect all 15:56 DSNiNETAiL Blink (Stalker); target: x=57.8,y=45.5 15:56 DSNiNETAiL Attack; target: x=48.6,y=46.3 crop up, the same way every time. The time stamp here fails to indicate that the above sequences happen within a single frame. Squirtle's blink micro on the other hand generates action sequences as follows: 13:59 StarTale Select Stalker x3 (10830,10834,1083c), Immortal (205ec), Deselect 2 units 13:59 StarTale Blink (Stalker); target: x=95.5,y=159.7 14:05 StarTale Select Stalker (10674), Deselect all 14:05 StarTale Blink (Stalker); target: x=97.6,y=155.2 14:06 StarTale Select Stalker x3 (306d4,206e4,10834), Deselect all Again, the timestamp here fails to indicate that the lag between the actions is much higher: to the tune of several hundred milliseconds. Machine learning tools could find other indicators too. Comparing the hacked replay to a pro replay you find the following split in the hack replay: + Show Spoiler +0:01 DSNiNETAiL Select Nexus (10298)
0:01 DSNiNETAiL Train Probe
0:01 DSNiNETAiL Select Probe x3 (102a0,102a8,102b0), Deselect all
0:01 DSNiNETAiL Right click; target: Mineral Field (101e0)
0:02 DSNiNETAiL Select Probe x3 (1029c,102a4,102ac), Deselect all
0:02 DSNiNETAiL Right click; target: Mineral Field (10144)
0:02 DSNiNETAiL Select Nexus (10298), Deselect all
0:02 DSNiNETAiL Right click; target: Mineral Field (101a4)
0:17 DSNiNETAiL Hotkey Assign 1
0:17 DSNiNETAiL Hotkey Assign 2
0:17 DSNiNETAiL Hotkey Assign 3
0:18 DSNiNETAiL Hotkey Assign 4
0:18 DSNiNETAiL Train Probe Meanwhile, human players such as squirtle would have splits that generate actions as follows: + Show Spoiler +0:01 StarTale Select Nexus (10250)
0:01 StarTale Train Probe
0:01 StarTale Select Probe x6 (10254,10258,1025c,10260,10264,10268), Deselect all
0:01 StarTale Right click; target: Mineral Field (10114)
0:01 StarTale Right click; target: Mineral Field (10114)
0:02 StarTale Deselect 6 units
0:02 StarTale Right click; target: Mineral Field (10170)
0:02 StarTale Select Nexus (10250), Deselect all
0:02 StarTale Right click; target: x=129.9,y=162.7
0:03 StarTale Right click; target: x=129.9,y=162.7
0:03 StarTale Right click; target: Mineral Field (100bc)
0:03 StarTale Right click; target: Mineral Field (100bc)
0:03 StarTale Right click; target: Mineral Field (100bc)
0:04 StarTale Hotkey Assign 4
0:04 StarTale Select Probe (10258), Deselect all
0:05 StarTale Hotkey Select 4
0:05 StarTale Select Mineral Field (100bc), Deselect all
0:06 StarTale Select Probe (10258), Deselect all
0:06 StarTale Hotkey Assign 1
0:07 StarTale Hotkey Select 4
0:07 StarTale Right click; target: Mineral Field (10118)
0:07 StarTale Hotkey Select 1
0:07 StarTale Hotkey Select 4
0:07 StarTale Hotkey Select 1
0:07 StarTale Hotkey Select 4
0:14 StarTale Hotkey Select 1
0:14 StarTale Hotkey Select 4
0:14 StarTale Hotkey Select 1
0:15 StarTale Hotkey Select 4
0:15 StarTale Hotkey Select 1
0:16 StarTale Select Probe (10264)
0:16 StarTale Hotkey Select 4
0:16 StarTale Select Probe x3 (10254,1025c,10268), Deselect all
0:16 StarTale Hotkey Select 4
0:17 StarTale Hotkey Select 1
0:17 StarTale Hotkey Select 4
0:17 StarTale Select Probe x2 (10258,10264), Deselect all
0:17 StarTale Hotkey Select 4
0:17 StarTale Select Probe x4 (10254,1025c,10260,10268), Deselect all
0:17 StarTale Hotkey Select 4
0:17 StarTale Hotkey Select 1
0:18 StarTale Hotkey Select 4
0:18 StarTale Train Probe
There are loads of potential indicators out there to mine data from, such as click speed/accuracy etc. By comparing these sorts of action sequences and finding indicators, we could get somewhere with automatic hack detection. All we would need are corpuses of "known hack" replays as well as "known good" replays to start training.
This is by far the simplest and most logical way I've seen someone suggest on this whole thread. Blizzard needs to hire you. I think if they had a staff of maybe 10? people looking at the action sequences either through an automated system or training people to have an eye for this so they can quickly go through submitted replays...This is astounding.
|
On May 31 2012 00:57 Rassy wrote:
"but if you don't have time to look at everything just watch 21:32 he storms army when there burrowed and he does not see them burrow. I watched his camera view 3 times im 100% sure he did not see them burrow. so 21:32 for those who do not have time to see entire replay"
Uuh cant you still see burrowed units, just like you can see cloaked units?
I thought the ground did look slightly different when there units burrowed.
He could have just seen the anomaly on the ground and storm?
Realy, like 99% of the evidence presented here is absolutely terrible.
In anny game you will sometimes see one army react perfectly to the movements of the other army, just by pure change!
Pros move their army all the time and There basicly only 3 movements possible lol, to the left or to the right, or hold position.
Anny movement towards the left, when the opponents army is aproaching from the left does look suspicious but the change to move somewhat in the right direction is actually like 33% >< now add in some gm game sense and people will move to the right place more often then they do not.
Just picking out thoose situations and ignoring all situations when there was no perfect reaction makes absolutely no sense.
100% proxying at the right spot on 4 player maps definatly is a clear tell though.
edit: well then i am wrong, i always have been under the impression that it is possible to "see" burrowed units (even when they not moving) just like you could see cloaked units.
If you realy cant see them then this should be a good evidence (though he could still preemptivly storm for burrowed banelings,though that seems unlikely)
I am maybe wrong here in wich case i like to apologise. (are you 100% sure you can not see non moving burrowed units?)
i stand by the rest of my post that the majority of the "evidence" here is realy terrible and hardly suspicious.
Also i definatly dont want to defend anny hacker (proxying 100% at the right spot is definnatly a clear tell). I hate hackers more then annyone here probably and i quit several games before because other people did hack.
I do think though that some of you are jumping to conclusions based on evidence wich is mostly circomstantial (sp?).
When looking at tournaments i often see pros move in the right direction without knowing whats to come.
Day 9 then says something like, "great gamesense from MC to intercept that drop, knowing it could come at this time"
I think you could pick out a few suspicious moments in EVERY grandmaster game if you did look hard enough.
It's people like you that let hackers get away with what they do because you're so blinded by "people being able to be so amazing at this game" and casters saying that "this community is amazing" that you don't understand that people hack in online games and SC2 is an online game. Maybe for you the evidence presented is not proof enough, but for people who actually have common sense and understand this game know that a lot of the evidence is obvious
|
ObZen:
The replay analysis should be as automatic as possible to be of any worth. Further, it would be pretty catastrophic to have false positives. False negatives (labeling a replay as probably human when it is in fact hacked) would be more acceptable. The replays that are suspicious could then be human-reviewed. I don't envision a future in which blizzard can be arsed to use such a tool, but that doesn't stop us from creating it.
Now, obviously this doesn't detect passive map hacks or such, but we could certainly detect certain bot hacks such as queen inject hacks, blink hacks, burrow hacks etc. I'm guessing map hacks could have suspicious camera movement patterns that could be detected; we need to datamine replays to find that out. Who knows what will pop up?
But yeah, detecting patterns like this would make it worthwhile to create a database of "known hack"-replays as a starting point.
|
Even though this thread is about impa and is the only thread i can find without it being ended, here is a hacker i also bumped into on the ladder seeing since we all know impa is a hacker. His/Her name is Skrosnk Protoss player here is the link: http://drop.sc/188783
|
On May 30 2012 16:19 Yoshi Kirishima wrote:Show nested quote +On May 30 2012 16:06 T.O.P. wrote:On May 30 2012 15:51 Yoshi Kirishima wrote:On May 30 2012 12:03 ZweiGaming wrote:On May 30 2012 11:07 paintfive wrote:Here's another hacker: http://drop.sc/188521Drops MULEs without selecting the CC or looking at the mineral line. 10:00 - decides to kill a pylon powering a stargate he hasn't even scouted instead of going straight for the mineral lines. 4:10 - sends marine out to snipe a probe that he hasn't even seen. and other shady shit. This guy is too low master for me to start asking replays of him, he would be hard to keep track of so I will not be doing so, i'm sorry. You can send this replay to blizzard via their email system at hacks@blizzard for them to analyse it. Wish you luck with it On May 30 2012 11:21 HappyTimePANDA wrote:On May 30 2012 11:15 dmasterding wrote:On May 30 2012 10:51 HappyTimePANDA wrote:On May 30 2012 10:45 aYtDuSteR wrote:On May 30 2012 10:43 HappyTimePANDA wrote:
Hackers will hack. I never understood the major upset on things like this. If people enjoy their game more hacking, then so be it. If you want to play normal then go and try and beat them. I should say I never have hacked a game, but I loved "god mode" in games I've played. I guess what I am saying is don't take this so seriously, unless you are a pro it doesn't matter. (even then tourny results matter not ladder) 1. Game was not meant to be played with 3rd party cheats and it ruins the enjoyment for people not using hacks. 2. Even though I want to play a normal game how can I when they are hacking. It's intrinsically impossible. 1. not many run with hacks. 2. Aim to be good enough to beat the hack 3. Who cares? I think most people forget the game is meant to be played for fun. Your record isn't some sign of your masculinity Hackers are a small percentage to legit players So we shouldn't crack down on hackers who are cheating and are being placed in GM in the place of legitimate Masters players who aren't hacking but are desperately trying to get their place in GM? You can get some ridiculous advantages by hacking - "aiming to be good enough to beat the hack" is probably not feasable. "most people forget the game is meant to be played for fun. Your record isn't some sign of your masculinity" I hate this argument so so so so so much. Being competitive about your record doesn't mean that you're not having fun - to me, my rank and achieving that rank IS fun. I derive fun from the feeling of working hard to teach myself the game, getting stronger mechanics and being able to appreciate the fruits of my labor. However, unjustly having a lower rank because people above me are maphacking and blink-stalker-micro-hacking is not fun at all. blizzard updates to cancel out the hacks. I just don't think it deserves more attention than that. No matter what people whine about it won't be dealt with any faster. When they update the hacks will go out, and within a day new hacks will be out. Why people like you think you can make the hacks go away is beyond me. I would be happy with a hack free game. I would also like a hack free internet etc It does make it faster when we have evidence, just profile Impa, he got kicked out of GM in a 24 hours matter (he had no bonus pool) and is now sitting in bronze (guessing he's banned). He had no loss in between GM to bronze, so it makes me quite enthusiatic that we played a role into this. Wow! That's awesome :D now we can use this as a way to persuade people that it's definitely not true that blizzard "doesn't care" or that "reporting does nothing", etc. Reporting still does nothing. They were only banned because this became a big deal on TL and reddit. Reporting on bnet... and reporting through sc2 does do something, even if it's not very significant i know some people are reported many times but nothing seems to happen but i have a friend who was quickly temp banned so, it depends
I also have to wonder how many hacking reports Blizzard gets that are just wrong or done by idiots who don't know how to play. I am sure it is several times more than the valid reports. They may just have to many false reports to pick out the real hackers without additional evidence.
|
Now i am not sure so sorry about that first post, but the probe thing and the very low scouting is just super weird and abnormal for a kid with a 50% w/l ratio and in the top 8 of his masters division.
|
On May 31 2012 01:15 kmh wrote:+ Show Spoiler +Again, this is addressed in the paper. Please don't blame the paper for my misinterpretation of it - you really should read it. They do discuss why sending the entire gamestate isn't feasible for RTS and go into detail that I can't go into because of space restrictions and the fact that I haven't spent enough time on the subject yet. Like I said, my understanding is that you cannot have a fully synchronized client, i.e. have both clients simulate all movements of all units, simply because by design you will not want both clients to have full knowledge of the gamestate. If both clients have that information available to them in an unencrypted form, you cannot avoid the possibility of maphacks. However, I don't see why you couldn't simulate the movements of all units in the visibility of both players in lockstep. However, you *can* communicate encrypted updates to the opponent and then only send the encryption keys as needed. This is done by communicating a list of what grid cells are visible to you (visibility map) as well as what units you have in each grid cell. To speed up computation, you do this hierarchically by splitting the map recursively into quadrants. You then send the changes to your opponent. In other words, you communicate your unit list and your visibility map, but do so in an encrypted fashion. Your opponent does the same to you. To avoid leaking information about the amount of units or how much of the map is available to you, you add chaff (fake data) to keep the amount of data sent constant. Because of the encryption method used, players can decrypt V_a ^ V_b - that is, the union of the visibility map for player A as well as the union for the visibility map of player B. You cannot learn anything about the areas that aren't visible to both. By design, this makes for the complete absence of passive attacks: i.e. maphacks and production hacks etc. However, it does nothing to prevent active attacks, such as blink hacks, burrow micro hacks, autoinject, auto-anything, adding extra units to your army, hacked build times, hacked unit stats, et cetera. Unlike maphacks however, these kinds of hacks are pretty trivial to detect post facto. That could even be made into an automatic process: i.e. to check the legality of your opponents moves after the game by uploading a signed copy of your replay after the game as well as periodically sending signed hashes of chunks of your action list to the other players during the game. That way, detecting disrepancies can be made automatic and completely traceable. I can't answer as to how much difference this makes in lagginess off hand. In the paper, they did some analysis and came up with figures as follows: players usually only do a maximum of 2 game-state changing actions per second. The rest are camera-changes that don't change the game-state and thus don't need to be communicated. Calculating all of the encryption creates some overhead, to the tune of less than 20 microseconds per opponent in the worst case. Basically this means that you have to send in the worst case 2 encrypted state changes per second, each a few hundred bytes long, and each taking a few ten microseconds to encrypt. As for what implications that has for the implementations of the netcode, I'm not really sure. My understanding is that you cannot send the mere input list, but rather that you have to communicate the delta of your gamestate at each simulation tick. You do not have to communicate changes that haven't happened. It's an interesting topic, and I really don't do the researchers justice. Please don't attack my interpretation of what I've read., because I'm pretty certain I must have gotten a few things wrong when trying to relay the gist of the paper here. Instead, read the paper at http://crypto.stanford.edu/~dabo/pubs/papers/onlinegames.pdf and let me know what you think about it - also feel free to contact the researches themselves with your feedback. --- The paper also cites another paper called "Battle of Botcraft" (available at http://www.cs.wm.edu/~hnw/paper/hop.pdf ) that proposes a method of bot detection based on machine learning methods. This is something we could already start doing right now, without any changes to any network code. By categorizing replays into "hacks" and "not hacks", and detecting common features for the hacked replays we could make hack detection automatic. For instance, looking at the dsninetail replay, action sequences such as: 15:55 DSNiNETAiL Deselect all 15:55 DSNiNETAiL Blink (Stalker); target: x=32.3,y=46.7 15:55 DSNiNETAiL Attack; target: x=37.9,y=54.9 --- 15:56 DSNiNETAiL Deselect all 15:56 DSNiNETAiL Blink (Stalker); target: x=57.8,y=45.5 15:56 DSNiNETAiL Attack; target: x=48.6,y=46.3 --- 15:56 DSNiNETAiL Deselect all 15:56 DSNiNETAiL Blink (Stalker); target: x=57.8,y=45.5 15:56 DSNiNETAiL Attack; target: x=48.6,y=46.3 crop up, the same way every time. The time stamp here fails to indicate that the above sequences happen within a single frame. Squirtle's blink micro on the other hand generates action sequences as follows: 13:59 StarTale Select Stalker x3 (10830,10834,1083c), Immortal (205ec), Deselect 2 units 13:59 StarTale Blink (Stalker); target: x=95.5,y=159.7 14:05 StarTale Select Stalker (10674), Deselect all 14:05 StarTale Blink (Stalker); target: x=97.6,y=155.2 14:06 StarTale Select Stalker x3 (306d4,206e4,10834), Deselect all Again, the timestamp here fails to indicate that the lag between the actions is much higher: to the tune of several hundred milliseconds. Machine learning tools could find other indicators too. Comparing the hacked replay to a pro replay you find the following split in the hack replay: + Show Spoiler +0:01 DSNiNETAiL Select Nexus (10298)
0:01 DSNiNETAiL Train Probe
0:01 DSNiNETAiL Select Probe x3 (102a0,102a8,102b0), Deselect all
0:01 DSNiNETAiL Right click; target: Mineral Field (101e0)
0:02 DSNiNETAiL Select Probe x3 (1029c,102a4,102ac), Deselect all
0:02 DSNiNETAiL Right click; target: Mineral Field (10144)
0:02 DSNiNETAiL Select Nexus (10298), Deselect all
0:02 DSNiNETAiL Right click; target: Mineral Field (101a4)
0:17 DSNiNETAiL Hotkey Assign 1
0:17 DSNiNETAiL Hotkey Assign 2
0:17 DSNiNETAiL Hotkey Assign 3
0:18 DSNiNETAiL Hotkey Assign 4
0:18 DSNiNETAiL Train Probe Meanwhile, human players such as squirtle would have splits that generate actions as follows: + Show Spoiler +0:01 StarTale Select Nexus (10250)
0:01 StarTale Train Probe
0:01 StarTale Select Probe x6 (10254,10258,1025c,10260,10264,10268), Deselect all
0:01 StarTale Right click; target: Mineral Field (10114)
0:01 StarTale Right click; target: Mineral Field (10114)
0:02 StarTale Deselect 6 units
0:02 StarTale Right click; target: Mineral Field (10170)
0:02 StarTale Select Nexus (10250), Deselect all
0:02 StarTale Right click; target: x=129.9,y=162.7
0:03 StarTale Right click; target: x=129.9,y=162.7
0:03 StarTale Right click; target: Mineral Field (100bc)
0:03 StarTale Right click; target: Mineral Field (100bc)
0:03 StarTale Right click; target: Mineral Field (100bc)
0:04 StarTale Hotkey Assign 4
0:04 StarTale Select Probe (10258), Deselect all
0:05 StarTale Hotkey Select 4
0:05 StarTale Select Mineral Field (100bc), Deselect all
0:06 StarTale Select Probe (10258), Deselect all
0:06 StarTale Hotkey Assign 1
0:07 StarTale Hotkey Select 4
0:07 StarTale Right click; target: Mineral Field (10118)
0:07 StarTale Hotkey Select 1
0:07 StarTale Hotkey Select 4
0:07 StarTale Hotkey Select 1
0:07 StarTale Hotkey Select 4
0:14 StarTale Hotkey Select 1
0:14 StarTale Hotkey Select 4
0:14 StarTale Hotkey Select 1
0:15 StarTale Hotkey Select 4
0:15 StarTale Hotkey Select 1
0:16 StarTale Select Probe (10264)
0:16 StarTale Hotkey Select 4
0:16 StarTale Select Probe x3 (10254,1025c,10268), Deselect all
0:16 StarTale Hotkey Select 4
0:17 StarTale Hotkey Select 1
0:17 StarTale Hotkey Select 4
0:17 StarTale Select Probe x2 (10258,10264), Deselect all
0:17 StarTale Hotkey Select 4
0:17 StarTale Select Probe x4 (10254,1025c,10260,10268), Deselect all
0:17 StarTale Hotkey Select 4
0:17 StarTale Hotkey Select 1
0:18 StarTale Hotkey Select 4
0:18 StarTale Train Probe
There are loads of potential indicators out there to mine data from, such as click speed/accuracy etc. By comparing these sorts of action sequences and finding indicators, we could get somewhere with automatic hack detection. All we would need are corpuses of "known hack" replays as well as "known good" replays to start training.
Best post I've read today, good stuff.
|
On May 31 2012 01:15 kmh wrote:Show nested quote +On May 30 2012 17:19 Mendelfist wrote:Well, in that case it's even worse. Continuously sending the current game state (encrypted) over the net is no more viable than sending parts of it on demand. There are just too many units involved in SC2. The paper focuses a lot on solving the cryptographic problem of when to lift the fog of war, and goes to length to show how efficient their algorithm is, but it does not mention that it requires a completely different network architecture than SC2 currently uses, an architecture that is so inefficient that I don't think it would be possible to use. This blog discusses exactly this problem: http://www.altdevblogaday.com/2011/07/09/synchronous-rts-engines-and-a-tale-of-desyncs/ Again, this is addressed in the paper. Please don't blame the paper for my misinterpretation of it - you really should read it. They do discuss why sending the entire gamestate isn't feasible for RTS
I quote: "In a peer-to-peer game, the easiest way to keep game data in sync between players is for each client to
broadcast its entire state (units, buildings, etc) to all other game clients. We call this the push approach. As far as we
know, this is the only approach used in practice because it minimizes latency and code complexity."
This is the exact opposite of what you said, and they are completely wrong. RTS games often use lockstep (including SC2), not "the push approach".
Basically this means that you have to send in the worst case 2 encrypted state changes per second, each a few hundred bytes long, and each taking a few ten microseconds to encrypt.
I can't see how you got this figure. First of all, the figure 2 game states per seconds is wrong. If you look at their graphs they have averaged them. They don't show the max value. The worst case is much higher. The game state change can also potentially be very large. Imagine a scan of the opponents army. There is no way to mitigate this in the worst case, which you have to design for. The game state inevitably has to get from one side to the other through the network, and I can't imagine how to compress this to "a few hundred bytes" for hundreds of units. Is their solution impossible? No, but extremely inefficient, and no, they do not adress this problem. I have read the paper. My objections still stand.
It's an interesting topic, and I really don't do the researchers justice. Please don't attack my interpretation of what I've read.
I'm not attacking your interpretation. I'm attacking the concept with problems that I can't see any way around.
|
On May 31 2012 01:15 kmh wrote:Show nested quote +On May 30 2012 17:19 Mendelfist wrote:Well, in that case it's even worse. Continuously sending the current game state (encrypted) over the net is no more viable than sending parts of it on demand. There are just too many units involved in SC2. The paper focuses a lot on solving the cryptographic problem of when to lift the fog of war, and goes to length to show how efficient their algorithm is, but it does not mention that it requires a completely different network architecture than SC2 currently uses, an architecture that is so inefficient that I don't think it would be possible to use. This blog discusses exactly this problem: http://www.altdevblogaday.com/2011/07/09/synchronous-rts-engines-and-a-tale-of-desyncs/ Again, this is addressed in the paper. Please don't blame the paper for my misinterpretation of it - you really should read it. They do discuss why sending the entire gamestate isn't feasible for RTS and go into detail that I can't go into because of space restrictions and the fact that I haven't spent enough time on the subject yet. Like I said, my understanding is that you cannot have a fully synchronized client, i.e. have both clients simulate all movements of all units, simply because by design you will not want both clients to have full knowledge of the gamestate. If both clients have that information available to them in an unencrypted form, you cannot avoid the possibility of maphacks. However, I don't see why you couldn't simulate the movements of all units in the visibility of both players in lockstep. However, you *can* communicate encrypted updates to the opponent and then only send the encryption keys as needed. This is done by communicating a list of what grid cells are visible to you (visibility map) as well as what units you have in each grid cell. To speed up computation, you do this hierarchically by splitting the map recursively into quadrants. You then send the changes to your opponent. In other words, you communicate your unit list and your visibility map, but do so in an encrypted fashion. Your opponent does the same to you. To avoid leaking information about the amount of units or how much of the map is available to you, you add chaff (fake data) to keep the amount of data sent constant. Because of the encryption method used, players can decrypt V_a ^ V_b - that is, the union of the visibility map for player A as well as the union for the visibility map of player B. You cannot learn anything about the areas that aren't visible to both. By design, this makes for the complete absence of passive attacks: i.e. maphacks and production hacks etc. However, it does nothing to prevent active attacks, such as blink hacks, burrow micro hacks, autoinject, auto-anything, adding extra units to your army, hacked build times, hacked unit stats, et cetera. Unlike maphacks however, these kinds of hacks are pretty trivial to detect post facto. That could even be made into an automatic process: i.e. to check the legality of your opponents moves after the game by uploading a signed copy of your replay after the game as well as periodically sending signed hashes of chunks of your action list to the other players during the game. That way, detecting disrepancies can be made automatic and completely traceable. I can't answer as to how much difference this makes in lagginess off hand. In the paper, they did some analysis and came up with figures as follows: players usually only do a maximum of 2 game-state changing actions per second. The rest are camera-changes that don't change the game-state and thus don't need to be communicated. Calculating all of the encryption creates some overhead, to the tune of less than 20 microseconds per opponent in the worst case. Basically this means that you have to send in the worst case 2 encrypted state changes per second, each a few hundred bytes long, and each taking a few ten microseconds to encrypt. As for what implications that has for the implementations of the netcode, I'm not really sure. My understanding is that you cannot send the mere input list, but rather that you have to communicate the delta of your gamestate at each simulation tick. You do not have to communicate changes that haven't happened. It's an interesting topic, and I really don't do the researchers justice. Please don't attack my interpretation of what I've read., because I'm pretty certain I must have gotten a few things wrong when trying to relay the gist of the paper here. Instead, read the paper at http://crypto.stanford.edu/~dabo/pubs/papers/onlinegames.pdf and let me know what you think about it - also feel free to contact the researches themselves with your feedback. --- The paper also cites another paper called "Battle of Botcraft" (available at http://www.cs.wm.edu/~hnw/paper/hop.pdf ) that proposes a method of bot detection based on machine learning methods. This is something we could already start doing right now, without any changes to any network code. By categorizing replays into "hacks" and "not hacks", and detecting common features for the hacked replays we could make hack detection automatic. For instance, looking at the dsninetail replay, action sequences such as: 15:55 DSNiNETAiL Deselect all 15:55 DSNiNETAiL Blink (Stalker); target: x=32.3,y=46.7 15:55 DSNiNETAiL Attack; target: x=37.9,y=54.9 --- 15:56 DSNiNETAiL Deselect all 15:56 DSNiNETAiL Blink (Stalker); target: x=57.8,y=45.5 15:56 DSNiNETAiL Attack; target: x=48.6,y=46.3 --- 15:56 DSNiNETAiL Deselect all 15:56 DSNiNETAiL Blink (Stalker); target: x=57.8,y=45.5 15:56 DSNiNETAiL Attack; target: x=48.6,y=46.3 crop up, the same way every time. The time stamp here fails to indicate that the above sequences happen within a single frame. Squirtle's blink micro on the other hand generates action sequences as follows: 13:59 StarTale Select Stalker x3 (10830,10834,1083c), Immortal (205ec), Deselect 2 units 13:59 StarTale Blink (Stalker); target: x=95.5,y=159.7 14:05 StarTale Select Stalker (10674), Deselect all 14:05 StarTale Blink (Stalker); target: x=97.6,y=155.2 14:06 StarTale Select Stalker x3 (306d4,206e4,10834), Deselect all Again, the timestamp here fails to indicate that the lag between the actions is much higher: to the tune of several hundred milliseconds. Machine learning tools could find other indicators too. Comparing the hacked replay to a pro replay you find the following split in the hack replay: + Show Spoiler +0:01 DSNiNETAiL Select Nexus (10298)
0:01 DSNiNETAiL Train Probe
0:01 DSNiNETAiL Select Probe x3 (102a0,102a8,102b0), Deselect all
0:01 DSNiNETAiL Right click; target: Mineral Field (101e0)
0:02 DSNiNETAiL Select Probe x3 (1029c,102a4,102ac), Deselect all
0:02 DSNiNETAiL Right click; target: Mineral Field (10144)
0:02 DSNiNETAiL Select Nexus (10298), Deselect all
0:02 DSNiNETAiL Right click; target: Mineral Field (101a4)
0:17 DSNiNETAiL Hotkey Assign 1
0:17 DSNiNETAiL Hotkey Assign 2
0:17 DSNiNETAiL Hotkey Assign 3
0:18 DSNiNETAiL Hotkey Assign 4
0:18 DSNiNETAiL Train Probe Meanwhile, human players such as squirtle would have splits that generate actions as follows: + Show Spoiler +0:01 StarTale Select Nexus (10250)
0:01 StarTale Train Probe
0:01 StarTale Select Probe x6 (10254,10258,1025c,10260,10264,10268), Deselect all
0:01 StarTale Right click; target: Mineral Field (10114)
0:01 StarTale Right click; target: Mineral Field (10114)
0:02 StarTale Deselect 6 units
0:02 StarTale Right click; target: Mineral Field (10170)
0:02 StarTale Select Nexus (10250), Deselect all
0:02 StarTale Right click; target: x=129.9,y=162.7
0:03 StarTale Right click; target: x=129.9,y=162.7
0:03 StarTale Right click; target: Mineral Field (100bc)
0:03 StarTale Right click; target: Mineral Field (100bc)
0:03 StarTale Right click; target: Mineral Field (100bc)
0:04 StarTale Hotkey Assign 4
0:04 StarTale Select Probe (10258), Deselect all
0:05 StarTale Hotkey Select 4
0:05 StarTale Select Mineral Field (100bc), Deselect all
0:06 StarTale Select Probe (10258), Deselect all
0:06 StarTale Hotkey Assign 1
0:07 StarTale Hotkey Select 4
0:07 StarTale Right click; target: Mineral Field (10118)
0:07 StarTale Hotkey Select 1
0:07 StarTale Hotkey Select 4
0:07 StarTale Hotkey Select 1
0:07 StarTale Hotkey Select 4
0:14 StarTale Hotkey Select 1
0:14 StarTale Hotkey Select 4
0:14 StarTale Hotkey Select 1
0:15 StarTale Hotkey Select 4
0:15 StarTale Hotkey Select 1
0:16 StarTale Select Probe (10264)
0:16 StarTale Hotkey Select 4
0:16 StarTale Select Probe x3 (10254,1025c,10268), Deselect all
0:16 StarTale Hotkey Select 4
0:17 StarTale Hotkey Select 1
0:17 StarTale Hotkey Select 4
0:17 StarTale Select Probe x2 (10258,10264), Deselect all
0:17 StarTale Hotkey Select 4
0:17 StarTale Select Probe x4 (10254,1025c,10260,10268), Deselect all
0:17 StarTale Hotkey Select 4
0:17 StarTale Hotkey Select 1
0:18 StarTale Hotkey Select 4
0:18 StarTale Train Probe
There are loads of potential indicators out there to mine data from, such as click speed/accuracy etc. By comparing these sorts of action sequences and finding indicators, we could get somewhere with automatic hack detection. All we would need are corpuses of "known hack" replays as well as "known good" replays to start training.
I think Blizzard will look into the issues if the Blink hack or other such hacks become more common. However, those sorts of hacks are so obvious that it may not be worth the programming effort to make an effective program(one that does that can be updated easily and does not bog down the servers) to detect it. Anything that preforms additional actions can be easily dectected by the community and reported. Though, as I stated before, I am sure that Blizzard has to many "false" reports of hacking or cheating to seperate the wheat from the chaff. Threads like this are a good way to highlight the worst offenders and bring them to Blizzards attention.
Map hacks are a whole other issue and not one that is easily solved. But cheating is part of any competitive activity and the only way to deal with it is to watch and report. The best thing Blizzard did was make a replay system that records so much information to allow people who truely care about the game to root out the cheaters. There is no silver bullet or program that is going to solve the problem.
|
You raise some very good points, and I would be inclined to agree with you. However:
On May 31 2012 02:52 Mendelfist wrote:
Imagine a scan of the opponents army.
This is speficically mentioned as a very simple change: you simply send the change in your visibility map over (V_A) and can thus decrypt the union of V_A and U_B. Scanning does not require your opponent to send you all the information of the units you scanned. He has already sent you all of that data in encrypted form previously. Instead, you merely need the information to be able to decrypt that particular (hyper)grid cell.
Remember: your opponent is constantly sending you his unit positions in encrypted form. At no point in time is there a sudden massive data influx.
As for not being able to simulate unit movements in lockstep anymore, you would seem to be absolutely correct.
|
They've done banning him, He has been devoted back to bronze.
But if there is any others you should make sure you have good proof  )
I'm on EU anyways
|
On May 31 2012 03:09 kmh wrote:You raise some very good points, and I would be inclined to agree with you. However: Remember: your opponent is constantly sending you his unit positions in encrypted form. At no point in time is there a sudden massive data influx.
So why did you object when I said "Continuously sending the current game state (encrypted) over the net is no more viable than sending parts of it on demand."? You said this is addressed in the paper. It isn't. By "sending the current game state" I don't mean repeatedly sending the complete game state (which of course would be utterly impossible) but changes in unit positions etc.
The fact that they think that broadcasting the entire game state between clients is the only used approach in RTS games tells me that these folks don't have a clue about game design. They seem more interested in the cryptographic problem.
|
On May 31 2012 03:22 Mendelfist wrote:Show nested quote +On May 31 2012 03:09 kmh wrote:You raise some very good points, and I would be inclined to agree with you. However: On May 31 2012 02:52 Mendelfist wrote:
Imagine a scan of the opponents army. Remember: your opponent is constantly sending you his unit positions in encrypted form. At no point in time is there a sudden massive data influx. So why did you object when I said "Continuously sending the current game state (encrypted) over the net is no more viable than sending parts of it on demand."? You said this is addressed in the paper. It isn't. By "sending the current game state" I don't mean repeatedly sending the complete game state (which of course would be utterly impossible) but changes in unit positions etc. The fact that they think that broadcasting the entire game state between clients is the only used approach in RTS games tells me that these folks don't have a clue about game design. They seem more interested in the cryptographic problem.
I think that both clients having the same information is critical to having a secure game. Otherwise people would build other hacks that mess with the syncing of the clients or flat out lie to them. After all, where there is a computer program, there is a hack. If Blizzard built such a system to begin with, we would be having the same discussion but we would saying "Why didn't Blizzard just build a system where all the information on both client's is the same? Don't they know anything about design?"
People will cheat because they want to cheat. They will find ways to do it, because they want to cheat. It has happened in every game since we started connecting computers. Hell, it happened on counsels when people got a turbo button on a controller and you didn't. There is no silver bullet to solving the issue beyond raw man power. The best detector for a cheater is another human looking at a detailed replay with lots of information. The best way to deal with that cheater once detected is to ban them.
|
I just played this guy twice - definitely a map hacker.
http://drop.sc/188814
We spawn cross on Shakuras - he 7pools, sends his overlord right to my base, then his lings, without ever scouting. Then never uses his mutas, probably because I had stalkers ready to defend.
http://drop.sc/188812
I lost the first one, and then my next game is him again cross spawn on Entombed. He 10 pools this time, and I get a cannon up before lings are there. He goes straight to the rocks at my natural, without scouting if I put a cannon up at the front. Then, when I move out to attack, he goes around my army and straight to reinforcements he can't see consistently.
The funny thing is that he still manages to lose, even to someone he just played, and still BMs.
|
|
|
|
|
|
EPT
