Actually, I see a lot of similarities between your idea and mine. I definitely think that this is a good option and here is why I think it is impractical to hack such a system:

(from a chat from an undisclosed location):
The Process of Authenticating with the Server:
Download the DLL from the server
1) download some salt to shake into the particular data output (to help with making it harder to fake a return). The salt is either randomly built into the DLL or is randomly assigned from the server.
2) DLL runs some particular check (or a number of checks) on the existing game files
3) DLL runs some other random check (or number of checks) on the game data in memory
4) DLL runs some random check (or number of checks) for known trainers/cracks in memory
5) The output from these is then run through a function/some functions that was downloaded with the DLL to calculate the return value
The result is transmitted back to the server.

The numbered items are the places where you can randomly insert different features into the DLL. The DLL is prebuilt by the server with random elements of those 5 (at least 5) items. This way the client has no clear way to predict what the method of authentication will be, and once there is a hack for a particular authentication method, you can stop authenticating in that way and create new methods of authentication.

Also, having checks for specific hacks can be a useful thing to stop a hack from gaining popularity and thereby decreases the likelyhood that the crackers will successfully crack the client without your ability to counter it. There are probably a few other Authentication methods that can be used in conjunction with this.

Additionally it would help for the server to require completely different structures to the data it requires, so that any patterns can be well and truly scrambled. The server knows what a valid return value from the function will contain (or what valid return values) as these can be created at compile time so it doesn't require the server to calculate them every time - although salting the functions outside of a dll build would definitely require server-side computation of the value.

You are all forgeting one very important thing, this must be stable, supportable and testable code. Sure you can write code that morphs like crazy and does all kind of tricks, but what happens when you throw an error? All of this stuff you are doing will just lead to more errors, it will also make it imposible to debug and find errors. Your testing department will have fits and your tech support will be almost imposible Now you can say that you can come up with ways of identifing what code is being run where and when, but if you do that then the hacker can do the same thing. It is not only about making code that can't be cracked, it is about making marketable and useful code that can't be cracked.

theTroll

This conversation is LOL.

TheTroll is correct, simply write your server software to filter and authenticate incomming 'commands'. It is best in practice to treat the client as a 'dumb terminal'.

You /Can/ write very complex systems to try and keep your client code safe.

however there is still the potential for it to be cracked.

but with a totaly server-side solution you've striped the hacker of all potential, save for breaking down your server room door.


You can't crack what you don't have, it just makes sense.

Quote:

Theoretically it is possible to break it, but in practice it is next to impossible.

Quote:

The idea is not to stop someone from cracking it, the idea is to stop someone from playing the game with a cracked client.

You cannot make a client side asset secure. Not with clever programming, not with clever hardware. If the client knows how to produce the checksum for the server, it is already compromised.

Look at SecuROM, how many games use it, and how many devs are working on it. SecuROM is not staffed by fools, nor do they have a small budget.

You are not going to make something that's better than the competition. Thousands of people work with this every day as their job and there still does not exist a solution which is "practically impossible" to compromise.

You're simply wasting your time.

Indies are in a slightly different boat than profesional studios, we can't afford mammoth servers, and we can usually afford the time to secure the client further.

Obviously, there is no way to secure the client 100% (and whatever they tell you, this is also true about the server), but we can make it dificult enough to 1) keep out inexperienced 'script kiddies', and 2) waste enough time to make the hack not worthwhile.

I don't really like the idea of downloading a whole new executable every 30 seconds, seems like a waste, and then you have to switch executables while the game runs, not very nice.

But how about a small DLL, which modifies some game code/resources (to change the checksum), performs a checksum of the changed game and resources and does a memory scan to find signs of common hack techniques.

It then encrypts the checksum result into its own code, and is sent back to the server, where the server checks both the checksum and the DLL code itself.

A new DLL comes down every say 5-minutes, with a new encryption key, new checksuming method, and new modification to perform.

This means that 1) a hacker cannot find the checksum until the DLL has changed the files 2) that they must hack a new DLL every time and 3) they must revert the DLL to its original state plus the encrypted checksum before returning it.

Quote:

Original post by SymLinked You are not going to make something that's better than the competition. Thousands of people work with this every day as their job and there still does not exist a solution which is "practically impossible" to compromise. You're simply wasting your time.

If that is the attitude, why then work with anything? Thousands of people work with possibly anything you can imagine, so in theory you should not be able to come up with anything that those thousands haven't thought of? I must say I strongly disagree with that attitude, every year there are programs and solutions developed by "random people" (for the lack of a better term) that professionals didn't think of even though they work fulltime on it.

Now back to the original discussion,

Quote:

Original post by TheTroll You are all forgeting one very important thing, this must be stable, supportable and testable code. Sure you can write code that morphs like crazy and does all kind of tricks, but what happens when you throw an error? All of this stuff you are doing will just lead to more errors, it will also make it imposible to debug and find errors. Your testing department will have fits and your tech support will be almost imposible Now you can say that you can come up with ways of identifing what code is being run where and when, but if you do that then the hacker can do the same thing. It is not only about making code that can't be cracked, it is about making marketable and useful code that can't be cracked.

I posted a longer post in the other thread about how I thought this could work, the impression I had of this would be that you have defined your functions for this file. Input, output of everything in the file is defined and then you can make up multiple functions with different features.

So basically you would have stable client(s) without any random seed then you would make a separate program for doing some randomization on this source code. Putting together different functions, randomizing those things that can be randomized (encryption keys, what files to hash check, what stuff to scan for in memory, etc..)

Each function would be hand written and tested, no self changing code or anything like that. Of course there is an increased potential for errors to occour and there will be lots of extra work to do something like this. But it could potentially help fighting against bots.

Quote:

Original post by swiftcoder I don't really like the idea of downloading a whole new executable every 30 seconds, seems like a waste, and then you have to switch executables while the game runs, not very nice.

I think the idea was to only do this on game startup, but your ideas about downloading a dll on a regular basis is interesting.

Quote:

Original post by TheTroll You are all forgeting one very important thing, this must be stable, supportable and testable code. Sure you can write code that morphs like crazy and does all kind of tricks, but what happens when you throw an error? All of this stuff you are doing will just lead to more errors, it will also make it imposible to debug and find errors. Your testing department will have fits and your tech support will be almost imposible Now you can say that you can come up with ways of identifing what code is being run where and when, but if you do that then the hacker can do the same thing. It is not only about making code that can't be cracked, it is about making marketable and useful code that can't be cracked. theTroll

First of all, wether the endproduct is stable or not is out of the scope of this discussion, if someone sucks at programming he will most likely write unstable software too...

Second, if you read well you will notice that the system I suggest will need very little alteration of your code.
Just look at it as if you have the option to enable/disable it from ur compiler options.
Because that's how im planning to write it, I will create an extension to the gcc compiler. I'm not crazy enough to write all this from scratch.

Quote:

Original post by SymLinked You cannot make a client side asset secure. Not with clever programming, not with clever hardware. If the client knows how to produce the checksum for the server, it is already compromised. Look at SecuROM, how many games use it, and how many devs are working on it. SecuROM is not staffed by fools, nor do they have a small budget. You are not going to make something that's better than the competition. Thousands of people work with this every day as their job and there still does not exist a solution which is "practically impossible" to compromise. You're simply wasting your time.

Quote:

SecuROM is the fastest growing and most effective copy protection system for CD-ROM and DVD-ROM. Available Worldwide - Most Compatible - Easiest To Use 200 million discs protected since 1997.

This thread aint about CD-Whatever protections....we are in the subsection "network programming".

I don't want any of you to think this is a flame or an insult but do you think you are the best and most inteligent developers ever? People have been trying to prevent hacking from the very begining, it has NEVER stopped hackers. Yes I am sure there are possible ways of slowing them down and there might even be a way or two of stopping them. But everything has a cost. There are hardware solutions that can prevent hacking, expensive. You could do all kind of network games to try to stop them, but they can intercept the network traffic, do what ever they want to with it and then pass it on to your game. Yes they can even do this on the machine they are on. Because you have no control of the packets after you send them you don't know what the end user is going to do with them. They could prevent all your speacil updates and even send messages back saying that everything is ok.

You can NEVER trust the client. Anything you come up with can and will be hacked. It is not because you are not good at what you are trying to do, it is not becuase your ideas are not good, it is because there are a lot of them, and they have lots of time.

theTroll

Quote:

Original post by TheTroll I don't want any of you to think this is a flame or an insult but do you think you are the best and most inteligent developers ever? People have been trying to prevent hacking from the very begining, it has NEVER stopped hackers.

I don't wanna sound insulting either, but I think you are confusing reality with that movie "The Net".

I never said im the most intelligent developper, in fact im going to use software that has been under development for many years to achieve my goal, cuz I don't think I can write a compiler better than gcc.

I am not confusing reality with the "Net", I am saying what I am saying after 25 years of software development. I have been in more meetings then I can count about how to prevent hackers. We have researched thousands of different methods. In the end they are only a way to slow people down, not stop them.

theTroll