Again can this be automated

[color=#282828][font=helvetica,arial,verdana,tahoma,sans-serif]

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.[/font]

[color=#282828][font=helvetica,arial,verdana,tahoma,sans-serif]

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

[color=#282828][font=helvetica,arial,verdana,tahoma,sans-serif]

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

[/quote]



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)

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

[/font]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

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!)

[/font]