Announcement

Collapse
No announcement yet.

Protection Methods - the underlying flaw

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Protection Methods - the underlying flaw

    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

  • #2
    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
    Don Dickinson
    www.greatwebdivide.com

    Comment


    • #3
      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).]
      If you try to make something idiot-proof, someone will invent a better idiot.

      Comment


      • #4
        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>
        Paul Squires
        FireFly Visual Designer (for PowerBASIC Windows 10+)
        Version 3 now available.
        http://www.planetsquires.com

        Comment


        • #5
          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


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

          Comment


          • #6
            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

            Comment


            • #7
              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.


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

              Comment


              • #8
                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]


                ------------------
                hutch at movsd dot com
                The MASM Forum

                www.masm32.com

                Comment


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

                  Just a thought.

                  Peter.


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

                  Comment


                  • #10
                    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.

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

                    Comment


                    • #11
                      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
                      Scott Turchin
                      MCSE, MCP+I
                      http://www.tngbbs.com
                      ----------------------
                      True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi

                      Comment


                      • #12
                        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

                        Comment


                        • #13
                          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..


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

                          Comment


                          • #14
                            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

                            Comment


                            • #15
                              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

                              Comment


                              • #16
                                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.
                                Code:
                                  ' #########################################################################
                                  
                                  '                             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
                                Code:
                                  ' ###########################################################################
                                  
                                      #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
                                Code:
                                  ' #########################################################################
                                  
                                  '                            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).]
                                hutch at movsd dot com
                                The MASM Forum

                                www.masm32.com

                                Comment


                                • #17
                                  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]

                                  Comment


                                  • #18
                                    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

                                    Comment


                                    • #19
                                      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%.


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

                                      Comment


                                      • #20
                                        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

                                        Comment

                                        Working...
                                        X