Frequently Asked Questions (FAQ)The SoftwareShield System FAQ here lists many of the commonly asked questions from our clients. They are arranged into the following categories:
Q: How does SoftwareShield compare to other software licensing products? A: SoftwareShield does allow you to activate on or off codes over the internet (with user input). SoftwareShield does allow you to create demo versions of your program for any period you wish which you can: extend by any period, change the period duration, reset to the default period or release completely - all using an Activation Code. Three example features SoftwareShield has that a leading competitor does not: 1) SoftwareShield has highly customizable and configurable software locking mechanism that the competition doesn't. We allow you to set your " System FingerPrint" options from none to any one of over 8 million different algorithmic combinations for uniquely identifying systems for which an Activation Code is designed. 2) SoftwareShield also has Activation Code "Shelf-Life" that the competition doesn't. You can make the Activation Codes you generate "expire" themselves if they are not used before their "shelf-life". Thus - codes are only good for the period you specify, (or unlimited time period if you wish). 3) SoftwareShield also has "Single-Use" Activation Codes which the competition doesn't. As their name implies, single use codes can only be input to a particular system once. These three features together can be individually turned on or off without affecting the other. There are loads of other features as well. One more thing, SoftwareShield is considerably less expensive than most of the leading competitors. Q: Are there any runtime redistribution royalties for SoftwareShield? A: No, none whatsoever. With respect to redistribution of runtime components and royalties: You may redistribute the runtime components of SoftwareShield to an unlimited number of your customers on an unlimited number of machines for an unlimited time period without any cost whatsoever to your company in the form of licensing fees or royalties. The only license restrictions imposed are those relating to development. Each developer seat, (beyond the first one which comes with the SDK) must be purchased individually. See also: End User Licensing Agreement. Q: I want to license (or copy protect) common document formats (such as MS Word, Excel Spreadsheets, HTML documents, Power Point etc.) Can I do this with SoftwareShield? A: Protecting an application from unauthorized use is relatively trivial with SoftwareShield. However there are numerous obstacles to effectively protecting common documents. PDF is one of the only common document formats which provides adequate security, however, with respect to Microsoft documents, please read the following: This situation presents numerous unique obstacles to effectively prevent un-authorized copying and distribution of these common document files. Mainly, the problem you will find is that you are relying on another application (MS Word, Excel etc). There are a few simple approaches to solve this problem, but they all have simple ways to defeat them: 1) Create a simple menu application, which simply navigates among and accesses the documents themselves. License this application with SoftwareShield by itself. Then, password protect (using the built-in Office features for example) the documents, such that the password required to open them is entered only in code (in your app) and is never exposed to the user. This way, the user may do a simple file copy, but will never be able to open it because your VB app is not present to enter the password. Problems: a) Once your app has actually opened the document for the user, there is nothing to prevent them from saving the document (through Word) to a new location and at the same time removing the password protection. b) Also, this feature is only available in some documents (e.g.: MS Word, and Excel) many document formats and host applications have no password locking feature at all. 2) Individually license each document using any built in VBA support (using a single SoftwareShield license and a single Activation Code for all). This requires that you write VBA behind each document so that when it is opened, it checks the license and closes the document immediately if not permitted or expired. Alone this approach would seem to work - but... Problems: a) Word and Excel both have settings so that you can disable any VB code inside them. This would prevent the calls to the SoftwareShield COM server to interpret the license, which would essentially defeat any licensing calls. b) It is awkward to do this in Power Point. (Although possible). c) Its impossible in many other formats (HTML etc.) 3) License your the menu app with SoftwareShield by itself, then - create a "container" file (like a resource .dll) which is compiled to contain all your Word, Excel, and Power Point documents together. Through Windows Explorer, the user will only see a single large file of an unknown format. Then, at run-time, load the file into a memory stream/buffer and load from it the document you need and start the Office application to view it. This is also very similar to another potential solution where you encrypt and decrypt the documents individually as they are needed. Either way, we have problems... Again - once started, there is nothing to prevent the user from simply saving the document in regular Office format, so they can open it (copy it) again later. If you choose to not use PDF, the best way is to port the entire content of the documents to a file format of your own which only your application can read (and write) and license that application. This removes the dependence on the external application over which you have no control and makes the documents much more secure and controllable. Q: My SoftwareShield license file has somehow become corrupted. How do I fix this? A: This can be caused by a variety of reasons. The most frequent cause is tampering with SoftwareShield license files. If you are not yet a client, or you have not yet recieved your permanent Activation Code, all you need to do is click OK to "recover your software now", then send the Authorization Request Code that appears to our support department and we will send you back a "Recovery Code". If you are already a client and you have recieved your permanent Activation Code, you can simply use this dual purpose code to recover your license. Q: Is it possible for SoftwareShield to license several plug in dlls (or other binary modules) individually, using only one license file for the complete installation? A: Yes. This is completely possible - provided that you control the source code for the plug ins, or at least the source code for the plug in loader. This is possible because each individual SoftwareShield license file may have up to 64 different Authorization Definitions inside it that can each control completely different elements of your software (including controlling individual modules or DLLs). You could program each individual module to load/execute (or not) based on its own unique Authroization Definition - from a single license file. You also have the option of using logical "groups" of modules which are controlled by SoftwareShield, allowing you to activate more than one module at a time. All from a single license file you distribute with your software. Depending on how you wish to license the modules, you could individually license 50 to 60 modules - and many times that if you license them in groups. There are many possibilities here depending on exactly how you want to license them. Q: Using SoftwareShield, can I lock my program to a specific computer? A: Yes. You may choose to "Machine Lock" your Authorization Definitions. SoftwareShield provides you with 23 different finger-print options you can set that allow you to lock the application to a specific machine in numerous configurations. As well, if you devise your own system for uniquely identifying a machine, you can easily "plug-in" your own algorithm to our FingerPrinting sub-system. You have complete control over the type and sensitivity of the FingerPrint, from just being bound to the hard-drive serial number for example to full-on locking that binds to a dozen different settings in hardware. Q: I want to implement a leased software package. Using SoftwareShield, if I have my program expire some period of time from the date it was first run, can the SoftwareShield System allow the customer to be able to revive it for another period of time by entering an Activation Code? A: Yes. You may choose "Periodic Expiry" and set it to any number of days (up to 9999 days or about 27 years, which should be more than enough). Lets call this period X days. Then, you can code your program so that the user has the opportunity to enter an Activation Code that will reset the expire period of the license through the SoftwareShield ClientProtector run-time component. This will allow them to get another period of X days of use before it expires again. You can repeat this process forever allowing you to implement a "lease period". Q: Our organization uses source control software. How do I manage my licenses for the build process of our installer? A: Most importantly - ensure that the license that is compiled into the installer package is always a distributable freshly compiled license. Once a copy of the distributable license has been opened and parsed by the ClientProtector, its contents are permanently altered and must never be deployed to a new machine. For this purpose we recommend that once your license project design has stabilized, you make a copy of a freshly compiled distributable license in a special folder named "ORIGINAL LICENSE". Never let the ClientProtector touch this original license file. This way, to test your code, you copy the original compiled license into your application directory, run your tests (which will alter the copy of the distributable license in the app directory). When you need to reset your environment, you do a clean with the SoftwareShield License Manager. This deletes/cleans all Alias files. Then, simply overwrite the distributable license in the application installation directory with a fresh copy from the "ORIGINAL LICENSE" directory and you are effectively "re-set" as though it was a fresh install. Make sure your automated build process fetches a copy of the distributable license from the "ORIGINAL LICENSE" folder to ensure a fresh license is deployed with your installer/build. Q: We build our product several times in the day. Do we have to make sure to clean the license each time I do a build and before I remove it? A: You generally only have to do a "clean" if you are actually testing the license and wish to reset your machine to "fresh". The process that the ClientProtector goes through for StartUp (and other functions) modifies the distributable license file as well as creating or modifying the alias files and possibly registry keys. The clean process simply deletes/cleans all the alias files and keys. A subsequent re-compile of the license project generates a fresh distributable license which has never been touched by a ClientProtector. These two steps allow you to "start-over" when you are testing and debugging your license code. Q: Can the Web-Activator be used without a payment gateway? A: Yes. While a payment gateway is not necessary, we still recommend an intermediate layer of any kind be used for security reasons. This intermediate layer can be either directly presented to the user through a browser (requiring thier input) or hidden from the user simply using TCP/IP HTTP requests directly to and from your application. Since any intermediate layer can be used, this can be an ASP/ASPX/JSP page such as the online verification system, e-mail address gathering system, or any other intermediary. The ASP/ASPX/JSP page links in the background to the Web-Activator, and the remits the generated code directly through its HTML presented to the user. While we do recommend an intermediate layer for security reasons, it is entirely possible for you to let the customer link directly to the Web-Activator, as long as you can also construct the URL in the correct format with the correct parameters. See the help for the URL format required by the Web-Activator. Another consideration is the parameters that the Web-Activator needs. If you are choosing to "FingerPrint" your codes (which is a form of hardware specific locking implemented in software) you will need the user to input an Authorization Request Code into the web page interface they use to verify/activate their software. This code can be retrieved from the SoftwareShield ClientProtector COM server component that is distributed/linked with the software. If no FingerPrint is used to uniquely identify the users computer system, and there is only one type of activation for the software, then this code could be implicit (it would be the same for everybody) and hence - no need for the user to enter it. However, you would still need to assemble the correct parameter string as mentioned above. Note that this doesn't mean that the Activation Code they get would not be unique. Because you could also configure the SoftwareShield license file to use a "shelf-life" for the code of a few days, all codes generated on different days would be unique. Q: Regarding the Alias License Files security, are the file accesses made in such a way as to be visible (say) via FileMon available from sysinternals.com? Is this secure? A: Yes, they are visible to monitoring software. However yes - it is still secure. Note that even if a hacker were to delete all these Alias Files, they still have to deal with the main license file, which is kept up to date with the state of the application. Also - as soon as the app is restarted and the ClientProtector can not find any aliases or the virgin installation key, the aliases are re-written. If instead of deleting them, they want to try and tamper with the files, they must first break the 512-bit BlowFish encryption (no easy task). Your software is much more likely to be attacked in other ways. Please see our Anti-Hacker Guide for more information. Q: I am deploying SoftwareShield and I am creating my installer. What file properties for the SSCProt.dll do I need to set? For example: "Never Overwrite" and/or "Permanent" in InstallShield? A: All installers are different, but follow these general guidelines: 1) Ensure the file is registered with windows. Instruct the installer to extract the registration information from the SSCProt.dll itself. This is sometimes referred to as "self-register". 2) You should "Overwrite if newer version" or "newer date" (either will suffice). This allows your installer to update the ClientProtector to the version you are deploying only if the target system by chance already has a copy of this dll and it is older than the one you have packaged. Naturally, if the target system does not have the file in the first place this is a non-issue and the file is copied in as usual. 3) You should mark the file as "Permanent". This prevents an uninstall your program from removing and/or un-registering the dll. This is important especially if the target machine by chance has another program from a different vendor that is also relying on the ClientProtector. If you allow it to be removed and/or unregistered, then the other program will stop functioning. 4) You should deploy the dll to the Windows system folder. This is not a strict requirement but is common practice. See also Deploying The License For Your Application. Q: I am developing my application with SoftwareShield, and when the object is created, I get an EOleSysError with message 'Class not registered'. What is wrong? How can I fix this? A: This error means only one thing - that the COM server that exports the class which your application imports is somehow not registered. If (somehow) the ClientProtector COM server is the offending dll then you must have somehow unregistered it or it failed to register when you installed SoftwareShield or your host application. If your installer is not built to register the ClientProtector component correctly, this error will happen on a freshly installed machine. If you somehow un register the component on your development machine, then you have somehow unregistered the server. To ensure the ClientProtector is registered with Windows either use the built-in registration function in the SoftwareShield License Manager, or to do this manually (on a test machine for example) use the following procedure: 1) Open a command prompt. (Start, Run,
then type "cmd" or "command"). regsvr32 SSCProt.dll 4) A dialog will appear indicating whether the registration was successful. This should succeed if you are in the correct directory, the COM server is in that directory and the Windows path to the regsvr32.exe utility is set correctly. You should have no trouble doing this in Win2k or XP. Q: Is it ok to have messages displayed when I am interpreting the return_code from a call to the ClientProtector? For example, an error message when their license period is expired, or if they refused to activate, or does this make it too easy for people trying to break the code? A: Everything is a matter of degree. Generally, it is necessary to display warnings and instructions on what to do. However - its a judgment call since this message can be used by a hacker to locate the source of your protection calls. Remember the golden rule about software piracy protection: "Use as much protection and anti-hacker mechanism that your particular and individual situation requires - But No More." There is always a trade-off between usability for the user and protection for you. Balancing these competing elements is important. We reccommend that you thoroughly read our Anti-Hacker Guide. Q: I am building my installer package for my SoftwareShield licensed application. What license files and components do I need to distribute? A: Make sure that Hidden Alias Files are NOT distributed with your application. They are created at run-time on the users system. There is only one exception: if you choose to use a Steganographic Alias File. If you do, this (bitmap) also must be distributed. We recommend for beginner users of SoftwareShield that you do not use steganographic alias files - thus simplifying things. This means you only have to distribute two things: 1) the ClientProtectorCOM.dll and 2) your compiled license file. (and optionally any steganographic alias files). Q: Does SoftwareShield support my customer moving their license between machines? A: Yes. SoftwareShield can easily be made to support activating a fresh copy on another machine using the same code... however, literally moving (copying) the license file will not work. They must install a fresh copy of your installer package on the new machine and activate it using a code you give them. This is a protection mechanism. Also, please see the help section on Deactivating Linceses for information on how to confirm that a single seat license has been deactivated before you issue a new code. Two key things to consider in this scenario: 1) "System Finger-Printing" in SoftwareShield is what ties an activation code to a particular machine. You would want to simply turn off Finger-Printing so the Activation Code will work on all machines thus allowing the user to install your software on a different machine in the future, and activate it using the same code you provided. Of course this assumes that you wish them to be able to do this without your support. Note that if you wanted to - you could enable Finger-Printing and instruct your customers that should they need to *move* a license that they need to install your installer package and contact you for a new code. 2) Also, if you wish for your customer to *never* need a new activation code - then you must also ensure that the Activation Codes you supply do not have a "Shelf-Life". SoftwareShield "Shelf-Lives" are a hard date embedded inside an activation code such that when that date passes on the customers system, the code will cease to function - regardless of Finger-Printing. Q: I am having trouble getting my CGIACodeGen.exe Web-Activator to run correctly. What might be wrong? A: First ensure you are running a Windows web server using IIS 5.0 or higher. The security in IIS5 is much simpler to configure, so lets start there; all you should have to do is deploy the Web-Activator to a sub-directory on your site where you allow only executable permissions. That's it. IIS6 however is locked down much more
tightly. Some of this may already be done for your server,
but just in case, we include issues which our customers
have already encountered. 3a) Click on the Default web site, right
click permissions - find the IIS_WPG Account and the Internet
Guest Account. Depending on your other settings, one or
both of them must be configured correctly to be able to
access the Web-Activator. Ensure that at least the IIS_WPG
(worker process group) has read & execute permissions.
See also: Deploying The Web-Activator. If you are still having troubles. Please contact Microsoft Support for your IIS product. Q: I want the user of my program to be able to send one Authorization Request Code and input one Activation Code to enable (or disable) multiple features of our software all at once. Can SoftwareShield do this? A: Yes. The parameter that you can send with a General Use Activation Code is 16 bits, so using the bits of the parameter as flags you can turn on or off up to 16 individual features (or groups of features) all at once. (See "General Use Codes".) A much more sophisticated way to do this is to use either a Run-Time or a Design-Time Composite Authorization Definition. Please see the help for more information on Composite Authorization Definitions. Q: Can a dishonest user defeat the license and effectively have an unlimited trial period by repeatedly creating new Windows users? A: No, but this depends on how you design your license. Note that only the first user (the one who installed the software) will be able to use the program at all (regardless of trial period) *IF* you select "User Name" in the "System FingerPrint Options" in the license project *OR* any one of the Alias Files you build into the license is a "registry" alias and is written to the HKEY_CURRENT_USER branch, *OR* uses a hidden alias in a folder which does not have the correct permissions for the subject user (such as the system folder). If you do not do any of the above - then any user can use the program. However - they will not get any additional trial period - the trial period will be unaffected by a new or different user running the program. Q: Can a dishonest user defeat the SoftwareShield System if they create a trojan ClientProtector COM object and replacing the real one with theirs which responds with affirmative answers to all the calls? A: Only if you fail to implement the checks we recommend. Note that replacing a COM server is only marginally easier than replacing calls to static functions inside your binary anyway. However - we are aware of this potential attack and describe a viable and simple defense against it. Inside your EXE, perform a CRC check on the ClientProtector COM server every time your program starts but before you actually use the system. Check the return value of the CRC check on the dll against a value you store inside your program. If they are not the same - the dll has been swapped [with a trojan COM server], damaged or altered. To make this even more secure have the value inside the program you check against be stored in three different places, and assemble it just before you use it. Further - perform the check in multiple places inside your program. A C++ example follows where, at development time, you have already run your CRC function on a trusted copy of the ClientProtectorCOM.dll file and you know it should return a value of 3070908778 : char
buffer1[25] = {'\0'}; if
(CRCCheck("SSCProt.dll") != atol(strcat(strcat(
itoa(val2, buffer1, 10), itoa(val3, buffer2, 10)), val1))) CRC-checks can be quite simple to implement. Any CRC algorithm can naturally be used. Please see our Anti-Hacker Guide for a more comprehensive look at how to impliemnt CRC checking as well as sample code. Q: I want to create a "pay-per-use" product. I want to offer an initial free number of uses to allow the user to evaluate the product. Then the product could then be topped up, rather like a mobile phone, by purchasing more uses online. Can SoftwareShield do this? A: Yes. SoftwareShield can accommodate this licensing model. There are two approaches which are somewhat different. 1) The whole application is "pay-per-use". This is essentially where a single execution of the application is considered a "use". This model is also known as an "execution limit" model or a "pay-per-execution" model. This model starts off with some number of executions allowed, and when reached, your application will not permit further executions, until "recharged" or the limit is released completely. Both of these actions can be accomplished with the SoftwareShield ClientProtector that you link to in your application. 2) A "pay-per-use" on a feature by feature basis. This model has more for you to consider but is completely available using SoftwareShield. The primary difference between this model and the one above is that you have much more fine control over what features are used in your application. Also, you can start the license with any one Authorization Definition already charged with some number of "uses". As you can see, there are a few choices that will determine exactly what the process will be to both initially activate and then subsequently add activations to your software which will need to be worked out. Regardless, SoftwareShield can accommodate the model you choose. An important choice you would have to make is whether or not to "FingerPrint" your licenses. SoftwareShield FingerPrinting essentially locks your software (and the Activation Codes you distribute) to a particular users machine. This means that your pay-per-use customer "A" can purchase uses from you, but when "A" illegally gives the Activation Code to his buddy "B", it will not work on his system at all. In fact it will only ever work on "A"s system. Additionally, due to protections built in to the SoftwareShield System (designed for your situation), "A" can only use the Activation Code you give him once. Entering it again on "A"s system will not provide him extra uses at all. This is because some codes (like the ones you will use) are marked as "single-use" codes. You can always generate "A" a new one when he decides to purchase more uses. |