PC Shareware 1999 March/PCShareware-3-99.iso/IMPLE/DJGPP.RAR/DJGPP2/CRCLOCKS.ZIP/CRCLOCK.TXT

Text File | 1997-07-31 | 25KB | 498 lines

┌────────────────────────────────────────────────────────────────────────────┐
│ CRCLock Copyright (C) 1997 Jonathan Thorpe. Cause & Effect Industries.     │
│ User Documentation Revision 1.9, Program Revision 2.4                      │
│ ShareWare Version.                                                         │
└────────────────────────────────────────────────────────────────────────────┘

┌──────────┐
│ Contents │
└──────────┘
[ 1] Terms of Usage.
[ 2] What is CRCLock?
[ 3] Features.
[ 4] How does CRCLock work?
[ 5] How safe is CRCLock?
[ 6] The Armorment Levels.
[ 7] Pitfalls and Weaknesses.
[ 8] Improvements in the Pipeline.
[ 9] Using CRCLock in a Program.
[10] Compiling under GNU C (DJGPP).
[11] Setting the CRC with CRCLock.
[12] Error Messages.
[13] What is BOSS?
[14] Reporting Problems.
[15] Official Copyright & Disclaimer.

┌────────────────┐
│ Terms of Usage │
└────────────────┘

  At the current time CRCLock is not a Freeware product, CRCLock is a
Shareware product meaning that you have the right to use it for up to 30 days,
after which if you still wish to use CRCLock, you are obliged to register it.
The registration terms and prices are as follows and a complete list of up
to date pricing terms can be found at the CRCLock web site at:
http://www.users.globalnet.co.uk/~jpt/CEI/cei.html, alternately you can link
to this page by going to http://www.users.globalnet.co.uk/~jpt/index.html.

Pricing:

┌──────────────┬───────────┬─────────────────────────────────────────────────┐
│ Personal Use │Free       │You can use CRCLock indefinetly and for free, as │
│              │           │long as you do not re-distribute your programs to│
│              │           │other people and/or sell it on for a fee.        │
├──────────────┼───────────┼─────────────────────────────────────────────────┤
│ Freeware     │Free       │Seen as though your're not making any money,     │
│              │           │neither will I. If you use CRCLock in a Freeware │
│              │           │program, that's fine by me and no fee will be    │
│              │           │charged.                                         │
├──────────────┼───────────┼─────────────────────────────────────────────────┤
│ Shareware    │£10.00     │If you use CRCLock in a Shareware program, you   │
│              │           │are obliged to pay £10.00. This is an            │
│              │           │insignificant fee to provide you with piece of   │
│              │           │mind, especially if your registration fee is much│
│              │           │higher than mine.                                │
├──────────────┼───────────┼─────────────────────────────────────────────────┤
│ Commercial   │Negotiable │If you wish to use CRCLock in a commercial       │
│              │           │program then the registration price will vary    │
│              │           │depending on the volume you are intending to     │
│              │           │market and your financial status. For example, a │
│              │           │company will have to pay a greater fee, than a   │
│              │           │standalone person attempting to start a          │
│              │           │commerical venture.                              │
└──────────────┴───────────┴─────────────────────────────────────────────────┘

Please go to the CEI website and then to the CRCLock link to find the real
mailing address for payment. Send some e-mail with your registration request
to [e-mail] and payment plans will be returned to you as soon as
possible.

  In order to use CRCLock in your Public Domain, Freeware, Shareware or
Commerical programs there are no special regulations that must be met except
that you are not allowed to reverse engineer, disassemble or otherwise modify
the CRCLock code (in this case CRCLock refers to both the master setting
program as well as the mobile code). If you are found to have violated the
terms stated above then you can expect full legal action to be taken against
you at the earliest opportunity of the author. Also note that the author
cannot be held responsible for any damage caused to your system or data
via the direct or indirect use of CRCLock. By using CRCLock in a program,
you are acknowledging and aggreeing to this license aggreement.

┌──────────────────┐
│ What is CRCLock? │
└──────────────────┘

  CRCLock is a security utility that allows you to add validation security
checks to your own C / C++ and GNU C programs, so that you can make sure
that your code has not been infected with a virus, or tampered with in some
other way, e.g. Reversed engineered by some would be hacker who wants to get
past your copy protection.

┌──────────┐
│ Features │
└──────────┘

- 3 Levels of Security Armorment.
- Employs Proven and Very Secure CRC Locking Techniques.
- Fast.
- Provides Filename Authenticity Checking.
- Provides FingerPrint Validation Checks.
- Provides CRC16 and CRC32 support.
- Provides protection to any Overlay data that is appended to the EXE.
- Provides support for 16 and 32 bit compilers including DJGPP v2+.

┌────────────────────────┐
│ How does CRCLock work? │
└────────────────────────┘

  CRCLock works on the well proven Cyclic Redundancy Check (CRC) theory.
This technique creates a value that corresponds to all the bits of all the
bytes contained in your source program, based upon a master equation which
can be of varying accuracy. By default CRCLock uses a 4 polynomial equation.
However, it is perfectly feasible for the user to modify this master equation
for their own uses to reduce the risk of CRC duplication, and further increase
the uniqueness of their own program.
  The advantages to this technique are that if any single bit in your program
is changed, it will completely change the output value created by the CRCLock
code. This effect is further amplified by the back propogation technique that
CRCLock uses to calculate its CRC's.

  CRCLock provides its security to your programs by creating a security
FingerPrint which is completely unique to your program. This FingerPrint
contains all of the necessary information that CRCLock requires to determine
whether the file is unchanged or not.

┌──────────────────────┐
│ How safe is CRCLock? │
└──────────────────────┘

  CRCLock comes with 3 main levels of security (Minimum, Standard and Maximum)
Each different level of security has different advantages and disadvantages
and it is up to you to decide which is best for your program.
  Even under the minimum security setting CRCLock is still very strong, and
it would take the talents of an experienced debugger (hacker) to modify the
code in order to circumvent CRCLock. To help make this hacking process harder
CRCLock implements what I call modular encryption.
  This is down to how CRCLock calculates the CRC and armors its FingerPrints,
instead of using just one function (procedure) to calculate the CRC, the
process is split into many different functions. This means that instead of
just redirecting one calculation routine the hacker must redirect them all
and then redirect the modular validation routines before they can bypass
CRCLock.

  You may be thinking "Why can't the hacker just modify the FingerPrint?".
Well, quite simple they could, but the FingerPrint itself is armored. :)
So, changing the FingerPrint would be a major feat of hacking, as with all
security programs it would eventually be possible (by the use of brute force
electronic methods) to break the locking method. This is again where the
various levels of armorment come into play, in the standard and maximum
armorment modes the FingerPrint itself is also protected against modification,
so even if a hacker did break the CRCLock FingerPrint Armorment and change the
embedded CRC, CRCLock would detect a FingerPrint Violation and fail. Either
way the tampering has been detected and your code is safe.


┌──────────────────────┐
│ The Armorment Levels │
└──────────────────────┘

  You can lock your files using 1 of 3 different methods as mentioned earlier.
They are:
 1 - Minimum Armorment,
 2 - Standard Armorment,
 3 - Maximum Armorment.

Minimum Armorment:

 Minimum Armorment provides basic level protection for your programs. It is
very fast at execution (practically un-noticable) even on large files.
It provides a 16 bit CRC lock out and is very useful for small files where a
large size increase in the main code would annoy you.

Standard Armorment:

 Standard Armorment provides a good general protection method. It implements
a 16 bit CRC as with minimum armorment, but it also provides filename security
and FingerPrint validation checking. This armorment level is again very fast
(although it is slightly slower than minimal armorment) and provides good
security.
 Filename validation is a feature that you can use to determine whether
somebody has attempted to rename the master EXE file for your program to
pass it off as one of theirs. If they have you can abort execution.

Maximum Armorment:

 Maximum Armorment provides the ultimate in security protection for your
programs, at a cost. Maximum security FingerPrints are much bigger than
minimum security FingerPrints and Standard FingerPrints. Also the time
required to calculate a Maximum Security FingerPrint is slightly greater than
that of a standard FingerPrint.
 Maximum level armorment provides:
 - A 32 bit CRC (no change gets through this),
 - Filename Validation,
 - FingerPrint Validation,
 - Much better security on large files (550Kb plus).


┌─────────────────────────┐
│ Pitfalls and Weaknesses │
└─────────────────────────┘

 16 bit CRC's are very safe, however, there comes a point in the locking
process were the CRC value becomes overloaded and the register is reset by the
CPU. When this happens the CRC is reset to zero and processing continues until
the whole file has been processed. In the end the final value left is the CRC.
This resetting effect means that it may be possible for tampering made to the
file before the reset to be missed by the locking mechanism.
 This resetting effect is extremely unlikely to occur and cause any problems
because if the file is tampered with before the reset, the reset will occur
at a different point in the file, therefore changing the final CRC, which
allows CRCLock to detect the tampering.

 However, it was appreciated that this effect may disturb some users and so
the option of a 32 bit CRC was added to the maximum armorment settings.
The above effect is much more likely to occur on large files and so if your
file is rather oversized and you can afford the extra FingerPrint space then
use the maximum armorment settings.

Pitfalls:
 Choose your armorment level carefully. Applying maximum armorment to a file
that requires a very fast start up time is silly. This is because the maximum
armorment takes longer to calculate its 32 bit CRC and perform all of its
other validation checks before it will allow execution to continue.
If you need a fast start up time, then you are much better off using minimum
armorment which has no additional checks.
 Other potential problems that you may run into with CRCLock are in the field
of executable compression. Executable (EXE and COM) compressors cannot be
run on any file that is going to be protected by CRCLock. This is because
once the file is compressed, CRCLock will no longer be able to recognise its
TagID and so it will have no way of determining how to lock the file.
 As hope for the future, I am currently working on a version of CRCLock that
can provide limited protection for files that are protected by executable
compressors, however, this revision of CRCLock will not be available for some
time, and will only be available to registered users.

┌──────────────────────────────┐
│ Improvements in the Pipeline │
└──────────────────────────────┘

- Variable CRCID Initialisation String for Custom Setup.
- Variable Size Polynomial Equations for Unique Custom CRC Tables.
- Anti-Debugger Technology for the Mobile Code including:
- Turbo Debugger Detection,
- SoftIce Detection,
- Instruction Trace Detection,
- Stealth Mode to catch Interrupt Re-Vectoring.


┌────────────────────────────┐
│ Using CRCLock in a Program │
└────────────────────────────┘

  To integrate CRCLock into one or more of your programs you need to do
several things. First of all, you need to add the "crclock.h" header file to
your code. Once this is done, you then need to tell CRCLock to scan your
program on startup. It is recommended that you make CRCLock the very first
function in your program to execute, that way you can guarentee no malicious
code is running before your program bothers to check whether it has been
tampered with. Once all of this is done, you're nearly there, all you need to
do now is compile your program and add the mobile code for CRCLock to the
compilation sequence. With Turbo C++ 3.1, this is accomplished as follows:
"tcc -ml -2 myprog.cpp clcodel.obj"
  This will execute the Turbo C compiler, compile your program (myprog.cpp)
and then it will add the CRCLock code for you (clcodel.obj) and resolve any
inter-program references that my exist. You can add any compiler optimizations
that you want to the command line in order to speed up the your code, CRCLock
should be unaffected.
  The last letter of the mobile code name (l in the example above), is the
memory model that the mobile code was compiled with. So in the above example,
"clcodel.obj" was compiled using the Large Memory model. The other memory
models are supported in a similar fashion. For example to compile the above
in the Compact memory model do the following:
"tcc -mc -2 myprog.cpp clcodec.obj". This only applies to 16 bit compilers
or a compiler that is creating real mode code for you. 32 bit and protected
mode compilers don't use memory models as such (technically they do, but they
only have one, Flat mode, so there easy to support).

So to sum all of this up, do the following:
1) Add the "crclock.h" header file to your code.
2) Add code to startup CRCLock and perform checks.
3) Compile code with CRCLock Mobile Code linked in.
4) Run CRCLock itself, to install a FingerPrint into your program.

 Your program is now ready to run on it's own completely standalone without
risk of anybody tampering with it.

For more information or if all of this seems a little daunting, see the
provided example program called "myprog.cpp".


┌───────────────────────────────┐
│ Compiling under GNU C (DJGPP) │
└───────────────────────────────┘

  To compile your program under GNU C (DJGPP), you need version 2 or better
of the program. CRCLock has not been tested on any version prior to 2 and it
has not been tested on the beta versions of DJGPP v2.0 either. However, to
compile your program under DJGPP, you do much the same as above for other
compilers. First of all add the header file to your program then type the
following at the command line:
"gcc -m486 -O2 myprog.c gnucode.o -o myprog.exe"

  This will generate a standard stubbed GNU C 32 bit protected mode executable
using 486 processor optimizations (this is the most advanced processor
supported by DJGPP v2.0), using an optimization level of 2 and the output
file will be "myprog.exe". All that's left for you to do now is set the CRC
with CRCLock and pick an armorment level.

*** Please note that DJGPP *MUST* have the mobile code and other libraries
*** that are to be linked to your program passed as the LAST parameters on the
*** command line. This is a compiler quirk and not a problem with CRCLock.
*** If you experience problems getting CRCLock to link in with your code,
*** try rearranging the order in which the libraries are linked in.

┌──────────────────────────────┐
│ Setting the CRC with CRCLock │
└──────────────────────────────┘

  After compiling your program and linking in the CRCLock mobile code, if you
try to execute it you will be greeted with a message that states that your
program has not been locked by CRCLock and then you are promptly returned to
DOS. Don't worry, your program isn't broken. What has happened is that the
mobile code of CRCLock has detected that it hasn't been locked and secured
by the master setting program (called CRCLOCK.EXE), and so it bombs back to
DOS telling you this. To correct the problem, run CRCLock on your program and
select the level of armorment that you wish to protect your file with.
For example to protect a file called MYPROG.EXE do the following:
"CRCLock myprog.exe"

  This will lock the file "myprog.exe" using the standard armorment setting.
To change the armorment use the command-line parameter "-l". To get a list
of the command-line parameters, just type "CRCLock" on its own and press
enter. To lock with maximum armorment you would do the following:
"CRCLock myprog.exe -l3"

  The locking process consists of 3 stages that are performed by CRCLock.
The size of your file determines how long this process takes, but you only
have to do it once and the mobile code does not suffer from these speed
problems.
  The first stage is the file analysis stage, this is the longest
stage and during this operation CRCLock is examining your source code to
determine whether or not CRCLock has been linked in.
  The second stage is the FingerPrint construction stage. During this
operation CRCLock is devising a FingerPrint that is suitable and Unique for
your program.
  The final stage is the armorment and storage of this FingerPrint in your
source file. Once this is complete your file has been locked with the
armorment settings that you specified.


┌────────────────┐
│ Error Messages │
└────────────────┘

CRCLock Specific:
─────────────────

"Can't open file 'filename.exe' for analysis."

  This error is generated by CRCLock when it cannot open the file you
specified on the command line for processing. It is most likely that the
file doesn't exist in the current directory or you made a spelling mistake.
Correct this and you should have no problems.

"CRCID not found. CRCLock is not Present or file is already locked."

  This message is generated by CRCLock after the file analysis stage. The
message is only generated if CRCLock could not find the TagID that it uses
to determine whether CRCLock has been linked in with your code or not.
If the message appears then the most likely explanation is that you forgot to
link in the CRCLock Mobile Code with your orginal source file. See above on
how to do this. The other possible explanation is that you have already
locked the source file with CRCLock, in which case a second locking would not
be possible.

"Multiple Instances of CRCID Found!! ID is not Unique."

  This message is only generated by CRCLock when it has found more than one
instance of its TagID in your source file. If this is the case, then CRCLock
does not know which is its own code and which is foriegn so it gives up and
issues this error. The cause of this is most likely that a string in your file
exactly matches (or contains a portion of) the TagID that CRCLock is currently
using. To correct this change this string in your source code, or modify the
TagID (CRCID) that CRCLock searches for. (Note: This function is currently
only available to registered users).

CRCLock Mobile Code Specific:
─────────────────────────────

All of the following errors are generated by the BOSS, henceforth they may
not appear exactly as they are shown below, but the wording will be identical.
For more information on the BOSS please see the section further on in this
documentation.


"CRCLock Requires DOS 3.x of higher."

  CRCLock must run on a DOS version of 3.x or higher, otherwise it will not
be able to locate the master filename for its filename checks. This is a
problem with the revisions of DOS that were made by Microsoft. A correction
that allows CRCLock to run on earlier versions of DOS is currently being
worked on.
  If you are confident that the armorment level of the file in question is
MINIMUM then you can use the DOS function SETVER.EXE to fool CRCLock into
thinking that it is running on a later version of DOS. This trick will ONLY
work on the minimum armorment level, the Standard and Maximum levels are
protected against this function.

"Self Access Error on file: 'filename.exe'."

  The mobile code for CRCLock was unable to access the EXE that it is linked
into. This is most likely to be caused if you have used the DOS utility
SETVER.EXE to modify the OS version number to fool CRCLock into running on
DOS 3.x or less, and if you have locked the file with Standard or Maximum
Armorment. It is also possible that this error may be caused by a sharing
violation. If you are running the DOS Share utility, try removing it from
memory. If you are running under Windows 3.x or 95, then quit to DOS.

"CRCLock FingerPrint Not Stored. Run CRCLock First."

  The mobile code for CRCLock has detected that the file it is linked to has
not been locked by the CRCLock master program. If this is the case CRCLock
cannot continue the file analysis because it has no reference FingerPrint
with which to work. The solution to this is to simply run the CRCLock master
program and lock the file with your prefered armorment level.

"FingerPrint Security Compromised."

  This is a particulally serious error. The error states that the CRCLock
mobile code has detected that the FingerPrint locked into the file by the
master program has been tampered with. In this case the remainder of the
internal checks cannot continue because the reference FingerPrint is invalid.
CRCLock will abort the program if this occurs, that way no damage can be done
by the modified code. This error can only be generated by the Standard or the
Maximum Armorment levels because the Minimum Armorment level does not lock
any FingerPrint analysis data, in order to keep the FingerPrint size down.

┌───────────────┐
│ What is BOSS? │
└───────────────┘

  BOSS stands for Basic Operations Support System and is an integral part of
both CRCLock and its mobile code. BOSS provides (as the name states) support
for all of the basic functions provided by an operating system and the run
time libraries of most programming languages.
  In the case of CRCLock BOSS performs functions such as file I/O, screen I/O,
parameter checking and error handling. The version of BOSS that is provided
with CRCLock and its mobile code is the cut down version, meaning that only
the functions required by the specific program have been linked in to the
main EXE. This is to keep size down and minimise any redundant code.
  In the full version of BOSS, it is possible for your programs to communicate
with BOSS to modify how it handles certain situations, but because your
programs do not require the use of BOSS, these features are not linked in and
so only the mobile code of CRCLock uses it. Due to this fact, some of the
error messages displayed by CRCLock will be formatted and handled by BOSS,
meaning they will appear differently to that shown in the Errors section of
this document.

┌────────────────────┐
│ Reporting Problems │
└────────────────────┘

  If you discover a bug or have noticed a specific problem with CRCLock on a
particular system or under a certain set of circumstances, please detail the
problem in a text file, including the machine specification that the problem
occured on and any resident programs that may have been running, and send the
information to '[e-mail]'.
  This address should be valid until October 1997, if you mail this address
and your mailer-daemon returns it as invalid, please download the latest
version of CRCLock from where ever you obtained the first version and check
the documentation for a new address.


┌─────────────────────────────────┐
│ Official Copyright & Disclaimer │
└─────────────────────────────────┘

Copyright 1995-1997 Cause & Effect Industries. All Rights Reserved.

  No part of this publication may be reproduced, transmitted, transcribed,
stored in a retrieval system, or translated into any other language or
computer language in whole or in part, in any form or by any means, whether
it be electronic, mechanical, magnetic, optical, manual or otherwise, without
prior written consent of Cause & Effect Industries.

CAUSE & EFFECT INDUSTRIES DISCLAIMS ALL WARRANTIES AS TO THIS SOFTWARE,
WHETHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
FUNCTIONALITY, DATA INTEGRITY OR PROTECTION.


CRCLock, BOSS, Cause & Effect Industries, CEI and the CEI logo are all
registered trademarks of Jonathan Thorpe and Cause & Effect Industries.


Trademarks of other companies mentioned in this documentation appear for
identification purposes only and are the property of their respective
companies.