Jump to content

[WIP] Windows Vista Extended Kernel


win32

Recommended Posts

50 minutes ago, burd said:

@win32

i get a range check error in export table tester, not sure why

im using kernel32 from SysWoW64 

Edit: redid it and no errors now

 

https://imgur.com/a/A5Tx9CF

I have since revised the instructions due to the corruption issues I experienced.

If all tables are good (you can check them each in CFF), then you don't have anything to worry about anyway though they will be useful with future updates.

Link to comment
Share on other sites


1 hour ago, win32 said:

I have since revised the instructions due to the corruption issues I experienced.

If all tables are good (you can check them each in CFF), then you don't have anything to worry about anyway though they will be useful with future updates.

my .xdata is blank although i have copy pasted right before 000D3A00 in hxd where the ending was, not sure if i have done it correctly, i also noticed that the file size changed on its own as shown in the below link :angry:

https://imgur.com/a/vvLodTv

 

seems like i managed to do it following the updated instructions , its tough considering i have the newer kernel which makes it confusing while reading it side by side with no experience whatsoever.

Edited by burd
Link to comment
Share on other sites

Is there a chance that this would work with version 6.0.6002.18005?

 

I've never really had experience with messing around with .dll files in this kind of way.

 

Edited by WindowsVista
Link to comment
Share on other sites

31 minutes ago, WindowsVista said:

Is there a chance that this would work with version 6.0.6002.18005?

Yes, but be mindful of any differences in memory offsets and addresses when compared to the versions shown here. And I'd be quite concerned about other missing API functions if that's pre-Platform Update (which I think it is).

Edited by win32
Link to comment
Share on other sites

42 minutes ago, win32 said:

Yes, but be mindful of any differences in memory offsets and addresses when compared to the versions shown here. And I'd be quite concerned about other missing API functions if that's pre-Platform Update (which I think it is).

Thank you,

i was wondering if i could make a Windows Vista ISO file with the updated kernel32.dll file.

Link to comment
Share on other sites

39 minutes ago, WindowsVista said:

Thank you,

i was wondering if i could make a Windows Vista ISO file with the updated kernel32.dll file.

You would have to add the kernel32.dll to the install.wim inside your ISO and I'm not sure exactly how to directly replace files within a wim/esd. But, with my updated instructions there is no need to replace system files - simply backup your modified kernel32.dll somewhere else and then add it to the folders of programs where it would be necessary, along with the xxxx.exe.local to redirect your programs to your updated file.

Edited by win32
Link to comment
Share on other sites

Update on x86 extension:

I have refined the implementation of SetThreadErrorMode, (Rtl)TryAcquireSRWLockExclusive and (Rtl)TryAcquireSRWLockShared.

On the x64 side, I've got SetThreadErrorMode and its dependency BaseSetLastNTError. x86 SetThreadErrorMode is based on Windows 2000 extended kernel code, though all others are based on Windows 7 code. Next up is GetCurrentProcessorNumberEx (needed by Pale Moon 28.10.0) and the entire K32* series of functions (there are about 25 of them). And then a few stragglers in user32 and shell32 will be added.

The manual patching instructions will be updated once kernel32.dll is filled out with all of the planned functions.

On another note, I have found a limitation of the DLL redirection scheme. While it works wonderfully for say, kernel32.dll where the program will call the local version, and even other system dlls (not located in the local directory) would refer back to the local version, it appears that ntdll.dll is exempt from it. Mind you I haven't applied the reg key mentioned in the article yet that would allow system-wide DLL redirection.

And as it stands, all program execution (as in GIMP 2.10.8 and a recent version of oCam) using my x86 kernel32/ntdll combo fails ATM. Yes, I did try renaming the local ntdll to ntdl1 then adjusting kernel32's import table accordingly. That still didn't work out as a fault occurred in the main ntdll at 0x77E0F7B3 (RtlInitializeNtUserPfn). I will keep investigating.

update: x86 ntdll is unbootable, but x64 kernel32 still boots to a stable system, now with K32GetProcessMemoryInfo implemented.

Edited by win32
Link to comment
Share on other sites

19 hours ago, win32 said:

Update on x86 extension:

I have refined the implementation of SetThreadErrorMode, (Rtl)TryAcquireSRWLockExclusive and (Rtl)TryAcquireSRWLockShared.

On the x64 side, I've got SetThreadErrorMode and its dependency BaseSetLastNTError. x86 SetThreadErrorMode is based on Windows 2000 extended kernel code, though all others are based on Windows 7 code. Next up is GetCurrentProcessorNumberEx (needed by Pale Moon 28.10.0) and the entire K32* series of functions (there are about 25 of them). And then a few stragglers in user32 and shell32 will be added.

The manual patching instructions will be updated once kernel32.dll is filled out with all of the planned functions.

On another note, I have found a limitation of the DLL redirection scheme. While it works wonderfully for say, kernel32.dll where the program will call the local version, and even other system dlls (not located in the local directory) would refer back to the local version, it appears that ntdll.dll is exempt from it. Mind you I haven't applied the reg key mentioned in the article yet that would allow system-wide DLL redirection.

And as it stands, all program execution (as in GIMP 2.10.8 and a recent version of oCam) using my x86 kernel32/ntdll combo fails ATM. Yes, I did try renaming the local ntdll to ntdl1 then adjusting kernel32's import table accordingly. That still didn't work out as a fault occurred in the main ntdll at 0x77E0F7B3 (RtlInitializeNtUserPfn). I will keep investigating.

update: x86 ntdll is unbootable, but x64 kernel32 still boots to a stable system, now with K32GetProcessMemoryInfo implemented.

I made a custom Windows Vista Image called Windows Vienna (Named after Windows 7's codename) 

I gave it it's own kind of look anyway i'm kinda off topic.

 

I used a program called gimagex which is very useful.

all you have to do is extract install.wim from the .ISO file and mount it but be sure to select the 'read and write' check box.

you can directly replace the modified kernel32.dll file in the Windows directory without any permission issues.

once done, check 'commit changes' and then select unmount.

 

here's what i achieved whith gimagex:

this took me 2 years to develop btw.

Vienna M12 2.jpg

Edited by WindowsVista
Link to comment
Share on other sites

14 hours ago, WindowsVista said:

I used a program called gimagex which is very useful.

all you have to do is extract install.wim from the .ISO file and mount it but be sure to select the 'read and write' check box.

you can directly replace the modified kernel32.dll file in the Windows directory without any permission issues.

once done, check 'commit changes' and then select unmount.

Very interesting. It's nice to find out all of the ways to customize and modify NT 6.x much like we have been doing to NT 5.x for many years. Unfortunately that doesn't mitigate the risk of it being overwritten by updates though.

Though I think that guy who was trying to get fully slipstreamed Vista install media with all updates-to-present would be interested.

On another note, this snippet of code is giving me a lot of trouble:

xdata:0000000078E6D07F loc_78E6D07F:                           ; CODE XREF: SetThreadErrorMode+4Aj
.xdata:0000000078E6D07F                 lea     rdx, [rsp+30h]
.xdata:0000000078E6D084                 call    near ptr RtlSetThreadErrorMode
.xdata:0000000078E6D089                 nop
.xdata:0000000078E6D08A                 cmp     eax, ebx
.xdata:0000000078E6D08C                 jge     short loc_78E6D092
.xdata:0000000078E6D08E                 mov     ecx, eax
.xdata:0000000078E6D090                 jmp     short loc_78E6D056

GIMP crashes when it encounters the nop. I know that it should be

xdata:0000000078E6D07F loc_78E6D07F:                           ; CODE XREF: SetThreadErrorMode+4A↑j
.xdata:0000000078E6D07F                 lea     rdx, [rsp+30h]
.xdata:0000000078E6D084                 call    cs:RtlSetThreadErrorMode
.xdata:0000000078E6D08A                 cmp     eax, ebx
.xdata:0000000078E6D08C                 jge     short loc_78E6D092
.xdata:0000000078E6D08E                 mov     ecx, eax
.xdata:0000000078E6D090                 jmp     short loc_78E6D056

But IDA doesn't like me patching that and turns it into this

.xdata:0000000078E6D07F ; ---------------------------------------------------------------------------
.xdata:0000000078E6D084                 db  9Ah ; š
.xdata:0000000078E6D085                 db 0C0h ; À
.xdata:0000000078E6D086                 db 0E8h ; è
.xdata:0000000078E6D087                 db 0DFh ; ß
.xdata:0000000078E6D088                 db  78h ; x
.xdata:0000000078E6D089                 db    6
.xdata:0000000078E6D08A                 db    0
.xdata:0000000078E6D08B ; ---------------------------------------------------------------------------

No better of course and it crashes on the shambolic non-code. I tried just placing the W7 version of RtlSetThreadErrorMode into my kernel32, but it called something in a completely unrelated function just above it (GetCurrentProcessorNumberEx+2) and failed there.

I also wonder why RtlSetThreadErrorMode was implemented in Vista but SetThreadErrorMode wasn't until 7.

update: So I noticed two calls to the same import, CsrClientCallServer (78DFE090). The one at 78DA0B24 looks like this:

FF 15 66 D5 05 00

While the call to it at 78DA0BA1 is like this:

FF 15 E9 D4 05 00

Perhaps I need to deduce something from that. Putting these somewhere else will direct them to a completely different memory address, so I need to figure out how to get to call 78DFE8C0 (RtlSetThreadErrorMode).

update: Apparently, a call cs:* only will call memory addresses below it, using the FF 15 ** ** 0* 00 format. But a quick look at XP x64's kernel32 reveals that the import table is at the beginning of the file, so call cs:* must refer to addresses above them. And the format for those is FF 15 ** ** FF FF (for close ones seemingly) or FF 15 ** F5 FF for ones very far away, with options for going in between. In the end, I was able to call RtlSetThreadErrorMode using hex code FF 15 36 18 F9 FF.

And it fixed everything SetThreadErrorMode! YIP YIP HOORRRRRRRRRRRAY!!!!!!!!!!!!!!!!!!! I will promptly correct the other functions.

10 hours ago I actually doubted myself enough that I briefly thought that I went in wayyyy over my head with this supposed vapourware project but now it is anything but!!! I even did a little editing of the photo in there. Still some missing functions so other components may not work well but I think I've got all figured out.

windows-vista-is-back.png

 

Edited by win32
Link to comment
Share on other sites

18 hours ago, win32 said:

Very interesting. It's nice to find out all of the ways to customize and modify NT 6.x much like we have been doing to NT 5.x for many years. Unfortunately that doesn't mitigate the risk of it being overwritten by updates though.

Though I think that guy who was trying to get fully slipstreamed Vista install media with all updates-to-present would be interested.

On another note, this snippet of code is giving me a lot of trouble:


xdata:0000000078E6D07F loc_78E6D07F:                           ; CODE XREF: SetThreadErrorMode+4Aj
.xdata:0000000078E6D07F                 lea     rdx, [rsp+30h]
.xdata:0000000078E6D084                 call    near ptr RtlSetThreadErrorMode
.xdata:0000000078E6D089                 nop
.xdata:0000000078E6D08A                 cmp     eax, ebx
.xdata:0000000078E6D08C                 jge     short loc_78E6D092
.xdata:0000000078E6D08E                 mov     ecx, eax
.xdata:0000000078E6D090                 jmp     short loc_78E6D056

GIMP crashes when it encounters the nop. I know that it should be


xdata:0000000078E6D07F loc_78E6D07F:                           ; CODE XREF: SetThreadErrorMode+4A↑j
.xdata:0000000078E6D07F                 lea     rdx, [rsp+30h]
.xdata:0000000078E6D084                 call    cs:RtlSetThreadErrorMode
.xdata:0000000078E6D08A                 cmp     eax, ebx
.xdata:0000000078E6D08C                 jge     short loc_78E6D092
.xdata:0000000078E6D08E                 mov     ecx, eax
.xdata:0000000078E6D090                 jmp     short loc_78E6D056

But IDA doesn't like me patching that and turns it into this


.xdata:0000000078E6D07F ; ---------------------------------------------------------------------------
.xdata:0000000078E6D084                 db  9Ah ; š
.xdata:0000000078E6D085                 db 0C0h ; À
.xdata:0000000078E6D086                 db 0E8h ; è
.xdata:0000000078E6D087                 db 0DFh ; ß
.xdata:0000000078E6D088                 db  78h ; x
.xdata:0000000078E6D089                 db    6
.xdata:0000000078E6D08A                 db    0
.xdata:0000000078E6D08B ; ---------------------------------------------------------------------------

No better of course and it crashes on the shambolic non-code. I tried just placing the W7 version of RtlSetThreadErrorMode into my kernel32, but it called something in a completely unrelated function just above it (GetCurrentProcessorNumberEx+2) and failed there.

I also wonder why RtlSetThreadErrorMode was implemented in Vista but SetThreadErrorMode wasn't until 7.

update: So I noticed two calls to the same import, CsrClientCallServer (78DFE090). The one at 78DA0B24 looks like this:

FF 15 66 D5 05 00

While the call to it at 78DA0BA1 is like this:

FF 15 E9 D4 05 00

Perhaps I need to deduce something from that. Putting these somewhere else will direct them to a completely different memory address, so I need to figure out how to get to call 78DFE8C0 (RtlSetThreadErrorMode).

update: Apparently, a call cs:* only will call memory addresses below it, using the FF 15 ** ** 0* 00 format. But a quick look at XP x64's kernel32 reveals that the import table is at the beginning of the file, so call cs:* must refer to addresses above them. And the format for those is FF 15 ** ** FF FF (for close ones seemingly) or FF 15 ** F5 FF for ones very far away, with options for going in between. In the end, I was able to call RtlSetThreadErrorMode using hex code FF 15 36 18 F9 FF.

And it fixed everything SetThreadErrorMode! YIP YIP HOORRRRRRRRRRRAY!!!!!!!!!!!!!!!!!!! I will promptly correct the other functions.

10 hours ago I actually doubted myself enough that I briefly thought that I went in wayyyy over my head with this supposed vapourware project but now it is anything but!!! I even did a little editing of the photo in there. Still some missing functions so other components may not work well but I think I've got all figured out.

windows-vista-is-back.png

 

Nice one,thats quite an accomplishment there,i hope you are planning to add more functions soon in your spare time,do keep us updated with the code/progress. :thumbup

Link to comment
Share on other sites

8 hours ago, burd said:

Nice one,thats quite an accomplishment there,i hope you are planning to add more functions soon in your spare time,do keep us updated with the code/progress. :thumbup

Yes. I just need to do about ten more patches of call near ptr to call cs: in the nine existing functions, and then I'll be adding more. These are other missing ones that I've found to be called by programs:

GetNumaNodeProcessorMaskEx

GetCurrentPackageId

GetSystemTimePreciseAsFileTime

plus their dependencies and sister functions

Those are going on the list along with the other unimplemented K32 functions as well as TryAcquireSRWLockShared (not sure why I shelved it earlier - perhaps because it's really a ntdll function but it doesn't matter since nothing really seems to call them directly from ntdll so it can go into kernel32, like BWC has done).

Anyway, I really like these x64 dlls. MS gets to do its own thing in its own code section, while I can just make a section for myself and move the export table to its own section and things are good. All of the existing functionality of Vista is retained and not a single beat is skipped. And if you choose not to replace your existing kernel32.dll and just use the modified one on a per-program basis using .exe.local redirectors, you will be preventing the direct execution of malicious executables requiring W7+ functions.

I'm also thinking about compatibility shims - One-Core-API expanded the amount of shims available in XP to include OSes like Vista/7/8.1/10. I think that I need something like that to get some installers to run since that seems to go above and beyond what Application Verifier can provide.

Edited by win32
Link to comment
Share on other sites

Wow! Am I dreaming?! Vista Extended Kernel is a reality?! 

Thank you, @win32 for putting work into this project and bringing it to fruition, and creating this tutorial. This is something that has been discussed & yearned for among those of us "old-timers" in the Vista community as early back as 2013/2014, and the closest thing we ever got was @smeezekitty's proxy stub DLL wrappers for Adobe Reader DC & Catalyst Omega, but unfortunately he has been inactive since 2016 :(

I never thought anyone would ever come forward with a full-blown extended kernel project. This is very exciting & promising as I had planned to stick with Windows Vista indefinitely, but worried for the future as software support (namely browsers) has continued to diminish. I'm not much experienced with any kind of coding, but if I can be of help in any way, do let me know.

I apologize to everyone here in the Vista community for being so inactive lately. Being an "essential" employee (letter carrier for USPS) during a pandemic is not easy! Package volume is through the roof since no one (understandably) wants to get out :P Hope everyone here is staying safe.

Link to comment
Share on other sites

I have now fixed the import calls and added K32EmptyWorkingSet. So about 26 more functions to go in kernel32!

OBS Studio 19.2.0 is mostly working now, but there are a few missing functions in MFPlat.dll (Media Foundation Platform), like MFTEnumEx (used to find video/audio decoders) and MFCreateMFByteStreamOnStream. While it picks up on audio, it doesn't record or show video and creates tiny (corrupt) files. Or it may be because it forces a D3D11 renderer and my DX10 native GPU doesn't seem to work very well with DX11 (Cities: Skylines is unplayably glitchy in D3D11 mode on Vista and 7 but fine in D3D9 mode on XP x64).

I think that the media foundation extensions will be fun, as I may even introduce the functions from Windows 8 as opposed to just the ones new to 7. That would mean adding stuff like Direct3D 11-based video APIs. Though adding DX11.1+ features will be pointless if the drivers available for Vista can't use them. And getting WDDM 1.1+ drivers on Vista is going to be one difficult undertaking, but probably easier than porting WDDM 1.0 drivers to XDDM (Windows 2000 Display Driver Model).

And I've found another limitation of LOCAL files. Programs don't like being debugged when redirection is taking place to files within folders; they throw a fault in StackHash_**** when trying to launch them through Dependency Walker. But if the same file is loaded from system32 as opposed to the program directory, with no redirection taking place, the program works (as well as possible) through Dependency Walker. So I thought about .manifest files, which give you the option to redirect only the files specified within them.

Here is an example of the contents of a manifest file used for DLL redirection:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity version="1.0.0.0" name="redirector" type="win32" />
    <file name="kernel32.dll"> </file>
</assembly> 

But it appears that manifest files don't seem to help much in that regard. So I guess you will have to replace your system files with mine if you're planning on debugging programs using my files.

4 hours ago, WinClient5270 said:

I'm not much experienced with any kind of coding, but if I can be of help in any way, do let me know.

Once I get a wide array of programs working stable, I hope that you do one of your excellent videos about the kernel's capabilities. You create some great promotional tools for Vista, and this one will explore some uncharted territory for the OS.

On one last note, this isn't the only new kernel extension project that helps Vista users out:

The tutorial specifically mentions building for x86, but I built it in the Vista x64 build environment in the Windows 7 DDK, so it could help with certain classes of drivers. Will it help for modern GPU drivers? Not really. NVMe and USB 3? Sure.

 

Link to comment
Share on other sites

On 6/21/2020 at 3:41 AM, win32 said:

And getting WDDM 1.1+ drivers on Vista is going to be one difficult undertaking, but probably easier than porting WDDM 1.0 drivers to XDDM (Windows 2000 Display Driver Model).

With that it would be possible to use newer AMD and nVidia GPUs, which would be a dream come true :)

Do keep on posting updates, this is an extremely interesting project.

Link to comment
Share on other sites

On 6/20/2020 at 10:41 PM, win32 said:

Once I get a wide array of programs working stable, I hope that you do one of your excellent videos about the kernel's capabilities. You create some great promotional tools for Vista, and this one will explore some uncharted territory for the OS.

Absolutely! And thank you for the kind words about my YouTube videos. Unfortunately I haven't made another one in a while due to being so busy IRL, but I'll try to make another one soon. I will certainly make one on your kernel extension project for Vista in the future, too. 

Speaking of getting programs working, I have one that you may be interested in trying: After growing up with the widely-beloved original console game from 2003, I decided to purchase the newly released SpongeBob SquarePants: Battle for Bikini Bottom Rehydrated on Steam. To my dismay (but not to my surprise), it will not run in Windows Vista due to several missing functions. It apparently works with Windows 7 or later according to the Steam page (Win7/8.1 support is claimed in the Additional Notes section), but at least two of these functions are exclusive to Windows 8 or later, so unless these are simply delay load functions that don't prevent the game from running in Windows 7 (I have yet to test it on that OS), then the game will only run in Windows 8 or later. 

After inspecting the game's executable with Dependency Walker, I came up with this list of missing functions in some DLLs within Windows Vista. Here is a list of missing functions (I know you've already integrated some of these):

KERNEL32.DLL missing functions:
GetCurrentPackageId
GetSystemTimePreciseAsFileTime
K32EnumProcessModules
K32GetProcessMemoryInfo
SetThreadErrorMode
TryAcquireSRWLockExclusive

USER32.DLL missing functions:
CloseTouchInputHandle
GetTouchInputInfo
RegisterTouchWindow

MF.DLL missing functions:
MFCreateDeviceSource
MFEnumDeviceSources

MFPLAT.DLL missing functions:
MFCreateDXGIDeviceManager
MFCreateDXGISurfaceBuffer
MFCreateMFByteStreamOnStream
MFCreateSourceResolver
MFPutWaitingWorkItem

Edited by WinClient5270
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...