Problem summary: my Windows XP fails to found in its file system a file
with specific name.
Smells like a rootkit, doesn't it?
All of a sudden an executable with some specific name (lets say
Myfile.exe) can't be run by Windows XP.
After double-click in explorer I get "Windows cannot find
'c:\temp\MyFile.exe'. Make sure you typed the name correctly and then
try again. To search for a file, click the Start button, and then click
Search" error.
That's interesting, and less rootkit-like.
Can you see the file via the shell, but find it doesn't run when
launched? If so, then maybe it's the opposite of the rootkit
objective; some sort of protection that is blocking running that file.
Or can you not see that file through the shell at all, whether you
eyeball it or use Search to find it, even though you've de-lamered
explorer so that it no longer hides hidden or system files?
1. The problem is system wide: the OS refuses to locate MyFile.exe on
any disk folder or even on USB drive.
OK. Both rootkits and safety blocks can do that.
2. Renaming the file solves the problem (MyFile_.exe works Ok).
OK; fits with both the above, suggesting they are too weak to use MD5
or similar fingerprinting and are name-based only.
3. The problem has nothing to do with the content of the file, since
when I took regedit.exe application and renamed it to MyFile.exe, I got
the same problem
OK; also points away from true identity management to simple
name-based blocking or hiding.
4. Nothing suspicious related to "Myfile.exe" was found in registry.
5. I assume that this happen as a result of running Microsoft
Application Verifier with this exe. I uninstalled Microsoft Application
Verifier, but the problem persisted.
I'm not familiar with Application Verifier. URL? Description?
Let's hear more about what "MyFile.exe" actually is?
On rootkits: A rootkit is simply a malware that makes use of
opportunities open to it, to hide itself from the OS in various ways.
Like any large and mature industry, malware vendors often specialize
in particular niches. So rootkit functionality often exists as a
separate stand-alone malware, rather than simply being integrated into
the same malware that does other stuff. This current state of affairs
has created a false sense of security, that "rootkits" are a special
breed of threat that can be managed separately.
There are two ways to detect rootkits:
1) Test for divergant behaviors
This is a test for rootkit quality failure, i.e. a rootkit that traops
some OS functionality while failing to trap parallel methods that can
be used to compare results. Where these two methods give different
results, it suggests that a rootkit is interfering with one method.
For example, a rootkit detector may use a high-level API call to list
files in a directory, then use a low-level API call to view the raw
cluster chain of the directory and build up a list of files based on
its own interpretation of the data. If some files appear in the
second view that are not shown in the first, it implies a rootkit is
"editing" the hi-level API call to hide those files.
This method of detection has to be run while the rootkit is active,
and is prone to false positives if the contents of what is being
tested should change between one test and the next. For example, if a
harmless process were to delete a file from a directory test after the
first test and before the second, it will appear as if the second
method was being fiddled with to hide the file.
There's a risk of provoking a punitive response, when going after
malware while it is actively running. A rootkit that has already
grabbed the API calls being tested, is well-placed to do this.
2) Formal scan for known rootkits
If you scan the system while none of that system's code is running,
then the rootkit is "asleep", and is just another inert files that can
be scanned as easily and safely as anything else. As long as the
scanner "knows" the rootkit's signature, it can detect it.
This approach is safer, but will fail if the rootkit is not known to
the scanner, whereas the other approach may detect such malware by
virtue of the way it behaves.
Played any "audio CDs" from Sony lately?
--------------- ----- ---- --- -- - - -
First, the good Customer feedback has
been clear and unambiguous.
