Anti Piracy
Due to extensive discussions on UseNet newsgroups during March of 1999, I decided to setup this section of the website. It will contain any and all information submitted relating to the prevention of software theft on Psion pocket computers. This information will almost entirely be for the Psion Series 5 (and other EPOC machines), unless submissions for other platforms (SIBO) are made. If there seems to be an interest in these machines as well, then extra sections will be added.
Note that this article has not been updated since 1999, and some information is probably either out of date or irrelevant by now (and any opinions expressed probably aren't even my own any more).
Introduction
The Psion community has always been very friendly and helpful. All of the programmers I've been in contact with are all willing to help each other free of charge. Personally, I have written applications for people simply because they requested it. I am not alone in this, and it is this spirit and attitude that have helped keep the userbase of the Psion happy with the quality and amount of (virtually) free software. The average piece of shareware only costs £10 Sterling, and considering the small number of registrations achieved by most applications, this is to be commended.
Unfortunately, this situation just isn't enough for some people. Piracy has been rife on many other larger platforms for a long time now. The Commodore Amiga was one of the worst for this, and the PC nowadays isn't much better. Just because software theft has almost become acceptable on the PC, there is a small (but growing) element of the Psion community that feels that the same should happen on their palmtops..
A Look to the Future (if piracy prevails)
Having opinions like these is all well and good. It's when people start acting on these opinions and placing requests in newsgroups for registration codes, hacks, and cracks for software that the problems start.
The problem with pirating Psion software stems from the small userbase. If one or two hundred people copy a PC program, a company may lose 1% of its sales of a piece of software. If the same happens on the Psion, then over 1/2 of the registrations may have been lost. Admittedly, that's a bit like comparing apples and pears, but all it takes is one posting of a registration code on a newsgroup and that application may lose half of its profit margin. Personally, I make next to no money out of my current software, so piracy doesn't bother me financially as much as many other authors. However, the knowledge that there are people out there willing to illegally copy my software brings a few thoughts to the front of my mind.
- Why write software for people who aren't going to appreciate it enough to spend 5 or 10 pounds supporting the author?
- Why bother making people register the software when they're going to distribute the registration codes?
- Why try and enhance my future career in computers by writing software and making no money out of it, when I could be designing websites, and making hundreds, if not thousands of pounds?
Currently I have diverted a lot of my time to websites to try and raise some funds, and if I see one registration code from any of my programs being released by someone who has paid for it, I will give up writing software for the Psion completely.
If it were just me then there would be no great loss to the Psion community. The majority of shareware authors for the Psion feel similarly though; why should they write software just so that people with no morals can have it for free? A lot of the shareware authors out there are writing programs as a second job, and quite a few more as a full time career. If they see themselves not making any profit out of this, then the chances are that they will quit and find work elsewhere.
So, if piracy continues, and grows at the rate it is currently doing, then in time one of two situations will come about. The first situation is with the shareware being given prices closer to that of commercial software to try and recoup the losses made due to piracy. The second situation is with no new software being released for the Psion at all. If this happens then the community will die out, and people will start switching to Windows CE/Palm OS where the new software is being released. Psion will then go to that place in the sky where Atari Lynxs, BetaMax video recorders, et al reside. Another point to make is that if the price of software does increase as in the first situation described above, then more people will start pirating it, and so the second situation will be arrived at whatever.
That would be a very sorry state of affairs, given the quality of the hardware, and the enthusiasm of the programmers for the Psion. (It's just a shame about the build quality, really!).
To try any stop this situaiton before it gets out of hand, the rest of this section of my website is devoted to ways of cutting down on software piracy.
Sample code for registration procedures
Every few weeks I receive an e-mail from someone asking how to write a registration procedure for their program. Every time I get one of these e-mails I write a new bit of code, a description of how to use it, and send it back to them. In return (without my asking) I usually get a free registration of the finished program. I like this situation; free software for me, a finished bit of shareware for them.
Now that I'm putting this next bit of source code on the Internet, I don't suppose I'll be getting many more free programs. Anyone who uses it is welcome to give me a code to their application though. A word of advice - you ought to change a few of the values around in this code otherwise there'll be dozens of applications all with the same registration algorithm.
A syntax highlighted version of the source code is viewable
on-line here 
.
Ways of combating hacking and cracking
It may take a little more time and effort than would otherwise be necessary to outwit the piracy, but it can be done. The methods described here will no doubt be overcome by hackers given time, but by then there should be new ways of preventing hacking available.
Registration codes
The main way of software authors getting ripped off is by the distribution of registration codes. By making it undesirable/impossible for these codes to be distributed then piracy on this front can be avoided. If the unique code given to each person registering the software is based upon the Psion's machine ID (as viewable from the Information -> Machine option on the system menus), then the code will not work on any other machines.
Psion, and many other individuals recommend against this though. Due to the shortcomings in the robustness of the Series 5, many people go through 3 or more Psions a year. They will then need a new registration code for each machine. This can only be done if you keep a list of everyone who registers your software. A downside to this is that any user could keep requesting new codes for "new" machines which actually belong to their friends. The simplest way around this is to keep a track of the machines they've been through, and require a new code to be entered for each release of the application. That way only their latest machine ID will be usable.
This method is still undesirable, as the user has to keep in contact with the author who may no longer be supporting the software. It also creates unnecessary work for the programmer. With the prospect of new PDAs being released by Psion all the time, it is also always possible that the next machine might not have a unique ID, making your software unusable.
An alternative to using the machine ID is to incorporate both the user's name and e-mail address in the registration code. Giving out codes containing your name is one thing, but giving out codes that contain a way of contacting and tracing you is another. It should be made clear to the user that this is the e-mail address that all updates to codes (e.g. for new versions of the software) will be sent.
Obtaining the unique machine ID
Every few weeks there's a posting made or a question
raised along the lines of "How do I get the unique machine ID?".
Every seems capable of using the
machineuniqueid:() command, but they don't know what to do with
the high&
and low&
values that are returned. The trick is in understanding the format of
the machine ID as displayed on the system screen (under the machine
option of the information menu). The data there is displayed as
16 hexadecimal characters. When you get the information returned from
the system procedure, the data is stored as the decimal representation
of the first half of the code (the first two 4 character segments) in
high&, and the
the second half inlow&.To convert
the variables returned frommachineuniqueid:()
into this format, you must use the hex$() procedure,
and concatenate the result. The code you end
up with should be something along the lines of:
machineuniqueid:(high&,low&)
unique_id$=hex$(high&)+hex$(low&)
The only difference between this and the code given on the system screen will then be the use of hyphens. That is most simply removed by only using the numbers 0-9 and the characters A-F when generating a code to send back to the user to register the program with.
Reverse engineering/disassembly
As RevTran became capable of dissassembling EPOC applications (as well as the older SIBO type) in the spring of 1999, a real problem has loomed on the horizon. RevTran is a dissassembler of sorts, allowing anybody to convert an application back to virtually the identical source code that was written.
A disassembler works by taking each Q-code token in the OPL application, and converting them one by one back to the representative text in the source file. Very little is lost in doing this; original global variable and procedure names are kept - virtually the only thing that is lost is local variable names. It then names these in sequence, giving a source program that is probably slightly harder to comprehend than the original, but that is still completely compilable.
To stop RevTran from working, there are two main approaches that can be taken:
- Entering invalid syntax that still compiles.
- Changing the compiled application with a hex-editor to make certain instructions invalid.
As is obvious, the first of these options is much simpler. The easiest way to do it is to create a procedure in the application that is never called, and include the errors there. That way they are never trapped during program execution. Ideas for inclusion in such a procedure are as follows:
- Undeclared variables - e.g. write a line of code such as
"x%=y%+1"wherex%andy%have not been declared either locally or globally. - Unnasigned functions - e.g. asking for the tangent of a number without
actually assigning it to a variable.
"a&=tan(50)"would just become"tan(50)". - Procedure without pre-cursors. This idea undoubtedly won't fool
any disassembler, but it's probably worth putting in for the one line
of code it'll take up. e.g. rather than the usually
"dInit ... dialog"structure, just call"dialog"on its own.
If you think you're up to the task of doing the second, then I'll leave you to it - I'm no expert on the q-code produced by the compiler. It is the only real way of stopping RevTran, however. If RevTran finds an error in a procedure, then it can usually just skip to the next procedure. Hence, any procedures you want protecting should have invalid code built into them. There are applications that are being freely distributed that alter your application so it cannot be RevTranned. The best of these on the SIBO based organisers was "RevMeNot", unfortunately this is not currently available for EPOC. Programs such as SafeOPL-32 are available, and do a reasonable job of adding security to your application. However, they mechanically substitute valid code for invalid, and a similar program can be written by a dedicated hacker that will reverse these effects. A good idea might be to use the methods described by SafeOPL-32 and then replace the valid code with random, invalid codes by hand.
As well as stopping the program from being disassembled in the first place, you might like to think about stopping it from being compiled again once it's been altered. The simplest ways of doing this are adding code to the program to make sure that the time & date of the application, and its size are correct. Such code would have to be hidden/encrypted in a way so that it was difficult to find in the program.
On a similar line, encrypting the registration procedures would make it more difficult for a hacker to either remove the code or to produce another program from it that produces registration codes for your software.
Threats
Whilst this is a nasty way of protecting your software, it may well turn out to be one of the most effective. Stating that the entry of invalid codes will result in awful things happening to the users Psion may stop some people from risking using codes they get off the Internet. Using tactics like this may scare people off from registering, or even using your program at all, though. Thankfully, if these threats are posted to the kind of places that only pirates read, then only pirates will find out about the possible problems (hopefully).
Rather than actually including such things in your program, simply claiming you have included them is an alternative. To para-phrase something I once heard on television, "If you actually do something like that, then eventually it will get found out and circumvented. If you claim to, but haven't, then people will keep searching". If I remember correctly, it was Michael Garibaldi (Jerry Doyle) on Babylon 5.