On Monday, January 12, 2015, João Varela <joaocvar...@gmail.com> wrote:
> Hi > > I rolled out my own license scheme so that I don’t have to pay anyone. ;) > I find that coding license checking methods with Cocoa and Objective-C is > terribly unsafe. Objective-C has the nasty habit of exposing classes and > their methods, which you can easily access/find out if you know what you > are doing (otool and class-dump for starters). Yes, and some other languages like Java, .NET, etc have the same problem. The runtime nature of Objective-C means that information about the classes must be stored in the binary, which makes it easy for determined hackers to crack your application. > I do all my license checking code in C++ or just plain C, and use > redundant checking in different places. Another trick I learned in a > conference is to use critical variables as static variables rather than > class ivars. Another important thing to do is trying to tie in your code with other critical subroutines in your program so that if a hacker patches your binary to change its functionality, it will break other things as well. This can be tough to do but can frustrate a pirate enough to where he may abandon the cracking attempt (especially if he's a novice). That may seem obvious, but I once saw an app (I won't say which) which encoded it's licensing technology in an external, loadable bundle. Replacing that bundle could thus crack the application without even having to modify the main app. > However, my needs are probably different than yours, but all I’m saying be > careful how you expose your licensing code if you are going to use > objective C. Separate out your license code so that it is never called from Objective-C: make it a static C method and call it via assembly if you have to. But don't do something dumb like hookup your validation code to a nib or to a view controller or app delegate - that makes it *way* too easy to find out where your validation code is stored, allowing a novice cracker to easily circumvent any protection. > > Please read this: > > http://loadcode.blogspot.pt/2006/02/cracking-software-on-os-x.html > > and this: > > > http://lifehacker.com/5736101/how-to-crack-just-about-any-mac-app-and-how-to-prevent-it Both very interesting articles, but tbh, I think that those techniques are fairly simple to perform for any software developer worth his salt. By implementing common sense security you can throw off 90% of potential crackers, leaving you only with the professionals to deal with. And you can throw in little surprises for them. ;) > > HTH > > J. Varela > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com <javascript:;>) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/sevenbitstech%40gmail.com > > This email sent to sevenbitst...@gmail.com <javascript:;> _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
