Wow, you're really taxing my brain. There's a difference between vaguely recalling something and remembering how the hell I did that stuff 15 years ago.
You could start with searching 'code caves', code injection, adding functionality, that sort of thing. When doing any kind of word searching here I'd strongly recommend using the Archive chm file I made of the entire site. The MS chm file reader has a much better search index than this vbulletin forum, that's how I find all these obscure posts. If you select View Full Version in the search result it will open the link directly in the hh.exe browser window.
http://www.woodmann.com/kayaker/chmfile ... 1_2016.zip
If the code you're trying to emulate is simple enough and you can reverse the functions, it might be easiest to code your own dll or kernel mode dll and have them loaded by the XP versions, your imports should be visible to call by name from injected code. Probably a few techniques for doing that.
Chances are however you'd like to be able to call the functions in the existing (possibly renamed) W7 exe and sys files, by name directly, from injected code in the XP versions. Slightly different issue.
Going that route, your executable files are presumably .exe and .sys, they'll have to be loaded as a dll essentially. In the case of a dll the usual injected code is LoadLibraryA, GetProcAddress to call your functions.
In the case of the sys file it could be a kernel mode dll. I did write such a beast, Sysdasm, here's a few lines from my intro text of the source code:
In this type of export module, the DriverEntry routine is never called but exists so the file is compiled correctly as a .sys driver. If you want to design such a Kernel Mode DLL with functional entry/exit routines, you can add PRIVATE exports declared as DllInitialize/DllUnload.
The easiest way to use such a kernel mode DLL is to include its .LIB file when compiling the driver which will communicate with it, and to declare the functions you want to import with EXTERN_C DECLSPEC_IMPORT. When the driver is loaded by the system, this second module is loaded as a required kernel DLL and the functions can then be called directly by name. The DLL is unloaded by the system when the driver closes.
The second method to make use of a kernel mode DLL is to load and unload it with ZwSetSystemInformation and the SystemLoadImage and SystemUnloadImage classes. You can then "walk" the returned IMAGE_EXPORT_DIRECTORY of the module to retrieve the function address(es).
One approach might be to code your own kmode dll that you get to load from the XP version, essentially to use it as a wrapper for calling functions in the unaltered W7 file. I'm thinking it might be easier to call and control functions from a wrapper than having the W7 file loaded directly and having to write gobs of asm code. Or not, depends on what works I guess.
Or maybe you could change the PE structure of the W7 .sys file so it's recognized as a kernel mode dll by the system, and by the XP version as a default import.
Another idea might be to have both the exe and sys file loaded in system memory, and have your code access the functions from there. There should be tuts for that, I think Arteam did a lot of "loaders".
What just came to mind, you should play with loading and calling these W7 files with Windbg if you can, SDbgExt might help. (And somebody else we know...
!remotecall, !remotecall64: Call a function in the target, using the currently active thread (symbols are not required, unlike â€œ.callâ€).
!loaddll, !unloaddll: Load or unload a .dll within the address space of the target, using the currently active thread.
As for the other ideas, here's some user/kernel loading examples using your own dlls
http://www.woodmann.com/collaborative/t ... hp/SysDasm