how to replace kernel32.dll in win2k/xp
 

i've created a modified kernel32.dll and would like to replace my current kernel32.dll with the new one.

i've tried using MoveFileEx with the delay until reboot flag, created a registry key to AllowProtectedRenames, also tried disabling system file protection (SFP), but the kernel32.dll file still cannot be replaced!!!

any ideas on what i should do? TIA!

Try with ERD commander.

Regards,

Z

thanks, i'll try ERD commander.

funny thing is, the microsoft hotfixes can easily update the kernel32.dll file, without even rebooting.

:mad:

You'll have to disable WFP.
WFP may be disabled by undocumented registry value. Go to
hxxp://www.collakesoftware.com/aboutwfp.htm
and read it carefully.
Then you have to patch sfc/sfc_os.dll and replace it using ERD. After it you can do anything you want. If you just replace kernel32.dll even using ERD, you'll see the result very soon :D Either Windows silently will replace it back, or you'll have to reinstall your Windows machine. :rolleyes:

Unless you know Microsoft's checksumming algorithm for there list of critical system files, you'll have to disable WFP and keep it disabled for the duration of your modified kernel32.dll. Service packs can update it easily by moving files into the cache, setting the checksum and then asking for a version update.

To actually update it yourself, your probably best off using dos, which, if your file system is ntfs, you'll need NTFS4DOS.

sfc.dll: (W2k SP4)

.text:76986CD1 loc_76986CD1: ; CODE XREF: sfc_1+370j
.text:76986CD1 mov eax, dword_769901D4
.text:76986CD6 cmp eax, 0FFFFFF9Dh
.text:76986CD9 jnz short loc_76986CE2
;patch here!
.text:76986CDB mov eax, esi
.text:76986CDD mov dword_769901D4, eax
.text:76986CE2
.text:76986CE2 loc_76986CE2: ; CODE XREF: sfc_1+382j
.text:76986CE2 cmp eax, ebx
.text:76986CE4 jz short loc_76986D24
.text:76986CE6 cmp eax, esi
.text:76986CE8 jz loc_76986E85
.text:76986CEE cmp eax, 2
.text:76986CF1 jz loc_76986E74
.text:76986CF7 cmp eax, 3
.text:76986CFA jz loc_76986DE8
.text:76986D00 cmp eax, 4
.text:76986D03 jz loc_76986DD7
.text:76986D09 cmp eax, 0FFFFFF9Dh
.text:76986D0C push ebx
.text:76986D0D jz loc_76986E95
.text:76986D13 push offset aSfcdisable ; "SFCDisable"
.text:76986D18 push edi
.text:76986D19 call sub_76988B30
.text:76986D1E mov dword_769901D4, ebx


For the files, you, perhaps, would be interested in sfcfiles.dll

Squidge
Now I'm curious about some things.

Service packs can update it easily by moving files into the cache, setting the checksum and then asking for a version update.

Sounds really interesting. Would you be more precise? I'd like to hear the technical details!
Now I realise, that patching sfc.dll is not the best thing to do! You, perhaps, can modify the list of files returned by sfcfiles.dll API SfcGetFiles. The array looks like:

.data:68012000 arr_of_files dd 0 ; DATA XREF: sub_6801109C+54o
.data:68012000 ; sfcfiles_1+33o
.data:68012004 dd offset aSystemrootSyst ; "%systemroot%\\system32\\12520437.cpx"
.data:68012008 dd 0
.data:6801200C dd 0
.data:68012010 dd offset aSystemrootSy_0 ; "%systemroot%\\system32\\12520850.cpx"
.data:68012014 dd 0
.data:68012018 dd 0
.data:6801201C dd offset aSystemrootSy_1 ; "%systemroot%\\system32\\drivers\\1394bus.s"...

So, you find you name here, substitute it with the anything you want, and, perhaps, you may now forget about the WFP for the concrete file, BUT! It is not a proper way of doing things!

Unless you know Microsoft's checksumming algorithm

Any ideas where I can find it? Do you mean a PE checksum or sth more sophisticated? Give me more info, please!

Wine
 

Hi folks!
What about Wine? It contains the sources for the PE Checksum code if this is the checksum you need.
I'm just trying to find the exact position in the code.
get Wine at hhhp://www.winehq.com
regards
PHaX

PE checksum is not a problem for me at all. But maybe Squidge means some more sophisticated algorithm...

SfcValidateFileSignature() validates the protected files using the CryptoAPI. MS probably calls sfc_os.dll's exported functions to install the new files (which are signed by MS).

Got that. Thanks. You info was really helpful. I was able to find more information (on Russian, sorry) and now I can more or less imagine what is going on.

SfcValidateFileSignature loads some API from mscat32.dll/WinTrust.dll:


CryptCATAdminCalcHashFromFileHandle - undocumented
CryptCATAdminEnumCatalogFromHash - documented -
hxxp://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/cryptcatadminenumcatalogfromhash.asp

CryptCATCatalogInfoFromContext - undocumented
WinVerifyTrust
- documented -
hxxp://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/winverifytrust.asp

CryptCATAdminReleaseCatalogContext - documented -
hxxp://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/cryptcatadminreleasecatalogcontext.asp

Let me remind you that you can completely disable WFP by setting SFCScan value to the undocumented one described by Collake and patch sfc.dll (sfc_os.dll in XP+) with the patch I gave you above.

For the "undocumented" functions, see:

hxxp://msdn.microsoft.com/library/en-us/security/security/cryptcatadmincalchashfromfilehandle.asp
hxxp://msdn.microsoft.com/library/en-us/security/security/cryptcatcataloginfofromcontext.asp

What the function seems to do (never used the CryptoAPI myself) is to first calculate the hash of the protected file and then search the catalogs for that hash.

Yeah, I know about that. But I wouldn't do that without also changing the magic value to something other than what's already in that dll file.

volodya: Unfortunately, I know very little beyond what I've already explained. I think the files have some kind of signed certificate which is used as the checksum, so is going to be difficult to create yourself without the private key microsoft use.