System File Checker (SFC) Question
Results 1 to 4 of 4

Thread: System File Checker (SFC) Question

  1. #1
    Some Assembly Required ShagDevil's Avatar
    Join Date
    Nov 2002
    Location
    New Jersey
    Posts
    718

    System File Checker (SFC) Question

    I have been checking around all day and could not find any comprehensive answers to this:
    Can running sfc.exe cause issues in relation to patches? Basically what I'm wondering is that if I just recently ran sfc.exe (using the original Windows XP SP2 CD) on a system that has been patched numerous times - will it cause problems with the system files? I'm not sure if patches generally change protected windows files.
    I was having login problems and running sfc.exe was the only way to fix it. Any help would be apprciated. Thanks.
    The object of war is not to die for your country but to make the other bastard die for his - George Patton

  2. #2
    Senior Member
    Join Date
    Feb 2003
    Location
    Memphis, TN
    Posts
    3,747
    I don't think that sfc would cause issues related to patches.


    I've ran it numerous times on desktops and servers alike and never had any problems because of it.
    =

  3. #3
    Senior Member IKnowNot's Avatar
    Join Date
    Jan 2003
    Posts
    792
    I have little knowledge here, so take this FWIW. I'm shooting off the top of my head here, while relaxing with a glass or two of wine. ( or three or six. )

    I'm not sure if patches generally change protected windows files.
    This I can tell you, even drunk, yes, patches do change protected windows files. Just look through your /windows/system32 directory, and choose to sort by date.
    You will see how many M$ .dll files have been changed, hopefully by patching and upgrades

    M$ apparently just the other day re-released the KBA Q222193 and is now Description of the Windows File Protection feature

    The only other relevant M$ article I could find was Description of Windows XP and Windows Server 2003 System File Checker (Sfc.exe)

    According to these articles, the only ‘supported mechanisms' of replacing protected files are through
    • Windows Service Pack installation using Update.exe
    • Hotfixes installed using Hotfix.exe or Update.exe
    • Operating system upgrades using Winnt32.exe
    • Windows Update


    If anyone has ever tried to manually replace one of these protected files they know first hand that it is re-replaced automatically by M$ WFP when they do, and although difficult, not impossible to perform a permanent replacement ( so I guess maleware can do it too! ).

    Correct me if I am wrong, but I think I see where your concerns are coming from:

    Since, according to the above referenced M$ KBA, WFP searches
    1. The cache folder (by default, %systemroot%\system32\dllcache).
    2. The network install path, if the system was installed using network install.
    3. The Windows CD-ROM, if the system was installed from CD-ROM.


    Then if something did manage to replace a protected file AND a cached version of it ( like getting someone to reboot ) then the WFP would not replace it, even if it were not signed.

    So now you come along, have problems, run sfc.exe, and WFP requests you to insert an install disk, then, finding a discrepancy, copies over the original ( lets say SP2 version ) of a file to replace the ‘non-verified' version. That file that was replaced could have been a trojaned version, but you may not have replaced it with the most up-to-date ( patched ) version.

    No where in the KBA does it say it checks the cabs used to update and/or patch the system: it merely states those are ‘supported mechanisms' to replace protected files, and it checks the original install data in Driver.cab.

    So what you are asking, in a not-so-long-winded way as me, is:

    After using sfc.exe and a XP SP2 disk to replace protected files, could I have outdated ( i.e. previously patched but now replaced with original and/or older ) files on the system?

    My response would be, yes, you may have. I have only used this tool maybe a few times since XP came out ( on really FUBARed boxes, ) and when I did I wrote down what files were replaced, then compared it to a known up-to-date good box, and updated files as needed. I remember having found several 'outdated' files.

    I do not know if this is the norm, or if this has changed, as I haven't used this tool in a few years.
    But that is probably why most just suggest, when a compromise is detected, to just reformat and reinstall, because few have the time ( and time is money ) to spend checking individual files on each box.

    I hope this did not scare you, and I hope someone will confirm that I am wrong. But this is what I have found.


    BTW, what cheyenne1212 said should be true if kept in context: a M$ patch would be allowed to replace both the protected file and the cached version, so it under normal circumstances WFP should not flag it and replace it: unless it needs to check with the original install media!

    Ouch.
    " And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes

  4. #4
    Some Assembly Required ShagDevil's Avatar
    Join Date
    Nov 2002
    Location
    New Jersey
    Posts
    718
    cheyenne1212,
    Ok, that's what I thought. For the most part, the answer is no, sfc doesn't mess with most patches. It seems that I should have done what IKnowNot did and keep a record of what sfc.exe changed and compared it to what was on my system *prior* to running sfc.

    IKnowNot,
    Thanks for answering my question in more detail than there is on the ceiling of the sistine chapel. That answered my question and then some. You get a gold star! now pass the damn wine
    The object of war is not to die for your country but to make the other bastard die for his - George Patton

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides