ۥ-!@ -$8"z.\.\\4\4\4\4\4j4.444444447(8FT8T8T8T8 _8 i8q8w8w8w8w8w8w884818\488Chapter seq chapter seq chapter copyprot Copy-Protecting Softwaretc "seq chapter copyprot Copy-Protecting Software" Introductiontc "Introduction" \l 2 This chapter considers various mechanisms to "copy-protect" software written for SIBO computers. Possible goals of copy-protection include: software should be able to run, only from the original SSD it is supplied in software should be able to run, only on one particular computer first generation copies should be allowed, but not second generation copies (ie direct copies make from the original SSD would run, but not copies of these copies) possibly, the number of first generation copies allowed could be limited. These different goals vary in their applicability to the different computers in the SIBO range. For example, software that disallowed even first generation copies would be very unwelcome on the Series 3, because it prevents consolidation - the process whereby users copy more than one different application onto the same SSD. It is unlikely that such software would sell at all well. On the other hand, this kind of strict copy protection makes more sense for the HC, and for corporate ("vertical") programs generally. At the same time, software developers may wish to apply differing amounts of sophistication in their copy protection schemes - some being willing merely to frustrate the casual would-be copier, and some being determined not to allow copying at all (if possible). This chapter does not favour one copy protection method over all others. Rather, it simply hints at various different possibilities. Software developers may find it convenient to mix and match the different proposals made, as well as others (along the same lines) that they can think of themselves. By the very nature of the subject, too much documentation would be self-defeating. Once any algorithm to implement copy protection becomes widely known, methods to defeat this algorithm may be developed and circulated. The free space methodtc "The free space method" \l 2 This method aims at strict copy protection: the software will only run if it is on the original SSD. This simple yet effective method turns one of the commonly debated 'disadvantages' of using Flash storage into an advantage. The method is based around the fact that when a file is deleted from a Flash SSD it remains on the pack taking up space but is no longer practically accessible. Assuming that an application master pack contains a deleted file, if someone were to copy this pack using the usual copy from the root including subdirectories, the resulting copy of the master pack will differ fundamentally: the deleted file no longer exists. This in turn means, rather conveniently, that the amount of free space on the pack will be different. Given the above you can then hard-code into your application a check to see if the figure for space on the pack matches the figure you expect: if it does then all well and good; else, do not allow the software to run. The way to find the amount of free space on an SSD is to call p_dinfo. For example, a program that prints the amount of free space on the disk the program was launched from: #include #include #include GLREF_D TEXT *DatCommandPtr; GLDEF_C INT main(VOID) { P_DINFO dinfo; p_dinfo(DatCommandPtr,&dinfo); p_printf("Free space is %lu",dinfo.free); p_getch(); return(0); } First generation copying methodstc "First generation copying methods" \l 2 Methods that allow first generation copies to run, but not second generation copies, rely on a separate "AppCopy" program being provided on the master SSD, in addition to the program itself. First generation copies can only be made using the AppCopy program. Copies made using ordinary Copy commands will fail. Further, AppCopy will refuse to copy first generation copies into second generation copies. Essentially, AppCopy does not make an exact copy, but changes some of the bytes in the application program. This can be done, even on Flash SSDs, provided: the original values of the bytes are all 0xff's the bytes are adjusted one at a time (assuming that a complete copy has already been made, and that this complete copy has to be altered). The last point is most important; the Flash filing system tests for the special case of only one byte being written, and in this case, alters the physical byte on the SSD. In other cases, the physical structure of the file is significantly changed. Preserving checksumstc "Preserving checksums" \l 3 Note that in adjusting bytes in a program file, care has to be taken not to disturb the code or data checksums (as reported eg by the tool edump.exe). Otherwise, the operating system will refuse to run the program, believing it to be corrupt. The checksums can be preserved in either of two ways: provided enough bytes are changed, the checksum can be left the same as it was originally rather than changing the program part of the image file, one of the add-files inside the image file should be changed (see the chapter Building an Application for details of add-files). In general, the second method is preferable. What kind of change should be madetc "What kind of change should be made" \l 3 The change made to the program file has two purposes: the file is now recognisably a first generation copy the change contains data somehow allowing this first generation copy to run, in a way preventing a straight copy of this file from running on another computer. Possible ideas on this second point include: information from an environment variable specially created on the target computer (secretly and with a random value), by the AppCopy program the date the copy was made (so that the copy will "expire" after a certain length of time) details about the low-level structure of the SSD (see below). To make the mechanism less obvious to a casual browser, any information from say an environment variable ought to be stored in the file encrypted in some way. Restricting the number of copies madetc "Restricting the number of copies made" \l 3 In order to restrict the number of first generation copies ever made to eight, say (which would not be unreasonable), certain bytes in the master copy of the program could be changed. As above, these bytes would start with the value 0xff, and would have to be written one at a time. The documentation for the product would have to state clearly that AppCopy could only be used eight times. This would have the effect of making the owner of the software most wary against making cavalier bootleg copies. This method will of course only work if the SSD containing the original copy can be written to. This will be impossible for OTP (One Time Programmable) or masked ROM SSDs. In this case, information about the number of first generation copies made could be stored in another environment variable, though of course this method would be easier to subvert. Low level SSD informationtc "Low level SSD information" \l 2 Each SSD contains a so-called "unique id" which can be used to identify it. Ordinarily, application software has no access to the unique id of an SSD. However, additional software available from Psion has this ability. Another potentially very useful piece of information would be the physical pack offset of the start of a nominated file on an SSD. An AppCopy program could create a small file on the target SSD, and then delete it, before copying the program file across. The physical pack offset of the start of the program file could then be written into the program file (possibly in encrypted form), for the program to check when it starts to run. Alternatively, information could be read from the deleted file. Again, access to this level of information on SSDs is not within the reach of ordinary application software. Contact Psion for more details of the availability of software providing information of physical pack offsets of files, etc. Copy-protection by changing the ROMtc "Copy-protection by changing the ROM" \l 2 In the case of the HC, it is possible to use the tool romwrite.exe to overwrite portions of a file custom$.dat in the ROM of the HC. See the chapter Introduction to the HC in the HC Programming Guide for details of the operation of romwrite.exe. Programs can then check that they are running on a given specified HC. To read the contents of custom$.dat, just open the file as normal, specifying the full path name rom::custom$.dat. One other possibility is to change the contents of the ROM more radically, eg placing certain software into the ROM, with a program on an SSD refusing to run unless this software is present in the ROM. For more details, again see the HC Programming Guide. General Programming Manual seq chapter copyprot Copy-Protecting Software page1 page1 page1 $uv/@.B88U   !%e f #$NORSqrBK  6709mn+189Zn !!J!K!!!!!!!""5"A""""00  ^""##$"$#$7$8$U$V$Z$[$\$]$b$c$g$h$i$j$o$p$t$u$v$w$}$$$@@#D8@HtP l y T QD>th9pKy gH; { M!D""#$$$!$S$U$_$a$l$ؿ񺵰!!!!!!!!!!!!!!Al$n$y${$}$$!!nHEADER PARA (for exaCODE PARAGRAPHHANGING BULLET LISTHANGING NUMBERED LIS Line Drawing INDENTED CODE LEFT CODE LEFT SIDE RIGHT SIDE Date printedCOLUMN 1COLUMN 2COLUMN 3LEFT CODE EXTENDED R FIGURE TITLELR but standard fontRIGHT SIDE MOVED RIGODD HEADER PARAGRAPHODD FOOTER PARAGRAPHEVEN HEADER PARAGRAPEVEN FOOTER PARAGRAPB B B B B B B F F !F( B B F B B F F F B B F B B B F B B B @F AF @F AF $8$$x$&I  h$ $8xx/!@&R@ $$8$80$8hh8(h$ (h$ p$ $ X$   $$h$h$ $(I&I (I &I2 "$ "R^kx~"$l$$Times New Roman Symbol&Arial 1Courier0elite 0prestige lettergothic 0gothicPS1LinePrinter"Helv 0AvantGarde Helvetica-Narrow0metro0presentation0APL0OCRA0OCRB Bookman emperorPS madaleinezapf humanist classic roman f roman g roman h Tms RmnNewCenturySchlbk palatino souvenir Garamond caledonia bodini university BScript @scriptPS @script c @script d@commercial script@park avenue BCoronet @script h@greekkana hebrew roman s russian roman u roman v roman w Pnarrator PemphasisPZapfChancery Pdecor dPold english Pdecor f Pdecor gPcooper black 0linedrawmath7math8PZapfDingbatsEAN pcline tech h5MS LineDraw+J_"   4RWY_dflqs~ !!! copyprot""PC$$ $#(hಅ%Y!1Alasdair MansonAlasdair Manson