Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Checksum testing


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 Hiyar   Members   -  Reputation: 130

Like
0Likes
Like

Posted 16 December 2011 - 02:58 AM

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

Sponsor:

#2 Ashaman73   Crossbones+   -  Reputation: 7793

Like
0Likes
Like

Posted 16 December 2011 - 03:49 AM

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.

#3 Nypyren   Crossbones+   -  Reputation: 4495

Like
0Likes
Like

Posted 16 December 2011 - 03:54 AM

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).

#4 Hiyar   Members   -  Reputation: 130

Like
0Likes
Like

Posted 16 December 2011 - 04:09 AM

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.

#5 Ashaman73   Crossbones+   -  Reputation: 7793

Like
0Likes
Like

Posted 16 December 2011 - 04:52 AM

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.

#6 NickWiggill   Members   -  Reputation: 177

Like
0Likes
Like

Posted 10 January 2012 - 09:37 AM

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.

#7 Bacterius   Crossbones+   -  Reputation: 9055

Like
0Likes
Like

Posted 10 January 2012 - 10:06 AM

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; // :D
}

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.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#8 clb   Members   -  Reputation: 1785

Like
1Likes
Like

Posted 10 January 2012 - 12:28 PM

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).
Me+PC=clb.demon.fi | C++ Math and Geometry library: MathGeoLib, test it live! | C++ Game Networking: kNet | 2D Bin Packing: RectangleBinPack | Use gcc/clang/emcc from VS: vs-tool | Resume+Portfolio | gfxapi, test it live!

#9 frob   Moderators   -  Reputation: 22218

Like
0Likes
Like

Posted 10 January 2012 - 01:38 PM

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.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#10 Bacterius   Crossbones+   -  Reputation: 9055

Like
0Likes
Like

Posted 10 January 2012 - 03:11 PM

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.

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.

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).

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#11 Antheus   Members   -  Reputation: 2397

Like
0Likes
Like

Posted 10 January 2012 - 03:50 PM

Is it possible for a hacker to modify the executable in a way that all kinds of checksum tests are useless.


If yes, how?


Through least possible effort. Hash too strong? Attack validation mechanism. Mechanism too strong? Attack the hash. Both too strong? Buy a wrench.

Is content downloaded? Poison DNS, perform social attack on GoDaddy, rely on memory corruption to resolve wrong IPs, serve your fake content from there without restrictions. Using SSL? Steal a root certificate and spoof that.

All security attacks are about exploiting the weakest link.

#12 Deprecated   Members   -  Reputation: 107

Like
0Likes
Like

Posted 11 January 2012 - 12:41 AM

Self-encrypting Code to Protect Against Analysis and Tampering (J. Cappaert, et al.) comes to mind.

A simpler way to provide strong security against reverse-engineering would be polymorphic encryption. Oddly enough it's a technique that originated from the malware hobbyists and although it's nowadays used by serious software developers a lot of good documentation and examples can be found on sites focusing on malware development and (software) security analysis.

It is disputed whether or not it is possible to create a software that can't be detected and therefore analyzed (see Blue Pill malware), although it is possible to protect the code good enough so that the effort of cracking it outweighs the worth of cracking it.


Although you could write every single function of your program so that it could be encrypted and loaded into memory only one function at a time (which makes both recursion and object-oriented programming impossible, by the way) it is highly unlikely that you'll find a graphics library that works with that kind of programming. It is also highly unlikely that you'll need that kind of security. As frob said, you need to consider who you're protecting yourself from and how much your data/code is worth to them.
Those who can do, do; those who can't do, do teach.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS