Norton doesn't (or can't) scan "\System volume information\..." path?

[Some Guy]

Connected my win-98 drive to an XP-pro development system to scan the
win-98 drive for trojans/virii (The Cleaner, and NAV from NSW-2002 -
both updated to current def's).

Some viral files were found (harmless- attachements saved from spam
e-mails for manual scanning).

I guess it's XP's habbit of creating \System volume information\ on
every drive connected to it. During a scan by the cleaner it found
this:

D:\System Volume
Information\_restore{EDD79313-3427-47E1-8259-F3CC96419F7F}\Rp36\A0002906.scr

The SCR is MyDoom.A (saved from an e-mail attachment - never
executed).

Basically,

1) how did it end up in that directory, and

2) Why does NAV refuse to scan any subdirectories / files in that
folder, and will only scan that (that particular file) when I drag
it's nose down to the file itself?

3) The Cleaner apparently has no problem scanning all files in that
path (when pointed to the top-level directory) and, funny enough, NAV
intercepts the file when The Cleaner tries to access it.

So why does NAV fear to tread into the \System volume information\
directory tree? Is Rp36 a "restore point" ? Just like the recycler,
seens the \sys vol info\ folder would be a good place for virii and
trojans to hang out (and a very important place for NAV to be able to
scan). ???

 

[kurt wismer]

Connected my win-98 drive to an XP-pro development system to scan the
win-98 drive for trojans/virii (The Cleaner, and NAV from NSW-2002 -
both updated to current def's).

Some viral files were found (harmless- attachements saved from spam
e-mails for manual scanning).

I guess it's XP's habbit of creating \System volume information\ on
every drive connected to it. During a scan by the cleaner it found
this:

D:\System Volume
Information\_restore{EDD79313-3427-47E1-8259-F3CC96419F7F}\Rp36\A0002906.scr

The SCR is MyDoom.A (saved from an e-mail attachment - never
executed).

Basically,

1) how did it end up in that directory, and

microsoft magic... seriously, i have no better explanation for the
internal working of how things are chosen for backing up in system
restore than that...

2) Why does NAV refuse to scan any subdirectories / files in that
folder, and will only scan that (that particular file) when I drag
it's nose down to the file itself?

normally that folder is not accessible... generally speaking one finds
that folder on an ntfs partition (we are talking XP here, after all)
with the permissions set in such a way that only the local system
account can even read it...

3) The Cleaner apparently has no problem scanning all files in that
path (when pointed to the top-level directory) and, funny enough, NAV
intercepts the file when The Cleaner tries to access it.

of course, it intercepts it in a memory buffer, which is exactly how
most detections of system restore contents goes down...

So why does NAV fear to tread into the \System volume information\
directory tree?

because making changes there could really screw things up...

Is Rp36 a "restore point" ?
yes...

Just like the recycler,
seens the \sys vol info\ folder would be a good place for virii and
trojans to hang out (and a very important place for NAV to be able to
scan). ???

unfortunately the risks outweigh the rewards... the consequences of
trying to restore from a restore point that's been corrupted by an
anti-virus (virus 'disinfection' does have a non-negligible chance of
corrupting the host) could be very bad...

 

[Alex Nichol]

Some viral files were found (harmless- attachements saved from spam
e-mails for manual scanning).

I guess it's XP's habbit of creating \System volume information\ on
every drive connected to it. During a scan by the cleaner it found
this:

SVI contains the restore points. While the virus was present, a point
was made that contained it - it can do no harm unless you restore to
that point, but Norton can't get it out. What you do is wait for a new
point to have been made on the clean machine. Then run
Start - All Programs - Accessories - System Tools - Disk Cleanup
and in its More Options click the button to 'Delete all but the most
recent restore point' - the infected one will go taking the virus with
it

 

[GTS]

Connected my win-98 drive to an XP-pro development system to scan the
1) how did it end up in that directory, and

2) Why does NAV refuse to scan any subdirectories / files in that
folder, and will only scan that (that particular file) when I drag
it's nose down to the file itself?

3) The Cleaner apparently has no problem scanning all files in that
path (when pointed to the top-level directory) and, funny enough, NAV
intercepts the file when The Cleaner tries to access it.

So why does NAV fear to tread into the \System volume information\
directory tree? Is Rp36 a "restore point" ? Just like the recycler,
seens the \sys vol info\ folder would be a good place for virii and
trojans to hang out (and a very important place for NAV to be able to
scan). ???

\System volume information\ is used to store System restore points and
Windows will not allow other programs to change these files. They can be
accessed in a read only mode. Infected files may be placed there by the
System Restore process itself. When a virus scanner identifies infection in
that area (which is not all that uncommon once system files are infected),
the usual procedure is as follows:

1. Turn off system restore. (Control Panel/System Restore Tab - check
"Turn off System Restore on all drives") . Windows will remove all saved
restore point files. Reboot.
2. Then turn System Restore on again. Windows will create a new initial
restore point and resume ongoing operation.

(Contrary to the other post in this thread, this has nothing to do with
NTFS. System Restore works the same way with Fat 32 and NTFS drives. Also,
the specifics of what is saved in RP's is documented. Generally it includes
registry changes, system files like dll's which have changed, and other
'system state' data.)

The behaviour you note by NAV seems odd. Other AV programs I use
(particularly ETrust) do scan that full directory and report all infected
files, although they cannot clean it, requiring the process I explained
above.

GTS

 

[Some Guy]

\System volume information\ is used to store System restore points
and Windows will not allow other programs to change these files.

Situation:

Connected a FAT32 drive (D to a system with an NTFS Win-XP pro drive
(C

XP booted and at some point created a \system volume information\
directory on the D drive. While in XP, I can browse, delete, and move
files within the D:\system volume information\ tree at will. I can't
do any of those things with the C:\system volume information\ folder.

You can point Norton to the D:\system volume information\ folder and
tell it to scan that folder, and it will go through the motions, but
it will report 0 (zero) files scanned (there are 2 files there - a
..log file and the .SCR file in question).

The cleaner WILL scan the D:\system volume information\ tree and
apparently Norton will intercept all files accessed from this tree and
scan it before The Cleaner gets it.

They can be accessed in a read only mode. Infected files may
be placed there by the System Restore process itself. When a
virus scanner identifies infection in that area (which is not
all that uncommon once system files are infected), the usual
procedure is as follows:

Using native system functions (my_computer, explorer) can you browse
your C:\system volume information\ folder while running XP?

Will Norton Scan "?:\system volume information\" during a manual or
scheduled scan (it appears the answer is no) or does virus discovery
in that folder depend on some other program accessing files in that
folder (it appears the answer is yes).

(Contrary to the other post in this thread, this has nothing
to do with NTFS. System Restore works the same way with
Fat 32 and NTFS drives.

Clearly the permission structure is different. Again, if a FAT32
drive (D is connected to a computer running XP (C then you _can_
browse, copy, and delete files within the D:\system volume
information\ folder. You can't do the same for the C:\system volume
information\.

The behaviour you note by NAV seems odd. Other AV programs I
use (particularly ETrust) do scan that full directory

I don't have an XP system in front of me currently, so I don't know
the answer to this: Tell Norton to scan your C:\system volume
information\ and look at the report. How many files did it say it
scanned? Zero?

 

[kurt wismer]

GTS wrote:




Situation:

Connected a FAT32 drive (D to a system with an NTFS Win-XP pro drive
(C

XP booted and at some point created a \system volume information\
directory on the D drive. While in XP, I can browse, delete, and move
files within the D:\system volume information\ tree at will. I can't
do any of those things with the C:\system volume information\ folder.

perfectly normal... the ntfs partition (C has file system permissions
that prevent you from accessing it while the FAT32 partition doesn't
support file system permissions so it can't prevent you from accessing
anything...

You can point Norton to the D:\system volume information\ folder and
tell it to scan that folder, and it will go through the motions, but
it will report 0 (zero) files scanned (there are 2 files there - a
..log file and the .SCR file in question).

perhaps norton has been designed to ignore that folder since it's so
often unscannable - just as many anti-virus products are designed to
ignore certain other objects (like the windows swap file)...

[snip]

Using native system functions (my_computer, explorer) can you browse
your C:\system volume information\ folder while running XP?

as a matter of fact you can, but you have to change the permissions on
the folder first...

Will Norton Scan "?:\system volume information\" during a manual or
scheduled scan (it appears the answer is no) or does virus discovery
in that folder depend on some other program accessing files in that
folder (it appears the answer is yes).

by default that is how things normally work, yes...

[snip]

Clearly the permission structure is different.

there are no permissions on the FAT32 drive - FAT32 doesn't support that...