Crash at Arm fixOffsets()

[gandalf4a]

When I tested arm UEFI as the attachment AcpiTableDxe.efi , both PEI and DXE modes crashed and generates a mini-dump, when executing fixOffsets(). How to deal with this problem?

System: Windows 11 22631.4169
IDA pro: 8.3.230608 Windows x64
efiXplorer: v6.0

[gandalf4a]

AcpiTableDxe.zip

[yeggor]

Hi. I see that you are using IDA 83 when the latest version of efiXplorer was not compatible with it. I've made it compatible and fixed some issues I didn't notice during the big change when updating the plugin and porting it to IDA 90 (https://github.com/binarly-io/efiXplorer/pull/94).

Please use the latest version from the master:

python3 build.py build-plugin ~/sdk/83/idasdk83 --hexrays_sdk ~/sdk/83/hexrays_sdk

I've tested your test case with IDA 83 and newer versions of IDA and can confirm that it works:

As for the crash in fixOffsets() (which is now fix_offsets()), I can't see how this is possible. I guess it can only happen if the sdk and IDA version are incompatible. Please note that you'll have to build efixplorer with corresponding sdk.

[gandalf4a]

Thanks for compatibility with ida83. I used the master version to compile through, and did not crash, but no matter the PEI or DXE module will appear unresponded pop-up window: What is the cause of this situation? My cpu and memory usage are only about 40%. I don't think it's due to poor hardware performance.

[yeggor]

could you share binary on which you catched this? Maybe somewhere we didn't make an early break from while(true) and it went unnoticed during testing (as arm support was tested much weaker than x86)

[yeggor]

I've added potential fix (which might affect analysis for DXE modules). Сould you check please? And still share the binary or firmware if possible?

[gandalf4a]

The firmware I tested was the same as the attachments above ‘AcpiTableDxe.efi’. Here's what I compiled the master（https://github.com/binarly-io/efiXplorer/commit/ef4d5e17560ae39417b5e2ce8b9a1a775d710d56) with the 83sdk, and I just added msg output to some functions to figure out what went wrong: efiXplorer64.zip Below is a picture of me executing other efi files, as follows: ArmCpuDxe.zip You can see that there is still no response when the fix_Offsets function is executed:

[gandalf4a]

I made a mistake, not losing the response at fix_offsets(), but at initial_analysis().

Here's what I tested by adding some msg：

You can see that it executes into the for loop and the following code is unresponsive:

#ifdef HEX_RAYS
    efi_hexrays::track_entry_params(get_func(ep), 0);
#endif /* HEX_RAYS */

There may be a bug in the efi_hexrays::track_entry_params() of the 83 sdk.

[gandalf4a]

The msg trace efi_hexrays::track_entry_params() function continues to print and finds that it is unresponsive when executing the following code:

cfuncptr_t cfunc = decompile(f, &hf, DECOMP_NO_WAIT);

[yeggor]

Thanks for the details. It's weird, I have everything working on IDA 8.3.230608 analysing both of the provided test cases.

Is it possible that you have other plugins installed that may conflict in some way?

Did you use the hexrays sdk from $IDA83_DIR/plugins/hexrays_sdk?

Also, as I can see, you chose to analyse this file as a PEI, whereas it's a DXE. This should not lead to such failure (I've checked such scenario), but you will get wrong analysis results in this case.

I'll try to test it on windows later, but I don't think the reason is the platform.

[gandalf4a]

I made sure to use the hexrays sdk.

However, this item is not displayed when cmake is configured.

Did it not work?