Any anti-malware software that can scan the registry of a slaved drive?

[Virus Guy]

Is there any anti-malware software that can properly scan a slaved drive
from another system - to treat it as if it was the primary, operational
drive during the scanning session?

Specifically, to scan the registry files contained on the slaved drive?

 

[Victek]

Is there any anti-malware software that can properly scan a slaved drive
from another system - to treat it as if it was the primary, operational
drive during the scanning session?

Specifically, to scan the registry files contained on the slaved drive?

..
That's a great question. I often remove an infected drive and put it in an
enclosure as a way of bypassing the malware. It would be nice to be able to
clean the registry at the same time instead of having the scan the drive
again when it's back in the system and booted. An alternative would be a
registry editor that could open the files on the slave drive so you could at
least kill the auto-starting entries.

 

[PajaP]

.
That's a great question. I often remove an infected drive and put it in an
enclosure as a way of bypassing the malware. It would be nice to be able to
clean the registry at the same time instead of having the scan the drive
again when it's back in the system and booted. An alternative would be a
registry editor that could open the files on the slave drive so you could at
least kill the auto-starting entries.

What is wrong with using the registry editor built into windows
(regedit) and loading the hive of the system and users?
Just don't forget to unload them when done

 

[tommy]

Is there any anti-malware software that can properly scan a slaved
drive from another system - to treat it as if it was the primary,
operational drive during the scanning session?

Specifically, to scan the registry files contained on the slaved
drive?

Registry files are stored in %SystemRoot%\System32\Config
use the context menu scan option , after identifying and selecting the
folder shown above "config"

 

[David H. Lipman]

From: "Virus Guy" <[email protected]>

| Is there any anti-malware software that can properly scan a slaved drive
| from another system - to treat it as if it was the primary, operational
| drive during the scanning session?

| Specifically, to scan the registry files contained on the slaved drive?

No. Not really. You would have to load the hives of the affected drives into the running
OS of the surrogate PC. I know of no software that will do that. Additionally any anti
malware scanner will acatully be examining the Registry of the surrogate PC.

However, you don't need to because if you remove the actual malware from the affected
drive then when the drive is returned to the affected platform, the registry will not load
the malware into the OS because it would presumably be no longer present.

Of course there is always the possibility in the above scerario that you remove the
malicious file from the affected drive but the file was REQUIRED to be loaded into the OS
upon boot and when the drive is placed back into the affected platform, the PC will boot
into a BSoD condition indicating a required file could not be found.

An example being a SubSys trojan loaded via...
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\windows

and would generate a stop error as in...
STOP: c0000135 {Unable To Locate Component}

 

[Virus Guy]

| Specifically, to scan the registry files contained on the slaved
| drive?

No. Not really. You would have to load the hives of the affected
drives into the running OS of the surrogate PC. I know of no
software that will do that.

Is there something fundamental about accessing and processing a
"non-loaded" registry hive that prevents third-party scanning software
from examining and even correcting the registry hive? Are hive
structures either so proprietary or so complex to make that task
impossible?

Additionally any anti malware scanner will acatully be
examining the Registry of the surrogate PC.

As they (most? all?) are written now, yes, that's how they work.

I'm wondering if there are any that can operate on a known-slaved drive
from a suspect machine.

I can't be the only one to see the value of the technique of scanning
and correcting a drive that's being accessed in slave-mode, as opposed
to one that's operating. I would think that ridding a drive of malware
is best done when it's being accessed as a slave, just as the best way
to repair your car is when it's parked with the engine turned off.

However, you don't need to because if you remove the actual
malware from the affected drive then when the drive is
returned to the affected platform, the registry will not load
the malware into the OS because it would presumably be no
longer present.

In theory - yes. In practice, it seems that there is no malware that
can detect 100% of viral/trojan binaries. So being able to remove the
various mal-planted auto-run keys in a slaved registry would seem to be
a desirable feature of any anti-malware application.

Of course there is always the possibility in the above scerario
that you remove the malicious file from the affected drive but
the file was REQUIRED to be loaded into the OS upon boot and
when the drive is placed back into the affected platform, the
PC will boot into a BSoD condition indicating a required file
could not be found.

So presumably when the drive is slaved and the "required" (but viral)
file deleted, that at the same time if the reference to the file was
removed from the slaved registry that the outcome you suggest would not
happen.

 

[Virus Guy]

Registry files are stored in %SystemRoot%\System32\Config
use the context menu scan option , after identifying and selecting
the folder shown above "config"

How does that help to answer my question?

 

[Virus Guy]

What is wrong with using the registry editor built into windows
(regedit) and loading the hive of the system and users?
Just don't forget to unload them when done

How do I load the hive(s) from a slaved drive into regedit and then tell
my anti-malware software to scan the loaded registry instead of the host
system registry?

 

[David H. Lipman]

From: "Virus Guy" <[email protected]>


| Is there something fundamental about accessing and processing a
| "non-loaded" registry hive that prevents third-party scanning software
| from examining and even correcting the registry hive? Are hive
| structures either so proprietary or so complex to make that task
| impossible?

All anti malware scanners presume that they are installed on the OS that is affected.
They are not designed to be used on surrogate PCs scanning hard disk of other OS'
and thus loading their respective registry hives.

| the surrogate PC.

| As they (most? all?) are written now, yes, that's how they work.

| I'm
| wondering if there are any that can operate on a known-slaved drive
| from a suspect
| machine.

NONE!


| I can't be the only one to see the value of the technique of scanning
| and
| correcting a drive that's being accessed in slave-mode, as opposed
| to one that's
| operating. I would think that ridding a drive of malware
| is best done when it's being
| accessed as a slave, just as the best way
| to repair your car is when it's parked with
| the engine turned off.

| In theory - yes. In practice, it seems that there
| is no malware that
| can detect 100% of viral/trojan binaries. So being able to remove
| the
| various mal-planted auto-run keys in a slaved registry would seem to be
| a
| desirable feature of any anti-malware application.

| So presumably when the drive
| is slaved and the "required" (but viral)
| file deleted, that at the same time if the
| reference to the file was
| removed from the slaved registry that the outcome you suggest
| would not happen. Otcome you suggest would not happen.

No it does happen, I've seen it.

The DLL would be named such as; base????32.dll (ex. basevml32.dll)
This is a SubSys trojan and with this trojan, it would be inserted into the following
registry key;
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\windows
and would become part of a DLL load chain. The name of malware DLL would be inserted ito
the registry key (such as; ServerDll=basevml32) . If you deleted the trojan by putting
the drive in a surrogate PC or by using the Recovery Console the PC would boot into a BSoD
complaining that the DLL could not be found.

Example NT Stop Error:
STOP: c0000135 {Unable To Locate Component}
This application has failed to start because basevml32 was not found.
Re-installing the application may fix this problem.

It loads via...
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\windows

Example of text in an infected PC:
-----------------------------------
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512,512
Windows=On SubSystemType=Windows ServerDll=basevml32,1
ServerDll=winsrv:UserServerDllInitialization,3
ServerDll=winsrv:ConServerDllInitialization,2
ProfileControl=Off MaxRequestThreads=16

Example of correct text:
----------------------------
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512,512
Windows=On SubSystemType=Windows ServerDll=basesrv,1
ServerDll=winsrv:UserServerDllInitialization,3
ServerDll=winsrv:ConServerDllInitialization,2
ProfileControl=Off MaxRequestThreads=16

The above is a real world example taken from my notes. The ONLY way to fix it is either
copy
basesrv.dll to basevml32.dll in the Recovery Console or preferrably load the infected OS
and edit the registry and reboot then delete basevml32.dll.

I mention the above because many presume placing an affected drive in a surrogate PC is
one of the best ways to deal with removing malware that may be loaded at run-time.
However, if you do, when you run the Anti malware software it will not correct the
registry of the OS of the affected drive and may leave the OS of the affected drive
impotent. I am NOT saying placing an affected drive in a surrogate PC is not a good
methodology. I am saying that it can have drawbacks and you must be prepared for them.

An advantage of placing an affected drive in a surrogate PC is that if there is a RootKit
that employs stealth and blocks anti malware scanners running on the affected PC, running
scanners on a surrogate PC will be able to remove the malware without activity of the
RootKit's capability.

If you place an affected drive in a surrogate PC expect it ONLY to work at the file level
disk level and not affect the Registry. Once you have scanned the drived with a few good
On Demand scanners then place the drive backing to the affected PC and use MBAM and other
anti malwre scanners within the affected PC's OS to remove illegitimate registry
modifications.

 

[Virus Guy]

All anti malware scanners presume that they are installed on the
OS that is affected.

I fully undertand that - although your "all" proviso leaves no doubt
about it, and so far nobody else has suggested that there is even one
scanner that can do what I'm asking about.

But your statement does not answer the question:

| Are hive structures either so proprietary or so complex to make
| that task impossible?

I mention the above because many presume placing an affected
drive in a surrogate PC is one of the best ways to deal with
removing malware that may be loaded at run-time. However, if
you do, when you run the Anti malware software it will not
correct the registry of the OS of the affected drive and may
leave the OS of the affected drive impotent.

Hence my question as to whether or not the "next frontier" of AM
(anti-malware) software would be to have the ability to scan and correct
the registry present on a slaved drive.

I am NOT saying placing an affected drive in a surrogate PC is
not a good methodology. I am saying that it can have drawbacks
and you must be prepared for them.

Would it not be possible to run a system in safe mode and therefor not
experience the BSOD in your example?

An advantage of placing an affected drive in a surrogate PC
is that if there is a RootKit

In my case, it seems that the malware in question was preventing me from
(re)installing and running NAV (and even the task manager) but not
MBAM. We know that it's fairly common for malware to have an in-built
list of file names and processes to interfere with and prevent proper
operation.

To your knowledge, is MBAM on such lists?

If you place an affected drive in a surrogate PC expect
it ONLY to work at the file level disk level and not
affect the Registry.

That is already a given, and was presumed in my first post in this
thread.

I'm asking if there are technical reasons why "external" registry files
could not accessed and manipulated by third-party software.

I'm suggesting that the functionality of AM software could be enhanced
and their utility and desirability increased by having this ability.

 

[tommy]

How does that help to answer my question?

I was thinking you could scan a networked drive from your original.
Sorry, I can't remember whether you can scan a networked drive or not with
an AV.
You might have to make a copy on a thumbdrive, then scan it, then replace
the original with the corrected one.
But it wouldn't be operational, but I know techs that use this technique all
the time.

 

[Virus Guy]

I was thinking you could scan a networked drive from your original.

And how could I trust that scanning an infected PC over a network would
result in ridding the PC of malware, and also cleaning that PC's
registry? An infected PC will most likely actively interfere will all
scanning and disinfection attempts, whether they are run locally or
remotely.

You might have to make a copy on a thumbdrive, then scan it,
then replace the original with the corrected one.

A copy of what? The infected drive, or just the registry from the
infected drive?

How would that help (or be different) vs just removing the infected
drive and slaving it to a trusted host?

But it wouldn't be operational, but I know techs that use this
technique all the time.

Ask them how they scan the registry of the infected source drive. There
is apparently no AV/AM software that does this.

 

[David H. Lipman]

From: "Virus Guy" <[email protected]>


| I fully undertand that - although your "all" proviso leaves no doubt
| about it, and so far nobody else has suggested that there is even one
| scanner that can do what I'm asking about.

| But your statement does not answer the question:

|| Are hive structures either so proprietary or so complex to make
|| that task impossible?

| Hence my question as to whether or not the "next frontier" of AM
| (anti-malware) software would be to have the ability to scan and correct
| the registry present on a slaved drive.


Can't speak to to future developments.

| them.

| Would it not be possible to run a system in safe mode and therefor not
|
| experience the BSOD in your example?
mple?


No.

| RootKit

| In my case, it seems that the malware in question was preventing me from
|
| (re)installing and running NAV (and even the task manager) but not
| MBAM. We know that
| it's fairly common for malware to have an in-built
| list of file names and processes to
| interfere with and prevent proper
| operation.

| To your knowledge, is MBAM on such lists?
such lists?


Definitely !
Example; TDSS/TDL3

| That is already a given, and was
| presumed in my first post in this
| thread.

| I'm asking if there are technical reasons
| why "external" registry files
| could not accessed and manipulated by third-party
| software.

| I'm suggesting that the functionality of AM software could be enhanced
| and their utility and desirability increased by having this ability.

I doubt it will EVER exist by major software manuafcturers.

If some bright white hat programmer can/will do it in the future ? Maybebut, I ahve my
doubts.

 

[David W. Hodgins]

Hence my question as to whether or not the "next frontier" of AM
(anti-malware) software would be to have the ability to scan and correct
the registry present on a slaved drive.

It would be very difficult (although not impossible). Consider
a slave drive with multiple m$ operating systems installed.
While the user could be asked which partition should be used
as the main system to look at, any partitions mounted as drives
by that system, would have different hardware addresses, so
it would be a problem figuring out which partitions were being
referenced, by which drive letters in the slave os.

Accessing the registry is done using calls to m$'s api (application
programming interface), which keeps track of which data goes in
which file, and, takes care of any changes between versions. M$
loves to make little tweaks that breaks backward compatibility.

Either the scanner would have to know about the changes between
service pack/os levels, or it would have to load the dll files from
the slave os in a virtual computer, which would defeat the purpose
of slaving the drive, as those files may have been corrupted by
the malware.

Much easier to backup the data, and replace the os with linux.

Regards, Dave Hodgins

 

[tommy]

And how could I trust that scanning an infected PC over a network
would result in ridding the PC of malware, and also cleaning that PC's
registry? An infected PC will most likely actively interfere will all
scanning and disinfection attempts, whether they are run locally or
remotely.

I didn't say it was desirable, just that I thought thats what you wanted to
as a way of scanning that registry.

A copy of what? The infected drive, or just the registry from the
infected drive?

How would that help (or be different) vs just removing the infected
drive and slaving it to a trusted host?

Its just another approach that comes to mind.
You yourself asked if there was a way to scan another registry on another
drive.
Don't you think you could scan the registry if it is on another drive, thumb
or slaved?

Ask them how they scan the registry of the infected source drive.
There is apparently no AV/AM software that does this.

I thought I just finished explaining how to do it.

 

[PajaP]

How do I load the hive(s) from a slaved drive into regedit and then tell
my anti-malware software to scan the loaded registry instead of the host
system registry?

Sorry, I was not replying to you directly.

I was replying to:
"An alternative would be a registry editor that could open the files on
the slave drive so you could at least kill the auto-starting entries".

My answer "What is wrong with using the registry editor built into
windows (regedit) and loading the hive of the system and users?" was
intended to provide a means to 'manually delete startup entries. I doubt
if anti-malware software would look at these hives?

 

[FromTheRafters]

.
That's a great question. I often remove an infected drive and put it
in an enclosure as a way of bypassing the malware. It would be nice
to be able to clean the registry at the same time instead of having
the scan the drive again when it's back in the system and booted. An
alternative would be a registry editor that could open the files on
the slave drive so you could at least kill the auto-starting entries.

Couldn't you load the hive in regedit then export it to a regfile and
then edit the regfile to your hearts content?
(I don't know, I'm just asking)

If you're at a point where slaving to drive is the easy way, then the
registry is not the worst of your problems.

Often it is easy enough to avoid the malware becoming active by booting
from alternate (read only?) media and scanning for malware from there.
This "content" scanning is mostly concerned with program files, not data
files like the registry. Once the malware "programs" are dealt with,
then "context" scanning (usually to help with malware "identification"
not strictly with detection - except where heuristic methods are used)
is used to collect data as an aid to removal. When gathering data to aid
in "removing" the malware, you will want the actual environment to be
the context, not some new clean host environment.

 

[Virus Guy]

It would be very difficult (although not impossible). Consider
a slave drive with multiple m$ operating systems installed.

I wasn't considering "multiple OS's" on the slaved drive. But ok, you
want to consider that situation for some reason - go ahead.

While the user could be asked which partition should be used
as the main system to look at, any partitions mounted as
drives by that system, would have different hardware
addresses

Different hardware addresses?

Since when does a hard drive appear as a "hardware address" to an OS?

so it would be a problem figuring out which partitions were
being referenced, by which drive letters in the slave os.

If a malware scan of the slaved drive reveals a list of detected
mal-files, and if a scan of the registry of the slaved drive turns up
references to those mal-files, then those registry keys can be deleted
without needing to understand the full-path to the mal-files as it
appears in the registry.

Likewise, if the AM software has it's own list of known mal-files, and
if it normally deletes registry entries containing those files, then
again there is no need to understand full-path to the mal-files as it
appears in the registry.

Accessing the registry is done using calls to m$'s api
(application programming interface), which keeps track
of which data goes in which file, and, takes care of any
changes between versions. M$ loves to make little tweaks
that breaks backward compatibility.

If that's the case, then that would be a technical barrier for AM
software to be able to scan and correct non-host registry files.

 

[Virus Guy]

Its just another approach that comes to mind. You yourself
asked if there was a way to scan another registry on
another drive.

Don't you think you could scan the registry if it is on
another drive, thumb or slaved?

The issue does not seem to be what form (or on what media) the external
registry files are presented to the AM software. The issue is that it
may not be possible for any third-party software to be able to read
registry files without the help of underlying Windows system calls and
functions. And such calls and functions apparently can only be
performed against the host's registry, not the registry as contained on
a slaved drive (or a thumb drive, what-ever).

I thought I just finished explaining how to do it.

No, you explained that registry files from a suspect machine could be
transported to a trusted host via thumb drives or some other media. You
did not explain if (or how) third-party AV/AM software can actually read
and manipulate them.

 

[Virus Guy]

Couldn't you load the hive in regedit then export it to a regfile
and then edit the regfile to your hearts content?
(I don't know, I'm just asking)

In a recent situation where I had MBAM operate on an infected system, I
would not want to manually edit the registry on a slaved drive if I'm
dealing with > 700 registry entries.

If you're at a point where slaving to drive is the easy way,
then the registry is not the worst of your problems.

If you slave a drive to a host system, an AV/AM scan will never detect
100% of the mal-files on the slaved drive by simply file-signature
analysis.

It's my opinion that the most useful and reliable function that AV/AM
software can perform against an infected system is to analyze (and
manipulate) it's registry, and that most systems are restored to
operational status more because of mal-keys and mal-data removed from
the registry rather than mal-files detected on the file-system.

Often it is easy enough to avoid the malware becoming active
by booting from alternate (read only?) media and scanning
for malware from there.

That is just another way to scan the drive without the drive's native or
installed OS being active. And it still doesn't address the issue that
the registry is not scanned and can still cause re-infection or
mal-operation when the system is re-started.