why?
data:00000000000E2280 ; EFI_GUID *gEfiLoadedImageProtocolGuid_0xe2280
.data:00000000000E2280 gEfiLoadedImageProtocolGuid_0xe2280 dq 11D295625B1B31A1h
.data:00000000000E2280 ; DATA XREF: sub_1CD7E+1D5↑o
.data:00000000000E2280 ; sub_1D0C6+111↑o ...
.data:00000000000E2288 db 8Eh ; Ћ
.data:00000000000E2289 db 3Fh ; ?
.data:00000000000E228A db 0
.data:00000000000E228B db 0A0h ;  
.data:00000000000E228C db 0C9h ; Й
.data:00000000000E228D db 69h ; i
.data:00000000000E228E db 72h ; r
.data:00000000000E228F db 3Bh ; ;

but corectly

.data:00000000000E2280 ; EFI_GUID *gEfiLoadedImageProtocolGuid_0xe2280
.data:00000000000E2280 gEfiLoadedImageProtocolGuid_0xe2280 DGUID {5B1B31A1-9562-11D2-8E3F-00A0C969723B}
.data:00000000000E2280 ; DATA XREF: sub_1CD7E+1D5↑o
.data:00000000000E2280 ; sub_1D0C6+111↑o ...
.data:00000000000E2280 ; ->EFI_LOADED_IMAGE_PROTOCOL_GUID

A question:
in IDA Pro, why did you choose 25 (x86) and 16 (x64) when looking for protocols?
In get_protocols() (https://github.com/yeggor/UEFI_RETool/blob/master/ida_plugin/uefi_analyser/analyser.py#L130):

            for address in self.gBServices[service_name]:
                ea, found = address, False
                if self.arch == 'x86':
                    for _ in range(1, 25):
                        ea = idc.prev_head(ea)
                        if (idc.get_operand_value(ea, 0) > self.base
                                and idc.print_insn_mnem(ea) == 'push'):
                            found = True
                            break
                if self.arch == 'x64':
                    for _ in range(1, 16):
                        ea = idc.prev_head(ea)
                        if (idc.get_operand_value(ea, 1) > self.base
                                and idc.print_insn_mnem(ea) == 'lea'):
                            found = True
                            break

In radare2, instead, you use LEA_NUM (x64), a kind of instruction offset. This solution, unfortunately, is not always accurate.

What is the correct solution?

Inside the analyse_all function we can find the following snippet which tries to delete the previous log file:

log_path = os.path.join('log', 'ida_' + scr_name.replace('.py', '.log'))
if os.path.isfile(log_path):
	os.remove(log_path)

However, IMHO the output emitted by the analyzer script is a Markdown file with an .md extension, which means the above code will never execute. Am I missing something?

Currently the IDA plugin does a very good job in finding calls to several selected UEFI boot services, but so far the runtime services were neglected. Since runtime services are a key part of the UEFI specification, supporting them will greatly aid the reverse engineering of virtually any UEFI module.

Failed while executing plugin_t.run():
Traceback (most recent call last):
File "C:/Program Files/IDA_Pro_v7.0/plugins/uefi_analyser.py", line 52, in run
self._analyse_all()
File "C:/Program Files/IDA_Pro_v7.0/plugins/uefi_analyser.py", line 93, in _analyse_all
prot_explorer.run()
File "C:/Program Files/IDA_Pro_v7.0/plugins\uefi_analyser\prot_explorer.py", line 181, in run
analyser.analyse_all()
File "C:/Program Files/IDA_Pro_v7.0/plugins\uefi_analyser\analyser.py", line 438, in analyse_all
self.make_comments()
File "C:/Program Files/IDA_Pro_v7.0/plugins\uefi_analyser\analyser.py", line 307, in make_comments
idc.op_stroff(address, 0, EFI_BOOT_SERVICES_ID, 0)
File "C:\Program Files\IDA_Pro_v7.0\python\idc.py", line 1267, in op_stroff
return ida_bytes.op_stroff(ea, n, path.cast(), 1, delta)
File "C:\Program Files\IDA_Pro_v7.0\python\ida_bytes.py", line 1007, in op_stroff
return _ida_bytes.op_stroff(*args)
TypeError: in method 'op_stroff', argument 1 of type 'insn_t const &'

Overall, I don't see the significance of this tool, and it feels like it's useless compared to uefitools. Are there any other test cases or usage methods, thank you.

IDA Pro is not the only reverse engineering platform in the world. Another popular one is Radare2, a highly-portable cross-platform reverse engineering framework and a toolkit without dependencies. It has support for analyzing binaries, disassembling code, debugging programs, attaching to remote GDB/LLDB, WinDbg servers, rich plugin system (see r2pm), and integration with various decompilers. For example, ghidra decompiler plugin - r2ghidra-dec. It is actively developed and can be easily integrated in various open source and commercial products. I believe, it will be highly beneficial to support these and provide a package for install from r2pm, see the package repository here: https://github.com/radareorg/radare2-pm

For documentation on writing plugins for radare2 see Scripting and Plugins Radare2 Book chapters.

Cutter is a crossplatform Qt/C++ GUI frontend to radare2:

For documentation on writing plugins for Cutter see the official tutorial and the curated list of various popular plugins.

ipxe-efi.zip

1. see .text:000000000001D0D4 - error

2. use for indirect call not only comment but IDA command: (example)

   op_stroff (0X1D130, 0, GetStrucIdByName("EFI_BOOT_SERVICES"), 0);

.text:0001D127 mov r8, [r13+10h]
.text:0001D12B xor edx, edx
.text:0001D12D mov rcx, r13
.text:0001D130 call qword ptr [rbp+140h] ; EFI_BOOT_SERVICES->LocateProtocol

changed to

.text:0001D127 mov r8, [r13+10h] ; Interface
.text:0001D12B xor edx, edx ; Registration
.text:0001D12D mov rcx, r13 ; Protocol
.text:0001D130 call [rbp+EFI_BOOT_SERVICES.LocateProtocol] ; EFI_BOOT_SERVICES->LocateProtocol

in this case Ida automatically comment parameters.
But previously you need load struct description from Tlib.

There are cases in which a DXE driver uses a protocol it registered beforehand, for example:

[UEFI_RETool] EFI_ARP_PROTOCOL_GUID protocol information
{
    "module_name": "ArpDxe",
    "protocol_name": "EFI_ARP_PROTOCOL_GUID",
    "guid": "F4B427BB-BA21-4F16-BC4E43E416AB619C",
    "service": "InstallMultipleProtocolInterfaces",
    "used_by": [
        "ArpDxe",
        "Ip4Dxe",
        "UefiPxeBcDxe"
    ]
}

In these reflexive cases, the dependencies graph shows two distinct nodes instead of just one: