John:

I would be extremely reluctant to buy any such product.
In one place I worked the serial numbers changed continuously (monthly) and we had one or two vendors that stuck it to us because of a bad key they sent and we literally had to back out of CPU upgrades because they didn't have 24/7 support.

Ed

On Jun 19, 2013, at 11:17 AM, John McKown wrote:

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to