Jump to content

[WIP] Windows Vista Extended Kernel


win32

Recommended Posts

Many things were tried today.

Attempts to expand the import table to accommodate ntext.dll would require all import calls to be refactored. In almost all 1250 functions.

Tried implementing BWC's version of one K32* function (which doesn't directly refer to any import calls). That tripped ntdll in part of a function (LdrLoadAlternateResourceModule) responsible for MUI support.

I even tried forwarding some K32* functions to their predecessors in psapi.dll, which is what ExtendedXP/One-Core-API do. Result: same as above. :no:

The overly simplified Windows 8.1 version of the function? BEX.

There is one thing left, which is to call ntext and its functions as offsets with the W7 versions of the functions. If it doesn't work, then this part of the project is on hold until I can think of another way to workaround these difficult limitations. Or I'll just hang around other OSes that aren't crippled to the casual modder like Windows 2000 or XP x64.

Link to comment
Share on other sites


3 hours ago, win32 said:

Many things were tried today.

Attempts to expand the import table to accommodate ntext.dll would require all import calls to be refactored. In almost all 1250 functions.

Tried implementing BWC's version of one K32* function (which doesn't directly refer to any import calls). That tripped ntdll in part of a function (LdrLoadAlternateResourceModule) responsible for MUI support.

I even tried forwarding some K32* functions to their predecessors in psapi.dll, which is what ExtendedXP/One-Core-API do. Result: same as above. :no:

The overly simplified Windows 8.1 version of the function? BEX.

There is one thing left, which is to call ntext and its functions as offsets with the W7 versions of the functions. If it doesn't work, then this part of the project is on hold until I can think of another way to workaround these difficult limitations. Or I'll just hang around other OSes that aren't crippled to the casual modder like Windows 2000 or XP x64.

If you can't find a way, you could take a look at modding Steam to think Vista is Windows 7 x64, like think it so much that the 7 x64 CEF is used, no Vista end of support banner, and it shows Windows 7 in system information.

You could also try getting Haswell/Ryzen working stabily on Vista. That'd probably require modding ntdll or ntoskrnl, but if you can find a way to fully disable signature enforcement, or add a fake signature, it'd be great, and help with extending the kernel.

Link to comment
Share on other sites

25 minutes ago, asdf2345 said:

If you can't find a way, you could take a look at modding Steam to think Vista is Windows 7 x64, like think it so much that the 7 x64 CEF is used, no Vista end of support banner, and it shows Windows 7 in system information.

Well, I think that once the version numbers exposed in ntoskrnl.exe and HKLM\Software\Microsoft\Windows NT\CurrentVersion (including the one under Wow6432Node) are changed to 6.1, it will probably do so, at the risk of breaking other stuff.

25 minutes ago, asdf2345 said:

You could also try getting Haswell/Ryzen working stabily on Vista. That'd probably require modding ntdll or ntoskrnl, but if you can find a way to fully disable signature enforcement, or add a fake signature, it'd be great, and help with extending the kernel.

For Haswell+, that is the intention of the LoadLibraryExW replacement in kernel32 (the patch for a similar Windows 7 issue dealt mostly with modifying that function, so I do believe that would be the culprit). Signtool from the Windows 7 DDK won't sign dlls in my experience, but no doubt it will sign an executable like ntoskrnl, which would allow it to boot with driver signature enforcement disabled.

But again, I may as well "crack" ntoskrnl to disable signing enforcement completely (and then fix Ryzen), which would open up ntdll and make things much easier for everyone. I just need to figure out how to do that.

Link to comment
Share on other sites

14 minutes ago, win32 said:

Well, I think that once the version numbers exposed in ntoskrnl.exe and HKLM\Software\Microsoft\Windows NT\CurrentVersion (including the one under Wow6432Node) are changed to 6.1, it will probably do so, at the risk of breaking other stuff.

For Haswell+, that is the intention of the LoadLibraryExW replacement in kernel32 (the patch for a similar Windows 7 issue dealt mostly with modifying that function, so I do believe that would be the culprit). Signtool from the Windows 7 DDK won't sign dlls in my experience, but no doubt it will sign an executable like ntoskrnl, which would allow it to boot with driver signature enforcement disabled.

But again, I may as well "crack" ntoskrnl to disable signing enforcement completely (and then fix Ryzen), which would open up ntdll and make things much easier for everyone. I just need to figure out how to do that.

Don't want to modify registry, would prefer tricking the .exe with hex mods and such.

Also, could you link me the Haswell+ Windows 7 patch?

Edit: Also, do you know when you fixed those issues? You made it sound like you fixed them, but my Haswell laptop with Vista is still quite f***y with the extended kernel,

Edited by asdf2345
Link to comment
Share on other sites

3 minutes ago, asdf2345 said:

Edit: Also, do you know when you fixed those issues? You made it sound like you fixed them, but my Haswell laptop with Vista is still quite f***y with the extended kernel,

oh, I haven't finished it yet (about ~95% done - and when I had access to the test machine I had many other things to deal with, which is why progress has been slow lately). And I'm first doing it with a base SP2 file because my test machine has serious problems with Windows Update that cause updates to fail most of the time. If it works there, then I'll adapt it to the extended kernel's kernel32.

7 minutes ago, asdf2345 said:

Also, could you link me the Haswell+ Windows 7 patch?

I only have a few select files. @burd has the entire patch though.

Link to comment
Share on other sites

9 minutes ago, gerona12 said:

I modified the MS Office 2013-16 installer and slipped the kernel32 / ntdll.dll from Windows 7. But it fails ......... How to install MS Office 2016 in Vista?

The installer will not be able to run until I open up ntdll as mentioned above or I am successful in using offsets to a ntext.dll for the new kernel32 functions.

Your only option right now is to install it on a newer OS, then copy over all files (not just in Office folder, but also in Program Files\Common Files\Microsoft (may be Microsoft Shared or Microsoft Office, not sure) as well as all reg entries created including those for services.

Link to comment
Share on other sites

9 minutes ago, win32 said:

The installer will not be able to run until I open up ntdll as mentioned above or I am successful in using offsets to a ntext.dll for the new kernel32 functions.

Your only option right now is to install it on a newer OS, then copy over all files (not just in Office folder, but also in Program Files\Common Files\Microsoft (may be Microsoft Shared or Microsoft Office, not sure) as well as all reg entries created including those for services.

I already think about it. I'll try it today.

Link to comment
Share on other sites

It seems like this could help achieve my newest goal: https://github.com/Mattiwatti/EfiGuard

This disables PatchGuard and Driver Signing Enforcement, but only with UEFI. And apparently W7 can run with Secure Boot on with this applied (possibly Vista as well?).

But, what about us Tandy 1000 users with our obsolete BIOS and MBR (oh, and don't forget Tandy graphics. Aero looks exceptionally awesome with those)? This guide to patching should suffice: http://web.archive.org/web/20170812173323/fyyre.ru/vault/bootloader.txt

Well, I think I saved myself a lot of time searching through ntoskrnl in IDA and seriously advanced the cause of Windows Vista. Great thanks to those who also want to control the OS, as opposed to having the OS control you. :thumbup

Edited by win32
Link to comment
Share on other sites

31 minutes ago, win32 said:

It seems like this could help achieve my newest goal: https://github.com/Mattiwatti/EfiGuard

This disables PatchGuard and Driver Signing Enforcement, but only with UEFI. And apparently W7 can run with Secure Boot on with this applied (possibly Vista as well?).

But, what about us Tandy 1000 users with our obsolete BIOS and MBR (oh, and don't forget Tandy graphics. Aero looks exceptionally awesome with those)? This guide to patching should suffice: http://web.archive.org/web/20170812173323/fyyre.ru/vault/bootloader.txt

Well, I think I saved myself a lot of time searching through ntoskrnl in IDA and seriously advanced the cause of Windows Vista. Great thanks to those who also want to control the OS, as opposed to having the OS control you. :thumbup

I don't want to have to reinstall every single OS on my computers just to use UEFI mode.

Edit; I was looking through these, and I'm curious as to if you're supposed to modify winload for us, or are we supposed to modify winload ourselves?

I don't really understand what tools are used in the second guide, and how exactly I'm supposed to fix this, but if it works on both UEFI and MBR, so I'm going to say it's superior.

Edited by asdf2345
Link to comment
Share on other sites

28 minutes ago, asdf2345 said:

 

I don't really understand what tools are used in the second guide, and how exactly I'm supposed to fix this, but if it works on both UEFI and MBR, so I'm going to say it's superior.

I will supply the modified winload/ntoskrnl. Perhaps even make a script to make/modify the boot manager entry. The second guide is intended for BIOS/MBR.

Link to comment
Share on other sites

1 minute ago, win32 said:

I will supply the modified winload/ntoskrnl. Perhaps even make a script to make/modify the boot manager entry. The second guide is intended for BIOS/MBR.

A quote from the second quide

"This could be worked into mbr bootkit code as well... this is beyond the scope of our intention."

Makes me believe they did it with Windows installed in UEFI mode

Edited by asdf2345
Link to comment
Share on other sites

7 minutes ago, asdf2345 said:

"This could be worked into mbr bootkit code as well... this is beyond the scope of our intention."

Makes me believe they did it with Windows installed in UEFI mode

I think they mean that they could patch the files on-demand at boot as opposed to modifying the files themselves. I think there are ACPI patchers for XP that do that.

And winload.exe, which is explicitly mentioned as such in the tutorial, is not used on UEFI. winload.efi is used instead.

Link to comment
Share on other sites

Just now, win32 said:

I think they mean that they could patch the files on-demand at boot as opposed to modifying the files themselves. I think there are ACPI patchers for XP that do that.

And winload.exe, which is explicitly mentioned as such in the tutorial, is not used on UEFI. winload.efi is used instead.

Oh, ok. I've not have much experience with UEFI Windows. After literally everything broke on my 7 UEFI install, and I realized XP couldn't use UEFI, I just stuck with legacy boot.

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