Hi,
Is it possible for a hacker to modify the executable in a way that all kinds of checksum tests are useless.
If yes, how? And is it possible to still detect the modification by using different methods such as testing different parts by using offsets, or some other method?
Thanks
Checksum testing
Hi,
Is it possible for a hacker to modify the executable in a way that all kinds of checksum tests are useless.
Yes.
If yes, how? And is it possible to still detect the modification by using different methods such as testing different parts by using offsets, or some other method?
Thanks
As long as the machine code is available (which is the case for all software you execute on your PC), you can hack it. You can make it difficult, but you can't avoid it.
Very simple example:
You have some checkSum method implemented which returns true, if everything is valid. The hacker just need to overwrite this method (directly in machinecode) to return always true. It is simple like that.
1. Yes.
2. A skilled hacker will find and disable the code that performs the tests.
3. No. The hacker would just disable those as well.
The only way I know of to be safe is to never provide the hacker with that code in the first place. That means moving important code to an online server and force the user to connect over the internet to use that functionality (removing the code for the feature ENTIRELY from the client). Just a simple login check will not suffice; if your client can do everything the server can, the hacker will simply disable the login requirement.
Unfortunately, server-side code often completely ruins your program's responsiveness (which is why you often see MMOs which don't have fast-action gameplay).
2. A skilled hacker will find and disable the code that performs the tests.
3. No. The hacker would just disable those as well.
The only way I know of to be safe is to never provide the hacker with that code in the first place. That means moving important code to an online server and force the user to connect over the internet to use that functionality (removing the code for the feature ENTIRELY from the client). Just a simple login check will not suffice; if your client can do everything the server can, the hacker will simply disable the login requirement.
Unfortunately, server-side code often completely ruins your program's responsiveness (which is why you often see MMOs which don't have fast-action gameplay).
Author
My question is, can the executable be modified so that any checksum cant detect it.
I didnt say the checksum algorithm is in the executable
And of course I would never use any checksum directly, A single checksum function used for "cmp" would be useless of course.
I didnt say the checksum algorithm is in the executable
And of course I would never use any checksum directly, A single checksum function used for "cmp" would be useless of course.
My question is, can the executable be modified so that any checksum cant detect it.
Let's say it is unlikely.There're endless checksum calculation possible, atleast, you could say the program itself is the "checksum" (in this case you would do a 1:1 comparision).
In theory it is possible to modify a executable so, that it will deliver the same check sum, but it is hard. It will get even harder when you use multiple,but different, check sum algorithm.And it will get even harder (almost impossible) when the hacker has no knowledge about the used check sum algorithm.
I read this question more as, "Can checksums be guaranteed safe?" As with everything else in regards to security, it depends very much on your communications architecture and my first impulse would have been to reply, "YES" because I use authoritative client-server.
Provided you're trusting the client (whether in P2P or client-server) to give you a yes/no answer to the question, "Is this valid?" then of course, like a bad child, the client can reply with any lie it deems fit. ("Did you do your homework?" -> "Yes, mom") This is a problem particularly in peer to peer, since if there is no single authoritative peer, no peer has a sound basis on which to question responses from any other peer (they are all equals).
On the other hand, just as in real life, when you want to determine authenticity or at least motivations of someone you suspect might lie, you as the authority might instead ask, "What is the answer to this question?", where that question is something to which the answer is known.
That's the only principle you should follow here. It's not just about checksums. Its about everything that needs to be secure in game network communications.
In my current project, the server requests checksums from clients for modified terrain chunks, to see that the client has implemented only the deltas to terrain that the server has implemented, and no other deltas. Since the client and server should have identical base copies, this is simple to maintain.
Provided you're trusting the client (whether in P2P or client-server) to give you a yes/no answer to the question, "Is this valid?" then of course, like a bad child, the client can reply with any lie it deems fit. ("Did you do your homework?" -> "Yes, mom") This is a problem particularly in peer to peer, since if there is no single authoritative peer, no peer has a sound basis on which to question responses from any other peer (they are all equals).
On the other hand, just as in real life, when you want to determine authenticity or at least motivations of someone you suspect might lie, you as the authority might instead ask, "What is the answer to this question?", where that question is something to which the answer is known.
That's the only principle you should follow here. It's not just about checksums. Its about everything that needs to be secure in game network communications.
In my current project, the server requests checksums from clients for modified terrain chunks, to see that the client has implemented only the deltas to terrain that the server has implemented, and no other deltas. Since the client and server should have identical base copies, this is simple to maintain.
Put it this way, anything that isn't performed in a secure environment (server-side, for instance) can and will be modified. If in an MMO the server performed absolutely no security checks on what the clients are sending, cheaters would be running rampant. On the other hand, server-side verification code cannot be modified by the pirate, and thus this is where security checks should be located.
As said above, if your program has a function that returns whether the passed checksum is valid:
bool IsValid(Checksum)
{
// do some checking
return result;
}
The pirate will simply transform it to this:
bool IsValid(Checksum)
{
return true; //
}
Same if you have a function that computes the executable's checksum:
int ComputeChecksum()
{
// compute the checksum as usual
return checksum;
}
The pirate will do this instead:
int ComputeChecksum()
{
return 0; // busted, all checksums will be the same now regardless of the program's state
}
So as you can see, if the code can be modified it is inherently insecure no matter how many checks you introduce - a good pirate will just bypass them all.
As said above, if your program has a function that returns whether the passed checksum is valid:
bool IsValid(Checksum)
{
// do some checking
return result;
}
The pirate will simply transform it to this:
bool IsValid(Checksum)
{
return true; //
}
Same if you have a function that computes the executable's checksum:
int ComputeChecksum()
{
// compute the checksum as usual
return checksum;
}
The pirate will do this instead:
int ComputeChecksum()
{
return 0; // busted, all checksums will be the same now regardless of the program's state
}
So as you can see, if the code can be modified it is inherently insecure no matter how many checks you introduce - a good pirate will just bypass them all.
A bit of clarification on the terms used: a checksum is not a term that is ever used to refer to a security check. When an author uses the word 'checksum', he or she always refers to protection against accidental data corruption, never to protection against malicious or deliberate data corruption.
When talking about protection against deliberately forged or tampered data, one uses the terms hash function, message authentication code and/or a digital signature. Based on these, if you are looking to build a system that is cryptographically strong, these will involve private-public key pairs and/or server-client communication.
Protections that don't use any of the above, become reverse-engineering challenges, instead of cryptographic challenges for the attacker (not to say that reverse-engineering challenges would be any easier in practice, if performed well).
When talking about protection against deliberately forged or tampered data, one uses the terms hash function, message authentication code and/or a digital signature. Based on these, if you are looking to build a system that is cryptographically strong, these will involve private-public key pairs and/or server-client communication.
Protections that don't use any of the above, become reverse-engineering challenges, instead of cryptographic challenges for the attacker (not to say that reverse-engineering challenges would be any easier in practice, if performed well).
Even if the OP is talking about attempting multiple hashes for security (not checksums), those are also breakable if the user has any control over the content being hashed.
Back in 2004 there was a research paper on it, just showing how long it took on average along with actual examples; they didn't show the method since that is readily available. They could find collisions for MD5 in under an hour on average; Havel-128 and RIPEMED hashes took a few hours to find a collision, but still nothing too difficult. That was 2004. Update to 2012 at half the time every 18 months, that reduces it down to just a few minutes for MD5 and under an hour for some of the others.
As long as the user has control over both sets of data being hashed finding a collision can be done with brute force rather quickly.
As with any security, you need to consider exactly who you are trying to protect from, how long the data will remain valuable, and consider the value of the target from the perspective of the attackers.
High-value targets (e.g. Sony's PS3 keys, or government secrets) are under constant attack by amateurs and experts alike.
Low-value targets are typically ignored in favor of higher value targets; the logic is simple enough. Why attack a small insecure bank with 50,000 customers when you can attack a large insecure bank with 5M customers? Why attack a small web site with 750 user accounts when you can attack a large insecure site with a quarter million accounts?
Unless you are working for an actual business with a substantial budget, your time is better spent on making your game rather than worrying about security. For a small game being fun/good enough to be pirated tends to simultaneously provide the network connections to help trend to critical mass of becoming profitable. When you reach that point you can apply an update to stop all piracy of your game.
Back in 2004 there was a research paper on it, just showing how long it took on average along with actual examples; they didn't show the method since that is readily available. They could find collisions for MD5 in under an hour on average; Havel-128 and RIPEMED hashes took a few hours to find a collision, but still nothing too difficult. That was 2004. Update to 2012 at half the time every 18 months, that reduces it down to just a few minutes for MD5 and under an hour for some of the others.
As long as the user has control over both sets of data being hashed finding a collision can be done with brute force rather quickly.
As with any security, you need to consider exactly who you are trying to protect from, how long the data will remain valuable, and consider the value of the target from the perspective of the attackers.
High-value targets (e.g. Sony's PS3 keys, or government secrets) are under constant attack by amateurs and experts alike.
Low-value targets are typically ignored in favor of higher value targets; the logic is simple enough. Why attack a small insecure bank with 50,000 customers when you can attack a large insecure bank with 5M customers? Why attack a small web site with 750 user accounts when you can attack a large insecure site with a quarter million accounts?
Unless you are working for an actual business with a substantial budget, your time is better spent on making your game rather than worrying about security. For a small game being fun/good enough to be pirated tends to simultaneously provide the network connections to help trend to critical mass of becoming profitable. When you reach that point you can apply an update to stop all piracy of your game.
Even if the OP is talking about attempting multiple hashes for security (not checksums), those are also breakable if the user has any control over the content being hashed.
Back in 2004 there was a research paper on it, just showing how long it took on average along with actual examples; they didn't show the method since that is readily available. They could find collisions for MD5 in under an hour on average; Havel-128 and RIPEMED hashes took a few hours to find a collision, but still nothing too difficult. That was 2004. Update to 2012 at half the time every 18 months, that reduces it down to just a few minutes for MD5 and under an hour for some of the others.
As long as the user has control over both sets of data being hashed finding a collision can be done with brute force rather quickly.[/quote]
This is absolutely not true for newer hashes. MD5 (and other old hashes like RIPEMD etc..) have been broken but no practical cryptographic flaws have been found so far for newer hashes such as SHA2, Whirlpool or even SHA3. Nobody in his right mind would use MD5 for more than transfer integrity verification, even at the time this paper was published. Cryptographic breaks don't suddenly come out of nowhere and destroy hundreds of secure platforms, instead it gradually appears through research that some algorithm may not be so secure after all and the latter is slowly shoved out of products for a better one.
Besides, the problem here isn't even about cryptography but about simple design - the point is that any logic (within the code itself) used to perform verifications on any data whatsoever can be abused if the code is located offline, regardless of whatever the code may be doing. It's enough to even insert a return true (in machine code, of course) at the beginning of a simple verification routine, and you're done.
Fundamentally, when you write code you assume the laws of logic hold true, however when you write security routines with code that may be potentially tampered with, those laws of logic no longer hold because of the accessibility of the code, making it infeasible to write secure code. This is the basis for online authentication, and the reason it works is because the verification code can no longer be tampered with as it is located on a remote server.
Unless you are working for an actual business with a substantial budget, your time is better spent on making your game rather than worrying about security. For a small game being fun/good enough to be pirated tends to simultaneously provide the network connections to help trend to critical mass of becoming profitable. When you reach that point you can apply an update to stop all piracy of your game.[/quote]
This is however true, and even big companies can't get it right sometimes, so time is often better spent on fixing the game for legitimate players than proofing it against the 0.1% that may be looking forward to pirating it (unless, of course, you run a risk of losing actual value by letting those 0.1% run rampant, in that case security should be included with the game from the ground up, but usually that isn't the case).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement