Advice: Security of VBA project

Hi everyone,

I'm perfectly aware that Excel is not a secure development plaform, but have a question about VBProject security.

How easy is it to break VBProject security? I have a workbook with a workbook open password to keep it secure from non-authorized individuals, but recently was informed of an advanced user in our system. I've never had to set project level security, as most people don't know how to get into the VB Editor, let alone go further.

Basically, what I'm after is to just lock the project down to keep in from being modified without my approval, but I'm curious to know if it can easily be hacked. (It's set with "lock project for viewing" and a password.)

I know that worksheet level security can easily be broken by brute force, but project security I'm not sure about.

Any insight would be appreciated.

Hey Ken,

As far as my (limited) knowledge goes, you can't break the VBA Project Password w/o some kind of third party program. Do you have a file you want tested?

Hi Zack,

I could probably come up with one...

The problem is that the VBA Project is not excrypted when it is locked, just the password is encrypted. So replace the encrypted password with another encrpted password (that you know the password key for) and you have access.

Okay, now that is interesting...

So the chance of someone uncovering the password is pretty slim then, but they can overwrite it with their own? It'll make it pretty obvious if it happens then, I guess.

I'm guessing that you need some more advanced knowledge than I've picked up so far, though, as everything password related in VBIDE seems to be read only...

EDIT: I'm not asking how to do this, mearly trying to figure out how easy it is to track down the code if someone were a malicious user.

Quote:

---

Originally Posted by kpuls

So the chance of someone uncovering the password is pretty slim then,

---

Try slim to none. Without 'professional' software, it almost can't be done. The preferred method for 'hacking' a VBAProject password, along with any Excel passwrod really, lies in changing it w/o knowing it.

And yes, I could test it for you.

All righty then...:)

Try this file. No workbook password, but does have a VBProject password. Only a msgbox in the module. What does it say?

Code:

---

Option Explicit

Private Sub sectest()
MsgBox "This is a test procedure with no value!", vbOKOnly, "testing!"
End Sub

---

They are not that hard, unfortunately. :(

No kiddin!

Okay, so did you use a VBA procedure to unlock it?

No.

Guys....do we want to leave this in the open discussion area? Just wondering. Zack: I'm gonna let it be your call.

:)

Hi all,

I find it unethical to discuss issues like this in public.

Kind regards,
Dennis

I don't see any problem with discussing security issues in generalities. Especially if people want to know how secure their programs really are.

So long as we discuss it as we are without providing step by step instructions, I don't see the problem.

Whether it's discussed here, or someone does a google search and finds any one of the 1000's of hacker sites that discuss issues like this doesn't really matter? I for one would rather have a legitimate site, with trusted content to be able to discuss these types of issues on. It's good to know that even the VBE password can be hacked, which just reinforces the issue of Excel not being a secure environment. Though to be honest, there's not a lot of users of DRJ's caliber running around, thank God(or your choice of Deity). I know I couldn't have bypassed the VBE password without a ton of research.

Cal

Thanks Anne/Dennis/Calvin,

I find it borderline. It could go one way or the other. I'm going to edit the thread, not delete it. I do find it good information as I think *most* of the populous will. The methods used will not be public material. If there is anything that is still borderline after editing, please let me know via private message.

Thanks all for you input! :yes

A few words from mvidas:

As discussed, VBAProject security is not secure at all. 3rd party 'professional' software is not needed. If the creator truly believes that their methods are one-of-a-kind and should not be seen by anyone, it should not be made in excel or vba.

However, as far as creating routines in VBA and protecting the vba project, I honestly feel that anyone who is determined enough to break that protection can probably write the same code themselves and that should not be a deterrant for releasing anything written in vba.

A few words from kpuls:


I?ve asked Zack to share my opinions on the ethical question, as the thread was locked before I had the chance. First off, though, I do want to say that I agree that the thread, in its original form, was pushing over into the darker side of ethical boundaries.

I want to make clear that my intention for this post was never to leave a ?how to? trail, and I?m glad that all references to the methods used have been removed, as I feel that it brings this post back into the acceptable realm of discussion.

What I was trying to prove (to myself), was how easy or difficult it would be for a malicious, somewhat skilled user to source out the method to crack my vbProject security. Keeping in mind that I dealt with people who both knew and trusted my intentions. It also became apparent that someone who knows what they?re doing, can do it.

For my situation, I have come to the conclusion that if I have a user in my network with both the skills and intent to plan and implement this kind of breach, my spreadsheets are probably the last things I have to worry about. A user of this class will most certainly attempt to deliver a far more devastating payload than attacking our Excel files.

I do feel, however, that this post illustrates how easy it is to compromise Excel?s security. Yes, this spells out, in black and white, just how vulnerable Excel is, but as developers, I feel we have both the right and need to know.

If anyone has any comments on this at all, please feel free to PM me to discuss.

I'm going to open this thread back up for discussion purposes. I see no reason we can't discuss the issue. I like what's being said. :)

This is a pretty touchy subject to some, and others feel completely different about it. Since the *hack info* was removed, I think it's cool if we continue the discussion.

Great stuff, guys! Great job, Zack!

It's good to make users aware of the weak protection Excel have. The reason for it as well this is the price, is that Excel and many other end-users softwares are so called open systems/softwares.

Instead of trying to improve the present protection abilities I strongly believe we need to take an another stand on the issue.

Nowadays I rarely protect workbooks instead I solve it by using other possibilities including signing contracts with clients to assure that the solutions are intact. This could easily be transferred to internal solutions as well, i e agreements within the department and/or between departments. The benefit is that the users can take part of the solution and perhaps learn one or more thing. Another advantage may be that clients can, to some degree, do the maintance by themselves.

For larger projects a better approach, both when it comes to protection as well as performance, is to separate code from interface, user-data etc. The code is compiled into COM add-ins. By using this approach the maintance can easily be done.

Sometimes this approach is not acceptable or not wanted for one or more reasons and then I just leave the solution unprotected, especially if the solutions have been installed on many end-users computers and contracts have been applied.

And I agree that if someone would like to take a closer look into a secret they can do it no matter how much protection we add, i e if You want to keep things secret then a good start is to not use a computer.

Hi Dennis,

I am a firm believer in leaving my Excel workbooks open to modification when it makes sense to do so. For the most part, I protect worksheets with no password, and let my users know this. The purpose is not to lock the file down at all, but rather to make sure that they don't do something nasty by accident. I do try to make sure that if they need to be able to change something, that they can. I also encourage my users to learn about Excel so that I'm not the only one in my organization to support the workbooks.

Unfortunately, however, there are times when protection is necessary, as honesty is just not a human trait that we can always rely on. In this case, the spreadsheet is a vital link between many of our point of sales systems and our general ledger. I know that sounds bad, but we have 4 legacy POS systems and a G/L which do not support any kind of interfacing technology except human hands! Excel can at least be used to create a journal entry in an acceptable format to import (manually) into our G/L. If I lose this spreadsheet, it will affect not only myself, but a few others in the organization. If we had the funds, this spreadsheet would not even be necessary, as we would have installed a fully integrated property management system, but unfortunately we're not there yet.

I do understand where you're coming from, but I, for one, do feel that protection abilities should be increased for this product. Excel has been pushed out to the business community for a long time, and is used the world over for purposes exactly like mine. I am also certain that many others also share my concerns.

I don't believe that anything out there is, or ever will be completely unhackable. I do think, however, that it should be a little more difficult than it currently is.

I am going to have to do some research on the COM add-in. That sounds very interesting to me...

This might be of use though not completely finished:

http://www.thecodenet.com/articles.php?id=38

:)

Nice Mark!

Now I don't need to make a write up about it myself - just point to Your article ;)

Don?t forget to mention the pros & cons about the different Instancing :)

Kind regards,
Dennis

Thanks for the link. I suppose I should create a COM addin eventually at least once.

Thanks Dennis!

:)

Hi Mark,

Thanks for that! It's a cool site you have there!

Question on the COM add-in... you need a full copy of VB6 or Visual Studio to do it? Although I've studied some VB6 procedures for VBA use on occasion, I've never programmed in VB6 (yet) so am not fully aware of what software is required.

Thanks,

Cheers Ken.

Yep to create a COM addin you need a copy of VB6. There is very little difference between VBA and VB6 so getting into it is easy. The main difference is the Forms where there are more controls and options available. There are other things that are useful though like the Printer object, Drawing methods and Control arrays.

:)

Yeah...if you have any questions on VB6, just ask me! (NOT!!)

You should be able to do it with VBA - what you need is the ability to compile to a DLL, which MS Office Developer, if you have it, gives you. I should add that I have not done this!!!

Hi guys,

No, it's not possible to create with the MOD version :(

It require a public class which is not possible to create with the MOD so the only way is to get Your hands of a copy of MS VB 6.0 and if You're lucky You may get it for a good price via some public auction-site like E-bay.

I believe the above is a good explanation why MOD was never a cash-cow for MS.

( The latest version is associated with Visual Studio.NET and it's named to VSTO, Visual Studio Tools for Office).

Kind regards,
Dennis

Thanks for that Dennis. I have seen various references to using MOD but had never tried it. Shame really, because to my little mind it seems you ought to be able to use VBA.

Quote:

---

I believe the above is a good explanation why MOD was never a cash-cow for MS.

---

That and the fact that if you're going to shell out for it why not get VB6 anyway and have increased functionality!

:)

Quote:

---

Originally Posted by XL-Dennis

Hi guys,

No, it's not possible to create with the MOD version :(

It require a public class which is not possible to create with the MOD so the only way is to get Your hands of a copy of MS VB 6.0 and if You're lucky You may get it for a good price via some public auction-site like E-bay.

I believe the above is a good explanation why MOD was never a cash-cow for MS.

( The latest version is associated with Visual Studio.NET and it's named to VSTO, Visual Studio Tools for Office).

Kind regards,
Dennis

---

Hi Dennis, long time no speak...

Are you sure you can't create a COM add-in using Office XP Developer edition? Although in the past I've usually used VB6 to create COM add-ins, I have created at least one using 'Developer. For example, the attached (useless) DLL file was created using Excel XP Developer. I'm confused by your reply as I can't think of any other worthwhile use for 'Developer other than creating COM addins. Am I missing something? :dunno

I've also attached the VBA project file which contains the source code.

Kind regards,
Dan

Hi Dan :)

Quote:

---

Are you sure you can't create a COM add-in using Office XP Developer edition?

---

You?re right that my previous answer should be refined and I apologize for being unclear:

Automation add-ins
Creating userdefined worksheetsfunctions can't be done with MOD as it miss the option Public - Creatable for classes.

COM add-ins
MOD can create com add-ins which extend the interface of Excel.

Quote:

---

Am I missing something?

---

I believe that with Your post and this one we don't miss anything ;)

Thanks my find for clarifying it and for pointing it out :)

Dennis