Protection against source-code manipulation




CrunchCode is able to integrate a monitoring of the contents of selected procedures and to react to changes.

Undesirable manipulations cannot be prevented in an open source text like VBA,
but they can be recognised and action taken
(e.g. termination of the program).

The protection does not apply to the original program, only the source–code processed by CrunchCode.


Select first the type of the protection:

Password: Protection of the VBA password.

You have set up a password which should prevent a display of the source code.

CrunchCode implements a function which checks,
whether the password protection is intact


VBA code: Protection of the VBA source code.

A password can or should not be set up
(e.g. because accesses to the VBA project are necessary).

CrunchCode implements a function which checks,
whether certain parts of the source code are unchanged.



The source–code–monitoring consists of four elements:

1. Targets = Procedures whose contents are to be protected from manipulation
  (only for the protection–type "VBA code")

2. Trigger = Instances in which the target is tested

3. Reaction = Action to be taken when the target has been manipulated

4. Handler = Procedure that performs the test and reacts to the manipulation


Functioning of the protection–type "Password":

CrunchCode implements a Handler, which is called during the program flow
by one or several triggers.
This checks whether the access to the VBA code is still locked.

Functioning of the protection–type "VBA code":

CrunchCode determines immediately before the end of a processing the CRC32–check–sum
of all targets and inserts into a standard module the handler,
which is informed about the targets and the CRC–sum.

During program execution, the handler is called by one or more triggers,
checks the CRC–sum of the targets and initiates a reaction, if the sum has changed.

ATTENTION!

This protection type requires an access to the VBA project object model!

For more information see below "e) SOURCE CODE DELETE".


As trigger are to choose from:

a) at program startup
    The integrity of the targets will be tested only at the start of the program.
    CrunchCode implements the handler–call at the beginning of a Auto_Open procedure.

    This option should only be used when a large number of targets are included
    and this hinders the program flow noticeably.

b) in event handlers
    The test is performed in event procedures (e.g. xxx_Click, xxx_Activate etc.).
    CrunchCode implements the call of the handler at the beginning of the respective event procedure.

    This ensures a high frequency of monitoring without inhibiting the program flow unnecessarily
    (Event procedures are always initiated in breaks).

    For technical reasons, testing is not possible for the events

..._MouseMove
..._BeforeDragOver
..._BeforeDropOrPaste

c) in the following procedures...
    The test is only performed in procedures specified by the user.
    CrunchCode implements the call of the handler at the beginning of these procedures.

    This way you can determine yourselves in what moments a check takes place.


In the case of manipulation of a target, the following reactions are possible:

a) stop the program
    The program is stopped, but not closed.
    It is further available for user's actions or a restart.

b) program resume with...
    The program runs a procedure that can respond to the manipulation.
    This gives you the opportunity to respond in a special way to manipulation.

    Note: "Property"–procedures can not be selected for program continuation.

c) close the program
    The program closes IMMEDIATELY with NO WARNING, any changes are not saved.
    Excel will not finish, other open files are not affected.

d) Excel quit
    Excel closes immediately, all changes in open files will be lost!
    This option offers a spectacular effect, but it also means
    that unsaved files will be affected.

e) SOURCE CODE DELETE
    The complete source code is deleted! Only few components will remain.
    These cannot be removed for technical reasons.

    The file is then saved so that the changes are permanent!
    An eventual error message can be displayed AFTERWARDS,
    so that it is not possibile to realize and intercept the deletion.

    This is the most radical method and means
    that the program is IRREVERSIBLY DESTROYED
    (in many cases causing the Excel to crash).

    The attacker is unable to manipulate the source–code further.

ATTENTION!

This method is only applicable to the protection type "VBA code".
It does NOT WORK WITH ACTIVATED PASSWORD PROTECTION.

On the target computer must in addition be enabled access to the VBA project object model.
Otherwise, no source destruction takes place.

The access you activate as follows:

     Excel 2003:
           Extras
           –> Macros
           –> Security
           –> Trust access to Visual Basic Project

     from Excel 2007:
           Options
           –> Trust Center
           –> Trust Center Settings
           –> Macro Settings
           –> Trust access to the VBA project object model


Additional notice about the targets:

Declarations outside of procedures (e.g. global constants) cannot be protected.
In order to monitor these, the value assignment must be relocated into procedures
so that these are added to the target list.

Example:

cannot be protected:

Public Const NO_CHG_TXT = "Do not change!"

can be protected:

Public strNO_CHG_TXT As String
...
Sub InitVar() \
   ...  \  to the target list
   strNO_CHG_TXT = "Do not change!"   > add "InitVar" to the target list
   ...  /
End Sub /




Handling

to protected procedures (= targets) – only for the protection–type "VBA code"

Specify the procedures that are to be monitored.

Warning! Only choose the most critical procedures.
The greater the number of procedures monitored,
the more noticeably is the program flow hindered.

Do not choose procedures, that (regular!)
may be changed during the program.


2. Check (= trigger)

Determination of the instances when a check should be performed.

Dispersion

When as trigger was chosen "in event handlers":

Proportion of the event procedures in which a handler–command
is inserted to check for source–code manipulations.

With a value of 100% this occurs in ALL event procedures.

However, such a frequent use of the handler–call enables
the meaning and function to be quickly recognised
which reduces the camouflage effect considerably!

Therefore, select a value that is significantly below 100%:
e.g.: 20% meaning the handler is inserted in only 2 out of every 10 event procedures.

The selection of procedures is random.
For technical reasons, testing is not possible for the events

..._MouseMove
..._BeforeDragOver
..._BeforeDropOrPaste

Should the examination happen only in certain event procedures,
then choose as trigger "in the following procedures".

Procedures select

When as trigger was chosen "in the following procedures":

Choice of the procedures that act as a trigger for checking the targets.

You can also select procedures that are themselves a target!
For technical reasons, testing is not possible for the events

..._MouseMove
..._BeforeDragOver
..._BeforeDropOrPaste


3. Reaction

Selecting the action for the case that the targets were changed.

Certainty

Probability with which the reaction actually takes place.

With a value of 100% the selected reaction is always performed
as soon as a change in the target was identified.

However, this also causes a direct link between test and reaction!
An attacker could quickly work out where or when the check
took place and could possibly eliminate the check in the source–code.

Therefore, select a value that is significantly below 100%:
e.g.: 40% = a real reaction takes place randomly only in 4 out of 10 cases.

The lower the probability chosen, the more random will the reaction appear.
This complicates identification of the trigger–point
thereby increasing considerably the camouflage effect!

Procedure list

If the chosen reaction was "program resume with",
specify which procedure the program
should continue with after a target–manipulation.

Hint:
This list does NOT include any procedures that were declared as "Private"
or selected as targets.

Display message

In addition, an error message can be displayed.

It is recommended this option only be used in special cases
because it is can be thereby recognised even better
the position in which the check took place.

With "|" you can insert line breaks in the message text.



as standard

Selecting "OK" will save the current settings as your default for future projects.
Then they can be also reactivated with "Preset" –> "user–defined".

Preset

Optimisation of the settings or reset to defaults.
(inter alia to those values which were saved "as standard").