Decompiling and cheating in UE4 games

All,

Just curious on a couple of concerns.

  • I’ve read in docs that blueprints are compiled to bytecode. Can this be reversed and allow people to cheat in a UE4 game?
  • In the ShooterGame example, are physics handled client or serverside? Could a client hack allow a player to walk through a wall?

Based on the above I’d like to come up with a design that minimizes the ability to cheat in a multiplayer game. And was thinking through this, I’m new to UE4 so still trying to get some of the concepts.

Thank you in advance for any insight!!

-Sal

No matter what you do, you will never be able to fully stop a player cheating or hacking . The only thing you can do is like you say minimise the risk by smart programming . When working always say to yourself never trust the client . do anything important run on the server , client should only be in charge of cosmetic and visual stuff. You can try to add checks in to catch clients cheating for example when a client moves you know that in X amount of seconds they should have travelled X amount of distance so then you check there old position to the new position if it is irregular then chances are they have cheated eg changed there speed , teleported across map etc

Once game is done you can do something called code abstraction to help stop reverse engineering. Basically what you do is copy all of you’re code so you have the clean master version and then In the version you ship to players you would go through and make you’re code unreadable so you would give variables rubbish names , change names of functions to not make sense etc so if someone was trying to reverse engineer they would have a difficult time.

Another method often used is using layers or servers to hide game data . So you would have a secure server with all the game data hidden on it and players can only download through a secure client what they need to run the game everything else is hidden behind the scenes and should be secure but again one this is not fool proof hackers can script injection , jack databases etc

Unfortunately the hacking business is just as lucrative as actually making the games people always like to win no matter what and often they just get banned buy a new copy of the game and carry on . Hackers make money selling the hacks , game companies get multiple copies of the game brought , and anti cheat companies make money by trying to stop them it’s a viscous cycle and only is the game players that loose out

One good method to deter multiplayer cheating is server-side checks. I.e. is this player moving faster than the game is designed? Or is the players aim inhumanly accurate? You capture enough data to prevent a false positive, and deal with them accordingly. This is what FairFight does, and its generally pretty good at picking out the actual cheaters.

That being said, unless a game is fairly popular, most of the ‘premium’ cheat suppliers won’t bother providing cheats as there is no financial reward for their effort.

I’m not a cheater. But the first time and last time I used a so called “Trainer” (I don’t know why they called it by this name), I was only wondering (I was like 13 years old) how a running .exe instance could even find the right variable address in the RAM of another running instance. Today, I’m only wondering why the hell does the operating system even allow to access RAM information just like that, in the first place!? Needless to say that this is a huge security hole, and not just for gaming.

Yeah, it ain’t that simple. At least with new OSs but only with malware. Game hacks are still quite unchecked by the OS. This problem is one of the reasons why I speak up for a Windows 10 close down via the universal platform. If the OS is more closed down, the OS could have more control over what’s going on in the RAM. Ideally, a Windows 10 without Win32 support could stop hacks entirely. Without having the devs to do anything!

It is not that simple. I used to write trainers until very recently. With recent games it is very difficult to find the memory locations and alter it as they usually randomize the location. However we can inject a DLL into the original game process (there are many methods to do this). Once that is done, the DLL is running within the same address space as the host process and you can access any memory location and even call functions within the host process (if you know the memory address and parameters).

Another way is to alter one of the DLLs the game usually loads. Most use the d3dxxx.dll. This altered DLL can then load additional files that the cheater wants. GTA’s ASI loader works this way as far as I know.

What I am trying to say is in these situations it is impossible for the OS to block memory access. How does the OS know if the access is coming from the original DLL or altered DLL and for what purpose.