Conference noted::hackers_v1

    A cleverer technique is for the program to checksum itself to detect if
    Patches are added, however that can be defeated by a patch into VMS
    itself to return the expected value when the process uses the
    appropriate system service (assuming that you know a SID that works).
    This doesn't even require analysing the program. I once worked out how
    to write a program that implemented a SET SID=xxx command (on a per
    process basis of course!), that would affect the GETSYI system service.

    If the program is constrained to use system services then I dont
    see how it is possible to protect it from a sufficiently determined
    user who has the ability to modify VMS (apart from encrypting the
    file and asking the user to type in some password).

    Andrew Palka

    The SID register in VAXen is not unique from machine to machine. Check
    the architecture handbook (I think) for details, but if you are going
    to depend on the SID register, you will be disappointed. 
    
    	Jon

    	If it's running in a networked environment, isn't the
    network address unique?
    
    -mike z

    	*ANYTHING* in software can be defeated by a determined hacker.
    Since every bit of your code is available on disk to patch and dump
    utilities every code path in it can be traced and analysed, and
    anything that relates to piracy protection can be removed. If you
    want to make it more difficult than just incredibly tedious for
    a hacker, then your package must incorporate tamper-proof hardware.
    
    	In fact,  you face two different and very difficult problems.
    Firstly, the machine must have some unique hardware characteristic,
    otherwise there is no way the software can tell it is being
    run on a different machine. Secondly, the software must not just
    check for the hardware characteristic, since any check can be found
    and patched out - its very function must rely on the hardware
    characteristic to produce the correct results if you want to be
    really sure.
    
    

    re .3 Yes there is a unique ethernet address for every ethernet
    adaptor, however I can still patch the driver to return the value
    that the program is expecting. It would be a bit harder if the program
    determines the DECnet address (which is unique within a single decnet),
    but it could still be done by changing logical names or patching
    the decnet software.
    
    Andrew

    ... that locks only keep out honest people (to quote my father).
    In my PDP days, we got some software that had to be installed with
    a supplied program.  The program took the system time, mashed,mangled,
    and rotated it, then produced a number which you would provide to
    a person you called.  They would give you the password for that
    particular number.  Once we discovered this, we shut off the system
    clock after setting it to a given value (this particular 11/23 let
    us do this).  We installed it several times.
    
    						Dave()
    

    How about a software key like that used in DECnet and Asymmetric
    multiprocessing, but, have this key only usable when certain hooks
    are in the layered product. When the key installs is should smash
    the hooks in the layered product and then smash itself.
    
    I always have liked the brute force approach. I admit this is not
    elegant or will it be successful in all cases.
    
    Warwick.

    	Any hacker worth his salt normally writes self-modifying code.
    Everyone knows it is always more efficient than something intelligible!
    No good hacker will be inconvenienced in the least by having to
    decipher it.
    
    	On the other hand, it could be difficult for DEC engineers who
    are trained to write maintainable code.

.0>    I would appreciate hearing any comments on implementing
.0>    piracy protection under VMS.

    If you are asking for something foolproof then you are asking
    for the impossible.
    
    On the other hand, you might be able to gather a Houseful of Hints
    from Hackers, containing Good Things To Do To Secure Your Software,
    not to guarantee success but rather to make security-cracking so
    difficult that the cost of breaking is exhorbitant.  This I believe
    can be done.  Remember that it is easy and fast for a user to PASS
    a thousand security checks, so you can layer them in a variety of
    places, to be executed at convenient times.
    
    Some things to consider adding to your working code:
    
    check_0:	(See below)
    
    check_1:	Do a straightforward compare as in .0, with a fail-branch
    		to you_lose_1.  Otherwise, continue with user execution.

    you_lose_1:	construct ^X 06BC7E7C (say, via MULL3 #12,#9418037 or
    		something more devious) at around 6(SP) and jump to it.
    		This is a $DELPRC call.  Of course, you should also zero
    		most of the user stack, leaving a few red herrings.
    
    check_2:	See if check_1, you_lose_1 and environs are intact.  If so,
    		proceed with execution.  Otherwise, the user is on to you.
    
    you_lose_2:	Now you can be really nasty.  You may even have privs.
    		I suggest among other things you put something convenient
    		in P1 space (CTL$A_COMMON+mumble perhaps) to indicate
		that you got here.  Check this back at check_0 and change
    		program behavior entirely.  In other words, after one
    		attempted illegal execution you "lock" the process from
    		further execution, forcing the user to log out and back
    		in again before making it to check_2.
    
    Is this on the right track?  I'm sure readers have lots of suggestions
    along these lines, but is this what you are prepared to implement?
    
      John

    RE: Using System IDs                      
    
    At a previous employer, we had a third party package, "TEL-A-GRAPH",
    that checked the SID.  At one time we had some flukey hardware problems
    and field service ended up replacing CPU boards and backplanes.
    Our SID ended up changing and "TEL-A-GRAPH" would no longer work.
    So we go from users screaming "When's the VAX coming up?!" to "How
    come TEL-A-GRAPH does not work!?".  This did wonders for customer 
    relations.  
    
    RE:  Using Patchs ala DECnet
    
    Anyone can get the DECnet patch off the distribution tape.  They
    can then modify  it slightly so that they have a new patch that
    does the same thing.  So this patch can now be used to "legally"
    run DECnet.  In the past I have seen these "How to Get DECnet for
    Free" patches available from hacker sources.
      
    Copy protection measures can be by-passed easily.  All they
    do is cause a pain for the honest users.
    
    The moral is:  Paranoia will destroy you. 

    Umm, yes, please don't succumb to the urge to 'do nasty things'
    when your hack detector gets triggered.  There are always ways that
    other things (bit rot, trashed pointers, phase of moon, whatever)
    can cause the same results.  I lost my warm fuzzies over a new macro
    assembler when I found the string "Christ is the answer" in a
    relocatable file when I was trying to get the date and time stamp
    options to work....  Please, no tricks!  Besides, you (and DEC)
    can be liable for 'bad things happening', even to pirates.
    
    Willie
    

    re: .10
    	Minor changes do not protect you from copyright law and make
    anything "legal". This is why DEC is still paying royalties to AT&T
    for Ultrix sales, even though the changes from anything produced
    by AT&T are far from minor. In fact, *publishing* a modified DECnet
    key would probably be easier to prosecute in most countries than
    illegal use of the original key. I suggest you try reporting the
    cases you see to your local DEC legal department for an opinion.

    Re: .11
    
    I absolutely agree that DEC the company should do nothing other
    than report "expired license" when the situation arises.  However,
    this file discusses hacking in general, not corporate poilcy.
    
    Suppose you were a 3rd-party software house selling some code, 
    call it DECwhiz, and depended on DECwhiz for your livelihood.  Then I
    maintain you might be a bit more concerned about copy protection. 
    You might even rationalize the power to do nasty things when you detect
    that (a) a license has expired and/or this system is not licensed to
    run your program AND (b) somebody has patched your software to bypass
    primary checks.  What you do then is up to you, and may influence
    your reputation as a DEC supplier.  But at the very least you ought
    to know what sort of traps you can set and what kind of Bad Things
    you will and will not do.
    
      John

    Thanks for all the responses so far.  I have been reading
    them, but haven't replied because I could not add any
    value.  (Perhaps a new trend in NOTES?)
    
    We never thought of doing anything malacious when the
    software expired.  We would simply like to be able to give
    customers' demonstration software with a 'time-bomb' and then
    encourage them to buy the product when their time is
    exhausted.