Sandboxie Forum - Horizontal scrolling inoperable with Maxthon (7834)

tzuk:

Fri May 14, 2010 11:55 am

In version 3.45.11 I added a new (mostly for internal use) NoRenameWinClass setting, which provides the functionality of OpenWinClass that is needed here, but without any adverse effects to security.

tzuk:

Wed May 05, 2010 12:23 pm

Thanks. Re Software Compatibility, it never occurred to me that it might be interesting to know what software was already there. Re Kaspersky, I think originally I aimed for detetion of just the IS suite, not the AV. In any case I will change the name of the template to - Kaspersky Anti-Virus/Internet Security.

U:

Tue May 04, 2010 7:00 pm

The template was added after installing beta 10. Scrolling also working. One question about the "Software Compatibility" dialog that pops up when a new software is being detected. How can I see (without comparing the templates.ini) which listed entry is new or modified since the last update? Maybe Sandboxie could remember which templates were existing before upgrading to a newer version and print the new arrivals in bold or something. And I have Kaspersky Anti-Virus, not Internet Security installed. If the template will do its job for both software how about generalizing its name to avoid confusion? The service by which KAV is being detected is actually the "Kaspersky Anti-Virus NDIS Filter".

tzuk:

Tue May 04, 2010 3:54 pm

I released version 3.45.10, please test the auto-detection feature when you have a chance.

tzuk:

Thu Apr 29, 2010 10:49 pm

Let me try to explain it again. The IE process can offer some services to other programs, like reporting what's in the current web page, and filling forms. To use these services, the other program needs a way to talk to IE. So this "Internet Explorer_Server" window thing has a known name that programs can look for, and so is the starting point to access the services. So a program sends a message to the window, asking how can I use the services, and the window gives back some number. The program takes this number and goes to COM (whatever it is) and says, here, I have this magic number, let me access the services. The OpenWinClass will let the program in the sandbox find the magic number this way, but the program in the sandbox can't talk to the COM outside the sandbox (whatever it is). It can only talk to the sandboxed COM. And the sandboxed COM will not be able to associate that magic number with the IE outside the sandbox. So the program in the sandbox can't do much with the magic number. This is why I said there is little cause for concern. I hope that makes some more sense.

U:

Thu Apr 29, 2010 10:21 pm

The horizontal scrolling is working in all windows I have tested except for programs that make use of the IE engine to display content, which would be when they are using the "Internet Explorer_Server" class. So unless someone finds a new compatibility issue with special mouse commands in other windows, the problem can be marked as solved. You were saying that there shouldn't be an issue if no outside IE windows are running. I never run IE itself but as you know, several programs are using its engine. Still nothing to worry about while running Maxthon sandboxed and another unsandboxed instance of an IE window class? This could happen quite often on my computer. I probably should read a little more into the effects of using OpenWinClass as to be honest, I don't fully understand them yet. Thanks again though for trying to explain.

tzuk:

Thu Apr 29, 2010 8:53 pm

]]>Quoting U: ]]>Is this compatibility setting going to have any effect on security or is there a scenario where you think it would make a difference? ]]> From what I read on the net, this window is used by IE to expose a COM object which represents the web page open in the browser. http://support.microsoft.com/kb/249232 However, sandboxed programs can't get to COM objects outside the sandbox, so the bottom line is that I don't think it is a concern in any real sense. And certainly, if you don't have IE running outside the sandbox at all, then it's a complete non-issue. ]]>Quoting U: ]]>As you probably already know, but I still want to point it out, this problem isn't exclusive to Maxthon but more to all Internet Explorer shells. ]]> While we're on the subject, how about non-IE browsers, and for that matter, other applications altogether?

soccerfan:

Thu Apr 29, 2010 4:05 pm

]]>Quoting U: ]]>Besides, Internet _ Explorer_Server does not work. ]]> Thanks for the quick confirm of your original setting. Much appreciated.

U:

Thu Apr 29, 2010 3:52 pm

See here: [img:47b23ba27d]http://i40.tinypic.com/15yztqw.png[/img:47b23ba27d] Besides, Internet _ Explorer_Server does not work.

soccerfan:

Thu Apr 29, 2010 3:37 pm

]]>Quoting tzuk: ]]>OpenWinClass=Internet Explorer_Server ]]> I'm wondering if an underscore is missing between Internet and Explorer (one of the OpenWinClass entries in the earlier posts,except U's last post, have a blank space).

U:

Thu Apr 29, 2010 3:22 pm

Will do, and thanks for guiding me through to finding a solution. Is this compatibility setting going to have any effect on security or is there a scenario where you think it would make a difference? As you probably already know, but I still want to point it out, this problem isn't exclusive to Maxthon but more to all Internet Explorer shells.

tzuk:

Thu Apr 29, 2010 2:05 pm

Good work. So I'm going to have Sandboxie look for the registry key, ReadKeyPath=\REGISTRY\MACHINE\SOFTWARE\Logitech\SetPoint And in that case, add OpenWinClass=Internet Explorer_Server And I hope this will take care of this issue. I'm going to add this auto-detection in the next beta build ( 3.45.10 ), and would appreciate if you could test it. Thanks.

U:

Thu Apr 29, 2010 10:50 am

Added all of Maxthon's window classes listed by WindowSpy - nothing. Used the Finder Tool over the Maxthon website frame and a new class came up: Internet Explorer_Server I have deleted all other classes and it is working with only this one.

tzuk:

Wed Apr 28, 2010 11:31 pm

I have a new idea. Those resource and debug logs, they show the names of windows that were accessed by a program running in the sandbox. However the program in the sandbox might create a window with a specific name, and then wait for some other component (like a service outside the sandbox) to access this window. Normally, Sandboxie would manipulate the names of the created window, and this might interfere with the component outside the sandbox, trying to find this window. But when there is a Window Access setting for * or #, Sandboxie no longer manipulates the names. This might explain why these settings make a difference. So what I'd like you to do is use WinSpy this time on the web browser process in the sandbox, and see if you can identify any windows within this process that look like they might belong to your logitech software. Then, add those names as Window Access settings. If you will experiment without having * or # in effect, then expect to find window class names that begin with a prefix of " Sandbox:DefaultBox: ". You will need to strip this prefix when you add the window class names to Window Access. You will probably need to add all the other window names as well. In other words: OpenWinClass=LOGI_DEVICE_LISTENER OpenWinClass=KodiakHiddenWndClass OpenWinClass=KHALHIDC_MainWindow OpenWinClass=KHALMOU_MainWindow OpenWinClass=KHALHIDN_MainWindow OpenWinClass=KHALHIDM_MainWindow OpenWinClass=KHALUSB_MainWindow OpenWinClass=KHAHLHPP_MainWindow OpenWinClass=KHALITouch_MainWindow OpenWinClass=KHALMouseware_MainWindow OpenWinClass=KHALMainProcessWindow OpenWinClass=$:Setpoint.exe OpenWinClass=$:KHALMNPR.EXE OpenWinClass=any window class names that you identify within the web browser process Then restart your web browser under Sandboxie, and check if the class name appears without the Sandbox:DefaultBox: prefix. If the prefix is gone, then the setting was applied correctly, and hopefully things will actually work.

tzuk:

Wed Apr 28, 2010 2:36 pm

Thanks, knowing for sure that it is the hash, that narrows it down even further. Let me think about this for a bit, I'll post again later.

U:

Wed Apr 28, 2010 2:28 pm

It's the # alone.

tzuk:

Wed Apr 28, 2010 2:01 pm

You said you were using version 3.45.07, it already includes the changes to OpenWinClass that I mentioned in the other topic. So I don't think upgrading to version 3.45.09 will make a difference. But seeing that it works with just # is interesting. You're sure that you did not also have * at the same time, right?

U:

Wed Apr 28, 2010 1:57 pm

The hooks don't work but the # hash does. Do you want me to try the .09 beta? I was kinda holding off until the new features are tested a little more.

tzuk:

Wed Apr 28, 2010 12:36 pm

I see there is something related to hooks. You can try to enable hooks but I'm not sure it will make any difference. Sandbox Settings > Restrictions > Low-Level Access > Turn on second checkbox The reason I think it won't make a difference is that the Window Access * exclusion which does work, is not related to permitting or allowing hooks. Please also review my comment here: http://www.sandboxie.com/phpbb/viewtopic.php?p=51374#51374 And try to add a Window Access exclusion that is a single # (hash) instead of the single * (star).

U:

Tue Apr 27, 2010 9:08 pm

Okay, did run the capture while having Maxthon open and trying to scroll. This was the output starting with SBIE, hope it helps: [quote:18c65a3c44](000588) SBIE (GA) WinHook 0002 on tid=003644 pid=000588 (000588) SBIE (GA) WinHook 0004 on tid=003644 pid=000588 (000588) SBIE (GD) PostMessage 49479 (C147) to hwnd=00020198 pid=001792 MS_WebcheckMonitor (001432) SBIE (GA) WinHook -001 on tid=003888 pid=001432 (001432) SBIE (GA) WinHook -001 on tid=003060 pid=001432 (001432) SBIE (GA) WinHook -001 on tid=001184 pid=001432 (001432) SBIE (GA) WinHook 0005 on tid=001184 pid=001432 (001432) SBIE (GA) AccHook on tid=000000 pid=000000 (001432) SBIE (GA) WinHook -001 on tid=001184 pid=001432 (001432) SBIE (GA) WinHook 0007 on tid=001184 pid=001432 (001432) SBIE (GA) WinHook -001 on tid=004076 pid=001432 (001432) SBIE (GA) WinHook 0005 on tid=004076 pid=001432 (001432) SBIE (GA) WinHook 0007 on tid=004076 pid=001432 (001432) SBIE (GA) WinHook 0002 on tid=004076 pid=001432 (001432) SBIE (GD) PostMessage 49477 (C145) to hwnd=00020198 pid=001792 MS_WebcheckMonitor [/quote:18c65a3c44]

tzuk:

Tue Apr 27, 2010 8:06 pm

OK. Another thing to try, open your Sandboxie.ini file and enter just below [GlobalSettings]: [GlobalSettings] GuiTrace=ad Then run DebugView from Microsoft and see if you get any messages from Sandboxie (they should start with SBIE). http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx You need to tell DebugView to "Capture Kernel" in the Capture menu. And if you use Windows Vista or later, you will need to modify your registry a bit: Create or open the registry key [code:1:ca7b45658e]HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter[/code:1:ca7b45658e] Under this key, create a value with the name DEFAULT type REG_DWORD and value 0xFFFFFFFF. Then restart your computer.

U:

Tue Apr 27, 2010 9:49 am

No change.

tzuk:

Tue Apr 27, 2010 12:30 am

There is one more option, try to add OpenWinClass=$:Setpoint.exe OpenWinClass=$:KHALMNPR.EXE in addition to the OpenWinSlass settings that you already have.

U:

Mon Apr 26, 2010 10:30 pm

Adding any or all of those RPC Controls makes no difference. The "*" under Window Access does allow me to scroll. WinSpy++ showed the following classes for both Setpoint.exe and KHALMNPR.EXE and I added all of them, without success: OpenWinClass=LOGI_DEVICE_LISTENER OpenWinClass=KodiakHiddenWndClass OpenWinClass=KHALHIDC_MainWindow OpenWinClass=KHALMOU_MainWindow OpenWinClass=KHALHIDN_MainWindow OpenWinClass=KHALHIDM_MainWindow OpenWinClass=KHALUSB_MainWindow OpenWinClass=KHAHLHPP_MainWindow OpenWinClass=KHALITouch_MainWindow OpenWinClass=KHALMouseware_MainWindow OpenWinClass=KHALMainProcessWindow

tzuk:

Mon Apr 26, 2010 9:00 pm

OK, then would you like to see which particular resources need to be excluded? I will again point you to that other topic, this time to this post in particular - http://www.sandboxie.com/phpbb/viewtopic.php?p=51232#51232 The idea in that post is to begin to narrow down the exclusions, it seems to progress well in the Synaptics issue, might be appropriate here as well.

U:

Mon Apr 26, 2010 10:26 am

Assuming you were referring to the Screen Reader option under Accessibility, enabling it allows me to scroll horizontally. Looks like the two problems are more similar than I thought.

tzuk:

Sun Apr 25, 2010 10:44 pm

There is a somewhat similar topic going on now, about Synaptics scrolling, please check if some of the approaches discussion there apply in your case as well. http://www.sandboxie.com/phpbb/viewtopic.php?t=7585

U:

Sat Apr 24, 2010 11:07 pm

Forgot something. :evil: I am using Sandboxie 3.45.07. You can merge/delete this post.

U: Horizontal scrolling inoperable with Maxthon

Sat Apr 24, 2010 10:57 pm

Using Logitech Setpoint 4.60 with Maxthon 2 and trying to perform "right/left scroll" with the mouse, the window of Maxthon will lose focus and nothing else happens. No other programs I've tested have this problem. Adding "LOGI_STROMBOLI_WND_CLASS" to the OpenWinClass for the Sandbox also didn't change anything. Any ideas what might be wrong?