• Advertisement
Sign in to follow this  

Unity anti aimboting hacking concept

This topic is 2996 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

ive been playing a few fps and im by no means a codeing guru but ive dabbled with it so i had a idea on the way hack prevention is delt with i wanted to run this idea by some of you guys the ideas i have are two fold 1) prevention 2) identification so the first idea this came to me in the idea of a virus altering itself to survive but in the sence of the program itself ive noticed alot of these fps and games nowdays do updates weekly or monthly and add or replace existing files i had the thought that maybe we could treat the prevention part as though screwing up the hackers app via a download was more effortless then the actual act of making the hack that way one person could rewrite a file easily and screw over a team of hackers placing critical parts to be hacked in a seperate small file or dll whatever that could be easily altered daily or weekly that is done thru the update the effect you would wish to have is to force the hackers to rewrite a hack daily makeing it very difficult to keep up and distribute a working version on a daily basis 2) this one is on identification everytime a ban is done the server tracks the frequency but doenst make that info availible to the players if a person is getting called or booted out of rooms constantly they will end up with a very high signature of being called out mods can then browse this list and track the types of hacks being used or possibly test their code to see if their hack prevention schemes are working this could even be used against hack users so mods can go into games with them to see if they are really cheating or not without them knowing alternatly these stats could be public and let the community decide weather or not to trust the said person the said stats would be games played # of accusations # of games kicked from by vote a new account would leave you a noob untrusted so you would start off the same as you would with alot of kicks and accusations however honorable players would not have this problem over time and that would be the jem of that idea anyways what do you guys think ???

Share this post


Link to post
Share on other sites
Advertisement
Your point one is indeed a nice thought. But, how do you ensure it is downloaded? How do you ensure every player on the game has the latest files? What if they have no internet and want to do Singleplayer? Do all gamers then have to download new files daily? Make sure it's really just a few kilobytes then.

But say a hacker hack the game so it says to the server it has the latest version? Or would this be some encrypted key that is derived from the changed data part?

Prevention part sounds good though. But be aware some hacks are barely noticeable, like wall-hacks. A good hacker can disguise it well.

Share this post


Link to post
Share on other sites
I don't know how easy it'd be to implement or how error-prone/slow it'd be, but one idea I had for protecting against wall hacking and somewhat against aimbots was to write the server in such a way that it doesn't send information about players if they're a certain distance away or obstructed.

e.g. The server knows (through some internal detection engine of some sort) that player X is behind a wall on which player Y is on the other side so it doesn't send X's coords to Y or Y's coords to X. With no coords to work with, an aimbot can't know where to aim... until they come from behind the wall and then it's game over. But this also works for wall hacks as if they can see through the walls... there's nothing there to see.

The idea is in its infancy, but might work with some tinkering.

Share this post


Link to post
Share on other sites
Quote:
Original post by Guinnie
I don't know how easy it'd be to implement or how error-prone/slow it'd be, but one idea I had for protecting against wall hacking and somewhat against aimbots was to write the server in such a way that it doesn't send information about players if they're a certain distance away or obstructed.

e.g. The server knows (through some internal detection engine of some sort) that player X is behind a wall on which player Y is on the other side so it doesn't send X's coords to Y or Y's coords to X. With no coords to work with, an aimbot can't know where to aim... until they come from behind the wall and then it's game over. But this also works for wall hacks as if they can see through the walls... there's nothing there to see.

The idea is in its infancy, but might work with some tinkering.


This is an idea which is certainly used in a lot of online games currently, although less frequently for action/shooter games.

Share this post


Link to post
Share on other sites
Reading the source code for cheats is a great way to understand how cheaters are thinking (you'll find sources for many counter-strike cheats are open source). And unfortunately, many of them are pretty creative. Now, I'm far from an expert in the field, but at some point i got quite interested in how cheats work. And its rather difficult to use prevention.

About changing the exe/dll: Assuming you actually find a way to force the version of the exe/dll to be up-to-date (I don't think you can). While you can change where functions are located in a game exe/dll, cheats usually keep hardcoded offsets to these functions. Now, every time you change the code, those offsets in game might change, depending on how you change the code. This is a problem that i've seen happen between some versions of CS releases. To counter this, they added automatic offset updating. I believe they also managed to dynamically find the offsets of the functions. Conclusion: Using this method, it will be really hard to prevent much.

About the player data: In many fps-games (where wall hacks may have the biggest impact) you can shoot through walls. If just the tip of your weapon is visible, i guess most part of the player model is rendered, and therefore can be made visible even when its behind (and the position etc is sent over the network). Big enough advantage already. Even if you manage to render only the visible parts and not send player coordinates when not necessary, sounds are played in 3D and can be rendered in an overlay. You don't know who's behind the wall, but who cares? Conclusion: While making the life of a cheater harder, it certainly doesn't stop them from shooting you through a wall.

Finally, the stats/tracking idea: In my experience many player accuse others of cheating when they, in fact, only are good players. Even server admins get this wrong sometimes. And i don't really blame them. It's sometimes really hard to separate cheaters from skilled players. Unless, of course, if you play against a rage cheater (360 degrees aimbot, wall hack, speed hack, etc). Conclusion: "Regular" players don't necessarily provide good/proper stats.

Pretty much is already done to prevent cheating, but since the code is run on the client computer, there is only so much you can do.

-- Unleeb

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By Alexander Nazarov
      Hello. I'm newby in Unity and just start learning basics of this engine. I want to create a game like StackJump (links are below). And now I wondering what features do I have to use to create such my game. Should I use Physics engine or I can move objects changing transform manually in Update().
      If I should use Physics can you in several words direct me how can I implement and what I have to use. Just general info, no need for detailed description of developing process.
       
      Game in PlayMarket
      Video of the game
    • By GytisDev
      Hello,
      without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
      Thank you in advance.
    • By Ovicior
      Hey,
      So I'm currently working on a rogue-like top-down game that features melee combat. Getting basic weapon stats like power, weight, and range is not a problem. I am, however, having a problem with coming up with a flexible and dynamic system to allow me to quickly create unique effects for the weapons. I want to essentially create a sort of API that is called when appropriate and gives whatever information is necessary (For example, I could opt to use methods called OnPlayerHit() or IfPlayerBleeding() to implement behavior for each weapon). The issue is, I've never actually made a system as flexible as this.
      My current idea is to make a base abstract weapon class, and then have calls to all the methods when appropriate in there (OnPlayerHit() would be called whenever the player's health is subtracted from, for example). This would involve creating a sub-class for every weapon type and overriding each method to make sure the behavior works appropriately. This does not feel very efficient or clean at all. I was thinking of using interfaces to allow for the implementation of whatever "event" is needed (such as having an interface for OnPlayerAttack(), which would force the creation of a method that is called whenever the player attacks something).
       
      Here's a couple unique weapon ideas I have:
      Explosion sword: Create explosion in attack direction.
      Cold sword: Chance to freeze enemies when they are hit.
      Electric sword: On attack, electricity chains damage to nearby enemies.
       
      I'm basically trying to create a sort of API that'll allow me to easily inherit from a base weapon class and add additional behaviors somehow. One thing to know is that I'm on Unity, and swapping the weapon object's weapon component whenever the weapon changes is not at all a good idea. I need some way to contain all this varying data in one Unity component that can contain a Weapon field to hold all this data. Any ideas?
       
      I'm currently considering having a WeaponController class that can contain a Weapon class, which calls all the methods I use to create unique effects in the weapon (Such as OnPlayerAttack()) when appropriate.
    • By Vu Chi Thien
      Hi fellow game devs,
      First, I would like to apologize for the wall of text.
      As you may notice I have been digging in vehicle simulation for some times now through my clutch question posts. And thanks to the generous help of you guys, especially @CombatWombat I have finished my clutch model (Really CombatWombat you deserve much more than a post upvote, I would buy you a drink if I could ha ha). 
      Now the final piece in my vehicle physic model is the differential. For now I have an open-differential model working quite well by just outputting torque 50-50 to left and right wheel. Now I would like to implement a Limited Slip Differential. I have very limited knowledge about LSD, and what I know about LSD is through readings on racer.nl documentation, watching Youtube videos, and playing around with games like Assetto Corsa and Project Cars. So this is what I understand so far:
      - The LSD acts like an open-diff when there is no torque from engine applied to the input shaft of the diff. However, in clutch-type LSD there is still an amount of binding between the left and right wheel due to preload spring.
      - When there is torque to the input shaft (on power and off power in 2 ways LSD), in ramp LSD, the ramp will push the clutch patch together, creating binding force. The amount of binding force depends on the amount of clutch patch and ramp angle, so the diff will not completely locked up and there is still difference in wheel speed between left and right wheel, but when the locking force is enough the diff will lock.
      - There also something I'm not sure is the amount of torque ratio based on road resistance torque (rolling resistance I guess)., but since I cannot extract rolling resistance from the tire model I'm using (Unity wheelCollider), I think I would not use this approach. Instead I'm going to use the speed difference in left and right wheel, similar to torsen diff. Below is my rough model with the clutch type LSD:
      speedDiff = leftWheelSpeed - rightWheelSpeed; //torque to differential input shaft. //first treat the diff as an open diff with equal torque to both wheels inputTorque = gearBoxTorque * 0.5f; //then modify torque to each wheel based on wheel speed difference //the difference in torque depends on speed difference, throttleInput (on/off power) //amount of locking force wanted at different amount of speed difference, //and preload force //torque to left wheel leftWheelTorque = inputTorque - (speedDiff * preLoadForce + lockingForce * throttleInput); //torque to right wheel rightWheelTorque = inputTorque + (speedDiff * preLoadForce + lockingForce * throttleInput); I'm putting throttle input in because from what I've read the amount of locking also depends on the amount of throttle input (harder throttle -> higher  torque input -> stronger locking). The model is nowhere near good, so please jump in and correct me.
      Also I have a few questions:
      - In torsen/geared LSD, is it correct that the diff actually never lock but only split torque based on bias ratio, which also based on speed difference between wheels? And does the bias only happen when the speed difference reaches the ratio (say 2:1 or 3:1) and below that it will act like an open diff, which basically like an open diff with an if statement to switch state?
      - Is it correct that the amount of locking force in clutch LSD depends on amount of input torque? If so, what is the threshold of the input torque to "activate" the diff (start splitting torque)? How can I get the amount of torque bias ratio (in wheelTorque = inputTorque * biasRatio) based on the speed difference or rolling resistance at wheel?
      - Is the speed at the input shaft of the diff always equals to the average speed of 2 wheels ie (left + right) / 2?
      Please help me out with this. I haven't found any topic about this yet on gamedev, and this is my final piece of the puzzle. Thank you guys very very much.
  • Advertisement