Is absolute security for Excel VBA code possible?

  • Thread starter Thread starter Frank_Hamersley
  • Start date Start date
F

Frank_Hamersley

I have been looking to protect a rather large and useful VBA codebase from
prying eyes.

To date I have been using the standard Excel password protection but the
password crackers zap this in their sleep - only 1:10 secs was required on
an old P166 clunker!

What are the options to really secure the code? I have ruled out (for the
moment) porting it to C++ and then compiling it an .xla. Would porting to
VB provide equivalent protection? Or is there some clever VBA arrangments
that can be made?

Some other ideas I had are...
1. if I could strip (programagically) all the comments just before release
to make any crackers task more tedious,
2. perhaps hex edit the password hash to gobblegook so it can _never_ be
matched by the cracker - would a downside of this be that it stops the VBA
engine from firing?

Cheers, Frank.
 
You can't really protect it in VBA. You have to convert to compiled code (a
dll) with routines that are called by "wrapper" routines in the VBA project.
 
Frank_Hamersley said:
I have been looking to protect a rather large and useful VBA codebase from
prying eyes.

To date I have been using the standard Excel password protection but the
password crackers zap this in their sleep - only 1:10 secs was required on
an old P166 clunker!

What are the options to really secure the code? I have ruled out (for the
moment) porting it to C++ and then compiling it an .xla. Would porting to
VB provide equivalent protection? Or is there some clever VBA arrangments
that can be made?

Some other ideas I had are...
1. if I could strip (programagically) all the comments just before release
to make any crackers task more tedious,

Rob Bovey's Code Cleaner does this as I recall
2. perhaps hex edit the password hash to gobblegook so it can _never_ be
matched by the cracker - would a downside of this be that it stops the VBA
engine from firing?

Cheers, Frank.

Probably.

If you are using Excel 2000 or higher then consider moving the
code to a COM add-in in VB6

Much of the module code will be relatively easy to move but
the forms will need reddrawing and there are some subtle differences
between forms in VB6 and Userforms in VBA. For example listboxes
in VB dont support multiple columns

I just completed moving an application with 15 forms and
8 code modules , it took me approx 2 weeks.

http://msdn.microsoft.com/library/d...html/deovrAddinsTemplatesWizardsLibraries.asp

Keith
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top