Jump to content

[WIP] Windows Vista Extended Kernel


win32

Recommended Posts

On 9/9/2020 at 10:11 AM, 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.

Quite late, but I was reading the Wikipedia page about WDDM, and found this

"DXGI 1.1, Direct3D 11, Direct2D, and DirectWrite were made available with Windows Vista Platform Update; however GDI/GDI+ in Vista continues to rely on software rendering and the Desktop Window Manager continues to use Direct3D 9Ex.

WDDM 1.1 drivers are backward compatible with WDDM 1.0 specification; both 1.0 and 1.1 drivers can be used in Windows Vista with or without the Platform Update."

Link to comment
Share on other sites


On 6/15/2020 at 3:15 AM, win32 said:

To prevent user confusion, I strongly recommend disregarding the tutorials and contacting me directly instead about the extended kernel. The original post appears below for prudency.

  Hide contents

For x86 kernel extension, see this post:

 

Attention Windows Vista x64 users!

Did you feel wounded by the way your OS was surpassed by NT 6.1? And felt salt being poured into those wounds when BlackWingCat implemented some of those NT 6.1+ functions in his extended kernel for NT 5.0?

Now I'm here to give Windows Vista the leg up it has always deserved! All you need is CFF Explorer and ExportTableTester. (rules prohibit the distribution of modified MS binaries)

First, enter X:\Windows\System32 (where X: is the letter of your system partition) and copy kernel32.dll (for this experiment, I'm using version 6.0.6002.19623; this method is applicable to versions through 6.0.6003.20686. users with later versions check out my second post below) to another folder. Open that copy of kernel32.dll in CFF Explorer and click "Section Headers [x]" on the left sidebar.

Keep your attention on the .text section and scroll down to the bottom of the hex representation of the section, where you will find a portion filled with zeros. Then starting at offset 000BCF50, add all of the non-zero code shown in the image below:

 

Save the file and exit CFF Explorer. Open ExportTableTester and drag-and-drop the file into its window. Click "Edit Exports" at the bottom of the window.

Enter each of the 000BCF** offsets referenced in the left window into the "Address of Function (Hex)" field on the right, followed by the function names associated with them below.

 

Reopen the file in CFF Explorer, click "Rebuilder" on the left sidebar, select the checkboxes for "Rebuild PE Header" and "Update Checksum" then click "Rebuild" before saving.

Place your modified kernel32.dll in the folder of each application that requires it. Create a file labelled "xxxx.exe.local" (where xxxx is the name of the application executable) in order to direct the executable to use the modified kernel32.dll as opposed to the one in the system32/sysWOW64 folder.

If you do the same steps as I did, you should be successful in this endeavour. As a sanity check, I opened Dependency Walker x64, checked the present kernel32.dll and it had those K32* functions previously exclusive to Windows 7 and up. What a feeling of accomplishment!

 

WARNING

Remember to keep the "Add New Section" checkbox enabled in ExportTableTester. If not selected, the expanded export table will overwrite some other code below it, which buggered up keyboard layout/localization settings (for example, all keyboard layouts under "English (Canada)" would function like the Canadian French keyboard).

Please test thoroughly and post in this thread about any issues that may arise. ExportTableTester, according to other users, may have issues of its own, but no other known tools will manipulate PE32+ export tables the way it does.

I plan on eventually introducing additional functions in kernel32.dll as well as in other system files to meet my first goal: running Waterfox 2020.03! In fact, all of the functions that have been added to kernel32 are the missing ones required by its xul.dll (with the exception of TryAcquireSRWLockExclusive, which forwards to ntdll.dll).

Hello.

Tried to run Euro Truck Simulator 2 and Garrys Mod (with Oct 2nd 2019 Steam build -which requires Ex-Kernel-) and they work absolutely fine.

However when I try to run Payday 2 it just crashes like "payday2_win32_release.exe stopped working" and when I view extra details it has something to do with "kernel32.dll"

Maybe you should take a look.

Much much regards.

Link to comment
Share on other sites

24 minutes ago, C9_Slips said:

However when I try to run Payday 2 it just crashes like "payday2_win32_release.exe stopped working" and when I view extra details it has something to do with "kernel32.dll"

Take a screenshot of the error dialog and post it here. Then I'll know what to do (hopefully). Is the game 32 or 64 bit?

 

I have now built a functional 32bit wrapper for ntdll, and it is being used by my kernel32 right now. So the focus will be on 32bit usermode improvements for the next while.

So the functions to be upgraded to Windows 7 specifications:

NtQueryInformationProcess

NtQuerySystemInformation

and probably more...

And now I want to deal with RtlGetVersion. I think I'm close to figuring it out.

.text:0000000078E9BD76                 mov     eax, [r9+118h]
.text:0000000078E9BD7D                 mov     [rcx+4], eax
.text:0000000078E9BD80                 mov     eax, [r9+11Ch]
.text:0000000078E9BD87                 mov     [rcx+8], eax
.text:0000000078E9BD8A                 movzx   eax, word ptr [r9+120h]
.text:0000000078E9BD92                 mov     [rcx+0Ch], eax
.text:0000000078E9BD95                 mov     eax, [r9+124h]
.text:0000000078E9BD9C                 mov     [rcx+10h], eax
.text:0000000078E9BD9F                 mov     r8, [r9+2F0h]

I think the r9+xxh indicates the ULONG values in the OSVERSIONINFOEXW structure. I believe that the r9+11Ch would indicate OSVersionInfoSize, whereas the other four pertain to MajorVersion, MinorVersion, BuildNumber and PlatformId. I just need to find a lightweight application with a OSVERSIONINFO(EX)W structure and set up a breakpoint in there and hopefully I'll know which is which.

Edited by win32
Link to comment
Share on other sites

6 hours ago, win32 said:

I have now built a functional 32bit wrapper for ntdll, and it is being used by my kernel32 right now. So the focus will be on 32bit usermode improvements for the next while.

So the functions to be upgraded to Windows 7 specifications:

NtQueryInformationProcess

NtQuerySystemInformation

and probably more...

And now I want to deal with RtlGetVersion. I think I'm close to figuring it out.


.text:0000000078E9BD76                 mov     eax, [r9+118h]
.text:0000000078E9BD7D                 mov     [rcx+4], eax
.text:0000000078E9BD80                 mov     eax, [r9+11Ch]
.text:0000000078E9BD87                 mov     [rcx+8], eax
.text:0000000078E9BD8A                 movzx   eax, word ptr [r9+120h]
.text:0000000078E9BD92                 mov     [rcx+0Ch], eax
.text:0000000078E9BD95                 mov     eax, [r9+124h]
.text:0000000078E9BD9C                 mov     [rcx+10h], eax
.text:0000000078E9BD9F                 mov     r8, [r9+2F0h]

 

have you released this?

Edited by burd
Link to comment
Share on other sites

16 minutes ago, jns629 said:

Can Someone Post The Links to the files which are done extending?

The extended kernel isn't ready for public release yet. You will need to direct message win32 to get the link.

Link to comment
Share on other sites

3 hours ago, Ximonite said:

The extended kernel isn't ready for public release yet. You will need to direct message win32 to get the link.

There are a few places where binaries have been released publicly, but they are probably very outdated, and it will probably never be posted directly on here due to file redistribution policies. Only the ntext files can be posted directly because I compiled them and not MS.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

So for those who want to know more about RtlGetVersion, which is the "root" function for other functions like RtlVerifyVersionInfo, VerifyVersionInfoW, etc.

I found that:

r9+118h equals MajorVersion

r9+120h equals BuildNumber (little endian of course)

Those are easy to modify by making the mov eax, [r9 + xxh] into mov eax, 5 or something similar. But r9+11Ch seems to be what I think it is, and r9+124h and r9+2F0h are problematic when changed. PlatformId is not something I want to change, and I think applications will be satisfied with SP2, but where exactly is MinorVersion? I suspect r9+124h but

So what should be done? Changing MajorVersion to 10 is not a good idea, as many browsers fail if compatibility shimmed to 6.2 and above. And Windows 10 tells legacy software that it's NT 6.2 anyway.

And also, changing values grabbed from memory to fixed ones can also depreciate the value of Windows compatibility mode, since they rely on RtlGetVersion to get the changed version numbers.

Things may be easier on the kernelmode side anyway. I think I just answered the question I asked some time ago:

ntoskrnl!RtlGetVersion - Vista SP2 6002

                        public RtlGetVersion
PAGE:000000014037FE50 RtlGetVersion   proc near               ; CODE XREF: RtlVerifyVersionInfo+65↑p
PAGE:000000014037FE50                                         ; sub_14011F9A0+7B↑p
PAGE:000000014037FE50                                         ; DATA XREF: ...
PAGE:000000014037FE50
PAGE:000000014037FE50 arg_0           = byte ptr  8
PAGE:000000014037FE50
PAGE:000000014037FE50                 push    rbx
PAGE:000000014037FE52                 sub     rsp, 20h
PAGE:000000014037FE56                 and     dword ptr [rcx+8], 0
PAGE:000000014037FE5A                 cmp     dword ptr [rcx], 11Ch
PAGE:000000014037FE60                 mov     rbx, rcx
PAGE:000000014037FE63                 mov     dword ptr [rcx+4], 6
PAGE:000000014037FE6A                 mov     dword ptr [rcx+0Ch], 1772h
PAGE:000000014037FE71                 mov     dword ptr [rcx+10h], 2
PAGE:000000014037FE78                 jnz     short loc_14037FEDC
PAGE:000000014037FE7A                 movzx   eax, byte ptr cs:dword_1401FEBC0+1

ntoskrnl!RtlGetVersion - Windows 7 SP1 7601

PAGE:00000001402C6744                 public RtlGetVersion
PAGE:00000001402C6744 RtlGetVersion   proc near               ; CODE XREF: RtlVerifyVersionInfo+5E↑p
PAGE:00000001402C6744                                         ; sub_140187940+7D↑p ...
PAGE:00000001402C6744
PAGE:00000001402C6744 arg_0           = byte ptr  8
PAGE:00000001402C6744 arg_8           = qword ptr  10h
PAGE:00000001402C6744
PAGE:00000001402C6744                 mov     [rsp+arg_8], rbx
PAGE:00000001402C6749                 push    rdi
PAGE:00000001402C674A                 sub     rsp, 20h
PAGE:00000001402C674E                 cmp     dword ptr [rcx], 11Ch
PAGE:00000001402C6754                 mov     dword ptr [rcx+4], 6
PAGE:00000001402C675B                 mov     dword ptr [rcx+8], 1
PAGE:00000001402C6762                 mov     dword ptr [rcx+0Ch], 1DB1h
PAGE:00000001402C6769                 mov     dword ptr [rcx+10h], 2
PAGE:00000001402C6770                 jnz     short loc_1402C67DD
PAGE:00000001402C6772                 movzx   eax, byte ptr cs:dword_14027BC5C+1

Notice that at rcx, 11Ch goes there in both. At rcx+4, 6 goes in both. At rcx+8, Vista puts 0 and 7 puts 1. At rcx+8, Vista gets 1772h (6002) and 7 gets 1DB1h (7601). rcx+10h = 2 is presumably shorthand for the expected PlatformID (2 = Win32NT).

XP x64 is very similar, but the location of MajorVersion/MinorVersion is somewhere completely different on 32bit NT 5.x (though someone else found it).

So this would probably affect what ntdll/ntext!RtlGetVersion and its offshoots call for OS versions and build numbers without affecting functionality, and render my internal CurrentVersion registry patch obsolete. But I still need to make the process of using a custom ntoskrnl as simple on UEFI as it is with a BIOS. :dubbio:

Edited by win32
Link to comment
Share on other sites

17 minutes ago, win32 said:

There are a few places where binaries have been released publicly, but they are probably very outdated, and it will probably never be posted directly on here due to file redistribution policies. Only the ntext files can be posted directly because I compiled them and not MS.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

So for those who want to know more about RtlGetVersion, which is the "root" function for other functions like RtlVerifyVersionInfo, VerifyVersionInfoW, etc.

I found that:

r9+118h equals MajorVersion

r9+120h equals BuildNumber (little endian of course)

Those are easy to modify by making the mov eax, [r9 + xxh] into mov eax, 5 or something similar. But r9+11Ch seems to be what I think it is, and r9+124h and r9+2F0h are problematic when changed. PlatformId is not something I want to change, and I think applications will be satisfied with SP2, but where exactly is MinorVersion? I suspect r9+124h but

So what should be done? Changing MajorVersion to 10 is not a good idea, as many browsers fail if compatibility shimmed to 6.2 and above. And Windows 10 tells legacy software that it's NT 6.2 anyway.

And also, changing values grabbed from memory to fixed ones can also depreciate the value of Windows compatibility mode, since they rely on RtlGetVersion to get the changed version numbers.

Things may be easier on the kernelmode side anyway. I think I just answered the question I asked some time ago:

ntoskrnl!RtlGetVersion - Vista SP2 6002


                        public RtlGetVersion
PAGE:000000014037FE50 RtlGetVersion   proc near               ; CODE XREF: RtlVerifyVersionInfo+65↑p
PAGE:000000014037FE50                                         ; sub_14011F9A0+7B↑p
PAGE:000000014037FE50                                         ; DATA XREF: ...
PAGE:000000014037FE50
PAGE:000000014037FE50 arg_0           = byte ptr  8
PAGE:000000014037FE50
PAGE:000000014037FE50                 push    rbx
PAGE:000000014037FE52                 sub     rsp, 20h
PAGE:000000014037FE56                 and     dword ptr [rcx+8], 0
PAGE:000000014037FE5A                 cmp     dword ptr [rcx], 11Ch
PAGE:000000014037FE60                 mov     rbx, rcx
PAGE:000000014037FE63                 mov     dword ptr [rcx+4], 6
PAGE:000000014037FE6A                 mov     dword ptr [rcx+0Ch], 1772h
PAGE:000000014037FE71                 mov     dword ptr [rcx+10h], 2
PAGE:000000014037FE78                 jnz     short loc_14037FEDC
PAGE:000000014037FE7A                 movzx   eax, byte ptr cs:dword_1401FEBC0+1

ntoskrnl!RtlGetVersion - Windows 7 SP1 7601


PAGE:00000001402C6744                 public RtlGetVersion
PAGE:00000001402C6744 RtlGetVersion   proc near               ; CODE XREF: RtlVerifyVersionInfo+5E↑p
PAGE:00000001402C6744                                         ; sub_140187940+7D↑p ...
PAGE:00000001402C6744
PAGE:00000001402C6744 arg_0           = byte ptr  8
PAGE:00000001402C6744 arg_8           = qword ptr  10h
PAGE:00000001402C6744
PAGE:00000001402C6744                 mov     [rsp+arg_8], rbx
PAGE:00000001402C6749                 push    rdi
PAGE:00000001402C674A                 sub     rsp, 20h
PAGE:00000001402C674E                 cmp     dword ptr [rcx], 11Ch
PAGE:00000001402C6754                 mov     dword ptr [rcx+4], 6
PAGE:00000001402C675B                 mov     dword ptr [rcx+8], 1
PAGE:00000001402C6762                 mov     dword ptr [rcx+0Ch], 1DB1h
PAGE:00000001402C6769                 mov     dword ptr [rcx+10h], 2
PAGE:00000001402C6770                 jnz     short loc_1402C67DD
PAGE:00000001402C6772                 movzx   eax, byte ptr cs:dword_14027BC5C+1

Notice that at rcx, 11Ch goes there in both. At rcx+4, 6 goes in both. At rcx+8, Vista puts 0 and 7 puts 1. At rcx+8, Vista gets 1772h (6002) and 7 gets 1DB1h (7601). rcx+10h = 2 is presumably shorthand for the expected PlatformID (2 = Win32NT).

XP x64 is very similar, but the location of MajorVersion/MinorVersion is somewhere completely different on 32bit NT 5.x (though someone else found it).

So this would probably affect what ntdll/ntext!RtlGetVersion and its offshoots call for OS versions and build numbers without affecting functionality, and render my internal CurrentVersion registry patch obsolete. But I still need to make the process of using a custom ntoskrnl as simple on UEFI as it is with a BIOS. :dubbio:

In the end, will we still have to change the minor verisons of some programs from 1 to 0 to get them to run on Vista?

Link to comment
Share on other sites

6 minutes ago, asdf2345 said:

In the end, will we still have to change the minor verisons of some programs from 1 to 0 to get them to run on Vista?

Nope, because Vista will be NT 6.1. I'd be flabbergasted if minorversion didn't change after this modification.

Anyway, kernel32 can be modified to lift that requirement as well if this doesn't work.

Edited by win32
Link to comment
Share on other sites

On 10/6/2020 at 7:35 AM, win32 said:

Take a screenshot of the error dialog and post it here. Then I'll know what to do (hopefully). Is the game 32 or 64 bit?

 

I have now built a functional 32bit wrapper for ntdll, and it is being used by my kernel32 right now. So the focus will be on 32bit usermode improvements for the next while.

So the functions to be upgraded to Windows 7 specifications:

NtQueryInformationProcess

NtQuerySystemInformation

and probably more...

And now I want to deal with RtlGetVersion. I think I'm close to figuring it out.


.text:0000000078E9BD76                 mov     eax, [r9+118h]
.text:0000000078E9BD7D                 mov     [rcx+4], eax
.text:0000000078E9BD80                 mov     eax, [r9+11Ch]
.text:0000000078E9BD87                 mov     [rcx+8], eax
.text:0000000078E9BD8A                 movzx   eax, word ptr [r9+120h]
.text:0000000078E9BD92                 mov     [rcx+0Ch], eax
.text:0000000078E9BD95                 mov     eax, [r9+124h]
.text:0000000078E9BD9C                 mov     [rcx+10h], eax
.text:0000000078E9BD9F                 mov     r8, [r9+2F0h]

I think the r9+xxh indicates the ULONG values in the OSVERSIONINFOEXW structure. I believe that the r9+11Ch would indicate OSVersionInfoSize, whereas the other four pertain to MajorVersion, MinorVersion, BuildNumber and PlatformId. I just need to find a lightweight application with a OSVERSIONINFO(EX)W structure and set up a breakpoint in there and hopefully I'll know which is which.

Can't take a screenshot of the entire "View details" thing but I can copy every single information in there:

"

Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    payday2_win32_release.exe
  Application Version:    0.0.0.0
  Application Timestamp:    5f367968
  Fault Module Name:    kernel32.dll
  Fault Module Version:    6.0.6002.19623
  Fault Module Timestamp:    5f11ff53
  Exception Code:    c0000005
  Exception Offset:    000bff71
  OS Version:    6.0.6002.2.2.0.256.1
  Locale ID:    1033
  Additional Information 1:    3234
  Additional Information 2:    2dfcfbd32f33f3fdaa0d0937222cb9c3
  Additional Information 3:    3234
  Additional Information 4:    2dfcfbd32f33f3fdaa0d0937222cb9c3"

Hope this helps

Screenshot_1.png

Link to comment
Share on other sites

13 hours ago, C9_Slips said:

Can't take a screenshot of the entire "View details" thing but I can copy every single information in there:

That is a very weird place for a crash. It's right in the middle of an offset to a registry entry \Registry\Machine\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers (nothing seems to refer to it)! Unless it's 32bit, then it's at the beginning of the export table entry for the function MapViewOfFileExNuma. :blink:

And in other news, so far the version changing initiative has crashed and burned. While the browsers are in better shape with the OS identifying as NT 10.0 than before, I still can't get MinorVersion changed whatsoever! Qt 5.10+ still manages to bypass ntext to call RtlGetVersion from ntdll! :realmad:

Major changes to RtlGetVersion in ntoskrnl but no effect on the user-mode version checking components. Some testing is needed with the considerably different XP x64 and W7 versions of RtlGetVersion to see if there are effects on those OSes and if so, I will look into replacing the Vista version of that function with one of those.

Edited by win32
Link to comment
Share on other sites

6 hours ago, win32 said:

And in other news, so far the version changing initiative has crashed and burned. While the browsers are in better shape with the OS identifying as NT 10.0 than before, I still can't get MinorVersion changed whatsoever! Qt 5.10+ still manages to bypass ntext to call RtlGetVersion from ntdll! :realmad:

Major changes to RtlGetVersion in ntoskrnl but no effect on the user-mode version checking components. Some testing is needed with the considerably different XP x64 and W7 versions of RtlGetVersion to see if there are effects on those OSes and if so, I will look into replacing the Vista version of that function with one of those.

I think it'd be best to fake NT 6.1 or 6.3 rather than 10

Link to comment
Share on other sites

3 hours ago, asdf2345 said:

I think it'd be best to fake NT 6.1 or 6.3 rather than 10

Unfortunately that is not possible right now as it seems to be much harder to change MinorVersion than MajorVersion on Vista (wasn't NT 6.0 supposed to be followed up by NT 7.0 according to MS plans in 2006?). I'm thinking of making a code cave to another part of the file where MinorVersion gets inserted farther up the food chain and see if it changes anything. And possibly even a filename swap between ntdll and ntext to deal with problematic software like Qt 5.10+.

Though I feel that this limitation may well be applicable to Windows 7 as well, but is less of an issue since I think W7 users will only need to spoof NT 10.0 in the future.

45 minutes ago, burd said:

 any news on the LoadLibraryRewrite from XP x64? or did it just not work out.

it didn't. though it may be revisited in the future based on 6519/7000/7601 since I am now aware of workarounds to import table limitations. Though the structures that Vista LoadLibraryExW refers to are very different from the other OSes.

Edited by win32
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...