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

"Anthony Cuttitta Jr." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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.

"Alan" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> "Anthony Cuttitta Jr." <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >
> > 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.

"Anthony Cuttitta Jr." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

>>
>> 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.
>

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.

"Alan" <(E-Mail Removed)> wrote in message news:<#(E-Mail Removed)>...
> "Anthony Cuttitta Jr." <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >
> > 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.

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

"Anthony Cuttitta Jr." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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.

"Alan" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> "Anthony Cuttitta Jr." <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >
> > 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.

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.

"Anthony Cuttitta Jr." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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.

"Alan" <(E-Mail Removed)> wrote in message news:<##(E-Mail Removed)>...
> "Anthony Cuttitta Jr." <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >
> > 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.

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

"Anthony Cuttitta Jr." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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.