|
Since coming back to BW I've found it's nearly impossible to get a normal game going on battle.net without someone blatantly hacking.
I make a living as a programmer and I want to look into developing my own version of an anti-hack/utility. I'm mostly wanting to do this because it seems like a fun little project.
I don't know anything about the way that these hacks manipulate StarCraft but I figure if I know the exploits that current hacks are using I can put measures in place to detect them and possibly prevent them.
Does anyone know if any source code for maphacks is available? Does any documentation exist for creating tools like this so that I have a jumping off point?
Thanks.
|
The BWAPI has the "complete map information" flag which allows it to access every piece of information from the opponent.
|
Just don't play on battle.net, easy.
|
The problem with detecting maphacks is that you can't analyze game packets to determine if someone is map hacking, thus requiring everyone in the game to run your antihack so that it can scan the process's memory. ICCup achieves this by doing a MD5 checksum in StarCraft.exe's memory space.
If you have good knowledge of assembly and hooking, please contact me since I'm interested in capturing game packets to write functions to detect other hacks.
|
There is nothing you can do against certain kinds of hacks, the reason for this is simple:
All the information is available on the computer of the hacker. The full map, with all units, all buildings, all research, all resources, etc is available in memory. All the hacker has to do is read his own memory. You can NOT detect if a remote computer is reading its own memory. You can NOT detect what the remote computer is doing with the read data. You can NOT prevent a remote computer from reading its own memory.
Some hacks manipulate the game directly (by rewriting their own memory) thus they make everything accessible within the game. These kinds of hacks can be detected by the game itself by checking its own memory for any changes. Of course, the anti-hack can be hacked to disable it again. Another problem is that the hacker needs to have the anti-hack installed and running to check for the hack. If YOU run your anti hack it does absolutely nothing to prevent somebody else from hacking.
But even if the hacker is running an anti-hack and is not overwriting his own memory with malicious code he can still simply read the memory and display it some other way. He could have a second monitor showing him all the information. There is absolutely NOTHING an anti-hack can do against that. You can not prevent a hacker from reading his own memory and showing it to him.
The only way to prevent these kinds of hacks effectively is to change the entire architecture of the application and re-write it from scratch. Something that is not going to happen.
|
There used to be several anti-hack tools available and I'm betting that they are still effective now.
First off there were highly effective anti-hack observer maps that would drop a player if it detected a hack. I believe it would drop an observer too if they had one on (say like a rally-point hack or drop hack)
It was available for several popular maps at the time like:
RoV, BlueStorm, Paranoid Android, python, lt, to name a few off the top of my head.
I still have these maps, if you are interested I can upload them.
There was also 3rd party tools you could use to detect hacks, it would alert you of what hack was used.
BWHF comes to mind, it was highly effective at detecting auto-mine and used a system that detected if an opponent clicked a unit/building that they wouldn't otherwise be able to see under fog-of-war / shroud-of-darkness.
It also added the player's nickname to a database and would alert you if you were to come across said hacker again.
However, if a player was smart and used a map hack without clicking on opponent's units/buildings, it wouldn't detect it.
Then there were other 3rd party programs that I have forgotten now because Blizzard banned every single user that used a 3rd party tool, whether that tool was a hack or anti-hack or not even a hack like chaos launcher/penguin plug. I remember several legit users lost their account with many games on it, while hackers didn't care too much since they usually had only a few games on there anyways.
I believe those anti-hack tools detected whether a specific hack was running, rather than trying to determine if map hack was being used, as stated by users above, a simple map hack could be impossible to detect.
|
On May 21 2016 03:13 RoomOfMush wrote:
The only way to prevent these kinds of hacks effectively is to change the entire architecture of the application and re-write it from scratch. Something that is not going to happen.
What architecture would you suggest?
|
On May 22 2016 03:00 AleXoundOS wrote:Show nested quote +On May 21 2016 03:13 RoomOfMush wrote:
The only way to prevent these kinds of hacks effectively is to change the entire architecture of the application and re-write it from scratch. Something that is not going to happen. What architecture would you suggest?
The most popular system for multiplayer RTS games is the Deterministic Lock-Step system. In this system every single machine runs the entire game. They all play the game in parallel. Each machine does the same operations in the same order with the same outcome and this way we can all play the same game.
To make this work each machine sends the user input to all other machines. When every machine has the user input from all players it will calculate the next "step" of the game. It will actually wait for all messages (thats why when one player lags everybody has to wait).
The obvious result is that each machine has access to everything that is happening in the game. You have the entire map with all units, all buildings, all resources, etc, because you are running the entire game locally.
An alternative is that the game runs on a server. Each machine sends the user input from its local player to the central server, the server calculates the new game state and then only sends back the information that is actually avaiable to the local player. This way every machine actually only knows the things its player is supposed to know. In a system like this all kinds of hacks would become much more difficult if not impossible. You could still cheat by having the computer "guess" positions and resources based on previous information but there is no guarantee for it to be accurate.
The problem is that the first system, the Deterministic Lock-Step, is rather simple to implement and very cheap on the resources. You only have to send tiny bits of data (the user input) compared to the entire game state. To give you some values: If we assume that we send the mouse position (x and y axis) and what buttons are pressed (and we even assume there is like 256 possible buttons) we are only looking at 40 bytes without doing any kinds of compression.
But if we send the whole game state we are looking at:
For each unit: hitpoints (2 bytes), energy (2 bytes), shields (2 bytes), face direction (4 bytes), position (8 bytes), owning player (1 byte), updates (? bytes), the current action being performed (? bytes) the current animation (? bytes) which gets us no less then 20 bytes and possibly much much more. This is for each single unit.
On top of that blizzard would have to pay money for the servers which now have to run the game. Right now they just connect players to bring them together. They dont have to actively do much. When suddenly all players are playing on blizzards computers instead blizzard would have to get 1000x more computing power. This would be outrageous costs.
What I could imagine would be a hybrid system with most games using the old Deterministic Lock-Step method but all 1v1 ladder games from masters or higher would use the advanced system to prevent cheating. This way blizzard could keep the cost relatively low while still offering anti-cheating methods for the people who need them most. They could even add an optional paid subscription where only players who pay a monthly fee (to keep the servers running) can play with the anti-cheating system.
This sure wouldnt give you perfect protection but it would already become much much better.
----------------------------------------------------------
An alternative to the above would be to make hacking more difficult. Basically, what happens right now, is that you (as a hacker) have to find out at which place within your RAM the important information (which you want to obtain) is stored. This is actually not that difficult. An experienced hacker can probably find that out by playing the game and monitoring changes to the RAM in real time to see which actions cause which changes. Once they know how the information is stored its absolutely no difficulty to just read it and then display it in some form or another.
But what blizzard could do is mandatory weekly updates which do absolutely nothing but screw around with the memory layout. This way the information would be someplace else entirely every single week. The hacking tools would need to adjust after each update. Sure, this would not be too much work for a hacker, but the point is that its still work. A hacker has to actually care and update his hacks every week if he wants to continue using it. And all other people who use this hack have to download it again and again and again to keep using it. This will discourage the more lazy users of hacks who just dont bother at some point. It will also make sure that once the hacker has no longer any interest in hacking SC2 his hacks wont work any longer.
For blizzard it shouldnt even be very hard to implement this since it is not a functional change in any way. I believe there are even professional tools out there right now which can do this for you. They simply take your compiled program and move code around to change the memory layout without changing the functionality.
This would be a much weaker protection than the above but it would be almost free. The best thing is that you can combine both of these to make it even more inconvenient for all those who are still trying to hack the above method.
|
The weekly update you suggest, to do nothing but randomize the locations in memory of the data relevant to the hacker, sounds like an awesome suggestion. Isn't that why the hacks always break after a big patch?
|
On May 22 2016 04:30 TheLordofAwesome wrote:
The weekly update you suggest, to do nothing but randomize the locations in memory of the data relevant to the hacker, sounds like an awesome suggestion. Isn't that why the hacks always break after a big patch?
That might be one reason why they break but of course there could be other reasons too. Any aggressive changes to the system will break the hacks since they most likely only read data statically instead of dynamically analyzing the program.
Those weekly patches would probably work initially but of course hackers aint stupid. They are going to figure things out and adapt. The reorganization of the memory layout should be truly random (or at least highly complex determinism) instead of fixed permutations or otherwise hackers are just going to see through the algorithms used and write their hacks to adapt dynamically.
|
On May 22 2016 04:30 TheLordofAwesome wrote:
The weekly update you suggest, to do nothing but randomize the locations in memory of the data relevant to the hacker, sounds like an awesome suggestion. Isn't that why the hacks always break after a big patch?
Yes but it also has the unfortunate consequence of breaking other "hacks" such as APM Alert and Lan Latency. I hope that Blizzard will release a patch soon because that would eliminate the majority of the bad hackers on the official Battle.net servers since no new hacks are being written and none of the current hacks would be updated.
|
On May 22 2016 05:19 xboi209 wrote:Show nested quote +On May 22 2016 04:30 TheLordofAwesome wrote:
The weekly update you suggest, to do nothing but randomize the locations in memory of the data relevant to the hacker, sounds like an awesome suggestion. Isn't that why the hacks always break after a big patch?
Yes but it also has the unfortunate consequence of breaking other "hacks" such as APM Alert and Lan Latency. I hope that Blizzard will release a patch soon because that would eliminate the majority of the bad hackers on the official Battle.net servers since no new hacks are being written and none of the current hacks would be updated.
That's kinda wishful thinking, because at any point in time there will be at least one butthurt nooblet out there who wants to feel like he's worth a damn in this world and will write the script to prove it on Battle.net East.
|
On May 22 2016 03:20 RoomOfMush wrote:Show nested quote +On May 22 2016 03:00 AleXoundOS wrote:On May 21 2016 03:13 RoomOfMush wrote:
The only way to prevent these kinds of hacks effectively is to change the entire architecture of the application and re-write it from scratch. Something that is not going to happen. What architecture would you suggest? An alternative to the above would be to make hacking more difficult. Basically, what happens right now, is that you (as a hacker) have to find out at which place within your RAM the important information (which you want to obtain) is stored. This is actually not that difficult. An experienced hacker can probably find that out by playing the game and monitoring changes to the RAM in real time to see which actions cause which changes. Once they know how the information is stored its absolutely no difficulty to just read it and then display it in some form or another. But what blizzard could do is mandatory weekly updates which do absolutely nothing but screw around with the memory layout. This way the information would be someplace else entirely every single week. The hacking tools would need to adjust after each update. Sure, this would not be too much work for a hacker, but the point is that its still work. A hacker has to actually care and update his hacks every week if he wants to continue using it. And all other people who use this hack have to download it again and again and again to keep using it. This will discourage the more lazy users of hacks who just dont bother at some point. It will also make sure that once the hacker has no longer any interest in hacking SC2 his hacks wont work any longer. For blizzard it shouldnt even be very hard to implement this since it is not a functional change in any way. I believe there are even professional tools out there right now which can do this for you. They simply take your compiled program and move code around to change the memory layout without changing the functionality. This would be a much weaker protection than the above but it would be almost free. The best thing is that you can combine both of these to make it even more inconvenient for all those who are still trying to hack the above method.
If im not mistaken you should be able to do this each time you start a program:
https://en.wikipedia.org/wiki/Address_space_layout_randomization
|
On May 29 2016 23:35 sabas123 wrote:Show nested quote +On May 22 2016 03:20 RoomOfMush wrote:On May 22 2016 03:00 AleXoundOS wrote:On May 21 2016 03:13 RoomOfMush wrote:
The only way to prevent these kinds of hacks effectively is to change the entire architecture of the application and re-write it from scratch. Something that is not going to happen. What architecture would you suggest? An alternative to the above would be to make hacking more difficult. Basically, what happens right now, is that you (as a hacker) have to find out at which place within your RAM the important information (which you want to obtain) is stored. This is actually not that difficult. An experienced hacker can probably find that out by playing the game and monitoring changes to the RAM in real time to see which actions cause which changes. Once they know how the information is stored its absolutely no difficulty to just read it and then display it in some form or another. But what blizzard could do is mandatory weekly updates which do absolutely nothing but screw around with the memory layout. This way the information would be someplace else entirely every single week. The hacking tools would need to adjust after each update. Sure, this would not be too much work for a hacker, but the point is that its still work. A hacker has to actually care and update his hacks every week if he wants to continue using it. And all other people who use this hack have to download it again and again and again to keep using it. This will discourage the more lazy users of hacks who just dont bother at some point. It will also make sure that once the hacker has no longer any interest in hacking SC2 his hacks wont work any longer. For blizzard it shouldnt even be very hard to implement this since it is not a functional change in any way. I believe there are even professional tools out there right now which can do this for you. They simply take your compiled program and move code around to change the memory layout without changing the functionality. This would be a much weaker protection than the above but it would be almost free. The best thing is that you can combine both of these to make it even more inconvenient for all those who are still trying to hack the above method. If im not mistaken you should be able to do this each time you start a program: https://en.wikipedia.org/wiki/Address_space_layout_randomization
But then the code that performs the randomization is part of the program (SC2) and thus in the hands of the hackers. If you give the hackers your code then they will be able to reverse engineer it. If the randomization is purely random (and thus impossible to guess) and done by blizzard (on a secure server) you can be sure that hackers have to figure out the new layout instead of figuring out the algorithm.
|
|
|
|
|
|
EPT
