I've carefully read your post here
. Indeed, a very good research work
. I'm very surprised with your discovery, put the '\\' character at the beginning of any path in SFCFILES.DLL
But, are you completely sure this will not have adverse effects? I'm unsure if modifying system files is a good idea, although SFCFILES.DLL is not signed.
Let me explain the SfcFileException() trick:
According to Collake's researchings (http://www.bitsum.com/aboutwfp.asp
), this API function generates an exception in the watcher thread of SFC, so no files will be modified in the system, but SFC is instructed to unprotect the file.
It works very well. You can run SFC /SCANNOW and the file will not appear!
But, it's not perfect, and it has a little fault. Suppose the following scenario:
1) You upgrade your Windows version with another version which reinstalls the previously unprotected file.
2) You use my tool to delete again the unprotected file. And yes, the file will disappear from the system32 subdirectory (no attempts are made to restore it. This is good).
3) But if you run again the SFC /SCANNOW command, the file will appear ONLY at the dllcache subdirectory!!
Note the file will NOT appear under the system32 subdirectory (thus, the file will not be "present" for the system, i.e., it will not be usable).
I think it's necessary to add your trick to my tool, in order to permanent delete the file across Windows reinstalls.
If you want, I can send you via PM the source code of my tool. It's written in pure C++ (not C# or .NET), compiled with VC++ 6.0.
Thanks for your interest too
PD: I think Windows updates use the SfcFileException() method in order to delete unnecesary/unsupported files, because they have the SAME fault as described in the above scenario...
PD2: Do you think it is possible to install a patched SFCFILES.DLL file directly from installation source (i.e., replace the original file in the I386 installation source with the patched and modifype'd version)?
Edited by ponghy, 26 June 2007 - 03:00 AM.