Jump to content

Idea to reduce hacking and misbehavior


Recommended Posts

Would be to have the users login to their forum account inside the MTA:SA software, Lets say (Just as example) that [uVA]James have a forum account and whenever he starts MTA:SA he needs to login with his forum details for the game to start.

And ingame his username will be same as the forum account he has here and whenever he use a hack or something the he gets like a Queer Penis on his profile here in the forum for a week.

Might be a bad idea, Just a suggestion though lol.

Link to comment

I still belive the best ban system will be to check for the install date and time of windows(i doubt there will be people with the same day, month, year, hour, minute, second install date). and based on that install date MTA could generate some sort of serial. Yes it is possibile to change the install date/time but its a hell of alot harder than just changing your IP or using Sockscap.

Link to comment
I still belive the best ban system will be to check for the install date and time of windows(i doubt there will be people with the same day, month, year, hour, minute, second install date). and based on that install date MTA could generate some sort of serial. Yes it is possibile to change the install date/time but its a hell of alot harder than just changing your IP or using Sockscap.

What if someone needs to reinstall? I don't see how this helps.

Link to comment

Ravenheart: as with most data the client sends to the server, the server has no means to verify that the information is correct... You wouldn't need to reinstall Windows at all - you'd have three easier possibilities:

- Change the Windows installation date in the registry (easier than spoofing an IP actually).

- Use a modified client that sends a different installation date to the server. As said, the server has to means to prove that what you tell it is true.

- If the client is so strongly protected that modifying it is difficult (which I hope will be the case), there's still the option of making a proxy server that does nothing but forward all traffic to the real server, but modifies the installation date if it is encountered. This is a sort of man-in-the-middle attack and is rather difficult to detect...

You can argue that the latter two points take work, but all it takes is 1 dedicated cracker really. Just look at sa-mp.

(And the above three points don't just apply to the Windows installation date but to any identifying information that can't be verified by the server. The forum account idea sounds better to me. Creating a new account is more hassle than setting a new installation date)

Link to comment
Show me where exactly does windows store its install date in the registry.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate

It's stored in Unix epoch time = number of seconds elapsed since January 1, 1970. I could add 5 to this number and be seen as a new user by the server.

You could always ban by their windows key, which can be found. Can also be changed but would be really annoying.

I don't think it would be legal for them to harvest Windows CD keys. They could of course send a hash of the CD key instead, but that could again be countered by a modified client or proxy server.

Finding a good protection is difficult :(

Link to comment

Well yes, it may not be the best idea to show their windows serial in a ban list. However, cheaters don't always deserve to be handled fairly.

True though a md5 hash or something similar of their serial would be a good compromise.

The best anti-cheat tool is a good admin in the end.

Link to comment

Ravenheart, unless there is something preventing/monitoring hooking into whatever it is that sends this generated id, it could be hacked and randomly created everytime a person connects. The truth of the matter is, hacking will exist. The only way I can imagine something becoming reasonably hard to hack is where game structures are dynamic and/or a secondary server/client dll/so running that monitors whether other applications are accessing restricted areas of memory. Think of anti-virus programs: they can in theory protect specified processes from being hooked/modified by anything.

Even in games designed for internet play, at some point, the client is trusted. In a game like GTA (closed sourced, intended for single player), it's all client side being modified by what a 3rd party app is telling it to do. It's too easy for these people who have nothing better to do than to monitor memory addresses -- a truly pathetic existence in which they have pride.

The banning system, as you've suggested, based upon unique client ids is good, but a method to derive them is not easy. Each person could be issued an id (non-public download), but then one enters the domain of preventing multiple ids per IP/hostmask. It is something, though, and if a system is setup in which each person can only obtain one id (not fool-proof, but at least something to make it difficult), the banning would become effective on "official" servers (provided these servers have the option of adhering to a public ban list of ids). Then the "cheater" in this case would have to find a way of obtaining a new id. Again, you face the same situation: if you generate a key from an install time, then the client's system must be trusted. If you generate a key on a server based upon an ip/hostmask, that info is trusted from the client.

Here's a possibily better situation for key-generation: client must download an app which will take the unique serial numbers of pieces of hardware, send them to a server, have them run through the algorithm to create a key. To the client, it might only take a min (the local app generates a long string of data to send and asks for an email address to return their unique id to). This does require a server to handle these events and generate keys. Unless a client is so obsessed with both cheating and playing that they will go to the lengths of changing his/her hardware, then it should provide a decent banning system. Unfortunately, as with lots of things in life, money could buy a way out. This also assumes that key authentication is NOT done client side, rather a master server must verify them. This should not be done through the server host (for the game), since that could open the doors to key stealing. It should be sent encrypted at least.

Well, that's a long post of ideas.

Link to comment
Ravenheart, unless there is something preventing/monitoring hooking into whatever it is that sends this generated id, it could be hacked and randomly created everytime a person connects.

...

Here's a possibily better situation for key-generation: client must download an app which will take the unique serial numbers of pieces of hardware, send them to a server, ...

You're contradicting yourself :P

Link to comment

I'm not contradicting myself. You should read over it again.

Note: Anything is hackable, as I pointed out, the methods I suggested were "stronger" in my opinion.

In the first statement, I was responding to a key being created client side in game or during installation of MTA using the installation date. Something which can be changed. A simple uninstall of MTA and new installation could create a new key if one edited one's registry or wherever else the data is stored.

In the second statement, I am referring to serial numbers from hardware (something which cannot be changed). Is it possible to fake these? Anything is possible, but far more difficult than other method. Also, an encrypted connection can be established between the master server for authentication when it accesses these serial numbers. This would require the person to modify the serials while the connection is established. If a simple routine was created for the master server to verify the integrity of the client side app which locates and sends the serial numbers, then it would become even more difficult to fake.

Your statement also requires one to assume that the "something preventing/monitoring hooking" is not part of the client app which sends the serial number information (as a hash or whatever).

Anything is possible, and anything can be hacked since at some point the client must be trusted. In that way, I'm not contradicting myself in that I pointed out the fact that anything can be hacked in the original post. It was to be implied that what I suggested was, in my opinion, a "better" way; scratch that, it was actually said: "Here's a possibly better situation..."

You could argue that difficulty is relative, which I think everyone can agree on, so why even mention a more difficult to hack solution? But then you enter the realm of relatives vs absolutes and find out that everything you know and understand isn't "right" or "wrong" or anything at all, go insane, and hang yourself. So let's avoid paradoxicality and just say that, in my opinion, that the method I suggested is subjectively and relatively more "secure."

Edit: I don't mean any offense by this post. I did assume you were kindly making a joke with no seriousness intended (because of the smiley face). Assume that I am responding in kind, and not in any malicious way.

Link to comment

Ah, I had indeed read too quickly over the "*possibly* better solution". My apologies about calling it a contradiction then. :)

Faking hardware serial numbers without touching the client or Windows system files would indeed be difficult, if not impossible.

Link to comment

Exactly. You'd have to hack a specific system file, which might not be appealing for the general cheating masses. The one thing to always remember as a general rule with cheaters is that there might only be one actual cracker for every 1000 cheaters. The rest of the cheaters just follow instructions. There are some cheats for different games that have been made by people who never actually play the game. They do it for the heck of it. I can understand wanting to be able to get by something and the satisifaction of accomplishment, but why release it to the masses?

Anyway, between the two, people would probably prefer trying to hack a client app than system files. If there is an authentication server that actually generates the key, and if the client has to send this information, then it requires that there must be a connection. When the authentication server connects it can check some hashes or what not and verify the integrity of the app's memory space.

Link to comment
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...