[WIP] Windows Vista Extended Kernel

[asdf2345]

On 9/7/2020 at 9:50 PM, asdf2345 said:

Most are from RTM SP2, but I'm pretty sure I posted some dumps from the 2017 EOS point, and the 2020 EOS point.

I'll try to get some more with the custom kernel tomorrow.

 

Bit late, but

Dumps.7z

[Dibya]

@asdf2345

It is possible to run newer Minport driver on XP by fixing missing api but DirectX/OpenGL will not run due to lack of XPDDM compatible user mode driver directive on WDDM 1.1 drivers.

[asdf2345]

1 minute ago, Dibya said:

@asdf2345

It is possible to run newer Minport driver on XP by fixing missing api but DirectX/OpenGL will not run due to lack of XPDDM compatible user mode driver directive on WDDM 1.1 drivers.

We're not talking about XP, we're talking about Vista

[Dibya]

Just now, asdf2345 said:

We're not talking about XP, we're talking about Vista

Structurally WDDM 1.1 is different to WDDM 1.0/

WDDM 1.0 handles GDI and DX10 differently , If NVIDIA left WDDM 1 directives , you guys are lucky.

[asdf2345]

2 minutes ago, Dibya said:

Structurally WDDM 1.1 is different to WDDM 1.0/

WDDM 1.0 handles GDI and DX10 differently , If NVIDIA left WDDM 1 directives , you guys are lucky.

Well, you could take a look and find out. I think that if the drivers even install, there has to be some of WDDM 1.0 left

[win32]

Technically Vista can take advantage of WDDM 1.1 features. I use driver version 320.92 x64 and DWM RAM usage remains stable even with over 25 windows open, as opposed to increasing linearly as what happens with WDDM 1.0.

I found this, 38x drivers running on Vista:

But how exactly? The kernel mode part has exported missing functions since 372.90.

[asdf2345]

4 minutes ago, win32 said:

Technically Vista can take advantage of WDDM 1.1 features. I use driver version 320.92 x64 and DWM RAM usage remains stable even with over 25 windows open, as opposed to increasing linearly as what happens with WDDM 1.0.

I found this, 38x drivers running on Vista:

But how exactly? The kernel mode part has exported missing functions since 372.90.

Maybe it'd be more worth it to mod 382.05 or 381.89 then

[burd]

9 hours ago, win32 said:

Technically Vista can take advantage of WDDM 1.1 features. I use driver version 320.92 x64 and DWM RAM usage remains stable even with over 25 windows open, as opposed to increasing linearly as what happens with WDDM 1.0.

I found this, 38x drivers running on Vista:

But how exactly? The kernel mode part has exported missing functions since 372.90.

Later on i found out , it doesn't work at all , 372.70 is indeed the last working so you are correct.

Edited September 10, 2020 by burd

[win32]

I have resigned myself to declaring that ntdll on Vista and up is indeed off limits. I again went to XP x64 for some inspiration and installed (Vista-compatible) Blender 2.90 on it. Several functions were missing like InitializeCriticalSectionEx. That function imports RtlInitializeCriticalSectionEx from ntdll, which also was introduced in Vista. So that requires doing the near-impossible, import table expansion.

Then I looked at One-Core-API. As @Ximonite pointed out, ntext helps extend ntdll. ntext is a layer between kernel32 and ntdll, and most of ntext is imports and forwards respectively from/to ntdll. No new imports unless we make our own binaries, but forwards are indeed exports from the file. The people designing the PE format certainly had some nice tricks up their sleeves! Though I was forwarding functions to ntdll from kernel32 in Windows 2000 back in June, so my memory is going I guess.

So this ntext would be a copy of ntdll with new and upgraded functions. But what about programs that call ntdll directly (which is frowned upon for win32 applications as kernel32 is what they're supposed to call as an intermediary)? A patcher that changes import table references from ntdll to ntext in a particular program is needed.

Preferably, I'd like to make the file that ntoskrnl loads and is integrity-checked a decoy named ntext (which would be the original ntdll), while everything else calls a modified ntdll (so no changes to import tables are necessary). But changing the reference to ntdll I found in ntoskrnl did nothing.

[burd]

2 hours ago, win32 said:

I have resigned myself to declaring that ntdll on Vista and up is indeed off limits. I again went to XP x64 for some inspiration and installed (Vista-compatible) Blender 2.90 on it. Several functions were missing like InitializeCriticalSectionEx. That function imports RtlInitializeCriticalSectionEx from ntdll, which also was introduced in Vista. So that requires doing the near-impossible, import table expansion.

Then I looked at One-Core-API. As @Ximonite pointed out, ntext helps extend ntdll. ntext is a layer between kernel32 and ntdll, and most of ntext is imports and forwards respectively from/to ntdll. No new imports unless we make our own binaries, but forwards are indeed exports from the file. The people designing the PE format certainly had some nice tricks up their sleeves! Though I was forwarding functions to ntdll from kernel32 in Windows 2000 back in June, so my memory is going I guess.

So this ntext would be a copy of ntdll with new and upgraded functions. But what about programs that call ntdll directly (which is frowned upon for win32 applications as kernel32 is what they're supposed to call as an intermediary)? A patcher that changes import table references from ntdll to ntext in a particular program is needed.

Preferably, I'd like to make the file that ntoskrnl loads and is integrity-checked a decoy named ntext (which would be the original ntdll), while everything else calls a modified ntdll (so no changes to import tables are necessary). But changing the reference to ntdll I found in ntoskrnl did nothing.

so making the winload.efi is still a thing or it wont be needed anymore?

[Sergiaws]

I could find extended kernel files in the download url of a youtube video uploaded by Winclient5270. I made a backup of the original dlls, then I booted my vm with a Windows PE disk and replace the original dlls with the modified dlls. I could boot the vm successfully but the extended kernel broke my screen reader (nvda 2017.3). It gives an error. I tried to run the narrator and it also don't work. Then I ran the .reg file which he had included but it doesn't help. So I don't know if it break something of MSAA. What can i try?

[win32]

1 hour ago, Sergiaws said:

I could find extended kernel files in the download url of a youtube video uploaded by Winclient5270. I made a backup of the original dlls, then I booted my vm with a Windows PE disk and replace the original dlls with the modified dlls. I could boot the vm successfully but the extended kernel broke my screen reader (nvda 2017.3). It gives an error. I tried to run the narrator and it also don't work. Then I ran the .reg file which he had included but it doesn't help. So I don't know if it break something of MSAA. What can i try?

Go to the folder where your screen reader is located and make a file named nvda.exe.local (or whatever the name of the exe is). Copy the original dlls into the screen reader's folder.

6 hours ago, burd said:

so making the winload.efi is still a thing or it wont be needed anymore?

Only if you want to use my ntoskrnl/ntkrnlmp on a UEFI system.Though you could use that loader/driver I mentioned earlier. But if you just need to use ntdll, it won't be needed anymore.

Edited September 10, 2020 by win32

[Sergiaws]

It doesn't help me, I think I will wait when extended kernel will be more advanced. However, thanks. And about Office 2016 in Windows Vista, did anyone try to run a portable version of Office 2013/2016 on Vista Extended Kernel?

[win32]

Lots of news.

I managed to work around ntdll somewhat. My ntext (ntdll with a new section and updated checksum) was successfully hooked by kernel32 through forwarded functions. But programs that call ntdll directly didn't go as well. Firefox would crash or pseudo-load hogging up several CPU threads. So I think a completely new wrapper dll that forwards to ntdll is necessary.

I was almost successful in getting the Windows 7 compatibility shimming framework to work (a modified aclayers.dll that fakes Windows 7 SP1 instead of RTM and acppage.dll in particular). But the latter calls registry-related functions from kernel32 instead of advapi32. So I added them to kernel32 forwarding to advapi32 but it didn't work as it would keep forgetting the compatibility options (those reg functions are slightly different on 7 than Vista but very difficult to implement). So it may be better to modify the Vista versions of the files, but it's not that clear cut to me, unless I were to replace one of the existing compatibility options (somehow I think no one really bothers with the 2003 SP1 option).

Edited September 11, 2020 by win32

[win32]

I tracked down the Perl script that effectively automates the process of making wrapper DLLs, especially for DLLs like ntdll which exports over 1800 functions:

http://web.archive.org/web/20070526114542/http://www.craigheffner.com/security/linkout.txt

This will prove essential for Vista and any future work for 7. And maybe even more so for 8.x and 10.

Though ActivePerl 5.26's installer errored out with this:

(0x80004005) the specified application is not a valid application for this OS platform.

Indeed, Windows Installer definitely knows it's "running" on 6.1.7601 SP1 based on the error log. I found the executable for the "state tool" and it had a subsystem version of 6.1, so that may have been the reason for the error, so perhaps I will follow BWC and disable the subsystem version testing like he did, after all (which will only work with system32 file replacement).

And just use Strawberry Perl anyway; it seems to work far better with Vista.

On another note, it appears that a new hack in my ntoskrnl (not released yet) to prevent it from changing CurrentVersion from NT 6.1 to 6.0 in the registry has fixed some OS functionality. When I added CoGetApartmentType to ole32.dll, I could no longer modify Sidebar widgets nor open folders with downloaded files through browsers. But I can do that with my modified ole32 once CurrentVersion is changed permanently. But not everything thinks it's on NT 6.1 yet (like RtlGetVersion), which is still a big problem that no one has solved since it arose in 2005. Windows compatibility mode will not solve it.

Edited September 21, 2020 by win32