52 replies to this topic

[hplus0603]

Quote

The original Runescape could. It records patterns within a players movement and bans players that look like bots.

It tried. It either got it wrong, and banned real players, or it got it wrong, and missed well-crafted macros, only banning the obvious ones. You can easily insert random delays, wiggles, and occasional "chatting" into a 'bot script.

Make your game interesting and rewarding to play. Make it so that there is very little impetus to cheat, or at least to grief. Make accounts valuable so you can deal with the worst offenders. Then focus on making the best game you can!

[Washu]

hplus0603, on 08 February 2012 - 11:22 PM, said:

Make your game interesting and rewarding to play. Make it so that there is very little impetus to cheat, or at least to grief. Make accounts valuable so you can deal with the worst offenders. Then focus on making the best game you can!

If an account is valuable then it is a viable commodity for "gold farming." People want to cheat because they are competative. If you take the steps to make it difficult then the majority of players won't... but I'll bet that after getting killed that 3rd or 4th time in a PvP arena a non-trivial number of them will google "<game> hacks." Rewarding gameplay is rarely something a "gold farmer" cares about, they're paid by the hour to make isk/gold/plat/ecto/<your game currency here> and then they sell it (or its sold for them). Many of the best bots are just farming bots. Very carefully crafted and designed farming bots, but bots nonetheless. Even Diablo 2 on battle.net ladder had farming bots for runes and rare drops.

[hplus0603]

Quote

after getting killed that 3rd or 4th time in a PvP arena

So why do you have PvP?

If you have valuable accounts, and gold farmers pay for the accounts to make gold, well, you're making more money, right? And the people who buy the gold play longer, right? So I don't see how that's necessarily bad. You could even manage that economy by reducing the amount of gold/loot awarded as sessions or daily activity goes long. You could also have your own gold-for-money marketplace to provide an upper limit to the price of farmed gold. Which also means that, when you design the game to survive a gold marketplace, the gold farmers will be less disruptive to your game.

I guess what I'm saying is that you should design for what you can actually do, rather than design some pie in the sky, and then cry as it crashes down to earth under the weight of reality :-)

[wodinoneeye]

Antheus, on 05 February 2012 - 12:05 PM, said:

wodinoneeye, on 05 February 2012 - 11:46 AM, said:

Again can this be ALL automated with a download/install and run auto-magically for a mind numbed script kiddee (or others even lower on the food chain) ???

Of course, same as any other patch. Write once, run anywhere. Cheater downloads a patch/trainer and that's it.

General idea behind the technique is how to avoid integrity checks, just like how to bypass int 3 blocks or similar.

The rest, actual hack, depends on what you want to do, which is no different from the way hacks work these days. But seeing crackers break through all DRM, even polymorphic versions sometimes even before the official version is available, I don't see any of the above as particularly "complicated". I don't even remotely follow the field on such kinds of exploits, so it's likely there are much simpler or more effective methods.

Dont know if you bothered to read the description of the (proposed) system I am talking about. Did you see where Ive said numerous times that the client executable is being modified frequently (and possibly different users randomly get different variants) ????

This means different hacks each time (handbuilt and redistributed, but might not work for those variant) *OR* a complex automated hack system that can read assembly like a human, unscramble what it does and then rebuild the hack to do the cheat.... (and have it include all the fancy tools and require special sandbox/vm/whatever and have them play nicely on a script kiddees system as an automagical install/run ).

You talk about crackers can do this and cheaters can do that, but creating a program to do what a hacker does by hand on a (daily) changeable program is something else entirely.

Thats what I have actually been asking -- NOT if a hacking expert could possibly break the system manually, but can they replicate their own knowhow within a program clever enough to handle some of the tactics Ive proposed ????

I would expect NO they cant so there goes 99% of the cheaters.
I would expect even the 'expert' hackers who daily will manually rebreak the client-server countermeasure would get sick of doing it.
Thus the goal of eliminating the greater majority of hackers would be possible.
Even my simplified countermeasures might be sufficient to do that.


What other cheats besides Aim-Bots are possible/done when the usual server side validations (someone enumerated above) are already done???

Auto projectile dodging ?? (may be preemptive for instant shots games to put you behind available cover and pop u out to take shots automatically)

View blockage Xray vision ?? for faulty validation systems that dont always filter out opponent position data sent to the client and rely on 3D obscuring at least near transitions( all those blind corners)...

Cheat Visual cues created from valid sound cues (when object not supposed to yet be visible, but can be heard)

[hplus0603]

If you think that will be successful, after all arguments you've seen here, then prove us wrong! Build a wildly successful game based on preventing cheating through constant client changes! I'd love to read that success story, and I'd be envious of your millions of dollars!

[wodinoneeye]

swiftcoder, on 05 February 2012 - 12:21 PM, said:

wodinoneeye, on 05 February 2012 - 11:46 AM, said:

What kind of knowhow is needed for something like this (I assume the tools are avaiable but they require alot of knowledge to use them sometimes)

There is nothing complicated about cracking software - all it requires is a decent grasp of assembly language and debugging techniques. The majority of people in the field seem to be self-taught, but anyone with a CS degree ought to be able to handle it - I'd warrant there are at least a few hundred members of this board who could pick up the necessary skills in a few days, if they turned their mind to it.

A number of my friends used to do this for fun in high-school/college - It was a easy way to establish your street cred as a 'leet hacker'.

Again can this be automated?? (read even my simplified counter measures of how the client exe would frequently mutate and self check -- thats what the automagical hack downloaded by a standard issue script kiddee would have to solve for)


I spelled out repeatedly that this solution wont work completely against hand crackers (unless it turns over so fast that even they with fancy tools and some partial automation cannot keep up with it), BUT if that cracking cannot be distributed (cant make a program smart enough to do whats needed OR the tools are too esoteric for you hordes of script kiddes who largely cannot do much for themselves or wont put in any effort) then there goes 99+% of the cheaters.

[wodinoneeye]

hplus0603, on 09 February 2012 - 08:55 PM, said:

If you think that will be successful, after all arguments you've seen here, then prove us wrong! Build a wildly successful game based on preventing cheating through constant client changes! I'd love to read that success story, and I'd be envious of your millions of dollars!

Unfortunately after seeing what passes for programming skills in several MMORPG (break more than they fix patches) and poor management decisions (pennywise, pound foolish decisions) whatever it would be would have to be utterly simple or the risk managers wont buy into it.

I listed a number of 'simple' countermeasures (and how to do them in the build mechanism) that I thought should not require rocket science that should programaticly/scriptually scramble the EXE sufficiently for daily rebuilds of the client exe (the corresponding server mechanism would likely work with data generated for the variant and not require rebuilds) to kill alot of the cheating (invalidating hack distribution to script kiddees).

Of course daily DL of the .exe might be seen as prohibitive (right now at least) and a smaller DLL download solution would deprive the mechanism of alot of its ability to be scrambled.

After gauging what might be needed for a working solution, a key question might also be - do the companies really care enough about the existing cheating (the 'give-a-damn' factor) to be willing to spend any additional money and face the possible risks ???

Edit- after poking at the Beginners section 'which engine should I use' probably the right place such a security system should be based (developed) would be built into the engine mechanism so that the game companies might have an ounce of reassurance (risk wise) .
BUT its likely that these engines are nowhere near close to total solutions and the game companies are still customizing large parts of the MMORPG system where this mechanism would live.

[swiftcoder]

*sigh*

I'm going to bow out now. We've made our point repeatedly:

There is no way to secure a client, short of hardware TPM. If it's in memory, I can hack it without trace. If it passes over the network (even encrypted) I can hack it as it crosses the wire. If the entire executable is rewritten in random layouts every second, I can hack the syscalls it relies on.

And I can package this all up in an executable so simple that my grandmother could figure out how to run it.

This is the reality. If you think you are smarter than the hackers of this world, then by all means go for it. Let us know when you make your first 100 million.

Personally, I'll be implementing server-side security

[hplus0603]

Quote

Again can this be automated

Yes. There already exist "memory scanner" tools that will look for particular values in memory, and then put in data breakpoints to locate the pieces of code that read/write those values. Great for finding counters for "gold" or "hitpoints" or whatever.

If you use automated mechanisms in the build system, then a hack could equally well reverse-automate whatever those mechanisms are.

In the end, the server just sees bits on the wire. It cannot make any assumption about how those bits are generated.

[Antheus]

wodinoneeye, on 09 February 2012 - 09:22 PM, said:

I listed a number of 'simple' countermeasures (and how to do them in the build mechanism) that I thought should not require rocket science

Unfortunately, these simple solutions are unsolved rocket science problems. Active research these days in homomorphic encryption is just about that. How to provide a secure/encrypted blob which can be modified using secret algorithms without revealing actual contents.

Exe protection on insecure client fails since executed code needs to be plaintext. There is currently no known method to avoid this.

Instead, all effort is put into making clients trusted or locked down and actively monitored.

Method which could provide provably viable reliable protection of such type would be worth a lot and would change the landscape of cloud computing. Hosts, for example, might be ran by untrusted third party, executing arbitrary code and handling arbitrary data, yet the host would not be able to decrypt the blobs. Solution like this, especially if mandated via some regulation would completely eliminate privacy concerns, but also potentially destroy today's gold mines. Imagine Facebook where you can do everything the same, but Facebook itself isn't capable of understanding the data it hosts.

[wodinoneeye]

hplus0603, on 10 February 2012 - 11:39 AM, said:

Quote

Again can this be automated

Yes. There already exist "memory scanner" tools that will look for particular values in memory, and then put in data breakpoints to locate the pieces of code that read/write those values. Great for finding counters for "gold" or "hitpoints" or whatever.

If you use automated mechanisms in the build system, then a hack could equally well reverse-automate whatever those mechanisms are.

In the end, the server just sees bits on the wire. It cannot make any assumption about how those bits are generated.

By automating I do mean not constantly manually tweaking the 'automated' hack program constantly (my repeated point about denying easy to use 'automagical' hack installs to script kiddees). I already said that common serverside validations are to be done and these counter measures are to stop hacks that those measures dont stop (aimbots and ???).

These memory scanner tools need very detailed inside information about the exe (and EXACT interrelation of multitudes of variables) about what they are supposed to lock onto (just to read them). Unless every value that you need for your hack cheat can be obtained it wont work. Just because you might be able to locate 'easy' values in memory doesnt mean you will be able to find ALL the data you actually need.

example - have to find the data locations for the xyz position of object I want (*random index here*) which is really enemyX so my aimbot can lockon and autotarget (aim my gun - object z, data_a data_b data_c data_d) and push that avatar input command (changeable command index that would have to be pre-determined since it changes in the jump table index scrambler) into the encrypted packet stream (or ONE message inserted into a otherwise undisturbed packet msg). Oh and trace the routines (changeable) that use this data and reverse engineer them to figure out which output data needs to be written again in some additional objects (which need to be found first) etc.. etc... etc...

ALL having to be completed to make the cheat work - all or nothing.

Assume this all has to happen fast enough so that the aimbot actually gets off its cheat before the game situation is invalid for the desired result...
(I assume your REQUIRED 'lockon' will require linear searches thru data spaces (those data spaces change because of the code reordering countermeasures so THEY have to be 'locked on' first ...)

Assume ALL the required data read reference points are locateable via your 'lockon' to predictable/known values (again ALL of them not just single easy ones like 'gold' or username). Many dont have 'easy' values to lock on to..... Structure offset positioning is useless if you cant find the base address in-memory of the objects involved. Alot of this datas is in transitory buffers that may move around in stacks (not consistant positioned across execution progress)

Do this for any/all the desired cheats without screwing up the data streams accidentally and having the server detect any of the mangled data being sent (validated serverside)...


Alot of not so simple data to locate and interpret in a timely fashion --AND all done fully automated with NO user interaction involved ....

A rather tall order.

Might all be worth it to give the hackers headaches and nightmares and drive some to suicide trying to achieve all this (or more likely they move on to some other game to get their ego trip)

[Washu]

Your encryption scheme is in the client, which means its on the clients machine, which means the "hacker" already has the code necessary to decrypt your packet stream. Which means the hacker doesn't need to read your magical memory to figure out where the enemy is, he just intercepts the network stream, snoops the packets, and decrypts them.

[hplus0603]

I think we're just saying "is not!" "is so!" all over again here, so I will lock this thread.

If you have specific networking/multiplayer implementation questions -- including references to things like encryption algorithms or whatnot -- then feel free to start new, specific threads. However, on the topic of "can I generally secure a client running on an untrusted computer/network," please do not re-open the discussion until you have an actual, working, system in place, because that's what it'll take to prove us wrong. (And, believe me, many have tried!)