Convert Excel VBA addin to a Protected Format

[Guest]

I've developed a 2d sketch package for floorplans and calculating areas
using Excel VBA and the native Excel drawing functions. I would like to
distribute the addins and protect the code from other users. My
understanding is Excel VBA addins have only a password protection which can
be easily broken and VBA addins cannot be protected.

Since Excel VBA addins are not protected, what other options do I have? I
want the distribution, installation, uninstall and possible licensing to be
as simple as possible and also secure. I'm looking for info which describes
the entire conversion and usage process.

I have several VBA addin files with approx 10k lines of code. I could
convert this to another format but it would be a non trivial task.

I am currently using XP with Excel 2003. I'm not concerned with earlier
versions of the OS or Excel. I want to be compatible with Vista and future
versions of Excel/Office.

Any suggestions or links would be appreciated.

thanks.

 

[Peter T]

As you say VBA code protection is minimal but perhaps enough to keep out
casual users.

The simplest way to protect would be to port to a VB6 ActiveX dll, and/or
adapt that to a Com addin. By 'simple' most of the vba code might work
pretty much 'as is' subject to fully qualifying absolutely everything, ie
all excel type objects and excel-vba functions. How much work is involved
would depend on how the vba was written rather than what it does. It is a
learning curve, particularly VB6 Forms which may need to be completely
re-written, though you can use your original Office (vba) userforms.

Although VB6 currently works in Vista it is no longer supported by MS who
would prefer you to use dot.net, even more of a learning curve.

Compatibility with future Excel versions is not directly related, your VBA
would need to do that anyway. As for Vista, AFAIK, the main issue is where
you can write to file and registry permissions.

You might want to weigh to potential loss of revenue of your code being
accessed against the cost of your time with learning curve or commissioning
someone to do it. Most casual users probably won't bother to break in.
Perhaps of more concern is the possibility of others distributing your work
as their own, either freely or commercially.

Regards,
Peter T

 

[Nick Hebb]

I did something similar and went the VB6 COM add-in route. It allowed
me to use 3rd party licensing / anti-piracy tools as well as 3rd party
components to obtain XP and Vista styles. But as Peter T mentioned,
VB6 has some drawbacks. If I had to do it all over again, I would
probably take the time to learn Delphi and use that in conjunction
with Add-In Express.

If you use VB6, you will need to likely need to change all your
references to Objects (late binding) and declare an Application object
and derive all Set statements from it, e.g. instead of Me or
ActiveSheet you would need something thing Set ws = xlApp.ActiveSheet.
If you are sinking events such as Worksheet_Change, then you cannot
use late binding.

To use early binding and be backward compatible, you will need to
obtain a license for Excel 2000 and set a reference to that version of
the Object Library. If you go that route, I would strongly recommend
setting up a Virtual Machine - either Microsoft's VPC (free) or VMWare
- and doing your builds in it.

Just my $0.02,

Nick Hebb
BreezeTree Software
http://www.breezetree.com

 

[Peter T]

Hi Nick,

Interesting you say in hindsight you would use Delphi in conjunction with
Add-In Express. Could I ask why the preference vs VB6.

With VB6 I haven't seen the need to use late binding providing the reference
is set to the lowest version of Excel. That of course requires the lowest
version is installed on the development machine. The same principle of
developing in the lowest version holds for a VBA addin.

In VB6, unlike VBA, I don't find a problem with early binding to do
something like the following within the same procedure -

If xlVer < 10 then
xl97/2k method
Else
method only available in later versions

Regards,
Peter T

 

[Nick Hebb]

Hi Peter,

Interesting you say in hindsight you would use Delphi in conjunction with
Add-In Express. Could I ask why the preference vs VB6.

The main reason is sustainability over time. Like VB6 it's a RAD tool,
but despite the persistent rumors of its demise, Delphi will likely be
around (and supported!) longer than VB6. The other thing is that is
produces small executables. As I add more and more 3rd party controls
and functionality to my application, the size is swelling rapidly. I
don't think download size is that big of an issue these days, but I do
consider smaller better. The Delphi community is fanatical and the
more I look into it the more I understand why.

The downside, of course, is that most sample code you'll find is
written in VBA. More and more I'm finding top search results showing
VB.Net and C# code samples. With Delphi, you don't get that knowledge
base. Plus, I prototype most functions in VBA then move the code into
VB6, so that's a plus forVB6 over Delphi as well.

With VB6 I haven't seen the need to use late binding providing the reference
is set to the lowest version of Excel. That of course requires the lowest
version is installed on the development machine. The same principle of
developing in the lowest version holds for a VBA addin.

Agreed. But if you don't already own a license for Excel 2000, non-
pirated copies are getting harder and harder to find. It took me some
hunting to find a legit version last year. Same goes for VB6 as well.
Alan57, I hope have luck with that if you decide to go the VB6 route.


Nick Hebb
BreezeTree Software
http://www.breezetree.com

 

[Peter T]

Thanks for that. I was unaware of Delphi's keep it small attributes. I don't
use any third party controls so that aspect hasn't been a factor for me, but
I will keep your comments in mind.

Hopefully, in view of the millions of VB6 app's out there, MS will not
disable VB6 in the foreseeable future.

Regards,
Peter T

 

[Guest]

Peter & Nick,

Thanks for the comments and information. It's become apparent to me that I
don't understand the problem well enough to make an informed, intelligent
decision. There does not appear to be a clear "correct" answer.

VB6 is probably the simplest solution, but if MS is not supporting it in the
future then this may have a limited lifetime and require another port in the
future.

Delphi may be an option, but I'm concerned about the compatibility with MS
and support. I prefer to use the MS advertised/supported/built-in tools to
minimize the compatibility issues.

Add-In Express looks useful but will be another unanticipated expense and
learning curve.

I've been told dot.net applications can be decompiled and do not provide
absolute security.

I still need to solve the installation kit/uninstall/licensing issues for a
non excel addin solution. The excel addin installation is simple enough and
I have a crude yet usable licensing scheme based on the C drive serial
number. I have some ideas on how to improve the licensing scheme and make it
easier to work with.

Another option I've considered is using a security enhancement tool for the
excel addin. The tool supposedly prevents most password recovery tools from
working. The tool also prevents the hex editor hack from working unless the
hacker understands the entire MS VBA protection scheme. Have you heard of
this or have any experience with this security enhancement tool? An excel
addin with this additional protection may be the simplest and most reasonable
solution.

I'm leaning toward the following solutions:

short term - use an excel addin with the additional protection.

long term - consider another programming language to create the addin. The
primary concerns are MS compatibility, lifetime/support, additional product
requirements (licensing, install, etc) and cost.

Please provide any additional suggestions/comments you have. I'm especially
interested in any comments you have on the enhanced security tool for an
excel addin.

thanks again.