WildBill

I can't begin to describe how much I hate that DLL. There is no symbol info available for it, and it's hopelessly complicated. Do you know if the problem goes away with an earlier version of my patched DLL? That would help me narrow the problem down.

Thanks! I found a separate issue in ntdll so I was going to release a new one anyway, so I'll put this fix in also.

I don't have a handy list of the functions in those files, though a tool like Ida could probably generate one. I'd love to eventually rewrite those in C as well, but first things first--rewriting kernel32 has already proven to be a much larger endeavor than I had envisioned...

This is what's in my kernel32.def file at present, which lists all of the exported functions currently implemented in C. I still have about 180 more to do before it contains everything in the latest V10 kernel. Also, until I have the first 830 or so all implemented I can't test or debug them, so crashes are likely until that point. Once I get everything working I can then put it through the hardening passes that I did for csrsrv and basesrv. http://www.mediafire.com/download.php?1966gy8kokutq6p I could post the full sources to my kernel32 project, but while it compiles it won't do anyone any good until it's complete enough to run in a 2k environment.

I don't know if this is worth considering, but once my reverse-engineered kernel32 rewrite is completed, that should be a real game-changer for extending the kernel. I'm creeping up on the 75% mark for the first cut at it (668/902 exported routines implemented in MSVC 2005). A kernel32 rewrite necessarily must go hand-in-hand with matching csrsrv and basesrv, but those rewrites are completed, barring any issues people here find in my sources.

It's the same file either way. I don't think I've ever had a separate one for uniproc in that patch. I guess no one has taken a look at the v9e sources

I finally have WideCharToMultiByte rewritten in kernel32 (it's pretty messy and probably buggy), but it's letting me make progress on a bunch of simpler functions that require it. I'm up to 565 exported functions rewritten out of about 902, and I expect progress to pick up now that most of the really tough NLS stuff is done (if nothing else, most of the .nls files will finally be documented). In the meantime, I was wondering if anyone has had a chance to look over the sources for my rewritten basesrv and csrsrv.

What happens if you use TweakUI to rebuild your icon cache?

KB2393802-V10 is now up on the main list, with the win32k.sys fix from v9e2.

Excellent! I'll post a v10 one (without my experimental rewrites) shortly.

Here's a v9e2 with a new win32k.sys. I'd be very surprised if this causes a crash and the official one doesn't. http://www.mediafire.com/download.php?fshx0n67py3na9w

Hmm. I think I know what to do. Give me an hour or two and I'll post another one.

BWC: I removed the v9e above and posted another one with an updated win32k.sys file (version 5.0.2195.7402). It explicitly sets ECX rather than relying on ValidateHmenu() to set it. If it works out for you, I can post a V10 on the main list. The new v9e is here: http://www.mediafire.com/download.php?7o1y5rbcr9eqxc0 For reference, this is what it looks like (a few other instructions above it changed to reflect the fact that some things moved up by 4 bytes): .text:A00A34E4 loc_A00A34E4: ; CODE XREF: xxxGetMenuBarInfo(x,x,x,x)+187j .text:A00A34E4 cmp [ebp+arg_4], 0FFFFFFFCh .text:A00A34E8 jnz short loc_A00A3530 .text:A00A34EA mov edi, [ebp+arg_0] .text:A00A34ED push edx ; int .text:A00A34EE push edx ; UnicodeString .text:A00A34EF push 1E1h ; MbString .text:A00A34F4 push edi ; int .text:A00A34F5 call _xxxSendMessage@16 ; int .text:A00A34FA mov [ebp+arg_4], eax .text:A00A34FD push eax .text:A00A34FE call _ValidateHmenu@4 ; ValidateHmenu(x) .text:A00A3503 test eax, eax .text:A00A3505 jz short loc_A00A3530 .text:A00A3507 push [ebp+arg_4] .text:A00A350A pop ecx .text:A00A350B mov edx, [ebp+arg_8] .text:A00A350E test edx, edx .text:A00A3510 jl short loc_A00A3530 .text:A00A3512 cmp edx, [ecx+20h] .text:A00A3515 ja short loc_A00A3530

I'm looking at that routine and I see something I don't like in its treatment of ECX. Let me see if I can do something with it.

I posted KB2393802-v9e today ("e" for "experimental"). I'm not adding it to the main list as it doesn't add any new functionality or attempt to fix any issues with v9. It does, however, include my rewrites of csrsrv.dll and basesrv.dll. If you manually extract the installer and look in the info folder it creates you can find the complete source code to my rewrites. I've tried to go the extra mile in hardening both against attack, but I invite anyone who is interested to play with them. Each was built with VS2005 standard and uses the libraries from the WinNT DDK version 3790.1830 for ntdll, etc. Here is the link for v9e: http://www.mediafire.com/download.php?skox32b1rddgl26 (updated...see a few posts down) Remember, this is experimental, so use at your own risk. So far I'm only using it in a VM.

I didn't think ntdll had changed all that much, though I did add a few things. I'll have to keep that in mind for v10. Speaking of V10, I'd like to ask for some suggestions on developing it. While I'm making steady progress on reverse-engineering and rewriting kernel32 (about 550 exported routines implemented out of about 902), it's still going to be a while before it's complete enough to test, debug, and harden. In the meantime the rewrites of csrsrv and basesrv are sitting idle and are basically complete. It seems to me to be a terrible waste of time to just have them sit on my hard drive when people could be testing them, playing with my sources, and possibly improving them (in light of stuxnet and flame, bulletproofing has been on my mind of late). To cut this spiel short, would it make sense for an interim v10 release (or some other nomenclature) with the rewritten basesrv and csrsrv included? Now that I've rewritten them in C, there should be a lot of potential for improvement, not to mention that patching them, localizing them, etc. will be infinitely easier.

kernel32.dll rewrite status: NLS Hell . 468 exported functions implemented out of a total of about 902 I'm currently bogged down in the NLS support -- apparently kernel32 does all the heavy lifting for localized data (date/time formats, etc.). I'm having to reverse-engineer a bunch of structures, and in the process the format of the various .nls files in system32. I now know all about Japanese emperor eras, how to convert numbers to Hebrew numbers (including the special cases for 15 and 16 and the reason behind them), and creating Hebrew and Hijiri dates. I've completely reverse-engineered locale.nls (and documented it to the nth-power in my kernel32.h) and partially reverse-engineered ctype.nls and unicode.nls. I've even had to write a Java program that dumps out all the info in locale.nls. And, now I know why there are alternate month names for Polish for certain months... (sigh)

The ActCtx API's are the ones I've been working on since November, but I'm finding that I need them to actually work or apps like Adobe Reader crash.

I've posted KB2393802-v9 It doesn't include the new rewritten stuff and is mostly a bugfix version. It adds several SxS API's to ntdll, but until the rest of the pieces are added to kernel32 they won't do anything (they should be safe to call, they'll just return error codes since they won't succeed). I still recommend it though as it fixes several bugs in -v8. Now I can work on finishing SxS support for v10 without having those bugs hanging over my head...

(sigh) Sometimes I wonder why I put myself through this... I've completely rewritten csrsrv.dll and basesrv.dll in C and I've significantly hardened them against attack. Then I figured it would be straightforward to update kernel32.dll to finish KB2393802-v9. But nooo..... for some reason I just can't make it work at the assembler level, partially because I can't trace its progress. So I decided to bite the mother-of-all-bullets...rewrite kernel32.dll in C as well. In 5 days I've implemented 329 exported functions out of about 850, though the pace will slow down as the remaining ones become more and more complex. Nevertheless, it's proving to be a much simpler process than rewriting csrsrv and basesrv -- mainly because kernel32 apparently doesn't really do all that much: it farms out the heavy lifting to csrsrv, basesrv, winsrv, and ntdll and is mostly just a wrapper for those DLL's. So this mainly an exercise of cranking the handle by examining each function in IDA's decompiler and implementing a version that VS2005 can digest. In some cases IDA produces code that is pretty convoluted and I have to do some rewriting, but so far it's not nearly as bad as it was for csrsrv and basesrv -- the code in kernel32 just isn't that complex. I'm hoping that this will be the last DLL I have to rewrite to get the patch working, since there isn't that much involved in getting SxS support going, and I've already done all the kernel-side stuff. The big unknown will be making sxs.dll happy, though I don't expect to have to rewrite it, just include it.

Hey all, just a little news update... I've finished rewriting csrsrv in VS2005 for KB2393802 v9 and it's working well. I've significantly hardened it against attack and fixed what I think are several bugs in the original. I could take the hardening approach one step farther, but I haven't decided to do it yet as it would be pretty paranoid. I also think I've fixed the crash issue in the UP PAE kernel (ntkrnlpa.exe). Unfortunately (or fortunately, depending on how you look at it) I;m seeing that the SxS messages that my upgraded kernel32 is generating are getting lost in basesrv.dll (which csrsrv loads). The easiest thing to do is going to be to rewrite basesrv as well, which I think will be a lot easier since it's a lot smaller than csrsrv and now I have a starting codebase to work with. I'm still working nearly every day on KB2393802 v9 and I'm bound and determined to finish it. I've put in doxygen comments for all of the routines in my csrsrv, but not yet for variables, types, etc. I'm not sure that it's really necessary as they're pretty self-explanatory. If people wish I can post the sources for it in the meantime in case anyone wants to improve on it.

Yeah, that's a long-standing bug that I never fixed. Someday when I have some time I need to fix that. Maybe once 2393802-v9 is out. At present I'm still working on the csrsrv.dll rewrite, though there are only a handful of routines left to do. Then I have to test it, debug it, and harden it (and then I have to finish the patch...) No wonder there have been so many LPC exploits in Windows over the years. This DLL would *never* pass code reviews where I work. It's utter garbage.

Do you remember which applications had problems when XP's comctl32 was used? What exactly happened? XP's comctl32.dll is not compatible with the changes in 2479628. The layout of the cursor/icon structures are different. XP added 32-bit support fields in the middle of the structure, whereas to maintain backward compatibility in Win2k I had to add the extra fields to the end. In other news, I think I'm almost there with 2393802-v9, but I'm having issues getting the larger csrss messages going across from kernel32 to basesrv. They're getting dropped somewhere once they get into csrsrv. I decided that since csrsrv.dll is rather small, the easiest thing to do would be to rewrite it from scratch based on the disassembly and load it up with debugging output when it sees problems. The rewrite is about 90% finished, and in the process I'm finding that MS did a shockingly poor job in writing it. They left it wide open to crashes if it gets invalid inputs, and looking at the XP version shows that it isn't any better. I'm probably going to add a compiler directive so it can be compiled as an "original" version and a "paranoid" one. One major difference is that I'm writing it in Delphi 6.0 instead of C (since I'm just not a C person), but this affords me the opportunity to make *sure* that the code is valid. Just be glad I'm not writing it in Ada

Does Windows create a minidump file? The error is occurring in strstr(), but if I can identify how it got there it might not be hard to fix. I'll remember to investigate it before posting v9. I think I found the problem, though I can't really test it here. I guess we'll see what happens when I post v9...

Does Windows create a minidump file? The error is occurring in strstr(), but if I can identify how it got there it might not be hard to fix. I'll remember to investigate it before posting v9.