Is it possible to statically patch kernel32.dll and other related files for NTVDMx64?

[happymimimix]

Currently, NTVDMx64 always download the symbols and patch the files dynamically in ram. I wonder if it's possible to statically patch these files on disk.
My Ra1ndows, previously known as Lindows 11.1, project is now already capable of loading any unsigned dll, exe, or sys on disk. Digital signature is NOT a barrier for me anymore. Great thanks to the cishim project that made all of this possible.
The problem is, are you injecting any new instruction into these files that are longer than their original length? If no, then a static on disk file patch is certainly doable!

Check out my Ra1ndows(WIP) repository: https://github.com/happymimimix/Ra1ndows

[leecher1337]

It is partly possible, but I don't see a lot of sense in it, as these files normally change quickly on updates, so unless you want to stay on an outdated DLL-version, patching the files has no benefit besides not having to inject the loader code into the target process.
Be aware that code has been added that lives inside the loader, so you'd need to add segments to the libraries and add the additional code there (or add IAT entries to load the code from the loader-DLL, but then you can keep it as-is anyway).

[happymimimix]

It is partly possible, but I don't see a lot of sense in it, as these files normally change quickly on updates, so unless you want to stay on an outdated DLL-version, patching the files has no benefit besides not having to inject the loader code into the target process. Be aware that code has been added that lives inside the loader, so you'd need to add segments to the libraries and add the additional code there (or add IAT entries to load the code from the loader-DLL, but then you can keep it as-is anyway).

I will not migrate the Ra1ndows project to any version newer than 22000.1, it's 22000.1 forever. So the files will of course never change.
Is the new code longer than the old code? If no, then I'm very certain this is doable.
There is a slight chance that I'll migrate Ra1ndows to 20348 if I can get the new DWM working correctly on 20348, but the chance is very slim. I think it's much more likely for me to get the old explorer and shell experience host on 22000 rather than the other way around.

[leecher1337]

Yes, the new code is logner than the old code as there are certain wrappers that have to pre-/post-process calls. It also laregely depends on the Windows version, i.e. on Windows XP, a whole new CreateProcess needs to be added and implemented, as the code is just missing in there, whereas other fucntions just need to be patched.
If you want to know more, you need to bite the bullet and check the loader code, it's not a secrect:

https://github.com/leecher1337/ntvdmx64/tree/master/ntvdmpatch/src/ldntvdm/ldntvdm

Depending on the OS configuration and patch level, verious patches need to be made or not made.
What would be interesting is to revert to old user32.dll etc. that aren't lackign the WOW16 support as the new ones do, so that Win16 applications would be runnable again.
Patching Win16 back into the current user32.dll etc. seems nearly impossible to me, it would require patching so many functions.

But whatever you do, ne prepared to have a lot of work with it, if you really plan to patch it into the DLLs.
So it certainly is possible, but it's hard to do. We dont jsut fix bugs by patching a JNE to a JMP or NOP some commands, the loader also replaces missing code.
Some stuff may be really be fixable in-place, i.e.:
https://github.com/leecher1337/ntvdmx64/blob/master/ntvdmpatch/src/ldntvdm/ldntvdm/consbmpbug.c
But other patches are not that easy.

[happymimimix]

So unless we have Windows 10 source code, static patch is not doable. At least not easily doable, since the new code is LONGER than the old code.