Van de Graaf Generator

If you’re a graphic designer, you’re probably familiar with canons of page construction. In book design, canons of page construction help you use aesthetically pleasing and balanced text block and margins. It has been used by many typographers throughout the ages, starting with the Gutenberg bible.

Constructing them, though, is somewhat of a pain. You have to go through a long series of steps, either in illustrator or by hand, constructing the text block geometrically. So I decided to write a small web app to do it automatically. Check it out online! Currently, only the most common canon is supported, but in the future I will add any canon I find the need to construct to the project.

If you’re more of a developer, I’ve open sourced the project on github under the Azure License.

Working on some Graphic Design homework…

This is simply amazing. It will change your life.

(Source: reddit.com, via cocoageek)

On Saturday, I attended the Compostmodern conference on sustainable design. Sustainability is a fancy buzzword used by big corporations so that they can feel socially responsible. File it away with previous contenders such as Synergy and Trickle-down, and don’t ever use it. But beyond the ill-advised terminology lies an really important concept; which is that as we design, we have responsibilities that go beyond the client’s brief and balance sheet. Sure, those should always be the primary considerations—but we also have a responsibility to our environment and society. Sustainability is at the intersection of consideration for the environment, society and economy.

In order to get the most out of the concepts from the conference, though, design must be defined as more than any or all of the professions suffixed with the word design. (Industrial, Graphic, Web, Interior, Interaction… you name it!) Design is—or should be—everything a company does. Every interaction anyone ever has with a company, good or bad, becomes part of its brand. One of the first concepts introduced by several of the speakers was that of 360° Design. With 360° Design, the challenge is to design a product or brand across all aspects of its presence, whether web, print, physical, or even the experience of using it. The concepts of sustainable design, though, apply to more than design. You can draw from it in entrepreneurship, leadership, or even as a way of life.

For me, two nuggets of wisdom stood out from the various talks. The first one pertains to getting a message effectively across through what speaker Jonah Sachs calls the Myth Gap. A successful myth is the combination of explanation, meaning and story. Explanation serves the rational mind, while meaning serves the emotional. The last element, the story, is what engages the consumer. A successful story can be further divided up in three basic elements: freaks, cheats and familiars. Freaks are human characters that are extraordinary in some way. Cheats are those don’t follow the status quo. This includes both criminals (whom the viewer is against), or rebels (whom the viewer roots for). The last element is familiars: things which viewers can relate to. It is by combining all of these elements that most of the successful stories caught traction.

Secondly, Lisa Gansky introduced attendees to the concept of the mesh. The mesh is about the sharing of experiences and physical things among people. The new wave of popular services provide access to experiences, rather than ownership of things. Netflix, for example, lets people experience movies without having to buy and own them. Zipcar, similarly, allows for on-demand access to a car without having to own a car. Airbnb provides peer-to-peer access to other members’ proprieties without having to rent a hotel room.

The overarching theme of the conference, though, was sustainability. The common perception of sustainability is that of radical green-activism such as Greenpeace. Many, including myself, find this kind of activism off-putting. Not only does it alienate me with its holier-than-thou attitude, but it often does much less good than what can be achieved through friendlier means. The key to getting people involved in a project that benefits the greater good is to incentivize the better option. Give them an alternative that does not compromise their experience of the product.

Green is not absolute. The goal should not be to have a green product, but rather a greener version of what people currently have and want. Sure, the warm feeling one gets when doing something good can be an incentive; but don’t kid yourself, people will always put their quality of lift first, and rightly so. After all, that is the whole basis of the american dream and the founding of this very nation—the pursuit of happiness. As Benjamin Franklin once said, “those who sacrifice liberty for security deserve neither.” Rephrasing his quote, I will boldly claim that those who sacrifice the pursuit of happiness for the hope of a better future deserve neither.

Playing with my brand-new Canon EOS 550D. Post-processed in Lightroom 3.

I Can Crack Your App With Just A Shell (And How To Stop Me)

Well, not you specifically, but by you I mean the average Mac developer. It’s too easy to crack Mac apps. Way too easy. By walking through how I can hack your app with only one Terminal shell, I hope to shed some light on how this is most commonly done, and hopefully convince you to protect yourself against me. I’ll be ending this article with some tips to prevent this kind of hack.

Disclaimer: I am fervently against software piracy, and I do not participate in piracy. Some will view this article as an endorsement of piracy, but rest assured that it is not. However, I do not believe that obscurity and ignoring the problem is an acceptable solution.

In order to follow along you’re going to need a few command line utilities. You’re going to need the Xcode tools installed. And lastly, you’re going to need an app to operate on. I chose Exces, a shareware App I wrote a long time ago.

Let’s start by making sure we have the two utilities we need: otx and class-dump. I like to use Homebrew as my package manager of choice. Note that I will use command line utilities only, including vim. If you prefer GUIs, feel free to use your code editor of choice, HexFiend and otx's GUI app.

$ sudo brew install otx
$ sudo brew install class-dump

The first step is to poke into the target app’s headers, gentlemanly left intact by the unwitting developer.

$ cd Exces.app/Contents/MacOS
$ class-dump Exces | vim

Browse around, and find the following gem:

@interface SSExcesAppController : NSObject
{
[...]
    BOOL registred;
[...]
- (void)verifyLicenseFile:(id)arg1;
- (id)verifyPath:(id)arg1;
- (BOOL)registred;

What do we have here?! A (badly spelt) variable and what looks like three methods related to registration. We can now focus our efforts around these symbols. Let’s continue poking by disassembling the source code for these methods.

$ otx Exces -arch i386

Note that Exces is a universal binary, and that we need to ensure we only deal with the active architecture. In this case, Intel’s i386. Let us find out what verifyLicenseFile: does.

-(void)[SSExcesAppController verifyLicenseFile:]
[...]
+34  0000521e  e8c21e0100              calll       0x000170e5                    -[(%esp,1) verifyPath:]
+39  00005223  85c0                    testl       %eax,%eax
+41  00005225  0f84e2000000            je          0x0000530d
[...]
+226  000052de  c6472c01                movb        $0x01,0x2c(%edi)              (BOOL)registred
[...]

This is not straight Objective-C code, but rather assembly—what C compiles into. The first part of each line, the offset, +34, shows how many bytes into the method the instruction is. 0000521e is the address of the instruction within the program. e8c21e0100 is the instruction in byte code. calll 0x000170e5 is the instruction in assembly language. -[(%esp,1) verifyPath:] is what otx could gather the instruction to represent in Obj-C from the symbols left within the binary.

With this in mind, we can realize that verifyLicenseFile: calls the method verifyPath: and later sets the boolean instance variable registred. We can guess that verifyPath: is probably the method that checks the validity of a license file. We can see from the header that verifyPath: returns an object and thus would be way too complex to patch. We need something that deals in booleans.

Let’s launch Exces in the gdb debugger and check when verifyLicenseFile: is called.

$ gdb Exces 
(gdb) break [SSExcesAppController verifyLicenseFile:]
Breakpoint 1 at 0x5205
(gdb) run

No bite. The breakpoint is not hit on startup. We can assume that there’s a good reason why verifyLicenseFile: and verifyPath: are two separate methods. While we could patch verifyLicenseFile: to always set registred to true, verifyLicenseFile: is probably called only to check license files entered by the user. Quit gdb and let’s instead search for another piece of code that calls verifyPath:. In the otx dump, find the following in awakeFromNib:

-(void)[SSExcesAppController awakeFromNib]
[...]
+885  00004c8c  a1a0410100              movl        0x000141a0,%eax               verifyPath:
+890  00004c91  89442404                movl        %eax,0x04(%esp)
+894  00004c95  e84b240100              calll       0x000170e5                    -[(%esp,1) verifyPath:]
+899  00004c9a  85c0                    testl       %eax,%eax
+901  00004c9c  7409                    je          0x00004ca7
+903  00004c9e  8b4508                  movl        0x08(%ebp),%eax
+906  00004ca1  c6402c01                movb        $0x01,0x2c(%eax)              (BOOL)registred
+910  00004ca5  eb7d                    jmp         0x00004d24                    return;
[...]

The code is almost identical to verifyLicenseFile:. Here’s what happens:

• verifyPath: is called. (+894 calll)
• A test happens based on the result of the call. (+899 testl)
• Based on the result of the text, jump if equal. (+901 je) A test followed by a je or jne (jump if not equal) is assembly-speak for an if statement.
• The registred ivar is set, if we have not jumped away.

Since awakeFromNib is executed at launch, we can safely assume that if we override this check, we can fool the app into thinking it’s registered. The easiest way to do that is to change the je into a jne, essentially reversing its meaning.

Search the dump for any jne statement, and compare it to the je:

+901  00004c9c  7409                    je          0x00004ca7
+14  00004d9f  7534                     jne         0x00004dd5                    return;

7409 is the binary code for je 0x00004ca7. 7534 is a similar binary code. If we simply switch the binary code for the je to 7534, at address 00004c9c, we should have our crack. Let’s test it out in gdb.

$ gdb Exces 
(gdb) break [SSExcesAppController awakeFromNib]
Breakpoint 1 at 0x4920
(gdb) r
(gdb) x/x 0x00004c9c
0x4c9c <-[SSExcesAppController awakeFromNib]+901>:  0x458b0974

We break on awakeFromNib so we’re able to fiddle around while the app is frozen. x/x reads the code in memory at the given address.Now here’s the confusing thing to be aware of: endianness. While on disk, the binary code is normal, intel is a little-endian system which puts the most significant byte last, and thus reverses every four-byte block in memory. so while the code at address 0x4c9c is printed as 0x458b0974, it’s actually 0x74098b45. We recognize the first two bytes 7409 from earlier.

We need to switch the first two bytes to 7534. Let’s start by disassembling the method so we can better see our way around. Find the relevant statement:

0x00004c9c <-[SSExcesAppController awakeFromNib]+901>:  je     0x4ca7 <-[SSExcesAppController awakeFromNib]+912>

Now let’s edit code in memory.

(gdb) set {char}0x00004c9c=0x75
(gdb) x/x 0x00004c9c
0x4c9c <-[SSExcesAppController awakeFromNib]+901>:  0x458b0975
(gdb) set {char}0x00004c9d=0x34
(gdb) x/x 0x00004c9c
0x4c9c <-[SSExcesAppController awakeFromNib]+901>:  0x458b3475

Here we set the first byte at 0x00004c9c. By simply counting in hexadecimal, we know that the next byte goes at address 0x00004c9d, and set it as such. Let’s disassemble again to check if the change was done right.

(gdb) disas
0x00004c9c <-[SSExcesAppController awakeFromNib]+901>:  jne    0x4cd2 <-[SSExcesAppController awakeFromNib]+955>

Whoops, we made a mistake and changed the destination of the jump from +912 to +955. We realize that the first byte (74) of the byte code stands for the je/jne and the second byte is the offset, or how many bytes to jump by. We should only have changed 74 to 75, and not 09 to 34. Let’s fix our mistake.

(gdb) set {char}0x00004c9c=0x75
(gdb) set {char}0x00004c9d=0x09

And check again…

0x00004c9c <-[SSExcesAppController awakeFromNib]+901>:  jne    0x4ca7 <-[SSExcesAppController awakeFromNib]+912>

Hooray! This looks good! Let’s execute the app to admire our crack.

(gdb) continue

Woot! Victory! We’re in, and the app thinks we’re a legitimate customer. Time to get wasted and party! (I recommend Vessel nightclub in downtown San Francisco.) Well, not quite. We still need to make our change permanent. As it currently stands, everything will be erased as soon as we quit gdb. We need to edit the code on disk, in the actual binary file. Let’s find a chunk of our edited binary big enough that it likely won’t be repeated in the whole binary.

(gdb) x/8x 0x00004c9c
0x4c9c <-[SSExcesAppController awakeFromNib]+901>:  0x458b0975  0x2c40c608  0x8b7deb01  0xa4a10855
0x4cac <-[SSExcesAppController awakeFromNib]+917>:  0x89000141  0x89082454  0x89042444  0x26e82414

That’s the memory representation of the code, a whole 8 blocks of four bytes starting at 0x00004c9c. Taking endianness into account, we must reverse them and we get the following:

0x75098b45  0x08c6402c  0x01eb7d8b  0x5508a1a4
0x41010089  0x54240889  0x44240489  0x1424e826

The very first byte of the series is the 74 that we switched into 75. By changing it back, we can deduce the original binary code to be:

0x74098b45  0x08c6402c  0x01eb7d8b  0x5508a1a4
0x41010089  0x54240889  0x44240489  0x1424e826

Let’s open the binary in a hex editor. I used vim, but feel free to use any hex editor at this point. HexFiend has a great GUI.

(gdb) quit
$ vim Exces

This loads up the binary as ascii text, which is of little help. Convert it to hex thusly:

:%!xxd

vim formats hex like this:

0000000: cafe babe 0000 0002 0000 0012 0000 0000  ................

The first part, before the colon, is the address of block. Following it are 16 bytes, broken off in two-byte segments. Incidentally, every Mach-O binary starts with the hex bytes cafebabe. Drunk Kernel programmers probably thought it’d be funny. Now that we have our beautiful hex code loaded up, let’s search for the first two bytes of our code to replace:

/7409

Shit. Too many results to make sense of. Let’s add another two bytes. Search for “7409 8b45" instead and boom, only one result:

001fc90: 0089 4424 04e8 4b24 0100 85c0 7409 8b45  ..D$..K$....t..E

Edit it to the following:

001fc90: 0089 4424 04e8 4b24 0100 85c0 7509 8b45  ..D$..K$....t..E

Convert it back to binary form, then save and quit:

:%!xxd -r
:wq

And… We’re done! To check our work, launch the app in gdb, break to [SSExcesAppController awakeFromNib] and disassemble.

$ gdb Exces 
(gdb) break [SSExcesAppController awakeFromNib]
Breakpoint 1 at 0x4c90
(gdb) r
(gdb) disas

Admire our work:

0x00004c9c <-[SSExcesAppController awakeFromNib]+901>:  jne    0x4ca7 <-[SSExcesAppController awakeFromNib]+912>

Quit gdb and relaunch the app from the Finder, and bask in your leet glory.

How you can stop me

Objective-C makes it really easy to mess with an app’s internals. Try to program the licensing mechanism for your app in pure C, that will already make it harder for me to find my way around your binary. Also read this older article of mine on three easy tips—stripping debug symbols, using PT_DENY_ATTACH, and doing a checksum of your binary—you can implement to make it a whole lot harder for your app to be cracked.

A truly skilled hacker will always find his way around your protection, but implementing a bare minimum of security will weed out 99% of amateurs. I am not a skilled hacker—yet with some very basic knowledge I tore this apart in no time. Implementing the various easy tips above takes very little time, yet would have made it enough of a pain for me that I would have given up.

The Ultimate Solution For Xcode Auto-Versioning With Git

After struggling with several suboptimal solutions for years, I have finally come to find the best Xcode versioning solution for git users. First off, tip of the hat to Marcus Zarra and Johannes Gilger for posting their solutions, which inspired me in my search for the ultimate solution.

A couple advantages that make this solution better than those I’ve used in the past:

• It’s completely filesystem independent. Save for the git binary location requirement, this would work across any Mac with no additional setup. (It should also be quite easy to edit the script to detect git using which.)
• It works across clones and systems.
• Because the version is the current git SHA1 hash, it always refer to a specific commit you can get back to when debugging later.
• It processes the version number at every build immediately. Some of the solutions I’ve used in the past required a double-build, because of Xcode’s tendency to run scripts after the preprocessor. Not so here.
• No duplication of code in projects with multiple targets.
• Works for iPhone, Mac App Store and Mac apps.

So without further ado, my solution: I rely on an external target of type Shell Script which I call Versioning. Every other target sets Versioning as a Direct Dependency, ensuring its script is run before the preprocessor. Versioning contains the following Run Script:

cd "$PROJECT_DIR"
VERSION=`/usr/local/bin/git rev-parse --short HEAD`

cd "$PROJECT_TEMP_DIR"
echo "#define GIT_VERSION $VERSION" > revision.prefix

cd "$PROJECT_DIR"
touch Info.plist

In Info.plist, the CFBundleShortVersionString is set to GIT_VERSION. In the project’s main build settings, Preprocess Info.plist is turned on and Info.plist Preprocessor Prefix File is set to $PROJECT_TEMP_DIR/revision.prefix.