Protection Methods - the underlying flaw

[Mike Trader]

First thank you to those who have helped bring me up to speed with the whole area of protection. I think I am allmost there

In writing my own version of protection I have come across one problem that is fundamental to all protection schemes - writing a file to the users hard drive.

If your protection method creates a file on the users hard drive and it is discovered and removed your protection is reset to the first time the app was run! Then the protection code writes a new file to the HD and starts all its counting and checking again!

All a user has to do is trash the file every time the trial period expires and he is done.

Is there a way to copy and modify the EXE itself to contain a number that can be checked by code in that EXE? that way the first time it is run, it could change something within itself, or append something and delete the original EXE thus providing a way to check and see if it really is the first time it is running on that machine.

I have tried without sucess to append a coded CRC to a file with:
OPEN TargetFile FOR BINARY ACCESS WRITE LOCK READ AS #100
PUT# 100, FileLength + 1, MyEncodedNumber
CLOSE# 100

Is there another way to append to a .exe?

Is there another method?



------------------
Kind Regards
Mike

[Don Dickinson]

Yes, I have done this with a shareware program I sell call CSelfX.
In order to have an EXE modify itself, I have the .exe make a copy of itself, then shell to the copy asyncronously.
The shelled copy, modifies the original exe (after it has shelled and exited, it's no longer in memory). The copy knows to modify the original because the original passes it a command line telling it to do that.
Then it restarts the orginal exe which in turn deletes the copy.

This might sound complicated ... and it is
It does work, however.

Best Regards
Don

------------------
dickinson.basicguru.com

[Matthew Berg]

Is there another way to append to a .exe?

Have you tried using resources? You could create an encrypted binary resource to store a key related to your protection scheme (or hide it in an image resource using steganography) which could then be compiled into your executable or added to the executable later on by another program. The main problem is the fact that it is also possible to update or remove resources from executables. Your program could detect if the resource was missing or changed (using a CRC check or similar method) and refuse to run or take some other appropriate action (such as record the tampering in a registry key).

If, however, the user simply deletes all the files that your application installed, you don't have any reliable way of determining whether or not the application has been previously installed other than using something like the registry.

[This message has been edited by Matthew Berg (edited April 26, 2001).]

[Paul Squires]

The worst thing about external files and registry keys is that
programs like FileMon and RegMon can quickly detect what and
where data is being written.

I too have read many, many threads from this Forum about
protection and I have come to the opinion that releasing a
DEMO version of the software, compiled without certain features,
or features limited, is the only way to prevent piracy.

A true user will want to buy your program if the demo impresses
them.



------------------
Paul Squires
mailto:[email protected][email protected]</A>

[Wayne Diamond]

In writing my own version of protection I have come across one problem that is fundamental to all protection schemes - writing a file to the users hard drive.
If your protection method creates a file on the users hard drive and it is discovered and removed your protection is reset to the first time the app was run! Then the protection code writes a new file to the HD and starts all its counting and checking again!
All a user has to do is trash the file every time the trial period expires and he is done.

When your program is first installed, have it install itself with a file that holds a value, such as "30" (we'll let the person run our software 30 times before expiring it). -- Obviously you would encrypt such data. Then, everytime the program runs, decrement that value. If the file is ever DELETED then you'll know tampering is going on (as the file should always exist - the installer put it there remember? )
Using your method, to reset the file all they have to do is delete it. Using the method i just mentioned, to reset it they just have to replace the file with the original - deleting it will trigger tamper detection. So if you use a combination of both methods you'll be throwing a spanner in the works - and that's really all you can do - try and make the cracker waste more time. You can't stop the inevitable, but the more of their time you waste the better
Also use the registry as well as files...

Best regards,
Wayne


------------------

[Mike Trader]

Don,
Very clever! I like it but how ...
"The shelled copy, modifies the original exe"
could you post a snippet of code por favor

Matthew,
I love that idea because it is there to start with, but I am new to resources, this may be a little out of my depth. How do read and write to a resource?

Paul,
I hear what you are saying but the functionality of my dll is either working or not. There are no "features" to disable. It either does its thing or it does not.


Wayne,
I like the concept but an installer ....
I read alot about installers, I d/l INNO and played with it all night. I discovered that it can install just files and not an EXE (my program is really just a dll that is called by TradeStation) but that i cannot disable the save file dialog AND specify the destination directory(s). I want to disable the save dialog cos I do not want the user to put the dll in the wrong place and/or the TradeStation file in the wrong place.

INNO just puts all files in the System directory if you disable the save dialog in the install process.

The other problem is that it is going to freak out my customers when they get into a full on Installer for a simple dll and TS study.

So is there another way to encapsulate a few files and put them in different folders when the encapsulating program is run, cos I like the idea.

To sum up, i need implementation examples or keywords to search poffs for pls

------------------
Kind Regards
Mike

[Wayne Diamond]

Mike, you don't need an install program ... as an example, just say you store your "Uses Left" count in a file called usesleft.ini , and your program is called myprog.exe - and they're the only two files in your program. You may not want to use an install program, you might just want to put it in a ZIP file - but that there is your 'installer'. What matters it that THE VERY FIRST TIME YOUR PROGRAM RUNS you know that that usesleft.ini file should exist, as it comes with the exe. If it doesnt exist, you know it's been deleted...
Basically the opposite of your method, but if you use both this method and your method together then the cracker will need to do both correctly otherwise he will trigger your tamper detection. Just another hurdle...

PS. I use CreateInstall2000 from www.gentee.com - it only adds approx 30kb overhead to the install package yet has the most features I've ever seen - it's not freeware but I still consider it one of my best buys. Inno setup added too much overhead for my liking, even though it's free.


------------------

[Steve Hutchesson]

The usual technique to prevent repeated installations is to write a key to
the registry that will remain there when the trial period is over so that if
the package is reinstalled, it will not run. It is not infallible but it
means that the cracker has to use Regmon or similar to find the key.

Another trick for date limited software is to write the expiry date into an
unused part of the PE header when the app is being installed and test it when
the app is started. You can access the memory image of the running file from
the instance handle and then add the offset of the piece of data you wish to
read to read it. After a set date, the app will no longer run.

As long as you are original in your ideas, your software wll probably remain
too complicated to crack for most people.

Regards,

[email protected]


------------------

[Peter Manders]

How about modifying a DLL just before and/or right after explicitely loading/unloading it?

Just a thought.

Peter.


------------------
[email protected]

[Frank Kelley]

The technique I have used to allow a fixed period of use of my fully functional program is to imbed the copy protection in data files created by the application. These data files contain a considerable amount of information about the user's clients...information he will not be willing to tamper with as it could cause a serious loss of revenue.

First, the information I use is encoded and further buried in "padding" that disguises exactly what part of the data contains the necessary information. The information stored includes a code for the date of installation, date of last use, expiration date (based on installation date) and a "key" identifier unique to that machine/installation. As an additional check, the information is duplicated in several data files used by the program and a "dummy" .dll is placed in the Windows system folder containing matching information (again encrypted and "padded" to diguise it).

If a user re-installs, the vital data files are wiped out--a serious financial loss! If the user backs up the data files and copies them back into the subdirectory after the re-install, the "keys" don't match and the program won't run (the install program will not re-create the dummy .dll if it already exists). If the user attempts to set the date on his system back to an earlier date, the software won't run. After the maximum number of days pass, the software won't run.

Also, to confound those who would hack into the program and "jump" over the verification checks, the program uses multiple checks throughout the code. Yes, it can still be hacked (anything can be if the determination is there), but the average user will not get that far.

No system of copy protection is perfect...it only deters the honest users. What hackers cannot provide is support and enhancements, and that's what usually compels users to pay for your program.

My .02.

------------------

[Scott Turchin]

Wayne has worked with me to make Python very protected, and while new debuggers come out all the time I personally think writing the file is still safe, HOWEVER......

First, you won't FIND my file by looking for "last modified", you may find it with a debugger of course, but I put about 150 known debuggers into my code, I check for their footprint and if they are there I simply GPF so they can't continue.....
Or exit function, or both of them....

I dont' know how secure my app is oging to be, but we're going to find out.
The code I posted was the file itself that is written.....


Scott

------------------
Scott

[Mike Trader]

This is all very interesting!

I am developing wayns idea of putting down the reg file with the installation. I am using Zip and the add on menu item MAKE .EXE. With this I can make a self extracting archive that does not ask the user for anything, unzipps to a temp file, executes a program (install.exe or whatever) and then deletes the temp file.

So in setup.exe i will get the current date and other pertinent info for the reg file and make a reg file in a folder somewhere. Then I will copy everything to its correct location.

The first time the app is run it will find the reg file and decrement the counter or whatever.

Teh reg file is encoded, but one problem still arises that is a fundamental flaw with this method. All a user has to do is run the installer again and a new current reg file is made.

aaaaaaaarrrrgh! this is conundrum like the mobius strip. It never ends!!!

so:
My problem now becomes, how to detect a prior install ..

Steve Hutchesson,
write a key to the registry ...
How? What key words should i search the Poffs datbase for? could post a code snippet?

Another trick .. is to write the expiry date into an unused part of the PE header when the app is being installed...

I really like this trick but How? What key words should i search the Poffs datbase for? could you post a code snippet? )




------------------
Kind Regards
Mike

[Borje Hagsten]

for easy registry handling, see: http://www.powerbasic.com/support/pb...ad.php?t=22943

regarding writing to exe - what happens when virus protection is
installed and active? my guess is it will scream..

question: why detect prior install? if user don't register first
trial period, or second, or third - at some point (s)he will get
tired of reinstalling and finally pay for the darn thing. most
important is to get devoted users. then to get them to pay. if to
prevent reinstall completely, you won't get as many devoted users,
= less future sales.

winzip, the most successful shareware of all times has built their
huge customer base this way. people have sometimes used unregistered
copy for years, and when nico then releases yet another new version,
many of those free-loaders finally think it's time to register. they
won't start using another zipper, because they have learned to use
and thrust this one. food for thoughts, maybe..


------------------

[Mike Trader]

Borje , i understand what you are saying. What my dll does is worth the Hassle of simply running the installer every 2 weeks. Unfortunatly I dont have the same faith in human nature and my user base is very small

So I have to prevent the possability of resetting the protection scheme with a simple re-install or deleting of the reg file

thx for the links. I will read ..... more!

------------------
Kind Regards
Mike

[Mike Trader]

I read all I could find on Register entrys. Petzold has nothing to say but in the win32 API help I found:

An application can use RegCreateKeyEx to temporarily lock a portion of the registry. When the locking process creates a new key, it receives the disposition value REG_CREATED_NEW_KEY, indicating that it "owns" the lock. Another process attempting to create the same key receives the disposition value REG_OPENED_EXISTING_KEY, indicating that another process already owns the lock

I assume that if my app is not running and owning the lock then it can be accessed by another app.

So Can FileMon or these other hacker apps delete register entrys? can a register entry be deleted by the user without these tools?

Because if so then we are right back where we started which is the underlying flaw ie all anyone has to do is delete the registry entry and re-run the installer and they are off and running again.

I cant believe all protection systems boil down to this! How does PACE work? What about writing to an unused sector on the hard drive or something. I need a way to do something that remains forever and is not completely erasable without reformatting the HD or re-installing the system software.

I begin to see why cracking software is easy. All you have to do is delete whatever the protection writes and reinstall.

Anyway back to register entrys. can someone tell me if the registry entry can be deleted easily and fill in the ???s
(great example, thx Wayne)
'---------------------------------------------------------------------------------------------------
FUNCTION PBMAIN() AS LONG
'Create new value in new key
'Setting = "Data in key" (MAX SIZE 2048 Chars) Description: ?????
'Key = "NewSetting" (Max Size ??? Chars) Description: ?????
'cMainKey = "SOFTWARE\RegistryTest" (Max Size ???? Chars) Description: ?????

IF SetRegValue(%HKEY_LOCAL_MACHINE, "SOFTWARE\RegistryTest", "NewSetting", "Data in key") = 0 THEN



------------------
Kind Regards
Mike

[Steve Hutchesson]

Mike,

Her are 3 simple programs that show how to patch a DLL file with a preset
date, a test DLL that shows how to get that date from the loaded DLL image
and a test program to run the DLL. It writes the date to an unused part
of the DOS header at offest 20 hex.

With a system this simple, it is not hard to modify if a cracker finds it
but you can complicate it a lot depending where you process the date in the
DLL. I have learnt this much that crackers hate basic dynamic string so
make sure you pull it apart at different parts of the DLL and test it in
different parts as well so it get a lot messier to break.

It can be broken but if you write it in a messy complicated manner, it will
take a fair bit of work to beat it.

Regards,

[email protected]

The patcher file.

  ' #########################################################################
  
  '                             Build with PBCC
  '                               DLL patcher
  
  ' #########################################################################
  
  FUNCTION PBmain() as LONG
  
      #REGISTER NONE
  
      LOCAL src      as LONG
      LOCAL LongDate as LONG
  
      Open "mikes.dll" for Binary as #1
        Get$ #1,lof(1),a$
      Close #1
  
      src = StrPtr(a$)    ' get string address
      LongDate = 29062001 ' date here in decimal form
  
      ! mov edi, src      ; source starting address in EDI
      ! add edi, &H20     ; add offset to patch at
      ! mov eax, LongDate ; copy date to EAX
      ! stosd             ; write EAX to address in EDI
  
      Open "mikes.dll" for Output as #1
        Print #1, a$;
      Close #1
  
      StdOut "Burrrrp ! date written to MIKES.DLL at offset 20 hex"
  
      FUNCTION = 0
  
  END FUNCTION
  
  ' #########################################################################

The test DLL

  ' ###########################################################################
  
      #COMPILE DLL
  
      GLOBAL hInstance   as LONG      ' the DLL's instance handle
  
    ' -----------------------------------
    ' set correct paths for include files
    ' -----------------------------------
      #INCLUDE "d:\pb6\winapi\win32api.inc"
  
  ' ###########################################################################
  
  FUNCTION LibMain(BYVAL hInst    AS LONG, _
                   BYVAL Reason   AS LONG, _
                   BYVAL Reserved AS LONG) EXPORT AS LONG
  
      LOCAL RetVal as LONG
  
      Select Case Reason
        Case %DLL_PROCESS_ATTACH
          hInstance = hInst       ' make DLL instance global
          RetVal = 1              ' needed so DLL will start
  
        ' -------------------
        ' uncomment if needed
        ' -------------------
        ' Case %DLL_PROCESS_DETACH
        
        ' Case %DLL_THREAD_ATTACH
        
        ' Case %DLL_THREAD_DETACH
        
      End Select
  
      FUNCTION = RetVal
  
  END FUNCTION
  
  ' ###########################################################################
  
  FUNCTION TestMe ALIAS "TestMe"() EXPORT as LONG
  
      #REGISTER NONE
  
      LOCAL src as LONG
      LOCAL dst as LONG
  
      ! mov esi, hInstance    ; get DLL image start address
      ! add esi, &H20         ; add 20 hex to it
      ! mov esi, [esi]        ; move DWORD at that address into ESI
      ! mov dst, esi          ; copy ESI into DWORD variable
  
      a$ = trim$(str$(dst))
  
      day$   = "day = "+left$(a$,2)
      month$ = "month = "+mid$(a$,3,2)
      year$  = "year = "+right$(a$,4)
  
      showit$ = day$ + chr$(13,10) + month$ + chr$(13,10) + year$
  
      MessageBox 0,ByCopy showit$,"Stored date",%MB_OK
  
      FUNCTION = 0
  
  END FUNCTION
  
  ' ###########################################################################

The program to test the DLL after it has been patched

  ' #########################################################################
  
  '                            Build with PBDLL
  
      #COMPILE EXE
  
      DECLARE FUNCTION TestMe lib "mikes.dll" ALIAS "TestMe"() as LONG
  
  ' #########################################################################
    
  FUNCTION PBmain() as LONG
  
        TestMe
  
        FUNCTION = 0
    
  END FUNCTION
    
  ' #########################################################################

[This message has been edited by Steve Hutchesson (edited April 28, 2001).]

[Semen Matusovski]

Any program protection is not effective. For example, it can't prevent that somebody, which have a legal release, will not put it into Internet together with "password".
Hardware protection (electronic keys) is more effective, but expensive.
"Mixed variant" - "password" depends of hardware (date of BIOS, HDD model and so on) works not bad, bBut this method requires to do new passwords, when customers change hardware (not comfortable for both sides).

In my opinion, how to protect, depends of certain app.
The best case, if app is designed for special kind of business - "hot phone" is the most effective method to struggle with piracy.
If app is designed for developers and enough cheap - delivery by E-Mail initial realease and - mainly - upgrades seriously helps.
For home users ... It's the most unhappy case. But not high price + mainly, printed manuals help.

Mike, can you describe a purpose of your software and potential customers ?
In this case it will be possible to give more certain advices.

------------------
E-MAIL: [email protected]

[Mike Trader]

Sure Semen,

Ehem .... My software, that I proudly created with the help of this fantastic forum, is a Dll that is called by TradeStation. It calculates fibonacci numbers (Phi and the golden mean and others) for a particular chart of market data. The way in which it does this and how it send back data to be drawn is the clever part.

So my "customers" would d/l the trial version and load the study into tradestation with import. The study calls the dll to do the fancy footwork (and the protection). They oooh and ahhh over it for 2 weeks get real comfortable with using it and then the nagging begins - hehe.

First its just one nag screen per day, Then after another week or so a nag screen every hour, untill after some period of time the nag screen comes up ever time it is redrawn (which is often). The nag screen has the timer which gets longer and longer ... you get the idea.

So then they send me an email and a check. The nag screen has a number generated by the random number generator when installed and crypted. I then create a registration number based on this and send it to them. If they re-install, or give the installer to a friend with the reg number it wont work.

My "customers" are likely to be unsophisticated with regards to cracking but smart enough to delete an obvious registry entry and or a reg file. There are alos very few of them. This is such a specialized area that it is unlikly that many people would be interested in it. Those that are will be very interested in this.



------------------
Kind Regards
Mike

[Borje Hagsten]

Semen is right. Out of about 1500 licenses sold to USA, I have 11
John Smith. While it may be a common name, I think several of those
are fake and some probably use this way to distribute the registered
version under untrackable name. Maybe not for own commercial reasons,
but among friends and in schools, etc.

In binary world, there's no way to protect 100%.


------------------

[Mike Trader]

Steve,
Fantastic! what a great example. I love it. I think that is what i ve been looking for. I can write the date in a crypted fasion when i install the dll. If no number is present the dll terminates. if they copy the dll at install it is date stamped so will fail date test later. If they re-install installer detects old Dll and fails. If they delete the old Dll and re-install ..... oh oh back to the undelying flaw.

So I guess i could use the registry to keep track of previous installs and prevent re-installing that way.

Thanks so much Steve.


------------------
Kind Regards
Mike