PE Tool for creating patches

[tomasz86]

Thanks for such a quick fix

Do you plan to keep adding new functions later on?

These are my suggestions.

1. Functions required for .NET Framework 4.0:

ntdll.dll -> RtlCaptureContext, DbgPrintEx

kernel32.dll -> GetProcessId, RtlCaptureStackBackTrace

rpcrt4.dll -> RpcServerUnregisterIfEx

msvcrt.dll -> _resetstkoflw

ws2_32.dll -> freeaddrinfo, getaddrinfo, getnameinfo

advapi32.dll -> TraceMessage

2. Functions required for the M$ exFAT driver:

msvcrt.dll -> _except_handler4_common, _itow_s

ifsutil.dll -> ?DismountAndLock@IO_DP_DRIVE@@QAEEXZ, ?HardWrite@IO_DP_DRIVE@@IAEEVBIG_INT@@KPAXE@Z, ?Initialize@DP_DRIVE@@QAEEPBVWSTRING@@PAVMESSAGE@@EEG@Z, ?Initialize@VOL_LIODPDRV@@IAE?AW4FORMAT_ERROR_CODE@@PBVWSTRING@@PAVSUPERAREA@@PAVMESSAGE@@EEW4_MEDIA_TYPE@@GEI@Z, ?QueryDriveType@DP_DRIVE@@QBE?AW4DRIVE_TYPE@@XZ, ?QueryHotPlugInfo@DP_DRIVE@@QBEEXZ, ?QueryWriteBlockSize@DP_DRIVE@@UBEKXZ

ntoskrnl.exe -> CcMdlWriteAbort, DbgPrintEx, IoQueryFileDosDeviceName, SeFilterToken

I know there are a lot of them Still this list would be much longer but you've already included many of the required functions in your kernel patch

Edited October 4, 2011 by tomasz86

[WildBill]

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

[WildBill]

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.

Edited October 7, 2011 by WildBill

[tomasz86]

Remember that you must install MS11-011 before installing MS11-020.

[WildBill]

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.

Edited October 4, 2011 by WildBill

[tomasz86]

WildBill,

This is what I did for Windows Installer 4.5 (which I'm testing at the moment) to prevent it being installed when MS11-011 is not present.

[Prerequisite]
    condition=CompositeOp,AndOp,kernel32dll.Prereq.Section
    condition=CompositeOp,AndOp,ntdlldll.Prereq.Section

[Kernel32dll.Prereq.Section]
    SingleOp= Kernel32dll.Present.Section
    Display_String="KB2393802 is not installed."

[Kernel32dll.Present.Section]
    GreatOrEqualOp=CheckFilever,System32.Files,kernel32.dll,">=",5.0.2195.7136

[Ntdlldll.Prereq.Section]
    SingleOp= Ntdlldll.Present.Section
    Display_String="KB2393802 is not installed."

[Ntdlldll.Present.Section]
    GreatOrEqualOp=CheckFilever, System32.Files, ntdll.dll,">=",5.0.2195.7007

By the way, Windows Installer 4.5 seems to work flawlessly although the update.inf needs to be heavily modified to get everything installed (or slipstreamed) correctly.

Another solution would be just to combine both updates into one which would avoid any possible problems. There are two many single updates for w2k nevertheless (around 250 if you include HBRs).

Edited October 4, 2011 by tomasz86

[tomasz86]

WildBill,

There is a problem with the header of iphlpapi.dll:

You need to do

modifype iphlpapi.dll -c

to make it copy correctly during text setup. I can confirm that such a corrected file is copied with no problems.

[bristols]

Hi WildBill,

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.

Speaking of shoehorning... Would you consider releasing two kinds of patches for each respective MS update that you work on?:

- a patch that goes no further than to address the issue(s) that the original MS update addressed - that is to say, one that accepts the boundaries of, and tries simply to emulate, the official update

- a patch containing all the extra, more experimental stuff you're exploring here, which has a much wider scope than the original patch

This would allow less technical and/or more time-starved users to continue the journey of keeping their Windows 2000 systems alive, as well as those who might find your more experimental work interesting but have no immediate use for its potential benefits. I think you'd bring along more users of your updates if people had the option to install these 'faithful', more stable updates - it might give them more confidence to try the experimental patches at their leisure. As things stand, users of your patches are obliged to take some extra risk in order to keep their systems up-to-date, since they have to go along your more experimental path with you. In addition, the potential for conflicts between your patches and those made by others (for example, blackwingcat) is now growing, it seems to me.

Speaking for myself, I would like to have this option. I'd like to be able to check out your experimental work when it's more established.

What do you think? Is this unreasonable? Would keeping two separate branches for each update amount to too much extra work?

[WildBill]

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.

[MacLover]

With the addition of two more functions, XP's SCHANNEL.DLL can be used with Win2k (I've tested it with blackwingcat's Known DLL Wrapper and it works with IE6's SSL/TLS.)

The functions are:

ADVAPI32.DLL -> CredIsMarshaledCredentialW

KERNEL32.DLL -> GetSystemWow64DirectoryW

I also tested XP's OLEAUT32.DLL and it ended up causing a script error every time I entered a system folder. (It seems to break Win2k's Web View)

Edit:

I just tested XP's DNSAPI.DLL and it causes the system to take an extremely long time to get to the logon screen and then logon fails with domain not found message.

Edited October 4, 2011 by MacLover

[WildBill]

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.

[WildBill]

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.

Edited October 5, 2011 by WildBill

[MacLover]

I've been doing some poking around with Dependency Walker and my device drivers and I've noticed a few more APIs that should be added to Win2k:

NTOSKRNL.EXE -> _vsnwprintf (This would let me use the Widcomm Bluetooth Stack that came with my netbook as well as the LAN and HDMI drivers for the system)

NTOSKRNL.EXE -> RtlGetVersion (This would fix the AMD AHCI driver so that I could run Win2k on my main desktop with AHCI. This, an API in WIN32K.SYS and a couple KERNEL32 APIs would fix the ATI 11.x drivers)

NTOSKRNL.EXE -> KeFlushQueuedDpcs (This would fix the Widcomm Bluetooth Audio Driver)

KERNEL32.DLL -> ActivateActCtx (This is also needed for the Widcomm Stack)

KERNEL32.DLL ->CreateActCtxA (Widcomm Stack)

KERNEL32.DLL -> DeactivateActCtx (Widcomm Stack)

KERNEL32.DLL -> AddVectoredExceptionHandler (ATI Driver)

KERNEL32.DLL -> RemoveVectoredExceptionHandler (ATI Driver)

WIN32K.SYS -> EngIsSemaphoreOwned (ATI Driver)

Fixing the 2xx series nVidia drivers would require a lot more added APIs than any of the other drivers I looked at:

NTOSKRNL.EXE -> DbgPrintEx

ADVAPI32.DLL -> LsaLookupNames2

KERNEL32.DLL -> GetProcessId

KERNEL32.DLL -> ReleaseActCtx

PSAPI.DLL -> GetProcessImageFileNameW

SETUPAPI.DLL -> SetupDiGetActualSectionToInstallExW

SETUPAPI.DLL -> SetupUninstallOEMInfW

SETUPAPI.DLL -> SetupDiGetClassRegistryPropertyW

SETUPAPI.DLL -> SetupDiSetClassRegistryPropertyW

WTSAPI32.DLL -> WTSQueryUserToken

CRYPT32.DLL -> CryptStringToBinaryA

Again this stuff would be nice, but no rush. Just figured I'd give some suggestions

EDIT: Strange, According to MSDN, KeFlushQueuedDpcs was introduced in Server 2003, not XP and yet Widcomm looks for it and XP SP3 has the function...

EDIT: Whoops, Accidentally looked at a Vista DLL for Widcomm 5.6 (I accidentally added a Vista ADVAPI32.DLL function to the list)

EDIT: Oops Those MSVCRT Functions for the nVidia Driver were functions from Vista... (Accidentally looked at a Vista DLL again)

EDIT: Crossed out functions added in MS11-011 v4

EDIT: Crossed out functions added in MS11-011 v5

Edited November 21, 2011 by MacLover

[WildBill]

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.

Edited October 7, 2011 by WildBill

[tomasz86]

WildBill,

Thanks a lot for all of this Would it be possible either to update this post and update the list with the newer changes you've made or maybe you could add them to the 3rd post (where the list of updates is located) so it'd be easier to navigate and have everything in a one place.

I'll try to check different applications and see what works and what does not.

Actually I've experienced a problem with your patch. When I install it in my running system, it doesn't start after reboot - the monitor shuts down after the login screen disappears and Windows doesn't boot. In the beginning I thought that it was related to BlackWingCat's kernel v5 but it's the same even with the v2 of your patch. Even though all of the files got copied correctly, the problem still persists. I can boot to Safe Mode and after uninstalling the patches I can boot normally again. On the other hand, I did many tests on a VM with a slipstreamed CD including your patches and everything works fine

Edited October 7, 2011 by tomasz86