VBS/VBA/VB and registry editing… (VB6)

Topic

New Reply

Never having used the Scripting Host, take this for what it’s worth….

Have you set a reference to the Windows Scripting Host Shell Object?

Maybe that is the difference?

Reply | Quote

Replies

Help a dumb and confused newbie.

If I use VBScript or even VBA, I can edit the registry by Creating the Windows Scripting Host Shell Object and then using simple commands like RegWrite or RegDelete:

Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.RegWrite …

However, as best I can tell, this is not an option for VB6. To edit the registry using VB6, I need to:

1) Declare each editing function from advapi32.dll separately (e.g., Declare Function RegSetValueEx…)
2) Declare each parameter I might use with a given function (e.g., hkey, ipValueName)
3) Declare a Type for each parameter (e.g., As Long).
4) Define Constants for the hives and data values (e.g., Const REG_SZ = 1)
5) Define Constants for registry permisions (e.g., Const KEY_WRITE = &H20006)

Then, I can use VB6 to edit the registry. Is this a correct assumption??

Is there no way to invoke the Windows Scripting Host Shell Object in VB6 like I can in VBS and VBA?

Also, can I stick ALL the Declarations and Constants I need to edit the registry in single “.bas” module, and then ‘refer to’ or ‘call on’ this module each time I want to have a VB6 program edit the registry?

Please respond as you would to an eight year old. Some people have said I frequently act that old anyway! ;-] THANK YOU.

Reply | Quote

In VB or VBA, try using

Set WshShell = CreateObject(“WScript.Shell”)

i.e remove the WScript. which precedes CreatObject

Andrew Cronnolly

Reply | Quote

Andrew — that does it.

Why wouldn’t everyone just do this?? Why would I need to jump through all the hoops of the API coding if I can do it this easy??

Thank you.

Reply | Quote

A lot of Corporate Systems Administrators disable/uninstall the Windows Scripting Host on all PCs they administer for “security” reasons.

I don’t know what the reasons are, that’s just what I have been told.

Reply | Quote

The reasons are to keep malicious scripts from executing from emails and web downloads.

Reply | Quote

That does not make sense to me!

You are saying that programmers go through the hassles of using the API to edit the registry… “to keep malicious scripts from executing from emails and web downloads.”

I am not sure I follow that logic.

———————————————–

If you are instead saying the users disable the WSH for this reason, then MAYBE that makes sense — until you think about it for about two seconds. Most people disable the WSH by simply disabling the file extension associations to the WSH executable.

This does NOT render the WSH inoperable, but it does prevent .vbs, js, .wsf, and other files from easily running. Even with every single WSH file extension DIS-associated, the engine still runs this code quite easily.

Hmmm… you should know this…

Reply | Quote

I can even go so far as to rename (and therefore disable) the WSH executable entirely. And guess what??

I can STILL run the VBA code and edit the registry.

So… I do not think “disabling WSH” in any of the usual fashions will stop this. I suspect only completely removing WSH from your system would be sucessful — but I suspect Windows and especially IE would not like that…

Reply | Quote

Renaming it isn’t how the administrators block it, and if it *is* blocked, then you won’t be able to do it that way.

You can always use GetSetting and SaveSetting to create and populate or read and individual keys if you don’t want to bother with GetPrivateProfileString and WritePrivateProfileString.

Reply | Quote

Interesting. How do administators block it? Please tell me as I would love to test this.

I do not think GetSettings and SaveSettings are going to do me any good. As best I can tell, they ONLY function in HKLMSoftware key — and that is pretty limited.

Additionally, GetPrivateProfileString and WritePrivateProfileString appear to be for .INI files — not the registry. How are those going to help me editing the registry???

Reply | Quote

I’m not doing it because I don’t do network administration anymore and haven’t in years, but I’ve worked in offices in the recent past where it definitely *was* disabled. The whole scripting host is disabled and it has nothing to do with what programmers want to do, it is a security issue to protect networks from attack. Trying to get around any network security issue is a good way to get fired in that kind of environment … especially if you happen to succeed.

Reply | Quote

It looks to me that the usual mechanisms of preventing email attachment scripts from running are not going to be effective at stopping this technique.

The ‘Set WshShell = CreateObject(“WScript.Shell”)’ method utilizes only two files that are a sub-set of the WSH. I best I can tell, most people do not disable these. I even wonder if IE uses these to help run script.

The two files are:

wshom.ocx – Windows Script Host Runtime Library (an ActiveX control)
scrrun.dll – Microsoft ® Script Runtime

So, unless ‘disabling WSH’ disables these exact files, then it looks to me like the WshShell method should work.

Reply | Quote

Removing or renaming the WScript.Shell object-identifier (ProgID? whatever it’s called) in the Registry would seem to kill it. Don’t know if anyone does it that way. I wonder if you could do it from a VBScript that instantiates that object and then, in a sense, commits suicide…

As for GetPrivateProfileString, there’s documentation in the Word VBA help files on how to use it to read Registry stuff. Not sure if the WinAPI works the same way as Word’s specialized versions.

Reply | Quote

Yes, someone *could* disassociate the WScript.Shell from its Class Identifier ({72C24DD5-D70A-438B-8A42-98424B88AFB8}), or remove the InProcServer32 entry for the Class ID — which is the WSHOM.OCX file I listed above.

However, that would generally not be considered as part of the standard method of “disabling WSH”. From my view, most administrators simply want to prevent their users from inadvertantly running scripts. To do that, they either dissociate the WSH file extensions (.vbs, .js. .wsf, etc.) from wscript.exe — or rename wscript.exe.

Interestingly, since WinME and Win2K-XP have WSH as part of the operating system, that seems to be the recommended method. One could un-install WSH in Win9x from Add/Remove Programs; whether that removes the WScript.Shell object and wshom.ocx is not clear to me…

Other references on this are:
http://apcsnh.com/vacm/wshremove.html%5B/url%5D
http://www.sophos.com/support/faqs/wsh.html%5B/url%5D
http://securityresponse.symantec.com/avcen…pt.hosting.html%5B/url%5D

BTW, IE does not seem to utilize the WSH files to run script — or at least I did not catch it doing this. It seemed to only utilize the iexplore.exe file — so all the script interpreting function might be built inside that program itself.
________________________________________________

Jeff, the only logical answer I can come up with is that using the API functions is the more powerful method. If you need to do more detailed or extensive registry editing or *enumerating* of mulitple values, then you must use the API functions. If you simply want to read and write to a value or two, the WScript.Shell function seems to suffice.

Make sense?

Reply | Quote

> BTW, IE does not seem to utilize the WSH files to run script — or at least I did not catch it doing this. It seemed to only
> utilize the iexplore.exe file — so all the script interpreting function might be built inside that program itself.

Unless the script needs one of the objects accessible through WSH, I think you’re right that IE is pretty much self-sufficient (not counting the script engine DLLs).

Reply | Quote

>>Not sure if the WinAPI works the same way as Word’s specialized versions.

One difference I’ve run into is the native Word commands restrict data value
string size to 255 characters. The API calls are bound by the registry limits
of 64k for string values.

Reply | Quote

Administrators on Win2k or NT servers would probably use System Policies to restrict access to shell components.

Reply | Quote

I don’t even know how to do that!! (Newbie alert)

Reply | Quote

Since you say it yourself (being a newby), wouldn’t it be a bit couragious to start meddling with the registry?

Reply | Quote

Not from my viewpoint. I am very adept at using regedit — and as we all know, Win9x has five default backup copies of the registry stored in the C:WindowsSysbckup.

There is no harm that I can see… I work in the registry evey day…

Reply | Quote

I’m not sure which library you have to reference, but under Tools|References.. (this is from memory since I don’t have access to VB 6 here at work)

You will be able to select a reference that will allow you access to the Scripting Host.

Reply | Quote