[shell-coding] fun stuff

  • From: ilmcuts <ilmcuts@xxxxxxx>
  • To: shell-coding@xxxxxxxxxxxxx
  • Date: Mon, 28 Feb 2005 23:56:11 +0100

Hey all,

Here are a few more things that have come up recently:

1.) SHLoadInProc/SHEnableServiceObject (follow-up)

If the COPYDATASTRUCT you receive has dwData == 2, the cbData is set to 20 (XP SP2). But sizeof(CLSID) == 16. That leaves room for another DWORD. So I tried:

struct LoadInProcData
{
    CLSID rclsid;
    DWORD dwUnknown;
};

I knew the CLSID had to come first because I had previously just casted lpData to a CLSID* and had succefully gotten the CLSID. A short test program resulted in the following values for dwUnknown:

1 - SHLoadInProc
2 - SHEnableServiceObject(clsid, FALSE)
3 - SHEnableServiceObject(clsid, TRUE)

That was almost too easy. Then again there is no app known to use SHEnableServiceObject, so there's no point in implementing it currently.


2.) SHFindFiles

As you might know, SHFindFiles doesn't work if Explorer isn't running. At least on most 2k/XP setups. Despite it being documented to return a BOOL, it returns REGDB_E_CLASSNOTREG if Explorer is not the shell. We had previously gotten it to work while an IE instance was running in the background, but I couldn't reproduce this any more. Maybe it's because of SP2. Either way, Regmon indicated that SHFindFiles is looking for a COM object, specifically CLSID_ShellBrowserWindow. I hope to have reduced the problem to the following line:

HRESULT hr = CoCreateInstance(CLSID_ShellBrowserWindow, NULL, CLSCTX_LOCAL_SERVER, IID_IUnknown, (LPVOID*)&pUnk);

This line returns S_OK under Explorer but REGDB_E_CLASSNOTREG if Explorer is shut down. I do not know whether fixing this will acutally fix SHFindFiles, but I think there's a good chance that the two are related.

Oleview.exe reveals that CLSID_ShellBrowserWindow is from shdocvw.dll, but it is apparently only registered when Explorer is running. Thus we must somehow get shdocvw.dll to register it. DllRegisterServer didn't help. A quick look at Dependency Walker reveals that the XP SP2 explorer.exe only links to three shdocvw.dll functions (names from WINE):

RunInstallUninstallStubs, WinList_Init, WinList_Terminate

Unfortunately neither of those appears to register the desired COM object... a test app which called all possible combinations of these three functions resulted in no change whatsoever. Of course there's always the possibility that Explorer uses GetProcAddress or calls the register export through some other DLL - if there is a dedicated "register classes" export at all.


3.) SHChangeNotifyRegister

Apparently this neat function stops working if Explorer is not the shell. A program I wrote which uses it only receives notifications a) if Register was called while Explorer was the shell and b) while Explorer is still running. Once Explorer is shut down the notifications stop coming in. Restarting Explorer doesn't help, Register needs to be called again.

I will probably convert my program to use FindFirstChangeNotification - assuming that this works without Explorer. Call me naive, but I have always assumed that the change notifications are kernel object, since they are waitable after all. Thus I wonder where the connection to explorer.exe is.


That's all for now. Lots of fun stuff to mess with.

ilmcuts

__________________________________________________
Subscription options and archive:
//www.freelists.org/list/shell-coding

Other related posts:

  • » [shell-coding] fun stuff