Re: Protecting Software w/ Software License Keys...
Re: Protecting Software w/ Software License Keys...
- Subject: Re: Protecting Software w/ Software License Keys...
- From: David Remahl <email@hidden>
- Date: Sun, 16 Jun 2002 08:29:28 +0200
>
Le 16/06/02 1:24, Erik J. Barzeski disait :
>
>
> But also like I said: if people want to crack your app, they will. Period.
>
> I've never seen a fail-safe registration code system. They can't be done,
>
> simply because if you can create a code, you can reverse engineer a code.
>
>
Or, if your app uses the Net, check it against a list on the
>
Net (and quit immediately if you can't connect to the mother server, because
>
people can use a firewall to block your request).
I implemented a solution like that in my application Can Combine Icons 3.0
that was released about 2 days ago. I will share some of my experience with
it.
Earlier versions of CCI relied on just a serial which depended on the
registrant name. It was a very trivial algorithm (adding ascii values with
some misc additions) and was cracked as soon as the program became
reasonably popuplar (March, or thereabout). The serial appeared in the
Surfer's Serials collection.
Partially offended and partially honoured, I started working on a defence
against the leaked code. I decided on a system where on an application
upgrade, the user would have to revalidate his/her registration code over
the internet. That allowed me to blacklist codes even between releases,
should the need arise.
I implemented it using a php script on my web server. When a legitimate user
launched cci 3, this is what happens:
1). A dialog informs the user that a revalidation is required.
2). A new dialog appears with two fields, one for the name and one for the
serial. Those are already entered for the previously registered user.
3). If/when the serial and name match (according to the simple ascii
adding+extras) the Validate button hilites.
4). When the user pushes the button, the application uses NSURL to send a
query to the server, encoding the application version, user name,
localization and serial into the URI.
5). The web server retrievs this information. It checks so that the
serial/name match and checks that the name is not in the blacklist mysql
database.
6). The web server sends back a dictionary plist, encoding the following
info:
- Name
- Serial
- Md5 sum of a string derived from different things (Unfortunately I can't
be more specific)
7). When the application gets the plist, it verifies that the md5 sum
matches the md5 sum of the same concatenated string.
It works rather well, and is almost transparent to the user who is connected
to the internet.
However, I didn't want to alienate people who didn't like to have their
computer connect to my server and send information back and forth. I assumed
all my users have an internet connection (they ordered online, and got the
serial by email).
The 'solution' I came up with was to allow a secondary registration
mechanism. Instead of connecting to the internet and retrieve the
dictionary, the user would get a plist attached to the registration
confirmation. The plist could be imported into the application and verified
according to step 7 above. I managed to fully automate this, since the
registration emails are automatically generated by the same server that
hosts the validation script.
So far so good.
When I released CCI, I was curious to see how many users who were using
pirated serials were stupid enough to try to validate them against my
server. About 56 hours after the release, I have had 350 validations. Of
those, 35% were using the single blacklisted serial from Serial Surfer.
(Those users got a surprise, since the serial did not validatie, and the
banner over created icons was switched from DEMO to PIRATED ;).
I saw an immediate effect on the number of registrations. At least 7 people
have first tried to register with a pirated number and later registered. 2
of them admitted that they had done that. And - surprisingly enough - both
were very nice and applauded my 'clever' serial mechanism!
Today I went on the internet to check what the pirates were doing. I found
two requests for CCI3 serials - one on alt.hackintosh and one on the forums
of macseialjunkie.com. I replied and said that any serial posted publically
would be blacklisted within a day.
A few hours later, however, I got to witness how quick they are. On the
macserialjunkie web site, instructions for how to manufacture the ccilicense
file appeared.
Still - having instructions online for how to crack the program is not quite
as bad as having the serial in a public collection! It is more difficult for
the pirates to distribute lengthy instructions (I should have made the dict
20k instead of 1k!), and will most certainly steer off the 'casual' pirate,
looking up a serial because it is easier than going to kagi. Having spent
about 5 hours, all in all, on the registration system, I am quite happy with
the result!
However, beginning to enjoy the game, I decided (yesterday evening, european
time) to give them a run for the serials. I gave it an hour thought and came
up with a solution that I believe will be very difficult for them to conquer
without a crack applied to the program. The following is a quick outline of
the method (as of yet untried, but implemented in a non-released version of
the app).
The new scheme is based on a public/private encryption scheme. I generated a
key pair and put the private key on the web server. The web server still
gets the same URI from the client. It still returns back the name and the
serial fields, but the md5 key has been replaced with a signature field
(base64 encoded). The server creates a digest using some concatenation of a
few strings (including the name and serial) and returns the signature for
that digest. When the client receives back the dict, it verifies that the
public key shows that the private key is a likely signee.
I seriously doubt that they will be able to generate a valid licensefile
quite as easily using the keys encryption...
Nontheless - I am absolutely positive that they will have some kind of
solution out within a month. Probably in the form of a crack/patch. In the
mean time, I'm enjoying the hide-and-seek game!
/ Sincerely, David Remahl, ITTPOI
PS. Can Combine Icons 3.0.0 is available from
http://www.ittpoi.com/.
Instructions for defeating the copy protection is available from
http://www.macserialjunkie.com/. But _do_ feel free to pay for it if you
want to use it! ;-) DS.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.