win32

I don't remember, but Edge also needs secur32 (perhaps a complete replacement of the file along with other crypto stuff since it's high-level enough?) and ntdll functions.

Yes, that is a problem that affects even the latest versions of Opera x64. I haven't added that function yet but do plan to do it in the release after next.

Then you are probably using a 32 bit version of Opera. The latest 64 bit version still needs one or two more functions anyway.

woah, that is simple compared to this one from 7 SP1 which does call NtQueryInformationProcess: .text:7390C954 SetCurrentProcessExplicitAppUserModelID proc near .text:7390C954 ; DATA XREF: .text:off_738B57E0↑o .text:7390C954 .text:7390C954 var_20 = byte ptr -20h .text:7390C954 var_1C = dword ptr -1Ch .text:7390C954 var_8 = dword ptr -8 .text:7390C954 var_4 = dword ptr -4 .text:7390C954 arg_0 = dword ptr 8 .text:7390C954 .text:7390C954 ; FUNCTION CHUNK AT .text:739B746A SIZE 0000002A BYTES .text:7390C954 .text:7390C954 mov edi, edi .text:7390C956 push ebp .text:7390C957 mov ebp, esp .text:7390C959 sub esp, 20h .text:7390C95C mov eax, ___security_cookie .text:7390C961 xor eax, ebp .text:7390C963 mov [ebp+var_4], eax .text:7390C966 mov eax, [ebp+arg_0] .text:7390C969 mov [ebp+var_8], eax .text:7390C96C lea edx, [eax+2] .text:7390C96F .text:7390C96F loc_7390C96F: ; CODE XREF: SetCurrentProcessExplicitAppUserModelID+23↓j .text:7390C96F mov cx, [eax] .text:7390C972 inc eax .text:7390C973 inc eax .text:7390C974 test cx, cx .text:7390C977 jnz short loc_7390C96F .text:7390C979 sub eax, edx .text:7390C97B sar eax, 1 .text:7390C97D push esi .text:7390C97E cmp eax, 80h .text:7390C983 sbb esi, esi .text:7390C985 and esi, 7FF8FFA9h .text:7390C98B add esi, 80070057h .text:7390C991 js loc_7390CA1E .text:7390C997 push 0 .text:7390C999 push 18h .text:7390C99B lea eax, [ebp+var_20] .text:7390C99E push eax .text:7390C99F push 0 .text:7390C9A1 call ds:GetCurrentProcess .text:7390C9A7 push eax .text:7390C9A8 call ds:NtQueryInformationProcess [...] I do remember trying a different implementation from BWC, but got a BEX. There is also the option of getting the subfunctions from kernel32 functions (like NtQueryInformationProcess.ProcessBasicInformation can be replaced by calls to CheckRemoteDebuggerPresent and GetProcessId). If a solution can be found for this problem, many compatibility problems from NT 5.0 to 6.0 x86 would be eliminated.

psapi.GetPerformanceInfo works when a program calls GetPerformanceInfo, obviously. Problems only arise when K32GetPerformanceInfo is brought into the equation. And I also neglected to mention that NtQueryInformationProcess also causes crashes in shell32.SetCurrentProcessExplicitAppUserModelID (from Windows 7) on Vista x86, in addition to K32GetProcessMemoryInfo so I don't think that our K32* implementations are bad. Those subparameters don't seem to further the understanding of the situation, considering that they have been around since NT 3.x. But I'm not sure about v14 and v21 for &SystemInformation. Perhaps it should be compared with the original GetPerformanceInfo from Vista. Then for NtQueryInformationProcess, we should compare K32GetProcessMemoryInfo, psapi.GetProcessMemoryInfo and SetCurrentProcessExplicitAppUserModelID. If only my development environment wasn't so fragmented to have equal access to tools at all locations... A newer version of gdiplus, as a higher-level DLL, can easily be dropped in. That is true for the Windows 7 versions on Vista x64, which will be needed for the latest versions of paint.net.

That's byte-for-byte equivalent to Vista's psapi.GetPerformanceInfo. I tried making K32GetPerformanceInfo (and some other K32 functions) redirect to their PSAPI_VERSION_1 equivalents. The only difference was Advanced Chrome 84 crashing silently instead of the dispatching of a crash dialog. 8.1's (K32)GetPerformanceInfo is a little different (and is self-contained), but I remember that no matter what implementation it was, the problem was NtQuerySystemInformation/NtQueryInformationProcess/etc. Those may return more subparameters in 7 x86 than in Vista x86, which may be where the problem lies. No. I chose 2017 as it predates a major performance drop in Windows binaries and Spectre/Meltdown mitigations. It would also be a lot of work refactoring everything. I thought about putting the new functions in wrappers linking back to the extant kernel32, and maybe trying some stuff with knowndlls to somehow make the redirection seamless like it is for custom ntoskrnls with different names, but shared data structures and subroutines would be a problem. And while I'm at it, there is going to be an installer, using a batch script. Admin privileges required. It renames the files in use, copies the new ones, and requires a reboot. I am also going to self-sign the files to satisfy the VirtualBox hardening requirements (you may have to do the same thing if you want to run 4.2.xx/4.3xx+ on Windows 2000).

Yes, I was planning on adding it in the next update beforehand, as it's the only outstanding function for Office 2019 x64 setup. Then there's RtlGetVersion that can spoof NT 10.0 (installers for recent MS software generally don't like running in compatibility mode/Application Verifier), and we should be set. x86 things are probably harder than that because of some K32* functions not working as well as they should. Your K32GetPerformanceInfo implementation seems similar to mine (and Windows 7's, which is a rearranged version of Vista's psapi.GetPerformanceInfo), so once we get the opportunity to test it, I wonder if it will work or it will fail in the same places as mine did (calls to NtQueryInformationProcess and similar functions). Then it will prove that those ntoskrnl functions are the problem on everything below Windows 7.

I believe that x64 binaries have been available for Office since 2010. If he were trying to run the x86 version, then it would have been asking for a lot more than SetWaitableTimerEx in kernel32.

5.0.5 is the current version, and it continues to work on vanilla Vista and XP.

Yes, they implemented these checks around the time of 4.3.x.

On Server 2003, they were moved to somewhere else in .text, decoupled from KiServiceTable, so I'd think those would be movable in 2000 as well. Also doesn't seem like a pain to refactor either, so you're lucky.

How important/easily refactorable is the code immediately below the current end to the KiServiceTable? IDA spazzes out on my copies of win2k's ntoskrnl, but right below it on my win2k3 version is a snippet that does get lots of calls to it though. win32k in Vista seems to have a function that declares the end of its service table. But there isn't one on 2000 ntoskrnl so I think you can just move code around and add stuff to the table without harm (actually that link shows there is a ServiceLimit, but I think it would be easy to change and is not its own function seemingly). Alternatively, you could change the offset that is used by KiServiceTable and recreate it somewhere else where it isn't bound by code. But it would be a painstaking process. If you can simply move (in the assembly sense of the term, since it's a copy as opposed to a proper move - why is it mov and not cpy?) around an export table while leaving it intact, perhaps someone could write a program that can move a service/dispatch table. this is what I'll probably read at next breakfast: https://resources.infosecinstitute.com/topic/hooking-system-service-dispatch-table-ssdt/

I don't think much can be done from outside safe mode other than a reinstall.

You should have installed KB2817183 and KB951748 before the extended kernel.

I'm not as upset about the situation as I was earlier. I recognize the need to prevent exploits through usermode dlls that interface with ring 0, especially in such mission-critical software like a hypervisor. I became even less irate since it appears the verification process is open to self-signing: The image/DLL verification hooks are at this point able to verify DLLs 302 * containing embedded code signing signatures, and will restrict the locations 303 * from which DLLs will be loaded. When #SUPR3HardenedMain gets going later on, 304 * they will start insisting on everything having valid signatures, either 305 * embedded or in a signed installer catalog file. I had some problems with self-signing back in July, so I kiboshed the idea back then. But now I'm much smarter, and will sign all extended kernel DLLs to prevent such incidents from happening again. It is one of the best practices I want to implement to polish the project further; another is for the files to adopt their own versioning, so they can be better distinguished from MS files.

You may want to enable Quality Windows Audio Video Experience. This is what fixes the Discord app problems.

In this case, you may try local dll redirection (like making a folder named virtualbox.exe.local in the virtualbox folder) and copy all MS versions of the files I have modified into it. Though it seems to be ignoring it and checking the files in system32. It is modified for the purpose of the extended kernel, but what about people who do standard uxtheme patching to allow unsigned visual styles? Perhaps Oracle should focus on legitimate improvements to their software than trying to attack OS enhancement projects. Well, OK, there are cases where files may have been tampered for malicious purposes but VirtualBox is not security software and should not pretend to be.

Sure! I'm always on the lookout for new, useful functions to add to the extended kernel (x64 in most cases). ksthunk.sys doesn't seem to have changed much between Vista and 7 (it would be perfectly possible to use the 7 version in Vista), if at all. Apparently most of the work done in it and associated ks.sys was done for the introduction of WDM drivers with Windows 98 (95 OSR 2.1)/2000.

I couldn't find any version checks in any of the NVIDIA HDA files. But I did notice that there are two different HDA drivers, nvhda64.sys and nvhda64v.sys. Which one do you have? Mind you, Vista and 7 should both use nvhda64v.sys. Though there were apparently differences at the registry level so I'd think there would be differences in what the inf puts in the registry on Vista and 7 but I couldn't find any either. Only different configs for XP/2003, 7/Vista/8, and 8.1.

And here it is: https://mega.nz/file/Bt9kWboR#slwDoaAQfBPOU8prjytUddjMLk0QYNgWxC1RAR59G2Y

OK, on Windows Vista x64 it is w32pServiceTable. I was looking at the 8.1 x64 version earlier and checked w32pServiceTable but it seemed all odd to me there. Windows 2000 has no w32pServiceTable, though there is also a call to ntoskrnl.KeAddSystemServiceTable somewhere in its win32k. Right above this is push offset off_A0170400 ;the offset in 5.0.2195.7399 anyway. The user32/gdi32 stubs seem to follow a similar pattern to ntdll ones, but the values being copied to eax seem to start at 1000h instead of 0. On Windows 2000 it seems that gdi32 takes some priority over user32 in the table.

I think you're talking about the NVIDIA HD audio drivers. I don't use that stuff, but perhaps I can look into them and see if there are any Vista-specific blocks. What specific driver version are you using (Vista and 7)?

It's not working for me either! I'm not aware of any other hosts though ntext is actually not an MS file and one I compiled myself so if I can find an alternative link I'll post it here. Here it is. Just ntext and nothing more. https://drive.google.com/file/d/1OvxwDWdI2yz3f6MTrz9T34PGESYuOE6p/view

Yes, the domain changed recently. Try this: http://o.rthost.win/gpc/files1.rt/palemoon-26.5.0-20180718.win2000.7z