Unprotecting a VBA Project

[Anthony Cuttitta Jr.]

I had to do some digging recently to try and find the answer to this,
and while I did find a couple good leads, the code wasn't *quite*
right. So, for the benefit of someone else trying to attempt to do
this crazy thing, I thought I'd post the code here. (Really, it's NOT
an ego thing...just trying to give back a little.)

NOTE: The constant "conPW " is the password to be used on the project.
The value is stored with the project at save/close, so locking the
doors when you leave isn't necessary.


Public Sub UnprotectVBAProject()
'This has been tested in E97 only.
On Error GoTo ErrHandler
Const conPW as String = "MyPassword"

'Open VBE
Call SendKeys("%{F11}", True)
'Open Project Explorer
Call SendKeys("%(V)P", True)
'PageUp 5 times to be sure "VBAProject" is selected
Call SendKeys("{PGUP 5}", True)
'Hit Enter to give prompt, enter PW and Enter again.
Call SendKeys("{ENTER}" & conPW & "{ENTER}", True)

ExitProcedure:
Exit Sub

ErrHandler:
Select Case Err.Number
Case Else
Application.ScreenUpdating = True
MsgBox Err.Number & vbNewLine & Err.Description,
vbCritical
Resume ExitProcedure
Resume
End Select

End Sub

 

[Alan]

I had to do some digging recently to try and find the answer to this,
and while I did find a couple good leads, the code wasn't *quite*
right. So, for the benefit of someone else trying to attempt to do
this crazy thing, I thought I'd post the code here. (Really, it's NOT
an ego thing...just trying to give back a little.)

NOTE: The constant "conPW " is the password to be used on the project.
The value is stored with the project at save/close, so locking the
doors when you leave isn't necessary.


Public Sub UnprotectVBAProject()
'This has been tested in E97 only.
On Error GoTo ErrHandler
Const conPW as String = "MyPassword"

'Open VBE
Call SendKeys("%{F11}", True)
'Open Project Explorer
Call SendKeys("%(V)P", True)
'PageUp 5 times to be sure "VBAProject" is selected
Call SendKeys("{PGUP 5}", True)
'Hit Enter to give prompt, enter PW and Enter again.
Call SendKeys("{ENTER}" & conPW & "{ENTER}", True)

ExitProcedure:
Exit Sub

ErrHandler:
Select Case Err.Number
Case Else
Application.ScreenUpdating = True
MsgBox Err.Number & vbNewLine & Err.Description,
vbCritical
Resume ExitProcedure
Resume
End Select

End Sub

Am I being simplistic, or does that mean that in order to break the
password on my VBA Projects, all someone has to do, is run that code
inside a loop, trying various values of conPW?

Surely it cannot be that trivial to unlock a project or am I just
being naive?

Alan.

 

[Anthony Cuttitta Jr.]

I had to do some digging recently to try and find the answer to this,
and while I did find a couple good leads, the code wasn't *quite*
right. So, for the benefit of someone else trying to attempt to do
this crazy thing, I thought I'd post the code here. (Really, it's NOT
an ego thing...just trying to give back a little.)

NOTE: The constant "conPW " is the password to be used on the project.
The value is stored with the project at save/close, so locking the
doors when you leave isn't necessary.

[snip]

Am I being simplistic, or does that mean that in order to break the
password on my VBA Projects, all someone has to do, is run that code
inside a loop, trying various values of conPW?

Surely it cannot be that trivial to unlock a project or am I just
being naive?

Alan.

Actually, my guess is that you're right. Good passwords are the key
(at least if your code is critical).

Nothing is hackproof.

 

[Alan]

Actually, my guess is that you're right. Good passwords are the key
(at least if your code is critical).

Nothing is hackproof.

Agreed - but this seemed a little too simple for my liking.

I tried to code it, but it is not quite as simple as it seems (or
perhaps I am too simple...)

Alan.

 

[Anthony Cuttitta Jr.]

Agreed - but this seemed a little too simple for my liking.

I tried to code it, but it is not quite as simple as it seems (or
perhaps I am too simple...)

Alan.

Has to be run from a command button on the spreadsheet. Can't run from debug.

 

[Alan]

Has to be run from a command button on the spreadsheet. Can't run
from debug.

I was running it as a sub from Tools - Macros - Run from a worksheet,
mainly since the first command was to open the VBE, which meant,
implicitly, I had to start from outside the VBE.

Why does it *have* to be run from a command button? Does that make a
difference?

Thanks,

Alan.

 

[Anthony Cuttitta Jr.]

I was running it as a sub from Tools - Macros - Run from a worksheet,
mainly since the first command was to open the VBE, which meant,
implicitly, I had to start from outside the VBE.

Why does it *have* to be run from a command button? Does that make a
difference?

Thanks,

Alan.

Exactly because of what you're saying. I don't know why it *has* to
be, just that running it from the VBE doesn't work (actually, flips
you back to Excel, then goes wacky), running it from the menus does
odd things too. Putting it on a button works cleanly though.

 

[Alan]

Exactly because of what you're saying. I don't know why it *has* to
be, just that running it from the VBE doesn't work (actually, flips
you back to Excel, then goes wacky), running it from the menus does
odd things too. Putting it on a button works cleanly though.

Strange but true!

However, I think that this approach is not so trivial, since there is
no way that I can see to trap the dialogue box that appears if you get
the password wrong.

By that, I mean that there does not appear to be any way to recognise
that it has popped up (or not), hence you cannot loop through multiple
tries.

Perhaps things are not so insecure after all - maybe it is a built in
feature to avoid it being done which would be a good thing?

Alan.

 

[Anthony Cuttitta Jr.]

Strange but true!

However, I think that this approach is not so trivial, since there is
no way that I can see to trap the dialogue box that appears if you get
the password wrong.

By that, I mean that there does not appear to be any way to recognise
that it has popped up (or not), hence you cannot loop through multiple
tries.

Perhaps things are not so insecure after all - maybe it is a built in
feature to avoid it being done which would be a good thing?

Alan.

I noticed that too. Apparently the Overlords of the Rainy Kingdom do
think ahead sometimes...

 

[Alan]

I noticed that too. Apparently the Overlords of the Rainy Kingdom
do think ahead sometimes...

Indeed!

At least I can go back to working on the assumption that my work is
'reasonably' secure.

I had a look on google for password crackers for free, working on the
assumption that if it really was trivial they would be all over the
place for free, but the only options appear to be paid services /
applications so probably it is not a significant concern.

Thanks,

Alan.

 

[Norman Jones]

Hi Alan,

At least I can go back to working on the assumption that my work is
'reasonably' secure.

I had a look on google for password crackers for free, working on the
assumption that if it really was trivial they would be all over the
place for free, but the only options appear to be paid services /
applications so probably it is not a significant concern.

I doubt that many in these parts would concur and, contrary, to your
impression, tools to remove or bypass Excel's protection are readily
available.

In my opinion, you would be well advised to treat Excel's protection as a
transitory inconvenience rather than a serious impediment to untrammelled
access.

 

[Alan]

I doubt that many in these parts would concur and, contrary, to your
impression, tools to remove or bypass Excel's protection are readily
available.

In my opinion, you would be well advised to treat Excel's protection
as a transitory inconvenience rather than a serious impediment to
untrammelled access.

Hi Norman,

Thanks for your comment - I am back to 'somewhat concerned' now!

I spent about 20 - 30 mins looking through links from Google, but
found nothing freely available to remove the passwords from a VBA
Project, nor indeed to remove the password from a workbook.

It is quite easy to find trial versions that work for up to 3
character passwords for both of these, but not free full versions for
any length of password..

It is also easy to find code to remove worksheet protection
passwords - is that what you meant?

However, perhaps my search skills are not so hot?

Thanks again,

Alan.

 

[Norman Jones]

Hi Alan,

It is also easy to find code to remove worksheet protection
passwords - is that what you meant?

No, I referred to all and any protection afforded by Excel.

Lest you believe my views to be idiosyncratic and unrepresentative, try
doing a Google Groups search using Excel, Security and Password as your
keys.

 

[Frank_Hamersley]

Hi Norman,
Thanks for your comment - I am back to 'somewhat concerned' now!

I spent about 20 - 30 mins looking through links from Google, but
found nothing freely available to remove the passwords from a VBA
Project, nor indeed to remove the password from a workbook.

It is quite easy to find trial versions that work for up to 3
character passwords for both of these, but not free full versions for
any length of password..

I found one that unlocks the most cryptic password I could come up with in
1min45sec and thats using my old P166 clunker!

Whilst looking over this topic a short while back I came across a
description of the Excel encryption methodology - from memory (so don't
quote me) the crypt'ed string is about 8 or so chars long but the first six
only have a choice of 2 possible (byte) values leading to only about
4,194,000 discrete hashes to test - not very challenging at all even to a
Z80!

Don't been concerned! - if you assume Excel security doesn't exist then you
will be fine! BTW if you do want to secure your code it appears an .xla
approach using a true compiler is the only option.

Cheers, Frank.