Soo... it would seem that nobody has bothered with this, or at least there's not much info on the subject. I'm worried that once I make something worthy of attracting many people, cheats will start spreading.
I'm talking about those lame memory modification tools here; I'm sure at least some of you know what I'm talking about. Is there any way to protect a MMF application's memory from being tampered with from the "outsite"? A way to detect and kill the popular debuggers and search tools, perhaps? C# and other .Net applications, for example have their memory in a "sandbox" to make it quite difficult to mess with; do MMF applications have any kind of protection? DMA? Anything?
...
Sorry, I'm a bit desperate for information. ; It would suck if I released something good, only for it to be ruined by a bunch of cheating children...
Well ... I dont know but it may be possible that there exists a kind of object that encrypts data like an encrypted array or similar. You could always make one yourself
MMF games rarely become so popular someone does a lot of work to cheat.
You could guard yourself against some cheats by doing some server side checking.
If everything happens on the server then it can't be hacked with memory editors. In games like MMORPGs nothing important is entrusted to the individual user, Everything happens on the server (movement, battles, experience, whatever). The players merely send commands and the server acts on them and sends them the result.
"Say you're hanging from a huge cliff at the top of mt. everest and a guy comes along and says he'll save you, and proceeds to throw religious pamphlets at you while simultaniously giving a sermon." - Dustin G
It seems that I wasn't specific enough in my first post. The game will have a central server, but it will only be used to store login and player stats data. Users will host games themselves. I do realise that some problems can be avoided by relying more on the server, but the problem is that this server happens to be another player as well. For instance: In a shooting game, he/she could disable collision detection for projectiles shot against him/her.
I guess one solution would be to make a variable mess, or "puzzle", which would make it a pain in the ass to isolate the correct memory addresses with which to tamper with. This, however, sounds very messy...
"MMF games rarely become so popular someone does a lot of work to cheat." Because you're all n00bs, heh heh... Kidding. For a game to be popular, it needs to have nice graphics in addition to an interesting theme. Many MMF games lack this. I honestly can't say whether or not mine will be any better, but at least that's my goal.
I have some nasty countermeasures in mind, but I'd rather not use those... unless I can't come up with a better solution. :/
Evil omg~!
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
4th April, 2005 at 03:45:10 -
For memory hacks there is the memory editor extension for MMF. But besides that you could always make the games verify their content with the player who is hosting the game, and if their content varies then disconnect them from the game.
But realisticaly, think about it when it happens. (Which it won't)
"Say you're hanging from a huge cliff at the top of mt. everest and a guy comes along and says he'll save you, and proceeds to throw religious pamphlets at you while simultaniously giving a sermon." - Dustin G
Another method you can use, which takes more memory but can often help, is duplication.
Hex editors (or at least the ones I've used) look for a certain value, and you keep looking until you've narrowed it down to one. For example, if you want to find the memory address of the ammo counter, you search for the value of the counter. Then you shoot once and search for the value of the counter minus one. Keep doing that, changing the value, until you find just one which always matches. And that is the memory address you want.
To make this harder, you can use an array and store each important value three times. That way you have three duplicates of the same number. The person has to try changing all three before they find the right one.
Once they have to do that, you can weave checks in with your events to ensure that all three counters are always the same. You may also be able to have a small array that I call an Audit Trail. It lists abbreviated data to tell you how key variables have changed and why. The idea is that if any changes don't add up, then it's been tampered with. (eg: ammo counter. The player loses 1 bullet each time he shoots. He has fired the gun 6 times. So his ammo should be [original value]-6. If it isn't, then something's been tampered with).
You can also store boolean values. These are a bit harder for some hex editors to deal with, because they usually set a whole byte's value. With a boolean value, you only want to change 1 bit of it - whilst allowing all the others to alter themselves happily.
That may help a bit.
But remember, a certain degree of editting and hacking simply makes people love your game more. Make it secure enough to be played safely, but not so secure that it's untweakable.
Have you tried using the save game object to make it a custom file that might not be tampered with instead of .inis? Or you could encode it using the Blowfish object. Hope this helps.
"Actually sir, we found a tiny unicorn in your exhaust. It was jumping around poking holes in your gas tank." "Oh thank you I did not know that. A tiny unicorn? Wow."
I've had a few ideas, and it turns out they weren't as creative as I thought at first. .
"But besides that you could always make the games verify their content with the player who is hosting the game, and if their content varies then disconnect them from the game."
Yep, cross-referencing. The server will actually be checked by other players for illegal modifications this way. This is one of the methods I'm going to use eventually.
"To make this harder, you can use an array and store each important value three times. That way you have three duplicates of the same number. The person has to try changing all three before they find the right one.
Once they have to do that, you can weave checks in with your events to ensure that all three counters are always the same. You may also be able to have a small array that I call an Audit Trail. It lists abbreviated data to tell you how key variables have changed and why. The idea is that if any changes don't add up, then it's been tampered with. (eg: ammo counter. The player loses 1 bullet each time he shoots. He has fired the gun 6 times. So his ammo should be [original value]-6. If it isn't, then something's been tampered with)."
Duplication will most certainly be used, but that "Audit Trail" would require some serious thought before I'd have an idea for a feasible implementation. I understand your idea, but there's a problem: The audit trail will not know that the gun has been shot 6 times if that value is frozen, so it will still match the tampered with ammo value.
In any case, this is certainly a start.
Also, another question. How easy are MMF executables to modify using a hex editor? Can in-game resources be stolen this way? What can be modified with ease? Are in-game string values stored in clear text inside the executable file? I'd like to know if I need to devise a plan to deal with that side of things.
"But remember, a certain degree of editting and hacking simply makes people love your game more. Make it secure enough to be played safely, but not so secure that it's untweakable."
Maybe, but I don't think so. In a game with online ranking/stat upgrades/avatars/currency, lamers will take any opportunity to get something for nothing, making the efforts of legitimate players to obtain the same benefits pointless. I don't see what things could be made tweakable, without compromising security. If it were a single-player game, I really wouldn't care...
"But realisticaly, think about it when it happens. (Which it won't)"
*laughs* At this point, I'm no longer even sure whether many people trying to hack my game is a good thing or not. I suppose it could earn me bragging rights among game devs, but it certainly wouldn't among the players. I guess I'll just have to live and see...
----------------------------
"Have you tried using the save game object to make it a custom file that might not be tampered with instead of .inis? Or you could encode it using the Blowfish object. Hope this helps."
Sorry, but you're a bit off-topic. We are discussing ways to protect the game from things like "money hacks" and "trainers" that are found among players of popular online games... Gunbound and MapleSory come to mind.
Yeah, it's very easy to steal extensions and midis. You can also rip MIDI files straight from TGF's .gam files because they're uncompressed (shouldn't work with cca though, since the cca file is compiled into the exe).
My explanation of how the audit trail works wasn't very good - it's basically a glorified array (with 2 dimensions). It starts with a list of possible actions, and how they alter the value. Eg: (for ammo again)
Action1 = Shoot (-1 bullet)
Action2 = Secondary Function (-5 bullets)
Action3 = Pick up ammo crate (+20 bullets)
Then after that it says the following:
Start : 50 (player starts with 50 bullets)
Action3 : 70 (player picks up ammo, so this goes +20)
Action1 : 69 (player shoots)
Action1 : 68 (and again)
Action1 : 67 (and again)
Action1 : 66 (so you see)
Action1 : 65 (it's just)
Action1 : 64 (a big)
Action1 : 63 (fat)
Action1 : 62 (ugly array)
Action2 : 57 (oo, a Secondary Function shot)
Obviously stuff like 'action1' would be represented by a code, probably just '1'. The array would grow to be huge after not very long, so you can let it get to about 20, then strip off the oldest 10 rows and replace them with one 'brought forward' value. So after being stripped it may look like this:
Bfwd : 63 (the brought forward number. We must always leave a few entries after it)
Action1 : 62 (this is the second-to-last value that we mentioned above)
Action2 : 57 (and this was the last)
Action1 : 56 (and here we start with the new things, the player shoots again)
Action3 : 76 (and now he picks up more ammo)
As you can see this is pretty cumbersome to use for lots of values - you'd only want it watching key ones, like health or ammo. But the Audit Trail itself doesn't need to be that big.
Because there is always at least a couple of values after it, the 'brought fwd' value can never be altered (because it would throw the other ones out of sequence).
The other actions recorded can't be altered either, because they each have a specific effect on the ammo counter. For example, Action2 always reduces the counter by 5. So if we have an audit trail like this:
Bfwd : 20
Action1 : 19 (this is a normal action)
Action2 : 200 (but this one has been altered)
The computer can check and see that the final value should be 20 minus 1 minus 5. It's not, so something is wrong.
As far as I can see, the most effective way to alter it would be to use a hex editor to add 'dummy entries' into the array. Adding an 'Action 3' several times so that the game thinks the user has picked up several ammo packs when he hasn't.
But that would be beyond most small-time hex editors I should think.
You could also change the final entry so instead of saying 'Action2 : 14' it actually says 'Action3 : 39' (so you've changed the value and the action to something that adds up - in this case, picking up an ammo case). That would be a pain. But at least the weirdness of the audit trail would make doing so much more difficult.
If someone made an Auditing extension (to do all this for you), then they could add a checksum and encryption to the array, and then any potential cracker would really be stuffed.
Advertisement
Post Reply
; It would suck if I released something good, only for it to be ruined by a bunch of cheating children...
Edited by the Author.
