WildBill

Ok, here's a c5 version. This adds the following: PsRemoveLoadImageNotifyRoutine PsRemoveCreateThreadNotifyRoutine plus redesigned PsCallImageNotifyRoutines, PsSetLoadImageNotifyRoutine, PsCallThreadNotifyRoutines, PsSetCreateThreadNotifyRoutine. Basically everything before I started putting in bootskin support. Windows2000-KB2393802-v1-early-c5-x86-ENU.exe

It looks like the checksum was wrong in c3, which is why it wouldn't load. If c4 works then you can ignore c3. Tomorrow I'll put together a c5 for you

Great. At least that stuff can be ruled out. I pulled it and posted this one to try, which is the next step up. It should work, as it adds a bunch of dead code and a few exported routines: RtlInt64ToUnicodeString RtlIntegerToUnicode RtlClearBit RtlTestBit RtlSetBit Windows2000-KB2393802-v1-early-c3-x86-ENU.exe If that works, this one hooks in the dead code and adds a few more routines: ZwQueryInformationThread IoForwardIrpSynchronously IoForwardAndCatchIrp Windows2000-KB2393802-v1-early-c4-x86-ENU.exe

Here's another test: I replaced the two multiprocessor files with early versions (the uniprocessor files are still v4). They're so early that I hadn't even bumped up the file versions yet, so be careful if you slipstream to make sure that they get copied. The changes are limited to the security patch itself, CPU count patch, EncodePointer and DecodePointer support, and two added routines (KeAcquireInterruptSpinLock and KeReleaseInterruptSpinLock). I'd be shocked if there are issues with EncodePointer and DecodePonter, because I actually wrote a program to unit-test them early on. If you're using SQL Server 2005, you can expect it to show an error when you boot up, since the kernel32.dll in the patch includes IsWow64Process but the early kernel EXE files don't yet strip out the KEY_WOW64_32KEY and KEY_WOW64_64KEY flags in NtOpenKey and NtCreateKey. Windows2000-KB2393802-v1-early-c2-x86-ENU.exe

Boy, this is bizarre. What happens if you try the patch directly instead of slipstreaming? Also, what happens if you run the patch on a Pro system vs. Server? I know this could take a while to test... :/ I make backups of files at certain points when I patch them, so I might have to build a special patch for you with early versions to try to isolate where the failure takes place.

Okay, here's a V4 test with the CPU core-limit patch removed (and some v4 stuff added). Let's see what this does: Windows2000-KB2393802-v4-test1-x86-ENU.exe

The patch definitely requires the new bootvid -- I added a set-palette function to bootvid that the kernel will use. I wonder if it's an issue with porting blackwingcat's cpu "patch" -- there's precious little patched code involved that runs before the boot screen comes up. I can make one that doesn't include it and post it for you to try. How many cores do you have running? I'm typing this on a laptop with a 2-core Intel T9500 with no issues.

Could you be more specific? Which updates are you talking about? WildBill, I did more tests and actually I was totally wrong and mislead by the bootlog created when logging to Safe Mode. This problem occurs before even bootlog is created. I have enabled /SOS in boot.ini and the exact moment when monitor goes off is after acpitabl.dat is loaded. This screen doesn't show up at all. I looked for it in Google and what I found out is that it may be related to HDD controller driver which can't be loaded. This is the driver I use. Hmm. If you're not even getting the boot screen (with no boot logo settings added to boot.ini), that rules out a lot of potential sources. One thing you can try is to replace bootvid.dll with the one from the v3 patch and see what happens. If it boots that would at least eliminate that as a potential source. Another test, if it boots, would be to verify that when you install MS11-011 that it indeed installs the bootvid.dll from the patch (version 5.0.2172.3).

Thanks. I'll check it out tomorrow night. My gut tells me that it's probably a deadlock of some sort; maybe it's detecting the presence of an XP API call and using it. One thing you might want to try is installing only MS11-011 and not MS11-020. That would eliminate one possible cause of a deadlock (albeit the less likely one, in my mind). My gut instinct is that the cause is in the redesigned calls to the set/create/remove notify routines in the kernel. I spent a lot of time making sure they were thread-safe, but maybe I missed a potential deadlock. Hopefully it won't be hard to track down. In the meantime, one thing you could do that would help is see if any of your drivers are using any of these routines: PsSetLoadImageNotifyRoutine PsRemoveLoadImageNotifyRoutine PsSetCreateThreadNotifyRoutine PsRemoveCreateThreadNotifyRoutine Edit: I just took a look and the drivers are using storport.sys, but I don't seem to have it. Can you post that as well? Perhaps that is also involved somehow. Hmm. Apparently storport is only for server 2003, so perhaps that isn't the issue. Two more questions: (1) are you using the uniprocessor or multiprocessor kernel? (2) are you using PAE?

I took a look at cdfs.sys and at first glance I don't see why there would be an issue. That's the sort of driver that we're all running, and it doesn't use any bound imports. I suspect the driver from winpcap, but I don't have it so I can't analyze it in Ida.

Any progress with your boot issues? Another question: do both v5a and v2 of blackwingcat's kernels cause the problem, or just v5? I ask because I'm looking at a diff of v5a vs. v2 and I don't see anything in common with my MS11-011 that could cause a problem. His v2, however does do some things that MS11-011 also does, like allowing V6 subsystem apps to run.

When it boots normally, what gets loaded after it?

I went and updated the MS11-011 and MS11-020 lists to include everything in the newest versions. By login screen, do you mean where it asks for your username/password? By that point it's probably not a driver, then, since they should all be up and running. Does anything show up in Event Viewer's application or system logs? Hopefully it won't be hard to track down the app that doesn't like the update and why.

I just posted v3's of both MS11-011 and MS11-020 that adds a few things and fixes a few things: Additions kernel32.dll (MS11-011) GetSystemWow64DirectoryA GetSystemWow64DirectoryW SetHandleContext GetProcessId advapi32.dll (MS11-020) CredIsMarshaledCredentialA CredpDecodeCredential CredpEncodeCredential CredpConvertCredential CredpConvertTargetInfo Fixes I found that there is an issue with bound imports. An Office 2000 component was crashing with the newest advapi32.dll, and I discovered that if I move things around in a DLL I need to change its internal time/date stamps so Windows will know to not use bound imports. Consequently, in these two patches I've bumped up the version numbers and reset the internal time stamps for all patched files. My PE tool will now automatically reset the time stamps whenever I change a file so this won't arise in the future. There are actually two time stamps, one in the file header and one in the export directory (if the file has one, not all do, e.g. drivers). Lowering the alignment value from $40 to $20 for the kernel was producing perfectly valid files, but they were confusing Resource Hacker. Apparently, Resource Hacker will move the relocations section when you do something to a resource (e.g. change the file version), but it wasn't correctly calculating where to put the relocations data. The short of it is that you wind up with corrupted files if you change any resources. I adjusted the location of the relocations data in each of the four kernel files so that Resource Hacker will once again deal with them properly. Thanks for taking the time to see what works and what doesn't. I can take some time to look at them over the weekend, but I wanted to get these updates out immediately. One thing I wish I knew was what would be needed for VS2008 to run so I could know if it's worth buying at some point. Edit...forgot that I had also added SetHandleContext.

I posted a v2 of MS11-020 that has these changes: - Fixes the checksum in iphlpapi.dll so it hopefully slipstreams properly. - Added prerequisites sections to the .inf file to (hopefully) enforce that MS11-011 is first installed. - Added some functions to advapi32.dll: CredIsMarshaledCredentialW CredMarshalCredentialA CredMarshalCredentialW CredUnmarshalCredentialA There's a lot more that I'd like to add to advapi32, but since the exports table is in the middle of the file I'm always having to move other routines out of the way so I can grow the exports table. The two routines that border it have a lot of other references to them, so this was all I could add on short notice.

I checked out iphlpapi.dll and the checksum in the header was wrong---that's probably why it wouldn't slipstream. I'll also look at the inf to see if I can require MS11-011 and I'll take a look at CredIsMarshaledCredentialW while I'm at it.

I've never seen the modifype tool before--what does it do? I'll check the DLL tonight to see if something needs to be fixed. As for having two patch types, I don't think I want to try to take that on. While it wouldn't be a problem for individual patches, I think it would quickly spiral out of control when later patches become dependent on earlier "enhanced" patches. Part of my aim with these two was to "bite the compatibility bullet", as it were: if I could get enough functionality in, it should be possible to make the jump to using XP patched DLL's directly. As it stands, I think that's possible with some of them now.

Yup. I tried looking at the inf file to see if I could prevent MS11-020 from installing unless MS11-011 was installed, but I couldn't figure out how to do it. With the two patches installed, Ida Pro 6.1 runs (which was a primary driver for the patch since I use it). Free Orion, Overlord, and Overlord II also run. I'm anxious to see what else people can run with all this new stuff shoved in.

Speaking of MS11-020, it's now posted. I reached the point where if I had to stare at it any longer I'd scream. The critical security patch has been in for a LONG time -- I got a little too ambitious and tried to also shoehorn KB968389 in. A lot of the groundwork for it is in the patch, but it's not complete (the channel binding functionality is dormant). That said, an interesting experiment might be to try using certain XP dll's since so much of the groundwork is in place). kerberos support for it is 80-90% complete (I think), though a little would also have to go into several other DLL's. -- the way channel binding is designed, it won't turn on unless lsasrv can query a certain set of dll's as to whether they support it. You can attempt to turn on channel binding by setting the registry keys according to the KB article and Windows will run fine, but lsasrv won't turn channel binding on since schannel.dll, secur32.dll, etc. don't export the routine that it wants to call so it can ask them if they support it -- it's an all-or-nothing deal. To date I've only added that support to kerberos. Anyway, the patch also adds some goodies: advapi32.dll (this is an unbelievable PITA to patch because of where the export table is!) CredFree CredUnmarshalCredentialW TraceMessage <--------- Just a stub so some games will run. A full implementation would require adding a ton of code to the kernel. A_SHAInit A_SHAUpdate A_SHAFinal MD5Init MD5Update MD5Final MD4Init MD4Update MD4Final CredIsMarshaledCredentialW CredMarshalCredentialA CredMarshalCredentialW CredUnmarshalCredentialA CredIsMarshaledCredentialA CredpDecodeCredential CredpEncodeCredential CredpConvertCredential CredpConvertTargetInfo dnsapi.dll DnsNameCompare_UTF8 iphlpapi.dll CancelIPChangeNotify <---------- this REQUIRES the new tcpip.sys that's also in the patch to work NhGetInterfaceNameFromDeviceGuid GetAdaptersAddresses kerberos.dll KerbIsInitialized lsasrv.dll LsaIGetLogonGuid LsaIIsSuppressChannelBindingInfo samsrv.dll (another HUGE PITA) SamIGetUserLogonInformationEx SamIGetUserLogonInformation2 ws2_32.dll freeaddrinfo/FreeAddrInfoW <------- Same routine, has two export names getaddrinfo GetAddrInfoW getnameinfo GetNameInfoW tcpip.sys No new routines, but added support for cancelling IP change notification Edit...updated to reflect v3.

Funny that you mention that...some of those are in my MS11-020 patch

I posted a v2 of MS11-011 with these changes: - Added ntdll.dll to the uniproc folder - Bumped up each kernel32.dll file to version 7150 - Added IsValidUILanguage() to kernel32.dll

At long last...my MS11-011 patch is up. While the security patch itself is pretty minor, since the kernel is patched so rarely I took the opportunity to add a lot more to it. As the posts above show, this is a massive upgrade to the w2k kernel. Since it is a kernel patch, I highly recommend backing up your kernel files just in case of any issues: ntoskrnl.exe ntkrnlpa.exe ntkrnlmp.exe ntkrpamp.exe kernel32.dll ntdll.dll boodvid.dll I've been using the bulk of it for several months now in both uniprocessor and multiprocessor environments so I really don't anticipate any issues, but you never know. Be warned that restoring a broken kernel can mean restoring the backups using a different computer (or in my case, a spare hard drive that boots Windows). I think it's unlikely in the extreme, but forewarned is forearmed. The next patch will be MS11-020. That one's pretty complete as well (and also includes a lot of upgrades). I'm basically trying to see how much I can add in a short amount of time before posting it. When both patches are installed, I would expect a lot of XP-only things to work on 2k. Just for the heck of it, attached is the boot skin I'm using. This is the boot.ini setting for it: /bootskin=1:1:1:0:1:264:384:112:7:8 The patch includes my notes, which are pretty extensive. Here's just a small snippet from one routine that documents the boot skin settings: ; ------------------------------------------------------------------------- ; GetCustomBootLogoSettings ; ; Loads the boot logo settings from boot.ini: ; ; +------------------------------ Flag: MASTER (0..1) -- must be 1 for any other custom functionality (default=0) ; | +---------------------------- Flag: fade in from black (0..1) -- 1 to enable (default=0) ; | | +-------------------------- Flag: no 2k progress bar (0..1) -- 1 hides it (default=0) ; | | | +------------------------ Flag: bouncy scrolling (0..1) -- 1 makes it bounce back and forth (default=0) ; | | | | +---------------------- Flag: use custom image (0..1) -- 1 enables using \SystemRoot\System32\bootskin.bmp (default=0) ; | | | | | +-------------------- Scroll x pos (0..639) *1 (default=0) ; | | | | | | +------------------ Scroll y pos (0..479) (default=416) ; | | | | | | | +---------------- Scroll width (0..640 - scroll x pos) *1, *2 (default=640) ; | | | | | | | | +-------------- Scroll height (0..480 - scroll y pos) *2 (default=10) ; | | | | | | | | | +------------ Scroll increment (0..scroll width - 2) *1 (default=4) ; | | | | | | | | | | +---------- Progress bar x position (0..478) *1 (default=274) ; | | | | | | | | | | | +-------- Progress bar y position (0..472) (default=437) ; | | | | | | | | | | | | +------ Progress bar color (0..15) *3 (default=1) ; | | | | | | | | | | | | | ; /BOOTSKIN=#:#:#:#:#:#:#:#:#:#:#:#:# ; ; *1 Horizontal positions, widths, and increments are clipped to even numbers: ; bootvid.dll doesn't support bitblt operations on odd pixel boundaries. ; If I had more time I'd rewrite it from scratch as back in the day I spent ; an enormous amount of time doing bare-metal VGA graphics (ahh, memories...) ; ; *2 Scrollable area is limited to one quarter of the total screen area, because ; that's all the static scroll buffer space we have. Unfortunatly we can't ; use dynamically allocated buffer space because bootvid.dll is called at a ; higher IRQL level such that we can't use pageable memory (attempting to do ; so results in a BSOD: Windows does not allow using pageable memory at that ; IRQL level and intentionally blue-screens when you try to do so). ; ; *3 Since the screen mode is 640x480x16, only the low four bits of the color ; value are used (the rest are zeroed out) ; ; Inputs ; ; LoadOptions [ebp+8] char* ; ; Outputs ; ; none (populates data in the data segment) ; ; Locals ; ; KeyName [ebp-8] UNICODE_STRING ; KeyHandle [ebp-$C] HANDLE ; ObjectAttributes [ebp-$24] OBJECT_ATTRIBUTES ; Flags [ebp-$28] word ; ScrollX [ebp-$2C] int ; ScrollY [ebp-$30] int ; ScrollWidth [ebp-$34] int ; ScrollHeight [ebp-$38] int ; ScrollIncrement [ebp-$3C] int ; ProgressXPos [ebp-$40] int ; ProgressYPos [ebp-$44] int ; ProgressColor [ebp-$48] int ; ; Comments ; ; You can't skip options, e.g. "::". To include an option, you MUST include all ; options before it. ; ; The code will allow spaces instead of colons to separate options. ; ; This allows what I would consider the minimum for decent bootskin functionality. ; I was tempted to go really insane and add some esoteric features, like: ; ; - staggered fades (e.g. fade in x colors, then fade in the rest) ; - fade in from an rgb color other than black ; - palette cycling (select block of colors and cycling type, e.g. continuous or ; back-and-forth) ; - tweaked 16-color modes for widescreen displays (e.g. 720x480x16, 640x350x16) ; - 256-color support (320x200x256) ; - tweaked 256-color support (320x240x256, 320x400x256, 360x400x256, 360x480x256) ; ; While cool, they would take an eternity to add and would require a complete ; rewrite of bootvid.dll. Perhaps some ambitious developer might want to take it on... ; ------------------------------------------------------------------------- bootskin.bmp

I just posted a V2 of MS10-084 that adds I_RpcExceptionFilter and updated the download link. Over the rest of the week I'll concentrate on buttoning up MS11-011... Edit...I updated the function summary to include RtlRandomEx for ntdll and AttachConsole for kernel32.dll. The AttachConsole is the one from XP rather than from blackwingcat's v10 kernel.

Well, I've finished copying bootskin support to the four kernel files, and I've added RtlRandomEx. I'll take a quick look at I_RpcExceptionFilter tomorrow.

I was planning to include my notes (as usual) in the update, but here's a short summary: ntoskrnl.exe/ntkrnlpa.exe/ntkrnlmp.exe/ntkrpamp.exe KeAcquireInterruptSpinLock KeReleaseInterruptSpinLock InterlockedPushEntrySList InterlockedPopEntrySList RtlInt64ToUnicodeString RtlIntegerToUnicode RtlClearBit RtlTestBit RtlSetBit ZwQueryInformationThread......already there, added it to the export table IoForwardIrpSynchronously/IoForwardAndCatchIrp (same routine, has two different exported names) PsRemoveLoadImageNotifyRoutine (had to completely redesign the set and call routines to make this work) PsRemoveCreateThreadNotifyRoutine (had to completely redesign the set and call routines to make this work) ntdll.dll RtlIpv4StringToAddressA RtlIpv4StringToAddressW RtlIpv4StringToAddressExA RtlIpv4StringToAddressExW RtlIpv4AddressToStringA RtlIpv4AddressToStringW RtlIpv4AddressToStringExA RtlIpv4AddressToStringExW RtlIpv6StringToAddressA RtlIpv6StringToAddressW RtlIpv6StringToAddressExA RtlIpv6StringToAddressExW RtlIpv6AddressToStringA RtlIpv6AddressToStringW RtlIpv6AddressToStringExA RtlIpv6AddressToStringExW RtlInitializeGenericTableAvl RtlIsGenericTableEmptyAvl RtlGetElementGenericTableAvl RtlNumberGenericTableElementsAvl RtlInsertElementGenericTableAvl RtlDeleteElementGenericTableAvl RtlEnumerateGenericTableLikeADirectory RtlLookupElementGenericTableAvl RtlEnumerateGenericTableWithoutSplayingAvl RtlEnumerateGenericTableAvl RtlEncodePointer (not a stub -- it's the real functionality and depends on changes to ntoskrnl.exe, etc.) RtlDecodePointer (not a stub -- it's the real functionality and depends on changes to ntoskrnl.exe, etc.) RtlInterlockedPushEntrySList RtlInterlockedPopEntrySList RtlInterlockedFlushSList RtlQueryDepthSList RtlInitializeSListHead LdrLockLoaderLock LdrUnlockLoaderLock LdrAddRefDll RtlComputePrivatizedDllName_U RtlValidateUnicodeString RtlDuplicateUnicodeString RtlDowncaseUnicodeChar RtlFindCharInUnicodeString RtlpEnsureBufferSize RtlMultiAppendUnicodeStringBuffer RtlAppendPathElement LdrEnumerateLoadedModules RtlRandomEx bootvid.dll VidSetVgaPalette (my own creation, see below for why) kernel32.dll DecodePointer (forwarded export to NTDLL.RtlDecodePointer) EncodePointer (forwarded export to NTDLL.RtlEncodePointer) InterlockedPushEntrySList (forwarded export to NTDLL.RtlInterlockedPushEntrySList) InterlockedPopEntrySList (forwarded export to NTDLL.RtlInterlockedPopEntrySList) InterlockedFlushSList (forwarded export to NTDLL.RtlInterlockedFlushSList) QueryDepthSList (forwarded export to NTDLL.RtlQueryDepthSList) InitializeSListHead (forwarded export to NTDLL.RtlInitializeSListHead) GetModuleHandleExA GetModuleHandleExW IsWow64Process IsWow64Message GetProcessHandleCount GetNativeSystemInfo (same as GetSystemInfo, simply added another export table entry) SetDllDirectoryA SetDllDirectoryW GetDllDirectoryA GetDllDirectoryW AttachConsole TzSpecificLocalTimeToSystemTime SetClientTimeZoneInformation IsValidUILanguage GetSystemWow64DirectoryA GetSystemWow64DirectoryW SetHandleContext GetProcessId (there's also an *ahem* little tweak to the cpu-count calculation...) All the functions have been added to all files and I've been using them for quite some time now. The very last feature is something special, which I just perfected on ntoskrnl.exe tonight...boot skin support: Over this weekend I have to add the bootskin support to the other ntos...exe kernel files, but the gist of it is this: if you want a custom bootskin, put a 640x480x16 BMP image called bootskin.bmp in your winnt\system32 folder. Then add an option to boot.ini which will tell the kernel to use it. The option format is as follows: /bootskin=<master flag>:<fade in>:<hide progressbar>:<bouncy_scrolling>:<custom_image>:<scroll_x>:<scroll_y>:<scroll_width>:<scroll_height>:<scroll increment>:<progress_x>:<progress_y>:<progress_color> master_flag : 0 or 1, it has to be 1 for any other option to work. It provides an easy way to revert back to default 2k behavior. fade_in: 0 or 1, when 1 it fades in the image from black (like XP does) hide_progressbar: 0 or 1, when 1 it hides the blue 2k progress bar that comes up. bouncy_scrolling: 0 or 1, when 1 it causes the scrolling "blue ribbon" area to bounce back and forth, cylon-style custom_image: 0 or 1, when 1 it enables loading the bootskin.bmp image. When 0, the kernel will use the default 2k image or whatever image is in the kernel's resource area. flag default values are all 0. scroll_x: 0 to 639 (default 0), specifies the left edge of the scrolling "blue ribbon" area. Note though that bootvid.dll requires that only even numbers are used, so the low bit will be automatically stripped off (1 and 0 have the same effect, 2 and 3 have the same effect, etc.) scroll_y: 0 to 479 (default 416), specifies the top edge of the scrolling "blue ribbon" area. scroll_width: 0 to 640 (default 640) , specifies the width of the scrolling "blue ribbon" area. Is checked against scroll_x to ensure that the area does not extend past pixel 639. Invalid values will cause the kernel to revert to default 2k settings. Note though that the maximum scrollable area is 1/4 of the total screen real-estate. This is because of a buffer size limit in ntoskrnl's allocated image area. scroll_height: 0 to 480 (default 10), specifies the height of the scrolling "blue ribbon" area. Is checked against scroll_y to ensure that the area does not extend past pixel 479. Invalid values will cause the kernel to revert to default 2k settings. scroll_increment: 0 to 639 (default 4), controls the speed that the "blue ribbon" area scrolls. Values greater than 320 cause it to appear to scroll right-to-left. progress_x: 0 to 478 (default 274), sets the left position of the blue 2k progress bar. progress_y: 0 to 472 (default 437), sets the top position of the blue 2k progress bar. progress_color: 0 to 15 (default 1), sets the color to use when drawing the blue 2k progress bar. bootvid.dll is pretty weird, and you might have to have scroll_x and scroll_width be on 4-pixel boundaries to avoid some pixel weirdness at the edges. I'm tempted to rewrite it from scratch, but I've been holding onto this update long enough. If you boot into safe mode, I disable all boot skin support. This is for safety. As an example, the screenshot below uses these settings: multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Professional" /fastdetect /bootskin=1:1:1:0:1:264:384:112:7:8 You don't have to include all settings, but to include a setting you have to include all settings before it (no skipping settings). When changing a custom boot skin, bear this in mind: because of the way the kernel starts up, it takes TWO reboots before the new skin is visible. This is because the kernel can't load the skin until the entire I/O subsystem is up and running, which takes quite a while. My solution is to use the registry to cache the bootskin because the registry is available a lot sooner (believe me, I tried every trick I could think of to come up with some other way). The first reboot will show the cached skin from the registry and will load the new skin into the registry. The second reboot, therefore, will show the new skin. All in all, it works very well, and performance is excellent. I also use a checksum to validate the cached image and I make sure that the loaded image is truly 640x480x16. I also enforce a maximum file size of 160k bytes, which will cover any uncompressed image (though RLE-encoded images also work). The cached skin is written to \Registry\Machine\System\CurrentControlSet\Control\Bootlogo in a series of 1k chunks, where the chunks are grouped into up to four keys containing up to 40k bytes (because according to MSDN, there is a key-size and value-size limit). The settings go in boot.ini instead of the registry because the kernel needs to know the settings when it first tries to show the default 2k image, and that is way before the registry is available. Edit...updated to reflect the v3 list.