(PeteCresswell) said:
Per Char Jackson:
That's probably because you know a lot more.
My assumption was that it had already been scanned by something
on my PC and found wanting bco the "Malicious..." message when I
started the download.
I'm totally clueless on the modalities of malicious software.
But, unimpeded by any knowledge, would think that something could
be malicious once unzipped and installed. How would one know if
an application that does something perfectly useful hasn't become
the vector or host for some StuxNet-type code? Yesterday's XYZ
app might be fine. Today's download of the nominally-same app
might be something else altogether.
Seems to me like it comes back to:
- Whether one trusts the supplier or not.
- How confident one is in one's ability to recover
(assuming they even know they're infected...) from
an infection by re-imaging.
I'd venture that most users don't even know what a system image
is - much less have a known good image to recover with.
That brings it down to trust and I think most users would trust
their anti-virus app more than they would trust a source that
they do not know anything about.
That lets your users off the hook, IMHO.
But, now that everybody in this thread as spoken up on behalf of
NirSoft, I guess I'm still on the hook...
Just because something "scans as clean", doesn't mean it's clean.
In the case of NirCmd, when I run it on virustotal, Sophos "detects"
it. When I go to the Sophos site, and look for references to NirCmd,
yes they list it, and they say absolutely nothing about why they
flagged it. It's a PUA (potentially unwanted application), but
they couldn't even be bothered to explain way.
To test NirCmd, I used regedit, exported the registry,
ran the command, then ran regedit and exported the registry
again. I did that in a virtual machine, to protect my main OS.
First off, make sure the command actually does something. If
the command syntax is wrong, nothing happens to the registry.
The NirCmd documentation gives this as an example:
nircmd.exe setdisplay 800 600 24
But in the virtual machine I tested in, the video card can only
go in 16 bit or 32 bit mode. There is no 24 bit, so the command fails.
As given, that command doesn't change the registry.
Once I change it to
nircmd.exe setdisplay 800 600 32
then it actually does something.
This is the kind of entry you'll find in the registry. There are
multiple of these. In this case, the virtual machine has an emulation
of an S3 video chip (a relatively dumb frame-buffer style chip),
and that's noted by the identifier "VPC-S3" for the video card.
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Hardware Profiles\0001\System\CurrentControlSet\SERVICES\VPC-S3\DEVICE0]
"Attach.ToDesktop"=dword:00000001
"DefaultSettings.BitsPerPel"=dword:00000020
"DefaultSettings.XResolution"=dword:00000400
"DefaultSettings.YResolution"=dword:00000300
"DefaultSettings.VRefresh"=dword:0000004b
"DefaultSettings.Flags"=dword:00000000
"DefaultSettings.XPanning"=dword:00000000
"DefaultSettings.YPanning"=dword:00000000
"Attach.RelativeX"=dword:00000000
"Attach.RelativeY"=dword:00000000
The BitsPerPel is hex, and 0x20 is 32 bits per pixel.
XResolution of 0x400 is 1024 decimal width.
YResolution of 0x300 is 768 decimal width.
The NirCmd syntax doesn't include refresh rate (at least,
as given in the example). And the refresh rate of 0x4b is 75Hz.
Whereas, if I'd set it manually, for an LCD I would have chosen 60Hz refresh.
60Hz would be 0x3C hex.
The "XPanning" (not used) could apply to cases where
what the user sees, is a "window" into the entire desktop
surface. For example, with the appropriate hardware and driver
support, I could be looking at a 1024x768 chunk of a 4000x3000 surface.
Some of the video drivers (SIS being one), allow the desktop to
be larger than the display can present, and then when you move the
mouse and bang against the side of the 1024x768 window, the window
"moves" to expose a different view of the 4000x3000 area. It could
be that is what the XPanning and YPanning values are for.
Anyway, that's what NirCmd seems to be changing. The tough part,
is figuring out just which of the multiple sets of those keys,
should be changed.
So you don't have to use NirCmd. You could experiment with
those kinds of registry entries, reboot, and see what resolution
it comes up in. Just be careful to use values that are reasonable,
or be prepared to use a Restore Point to bring sanity to the system.
(Like, go into Safe Mode, restore to a previous sane state, such
that on the next reboot, you can see the screen again.)
Paul