[NSBlog date:@"19 September 2008"].comments = 0;

teaser

Prepare … to … laugh!

Due on the app store soon.

Curl Wallpaper

[NSBlog date:@"25 July 2008"].comments = 0;


[click on image to download]

Notes on air travel

[NSBlog date:@"24 July 2008"].comments = 1;

I would say I fly pretty frequently. Having just come back from Geneva, Switzerland to Durban, South Africa, there’s a few things I noticed.

3 Easy Tips to Prevent a Binary Crack

[NSBlog date:@"27 June 2008"].comments = 9;

When coding anti-piracy prevention measures, your goal should be to keep honest users honest.
It is important to make the user experience pleasing and simple for your paid customers.

While in an ideal world, people would buy everything legally, reality is very different.
Most people, if tempted with an easy free way to get your app, will pirate even though they know it is wrong.

Here are three easy tips that will help your app resist to binary cracks, but do not take much work to implement.

You can grab the sample code for the first two tips.

Strip debug symbols

Stripping debug symbols will remove all the method names from the executable, which makes it a lot harder for anyone to reverse-engineer your app using gdb. (I showed how this is usually done here) Now, instead of seeing all your method names, which method the app is currently in, and instead of being able to breakpoint the app at that spot, they’ll only see hexadecimal addresses.

You can still get around this by class-dumping the executable and getting new method’s hex addresses from there, (although they might be off by a certain difference which you’d have to calculate) but this already makes it a lot harder for crackers to attack.

So, without further ado, here’s how you do this: Apple’s documentation has a detailed explanation, so instead of rewriting it myself, I’ll just copy-paste it here:

Xcode provides several built-in options for stripping executables of their debugging symbols. One of these is the Strip Linked Product build setting. While typically set, it has no effect unless the Deployment Postprocessing setting is also set. Deployment Postprocessing is a master switch that enables the action of a host of other build settings. It’s approximately analogous to running the xcodebuild tool with the install command.

Again, open the target build settings and turn on debugging symbols for the Release configuration. Open the project build settings; in the Release configuration, enable both Strip Linked Product (if it isn’t on already) and Deployment Postprocessing. Your project settings should now resemble those shown in Table 2.

Build Setting Value
Deployment Postprocessing YES
Strip Linked Product YES

PT_DENY_ATTACH

Behind this barbaric name is a very useful flag which lets you prevent gdb from attaching to your app. Ever tried debugging iTunes? Give it a try now, but be prepared for a disappointment, it crashes gdb when it tries to attach to it.

One step further in protecting your app after striping debug symbols is to activate PT_DENY_ATTACH. Note that this doesn’t make stripping debug symbols useless. While in theory it does, there are ways to get around it.

Activating this protection is really easy, and only involves editing your main.m.

//
//  main.m
//  ProtectionSample
//
//  Created by Kenneth Ballenegger on 2008/06/27.
//  Copyright Azure Talon 2008. All rights reserved.
//

#import <Cocoa/Cocoa.h>
#include <sys/ptrace.h>

int main(int argc, char *argv[])
{
    //Build settings -> Other C Flags: -DDEBUG
#ifdef DEBUG
    //do nothing
#else
    ptrace(PT_DENY_ATTACH, 0, 0, 0);
#endif
    return NSApplicationMain(argc,  (const char **) argv);
}

This code should be pretty self-explanotary…

You need to have a flag that differs for release build and debug builds. You want to be able to debug your app while you code it. That’s why I set Other C Flags for the Debug build settings to “-DDEBUG” and used an #ifdef to activate it only for release builds.

Test it if it works quickly, fire up terminal and try to use gdb.

seoMac:~ kenneth$ gdb /Users/kenneth/Desktop/ProtectionSample/build/Release/ProtectionSample.app/Contents/MacOS/ProtectionSample
GNU gdb 6.3.50-20050815 (Apple version gdb-952) (Sat Mar 29 03:33:05 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries ..... done

(gdb) r
Starting program: /Users/kenneth/Desktop/ProtectionSample/build/Release/ProtectionSample.app/Contents/MacOS/ProtectionSample
Reading symbols for shared libraries ++++....................................................................... done

Program exited with code 055.
(gdb)

Congratulations, it works! Your app cannot be loaded into gdb anymore. (Note: there are workarounds. Experienced hackers who really want to will still manage to get in.)

Checksum your binary

The last tip for today is of a different kind, and it is probably the most effective of the three.

Basically, all you need to do is to checksum your binary. Put the md5 somewhere in your .app, preferably well hidden. Preferably use a salted hash, or double-hash it. Make it hard for a potential hacker to figure out how to get the correct hash for a given hash. Hide the file in which you store this hash well, or store it in your Info.plist. Where you store it doesn’t matter, but you can’t put it in the binary. Preferably set up a build script that will re-generate the new hash at every build (when your binary changes), so you don’t have to do it yourself.

In your code, check the stored hash against the binary, and if they are different, it means the binary has been modified. In that case, display an error message asking to re-download the app from your site, and quit.

New Site

[NSBlog date:@"21 June 2008"].comments = 0;

I am not dead.

I haven’t posed here in more than a month, because a month and a half ago I suddenly found myself without a computer. The local power utility company, Eskom, burnt my motherboard down. I have already posted about how much Eskom sucks in the past, so I will not elaborate on that.

So my Mac was broken, just when the 1 year warranty was over. I sent it in for repairs, at a local Apple Certified repairs place. They quoted me for nearly R10’000 (That’s about $1500). After a month of nothing being done, I decided to just buy a new Mac, instead of bothering repairing that one. I bought a new iMac 20” 2.66GHz, and switched the RAM and the Hard Disk from the old one. I am now back online, with a brand-new computer, and I shall be updating this blog more often now.

The real reason for this post, though, is to announce my new site. I have had this idea in mind for a long time, and I really needed a site that could serve as my identity hub. By that, I mean a page that links to my main profiles around the internet: This blog, my company site, my deviantArt profile, my Twitter account, my last.fm profile, and lastly my Facebook profile.

Introducing kenneth.ballenegger.com!

I have to say I’m pretty proud of this design.

Here’s a short video of the main design steps & decision that went into this site:

Older Entries
Newer Entries