OSDev.org

How to write an application that will allow you to access to EFI Table, EFI Services from WinXP 64-bit or newer Windows but not used Windows API and functions?

You can't. Windows will not give you access to UEFI runtime memory.

But I know that WinXP 64-bit does not have access to EFI and that's why I ask about an application that will have access.
In Win7 or newer, you can easily edit Boot Menu NVRAM using bcdedit or BootICE: On WinXP no access:

The problem is deeper than Windows. To boot WinXP, the PC's boot firmware has to go into BIOS mode. The only way back from BIOS to UEFI is for the MBR to fail to boot. Some PCs don't even support that properly, crashing if they find an unbootable MBR.

eekee wrote:The problem is deeper than Windows. To boot WinXP, the PC's boot firmware has to go into BIOS mode. The only way back from BIOS to UEFI is for the MBR to fail to boot. Some PCs don't even support that properly, crashing if they find an unbootable MBR.

I don't understand what this has to do with the topic?

I know how to boot WinXP SP2 64-bit under pure UEFI - this is my tutorial which I wrote a few days ago:
Sysprep WinXP SP2 64-bit on pure UEFI - V3
Here is a post in the topic from which I started (September 2018) to deal with WinXP 64-bit on UEFI:
Does Windows XP have EFI

Ah, sorry. I assumed from the 3rd screenshot that WinXP can't boot from UEFI.

This is a crazy hack for you if you are brave enough to write a UEFI program and Windows driver in addition to the interfacing program to accomplish what you ask about:
Write a UEFI application. Its role would be 1) get started as an OS loader via UEFI Boot Manager, e.g. you start it manually either via "boot from file" Boot Manager menu or via UEFI "shell" (that in fact is command interpreter and not shell). From UEFI this app gets for free all you ask about - System Table pointer and everything else, because it's contained in the latter. Then this app, using UEFI EFI_FILE_PROTOCOL's Write() (and everything else needed) will dump the needed info into some file, on a FAT volume, that UEFI will certainly can access to. If ESP is present, then it's a good place, say write it into "efi\beta\mycrazyhack.dat" file and then either 1) simple but might (or might not) be unreliable, needs to be checked, just return to UEFI, after what you would just boot Windows a normal way, or 2) the app itself will chainload Windows' bootmgrfw.efi - this is a bit more complicated, I'd go with variant 1 and only if it fails, would start to mess with this one.

Now to the driver/interfacing program part. You create a program that, running as an administrator, starts the driver, you made and sends special requests to it, sending info (for example, UEFI System Table pointer in the system address space (its physical address in other words)), that it takes from the "ESP:\efi\beta\mycrazyhack.dat"***

The driver gets this info and further it needs to find correspondence (mapping) between the input system (physical) address of the System Table, I believe, you would really need the Runtime Services Table address and its virtual address. How to do that? if you can find PFN database, it's easy. Just go to the appropriate PFN slot, if the physical address is 0xB00B5000, then the slot index will be: So the slot index is 0xB00B5 and PFN entry address is PfnBase[0xB00B5]. there you'll find the virtual address of the page, if it's set up. which could be not the case. But then, you would know, that you cannot access UEFI Runtime Services, probably having to validate, that all the pointers in the RT are also valid and already mapped, otherwise here your driver will crash the system. If you reach this point, you can access to the UEFI Table, in its run time state. On a system, that wasn't intended to support it yet, keep this in mind. But it should work on Itanium XP, shouldn't it? Maybe you have such? Itanium is also abandonware. Unfortunately. btw, don't forget, that on it page size is 8KB so the PageSizeExponent from the above formula is 13.

*** - if the FAT volume, you've taken your dump into is ESP, then don't forget to attach/assign letter to it before starting your app, so that it would be free of that burden. do it through diskpart. ESP is easily findable. because it's marked as "System". do in the diskpart prompt: lis vol. find ESP volume and its number N. Once you found it, do: select volume N -> assign letter S, S - is a free letter, you want to assign to ESP.

This is all a pure theory and I might be wrong about PFN, because it's how my own PFN is going. I might get it wrong reading about that stuff in Windows. Anyway, it could be a fun adventure if you wanna access to UEFI guts from XP this badly.

@zaval
Thanks for the answer. I found something like memory.efi but I don't know what it is for. Maybe it could be used?
Efi-memory is a proof-of-concept EFI runtime driver for reading and writing to virtual memory.

All runtime services functions are hooked now to make sure they are close to each other

In Win10 efimapper.exe & blank.sys works but not in WinXP (after edited MajorOperatingSystemVersion & MajorSubsystemVersion from 6 to 5)

In kernel32.dll WinXP SP2 64-bit is only InitializeCriticalSection function: