[WIP] Windows Vista Extended Kernel

[win32]

A very strange situation on the x86 side of things; it appears that in general for some imported ntdll functions on x86, they crash when being imported. Forward exporting functions doesn't seem to work either. But replicating the ntdll function in kernel32 works fine (in the case of RtlSetThreadErrorMode). But what about NtQueryInformationProcess and the like? You can't put stuff that interacts with ring-0 all over the place!

I'm not sure what exactly is wrong, but it may be some strange artifact of WOW64 switching/thunking. I have yet to test any kernel extensions on a pure Vista x86, but I did make an attempt at kernel extensions on XP x86 for a specific purpose and did not have issues with import calls failing much like on Vista WOW64.

With these discoveries in mind, my solution to this problem is to take one of the components of the x86 ntdll wrapper, ntnew, which was to house the code for the new x86 ntdll functions, and add the new x86 kernel32 functions to it, thus it will now be known as ntk32.dll.

This is how this wrapper will be structured:

Programs needing new ntdll functions: call ntext.dll instead, which will forward new functions to ntk32.dll.

Programs needing new kernel32 functions: call kernel32.dll, which is the existing one augmented with an expanded export table, which in turn will forward new functions to ntk32.dll.

Hopefully this should maximize portability of the x86 extended kernel components between WOW64 and pure x86 Vista. I just hope that calling the Nt/Zw* functions will be successful as that has yet to be tested and I wonder if it will be possible from ntext as opposed to ntdll. That will be a major setback if it cannot.

UPDATE: NtQueryInformationProcess called through ntnew (have yet to implement kernel32 stuff in there yet), is working.

Edited December 16, 2020 by win32

[Dixel]

12 hours ago, win32 said:

...this should maximize portability of the x86 extended kernel components between WOW64 and pure x86 Vista...

Wow ! This is just wow ! Fellow members , where are your likes !? Win32 , by pure x86 Vista you mean RTM ?

[win32]

17 minutes ago, Dixel said:

Wow ! This is just wow ! Fellow members , where are your likes !? Win32 , by pure x86 Vista you mean RTM ?

SP2 is the intended target, but it is possible that this wrapper could be adapted to RTM versions of kernel32 and ntdll.

[win32]

On 11/11/2020 at 5:15 PM, Ximonite said:

I wonder how NtQueryInformationProcess could be causing issues with shell32.SetCurrentProcessExplicitAppUserModelID, especially since the implementations I have seen don't even call NtQueryInformationProcess. Here is the one non-stub I have seen:

Now that I'm revisiting 32 bit components, I'm wondering where this came from? It's not in my One-Core-Api binaries or 7 or 8.1.

I am having serious thoughts about putting it into ntk32 to make as portable as kernel32/ntdll components, especially if somehow I have to use the 7 implementation.

ntk32 also has the advantage in that I can properly expand the import table as it's in the "right place" (bottom of reloc section - weird but it works). I found that certain functions are perfectly importable by my new functions, but others like NtQueryInformationProcess and RtlSetThreadErrorMode are not.

Edited December 17, 2020 by win32

[Ximonite]

5 hours ago, win32 said:

Now that I'm revisiting 32 bit components, I'm wondering where this came from? It's not in my One-Core-Api binaries or 7 or 8.1.

It's from BlackWingCat's extended kernel, but it calls ole32.CoTaskMemAlloc directly instead of calling a function that calls it with LoadLibraryA and GetProcAddress.

Also, here's the matching implementation of GetCurrentProcessExplicitAppUserModelID:

mov     edx, [esp+AppID]
test    edx, edx
jz      short loc1
mov     eax, lpString
test    eax, eax
jz      short loc_7D04A866
push    eax             ; lpString
call    ds:lstrlenW
inc     eax
add     eax, eax
push    eax
call    ds:CoTaskMemAlloc
mov     [edx], eax
mov     eax, lpString
push    eax             ; lpString2
push    dword ptr [edx] ; lpString1
call    ds:lstrcpyW
xor     eax, eax
retn    4
loc1:
mov     eax, 80004005h
retn    4

GetCurrentProcessExplicitAppUserModelID.hex

[win32]

46 minutes ago, Ximonite said:

It's from BlackWingCat's extended kernel, but it calls ole32.CoTaskMemAlloc directly instead of calling a function that calls it with LoadLibraryA and GetProcAddress.

Also, here's the matching implementation of GetCurrentProcessExplicitAppUserModelID:

Thanks Ximonite.

With this all taken into account I've finalized my plans for shell32 x86. Those functions are much simpler than what I had been originally looking at. Then there is SHGetPropertyStoreForWindow, which doesn't exist in BWC's kernel but does on 7; that seems quite simple, and I think it could be used on 2000 if the __security_cookie stuff is cut out of the start and end (unless you want to start using it).

I will be putting this into its own wrapper (shellnew.dll) instead of stuffing into ntk32 as I briefly wanted to do.

Have these functions even been tested on 2000? Looks like Vista will be the proving grounds to determine their capability as lots of modern applications call them.

Shell_NotifyIconGetRect will be redirected to Shell_NotifyIconW and SHAssocEnumHandlersForProtocolByApplication will be redirected to SHAssocEnumHandlers as that satisfies Opera on x64.

[Dixel]

Someone claims to have  "a new kernel For Vista" . Beware , an advanced English ahead .

https://steamcommunity.com/app/498240/discussions/0/143388132201481545/

[asdf2345]

6 hours ago, Dixel said:

Someone claims to have  "a new kernel For Vista" . Beware , an advanced English ahead .

https://steamcommunity.com/app/498240/discussions/0/143388132201481545/

Who and where did you get the idea from?

[win32]

1 hour ago, asdf2345 said:

Who and where did you get the idea from?

Quote

This link will be of all my vista assets that includes a new kernel For Vista Users.

That is my kernel with no changes whatsoever!

And also, I am testing my shellnew.dll wrapper. Calls to SetCurrentProcessExplicitAppUserModelID are succeeding. The other four I have yet to test due to the lack of maturity of ntk32, but I noticed a substantial side effect of decoupling the wrapper from shell32, in that the functions called by these functions are quite old.

This means that the shellnew wrapper can be used on every Windows NT version dating back to Windows NT 4.0, and possibly all of Windows 9x, provided the functions are added to the shell32 export table and forward to shellnew. Shell_NotifyIconGetRect can be redirected as well on those OSes, and possibly NT 3.51 with NewShell, while the redirect to SHAssocEnumHandlers is not possible on anything below Vista as that function appeared with Vista.

Edited December 18, 2020 by win32

[Dixel]

8 hours ago, asdf2345 said:

Who and where did you get the idea from?

Strange question . Did you actually read the page ? How am I supposed to know "who" he (or she) is ? I just found that page when I was looking for Intel Haswell HD Graphics drivers , by pure accident . And that person claims to have made them too , in addition to the "new kernel" , funny , huh ? ..... noooot .

Actually it is stealing . Don't you wanna do something about it ? Oh , sorry , they "didn't kill you dog or smth" . Relax, I'm just joking.

But I really think something needs to be done. @win32 and what do you think ?

[asdf2345]

7 minutes ago, Dixel said:

Strange question . Did you actually read the page ?

Yes, I've read it multiple times before.

Hint: I'm Blanc

[Dixel]

3 hours ago, asdf2345 said:

Yes, I've read it multiple times before.

Hint: I'm Blanc

Before ?! Then why didn't you tell us here ? I thought I was the first to discover. That person had written "This link will be of all my vista assets that includes a new kernel For Vista Users" . "my" .

[asdf2345]

5 minutes ago, Dixel said:

Before ?! Then why didn't you tell us here ? I thought I was the first to discover. That person had written "This link will be of all my vista assets that includes a new kernel For Vista Users" . "my" .

I see it as a mirror, and I doubt that many people would even see that page, so I don't really care.

Also, keeping the vast amount of info it had available was worth not telling anyone.

[Dixel]

3 hours ago, asdf2345 said:

I see it as a mirror, and I doubt that many people would even see that page, so I don't really care.

Also, keeping the vast amount of info it had available was worth not telling anyone.

I'm not sure what "vast amount of info" you mean , win32 has confirmed that the kernel belongs to him , and I confirm that the drivers are fake , I tested them myself . He didn't do anything himself , except for tonns of misspellings. 

[asdf2345]

2 minutes ago, Dixel said:

I'm not sure what "vast amount of info" you mean , win32 has confirmed that the kernel belongs to him , and I confirm that the drivers are fake , I tested them myself . He didn't do anything himself , except for tonns of misspellings. 

The reuploaded folder is missing a bunch of the old drivers and programs