Quote:Original post by Anonymous Poster

Quote:Original post by Toolmaker
... but the game seems to quit when another process writes to memory.
...
This is also something you sohuld look for. Processes that are attached your client or trying to write to it's memory. I think there's a way to enumarate all attached processes.

Toolmaker

Complete, total, and utter waste of time. This was proved pointless approximately 7 years ago when Diablo was hacked using ?softICE? and live memory debugging. If someone has the time/inclination/energy to try hacking like that, they'll sooner or later find softICE and friends.

Here's the hacker solution (you can pass on to your friend if you like)

1. Find the memory you want to change
2. Change it
3. Step through the program letting it "discover" the interference
4. Identify the code that did the discovery
5. Disable it.
6. Go back to 1-2, and this time you won't be stopped

...or variations on that, depending on how many checks the program does. In general, someone who writes self-protecting code doesn't really understand basic security theory and probably ought to get a different job doing something they're competent at instead.

There are things that are worth doing just to slow down the hackers, but for any successful game you just want to either protect it, or not - this half-arsed crap just increases development time (+cost) without making the game any more secure.

redmilamber

You just proved yourself deaf. As just stated, Maple has specific guards that allow it to shutdown immediately upon the detection of a debugger trying to attach itself (yes, there is currently one way around this, which requires windows 98 compatiblity mode and a special VxD, but it can be fixed). It has both general purpose detection (it can detect any generic unknown debugger attaching, and can detect memory changes [it is possible to read so long as not set remote write mode in virtualProtect], and is filled with a list of known debuggers and hacking tools that will cause it to shutdown before any of the above even happens [as with most anti-hacking code, softice is at the top of the list for software to detect]).

Your post makes it sound like you are an amateur who has probably never even seen SoftIce in action, and are simply refering some kind of mythical version of SoftIce that you've hear about. But then that may not be true, you simply make it sound that way by not knowing much at all about what you are talking about.

I dont think maple story is a good example of a secure online game, I've read that the hit detection is done client side, which might be good for pushing down the processing necessary on the server, but now people have the ability to walk around without taking a hit. Also aparently life regen is also client sided, not good :( (aparently also you get kicked off for regaining life too often). Maple story's debugger detection isnt more than a call to IsDebuggerPresent() which can be got around easily, and I think they do CRC checks on their code or something periodically, i just read it but i'm not sure :P. I never did anything with this game personally but just read some stuff from people who have :).

Obviously encrypting your protocol will help to a point - however still dont asume this will protect anything. This will stop simpler crackers, but still people will reverse your encryption. Also encrypting your packets wont be all protecting because when people edit something like their position for example - your encryption will still process whatever coordinates they set.

Generally as said the client should just request actions being done, and the server should check if it's possible, within range, within reasonable values to not crash your clients, correct length packet, etc. Basically asume the player can and will use any possible values for everything in the packets. Generally they can get really creative, and if you give them any openings it could result in total disaster. Also a major thing alot of game developers tend to forget about is speed, be sure to not let them take advantage of this on you :)

A good thing to do to track duping is to ID your high end items, so you could go through your database periodically and make sure no one has more than 1 of the same ID best item in the game :D Maybe since it's a small scale game you could even detect when high end items like this are sold to NPC's, traded, whatever :) I guarantee if you put a great item in the hands of someone who knows how to dupe - they will do it. You could use this to your advantage by letting them 'find' an amazing item, and log all traffic between you and the person who has that special item (of course they will transfer it to some newbie to dupe with to avoid deletion, yada yada) althrough you should be extremely secure when dealing with item transferring/dropping/picking up/whatever so there shouldnt be any duping, but sometimes stuff just happens ;)

Quote:Original post by Michalson
You just proved yourself deaf.

I'm sorry if it wasn't obvious, and I'm sorry for not explaining in detail, but I thought it *would* be obvious. As hplus explained in slightly more detail... you can NEVER write an application that prevents debuggers attaching unless you have more power over the user's machine than the user themself has. Whilst MS is trying to get machines built and sold where this would be true (MS + partners would be able to do things to your machine that you could not control because the hardware and software would have a shared secret) it is still far from being reality.

In the meantime, there is nothing you can possibly do to any client machine that the machine's owner (the game-player) cannot outwit, given the right tools, effort, and brain power. This is one of the things peculiar to games that makes game-security much more interesting than normal security - anything that enters or leaves the player's machine is untrustable. The player has NO vested interest in keeping the system secure; quite the opposite.

Quote:Original post by Michalson
Your post makes it sound like you are an amateur who has probably never even seen SoftIce in action, and are simply refering some kind of mythical version of SoftIce that you've hear about. But then that may not be true, you simply make it sound that way by not knowing much at all about what you are talking about.

Alternatively, it could just be that you missed my point :). Being pedantic, if you re-read my pseudo-code carefully you'll see it was actually written to apply inclusively to your "detection of debugger attaching". Shrug. re: usage, I haven't personally used it since D1, and I haven't played that in many years (D2 is already getting on for a decade old!).

re: being an amateur - yes, I am in no way a professional game-cracker! But I am a security professional in the games industry.

Quote:Original post by graveyard filla
basically i just dont trust anything to be done client side.

true

Quote:im still a little confused on how people cheat though.. so it's mostly people attaching a program to the memory of my program?

Not only that. As stated in a previous post, by intercepting data sent from the server to the client, one could gain information that are normally not available (radar exploit).

Also, never, ever send another player IP address. I can't remember which game was using peer-to-peer connection for chat to save some bandwidth. Some users were using it to launch small DOS attack on the other player, resulting in the attacked player not receiving delayed server information (when receiving it) and thus giving an unfair advantage to the attacking player.

Quote:is it possible for them to write a program that could receive the packets my game should and then manipulate the packets and send it to the game, like how i describe in my first post?

Yes but normally it's the other way around ( outgoing packet are intercepted and modified before getting to the server ).

Quote: not really sure what any of that means, but it sounds nice [smile]. it says that it add's up to 15 bytes to each packet though. and i can't use it for only certain packets, its either all or nothing. do you think i should turn this on? or should i just try to account for the security on the game level only? is 15 bytes too much for every packet?

Depends on your average packet size and packet throughput. But, if I remember well, you're not aiming for MMO user count so the little extra shouldn't be noticable.

Gizz

Is there nothing that can be done using Data encryption? even if it was hardware assisted encryption/decryption?

For example:
What if every server->client stream was encrypted with mutually secret keys? If that was done, then no packet sniffing would get any information.

What if every client->server message had a digital signature that was applied by hardware? this would verify authenticity of the client message, and prevent spoofing.

At the network layer, this is really all you can do.

You can't prevent someone from changing the source program in resident memory, by watching or modifying the network layer.

(or can you?)

Harlan

Quote:Original post by Harlan
Is there nothing that can be done using Data encryption? even if it was hardware assisted encryption/decryption?

See above. Short answer: no, unless there is a shared secret between CPU/(core of PC) and your game which locks out all OS's on the PC from actually doing anything, OR between (CPU/etc and OS and game) which causes the OS to give more access to the game-code than it does to any code sourced by the *owner* of the PC.

IMHO it's an evil ass-raping scum of the universe style thing to do for MS to propose "owning" part of every physical PC in the world such that the physical owner does not own the PC any more (this is what they were proposing with Palladium, in one of it's guises). In some jurisdictions (notably parts of Europe) this kind of thing was tentatively made illegal many years ago - unfortunately, such laws can be removed, given enough bribes to govt, and MS will probably get them annulled / "corrected" sooner or later :(. Sob.

So, whilst technically speaking it is both possible AND there are prototypes around that would allow it AND MS has shown an interest in bringing it to consumer desktops, you would be a fool to follow that path. Maybe in 20 years time, if MS wins...