Any anti-malware software that can scan the registry of a slaved drive?
Virus Guy
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
news:4B191A06...@Guy.com...
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
wrote:
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
Registry files are stored in %SystemRoot%\System32\Config
use the context menu scan option , after identifying and selecting the
folder shown above "config"
--
Tommy
David H. Lipman
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}
--
Dave
http://www.claymania.com/removal-trojan-adware.html
Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp
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
How does that help to answer my question?
Virus Guy
> > > Is there any anti-malware software that can properly scan a
> > > slaved drive from another system - Specifically, to scan the
> > > registry files contained on the slaved drive?
>
> 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
| "David H. Lipman" wrote:
>> | 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?
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.
>> 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.
NONE!
| 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
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.
--
Tommy
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
| "David H. Lipman" wrote:
>> 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.
Can't speak to to future developments.
>> 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?
mple?
No.
>> 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?
such lists?
Definitely !
Example; TDSS/TDL3
>> 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.
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
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
tommy
Virus Guy wrote:
> tommy wrote:
>
>> 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.
I didn't say it was desirable, just that I thought thats what you wanted to
as a way of scanning that registry.
>
>> 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?
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?
>
>> 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.
I thought I just finished explaining how to do it.
PajaP
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
news:hfb90q$p7l$1...@news.eternal-september.org...
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
> > 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.
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
> > 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?
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).
> > 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.
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
> > > Is there any anti-malware software that can properly scan a
> > > slaved drive from another system - 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
>
> 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.
FromTheRafters
> FromTheRafters wrote:
>
>> > > Is there any anti-malware software that can properly scan a
>> > > slaved drive from another system - 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
>>
>> 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.
Yeah, that really *would* be a PITA.
>> 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.
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.
>> 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.
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.
>> Accessing the registry is done using calls to m$'s api
> 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.
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.
> > 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.
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
> would not want to manually edit the registry on a slaved drive if I'm
> dealing with > 700 registry entries.
>
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
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
<dwho...@nomail.afraid.org> wrote:
>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
news:ng8oh5l2s8h9740e6...@4ax.com...
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
--
"tommy" <tommyle...@removeyahoo.dropcom> wrote in message
news:hfeih3$r21$1...@news.eternal-september.org...
The Central Scrutinizer
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news:hfc2u...@news3.newsguy.com...
> From: "Virus Guy" <Vi...@Guy.com>
>
> | Is there any anti-malware software that can properly scan a slaved drive
> | drive during the scanning session?
>
>
> 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.
> 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.
:-)
> 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}
>
>
David H. Lipman
| "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
| news:hfc2u...@news3.newsguy.com...
>> From: "Virus Guy" <Vi...@Guy.com>
>> | 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.
A Registry editor does NOT provide the same capability as scanning the Registry.
The Central Scrutinizer
be inadequate for this purpose?
--
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news:hfp6d...@news3.newsguy.com...
David H. Lipman
| 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
> Victek wrote:
>
>> 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.
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 [Malware Researcher]
MalwareBytes - http://www.malwarebytes.org
BugHunter - http://bughunter.it-mate.co.uk
Dustin Cook
> From: "Virus Guy" <Vi...@Guy.com>
>
>| 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
> "David H. Lipman" wrote:
>
>> 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?
Some malware will kill us dead in our tracks, yes.
Dustin Cook
> "David W. Hodgins" wrote:
>
>> 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).
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....
David H. Lipman
| On Sun, 13 Dec 2009 19:35:14 +0000, Dustin Cook wrote:
>> 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?
Doubtful.
More like the success of the software against the Rogues and TDSS.
FromTheRafters
news:Xns9CE094C33E0...@69.16.185.247...
Maybe in the future, antimalware will have to go polymorphic to hide
from the malware - not much different on this side of the fence after
all, eh? :o)
FromTheRafters
news:pan.2009.12...@cdc.gov...
> On Sun, 13 Dec 2009 19:35:14 +0000, Dustin Cook wrote:
>
>
>
> place it in the category of squeaky wheel, thereby increasing the
> likelihood of it being targeted for crippling attacks?
No, I suspect that it is the results that count. If my malware were
discovered, I would investigate what program detected it and work to
defeat that detection. There are probably writers right now compiling
what programs would be best to attack with appkill routines.
Dustin Cook
> Dustin Cook wrote:
>>
>>> To your knowledge, is MBAM on such lists?
>>
>>Some malware will kill us dead in our tracks, yes.
>
> like a mutex for whatever your executable depends?
Yep. Some block by filename, and others actually look for our presence in
memory and show us the door. *shrug*
Dustin Cook
> On Sun, 13 Dec 2009 19:35:14 +0000, Dustin Cook wrote:
>
>
>> 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?
>
I don't think this forum (usenet) has much if anything to do with it. When
you have a good product, in high use, it will be targetted; that's just the
way it is.
Dustin Cook
@news.eternal-september.org:
No, it seems the grass just looked taller.. :)