COMMAND

    registry

SYSTEMS AFFECTED

    Win2000

PROBLEM

    Jeremy  Collake  found  following.   You  can disable Windows File
    Protection (aka  System File  Checker) by  setting the  SFCDisable
    value (see Q222473) to 0xffffff9d.

    The more one dug  into the internals of  SFC, the more one  begans
    to think  that it  would not  be as  easy as  you first thought it
    would be - and indeed Microsoft does not want it to be easy.

    Windows  File  Protection,  while  annoying,  does  provide a good
    degree of  system stability  and even  some level  of virus/trojan
    protection by preventing system files from being modified  without
    at least notifying the user.  Therefore, you'll be *very*  shocked
    when you  look through  a disassembly  of sfc.dll  and come to the
    code that checks the value of the SfcDisable in the WinLogon  key.
    We see in the  code of ordinal 2  sticking out like a  sore thumb,
    this:

        76986A89                 push    1
        76986A8B                 cmp     eax, ebx
        76986A8D                 pop     esi
        76986A8E                 jz      loc_76986B97
        76986A94                 cmp     eax, esi
        76986A96                 jz      loc_76986B7A
        76986A9C                 cmp     eax, 2
        76986A9F                 jz      loc_76986B69
        76986AA5                 cmp     eax, 3
        76986AA8                 jz      short loc_76986AE0
        76986AAA                 cmp     eax, 4
        76986AAD                 jz      short loc_76986ACF
        76986AAF                 cmp     eax, 0FFFFFF9Dh
        76986AB2                 push    ebx
        76986AB3                 jz      loc_76986B86
        76986AB9                 push    offset byte_76981898
        76986ABE                 push    edi
        76986ABF                 call    sub_7698877D
        76986AC4                 mov     dword_769901D4, ebx
        76986ACA                 jmp     loc_76986B97

    Ok, values 0, 1, 2, and 4 are documented at

        http://support.microsoft.com/support/kb/articles/Q222/4/73.ASP

    but what the heck is this  0ffffff9dh value that it accepts?!   As
    you can  see, any  value other  than 0,1,2,3,4  and 0ffffff9dh are
    assumed  to  be  zero,  which  is  the default of SFC enabled with
    popups enabled.   So, without  further delay,  let's go  and  plug
    0ffffff9dh into the SfcDisable value to see what was up.   Reboot.
    I'll  be  darned,  Microsoft  provided  a  very,very simple way to
    fully disable WFP!  Value 3 leaves WFP enabled and is changed to 0
    after the first boot.

    When  booting  with  this  value  in  the  SFCDisable value in the
    WinLogon key

        HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

    an event is written to the system log, ID 64032 from Windows  File
    Protection, with the description: "Windows File Protection is  not
    active on this system".

    All attempts to  replace/delete protected system  files succeeded,
    just as if you were in safe mode.  Jeremy rebooted a few more times
    and verified that it is the one value (other than 4=popus disabled)
    that is not reset to 0 after the first boot.

SOLUTION

    It is important  to note that  only administrators and  server ops
    have permission to  write the winlogon  key.  If  you're an admin,
    resistance is (eventually)  futile - you've  got rights to  change
    anything you like.

    Please remember that the  main reason Microsoft doesn't  document,
    nor intended to  provide a way  for administrators to  disable WFP
    is that  they didn't  want application  programmers to temporarily
    disable WFP while they  replace various system files  and possibly
    compromise system  stability by  inducing DLL  hell.   In an ideal
    environment, where administrators  are the only  ones who will  be
    installing  new  applications  on  workstations,  the WinLogon key
    will,  under  usual  permissions,  be  fully  accessible  by   the
    application.