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

[FromTheRafters]

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.

Yeah, that really *would* be a PITA.

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.

True, and the registry could still cause the undetected malware to load.
The key to detecting malware is...well ..the ability to detect malware.

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.

And *that* they do (scan "the registry"), but when the registry data
structure's data is stored on disk it is a binary data file requiring
manipulation upon boot to build the data structure known as "the
registry". I think what you suggest could possibly be done, but at what
cost - and for what benefit? It is still only data that undetected
malware would have to be leveraging.

That is just another way to scan the drive without the drive's native
or
installed OS being active.

Yes, and it doesn't require another computer at all.

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.

Only if there is a failure to detect the malware using the registry as a
start method or as a repository for (possibly hidden) code.

This may interest you.

http://www.sentinelchicken.com/data/TheWindowsNTRegistryFileFormat.pdf

 

[David W. Hodgins]

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

I have 3 versions of linux, win 98, win Xp, and windows 7 rc all
installed in different partitions, on two physical hard drives,
plus another half dozen systems installed in virtual drives.

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

Since always! The bios requires a hardware address to figure out
which drive you want to access. With m$ software, the drive letter
is translated into a device number, and then it uses the fat or
ntfs directory to get a sector address, based on which partition
you are accessing. (Assuming a recent drive controller that uses
lba or lba48 addressig. Older drives required a cylinder/head/
sector address).

M$ chose to use drive letters to id partitions. Take a system with
one hard drive, with one primary partition, and multiple extended
partitions. Add a new hard drive with one primary partition. Surprise,
surprise, the new primary partition becomes drive d:, while what was
drive d: previously, now becomes drive e:. All registry entries that
refer to files on drive d: will now be invalid.

Older versions of linux had similar problems when adding a new device
changed the device name of an existing device (rarely happens).
Current versions use the uuid or label of the partition, to figure out
what partition should be mounted on a given directory name.

If you have a hard drive connected to the first ide channel, with
the jumpers set to master, it will be seen by the bios as drive 80
(hex). If it's connected via a usb external drive, it will be seen
with a different hardware address. Which hardware addresses are
seen as which drive letters, in any m$ os, depends on what was
connected when the system was booted, assuming no bios translation,
or boot loader translation.

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.

Registry entries use drive letters to figure out the path to the
file. A host os has no way to figure out which drive letters
in a slaved os referred to which drives/ partitions. Since the
host os by definition, has the hard drives connected in a different
order, there is no way to relate drive letters to the correct
partitions.

What if the malware installs it self in drive e:? The registry
entries will all refer to drive e, but the os that has that drive
temporarily slaved as drive j, will not have any way of knowing
what partition the slave os called drive e.

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.

Again, the os running the am software has no way of knowing which
partitions should correspond to the drive letters in the slave os,
even assuming only one os on the slave drive. What was drive c:
on the slave os may be drive d:, e:, etc, on the host os.

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.

Correct. Any AM software trying to scan a slaved drive would have
to be using software developed by m$, or it's developers would have
to reverse engineer every update ever released by m$, to see which
ones changed what is stored in which files to make up the registry.

The malware scanner would have to know which drive(s) were installed
in the slaved os, and what type of hardware connectors were used,
in order to guess which partitions had which drive letters, when
booted from the slave os.

It would be relatively easy to write a malware scanner that assumes
the slave drive only has one partition, that should be treated as
the c: drive, (assuming the registry format doesn't change between
os/service pack levels -- False assumption). While that would handle
the bulk of the systems currently in use, it wouldn't work in any
other cases.

Regards, Dave Hodgins

 

[Virus Guy]

If you have a hard drive connected to the first ide channel,
with the jumpers set to master, it will be seen by the bios
as drive 80 (hex).

That is a logical address. Not a "hardware address". The only
addressable hardware in the path between the OS and the file system is
the drive controller (be it IDE, SATA, USB, Firewire, SCSI, etc).

Drives themselves are not directly accessible as I/O mapped devices on a
PC's expansion bus.

But all this is moot. The typical use-case situation is a single hard
drive running a single OS attached to the primary IDE channel of a
suspected infected PC.

Registry entries use drive letters to figure out the path to
the file. A host os has no way to figure out which drive
letters in a slaved os referred to which drives/ partitions.

AM software analyzing a slaved registry does not need to "figure out"
the drive lettering scheme contained in the slaved registry if a
suspicious registry entry is going to be deleted. If the AM software
wants to find the file being referenced by the suspicious entry, I don't
see why that would be hard to do. The slaved drive will usually be the
D drive, and if the suspect file would be pathed as "c:\what-ever". The
AM software will simply subtitute "d:\what-ever" and look there for the
suspect file. Or it can simply search the entire slaved drive until it
finds the suspect file.

What if the malware installs it self in drive e:? The
registry entries will all refer to drive e, but the os
that has that drive temporarily slaved as drive j, will
not have any way of knowing what partition the slave os
called drive e.

All the AM software needs to do is perform a search of the entire slaved
drive for the path-spec being referenced by the suspicious registry
entry. If the malware was installed in e:\here\is\malware\malfile.exe
(as it appears in the slaved registry entry) then look for the path
here\is\malware on the slaved drive. It might be found in the G drive.
That tells the AM software that the real E drive has been mapped to the
virtual G drive for the purposes of this scanning session.

Again, the os running the am software has no way of knowing
which partitions should correspond to the drive letters in
the slave os, even assuming only one os on the slave drive.
What was drive c: on the slave os may be drive d:, e:, etc,
on the host os.

The AM software can bring up a list of drives attached to the host
system and ask the user which drive is the slaved drive to be scanned.
That automatically tells the AM software which logical drives belong to
the host machine and which ones belong to the slaved drive. The AM
software then knows which logical drives to scan when looking for
mal-files.

The malware scanner would have to know which drive(s) were
installed in the slaved os, and what type of hardware
connectors were used, in order to guess which partitions
had which drive letters, when booted from the slave os.

Again I disagree with that (see preceeding explanation).

Like I said, once the user identifies the slaved drive to the AM
software, the logical drive-letter assignments are knowable to the AM
software for the slaved drive. If the slaved registry contains a
reference to d:\this\directory\malfile.exe, then the AM software can
simply substitute every logical drive letter assigned to the slave drive
until it finds the correct path-spec.

For example, what was the d drive on the infected system becomes the g
drive on the logically-slaved host system. Therefore, a search for the
path \this\directory\malfile.exe will be found on the g drive. The AM
software will then know that D maps to G, and can proceed on that basis.

 

[Victek]

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.

Yes, but it may be enough to just delete the auto-start entries. Then the
drive can be booted in the original system and the user can control the OS
sufficiently to do the remaining cleanup. In fact I was able to
successfully clean a system recently without removing the drive because the
malware didn't block access to regedit - I killed the auto-start entries and
the rest was easy.

 

[Virus Guy]

Yes, but it may be enough to just delete the auto-start entries.
In fact I was able to successfully clean a system recently without
removing the drive because the malware didn't block access to
regedit - I killed the auto-start entries and the rest was easy.

I'm not saying that you can't perform any necessary or useful registry
changes on an infected system when the system (and it's malware) is
still running, regardless if you do it manually with regedit or
automatically with AM software.

All I'm saying is that it would be nice if there was AM software that
could scan and manipulate the registry on a slaved drive and
remove/repair suspicous registry entries on the slaved drive just as
compentently, easily, automatically and completely as if it was
operating on the host's registry.

If I went further, I'd say that trying to repair an infected system
while it (and it's malware) is still running is *usually* dicey,
problematic, and leaves you wondering if you actually got all the bad
stuff off the system. That's why the very first thing I do when I
encounter a suspected-infected system is remove the drive and scan it as
a slave attached to a trusted malware-free system.

 

[FromTheRafters]

Yes, but it may be enough to just delete the auto-start entries. Then
the drive can be booted in the original system and the user can
control the OS sufficiently to do the remaining cleanup. In fact I
was able to successfully clean a system recently without removing the
drive because the malware didn't block access to regedit - I killed
the auto-start entries and the rest was easy.

Also, once you assume that a malware program file is not detected on the
drive, that malware program may be invoked by a completely legitimate
registry start method. That is to say that "infection" can be used as a
startup method by infecting a legitimate registry invocation's target.

First and foremost, you must be able to detect and identify malware in
order to remove malware. Failing that, registry entry pruning is often
pointless.

 

[FromTheRafters]

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.

A minor point perhaps, but consider...

On Win98 one could place a malware file in system32 (IIRC) and name it
rundll32.exe. Finding that malware file on disk would not give you
"carte blanche" to remove all registry entries that call it. As I
recall, some registry entries explicity called the 'run dll as exe'
explicitly (from "system" - no problem there - but others
(LoadPowerProfile) didn't and ran the one in "system32" instead (I
always just assumed this was because of the "working directory" being
system32 rather than "system" but never actually checked it out).

Just for kicks, copy "notepad.exe" as "rundll32.exe" in the System32
directory. Eventually, notepad will appear complaining that it can't
find "LoadPowerProfile" (notepad thinks that the "LoadPowerProfile"
argument is a text file that you want opened). Cleaning all references
to "rundll32.exe" from the registry will probably give you less than
optimal results.

 

[Char Jackson]

M$ chose to use drive letters to id partitions. Take a system with
one hard drive, with one primary partition, and multiple extended
partitions. Add a new hard drive with one primary partition. Surprise,
surprise, the new primary partition becomes drive d:, while what was
drive d: previously, now becomes drive e:. All registry entries that
refer to files on drive d: will now be invalid.

If that relatively straightforward behavior surprises you, you might
be stunned to learn that MS gives you tools to change/rearrange your
drive letters as you see fit, at any time. It's only a few mouse
clicks in Administrative Tools.

But the bottom line is, as others have said, that slaving a drive
should cause no great confusion to a scanning procedure. It's not like
the entire path has magically changed; only the drive letter has
changed. No big deal.

 

[FromTheRafters]

If that relatively straightforward behavior surprises you, you might
be stunned to learn that MS gives you tools to change/rearrange your
drive letters as you see fit, at any time. It's only a few mouse
clicks in Administrative Tools.

But the bottom line is, as others have said, that slaving a drive
should cause no great confusion to a scanning procedure. It's not like
the entire path has magically changed; only the drive letter has
changed. No big deal.

I think that the main stumbling block here is 'is it worth doing?'.

I believe that it should be possible for an AM program to mimic the OS
insofar as to translate the binary data files into a data structure like
the OS does. Once done, that structure can be parsed in whatever manner
the AM program desires. Changes can be made to the data and then the
program can mimic again for the the storage of the now modified files in
their binary data format.

All of this because someone wants to clean it while the drive is hosted
on another hardware platform rather than cleaning it on another software
platform on the same hardware.

Maybe you could use the registry data to find an undetected malware
file, maybe you could clean the registry without having to load it back
on the victim machine by identifying the actual malware file and looking
for references to it in the registry. I just don't see the advantage to
slaving the drive over just booting clean I guess.

 

[The Central Scrutinizer]

Holy crap... You are in big f-ing trouble here

 

[The Central Scrutinizer]

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.

An AVAST BART boot CD probably would... When you boot up, it does have a
registry
editor. I have used it... It is cool. But you experts probably know better.

 

[David H. Lipman]

From: "The Central Scrutinizer" <[email protected]>



| An AVAST BART boot CD probably would... When you boot up, it does have a
| registry editor. I have used it... It is cool. But you experts probably know better.

A Registry editor does NOT provide the same capability as scanning the Registry.

 

[The Central Scrutinizer]

So does this mean that you have run the avast bart boot CD and found it to
be inadequate for this purpose?

 

[David H. Lipman]

From: "The Central Scrutinizer" <[email protected]>

| So does this mean that you have run the avast bart boot CD and found it to
| be inadequate for this purpose?

It does not fit the requirements identified by Virus Guy.

 

[Dustin Cook]

I'm not saying that you can't perform any necessary or useful registry
changes on an infected system when the system (and it's malware) is
still running, regardless if you do it manually with regedit or
automatically with AM software.

All I'm saying is that it would be nice if there was AM software that
could scan and manipulate the registry on a slaved drive and
remove/repair suspicous registry entries on the slaved drive just as
compentently, easily, automatically and completely as if it was
operating on the host's registry.

I can't say for sure what the technicians version does, but this isn't
something a typical home user would be doing.

If I went further, I'd say that trying to repair an infected system
while it (and it's malware) is still running is *usually* dicey,
problematic, and leaves you wondering if you actually got all the bad
stuff off the system. That's why the very first thing I do when I
encounter a suspected-infected system is remove the drive and scan it

Well, to each his or her own I suppose. I wouldn't risk damaging hardware
to initiate a scan when a PE disk would give me full access to the
affected system and I could have a good look around.

Then again, that is what seperates good technicians from typical hardware
guys playing technician from momies basement; skill. Pure, skill... or
lack of it, in some cases...

 

[Dustin Cook]

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}

And if you really know what your doing; like yourself, this really isn't
an issue. If your playing mr pc fix it, which I'm getting the impression
virus guy here is, then you might be in trouble. yes.

 

[Dustin Cook]

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.


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


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?

Some malware will kill us dead in our tracks, yes.

 

[Dustin Cook]

That is a logical address. Not a "hardware address". The only
addressable hardware in the path between the OS and the file system is
the drive controller (be it IDE, SATA, USB, Firewire, SCSI, etc).

Wow. Dude, seriously. I mean no offense when I say the following:

Stop whatever repairs your doing, close your shop; get books on computer
basic hardware, 101; for ibm pcs and compatables. Do lots of reading. I
suggest you start with the old isa system and work your way up. You really
don't know what's going on....

 

[ASCII]

Some malware will kill us dead in our tracks, yes.

like a mutex for whatever your executable depends?

 

[Toxic]

Some malware will kill us dead in our tracks, yes.

Do you think the often repeated endorsements in this forum of MBAM
place it in the category of squeaky wheel, thereby increasing the
likelihood of it being targeted for crippling attacks?