WildBill

It's been about a year since I've posted, but I've been quietly working on my rewrite of kernel32.dll on and off. I've gotten it to the point where I'm pretty confident that it's finally free of any bugs I've posted the source and DLL here: http://www.mediafire.com/file/jea4ca8d7f4g3yj/Windows2000-kernel32-rewrite-v6.zip I'm thinking that the next logical step would be to start on a rewrite of ntdll.dll, which I hope will be easier (since it's smaller). I'm not even using Win2k all that much anymore, but I still like the idea of eventually being able to build our own Win2k kernel that can run on modern hardware.

I've posted the newest version of my kernel32.dll rewrite, including source: http://www.mediafire.com/download/4ovx3tv1o85cc9m/Windows2000-kernel32-rewrite-v5.zip I can't say it's bug-free, so test with extreme caution, but I don't know of any bugs in it.

Yes, it's fixed in KB2508429 v17, which has srv.sys 5.0.2195.7371. I just double-checked the file in IDA and it's fixed. On another note, I'm still plugging away with my kernel32.dll rewrite. I had thought it was ready, but I found a bug when I run Seven File Replacer -- the GUI doesn't render properly. I've been slowly verifying the routines that it calls, but Seven File Replacer is a hideously complex program for some reason, so it's been really hard to track down. EDIT: I had a bout of insomnia and decided to work on verifying some more routines in my rewrite. What a relief -- I finally tracked that bug down! memset() in the original kernel32 is **evil**.

That's just bizarre. I scanned it on my end with Avast and it's clean, so I deleted it from MediaFire and I'm re-uploading it. I'll update the link once it completes. Hmm. It still thinks it's infected, so I rebuilt the .exe and I'm reposting it. For some reason the new one is different from the original. I have no idea why.

I've got a couple new versions posted up on the master list: Windows2000-KB2508429-v17-x86-ENU.exe iphlpapi.dll if_indextoname Windows2000-KB2479629-v3-x86-ENU.exe (There was no v2, that was internal and only added IsProcessInJob) kernel32.dll IsProcessInJob GetNumaHighestNodeNumber GetNumaProcessorNode GetNumaNodeProcessorMask GetNumaProcessorMap GetNumaAvailableMemory GetNumaAvailableMemoryNode GetLogicalProcessorInformation ntdll.dll NtIsProcessInJob ZwIsProcessInJob ntoskrnl.exe/ntkrnlpa.exe/ntkrnlpa.exe/ntkrpamp.exe Added support to NtQuerySystemInformation for new kernel32 API calls

Thanks! I'm almost fully recovered; I had a bout of anemia a couple weeks ago, and I've been cooking steaks every night to try to get my numbers back up. I'll be seeing the doc tomorrow, but I anticipate that I should be back to work on Monday. I've started looking at the requested routines, and it looks like I only need to add CreateActCtxW (as the patch versions I have here already contain the other routines). That one will be tricky because I've found that putting in stub versions causes some applications to act wonky (because they expect them to actually work). I once took a stab ad making fully functional versions of the activation context API (which MS calls the Fusion API), but it's far from trivial. Still, taking another look never hurts.

Funny that you mention those, since I'm testing an update here that adds the first two (GetNumaHighestNodeNumber and GetLogicalProcessorInformation). Unfortunately health issues intervened and I'm currently recovering from gall bladder surgery. When I get back on my feet so to speak I'll try to remember to look at the rest of those.

It's been a long while since I mentioned it, but I've quietly been working on a total rewrite of kernel32.dll in C. It took forever, but I've finally squashed enough of the bugs such that it's booting in a VM without exhibiting any errors. Once I synchronize it with the current kernel32.dll in my patches, I'll be releasing a new version of the rewrite with full source.

For what it's worth, here is the MS page on bugcheck 0x7F: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559244%28v=vs.85%29.aspx It sounds like a diff of the working and failing drivers might be in order, but blackwingcat is right -- the crash dump should help a lot.

New update: KB2508429 v16 (apparently I never uploaded v15, oh well...). There are three new functions for advapi32 since v14: RegSaveKeyExA RegSaveKeyExW EnumerateTraceGuids

I've been sitting on the update so I could test it thoroughly, but I just posted KB2479629. It combines KB2479628 and KB2393802, rendering them obsolete. It also adds some new stuff: ntoskrnl/ntkrnlpa/ntkrnlmp/ntkrpamp.exe The fix for the NTQueryInformationProcess bug that blackwingcat found. setupapi.dll Added SetupUninstallOEMInfW user32.dll Added true implementations for the following (for mouse and keyboard support only, not other USB devices) DefRawInputProc GetRawInputBuffer GetRawInputData GetRawInputDeviceInfoA GetRawInputDeviceInfoW GetRawInputDeviceList GetRegisteredRawInputDevices RegisterRawInputDevices win32k.sys Kernel-side implementation of the raw-input API that user32.dll invokes (where the real work is). wtsapi32.dll Added stubs for WTSRegisterSessionNotification and WTSUnRegisterSessionNotification

I'm putting together a patched called KB2479629 that combines KB2479628 and KB2393802. It incorporates fixes to the bug that blackwingcat found, the win32k.sys raw-input API, and I think a few other things (I'll have to go back and see what else I added). KB2479629 isn't used by MS so it should be safe to use.

Thanks! I'll integrate it into the next patch. I'm currently testing a win32k/user32 update that adds support for the raw-input API for mouse and keyboard devices. The changes are pretty intrusive so I want to really thoroughly test it before releasing it. Since win32k.sys is contained in both KB2393802 and KB2479628, I'm leaning pretty heavily on combining the two patches and coming up with some other designation for it. I also found at least two potential crash bugs in win32k.sys that the update fixes.

I did some more investigating, and this is something that I'm really going to need help with. The fault during the call to DefineDosDeviceW is really occurring, but it's also a red herring. What's really happening is heap corruption. The stack back trace doesn't have all of the symbols in ntdll that I've figured out by reverse engineering. The actual call hierarchy is like this: ntdll!RtlpCoalesceFreeBlocks ntdll!RtlFreeHeap ntdll!CsrFreeCaptureBuffer kernel32!DefineDosDeviceW winlogon!Logoff I'm attaching a .dbg file for ntdll that I've generated from my .map file that has lots more symbol info, but the real issue is there is a bug somewhere in the kernel32 rewrite that's corrupting the application heap. I've suspected this for some time but haven't been able to track it down. I *really* need help on this one. ntdll_info.zip

It looks like the exception occurred somewhere in kernel32.DefineDosDeviceW (address 0x7C5B3DE3). I'll look into it some more during the week, but from what I can see so far it happened when it called CsrFreeCaptureBuffer, which led to RtlZeroHeap, which led to the exception. Maybe it was a bad pointer?

Are the details from the BSOD the same? I'm wondering if the bug is not in srv.sys.

Another easy fix, and it's posted; I'd be very surprised if you still get STOP errors with KB2508429 v14, at least in the same place...

A-ha. There were actually two bugs in the code; EAX was incorrect, but EDX was also incorrect. I fixed the EAX one but not the other. I'll post another update as soon as I fix this one.

It turned out to be pretty easy to fix, so KB2508429 v13 is now up. Please let me know how it turns out!

Ouch. There definitely is a bug there. I'll work on fixing it this weekend.

I won't declare it completed, but it's ready for another posting and round of testing http://www.mediafire.com/download/2ikz2xg2rw0eqbk/Windows2000-kernel32-rewrite-v4.zip I still have a lot of API's to add to it that were added since KB2393802 v14, for instance.

Ugh. The good, the bad, and the ugly. The good: I finally figured out why backup/restore functionality wasn't working in my kernel32 rewrite and fixed it. The bad: It was due to a bug I introduced right when I first started patching kernel32.dll. The ugly: I just posted KB2393802 v21, which is an emergency release that fixes the bug. Any backups you made using KB2393802 prior to v21 will not restore properly.

Yeah, I generally work on mine independently. If I had a list of the API differences handy I'd probably be able to add whatever is missing. Anyway, Windows2000-KB2479628-v10-x86-ENU.exe is now available. I've integrated blackwingcat's additions, and I'm posting this from Firefox 26! I did make a couple of changes to blackwingcat's code, however. There was one case where he loads a DLL and then unloads it, but leaves the handle to it unchanged. This could cause other API calls to fail because they would think the DLL was loaded when it wasn't. I bypassed the call to UnloadLibrary() for safety's sake. The other change was in how I handle the call to CoCreateInstance(). I call the full routine, which checks to see if it's loaded or not. blackwingcat calls to the middle of it, which seems unsafe to me. Other than that, the functionality is identical. Enjoy!

Just a little addendum: I'm working on KB2479628 v10 that integrates all of blackwingcat's additions to shell32.dll (I've done them all except the SHRestricted upgrade). I might try to add a few more API's if I can as well. I already have Firefox 26 running in my VM

Hey everyone, I have three new updates available. They add a bunch of new API calls: Windows2000-KB2479628-v9-x86-ENU.exe shell32.dll ShGetFolderPathAndSubDirA ShGetFolderPathAndSubDirW Windows2000-KB2393802-v20-x86-ENU.exe ntoskrnl/ntkrnlpa/ntkrnlmp/ntkrpamp.exe PsGetCurrentProcess PsGetCurrentThread PsGetCurrentProcessSessionId NtQueryInformationProcess: added support for PROCESSINFOCLASS.ProcessImageFileName (0x1B), required by psapi additions below psapi.dll GetProcessImageFileNameA GetProcessImageFileNameW GetPerformanceInfo kernel32.dll GetUserGeoID GetGeoInfoA GetGeoInfoW Windows2000-KB2508429-v12-x86-ENU.exe dbghelp.dll SymFromAddr SymFromName In kernel32, I implemented the GetGeoInfo functionality by adding GEOINFO resources to the file with Resource Hacker. They're a set of $-delimited Unicode strings that contain the returned values for Geo info types 1 through 11 (everything that I could dump from a Win7 box). If you need to make a localized version, I strongly recommend adding new localized entries and leaving the existing 1033 (en-US) strings in place: this is because the code that I added will substitute locale 1033 (0x409: en-US) if a program asks for the invariant locale 0x7F (which Win2k doesn't have). At some point I want to add a way to override the OS version information that applications receive: I wanted to try out the Neverwinter MMO, and I was only able to get it to install by trapping a call to GetVersionEx in a debugger and changing the returned values to tell it the build was 5.1.2600 (XP). I hate it when apps try to protect you from yourself! Anyway, once you get past the installation process, it runs just fine with these patches installed. I was also able to play The Witcher, but you have to grab dbghelp.dll from XP SP3 and put it in the game's folder. I've started looking at trying to upgrade 2k's dbghelp.dll to support the API calls it needs, but it's not a trivial process.