Being a cracker nightmare!

I am trying to make a code hard to crack using Objective-C on a Mac.

One of the things I have to do is to check to see if the application was cracked.

I am new to Objective-C and Xcode and whatever way I imagine to test my application I always end in a basic test that can be patched easily.

For example: suppose I am about to test for the existence of a given value in a certain part of the binary. That operation will be something like:

"is this value = x?" if NO, it is cracked.

This is very easy to crack. The hacker can easily patch the test and make it be true always.

I am trying to imagine something that could test something, not appearing as a开发者_运维问答 test that can be easily patched.

I know I cannot stop 100% piracy, but at least I am trying to make things more difficult, to discourage most part of crackers out there.

Any ideas of ways stuff like this can be done without and turns things difficult for someone looking at the binary?

thanks for any help.

Unless your software is security related, I think a better approach would to change your licensing plan to make the software free for home users that barely use the software and expensive for organizations.

Organizations rarely use cracked software, due to the legal issues, where as home users that are occasional users don't like to spend $100s for using the software once in a while.

This would take away the motivation of crackers to crack the software.

Don't. Remember, (good) crackers crack software for fun. The more elaborate your protection scheme is, the more challenging and fun it will be for the cracker. Plus, people who are likely to use your software illegally are not going to pay for it anyway, even if they can't get a cracked version. Your time will be better spent making your product better.

Having said that, you can deter most amateur crackers by stripping your executable of debugging symbols. You'll have to enable this in project preferences.

All really strong protection schemes I'm aware of use self-modifying code extensively, one way or another. However, this is definitely not something a beginner programmer should be prepared to handle.

Make it hard for them to evaluate your scheme, and change your scheme regularly. A textbook example is to perform the check at odd intervals which will be time consuming for them to locate the sources of your checks and all cross references during the progress of the license evaluation. Combine that with multiple checks and you should be set for most releases, just add a good dose of creativity when creating your scheme. Also, it's a bit fun to play their game; to get them to release a crack that fails 1 month after the crack is posted... ok, that may just backfire on you, but if you are trying hard to fight them in the first place...

It's an interesting community; if you're new to this, studying the communities will also be beneficial. As previously mentioned, cracks happen for challenge, some product versions will simplify their copy protection scheme for 'free advertising'. So... you can't really fight cracking too hard because if somebody is determined, it will just waste your time and frustrate you. Observing the culture can be interesting. You're probably in the best position if you acknowledge that it being cracked equates to 'popular software', and therefore, you should be happy. You should generally not lose much sleep over this (though there are of course exceptions to this). Furthermore, as this question is listed in the Mac category: I am not going to dig up stats, but your software is less likely to receive attention from crackers if you're targeting OS X.

If you're a beginning programmer, clever use of that information (and acceptance) may be all you need to know to effectively fight crackers.

One danger is that if you go to overly great lengths, you may end up breaking things for legitimate users. A number of Atari's arcade machines in the 1980's had code which would do various interesting things if it detected that the ROM was altered. The effects would be subtle; for example, a game called Tempest would award unlimited free games if the game ended when a player had certain score values. In the release ROM of Tempest, however, the checksum was calculated incorrectly, so all machines had this behavior. I'm not sure to what extent this bug affected earnings in fielded machines, but I would imagine some operators would have been rather upset upon discovering it.