Some of the ideas deriving from the world of cryptography have application in the world of protecting the authors of computer software from the thieves who would use that software without paying the authors to do so.
It is annoying to me that there is a trend towards software only being usable if you connect to a server out there in Internet Land, and get authorization. Even if you only have to do that "the first time", it still annoys me. I pay for my software. I also have to reinstall things from time to time, when hardware breaks down. Will the server necessary to "turn on" something I've paid for still be there the next time I need to do an install? Will they refrain from demanding email addresses, pester me with adverts, etc?
No, the old model was better. Software often came in a form which could be used for a time, or with a limited feature set. If you decided it was "for you", you contacted the author, paid a fee, and received a short bit of text to be inserted in an ini file. A registration key. As long as you didn't lose the key, you could use it repeatedly, as machines fell over.
Of course, that also meant that "DirtBag University", in Podunk, could buy "one" copy, for "personal" use... and then install it on 100 machines, and send all their students home with copies to use at home, too, passing the registration key out along with the exe file.
There were (are!) steps which can be taken. And (most) of the rest of this is about them, and an exploration of how cleverness can be fun. For me at least... you'll share the enjoyment, too, I hope.
First a quick word about ini files.
"The registry" is all the rage, in Windows circles, these days. Fine for some things. Overkill for others.
An ini file is a file that goes with the main exe file for an application. Typically, it is a text file... you can read the contents with a simple text editor (The Windows (bog) standard, or Textpad or similar, if you take my advice.)
At certain points in the exe file's operation it reads things from the ini file. It may also write things to it, like, for instance, where on the screen, and how big, the user likes the window for that application.
An ini file is the logical place to put the registration key for a program.
A registration key is a string of characters which mean nothing to a human, but which a program can read and attempt to interpret. If a valid registration key has been supplied to the program, the program does what it should. If someone is playing games, and trying to "forge" a registration key, if the system is clever enough, the program will just shut down and deny use.
As mentioned above, simple registration keys are not very robust protection against thieves.
One thing an author can do to enhance the protection provided is to "tie" the registration key to some text to be displayed on the screen when the program is running. For example, the text might be " It would take one disgruntled student to "drop a dime" if that message was coming up on every screen in Dirtbag University when the program was being illegally used.
The phrase "This program licensed for the personal use of Professor Bloggs on one computer." would be supplied to the purchaser of the license along with the registration key, and it would go into the ini file along with the key.
When the program fired up, it would fetch the key, fetch the "This program licensed..." string, and compare them. In a moment, I will show how the two can be "tied". And, obviously, the program would put the "... licensed..." text on the screen.
Yes... it is possible to get "inside" a program, and knobble the "put it on the screen" part. Possible. Not easy.
So... how does it work? (We're about to get to the cryptographical matters, by the way, if you were wondering.)
We need to go back a bit in the history of Professor Bloggs' key to use the program.
When he sent his money, he also had to declare how he wanted to use the program. The vendor then, using software to make it easy, typed in the plaintext string, and indicated which program the key was for.
Obviously, real world instances of all of this involve frills and refinements, but it could all be as simple as the registration- generating- program using a "secret", fixed, encoding key, and an undisclosed cipher to transform the "... licensed..." text to an encrypted version. That, the encrypted version, would be Professor Bloggs' registration key.
He now puts the "... licensed..." text and his registration key into his ini file. When the program starts up, it fetches them both. The program has the cipher and the secret encoding key hardcoded inside it. It trys decoding the registration key. It compares the decrypt with the plaintext "... licensed..." text. No match? Shut down. Easy!
Once a program has something like the above, the vendor can put other things into the registration key. Suppose the program can be used a several different levels? (Maybe it can display images from files of various formats. An inexpensive version of the program might allow displaying, say, just JPEGs. Users who have paid more can display JPEGs and PNG files. How much a user is allowed to do can be specified with a character in the string which emerges when you decrypt the registration key. The registration key doesn't have to be restricted to only checking that the "... licensed..." text is un-corrupted.
Do you see the redundancy in the system described? There's something "extra", something "unnecessary" in the ini file.
Scroll down when you are ready to be told what it is, but maybe spotting it for yourself is more satisfying....
... The answer is just a little farther down the page now...
Yes! You don't really need to have the "... licensed..." text in the ini file in plaintext. It could just be in the registration key, just be put on the screen without any question of the program not running if it and the plaintext version didn't match.
Here are a few reasons for the "complicated" version...
What else can authors do to protect their creations from theft?
An obvious step: Arrange for the program to display a copyright notice, e.g. "This software copyright Henry Tuggey, 4/14".
Now, if that was done "the obvious way", it is not terribly difficult for a baby hacker to go into the .exe file, find "Henry Tuggey", and replace it with some other name.
But. Henry was more clever than that. "Henry Tuggey" does not appear inside the .exe file. Instead, there is an encrypted version of that text. It may be as simple as "Ifosz Uvhhfz"... each letter has been changed to the next one in the alphabet. Easy enough to see, here. Not so easy to find in 120k of object code. Even if you know the author went one letter forward, as opposed, say, to going 4 letters backwards. Once the program has "Ifosz Uvhhfz" available to it, it is trivial to display that as "Henry Tuggey" in the appropriate place.
I hope that was interesting as an example of a use for encryption? If only for "general knowledge". And if a few in a smaller universe, the programmers, feel they want to use ideas inspired by reading the above, it was worth my time to write it up for you.
It is easy to admire the rogues. And some say software theft is "okay".
But think about it: If the programmer's don't get paid for the work they have done, will they write more programs?
Have you heard of Flattr? Great new idea to make it easy for you to send small thank you$ to people who provide Good Stuff on the web. If you want to send $$erious thank yous, there are better ways, but for a small "tip" here and there, Flattr ticks a lot of boxes which no one else has found a way to do yet. Please at least check out my introduction to Flattr, if you haven't heard of it? "No obligation", as they say!How registration keys use cryptography- from the Flat Earth Academy.
Search across all my sites with the Google search button at the top of the page the link will take you to.
Search just this site without using forms,
Or... again to search just this site, use...
The search engine merely looks for the words you type, so....
*! Spell them properly !*
Don't bother with "How do I get rich?" That will merely return pages with "how", "do", "I", "get" and "rich".
I have other sites. My Google custom search button will include things from them....
One of my SheepdogGuides pages.
My site at Arunet.
--Click here to visit editor's freeware, shareware page.--
This page's editor, Tom Boyd, will be pleased if you get in touch by email.
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes. There were two "unknown attributes" in Google+ button code, two further "wrong" things in the Google Translate code, and similar in Flattr code. Sigh.