Perhaps the "simplest" way would be to somehow have an entire subroutine encrypted. The subroutine would be "self relocating" in order to avoid address constants. The encryption key would be somehow tied to the CPUID and the date. When you get a new key, you also get a new encrypted subroutine. The main code does a STORAGE OBTAIN to get storage, reads and decrypts the subroutine into to. Then addresses the subroutine via a special "call" macro which gets the address via a name/token pair.
Personally, I would likely do what I've seen a book publisher do. Each book is subtly different in inconsequential ways. But he can do a SHA-1 on the book, compare against his database, and find the purchaser. Although, IANAL, this would most likely hold up in court. Maybe not for a single second user. But for 10s or 100s? Sure. IBM, or other vendors, could do the same. Generate a passcode of some sort. This passcode would influence the resultant object module in ways which do not affect its results. Keep a SHA-1 of the program objects. At execution, check the SHA-1 in various places along with the passcode. If something doesn't match, give some spurious error message which is documented like: "Serious internal error detected. Contact support. Code=..." Let them report themselves. On Wed, Jun 19, 2013 at 11:03 AM, Paul Gilmartin <paulgboul...@aim.com>wrote: > On Wed, 19 Jun 2013 08:42:10 -0700, Charles Mills wrote: > > > >- ... (assuming he had write access to the load library, or to > "protected" memory). > > > Il va sans dire. > > >- Our "key" (licensing, whatever you want to call it) is definitely > "protection by obscurity." If you knew exactly how it worked, you could > defeat it, and run our product forever on every mainframe in the world. > > > Is there any licensing scheme for which that is not true? > It can be as simple as zapping a mask in a branch taken > when validation fails. > > I imagine encrypting the executable code, and letting the preamble > "call home" to get the current day's decryption key. But I still see > holes. > > <STRAWMAN>Or run the entire application in "the cloud", where the > vendor could retain control.</STRAWMAN> > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
