.webp)
We promised to release the new version of efiXplorer with ARM-based firmware support last week at the inaugural LABScon event. This is one of the most important releases since the project began in February of 2020. In the beginning, efiXplorer focused primarily on x86-based firmware analysis, but after seeing the growth of ARM-based servers and laptops, we are now adding support for ARM.
There are numerous improvements to the efiXplorer analysis engine, as well as the introduction of a new feature -- the analysis of AArch64 modules for ARM-based firmware images.
See below for a complete list of improvements: - [FEATURE] GUIDs installation mechanism - [FEATURE] The GUIDs database is now located in a separate repository:
https://github.com/binarly-io/guiddb - to install it, just copy the guids.json or guids/guids.json file into the directory with the plugins - [FEATURE] The JSON report generated by efiXplorer now includes additional information, such as service arguments addresses - [FEATURE] Improved SMM modules analysis - [BUGFIX] efiXloader (thanks to @cc-crack) - [FEATURE] Added attributes extraction for NVRAM variables - [FEATURE] Improved detection of vulnerabilities related to improper use of GetVariable service (thanks to @naconaco) - [FEATURE] Improved GUIDs detection - [FEATURE] Added segment permissions fixes (to fix the results of decompilation of some modules) - [FEATURE] Dependencies and idasdk updated to the latest versions - [FEATURE] Added support for analysis of EFI modules with AArch64 architecture - fix entrypoint for EFI modules - global/local variables detection (that contains addresses of major tables such as ST, BS and RT - fix names and types for the major variables - Boot services, Runtime services detection - GUIDs detection - protocols detection - changing names and types for the protocol interfaces - displaying windows with lists of GUIDs, services, protocols and navigation through them - [FEATURE] Added tracking types of arguments that are passed to child functions to change child function prototypes - [FEATURE] Other minor improvements to the plugin
The complete list of commits since the previous v4.1 [BHASIA Edition] release:
https://github.com/binarly-io/efiXplorer/compare/4.1...master
In this blog, we will take a closer look at the major changes and improvements in efiXplorer v5.0 [LABScon Edition].
It should be noted that in contrast to the x86 analysis, almost all features are implemented with additional detectors based on Hex-Rays Decompiler SDK. The Hex-Rays SDK provides a lot of interesting features to improve code analysis through adoption of intermediate representation (IR) which can help to automate many routine code analysis work. Thus, it can easily be extended and transferred to new processor architectures in the future because of IR adoption for the analysis. However, this means that efiXplorer requires an IDA with Hex-Rays Decompiler for ARM to analyze AArch64 firmware modules.
By default, the types from IDA type information library (TIL) files uefi64.til will not be compatible when loading EFI modules compiled support of the AArch64 architecture in IDA. Here is the hint, in order to fix, copy the file uefi64.til from til/pc/uefi64.til directory to til/arm/uefi64.til. In this case efiXplorer will rename the start/main function (entrypoint) to the _ModuleEntryPoint function and the prototype of the function will be fixed automatically by IDA code analysis. Let’s look at the example to see the difference in the figure below.
Before fixing the issue with type information:
After fixing the issue with the type information:
When a type information library is loaded, functions with names matching the prototypes present in the library will have their prototypes applied from the database. In this way, analysis of the code is significantly changed to make the code much more readable.
With Hex-Rays SDK-based analysis, we track the types of variables that are passed to child functions and change their prototypes as IDA does not do this automatically. This helps to analyze code based on type information automatically and improves the pseudocode generated by IDA, making it easier to perform subsequent analyses. Once definitions are loaded from the type library, IDA and the Hex-Rays Decompiler can use them. These types can be used in function prototypes and global variables.
Let’s take a closer look at one example: After we fix the module entry point, arguments from ModuleEntryPoint can be propagated to child functions. But the prototype of the child functions will not be changed automatically as shown on the figure below.
The new version of efiXplorer modifies the child function prototypes recursively before the main analysis flow takes place, which results in the improvements shown in the figure below.
Another example:
In future versions of efiXplorer, we plan to apply the same techniques to improve the analysis of SMI handler routines, e.g., to track the use of the CommBuffer, which was out of scope in the previous versions of the efiXplorer plugin.
Now efiXplorer will detect the necessary global and local variables and change their names and data types automatically, which significantly improves the code analysis process.
This new feature with automated global and local variables recognition has been also implemented on top of Hex-Rays SDK.
Let's explore some new features that make firmware researchers' lives easier and help to understand better attack surfaces and code coverage during analysis.
EFI protocol and service information are important primitives that aid in understanding the logic of the code flow when reverse engineering UEFI firmware. We make this very easy with the new efiXplorer release improvements as shown on the figure below.
This release also includes an revised EFI protocol recognition algorithm which has better coverage and provides significant improvements. The results shown in the picture below.
The detection of the GUIDs for the EFI protocols is very important to create clean and readable decompiled code.
Overall, these combined improvements create a better experience and reduce the time of the code analysis when it comes to UEFI firmware reverse engineering.
Another new feature focuses on changing names and types for the protocol interfaces which was not available in previous versions. This functionality now makes code look much cleaner.
On the figure below you can see the difference between different architectures supported by efiXplorer at the moment.
Thank you for all the support coming from the REsearch community. We will focus on the further improvements in efiXplorer to make the UEFI firmware analysis more approachable and enjoyable.
Our backlog is full of new features, so stay tuned for the upcoming releases!
.svg)
