Windows Server 2003 (NT 5.2.3790.0) build guide

Code Additions

Some /g/ users have also added missing components & other fixes to the source, where available links have been provided here (though due to the nature of the internet, it’s very likely these links will eventually go down)

Win2k3 extra patches

A set of patches created by a helpful anon, check out their guide here, contains some very useful info.

XP source-ports

Some components missing from the Win2003 source can be found in the XPSP1 tree, although usually older than the component binaries shipped with Win2003 RTM (missing certain bugfixes etc). Some anons have had success porting them over to the Win2003 tree, & even updating them based on the Win2003 binaries.

  • base\hals\processor\: responsible for processr.sys, amdk6.sys, amdk7.sys, p3.sys & crusoe.sys

Wouldn’t build in the Win2k3 tree at first but an anon found what edits were needed to build, another anon later added updates to the code based on the Win2003 driver binaries. Has mostly been updated to Win2003 SP0 level, except for the GetAcpiTable function.

Latest version as of last guide update: processorXP_win2003_update.7z

  • base\ntsetup\pidgen\: responsible for pidgen.dll

The Win2003 RTM binaries expose some new exports missing from the XP version, required for Win2003 setup and other things to use it. These were added by an anon, but it was later found that Win2003 also makes use of a newer crypto library that allows for larger public keys to be used, which sadly isn’t available anywhere in the source packages.

This makes updating the XP code to match Win2003’s binaries a lot more difficult, but the updated code that uses newer exports can still come in useful for making a DLL that win2003’s setup can work with - eg. an anon has used this code to make a pidgen that accepts any key, seems to work great as long as winlogon doesn’t have WPA crap active.

Latest version as of last guide update: win2003_pidgenXP_cracked.zip (requires winlogon200X or patched winlogon 2003)

  • shell\osshell\accessib\magnify: responsible for magnify.exe & mag_hook.dll

Builds fine under Win2003, one anon figured how to update magnify.exe code to match the Win2003 binary (as narrator.exe code had the same changes made, and luckily we have the Win2003 version of that, the changes could easily be copied over)

  • base\fs\utils\dfrg: responsible for defrag.exe, dfrgntfs.exe, dfrgfat.exe, dfrgres.dll, dfrgsnap.dll & dfrgui.dll

Builds fine under Win2003, code is older than the actual Win2003 binaries though and missing some small updates/bugfixes. An anon later provided patched code that brings it closer to the Win2003 versions, although:

I couldn’t get GetExtentListManuallyFat & ScanNtfs matching, decided to leave those as they were in XPSP1 as I don’t trust my filesystem-code-writing skills that much.

Maybe some filesystem-wizard could get it updated fully, besides that there were also troubles with PDB paths, these were found to be mostly caused by razzle.cmd which was then fixed in a newer update of this guides accompanying ZIP file.

winlogon.exe

Unfortunately code for winlogon wasn’t included in this source kit, likely due to winlogon being one of the main files used in WPA. This prevents our builds from being able to boot up properly unless winlogon.exe is taken from a retail release (which is tampered with WPA activation & code obfuscation and who knows what else…)

To try getting around this an anon posted a version of winlogon’s code from win2000 ported over to server2003, and later another anon then fixed this port to re-enable the InitShutdown service (which was removed during the port due to missing files), and then found a fix to allow this built winlogon to get to the logon screen without restarting, while this was a good start at making the login prompt actually show without crashing unfortunately trying to logon would only greet you with an error message.

A few weeks went by with little progress, until a day when some anons started talking about getting the amd64 build booting, one of the main problems identified was winlogon - the only available amd64 binaries being from SP1+, which didn’t seem to work properly on our SP0 amd64 builds. This talk about winlogon eventually spurred an anon to start working on updating the win2000 code to match closer with the win2003 binary (a list of some of the changes made are available here)

Not long later a fixed version was produced that finally allowed logging into the system successfully, albeit with some issues such as fast-user switching not being supported, and profiles not being setup correctly, besides these small issues it overall seemed to work pretty well.

Sadly by the time anons had winlogon working & were starting to play with AMD64, the /wxp/ threads were also starting to die out, with idiots invading the thread to cause stupid arguments over trivial shit, making more & more people leave the threads for good…

However, one anon did actually stick around & managed to reverse XP’s winlogon properly, even releasing their decompilation that worked pretty much perfectly, sadly most anons never saw this as it was during the dying days of /wxp/, so many still think we’re stuck with the hacked up win2000 build - but now you know that isn’t the case!

(note that winlogon200X requires a small change for postbuild to succeed with this winlogon: edit winlogon\sources.inc, find the DELAYLOAD line, and change it to DELAYLOAD=winmm.dll;netapi32.dll;ole32.dll;msgina.dll - I’m not sure whether ds.zip also requires this or not)

systime.c/exinit.c

These two source files are missing from the base\ntos\ex folder, instead replaced by pre-compiled .obj files with the same name. Some investigating into these obj files shows a lot of WPA code being present, likely why code wasn’t provided for them.

An anon posted re-created .c files based on WRK’s objs which were made a while ago, these seemed to work fine on server2003, but were later found to cause BSODs. That anon later posted a fixed version which apparently solved the BSODs, but later anons also found this fixed version still had some issues of it’s own (using spinlocks while the .obj never did, missing functions that win2003 had but WRK didn’t), and another anon also found that the system-clock seemed to move a lot slower when using these re-creations.

Over time some small improvements were made to these files (with fixes like removing spinlocks), and an anon did some work getting systime.c to match with the .obj, mostly with success besides some minor parts.

After a few weeks an anon started posting exinit.c files which were “100% matching” for anons to test, once other anons tried them out and a few minor bugs were found & fixed that anon then posted a pack that also contained a systime.c recreation they were working on, that was also “100% matching”. Since then it’s had a few small updates to improve checked builds & fix 64-bit building, but generally appears to work fine.

So now after only a couple months since the leak dropped we finally have source code for exinit & systime that match up with the pre-compiled objs included in the leak, letting us make any changes to it that we like (such as removing expiration/timebomb code), as well as compile well-working versions of exinit/systime for AMD64 (since obj files for that platform weren’t included). Many thanks to all the anons that worked on it up to this point!

  • Latest version as of last guide update: win2003_missing-ex-files_v2.zip (included in prepatched v10a)

EncodePointer/DecodePointer kernel32 functions

These were added in XP SP2+ as a method for masking pointer addresses (as a security measure?), some apps that “require SP2” or “require Vista” actually only require these two functions. A /g/ user posted changes to allow stub functions to be exported, and a later user updated that so the functionality of the functions is also restored.

Sizzle dev-environment

A /g/ user ported over the OpenNT NTOSBE build-environment to the Win2003 source, as a replacement for the razzle build-environment that was included with the source.

Currently it can mostly build the sources fine, with a few issues noted by users (which are still waiting for a patch?). Post-build currently isn’t implemented with this though, but maybe using razzle afterwards to postbuild would allow for setup files to be generated?

Apparently can also handle building under AMD64 build OS’s too, along with Win10 support, and can mostly build all the 16-bit objects fine without any NTVDM issues.

DirectUI.lib

An anon found a period-appropriate version of Bison.exe & managed to fix up the Bison.skl file to allow building DirectUI.lib, but after some testing it was found that this version sadly doesn’t work properly compared to the pre-built XP version, producing a parse error when the code is ran.

The files needed for DirectUI are still included in the prepatched.zip for anyone that wants to try tackling this, it’s likely MS had customized the Bison.skl quite a bit, hopefully someone can figure out what exactly was changed…

For now we found that using pre-compiled parse.obj from the directuid.lib included with the source seems to work fine, of course using anything pre-compiled isn’t ideal, but at least this way we can still build the rest of DirectUI.lib from the source, rather than needing to rely on an entirely pre-compiled (and version-mismatching) directui.lib from XP.

Themes

An anon posted disassembled versions of all the officially released MS themes (Royale/Zune/Embedded etc), these disassembled versions just slot in to the existing source code, and will then be built as part of the normal build, with some small modifications to layout.inx they can also be included into our builds automatically.

Extra kernel32.dll functions

A fellow dev has worked on adding some extra functions to kernel32.dll, required by some newer apps, you can find more info about that here. (sadly the linked 20201202__KERNEL32.DLL.v6.zip file has since been deleted, but thanks to an anon has been reupped here: https://mirrorace.org/m/4rIp2)

Downlevel DLLs

Like with kernel32.dll, it seems there’s “downlevel” DLLs that some apps require to work, a user has made available versions of these for XP here. (and just like kernel32.dll the file has been deleted since, but thankfully has been reuploaded to https://mirrorace.org/m/5NDjE

author

created April 5, 2022

words 1798

tags #windows, #source