[RESOLVED] Challenge - Create Add-In to prevent *.vbw actions

[LaVolpe]

I have little experience with creating add-ins, so I thought maybe some of you that really like this kinda thing might be interested in a new project for the VB community.

For a discussion on this topic, jump to post 125 (page 4) at https://www.vbforums.com/showthread....anetSourceCode

Basically, vbw files do present a potential security risk that could allow usercontrols (UCs) to execute code as soon as a project is loaded into the IDE, before the project is even run. The challenge, if you want to call it that, is to write an add-in that would prevent anything showing up in the IDE's design view that is not a code page on initial load, i.e., form GUIs primarily, but any GUI would be preferred. Why? ...

The vbw file contains statements that could tell VB to display a form, or any GUI, in design view immediately upon loading the project (.vbp). If that form has a UC on it, then that UC's Initialize & ReadProperties events will execute. If there is any malicious or poorly-written code executed from those events, they are executed without you having the ability to stop it, barring an error in that code. If you run your IDE elevated (like most of us do nowadays), that UC has full admin rights too.

Deleting vbw files solves that immediate problem. But unless you are aware of this issue or simply forget, then it can be too late.

The add-in should only trigger on existing projects, not new projects where a new form is almost always displayed.

Granted, this may not be the right place for this thread and if a mod decides to move it, so be it. I tried to search vbForums to see if such a utility/add-in exists, but found none. If anyone knows of it, just post a link here if you would, TIA.

Updates
Eduardo posted a solution in the codebank that will purge a vbw file before VB gets hold of it. And also purge it if VB re-saves it when the project unloads. Post comments about that project at that thread. Here it is
https://www.vbforums.com/showthread....15#post5492915

Curious whether a solution can be found that will allow vbw files, just prevent loading GUIs only at initial project load, and only for existing projects not new projects?
Found a way, posted suggested changes to Eduardo's thread ^^

[Thierry69]

Good idea.
If I have time tomorrow, I could investigate to create it

[Elroy]

I might take the challenge, but possibly not today.

But, just to be clear, you're wanting an Add-In that, if loaded, it just deletes the VBW file just before any VBP (including VBG) project is loaded?

[LaVolpe]

If any of you get it production-ready and post it on this site, let me know so I can reference it on this thread & resolve this thread.

[LaVolpe]

But, just to be clear, you're wanting an Add-In that, if loaded, it just deletes the VBW file just before any VBP (including VBG) project is loaded?

No, that will likely be too late. I think VB's add-in extensibility let's you know whether a project is "New" or not and which GUIs are being displayed. I'm just not that familiar with it to know all the details & interaction it provides. But I do expect that the add-in, when after initially triggered, will turn itself off for the current project so that users can then display the GUIs at their own risk.

[Elroy]

LaVolpe, I think we're on the same page.

I'm definitely NOT thinking of something that would scan our C-drives and delete all VBW files.

Short of that, the best we could do is to "detect" when the VB6 IDE is about to open a VBP file, and, delete any VBW before the VBP is actually opened. Maybe I'm saying it wrong, but when the IDE is about to open an existing project.

[LaVolpe]

For those of you interested, here's a small idea to help out.

A test project should be something really simple. A form hosting an uncompiled UC, where maybe the only thing in the UC is an initialize event having a messagebox. Place UC on the form & save project. Now open the vbw file in NotePad. Find the form and remove the letter C at the end of the line, leave the trailing comma. Save the vbw & make it read-only. Now VB won't overwrite it during your tests.

[Elroy]

For those of you interested, here's a small idea to help out.

A test project should be something really simple. A form hosting an uncompiled UC, where maybe the only thing in the UC is an initialize event having a messagebox. Place UC on the form & save project. Now open the vbw file in NotePad. Find the form and remove the letter C at the end of the line, leave the trailing comma. Save the vbw & make it read-only. Now VB won't overwrite it during your tests.

Hmm, that's more complicated than I was thinking. Personally, I delete those VBW files all the time. I'll often search my primary project (with 100s of modules) for something, and wind up with, say, 30 windows open. Then, next time I load it, those 30 windows pop open again, which is quite annoying.

Personally, I'll accept the task of re-opening some window when I'm popping in and out of the IDE over the convenience of having them open automatically. Even when I've downloaded some project with a VBW, it's annoying when all the code windows pop open. I'm perfectly capable of double-clicking them in the project window if I want to see them.

But anyway, I'll probably examine the possibility of an add-in that just deletes the VBW. Whatever I come up with, I'll post here.

Maybe we can give people a couple of different options.

[Eduardo-]

Here it is.

[LaVolpe]

Elroy, if someone double clicks on vbp file or activates it from File|Open from the IDE, deleting vbw might be too late. The IDE may have already read & cached the file before and add-in can intercept. If not, then yes that would be the easiest solution I'd think. If it's there, delete it if it's not, no worries. However, that is pretty much a hammer which prevents anyone from saving their workspace and expecting the code pages to re-display.

Like you, I prefer to not have them displayed at all when I open a project. But there are times when I do want them displayed. That's why I think a different solution that simply tells the IDE: "Existing project just being loaded? If so, don't load GUIs, load anything else". And after that check is made, turn itself off until the next project is loaded into the IDE. Those were my initial thoughts.

[LaVolpe]

Here it is.

LOL that was fast. One question? That should work on non-US locales for projects created in those locales? I'd think yes? If not, maybe use APIs for setting attributes & killing file?

Edited: to be more clear. Let's say someone saved their project in a folder containing unicode. I'd think that if they could save it there, then Kill & SetAttrs should work just fine.

I'm curious whether others can come up with another solution that will allow vbw files to exist, just not loading the GUIs? Let me update post #1 to your link in the codebank.

[Eduardo-]

LOL that was fast. One question? That should work on non-US locales for projects created in those locales? I'd think yes? If not, maybe use APIs for setting attributes & killing file?

I'm curious whether others can come up with another solution that will allow vbw files to exist, just not loading the GUIs? Let me update post #1 to your link in the codebank.

I tested and the IDE cannot read Unicode named *.vbp files.

Of course someone with the IDE in another locale could write these files, but you want be able to load them.
Another developer with the same locale will, but also the Add-In must work for her/him.

[Elroy]

Nice Eduardo,

I was actually stuck on the mProjHandler_ItemAdded event. It didn't dawn on me that it would fire even when the VBW file was being added.

Elroy

EDIT: Yep, all tested and works as advertised. The first (and probably only) add-in I'll load on start-up in the VB6 IDE. Now we just need an add-in for add-ins to delete that pesky DCA file.

[LaVolpe]

FYI. I messed around a bit and am able to determine what is loaded in the project before any UC code activates. However, I am not able to prevent activation (while keeping the vbw file). I can delete the project item -- but what good is that other than preventing the UC code from executing. Form is now gone & wasn't able to add it back -- remember, I'm not well experienced with add-in creation.

Although that still may be the workaround; just don't know how to do that within the add-in. May need to cache the item's filename, then reload the file via its name into the project? Even if that is done, would cause VB's internal dirty flags to set. But I still may play with that idea a bit later more out of curiosity. Don't think I'd be keen on any solution that requires modifying the actual project files (excluding vbw of course), should something go wrong & trash someones project.

edited & likely final follow-up
Deleting & re-adding forms is a no-go. Not only would any problems result in trashed project, would need to track/restore extra stuff, like the startup object for example. There just aren't enough events to know what's going on. We know what GUIs exist in the project, but after the project initializes, then the next event we get is that something in the IDE was selected. That's too late as any UC code activated before then. I think the only other workaround is overkill -- create a hook, listen for new window creations, look for form-related designer windows, then prevent their creation. Eduardo's solution of deleting the vbw file seems to work well & doesn't require a lot of monkeying around. I'll mark this thread resolved. That doesn't stop someone trying what I outlined above though or some other solution.

Edited: found a way of keeping the vbw file & preventing code execution. I offered it up to Eduardo for updating his solution.

[LaVolpe]

Yep, all tested and works as advertised. The first (and probably only) add-in I'll load on start-up in the VB6 IDE.

Manifest your IDE, and you'll probably want my add-in to restore the popup palette & possibly restore drag/drop from non-elevated Explorer to elevated IDE (manifested or not).

[Elroy]

Manifest your IDE, and you'll probably want my add-in to restore the popup palette & possibly restore drag/drop from non-elevated Explorer to elevated IDE (manifested or not).

Yeah, I know. I'll stop there for the sake of not starting a longer discussion on that topic.

[Thierry69]

Just wake up and already done....
So no need for me to do it
I'll take a look