I have been trying to find a software license which, like the Creative Commons Attribution license, would let the licensee do pretty much anything with the software, except it would require attribution in a meaningful way. That is to say, documentation and/or credits of any derivative work.

The MIT license came closest to this, and it is the base on which the Azure License was written.

A good way to give attribution, as required by the license, would be a friendly “Contains code by Copyright Holder [linked]” or “Special thanks to Copyright Holder [linked]” in the about box.

Without further ado, the Azure License:

The Azure License

Copyright (c) {year} {copyright holders}

Attribute to {individual or group name} - {link}

You (the licensee) are hereby granted permission, free of charge, to deal in this software or source code (this “Software”) without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sublicense this Software, subject to the following conditions:

You must give attribution to the party mentioned above, by name and by hyperlink, in the about box, credits document and/or documentation of any derivative work using a substantial portion of this Software.

You may not use the name of the copyright holder(s) to endorse or promote products derived from this Software without specific prior written permission.

THIS SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THIS SOFTWARE OR THE USE OR OTHER DEALINGS IN THIS SOFTWARE.

http://seoxys.com/azure-license/

Plain text Azure License

I had been trying to renew the contract through the Apple Store for over a month now. However, I initially signed up through the Swiss Apple Store, and that is the only store it will let me use.

The French Swiss store is broken, and will not work at all. The German Swss store works, but will only accept a Swiss credit card. Thankfully, I do have one, but for some obscure reason, it throws an “unexpected error” every time I try to use it. It won’t let me use my US Bank of America cards at all.

I’ve called and emailed Apple’s support team many times. Yet all they tell me is that they’ll forward it to some other team, which will (after waiting another week) email me proposing that I try “emptying my browser’s cache.”

I’m kind of unsure about what to do now. With every day that passes, I miss out on a substantial amount of money. Not only that, but not having the App in the Store causes many other problems, such as breaking links from my website, and more…

Today, after three whole months in review (seriously, I’m not making this up!), they decided to finally tackle the issue and issue me a rejection for no other reason other than “because we said so.”

See for yourself.

Please note, this is for iLaugh 1.1.1. iLaugh 2.0 is still in review, as a new application, and there’s no reason it should be rejected. In fact, the premium edition has already been approved and is already live on the App Store.

Speaking of iLaugh 2.0 – the first public screenshot ever:

The general question in all of these articles is: “Can an average guy become a successful iPhone developer?”. The answer depends on how you define success, and on that topic I can speak from my own experience.

If, to you, success means making a million bucks overnight you will most likely be unsuccessful. To me, success is defined as the return on my investment (both in time and money) on the project. In my previous article, I mentioned making somewhere around a hundred dollars a day on iLaugh. However, I didn’t mention how much I invested in the project.

The first version of iLaugh and its subsequent revisions took me very little time to create. I estimate that I invested between ten to twenty hours of my time to create iLaugh 1.0. At my asking rate of $100 per hour, that represents a $1,000 to $2,000 investment. The server running the first iteration of the iLaugh API cost me about $100 per month to maintain.

If you look at the numbers for iLaugh from previous months, I make over $3,000 monthly (for a total of over $8,000 so far). Thus, I consider it a success.

Many people, in response to my previous article, said that I too, was one of the lucky ones, albeit on a smaller scale. And while that may be true, considering the low quality of that first iteration of iLaugh, a more carefully crafted app would likely have done better.

I believe the potential for success is relative to the investment put into anything.

If you look at the familiar success stories, many of them involve reinvestment and good marketing. For instance, Tapulous hit the jackpot with their Tap Tap games. Being good friends with one of their employees, I know exactly how much work goes into their production.

Perhaps one of the most talked-about success stories is Trism. Its developer, Steve Demeter, made an insane $250,000 in just two months. What I believe is the key to Steve’s long-term success, is that instead of buying a fancy sports car, he reinvested his money into founding a sustainable business.

Part of reinvesting, and a facet of development often ignored, are things that a typical developer can’t do. Most importantly: design, copywriting and marketing. These are things that will most likely have to be outsourced. Developers are reluctant to do that, because it’s very costly, but in the end, ignoring it is going to cost them the popularity of their application.

I view iLaugh 1.x as a catalyst towards bigger and, hopefully, even more successful endeavors.

In fact, I have already put a big part of my (in comparison to the numbers above, quite mediocre) earnings into the second iteration of iLaugh. I’ve hired a bunch of people much more talented than I am in their respective fields, and iLaugh 2.0 is coming along really nicely. It will be entirely different and nearly incomparable to the first iteration. There are some very cool things coming.

So, responding to my initial question: “Can an average guy become a successful iPhone developer?”. Yes! An average developer can be successful in the App Store. But it takes hard work, a lot of time, money, and perseverance.

The latter tend to blame the App Store for the failure of their application(s). Granted, the App Store is a harsh market which has both its advantages and its flaws. But, in my humble opinion, a good craftsman never blames his tools.

The App Store has trends that can be analyzed, and if you’re going to be developing for the iPhone, you need to learn how to adapt. I have learnt this first-hand through experimentation, and have learnt many valuable lessons along the way.

Last September, while working on a much bigger iPhone game, I thought it would be cool to create a quick one-trick application for viewing jokes. I never envisioned that iLaugh would become my most lucrative app that would keep me going while I develop the aforementioned game.

The Y-Axis shows daily revenue in US dollars.

Let’s leave the end of the graph (Feb-Apr) aside for a minute, we’ll get back to it.

You can see the initial release spikes, typical of the App Store, and then a very depressing downwards trend right after release. For the second release, 1.1, I upped the price from $0.99 to $1.99. Which slightly lowered the initial spike revenue. But at that stage, I had a much more mature app which unfortunately, due to lack of effective marketing stagnated at a sub-$20 daily revenue.

But in February, I made pretty much the best decision I have ever made. That, of course, was to release a Lite version. I initially thought it would be a nearly cost-free way to get some free advertising for the premium version. The main reason I put ads inside the Lite version was actually not to create revenue, but rather to give users a reason to upgrade. But, other than that, the Lite version was an identical, fully functional copy of the premium version.

As you can see, it did a pretty decent job of advertising the premium version. Since the mid-Feb release of iLaugh Lite, daily revenue for iLaugh has been much higher than it previously was.

Fortunately, iLaugh Lite became quite popular on the iTunes App Store, and while never entering the global top 100, it has charted as high as #29 on the Entertainment chart, and has been in the top 40 entertainment apps nearly since its release.

While this did have some unexpected consequences, like bringing my entire server down due to excessive traffic which brought the iLaugh service down and forced me to upgrade to a better server, the benefits were pretty clear.

This graph shows daily iLaugh Lite downloads.

This equates to about 100,000 monthly downloads.

Here’s a graph that shows the web-service traffic this generates (since each joke is fetched from my server, this gives me a pretty good overview of the actual usage of the app). Unfortunately, I only started using this particular analytics package on March 2nd, so that’s when the graph starts.

To date, iLaugh has served over 6 million jokes, and it’s going at about one million per week.

So far I left out one pretty important thing: ad revenue. But one always leaves the best for last, right? So here goes:

As the installed user-base for iLaugh Lite grows, so does daily ad revenue. Currently, I’m seeing pretty good numbers. I have around 6 million monthly ad impressions, and as you can see in the above graph, I’m seeing around $100 daily ad revenue.

While these aren’t mind-shattering numbers, I think they give a pretty good overview of what one can achieve as an average developer for the iPhone platform.

First, it’s a great feature for the user. It’s a joy to just chose a beloved track, and instantly get plenty more of that awesomeness. I’ve been a great fan of Genius myself, and I use it all the time. It’s also great when picking out tracks for a DJ set.

But what probably goes unnoticed by the general public is the staggering amounts of money Apple will be able to make of this. They will own the data to what millions of people are listening to. They’ll have direct access to millions of people’s tastes, likes, dislikes. Many companies would kill for such data, and I wouldn’t be surprised if the labels were prepared to pay big for such statistics.

Additionally, Apple is using genius to sell more music on the iTunes Store through the sidebar. The iTunes Store is already the biggest music retailer in the US, but with Genius, it’ll only sell even more music to the people already buying music on the store.

And lastly, Apple could sell promotions for artists who want more exposure for their music. Since Apple controls what users are exposed to / listen to when they’re in Genius, they can now push an artist more often in their user’s Genius lists, and thus give the user the impression and the feeling of liking the music. They can thus manipulate the user’s tastes, and I’m willing to bet that many record labels would pay big money for that kind of exposure.

A recent post by Marco Arment captured my attention.

The argument has been done to death the first season, no need to go over it again. But there’s a few things so fundamentally wrong with his argument that I have to call him out on it.

It’s the usual Phill Ryu publicity stunt that will result in a bunch of blog attention, a few developers selling licenses at very steep discounts, and a token charitable donation to downplay the hundreds of thousands of dollars that Ryu will likely walk away with.

Firstly, having worked with and for MacHeist personally, I can tell you first hand that it isn’t just a one-man show. There’s a much bigger team of Directorate, Coders, Designers and more, as you can see on their about page. Phill Ryu is best known as the public face of MacHeist, because it is his role. But by no means is it his own personal cash crop.

Secondly, specific numbers aside, donating 25% percent of revenues to charity is certainly not a “token donation.” A quarter of any revenue is not to be taken lightly. Now, granted it might be a marketing tool, but don’t let that negate the fact that charity does end up with a pretty huge donation in the end. MacHeist donated $500,000 last year, and this year looks like it might be getting a full million.

a previous MacHeist offered developers about $5,000 per application for sales that eventually grossed over $300,000

Now, this is just plain false. This is unconfirmed data and is based merely on rumors. It might very well have been the case, but do not parade it as fact, and do keep in mind that at the time a $5000 flat offer for an unknown business model that could very well end up in a flop was a pretty serious risk to take. The MacHeist guys did in fact claim that the numbers were much higher. Either way, this argument has gone back and forth enough the first season.

But the part that really gets on my nerves is this:

Their developers can tell themselves that it’s a good deal and it’s worth eating the discount to gain exposure.

We — and I say that as a developer who participated in a previous MacHeist bundle — are old enough to tell what’s good for us. What we especially don’t need is outsiders telling us we’re being ripped off. We’re running a serious business, and trust me when I say that we do not take such decisions lightly. What’s worse is that the person giving this argument is not even a Mac developer, according to his blog.

What you need to understand is that MacHeist is a business. We developers also run businesses. The keyword here is business. We don’t take these decisions on emotional value. We take these decisions because we judge that they will be beneficial to our businesses. We have to consider many things: The price of supporting and distributing thousands of licenses; (Please note that not all MacHeist sales actually mean an extra user for the developer. Many customers buy the bundle just for a specific app.) The actual (flat or percentage) monetary revenue we make out of it; The exposure we gain; The image this gives off the app.

Additionally, I’d like to prove this by giving the example of Gus Mueller. In the first season, he was offered a deal, which he declined, because he perceived it as a bad business decision. On the other head, he accepted the deal this time around with Acorn, because this time his perception of the new deal was different.

I have one thing to ask you, and that is not to believe when people tell you the developers are being ripped off. Rather make the decision to purchase the bundle on whether it has enough value for you to justify $39.

When you upload an iPhone application to the App Store through iTunes Connect, you’re presented with a few screens of information to fill in. First, there’s the screen where you put the Application’s description, category, and any other textual information about it.

Then there’s the screen where you upload the binary, the icon(s), and screenshots. And lastly there’s a screen to set the price. Unlike what I thought would be the case, you cannot chose a specific price. You get to chose from several price groups. A price group has a price in US Dollars, and a price in different currencies usually of a similar value. (For example, a $0.99 app in Switzerland is CHF 1.10)

At the top of this page, there is a little warning message that says you need a contract with Apple if you’re going to put up non-free apps. I did not pay too much attention to it, and the rest of the process seemed to go smoothly, eventually leading back to a page where I could see my app was “In Review”.

I was still slightly confused about this contract message, and decided to find out what it was about. I asked a few fellow developers, and found out that Apple would not sell my app until the contract was taken care of.

In iTunes Connect, there is a section on contracts, with a link to create a new contract. A contract is made of three parts; Contact Details, Banking Details and Tax Details.

• Contact Details

  This is very straightforward. I just had to fill in my full contact details. (Including physical address.)

• Banking Details

  This is slightly more complicated. I’m with one of the smaller Swiss banks, and I wanted to use this account for my App Store revenue.

  One of the things Apple requires is a SWIFT code. Luckily, I’m with a Swiss bank, and these tend to be very professional. I just had to give my bank a phone call, and I had my SWIFT code. However, after reading a recent topic on the MacSB mailing list, it appears to be very common for many of the smaller banks in the US and other countries not to have SWIFT codes. In which case you’re screwed and you’ll have to open a new account with a bank that has a SWFT code. (Apple recommends Bank of America.)

  Another thing required by Apple is the IBAN. International Bank Account Number. My bank informed me that they printed these on all the bank statements they issued. However, I didn’t have any bank statement around. It wasn’t too hard getting this number. Switzerland has a standardized way of building these numbers from your CB Number (Clearing Banquaire - this is what we call Branch IDs) and your account number. A handy little script I found on the web would take this info and convert it into an IBAN. (I later found one of my Bank statements, and the IBAN generated did indeed match the one on the statement).

  Apple also asked for the Branch ID (I put my CB number for this) and account number, and another number called the SIC / Short Code. I researched it a bit, and it looks like I didn’t need it. I just left that field blank.

• Tax Details

  This is where it gets nasty. Note that this is not an Apple thing, this is government tax regulation. Apple provides an online version of the government form W-8BEN. It seems I am not obligated to fill this form in, but if I don’t, Apples keeps another 30% of my revenue as anticipated taxes. This, with the 30% commission they take from every sale, leaves me with only 49% of my gross sales. (70% * 70% = 49%)

  This form is extremely cryptic, and I filled it in to the best of my knowledge. This, however, wasn’t enough for Apple. The form complained about missing information. It’s only then that I realized that Apple provides a handy tip sheet explaining how to fill the form in, and what are the most common answers.

  With this information, I was able to understand and fill in most of the form. Except for one field: Taxpayer Identification Number. Since I’m not a US resident (although I’m eligible for citizenship by blood, and plan to apply soon), I did not have this information. Apple’s tip sheet luckily had a small paragraph regarding this. An EIN (Employer Identification Number) would do. To get an EIN, I had to download another form entitled SS-4.

  This form was even more cryptic than the previous one. It is obviously made for more traditional companies, and had questions asking how many employees I have in different field, how much wages I paid them, where and when my company was incorporated, and a bunch of other tax-related questions. It also asked a few things I couldn’t fill in, such as my SSN (Social Security Number - I don’t have one). I phoned the IRS (Internal Revenue Service) - the government entity I had to submit the form to - and it turned out this field wasn’t necessary. In response to the question “Check one box that best describes the principal activity of your business”, there of course wasn’t anything about technology. I had to tick “Other (specify)” and enter “Royalties”.

  There is three way you can submit the form. Firstly, you can do it the traditional way of mailing it by post. But this would take a minimum of 4 weeks. Second way would be by fax, but this would also take at least 1 week. The third way is actually pretty clever. You fax while you’re on the phone.

  Problem: my phone and my fax are on the same phone line. Meaning I can’t do both at the same time. I do have a cellphone, but phoning oversees for a good half hour at least from a cellphone would be so outrageously expensive it didn’t make any sense. Luckily, I though of a brilliant idea, and opened a Skype Out account. The audio quality wasn’t very good, but at least it worked. After another hour of phoning, I finally had my EIN and could submit the W-8BEN form to Apple.

Everything seems to be in order as of now. My app is still in review, but expect it in the app store soon.

Part Two: Asymmetrical Cryptography

Asymmetrical Cryptographic Keys are a great way to secure you app, because the code used to generate serials is not included in your app, thus removing the risk of a keygen. Using a private key, you sign (or encrypt) some of the user’s details. You then use this singed data as the key to your software, either in the form of a serial, a file, or even an image with the data embedded. You then verify that the signature is valid using the public key in your app.

Example

Start off by generating a set of private and public RSA keys. You can do this by using the following in Terminal.app:

openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -out public.pem -outform PEM -pubout

You can use different size keys. Using a shorter key, such as 512 will make your software more vulnerable to brute-force attack, but has the advantage of making the signature smaller (Which is useful if you wish to display it in the form of a Serial Number).

I believe I used the following set of keys. The keys are also included as files in the source code of this example (available at the bottom of this article).

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAwKhjrkHmaupDGERSHdgZuSwBWBr4kufBGz0Dk5sn3PR3ZtaP
Vrv6+5Mdz1gAEBYbUVH3m+4+dHcwol5xNckKBT8M5Zy6GPoV9dBUS/1wQBzgdTzf
jvV4uE9S0pofQWw3faZ904tTOjbM0qUko2nd7yyjYBhh/m1ABEFHuL62BvRp13na
vv6534OqqeExEb9VD3K9+Rr4+YQVRUpqZSz2xwhqfLgAzFVQ9bmSG8yTVKmF/vQA
t+N8ThN2WO5qYtCbPawkmIpwvUCTXkxAiiTPNOiU3G1vwtzBoma9TL6dgGmhq6P7
0KBcQNGUEpA2PFC7MEBeNyVyiMIOAvrkHjY/VQIDAQABAoIBABUNET9EMiIykLxB
Etvx9fWWylrPL6QVsLMCOrbROEzbZYSWIzlt9uGwVIyIaBFZ6Qg8tZqTML3XHDhR
q3seCXtDRWx9cJQ0F1wxtFRNUAuhXCFTUnYzekphWIJslse2RGX1YEBSM/jjbgQC
SXuVoMt2jC9+2o5Lb7hHTcfxBsDBmZpghArT5seTOwDOOhTULqoh2wgZYB2IpgTI
UV2CPpAqRVECRnPNdE5UcNIeHc7g4aji5BO0G0u8uM4RUffuRcLaPymuxpU9vwd1
gjVaG6BF/2odW7GEBU3FNLUtvr9MxT+HC+hwOJUuk8NWxU7DqMdyiwSs7W3Nnx7R
5RPvj8ECgYEA34DZjy5EMm7QyPZA6DvAZv6RIecFEwEkwFG+mQgoCy4VfLikkwzC
bI8M8fc6Xiix7ZTjSmvuHt1D4HSRHMOVYgDzY0A5+F+8X657mN5TwNlYMOUkDX3I
rNwc3cRVqtLZYGX0H7cR6eEomGJ7fA9gKuTpaXI0IJz5DsqsgTaGvfECgYEA3Ktr
Q53i52jnssL9c3JsxQO+I/2fWKgo3bZeBI/5zLsz3itVjFjMVldrIK1QZWXI4z7l
dPYwh6qCa1unsizuuzeAhW6NcuUjGPBlBqlo/a9WfOo16ExPXBoH3PH2DXz/YS+D
DOp4Wl8ePhO7C46t3zmGahchysx3kCGkAmNkA6UCgYEA0upvZNUOemFlGiB5RC8O
9KMLJukyOqr7mZoKubOexl4o3NgKRtLlrziXyMe8Bxt0PXYhwBt2TR4Vbf3S60gO
8rte86yqiB8gT1MDRFGazATPWuUCTtECzU2y1/ztsxTjGjtcU4mZmBJpEtTtHzgL
Uq9PLbkeRCCeUD0m6ZEhOqECgYB85jFyNh1F6aSrE56tB2j1Iicu69CTN6rZwuz4
HB3BeXvkFhb3txMBE7244yAMJE5OAT2Ss/3H7AShi2EhgjklkkaWP3qkO3lgFkC4
Qo8Ad4u2bEJS105bzQgCUJl6DPPnKCM+3j98tzXA4R4PbpSPMloYFju0M4LA+6l/
CI6FWQKBgQCWr4Py/GBhgoYOlY/f41NzOfsttwcCBum3uPbiPq6gM/AQQRjzdUmK
QRgG9XXs/33KUMiU+/15hK8ShrOWRSx+zHdgeMhVmuYJdEeygANI9dkonJ3+Olth
77beMQrKIY9kw4bVRFtLWhxfAHXvnksnBg79PX05joVvoHFgVxuwlg==
-----END RSA PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwKhjrkHmaupDGERSHdgZ
uSwBWBr4kufBGz0Dk5sn3PR3ZtaPVrv6+5Mdz1gAEBYbUVH3m+4+dHcwol5xNckK
BT8M5Zy6GPoV9dBUS/1wQBzgdTzfjvV4uE9S0pofQWw3faZ904tTOjbM0qUko2nd
7yyjYBhh/m1ABEFHuL62BvRp13navv6534OqqeExEb9VD3K9+Rr4+YQVRUpqZSz2
xwhqfLgAzFVQ9bmSG8yTVKmF/vQAt+N8ThN2WO5qYtCbPawkmIpwvUCTXkxAiiTP
NOiU3G1vwtzBoma9TL6dgGmhq6P70KBcQNGUEpA2PFC7MEBeNyVyiMIOAvrkHjY/
VQIDAQAB
-----END PUBLIC KEY-----


Next, we will create the generator. We will start by concatenating the details (full name and email address) into a single string:

First Last+email@address.com

Then, we will use RSA to sign this string using the private key generated above:

lFZpwJ6GPLXz8sDez033RIxJsN072lOEa0qF+8hQ5KCcZEPQqSBU4MKbW+UJxIfSmKMOBYnVfy/wwAoSxTtqn2JIuAPEJvsTlb0mGH5u7mpxH+FDj2TicoBKephWv7UXP9k10OPA45247+j/u4yKT1UZcq7WjChQ3JoE3wBtEoFucQm8vLk/VqvNaBM1TyNEgwT8FmrKlbK1FNUI8nQ0QOEJ9P8oMAblkWE5kALZZqWnAs6xE7c73sex73t5FvxYRqRDzRDzkjTwK0anXCv8dmeLvnaaHAFcfD5llx09oa89q+wzWucE7V1TsPRYKH1sZsSz5G2xTt2pZrjIoTw5ew==

Note: for this sample app, I explicitly turned off creating newlines in the base64 signature.

The code used for this generator is:

-(IBAction)generate:(id)sender
{
    NSData *privateKeyData = [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"private" ofType:@"pem"]]];
    NSData *publicKeyData = [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"public" ofType:@"pem"]]];
    NSString *details = [NSString stringWithFormat:@"%@+%@", [name stringValue], [email stringValue]];

    SSCrypto *crypto = [[SSCrypto alloc] initWithPublicKey:publicKeyData privateKey:privateKeyData];
    [crypto setClearTextWithString:details];

    NSData *signedTextData = [crypto sign];
    NSString *string = [signedTextData encodeBase64WithNewlines:NO];

    [serial setStringValue:string];

    [crypto release];
}

As you can see, I used Septicus Software’s great SSCrypto framework for this task… It makes things so much easier… Unfortunately it doesn’t support base32 or DSA, which would both have helped make more human-friendly keys.

The other piece needed is the validator, used in your software to validate serial numbers. Include only the public key in your app, and use RSA to verify the key.

-(IBAction)validate:(id)sender
{
    NSData *publicKeyData = [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"public" ofType:@"pem"]]];
    NSString *details = [NSString stringWithFormat:@"%@+%@", [name stringValue], [email stringValue]];
    NSData *number = [[[serial stringValue] dataUsingEncoding:NSUTF8StringEncoding] decodeBase64WithNewLines:NO];

    SSCrypto *crypto = [[SSCrypto alloc] initWithPublicKey:publicKeyData];
    [crypto setCipherText:number];

    [crypto verify];

    if([[crypto clearTextAsString] isEqualToString:details])
        NSRunAlertPanel(@"Result", @"Good serial!", @"OK", nil, nil);
    else
        NSRunAlertPanel(@"Result", @"Wrong serial!", @"OK", nil, nil);

    [crypto release];
}

Important Note: In this sample code, I included both the generator and the validator in the same application. I included the private.pem file in the bundle. You should never do this. If the private key is ever leaked, it compromises the whole security of your application.

Making it safer

You can easily make it more secure by combining this technique with the technique explained in Part One. Instead of simple concatenating the details as I did here, you could use all the techniques applied in Part One, such as using a hash instead, or doing ROT13 on it, or rearranging the order of the characters.

Another thing you should do is to hardcode and obfuscate your public key. Having it as a file in the bundle makes you vulnerable to key substitution. (Basically, a cracker would replace the public key in your app by a different key they created using a private key they know, thus making their licenses valid instead of yours.)

Form Factors

While you may not realize it at first sight, this has become one of the most common methods in Mac shareware, thanks to the open-source framework AquaticPrime. AquaticPrime uses this technique behind the scenes, by embedding the signature in a plist file. AquaticPrime is a very easy way to use this. Unfortunately, if you decide to use AquaticPrime.framework in your app, it is very easy to replace the .framework file with a malicious one that will always claim your licenses are valid.

To date, as far as I know, there isn’t any HackuaticPrime.framework yet, but this might one day become a problem with AquaticPrime gaining popularity thanks to it’s extreme simplicity of implementation.

Update: Devon in the comments suggests implementing a hash check of the framework, which is a simple way of checking the framework’s integrity. Of course, there are still ways to get around it, but this makes it one step more difficult.

Another common form factor for Asymmetrical Cryptographic Keys is custom URL schemes. That’s actually a very clever and convenient way of doing it. To register, the users get to simple click on a link which looks like this: (All the user sees is a nice “Click here to register” link)

myapp://name:email:key

Another clever, but controversial form factor is Agile Web Solution’s 1Password License “Cards”.

And of course, if you find a way to make short base32 signatures (I hear DSA makes short signatures), you can even use longer Serial Numbers.

AHJ53-5HGJZ-8DG8R-284DF-56FJB-74FH4-FJUEH

Sample Code

The code used in this article can be downloaded here.
As always, licensed under MIT license. If you do use it, mention it in the About Box or readme.txt.

Part One: Serial Numbers
The next part will be coming soon.

Part One: Serial Numbers

Serial numbers are the simplest, most practical option. However, they are also the least secure. It consists of taking at least one of the customers’ details, and creating a serial number from it. The serial number is usually tied to either the customer’s name, or his email address, preferably both.

For example, let’s say the customer’s name “First Last” and his email address is “email@address.com”. The first step would be to strip his name and email address of any non-alphabetical characters, concatenate it and convert it to uppercase. (I put the email address first, because it’s less recognizable) Here’s what we get:

EMAILADDRESSCOMFIRSTLAST

Now map this string onto a XXXX-XXXX-XXXX-XXXX-XXXX key. If there are any character leftovers, just discard them. If there aren’t enough characters to fill all the Xs in, leave them as something constant. (they don’t have to be all the same, but they have to be the same for each position all the time. You could for example say you’re mapping it onto an QRST-ABCD-IJLK-EFGH-MNOP key, and leave unfilled spaces as is)

EMAI-LADD-RESS-COMF-IRST

Then, we’d apply ROT13 on it.

RZNV-YNQQ-ERFF-PBZS-VEFG

Lastly, we could replace any swearwords in the key by some random other constant text, just in case.

Another example, using a similar method: Using the same customer, here’s what we’d do. Take his details, concatenate and salt them:

First Last+random salt+email@address.com

Then, MD5 the result and add another salt:

salt+0fb61d4a0f894c63d3ddbd8388404b6c

Next, SHA1 the result:

28a8275bdcbca542f567efef9cc4db2150c38900

And finally, uppercase it and map it onto a XXXX-XXXX-XXXX-XXXX-XXXX serial:

28A8-275B-DCBC-A542-F567

When you have decided on a serial scheme, implementing it is easy. Upon registration, you take the buyer’s name and email address, and generate a serial from it. He then has to input this serial into you app, along with his name and email address. All you have to do in you app is take the name and email address he gave you, generate a serial from it, and check it against the serial he gave you.

Making it more secure

For security reasons, one important step to take is obfuscating how you create those serials, in case anyone tries to create a keygen for you app. The easiest way is adding dummy maths code in the middle of the code where you work out your serial. It will not affect your serial, but it will show up in the assembly code in case anyone tries to gdb your app (more on that in another blog post I have planned).

Another quick thing you could do is shuffle the characters a bit on a set pattern to make them less obvious.

For example you could use this pattern:

ABCD-EFGH-IJKL-MNOP-QRST

becomes

TMLN-DQGA-ISPC-BEOK-FJRH

Stand-alone serials

Sometimes, your serials cannot be tied to any of the customer’s data, for example for retail sales. In that case, you’d need a different serial scheme. You need to choose certain characteristics / rules that make a serial valid. It could be as simple as checking that the 19th character is a W.

Here’s a set of example rules you could use:

• The ASCII value of the first character of all five blocks of four characters have to add up to 100.
• The last character of all five blocks of four characters have to be vowels.
• The first character of either block 3 or 4 has to be E.
• The ASCII value to the third character of every block have to be even numbers.

In your apps, just check the serial against the rules, and if it’s correct, you can assume it is a correct serial.

For your generator, you can have a pre-made list of valid serials, and assign them to a customer or print them on a retail copy when needed. The problem with this method is that you can eventually run out of valid serials. In which case you would have to generate a new batch of serials, or reassign already used serials to a second customer.

Another (better) way of doing stand-alone serial numbers is splitting the serial number in two, and basing the second part on the first part. [thanks to tomasf from the #macsb IRC channel for this method]

For example, in a serial number ABCD-EFGH-D07A-A959-F269, separate the first eight characters from the rest of the serial:

ABCDEFGH

Salt it:

saltyABCDEFGH+123

MD5:

d07aa959f269104ab28e2a748c415c5c

Map it onto XXXX-XXXX-XXXX:

D07A-A959-F269

And check it against the second part of the serial. In this example, the serial is correct.

Part Two: Asymmetrical Cryptographic Keys
The last parts will be coming soon.