Leaderboard

I have since revised the instructions due to the corruption issues I experienced. If all tables are good (you can check them each in CFF), then you don't have anything to worry about anyway though they will be useful with future updates.

.xdata is the preferred nomenclature.

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

Sure , using randomly a sufficient number of random tools before or later you will succeed , though you won't ever learn about the matter at hand and occasionally you will botch something beyond recovery . jaclaz

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