PDA

View Full Version : Deny Access to the VBE?



Stargazer
10-03-2011, 09:05 AM
Hi,

The old saying stands true: You build a better program and the world makes a better idiot to break it!

We have a workbook that, in a rather complex and convoluted manner, counts down and closes after x-amount of inactivity. This is because the book cannot be shared and must be accessible at all times. We have also built in just about every single possible security and safety system you can think of. This all works, but we now have a new problem to try and get around.

We believe they have managed to stop the clock by opening the VBE and clicking the 'Stop' button. All the code is password protected. Only my colleague and I know it and I know how protective Paul is with his code so I know he's not going to let anyone have the password. But the stop button is accessible without using the code password since it is in the toolbar and not in a module of any sort.

So is there a way to prevent the VBE from being opened?

Our initial thoughts are:-

1) On the timer tick, do a 'For Each' to capture the title of all open windows on the machine and if any of them are like "Microsoft Visual Basic*" then close it.

Hopefully this would veto the VBE before 'they' manage to stop the timer. But we have yet to find a way to get application window titles/captions outside of the Excel container.

2) Hide everything from the formula bar upwards and do a keypreview on Alt+F11.

Messy and makes it obvious that we don't trust the managers as far as we could spit them.

3) Password protection prior to showing the VBE.

Would require a re-work (probably) of Excel's own code and therefore is unlikely.


If you have any ideas or thoughts, I would be interested to hear them.

Regards,

Rob.

Bob Phillips
10-03-2011, 09:21 AM
Application.VBE.MainWindow.Visible = False

ianswer
10-03-2011, 12:50 PM
A question ... how to enable then ?

Stargazer
10-04-2011, 01:08 AM
Application.VBE.MainWindow.Visible = False

Thanks for this. Any ideas if there's a security setting somewhere that might cause me to get the message "Programmatic access to Visual Basic Project is not trusted" ?

Stargazer
10-04-2011, 01:28 AM
Scratch that last question... Found it in the Trust Centre settings...

"Trust Access to the VBA project object model". Ticking this seems to be making things easier.

Bob Phillips
10-04-2011, 02:11 AM
Yes, it is is macro security settings, Tools>Macro>Security...>Trusted Publishers and check the 'Trust access to Visual Basic Project' checkbox

Aflatoon
10-04-2011, 02:17 AM
Of course, all the user has to do is not allow that...

Bob Phillips
10-04-2011, 03:00 AM
Then you could test for it and just not allow the thing to run.

But ... it seems that the proper way is to educate the users, and 'encourage' them not to mess.

Aflatoon
10-04-2011, 03:38 AM
Or the user could simply enter design mode.

I agree that education is a far superior solution, especially if there is a 'stick' of some sort involved, such as threat from a manager. Or perhaps an actual stick.

Stargazer
10-04-2011, 03:54 AM
We've tried the education method. They nod, they appear to take it in and then they deliberately go about trying to find ways of breaking the rules.

Each time we build in another condition. We've got things that prevent other workbooks being opened in the same application container. We have things that deny the creation of new workbooks. The file checks its name and location on startup to prevent itself from being copied to other places on the network. It even creates a series of files and updates them so one of my little .net applications can set off an alarm on my PC if someone somehwere starts doing something silly with it. The countdown clock has gone through 4 distinct stages of evolution to the point where it is now unstoppable by any means other than our devloper login which we have passworded up to the hilt and are now thinking of putting on USB drives, so we can access the program on other peoples PC's using our personal flash drives with specific files that only we will have.

This is just scratching the surface. And why do we have all of this?

Because two people simply cannot wrap their tiny minds around, "Please close the workbook when you're not using it."

If I outranked them, I would probably fire them for being inept, tip them out the window or simply deny them access to the files we create. Sadly, I work for them and as such, all I can do is to continue to try and fight my side of the war and hope that eventually, the application will be so watertight that they'll have nothing left to try.

Each time they find a way to break it, they just force us into making the prgram stronger. Eventually it will be unbreakable.

I wonder if this is how SkyNet started out?

Bob Phillips
10-04-2011, 04:05 AM
But you will never be able to keep ahead of them. It is like viruses, a new one appears that you haven't anticipated, so you build a defence, and someone else finds a new flaw, so you ... and so on, ad infinitum.

If they will persist in this behaviour, withdraw support, remove the software. Address the problem, not the manifestation of the problem.