[tomasz86]

EDIT: From this moment all information about everything I do will be available here & here.

EDIT: There was a small bug in BETA5. Please use BETA5a instead.

I've prepared a BETA5 of Unofficial Updates Rollup. I've only fixed some bugs. This one is very likely to be the final version.


Windows2000-UURollup-BETA5a-x86-Global.exe (20 MB)

This post has been edited by tomasz86: 23 March 2012 - 07:41 AM

[blackwingcat]

msvcrt.dll (VC6 Runtime) compatible to Windows XP/2003.
I use in KDW msvcrt changed a little change from 2003's one.

Lastest DBGHELP.DLL is included in last SDK, and it is Advanced compatible to XP7s one.
Almost game installers include it.

CryptStringToBinaryA/W
WIndows 2000 has native both functions.
Plz see offcet 00072180 and 0007232A (5.131.2195.7147)

MacLover, on 19 October 2011 - 03:25 PM, said:

I just finished going through all of the files for VS2008 and found that the following APIs are needed to run it:

MSVCRT.DLL -> _vscwprintf (WIC)
MSVCRT.DLL -> _wtof (WIC, WPF)
MSVCRT.DLL -> _aligned_free (WIC)
MSVCRT.DLL -> _aligned_malloc (WIC)
MSVCRT.DLL -> ___lc_codepage_func (WPF, XPS)
MSVCRT.DLL -> ___lc_handle_func (WPF, XPS)
MSVCRT.DLL -> __uncaught_exception (WPF, XPS)
MSVCRT.DLL -> _resetstkoflw (WPF)
MSVCRT.DLL -> __crtGetStringTypeW (XPS)
MSVCRT.DLL -> __crtLCMapStringW (XPS)
MSVCRT.DLL -> ___mb_cur_max_func (XPS)
MSVCRT.DLL -> __pctype_func (XPS)
MSVCRT.DLL -> _strtoi64 (XPS)
MSVCRT.DLL -> _strtoui64 (XPS)

DBGHELP.DLL -> SymLoadModuleEx
DBGHELP.DLL -> SymEnumTypes
DBGHELP.DLL -> SymGetTypeInfo

CRYPT32.DLL -> CryptStringToBinaryA
CRYPT32.DLL -> CryptStringToBinaryW

[WildBill]

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.

[tomasz86]

@WildBill

The ole32.dll 5.0.2195.7060 from your 979687 seems to be buggy. Please check this and the following post.

This post has been edited by tomasz86: 03 April 2012 - 02:59 AM

[WildBill]

(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.

[WildBill]

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...

This post has been edited by WildBill: 14 May 2012 - 01:24 PM

[tomasz86]

Thanks WildBill

By the way, here is a slimmed down version of the update.inf for KB2393802-v9. All useless sections and lines have been removed so it's much easier to navigate.

Attached File(s)

•  update.inf (3.96K)
  Number of downloads: 10

This post has been edited by tomasz86: 14 May 2012 - 03:33 PM

[tomasz86]

These APIs are present in BWC kernel's kernel32.dll and are not included in yours:

ActivateActCtx
CheckRemoteDebuggerPresent
CreateActCtxA
CreateActCtxW
DeactivateActCtx
GetGeoInfoA
GetGeoInfoW
GetUserGeoID
ReleaseActCtx
WTSGetActiveConsoleSessionId

Would it be difficult to add them in the future version, especially the ones which have sth to do with ActCtx, i.e. ActivateActCtx, CreateActCtxA, CreateActCtxW, DeactivateActCtx & ReleaseActCtx? They help fix a lot of dependencies and also make it possible to use uxtheme.dll directly from %systemroot%\system32. Without these dependencies there are problems with .NET Framework (when uxtheme.dll is present in the system, that is).

This post has been edited by tomasz86: 14 May 2012 - 04:24 PM

[WildBill]

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.

[piotrhn]

In KB2393802-v9 fixed error with boot.ini->/PAE, now works ok without BSOD.

Thanks WildBill

[blackwingcat]

Hi,

Pe Tool v0.05 Seems to make broken out export table offset +0xc.
for example. Load hal.dll and save it. The name pointer is indicated "L.DLL"

[WildBill]

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)

This post has been edited by WildBill: 29 May 2012 - 03:31 AM

[tomasz86]

I think there's something wrong with the new version of ntdll.dll. My system gets stuck at the "preparing network connections" screen after installing the new version of the kernel and rebooting. Safe mode doesn't work too (it gets stuck at the login screen).

If I install it without the new ntdll.dll (=keep the ntdll.dll from v8) there are no problems. I've also installed it successfully in a VM (Virtualbox) where a uniprocessor non-PAE kernel is used. On my real system it's a multiprocessor PAE kernel.

This post has been edited by tomasz86: 01 June 2012 - 05:56 PM

[WildBill]

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.

[tomasz86]

I'm always ready to test although I can't really "improve" anything because of lack of any programming skills. I can only test the files in real environment.

By the way, it'd be nice go have

GetGeoInfoW
GetUserGeoID

in kernel32.dll. They are required for Chromium (Google Chrome, SRWare Iron) to work. The two APIs are present in BlackWingCat's kernel32.dll.

[piotrhn]

tomasz86, on 01 June 2012 - 05:55 PM, said:

I think there's something wrong with the new version of ntdll.dll. My system gets stuck at the "preparing network connections" screen after installing the new version of the kernel and rebooting. Safe mode doesn't work too (it gets stuck at the login screen).

If I install it without the new ntdll.dll (=keep the ntdll.dll from v8) there are no problems. I've also installed it successfully in a VM (Virtualbox) where a uniprocessor non-PAE kernel is used. On my real system it's a multiprocessor PAE kernel.

I installed Win2000 +KB2393802-v9, on real hardware:
Athlon 64 x2 5600+
4GB RAM
Geforce 9800gt
Gigabyte GA-MA790X-DS4

Everything works fine.

[blackwingcat]

Windows2000-KB2393802-v9-x86-ENU.exe seems that it only changes the expand registry functions , it isn't fixed other buffer overflow security holes.

http://blog.livedoor...es/1671977.html

This post has been edited by blackwingcat: 21 June 2012 - 08:17 PM

[blackwingcat]

I tried to use Windows2000-KB2393802-v9-x86-ENU.exe.
But it sometimes crashes with BSoD by Access VIOLATION on 0xA00A3512 in win32k.sys

A00A34E8 837D0CFC cmp dword ptr [ebp+0Ch],FFFFFFFCh
A00A34EC 7542 jnz LA00A3530
A00A34EE 8B7D08 mov edi,[ebp+08h]
A00A34F1 52 push edx
A00A34F2 52 push edx
A00A34F3 68E1010000 push 000001E1h
A00A34F8 57 push edi
A00A34F9 E85A89F6FF call SUB_LA000BE58
A00A34FE 89450C mov [ebp+0Ch],eax
A00A3501 50 push eax
A00A3502 E8D49EF7FF call SUB_LA001D3DB
A00A3507 85C0 test eax,eax
A00A3509 7425 jz LA00A3530
A00A350B 8B5510 mov edx,[ebp+10h]
A00A350E 85D2 test edx,edx
A00A3510 7C1E jl LA00A3530
A00A3512 3B5120 cmp edx,[ecx+20h] <-----------
A00A3515 7719 ja LA00A3530
A00A3517 85D2 test edx,edx
A00A3519 8B450C mov eax,[ebp+0Ch]
A00A351C 894314 mov [ebx+14h],eax
A00A351F 7514 jnz LA00A3535
A00A3521 8D774C lea esi,[edi+4Ch]
A00A3524 8D7B04 lea edi,[ebx+04h]

It seems somethings bad code.

This post has been edited by blackwingcat: 23 June 2012 - 07:36 AM

[WildBill]

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...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.

This post has been edited by WildBill: 23 June 2012 - 03:41 PM

[WildBill]

blackwingcat, on 23 June 2012 - 07:36 AM, said:

I tried to use Windows2000-KB2393802-v9-x86-ENU.exe.
But it sometimes crashes with BSoD by Access VIOLATION on 0xA00A3512 in win32k.sys

A00A34E8 837D0CFC cmp dword ptr [ebp+0Ch],FFFFFFFCh
A00A34EC 7542 jnz LA00A3530
A00A34EE 8B7D08 mov edi,[ebp+08h]
A00A34F1 52 push edx
A00A34F2 52 push edx
A00A34F3 68E1010000 push 000001E1h
A00A34F8 57 push edi
A00A34F9 E85A89F6FF call SUB_LA000BE58
A00A34FE 89450C mov [ebp+0Ch],eax
A00A3501 50 push eax
A00A3502 E8D49EF7FF call SUB_LA001D3DB
A00A3507 85C0 test eax,eax
A00A3509 7425 jz LA00A3530
A00A350B 8B5510 mov edx,[ebp+10h]
A00A350E 85D2 test edx,edx
A00A3510 7C1E jl LA00A3530
A00A3512 3B5120 cmp edx,[ecx+20h] <-----------
A00A3515 7719 ja LA00A3530
A00A3517 85D2 test edx,edx
A00A3519 8B450C mov eax,[ebp+0Ch]
A00A351C 894314 mov [ebx+14h],eax
A00A351F 7514 jnz LA00A3535
A00A3521 8D774C lea esi,[edi+4Ch]
A00A3524 8D7B04 lea edi,[ebx+04h]

It seems somethings bad code.

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.