win32

I brought BWC's PE Maker to its knees. It appears that the gigantic export table of my 32 bit ntext with about 1850 functions and about 109 000 (decimal) bytes in size is too much for the application. It only seems to write the first 100 000 bytes of it. And having the export table below rsrc/reloc is a no-go with PE32 of course (need to redirect to a kernel32 pointing to ntdll or OG ntext for x86 software to work at all on my system right now ). So I looked at the problematic x86 K32* functions again. It appears that any upgrading of Nt/Zw* functions will need to be done in ntoskrnl, and some of those are very complex. But there are other ways to look at the situation, like comparing the changes between the original psapi functions and the K32 equivalents (simply forwarding a K32* to psapi doesn't work in many cases). And guess what, the only differences I saw between psapi's GetProcessMemoryInfo and K32GetProcessMemoryInfo were quite minor. All of them were like this: NT 6.0 psapi!GetProcessMemoryInfo jz routine1 if not zero, go to routine2 NT 6.1 kernel32!K32GetProcessMemoryInfo jnz routine2 if zero, go to routine1 Every routine was the exact same!! A change in strategy is needed.

Unfortunately that is not possible right now as it seems to be much harder to change MinorVersion than MajorVersion on Vista (wasn't NT 6.0 supposed to be followed up by NT 7.0 according to MS plans in 2006?). I'm thinking of making a code cave to another part of the file where MinorVersion gets inserted farther up the food chain and see if it changes anything. And possibly even a filename swap between ntdll and ntext to deal with problematic software like Qt 5.10+. Though I feel that this limitation may well be applicable to Windows 7 as well, but is less of an issue since I think W7 users will only need to spoof NT 10.0 in the future. it didn't. though it may be revisited in the future based on 6519/7000/7601 since I am now aware of workarounds to import table limitations. Though the structures that Vista LoadLibraryExW refers to are very different from the other OSes.

That is a very weird place for a crash. It's right in the middle of an offset to a registry entry \Registry\Machine\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers (nothing seems to refer to it)! Unless it's 32bit, then it's at the beginning of the export table entry for the function MapViewOfFileExNuma. And in other news, so far the version changing initiative has crashed and burned. While the browsers are in better shape with the OS identifying as NT 10.0 than before, I still can't get MinorVersion changed whatsoever! Qt 5.10+ still manages to bypass ntext to call RtlGetVersion from ntdll! Major changes to RtlGetVersion in ntoskrnl but no effect on the user-mode version checking components. Some testing is needed with the considerably different XP x64 and W7 versions of RtlGetVersion to see if there are effects on those OSes and if so, I will look into replacing the Vista version of that function with one of those.

Nope, because Vista will be NT 6.1. I'd be flabbergasted if minorversion didn't change after this modification. Anyway, kernel32 can be modified to lift that requirement as well if this doesn't work.

There are a few places where binaries have been released publicly, but they are probably very outdated, and it will probably never be posted directly on here due to file redistribution policies. Only the ntext files can be posted directly because I compiled them and not MS. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- So for those who want to know more about RtlGetVersion, which is the "root" function for other functions like RtlVerifyVersionInfo, VerifyVersionInfoW, etc. I found that: r9+118h equals MajorVersion r9+120h equals BuildNumber (little endian of course) Those are easy to modify by making the mov eax, [r9 + xxh] into mov eax, 5 or something similar. But r9+11Ch seems to be what I think it is, and r9+124h and r9+2F0h are problematic when changed. PlatformId is not something I want to change, and I think applications will be satisfied with SP2, but where exactly is MinorVersion? I suspect r9+124h but So what should be done? Changing MajorVersion to 10 is not a good idea, as many browsers fail if compatibility shimmed to 6.2 and above. And Windows 10 tells legacy software that it's NT 6.2 anyway. And also, changing values grabbed from memory to fixed ones can also depreciate the value of Windows compatibility mode, since they rely on RtlGetVersion to get the changed version numbers. Things may be easier on the kernelmode side anyway. I think I just answered the question I asked some time ago: ntoskrnl!RtlGetVersion - Vista SP2 6002 public RtlGetVersion PAGE:000000014037FE50 RtlGetVersion proc near ; CODE XREF: RtlVerifyVersionInfo+65↑p PAGE:000000014037FE50 ; sub_14011F9A0+7B↑p PAGE:000000014037FE50 ; DATA XREF: ... PAGE:000000014037FE50 PAGE:000000014037FE50 arg_0 = byte ptr 8 PAGE:000000014037FE50 PAGE:000000014037FE50 push rbx PAGE:000000014037FE52 sub rsp, 20h PAGE:000000014037FE56 and dword ptr [rcx+8], 0 PAGE:000000014037FE5A cmp dword ptr [rcx], 11Ch PAGE:000000014037FE60 mov rbx, rcx PAGE:000000014037FE63 mov dword ptr [rcx+4], 6 PAGE:000000014037FE6A mov dword ptr [rcx+0Ch], 1772h PAGE:000000014037FE71 mov dword ptr [rcx+10h], 2 PAGE:000000014037FE78 jnz short loc_14037FEDC PAGE:000000014037FE7A movzx eax, byte ptr cs:dword_1401FEBC0+1 ntoskrnl!RtlGetVersion - Windows 7 SP1 7601 PAGE:00000001402C6744 public RtlGetVersion PAGE:00000001402C6744 RtlGetVersion proc near ; CODE XREF: RtlVerifyVersionInfo+5E↑p PAGE:00000001402C6744 ; sub_140187940+7D↑p ... PAGE:00000001402C6744 PAGE:00000001402C6744 arg_0 = byte ptr 8 PAGE:00000001402C6744 arg_8 = qword ptr 10h PAGE:00000001402C6744 PAGE:00000001402C6744 mov [rsp+arg_8], rbx PAGE:00000001402C6749 push rdi PAGE:00000001402C674A sub rsp, 20h PAGE:00000001402C674E cmp dword ptr [rcx], 11Ch PAGE:00000001402C6754 mov dword ptr [rcx+4], 6 PAGE:00000001402C675B mov dword ptr [rcx+8], 1 PAGE:00000001402C6762 mov dword ptr [rcx+0Ch], 1DB1h PAGE:00000001402C6769 mov dword ptr [rcx+10h], 2 PAGE:00000001402C6770 jnz short loc_1402C67DD PAGE:00000001402C6772 movzx eax, byte ptr cs:dword_14027BC5C+1 Notice that at rcx, 11Ch goes there in both. At rcx+4, 6 goes in both. At rcx+8, Vista puts 0 and 7 puts 1. At rcx+8, Vista gets 1772h (6002) and 7 gets 1DB1h (7601). rcx+10h = 2 is presumably shorthand for the expected PlatformID (2 = Win32NT). XP x64 is very similar, but the location of MajorVersion/MinorVersion is somewhere completely different on 32bit NT 5.x (though someone else found it). So this would probably affect what ntdll/ntext!RtlGetVersion and its offshoots call for OS versions and build numbers without affecting functionality, and render my internal CurrentVersion registry patch obsolete. But I still need to make the process of using a custom ntoskrnl as simple on UEFI as it is with a BIOS.

not yet. that was a bit of thinking out loud.

Take a screenshot of the error dialog and post it here. Then I'll know what to do (hopefully). Is the game 32 or 64 bit? I have now built a functional 32bit wrapper for ntdll, and it is being used by my kernel32 right now. So the focus will be on 32bit usermode improvements for the next while. So the functions to be upgraded to Windows 7 specifications: NtQueryInformationProcess NtQuerySystemInformation and probably more... And now I want to deal with RtlGetVersion. I think I'm close to figuring it out. .text:0000000078E9BD76 mov eax, [r9+118h] .text:0000000078E9BD7D mov [rcx+4], eax .text:0000000078E9BD80 mov eax, [r9+11Ch] .text:0000000078E9BD87 mov [rcx+8], eax .text:0000000078E9BD8A movzx eax, word ptr [r9+120h] .text:0000000078E9BD92 mov [rcx+0Ch], eax .text:0000000078E9BD95 mov eax, [r9+124h] .text:0000000078E9BD9C mov [rcx+10h], eax .text:0000000078E9BD9F mov r8, [r9+2F0h] I think the r9+xxh indicates the ULONG values in the OSVERSIONINFOEXW structure. I believe that the r9+11Ch would indicate OSVersionInfoSize, whereas the other four pertain to MajorVersion, MinorVersion, BuildNumber and PlatformId. I just need to find a lightweight application with a OSVERSIONINFO(EX)W structure and set up a breakpoint in there and hopefully I'll know which is which.

Yes, but osloader.efi is presently non-functional. And not needed if you're on BIOS/MBR. Likewise, osloader.exe is useless on UEFI.

Actually, 2000/XP (not sure about how NT4 with SP4+ will handle it, though it would probably be the same - earlier NTs won't read NTFS 3.x) will also require you to get around the file permission hurdle.

so nothing refers to the problematic instruction anymore, yet it's still responsible for crashes? sigh

Now I have uploaded another one, that tries to bypass the problematic set of instructions.

i just uploaded a new one making a different assumption at the offset.

I changed something at the offset where the error occurred. I wonder what the crashes look like now?

uploading revised version now.

no, that's the 32bit version of nvwgf2umx.dll.

I have released modified versions of the 372.70 user mode drivers in an effort to get them to use Windows 7 driver directives. Both 32 and 64 bit binaries. You can find them in my Vista extended kernel folder. x64 files are suffixed with an x and go into system32. x86 files go into syswow64.

No:

OK. opengl32.dll is also a file distributed with the OS. Are things different with the regular Vista version of the file, with and without extended kernel?

The stackhash crashes, I don't really know what to do with those. But I noticed that in your first "log", the exception offsets for Watch Dogs and 7DTD are the same. Do they have the same anticheat or DRM? Though maybe the Windows 7 version of opengl32.dll can be dropped in.

I removed it, and the same thing happened, so the crash doesn't seem to be related to the digital signature. Though I'm not exactly sure why the crashes are happening. Could be because of your reason or that the 8.x directx graphics kernel doesn't work well with W7-targeted binaries. DirectX binaries were not digitally signed until Windows 8 came out.

I just checked the kernel32 fault and it is not in a section of the file that I modified/added. It's in a subroutine called by ReplaceFileW, CreateDirectoryExW and indirectly by CopyFilesExW. Vista's WEI does indeed max out at 5.9.

Does it crash with the regular MS files?

Well, that function is not in that copy of ole32. Someone else complained to me about it. The standard extended kernel v3.0e English (not the gameguard version) has this function in ole32 and works good with roytam's browsers. But I remember that the extended kernel installer has many options, some of which have to do with ole32.

Not for any changes to 372.70. Only for newer drivers once ntoskrnl is extended.

At that offset, there is call to an internal function called _errno. Unfortunately it is difficult to determine what exactly caused the crash, but I have some ideas. I noticed that the d3d12 runtime is digitally signed, and as such is not supposed to be modified. So I'll remove it and you can see how that works (no d3d12 games here). You may need to boot with driver signing disabled.