Jump to content

[WIP] Windows Vista Extended Kernel


win32

Recommended Posts

Just now, asdf2345 said:

I've gotten newer clients working without a browser, so only small mode works. Also, I only get the superior old chat UI.

the newer clients work anyways in small mode like win32 and i have already investigated , but in broken form with big picture mode or small mode the only way to use it at the bare minimum. The main task is getting everything to work , you will need a working steamhelper aswell to get it to work.

Link to comment
Share on other sites


I had done a bit of work on the x86 kernel32, by adding relocations, but I'm still getting nowhere with Advanced Chrome 74/84. I'll try adding a few more functions to kernel32 to bring it closer in line with the x64 one anyway.

And I'll revisit x86 shell32 in due time (I've found a possible working stub for SetExplicitUserModelID or whatever it's called). It's just that I've focused on win2k stuff for the past few days...

Edited by win32
Link to comment
Share on other sites

In my honest opinion, I think that you should prioritize x64 work rather than x86, as x86 is first of all, harder to get stuff working on and secondly, less people use it by a long shot.

Edited by Windows 2000
Link to comment
Share on other sites

32 minutes ago, Windows 2000 said:

In my honest opinion, I think that you should prioritize x64 work rather than x86, as x86 is first of all, harder to get stuff working on and secondly, less people use it by a long shot.

but its needed for 32bit apps to run even on 64bit systems 

Link to comment
Share on other sites

1 hour ago, Windows 2000 said:

as x86 is first of all, harder to get stuff working on and secondly, less people use it by a long shot.

... Says a WinXP x64 user :P (going by your avatar), a minority inside the community of XP users (most of which have been on x86 all along) ...

 FWIW, when Vista OEM was first released (as a successor to WinXP x86) and pre-installed in new hardware (this was my case here ;) ), it was practically always 32-bit (the lack of 64-bit Vista drivers was, of course, an issue at the time...)!

Do you actually have figures to support that "long shot" argument, or are you simply going by MSFN posters in these threads?

In any case, I am a 32-bit user myself and just being patient for @win32 to work his miracles :thumbup ; all Vista users have waited and wished for this for the last, say, four years, I think one can wait just a tad longer until something stable and functional is released in due time... :yes:

Link to comment
Share on other sites

33 minutes ago, VistaLover said:

it was practically always 32-bit (the lack of 64-bit Vista drivers was, of course, an issue at the time...)!

MS forced hardware vendors to supply x86 and x64 drivers for WHQL certification starting with Vista. But there were devices such as printers that were released only a couple of years before Vista that were challenged in the x64 driver department. And when you have 2 or 3 GB of RAM, the advantages of x64 are not as profound as they would be with loads of RAM (and even with 12 GB of RAM and a PAE-capable OS, you can still get by on x86).

As an ex-Core Duo user, that would be part and parcel of a decent configuration for Vista yet it is a 32 bit CPU.

And then there's Steam and Office 2013+ installers. They are quite popular yet they don't exist in a 64bit form.

But indeed, I've faced many challenges on x86 that haven't surfaced in x64. Indeed crashes that occur when calling NtQuerySystemInformation and NtQueryInformationProcess are a real PITA. I've just noticed that those two functions have received minor upgrades on 7 (but not on x64, which is why it works there). But ntdll is off limits due to it having a mandatory signature and signtool refuses to sign dlls (probably why no one really does deep-down modifications to 8.x and 10 since the signing requirements are very stringent, even compared to Vista/7).

So I decided to implement the Windows 7 versions as subroutines in kernel32.dll, as it is possible to successfully implement some ntdll functions in kernel32. But that just trips DEP, so that's a non-starter.

I'll have to file this one away in the "MS paranoia impedes power users" folder.

In fact, the next function I was going to implement, K32EnumProcesses also calls the functionally-deficient ntdll functions mentioned above, so it's dead in the water. :angry:

Yet again, our hopes rest with the BWC versions of those functions.

Thanks a lot, M$.

Link to comment
Share on other sites

19 minutes ago, win32 said:

But ntdll is off limits due to it having a mandatory signature and signtool refuses to sign dlls (probably why no one really does deep-down modifications to 8.x and 10 since the signing requirements are very stringent, even compared to Vista/7).

So I decided to implement the Windows 7 versions as subroutines in kernel32.dll, as it is possible to successfully implement some ntdll functions in kernel32. But that just trips DEP, so that's a non-starter.

Couldn't we just fully disable DEP, or boot in test mode?

Edited by asdf2345
Link to comment
Share on other sites

7 minutes ago, asdf2345 said:

Couldn't we just fully disable DEP, or boot in test mode?

Yes, you can. Though in this case, I've found that a DEP-related crash covers up a buffer overflow exception that would have occurred without DEP.

Link to comment
Share on other sites

1 minute ago, win32 said:

Yes, you can. Though in this case, I've found that a DEP-related crash covers up a buffer overflow exception that would have occurred without DEP.

What about trying a different dll, like shell32, or something?

Link to comment
Share on other sites

Just now, asdf2345 said:

What about trying a different dll, like shell32, or something?

For the kernel32 functions? Seems non-practical. Either you'd have to modify each program's export table to point to shell32 for those functions or (easier) add the entries to kernel32's export table but have them forward to shell32. In this case, you may as well create a completely new dll that containing nothing more than those functions.

But there are still a few things left to try to fix the functions in kernel32 and shell32.

Link to comment
Share on other sites

1 hour ago, win32 said:

(probably why no one really does deep-down modifications to 8.x and 10 since the signing requirements are very stringent, even compared to Vista/7).

So this means Windows 8.1 has no chance for extended kernel? What about porting dx12 to Windows 8.1? It always angers me when i see that new AAA games support w7/10. Why did microsoft do that :(

Link to comment
Share on other sites

2 minutes ago, Jaguarek62 said:

So this means Windows 8.1 has no chance for extended kernel?

Only with local DLL redirection, and I think they will likely be blocked because those DLLs will not have a valid signature. But again, DWM can be hooked by AeroGlass for Win8.1+...

Edited by win32
Link to comment
Share on other sites

18 hours ago, win32 said:

But indeed, I've faced many challenges on x86 that haven't surfaced in x64. Indeed crashes that occur when calling NtQuerySystemInformation and NtQueryInformationProcess are a real PITA. I've just noticed that those two functions have received minor upgrades on 7 (but not on x64, which is why it works there). But ntdll is off limits due to it having a mandatory signature and signtool refuses to sign dlls (probably why no one really does deep-down modifications to 8.x and 10 since the signing requirements are very stringent, even compared to Vista/7).

In this case, you could have a separate dll with only the new/enhanced ntdll functions and leave ntdll unmodified. (similar to One Core API's ntext.dll)

Link to comment
Share on other sites

17 minutes ago, Ximonite said:

In this case, you could have a separate dll with only the new/enhanced ntdll functions and leave ntdll unmodified. (similar to One Core API's ntext.dll)

Yes, I had considered it:

17 hours ago, win32 said:

In this case, you may as well create a completely new dll that containing nothing more than those functions.

Then, I thought: would it be impeded by the code signing requirements (which are not present on XP/2003)? But again, AeroGlass gets around them.

This seems to have some useful information:

https://www.ethicalhacker.net/columns/heffner/intercepted-windows-hacking-via-dll-redirection/

(specifically the part about building a "stub" DLL - I've got almost no C/C++ knowledge but when I do read C, it does make a good deal of sense to me)

Perhaps I would then muck around with the kernel32 import table so that it would import these functions from the ntext and hope it will work. This would also make system file replacement mandatory for 32 bit binaries.

But my plan B (which is now a plan C) was to simply replace them with BWC's implementations of K32* functions, which simply expand upon the lesser versions of those functions in psapi.dll.

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...