Advertisement

Stop hacking

Started by June 29, 2017 11:58 AM
11 comments, last by Sergey Ignatchenko 7 years, 2 months ago

Is there a program to ensure that the game I've created does not get hacked from third party apps such as lucky patcher, game guardian, game killer etc. If so, how I do I prevent this obstacle from ruining the game. The game is online based but I just recently found out there are hackers. Is there a program I could use to stop this or is it in the coding.

 

Thankyou

One thing you can do is try to run as much of the game logic as you can on the server side. You can't really trust the data clients give to the server, since they can mess with that data, then pass it to the server. Examples might be telling the server where they are (even if they are not really at that location), or how much health they have left, etc.

Advertisement

Yeah, pretty much what iedoc said. There's no magic software or library that will prevent your game from being hacked. If it's an online game, run any sensitive logic in the server, validate the data you get from the client and make sure you have a strong authentication system and protection against common threats like cross-site scripting, session hijacking and so on (Edit: I just saw the unity tag, so you probably don't need to worry about cross-site scripting and might not need an authentication system).

Also take into account that, unless your game gets a big user base, it's unlikely that anybody actually bothers to hack it, so be mindful of how much effort do you want to put into it beyond basic security practices.

I had a problem with someone decompiling my game client so I bought one of the best code obfuscating programs I could find and all it did was cause peoples virus scanners to think the game client was a virus. I guess people who create viruses use those types of tools.

I do keep as many decisions as possible server side. 

The attacker fully controls the computer that the game client is running on. Just consider what someone can do with a virtual machine with full suspend/rewind/resume support, and you'll realize you cannot "lock up" the client.

The attacker can decompile whatever code is being run on the client, as the client is run it, no matter how much you obfuscate or encrypt the code. Such measures simply don't matter to a determined attacker, because the code needs to be actually runnable by the CPU, and anyone with the right tools can take that instruction stream and disassemble it.

Similarly, the attacker can look at all the data you send and receive on the network. It doesn't matter if you use HTTPS or some other kind of encryption, because the attacker can inject themselves in your network code before the encryption is applied.

You have four options here:

  1. Decide that it doesn't matter if someone is cheating. For games that are largely puzzle games or other single-player experiences, a cheater would mainly just cheat himself. Does that matter at all?
  2. Build your system such that the interface to the server is the "game rules," and the data from the client is simply an expression of the players' desires. If the player desires to go left, send a "player goes left" command, and let the server figure it out. If the player wants to fire a weapon at 33 degrees, send that as a command. Do not use any messages that express specific state or events -- don't say "I now have 1000 gold" or "I hit player 3 for 89 damage." For fast-paced games, this will introduce latency, which you will have to manage by some time-traveling smarts in the game client and perhaps on the server. (All of the "multiplayer game models" write-ups you see online basically revolve around the different ways of doing this.)
  3. Decide that your game is not going to be particularly popular, and thus cheaters will not likely discover your game, and if they do, they will not be likely to actually want to spend a lot of effort on it.
  4. Research all the cheating tools, and keep a constant watch out on various user forums for your game, looking for exploits. Patch each of them as you find them. Study the cheating software in detail, and come up with a mitigation that works for each of them. Keep working on this, every day, for as long as your game is alive.

Which one you choose is up to you.

 

enum Bool { True, False, FileNotFound };

HPlus covered some options and there are more.

3 hours ago, MvGxAce said:

Is there a program to ensure that the game I've created does not get hacked from third party apps

There are programs that make it more difficult, but it can never become impossible.  Even the games using the most sophisticated techniques that invest millions of dollars into protections (such as World of Warcraft and League of Legends) still cannot block all of it.

There are many ways to attack a game, and even more are discovered all the time.  

3 hours ago, MvGxAce said:

The game is online based but I just recently found out there are hackers. Is there a program I could use to stop this or is it in the coding.

For network games, attackers can attack the protocol. It is trivially easy to break through secure sockets, they only protect during transit; just like armored cars, it doesn't matter how armored the vehicle is when the bag of paper money had been replaced with a bag of fake monopoly money before the armored car was used. Attackers have complete control of the game, they can send whatever data they want through the pipes. Attackers can send data saying the player had aimed perfectly, send data saying the player had moved perfectly, or jumped at the right time to avoid danger, or otherwise send tampered data.

 

Attackers can also send malformed data through the pipes, so it needs to be verified as well. What happens if you get text string that is enormous, like a player name that is 3MB in length? What happens if you get a packet ID of type -1? What happens if you get a string that says it is length -1? What happens if you have levels 1-8 and someone sends a command to load level 45?

Players have other attacks through the program rather than through the network. Programs called 'aimbots' that read game data or that read screen buffers and send mouse events. Programs that grant unlimited money or free items. Programs or tools that make walls invisible, or that make enemies a highly visible color like neon yellow, or that load a map showing where every player is located.

 

An effective countermeasure to many attacks is to only tell the client the minimum that it needs to know. Don't say where players are at unless they're being drawn on the screen. If something is outside line-of-sight then it doesn't exist. Give out data on a 'need to know' basis.

Another highly effective countermeasure (which is also costly to implement) is to validate everything that comes from the client and run it all on the server. Trust nothing, and design the protocol so that the client sends requests and the server runs the simulation. If the player says they fired at a location at a time, verify that the player could have been at that location at that time. If the player says the jumped to safety from a place at a time, verify that they could have been at that location at that time. It could say they used a weapon they don't own, or say they bought an item with money they don't have. It could say they sold a rare item even though they didn't own it, or that they killed a monster that wasn't actually there.

Check for statistics. If someone has a very high accuracy, perhaps 100% of their shots are kills, that's probably a cheater. Many online games show a few stats at the end of game to help the community; a player may have 15% hit rate, 20% hit rate. A skilled player may have 60% hit rate. People who have very high hit rates, high frag counts, low death counts, and other unexpected values some games will allow players to flag them as potential cheaters.

Even with all that, there are bugs and defects that cheaters can still exploit. There was an infamous WoW "Corrupted Blood" bug, where a player could acquire a spreadable virus-like debuff, then through various methods bring the virus to a town of low-level players and infect them, leading to mass deaths. Several games have had walls with a slightly errant polygon, a skilled player could stand on that polygon or pixel error to gain an advantage.  Some games have had collision errors, where an unusual series of events could place a player inside a wall; they have a perfect shield and can fire at anyone. 

No matter what efforts you try exploits will still exist.

Advertisement

It is absolutely true that exploits will always exist in some form.

What is also true, and moderately less depressing, is that you can invest a bounded amount of effort to make the vast majority of exploits not worth it. In other words, you can ignore some exploits that just aren't a big deal, in exchange for defending against the ones that are a big deal.

This is important from a cost/benefit perspective. If you get hung up on blocking every possible exploit, you'll exhaust your resources (and yourself) sooner or later. But if you let some things slide so you can focus on the important hacks, you can spare yourself a lot of work and preserve some sanity.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

I was wondering how to avoid apps just like game guardian game killer etc I want to mainly avoid these apps

If you're using Unity, this is a bit harder, because C# doesn't give you "perfect" control over data storage.

In general, the idea is to scramble and checksum the actual values used. In C++, this is easily done with a wrapper:

Here's a simple version to get you started (typed, not compiled):


template<typename T> class Hidden {
    public:
        Hidden(T const &t) : val_(0), cs_(0) { write(t); }
        operator T() const { check(); return read(); }
        Hidden &operator=(T const &t) { check(); write(t); return *this; }
    private:
        uint8_t val_[8];
        uint8_t cs_;
        T read() const {
            uint8_t tmp[8];
            memcpy(tmp, val_, 8);
            descramble(tmp, sizeof(T));
            return *(T *)tmp;
        }
        void write(T const &t) {
            uint8_t tmp[8];
            *(T *)tmp = t;
            scramble(tmp, sizeof(T));
            memcpy(val_, tmp, 8);
            cs_ = calc_checksum();
        }
        void check() {
            if (calc_checksum() != cs_) {
                throw new std::runtime_error("hack or bug detected");
            }
        }
        uint8_t calc_checksum() const {
            uint8_t cs = 0xc0;
            for (uint8_t const *p = tmp_; p != &tmp_[8]; ++p) {
                cs = cs * 0xfd + *p;
            }
            return cs;
        }
};
	Hidden<int> haha;
	haha = 3;
	int unpacked = haha + 5;
	

I also wrote a description of the code, after the inline code, but the new forums seems to have swallowed that part :-(

enum Bool { True, False, FileNotFound };

You could check to see if a specific process is running on the target machine, if it is then close the game or uninstall the program running the specific process. But then they can just rename it, you'd then look at more specific things about the program but yeah I wouldn't bother with that.

My approach is the suggestion approach, I'll write the client so that it prevents the player from trying weird stuff, while writing the server so that it doesn't accept any weird stuff, my first goal is to get the client/server working so say x/y coordinates, player logs into the server, player gets player data, player spawns at default coordinates, player starts walking around.. so player presses W the server will receive the input and update the players position based on the speed the player is going and the direction, when the player releases W the server will receive the key release information and stop the player from moving. So even if the player somehow prevents the W release from being sent, the player would stop moving client side but server side the players still gonna move.. which isn't beneficial to the player. the player could try to teleport using say Cheat engine but the server monitors the client side current position, this is where you move past just getting the client server connection to work you're now starting to monitor player activity, so first things first this could be lag or something, so don't just ban the player, maybe try to reconnect the player after doing a ping test, if the ping works fine and the player is still connected then he's trying to hack so either way teleport him back to the last known state of what ever changed.

 

I dont know what those apps are you're talking about but as long as the client cannot COMMAND the server, then there's no way that they can hack anything meaningful. Then it falls down to BUGS and glitches where they somehow managed to open up a chest and loot it twice. That's a different story. 

This topic is closed to new replies.

Advertisement