Protecting VBA Code

[Bill Bell]

I was wondering if there have been any developments in protecting VBA
code. I was hoping by now there would be some easy way to compile VBA
code into a DLL or COM addin.

I saw some websites claiming to be able to easily break the passwords.
How secure is the password protection? If you have a long password
does that help. I am using Office 2003 and Office XP.

Regards,
Bill Bell

 

[Daniel Klann]

Bill,

Unfortunately what the websites claim is correct regarding protection of the
VBA project. I purchased a password cracking tool a couple of years ago
(for legitimate purposes) and it can break any password. For example, I
protect a project using this complex and long password (32 chars):-

%^ll-02-+$j';L*30)>65Jï£AKJ%_!~2

Because of the encryption algorithm used there are many possible
combinations that could be used to break this e.g. T8H would unlock a VBA
project protected with the above password. The encryption used for the file
password in Excel is stronger than anything else used in Excel but can still
be broken. In this case it is worth using a password that is long and
complex.

Anyway, creating your own COM addin is a fairly straightforward task but you
need to have software that will allow you to create it e.g. Office Developer
Edition, Microsoft Visual Basic .NET, Microsoft C++ and Microsoft Visual
Basic 6. Office Developer is probably the easiest method of converting an
existing project into a COM addin.

Hope that helps,
Daniel

 

[Bill Bell]

Daniel, thanks for the info. I was looking on MS web site for Office
Developer and I am confused on what product to purchase. I need the
COM addin to work in Office 2000, Office XP and Office 2003.
They have reference:

0 Microsoft Office XP Developer - but it appears that product
is discontinued.
0 Visual Studio Tools for the Microsoft Office System. This looks
it will create a COM addin.
0 Visual Studio .NET 2003 - This sounds that whatever it produces
will only work with Office 2003.

Any help in clarifying the confusing MS marketing material is appreciated.

 

[Rick]

Hi,

It took me months to figure it out completely, part time,
but I'm now able to write all of my VBA Excel code in VB6
and then compile that program as an executable.

Some people here were very helpful, in getting me
started. It takes a lot of effort - because once you
discover one thing - it leads to another problem - but
each time there is another solution.

It works and it's flawless! I'm so suprised that more
people don't realize it.

Why isn't this mentioned more often? Does anyone have any
opinions of why they would not write the VBA code in VB6,
to create a more secure environment for source code? Why
would other methods be better? What are those methods?

Thanks, Rick

 

[buczacz]

I'm a bit rusty on this procedure, and I don't know about compatibility
with the newer versions of Excel, but it supposedly worked as a barrier
to reverse Engineering of code in Excel95. I used this procedure to
better assure that a cost estimation spread sheet was doing what I
intended it to do, and not to necessarily prevent someone from seeing
how it was being done.

The concept I employed was to save the macro as an "add-in" macro. The
Excel HELP notes on "add-in" macros warned that users will not be able
to decode macros saved as an "add-in," and they should save the
original code, so it could later be modified if needed. Supposedly the
code stored as an "add-in" is "compiled" macro code.

javascript:checklength(document.vbform);

[check message length]


I have saved and used macros as an "Add-in" in Excel95. I'm not sure
the feature exists in later versions of Excel. If indeed the code is
saved in compiled form, it would represent a significant barrier to
reverse engineering the code.