Jump to content

[WIP] Windows Vista Extended Kernel


win32

Recommended Posts

48 minutes ago, win32 said:

We are only two functions away from getting GIMP 2.10.18 to possibly work - SetThreadErrorMode and K32GetModuleFileNameExA. So the first test of the extended kernel will be very soon. If anyone can find other x64 programs that were only prevented from running on Vista by the lack of the functions that have been implemented already, that would also be good.

im looking to find such a program , i found autodesk had an issue with the functions added back in 2014 but i doubt its worthwhile to try it now.

 

EDIT:- Tried Epicgameslauncher , it should throw up errors of missing functions, the ones added in the extended one but it doesnt and only gives a SetThreadErrorMode error

Edited by burd
Link to comment
Share on other sites


So I added those two functions and tried launching GIMP 2.10.18. However, even after getting over the hurdle represented by those two functions, there was another missing one in shell32.dll, SetCurrentProcessExplicitAppUserModelID. And it looks like it's an important one too:

https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-setcurrentprocessexplicitappusermodelid

Quote

Specifies a unique application-defined Application User Model ID (AppUserModelID) that identifies the current process to the taskbar. This identifier allows an application to group its associated processes and windows under a single taskbar button.

This method must be called during an application's initial startup routine before the application presents any UI or makes any manipulation of its Jump Lists. This includes any call to SHAddToRecentDocs.

Once it tried calling that one, it suddenly went crazy and crashed. Now I'm wondering if it would be better to have it forward to an API function representing XP/Vista-style taskbar grouping or keep it the way it is.

But again, I'd like to focus on taking care of kernel32.dll and functions forwarded from it to ntdll.dll before the lower level dlls, as well as also making updates to the 32bit versions.
Anyway, the code for these two new functions is available here:

SetThreadErrorMode: 48 FF 25 D9 DC 05 00 CC
K32GetModuleFileNameExA: 48 FF 25 49 2D 04 00 CC

UPDATE: GIMP 2.10.0 is working, but it doesn't seem to use any of my functions. But it's still higher than the 2.8.22 that's listed in the last versions of software thread.

Edited by win32
Link to comment
Share on other sites

58 minutes ago, win32 said:

 


SetThreadErrorMode: 48 FF 25 D9 DC 05 00 CC
K32GetModuleFileNameExA: 48 FF 25 49 2D 04 00 CC

 

should i add these below the others in .xdata.?

Link to comment
Share on other sites

So the problem is at 00128E30, so it's still my code, or more specifically K32GetProcessMemoryInfo.

And in the process I've discovered a serious problem. Windows 7 x64 code that looks like this:

1408330636_whatitshouldbe.png.a7cc1b1d670d02ab727baf099f1b3277.png

Looks like this when placed in a Vista x64 binary:

wtf.png.12cc15d57b986081f12b1ef27df63278.png
I don't have this problem with x86 binaries.

This means that the functions that have been implemented are glorified stubs. They may still be useful in certain cases. I do plan on making a proper x86 kernel extension, as there are still many x86 applications around today. And hopefully I can eventually get over this setback and return to extending Vista x64.

UPDATE: This just happened to me with a chunk of an x86 subroutine. It appears that I have to right-click and convert it to code (and then modify it further). I will investigate this further when I start trying to extend x64 again. And yes, the results of most of the posts of mine so far have revealed my incompetence in this arena, which is being corrected as I type.

Edited by win32
Link to comment
Share on other sites

So here is the first part of the Windows Vista x86 kernel extension tutorial. More functions are to come.

Since the code will be much longer than before, we will use HxD along with CFF Explorer and PEMaker v0.82 to speed up the process.

Take the kernel32.dll from your X:\Windows\System32 folder (on x86 systems) or X:\Windows\SysWOW64 (on x64 systems) and copy it somewhere else. Open that copy of kernel32.dll in CFF Explorer and click "Section Headers [x]" on the left sidebar. Right-click on the table of sections and click the option to "Add Section (Empty Space)". Set the size to 0000B100, then name the new section .xdata. Set the characteristics to 60000020. Close CFF Explorer and open the file in PEMaker.

Head to the "Export TBL" tab. click the lower Load button and watch the export table populate. Change "Table Address" to 000D2600 (or whatever value you get for "RawPointer" of .xdata in the "Section" tab preceded by three zeros) and then click the lower Save button. Go to the "Main" tab and "Check" "SizeofCode", before saving your kernel32.dll itself.

Open the file in HxD.

While in HxD, copy the code below into your file by right-clicking in the new section below the export table (which will correspond to 000DC000 or so, in order to give the export table some wiggle room) and then clicking the "Paste write" option.

8B FF 55 8B EC 5D FF 25 D4 15 88 6B

This code represents K32GetProcessMemoryInfo, taken from the Windows 2000 extended kernel. I tried with Server 2019 initially, but found out that the kernel structure is very different from Vista, where the bulk of the code is not contained in kernel32 itself, rather it being in One-Core API dlls (not to be confused with XP extended kernel, this is of MS' doing). Even with Windows 7, which still had complete code for the functions in kernel32, things didn't work out.

Reopen PEMaker, go to the "Export TBL" tab and load it, then enter the offset corresponding to the start of your function (which again will correspond to 000DC000 or so) in the third box from the left, and then the function name K32GetProcessMemoryInfo in the far-left box. The rest will be done for you. First save the export table, then save the file.

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.

WARNING

At present, this file seems to have issues with export table modification, whether it be through ExportTableTester or PEMaker, regardless of which action is taken with the export table (moving it, keeping the existing one and simply adding functions to it, or creating a second one with the new function). It doesn't seem to work properly and throws an error about being "not designed to run on Windows". It appears that somehow, the import, resource and relocation tables have been corrupted. A very tricky process indeed, which deviates greatly from the process for x64 libraries.

UPDATE: by simply adding the function in PEMaker and not selecting the option to align the import table yet correcting file and code size, I have managed to only corrupt the import table, which is still very sad.

What a comedy of errors this has been. :crazy:

SECOND UPDATE: it was just me again failing to realize that the export table was overwriting the beginning of the import table. I used PEMaker to move the import table address from 000C281C to 000C286C and now things are cool. I know that many of you are probably wishing that they could get binaries given the complexity... but now things are back on track using v0.82 of this tool from the great BWC: http://blog.livedoor.jp/blackwingcat/archives/1313117.html

with this in mind, another revision to the instructions is incoming, involving a way to non-destructively move the export table to avoid destroying anything else. In hindsight, the decision to have these extensions alongside system files instead of replacing them was great.

Edited by win32
More stable functions
Link to comment
Share on other sites

9 minutes ago, win32 said:

So here is the first part of the Windows Vista x86 kernel extension tutorial. More functions are to come.

Since the code will be much longer than before, we will use HxD along with CFF Explorer and ExportTableTester to speed up the process.

Take the kernel32.dll from your X:\Windows\System32 folder (on x86 systems) or X:\Windows\SysWOW64 (on x64 systems) and copy it somewhere else. Open that copy of kernel32.dll in CFF Explorer and click "Section Headers [x]" on the left sidebar. Right-click on the table of sections and click the option to "Add Section (Empty Space)". Set the size to 0000B100, then name the new section .xdata. Set the characteristics to 60000020. Close CFF Explorer and open the file in HxD.

While in HxD, copy the code below into your file by right-clicking at the beginning of your new section (which will correspond to 000D2600 or slightly below; the "Raw Address" of .xdata as given in CFF) and then clicking the "Paste write option".


8B FF 55 8B EC 83 EC 30 56 8B 75 0C 85 F6 75 19 68 0D 00 00 C0 FF 15 68 05 D7 7D 50 FF 15 AC 0D D7 7D 33 C0 E9 8F 00 00 00 83 7D 10 28 73 04 6A 7A EB E9 83 7D 10 2C 57 6A 00 6A 30 8D 45 D0 50 6A 03 FF 75 08 1B FF 47 FF 15 20 05 D7 7D 85 C0 7D 12 50 FF 15 68 05 D7 7D 50 FF 15 AC 0D D7 7D 33 C0 EB 53 33 C0 85 FF 0F 95 C0 8D 04 85 28 00 00 00 89 06 8B 45 D8 89 46 04 8B 45 DC 89 46 08 8B 45 E0 89 46 0C 8B 45 E4 89 46 10 8B 45 E8 89 46 14 8B 45 EC 89 46 18 8B 45 F0 89 46 1C 8B 45 F4 89 46 20 8B 45 F8 89 46 24 85 FF 74 06 8B 45 FC 89 46 28 33 C0 40 5F 5E C9 C2 0C 00

This code represents K32GetProcessMemoryInfo, taken from Windows 7 instead of Server 2019.

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

Enter the offset corresponding to the "Virtual Address" value for .xdata in CFF Explorer, and then the function name K32GetProcessMemoryInfo 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.

Shut down Vista and boot into another OS on your PC (or a Linux Live CD/USB if you don't multiboot). Go to your X:\Windows\System32 and rename your present kernel32.dll to kernel32.old (if you're doing it from another Windows, you will probably have to take ownership of the file and adjust the permissions accordingly). Then paste in your edited kernel32.dll before booting into Vista.

Just a thought. Is it possible to fool programs to look for the modified kernel32 instead of actually modifying the system file? For example, renaming the updated file to kernel33 and changing some attributes in the executable to look for that file?

Link to comment
Share on other sites

25 minutes ago, greenhillmaniac said:

Just a thought. Is it possible to fool programs to look for the modified kernel32 instead of actually modifying the system file? For example, renaming the updated file to kernel33 and changing some attributes in the executable to look for that file?

Yes, that would definitely be possible; just change all references in the target program's import table from kernel32 to the modified kernel33. However, that may be very complex in the case of programs that have many dependencies on other files that in turn have unresolved dependencies on kernel32 (which would be resolved with a modified kernel32/kernel33).

As it appears that putting the new code/stubs in separate tables from the original MS code maintains the OS' stability, I decided that modifying system files would work best, though it will prove somewhat undesirable for those who continue to update the OS.

But I've been thinking about HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs, which seems to direct applications to system DLLs; perhaps I could have two entries for both kernel32 and kernel33 (kernel32 = kernel32.dll and kernel32 = kernel33.dll), thus rendering the reboot and replacement of system files unnecessary? But I'm booted into Windows 2000 right now, and I'm not sure if that key exists in Vista.

UPDATE: it does exist in Vista, but I had to take ownership of it to edit. I'm going to try changing the kernel32 entry to say "kernel32.dll, kernel33.dll" and see what happens.

another UPDATE: unfortunately the system and applications don't recognize the x86 kernel33.dll with the extra function.

Edited by win32
Link to comment
Share on other sites

Don't programs load DLLs that are available on the same path as the executable first? Would it be possible to put the modified kernel32 in the program folder so it could use the extra functions it needed?

EDIT: Found this interesting article: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

Edited by greenhillmaniac
Link to comment
Share on other sites

20 minutes ago, greenhillmaniac said:

Don't programs load DLLs that are available on the same path as the executable first? Would it be possible to put the modified kernel32 in the program folder so it could use the extra functions it needed?

EDIT: Found this interesting article: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

Oh yeah, I remember discussion on the use of .manifest files to redirect DLLs in XP, and I did try it a little bit in Vista where it worked, but forgot about it after it failed in 2000.

Another method of redirection is explained here: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection

So instead of replacing kernel32.dll, you can simply create yyyyy.exe.local in the same directory as yyyyy.exe and plant the custom kernel32.dll in the directory as well, avoiding the effects of monthly updates.

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