Bob wrote: > Limiting the program to a memory card is the same as limiting the program > to specific device. A device that has a ROM Serial Number is a more > better solution.
In a purely practical sense, a single solution like a ROM serial number is NOT a good solution. The reason is, in a 68k app at least, the only way to access a serial number is going to be through a system call, and that means a system trap. And THAT means that since it's the 68000, it's going to have to be an A-line instruction. (Traps are missing opcodes, and Motorola reserved the opcodes 0xA000 through 0xAFFF for use as system traps or whatever else the operating system wants them to be.) So, for example, FrmDrawForm() is 0xA171. Let's say for the sake of discussion that the hypothetical call SysGetHwSerialNum() is trap number 0xA833. And let's say that suddenly everyone modifies all their Palm apps to use this new "secure" method of locking the software to the device. Well, what have we accomplished? Now it's trivially easy to locate the registration logic within the machine language of an app! All you do is search for A833 within its code resources. And the worst part is, if everyone did move to hardware serial numbers, they'd all be using the SAME method of protecting their software. You could practically write a program that would AUTOMATICALLY crack all Palm software! The situation right now is a bit different: everyone uses a slightly different method to protect their software. So there is no one hex code that you can search for in order to locate the registration logic. You have to start all over again to figure it out for every separate app. In this sense, diversity and variation are good! - Logan -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
