|
On July 28 2015 23:42 RoomOfMush wrote:
Many hacks work by analysing the RAM and changing values (which you can do absolutely NOTHING against) but there is always security through obscurity. I could imagine automatic updates, perhaps once every week, that move all the variables around and thus make all hacks obsolete. So each time there is an update hackers would have to change their hacks and update as well. This might become tiring for some hackers and discourage them.
you realize that security through obscurity is a sarcastic term and its actually a bad thing, right?
|
On July 29 2015 16:19 weikor wrote:
Ok, on the other hand - lets assume blizzard CANT fix the hacks.
Does it really matter?
Unless hes disrupting my game - drophack etc, or hes gaining an economical advantage - more minerals - the game is still winnable. Maphack really only punishes hidden expansions or cheesy builds you dont want scouted. Maphack basically provides the advantage of 1 scan in his base, and an SCV searching for hidden expos.
Im not trying to defend it, but think of it this way - maphack boosts you up one league, but unless youre winning money it makes no difference .
Imagine, You are diamond, Tony is Silver, and Bob is also diamond.
The other 2 decide that hacking is the way to go.
So bob now advances to master league, but faces mechanically superior opponents - hits a wall and can barely improve - hes still a bad player.
Tony has special service on his hack, advances to diamond - but you still crush him because he makes 30% less SCVS and spends his time supply blocked while looking at the map.
In any way, these players are still "Bad", and for 99% theres no other reason to play sc2 than self improvement.
Sorry, but that's not how it works. Counterattacking, dropping and mutalisk-play all become unviable with this. I've once played a hacker who made it to mass ravens. Good luck trying to get a fungal off if he always knows where your infestors are, even if you burrow them (I didn't even get close to his ravens).
Techswitch based play - completely useless too.
|
On July 29 2015 16:40 brickrd wrote:Show nested quote +On July 28 2015 23:42 RoomOfMush wrote:
Many hacks work by analysing the RAM and changing values (which you can do absolutely NOTHING against) but there is always security through obscurity. I could imagine automatic updates, perhaps once every week, that move all the variables around and thus make all hacks obsolete. So each time there is an update hackers would have to change their hacks and update as well. This might become tiring for some hackers and discourage them. you realize that security through obscurity is a sarcastic term and its actually a bad thing, right?
Worked for Apple.
|
On July 29 2015 16:40 brickrd wrote:Show nested quote +On July 28 2015 23:42 RoomOfMush wrote:
Many hacks work by analysing the RAM and changing values (which you can do absolutely NOTHING against) but there is always security through obscurity. I could imagine automatic updates, perhaps once every week, that move all the variables around and thus make all hacks obsolete. So each time there is an update hackers would have to change their hacks and update as well. This might become tiring for some hackers and discourage them. you realize that security through obscurity is a sarcastic term and its actually a bad thing, right?
It is not a "sarcastic term" it is a strategy. Some people believe it is a suboptimal strategy, but that really depends on the problem at hand.
You can not say one tool is just bad. Its a tool, its designed to do a certain purpose. There are no bad tools, there might only be too few applications for them.
People who say "Security through obscurity" is "bad" really mean that it is worse then a solid foundation that allows you to use more profound security measures. Unfortunately the foundation in our situation is flawed (from a security point of view) and unlikely to change so security through obscurity suddenly becomes a valid option.
Dismissing an option on the grounds of what others say is a very stupid move.
On July 29 2015 15:53 Archiatrus wrote:
I do not think the weekly update thing works. I have no idea how this really works but I assume, that you somehow can "break" into the executable and make specific function calls. So if for example if the mineral count is saved every week on another place you can just update the hack by running something like: drone.deliverMinerals() or similar. Then you just profile which memory accesses are made and you now know where the mineral count is stored. Or for the production tab you run something like openProductionTab(). It will check whether you are a spectator or not. Well, there is the position for the spectator rights Boolean in the memory. Obfuscation of the values would also not work. Just say you build a drone, your worker has minerals, your worker shall deliver them. The last two you repeat 10000 times. You do not have to let it play this for real. Just set the has Boolean that it has minerals true and then deliver. Your cpu should run through this in no time. That way you have all the values from 0-50000 minerals that end on 0 or 5. Then you make some extractor trick at the beginning and you get the values that end on 4 and 9 etc. Actually, imo this "obstacle" would make it more fun to write the hack.
To make it one level harder you could change the function names to random signs. The problem is that at some point the function has to be clear. If you press a hotkey the "hotkeyToFunction"-function needs to know what to do. You would not want your marines to manually detonate when you press stim;) So what you do is call the "hotkeyToFunction"-function with "[stim hotkey]" and monitor which function calls are made after this. Voila you know that 9q82(/&Hsjg& is in fact marine.stim(). So the plan is basically: poke it with a stick and see what exactly happens. Is this hard or tedious? Yes (depending on your hacking abilities). But after you have done it once you just write a script that replicates this very systematically poking and you just run it once per week.
Like I said, I have no idea whether the assumption that you can "break" into the executable, make and monitor function calls and memory accesses is too far fetched. And I am quite sure it is not as easy as described above, but I am also convinced there is no way to prevent or even make it too complicated to hack. The only way is to try to detect hacks somehow when they are used. But this is a lot harder on the blizzard side without violating your privacy. (And then I would be f*cked since I use the MMR Rating Tool;) )
That is not how it works. SC2 is not written in Java, it is a compiled program that you get in byte-code format. There are no functions, there are no methods, there are no classes and there are no structs.
All you can do is monitor the values in your RAM and change them and see what happens. There is no dynamic code analysis that you can perform. Detecting a "hack" is impossible when the hack simply reads and writes your RAM. The user is in full control of his/her computer and blizzard can do jack shit about that. If they want to read their own memory they can do so and you can not detect it or do anything about it.
|
I'm not sure you quite understand Blizzards anti cheat methodology. This is proven from the past. Warden is there to execute a payload of arbitrary code at any time. Blizzard just looks at the popular cheats programs out there, they write a detection routine and one day turn it on. Then they ban all the sheeple that were using it over a weekend in a big wave and make a story about it to scare others from trying it until next year. It's their cost efficient approach of taking out the trash once a year rather than cleaning up every day.
|
On July 29 2015 17:45 aka_star wrote:
I'm not sure you quite understand Blizzards anti cheat methodology. This is proven from the past. Warden is there to execute a payload of arbitrary code at any time. Blizzard just looks at the popular cheats programs out there, they write a detection routine and one day turn it on. Then they ban all the sheeple that were using it over a weekend in a big wave and make a story about it to scare others from trying it until next year. It's their cost efficient approach of taking out the trash once a year rather than cleaning up every day.
They can still do that. The method I proposed can be applied on top of that to make hacking more annoying for the casual hackers. Its a completely automated process that doesnt cost blizzard a penny except for the initial employment.
|
On July 29 2015 17:31 RoomOfMush wrote:Show nested quote +On July 29 2015 15:53 Archiatrus wrote:
I do not think the weekly update thing works. I have no idea how this really works but I assume, that you somehow can "break" into the executable and make specific function calls. So if for example if the mineral count is saved every week on another place you can just update the hack by running something like: drone.deliverMinerals() or similar. Then you just profile which memory accesses are made and you now know where the mineral count is stored. Or for the production tab you run something like openProductionTab(). It will check whether you are a spectator or not. Well, there is the position for the spectator rights Boolean in the memory. Obfuscation of the values would also not work. Just say you build a drone, your worker has minerals, your worker shall deliver them. The last two you repeat 10000 times. You do not have to let it play this for real. Just set the has Boolean that it has minerals true and then deliver. Your cpu should run through this in no time. That way you have all the values from 0-50000 minerals that end on 0 or 5. Then you make some extractor trick at the beginning and you get the values that end on 4 and 9 etc. Actually, imo this "obstacle" would make it more fun to write the hack.
To make it one level harder you could change the function names to random signs. The problem is that at some point the function has to be clear. If you press a hotkey the "hotkeyToFunction"-function needs to know what to do. You would not want your marines to manually detonate when you press stim;) So what you do is call the "hotkeyToFunction"-function with "[stim hotkey]" and monitor which function calls are made after this. Voila you know that 9q82(/&Hsjg& is in fact marine.stim(). So the plan is basically: poke it with a stick and see what exactly happens. Is this hard or tedious? Yes (depending on your hacking abilities). But after you have done it once you just write a script that replicates this very systematically poking and you just run it once per week.
Like I said, I have no idea whether the assumption that you can "break" into the executable, make and monitor function calls and memory accesses is too far fetched. And I am quite sure it is not as easy as described above, but I am also convinced there is no way to prevent or even make it too complicated to hack. The only way is to try to detect hacks somehow when they are used. But this is a lot harder on the blizzard side without violating your privacy. (And then I would be f*cked since I use the MMR Rating Tool;) ) That is not how it works. SC2 is not written in Java, it is a compiled program that you get in byte-code format. There are no functions, there are no methods, there are no classes and there are no structs. All you can do is monitor the values in your RAM and change them and see what happens. There is no dynamic code analysis that you can perform. Detecting a "hack" is impossible when the hack simply reads and writes your RAM. The user is in full control of his/her computer and blizzard can do jack shit about that. If they want to read their own memory they can do so and you can not detect it or do anything about it.
Hm I always thought you could find even after compilation the functions (or specific instruction patterns or.. sry I do not know how to call those). But how did the OP then find the anti-cheat code?
So I can not run those "functions" from the outside on purpose. But what about the editor? You make a special map where the units make a certain set of instructions and you make snapshots of the RAM. See what changed after each instruction and then automatically deduce where what is stored? For example you walk over a mineral globe, get 100 mins, build spine crawler. So some value got up and than down to its original value. Then you run those map after each weekly update.
|
There are literally millions of values that change every few nanoseconds. Just watching for any change and trying to deduce which adress is the right one is a very suboptimal solution, especially if the original value might be obscured (through one of the means I originally described). It would be like picking the right grain of sand on the beach.
If you are interested in the detailed mechanics of reverse engineering I would suggest watching a video on this or reading a tutorial. There are actually videos where people show you how to write a hack for SC2 yourself. Alternatively do an internet search for "reverse engineering C++".
|
On July 29 2015 18:36 RoomOfMush wrote:
There are literally millions of values that change every few nanoseconds. Just watching for any change and trying to deduce which adress is the right one is a very suboptimal solution, especially if the original value might be obscured (through one of the means I originally described). It would be like picking the right grain of sand on the beach.
If you are interested in the detailed mechanics of reverse engineering I would suggest watching a video on this or reading a tutorial. There are actually videos where people show you how to write a hack for SC2 yourself. Alternatively do an internet search for "reverse engineering C++".
I think this is the best summary for why the weekly update idea is not a good one.
|
be aware using this. ReminD (wc3 pro player) got banned from Blizzard by using anticheat (in wc3 days).
|
making hacking very difficult or impossible can't be done. its been a problem for 20 years and lots of big companies have taken a shot at this issue and have failed.
many aspects of the online experience have been improved since 1995 by several studios. however, players using hacks continues to this day.
|
On July 29 2015 21:02 Dickbutt wrote:Show nested quote +On July 29 2015 18:36 RoomOfMush wrote:
There are literally millions of values that change every few nanoseconds. Just watching for any change and trying to deduce which adress is the right one is a very suboptimal solution, especially if the original value might be obscured (through one of the means I originally described). It would be like picking the right grain of sand on the beach.
If you are interested in the detailed mechanics of reverse engineering I would suggest watching a video on this or reading a tutorial. There are actually videos where people show you how to write a hack for SC2 yourself. Alternatively do an internet search for "reverse engineering C++". I think this is the best summary for why the weekly update idea is not a good one.
What? How? Nothing I said in that quoted post has anything to do with weekly updates.
|
I understand nothing about programming but it saddens me to hear this, but from reading your post it seems like you have no clue either about what to do about it? It sucks, but I guess hacking is something we are going to have to deal with. If Blizzard was just more proactive about catching players and looking at reports, that would at least be something.
|
Papua New Guinea1059 Posts
Blizzard is suing hack devs, just the big ones, and have been since the early days of WoW. And trust me, it's not a solution.
|
There is no new anticheat.
It's just the old one from HotS, applied onto LotV. So the cheat works the same by possibly changing 4-10 lines of code?
Blizz is lazy. But they have to find an anticheat, because Heroes of the Storm shares the same engine and the SC2 hack also serves to give vision, and I bet they have to do something about it.
It's 1 problem (engine-based) for 2 games, so they have to fix it some day, for sure.
|
On July 29 2015 17:31 RoomOfMush wrote:Show nested quote +On July 29 2015 16:40 brickrd wrote:On July 28 2015 23:42 RoomOfMush wrote:
Many hacks work by analysing the RAM and changing values (which you can do absolutely NOTHING against) but there is always security through obscurity. I could imagine automatic updates, perhaps once every week, that move all the variables around and thus make all hacks obsolete. So each time there is an update hackers would have to change their hacks and update as well. This might become tiring for some hackers and discourage them. you realize that security through obscurity is a sarcastic term and its actually a bad thing, right? It is not a "sarcastic term" it is a strategy. Some people believe it is a suboptimal strategy, but that really depends on the problem at hand. You can not say one tool is just bad. Its a tool, its designed to do a certain purpose. There are no bad tools, there might only be too few applications for them. People who say "Security through obscurity" is "bad" really mean that it is worse then a solid foundation that allows you to use more profound security measures. Unfortunately the foundation in our situation is flawed (from a security point of view) and unlikely to change so security through obscurity suddenly becomes a valid option. Dismissing an option on the grounds of what others say is a very stupid move.
One good example: even if you have a very good password in a server, there's no good reason not to change the SSH port. You gain nothing against the serious offender, but the random chinese brute force bots won't bother you.
|
I used to laugh at Avilo for constantly accusing his opponents of cheating until I played against a very blatant hacker in a game. I mean I hear about hacks here and there but never experienced very blatant hacking and after that experience, I pretty much lost interest in the game. Coming here and seeing how prevalent it is, I'm glad I stopped playing. It's just not fun playing a game with the goal of getting better and getting higher ranking when in the back of your mind, your opponents could be cheating.
|
On July 29 2015 23:54 bucckevin wrote:
I used to laugh at Avilo for constantly accusing his opponents of cheating until I played against a very blatant hacker in a game. I mean I hear about hacks here and there but never experienced very blatant hacking and after that experience, I pretty much lost interest in the game. Coming here and seeing how prevalent it is, I'm glad I stopped playing. It's just not fun playing a game with the goal of getting better and getting higher ranking when in the back of your mind, your opponents could be cheating.
How old are you ? Welcome to the real world. I can guarantee you that you'll see it everywhere, be it sport, politics, or anything. But hey, it's better to think that the world is fair and peaceful right ?
|
On July 29 2015 23:34 rockslave wrote:Show nested quote +On July 29 2015 17:31 RoomOfMush wrote:On July 29 2015 16:40 brickrd wrote:On July 28 2015 23:42 RoomOfMush wrote:
Many hacks work by analysing the RAM and changing values (which you can do absolutely NOTHING against) but there is always security through obscurity. I could imagine automatic updates, perhaps once every week, that move all the variables around and thus make all hacks obsolete. So each time there is an update hackers would have to change their hacks and update as well. This might become tiring for some hackers and discourage them. you realize that security through obscurity is a sarcastic term and its actually a bad thing, right? It is not a "sarcastic term" it is a strategy. Some people believe it is a suboptimal strategy, but that really depends on the problem at hand. You can not say one tool is just bad. Its a tool, its designed to do a certain purpose. There are no bad tools, there might only be too few applications for them. People who say "Security through obscurity" is "bad" really mean that it is worse then a solid foundation that allows you to use more profound security measures. Unfortunately the foundation in our situation is flawed (from a security point of view) and unlikely to change so security through obscurity suddenly becomes a valid option. Dismissing an option on the grounds of what others say is a very stupid move. One good example: even if you have a very good password in a server, there's no good reason not to change the SSH port. You gain nothing against the serious offender, but the random chinese brute force bots won't bother you.
Thats not a counter-argument. As I said, whether a strategy is "good" or "bad" depends on the situation. A server password is a different situation then a massively multiplayer online game like starcraft.
|
On July 29 2015 17:31 RoomOfMush wrote:Show nested quote +On July 29 2015 16:40 brickrd wrote:On July 28 2015 23:42 RoomOfMush wrote:
Many hacks work by analysing the RAM and changing values (which you can do absolutely NOTHING against) but there is always security through obscurity. I could imagine automatic updates, perhaps once every week, that move all the variables around and thus make all hacks obsolete. So each time there is an update hackers would have to change their hacks and update as well. This might become tiring for some hackers and discourage them. you realize that security through obscurity is a sarcastic term and its actually a bad thing, right? It is not a "sarcastic term" it is a strategy. Some people believe it is a suboptimal strategy, but that really depends on the problem at hand. You can not say one tool is just bad. Its a tool, its designed to do a certain purpose. There are no bad tools, there might only be too few applications for them. People who say "Security through obscurity" is "bad" really mean that it is worse then a solid foundation that allows you to use more profound security measures. Unfortunately the foundation in our situation is flawed (from a security point of view) and unlikely to change so security through obscurity suddenly becomes a valid option. Dismissing an option on the grounds of what others say is a very stupid move.
+1 obfuscation is an option and can work well in the hands of a skilled software developer for certain problems.
obfuscation has been used for many years.
didn't the first few versions of MS Visual Studio come with an obfuscator ?
i'm almost positive MS VS 2005 had one.
Many encryption methodologies include an element of obfuscation.
|
|
|
|
|
|
EPT
