Re: Explorer is leaking memory and eating CPU

On Wed, 27 Sep 2006 18:55:18 +0300, "George Valkov" <a@xxxxx> wrote:
"cquirke (MVP Windows shell/user)" wrote in
On Mon, 25 Sep 2006 11:54:42 +0300, "George Valkov" wrote:

The problem will only occure some rare times, and I assosiate it with
audio-video edditing tools or codecs. The last time only SoundForge and
VirtualDubMod was running. MPEG2 codecs are the ATI build of Cyberlink.
and AVI codec (for both video and audio) is ffdshow. It's most likely that
explorer and ffdshow don't like each other, so I'd like to disable
thumbnail preview and any other code that is trying to open AVI files in
explorer, when I select or drag them.

Or even list them...

By design, 3rd-party integrations into Explorer are permitted, and may
show up as "Explorer" rather than their own names in Task Manager,
firewalls, etc. These integrations can run whenever you list files

They also create context menus and other tasks. There`re the extentions
installed in the registry as handlers, explorer calls the appropriate method
from some DLL library and so on. As long as one knows how to, he/she can do
a lot of things with this technology - for either good or bad reasons.

The problem with them is that they exceed the user's intentions. A
user may list and select a file intending to delete it, knowing that
it's suspicious, and here we have the shell groping around inside the
file's contents on the ASSumption the user wants to "open" it.

In an age where we still expected code to do only what it was written
to do, this might be safe - i.e. you could say with a straight face
that "we're only looking at some data fields, it's not as if we're
going to run any code from the file".

But today, we should be aware that any code may turn out to be
exploitable, and once that hapens, what we designed the code to do is
completely irrelevant to what it can be exploited to do.

The other more mundane objection is one of performance, especially
when the file isn't structured as it should be. We saw this ages ago
with large corrupted .AVI files, where the shell would wade through
the entire file from one end to the other, looking for some metadata
tags that we prolly couldn't be bothered with anyway.

A single file like that may drastically slow down any listing on the
folder that contains it.

Malware authors have noted this and make use of it, though not as
often as the more traditional startup integration points.

And the bad news here is that these malare are harder to track and clean
manually (if you only check the Run locations in the registry). Handlers are
a powerfull tool, so let's hope most bad guys won`t notice ;-)

I'd rather see us equipped with management tools before then... the
Nirsoft functionality should be built into MSConfig, really.

See www.nirsoft.net (not the .com site!!) for suitable tools to manage
codecs and shell integrations (Shell Extension Viewer), as MSConfig
and HiJackThis don't patrol this part of the perimiter fence :-)

I`ve been using NirSoft`s tools for a few years. As I just replayed to Ken
Zhao, Your idea to use the Shell Extension Viewer, just pointed me to the
right place: Avi Properties Handler ::disable(). Thank You!

Cool!

Malware codecs are around, and formal malware scans (e.g. from a Bart
CDR boot) is the best way to approach that. If used with the
RunScanner plugin, you can use most registry-orientated NirSoft tools
including Shell Extension Viewer, but listers of drivers and services
may give misleading results based on runtime observations that will
reflect the Bart rather than the HD OS environment.

I like BartPE. By the way do You know of a way to enable UDF read/write
support while in BartPE?

No I don't... I don't use CD writing from Bart because Bart dies if I
eject the disk it's running from. There are two ways around that:
- add a second CD or DVD writer drive
- boot Bart off USB or RAMdisk instead of CDR or DVDR

The latter is something of a "holy grail" in the Bart world. A core
issue is that when NT versions older than Server 2003 (or perhaps it
is Server 2003 SP1) will reset the USB during the OS startup process,
which basically amputates the OS's head at that point.

The solutions I've read about, involve either using Server 2003 or
later code base (alas, XP SP2 is too old) as this doesn't reset the
USB, and/or throwing the whole OS into a RAM disk and then actually
booting it from there (which will need a fair bit of RAM).

I haven't tested MS WinPE older than the 2.0 version that is built
into Vista, but the Vista one works quite well in this respect - the
OS has a different drive letter to the DVD drive it booted from, and
you can eject the Vista installation DVD without crashing it. I know
that Vista is built from post-2003 code base, so there's one less
obstacle to booting it in nOS form from a USB stick.



------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
------------ ----- --- -- - - - -
.