Delving Deep into Reverse Engineering of UEFI Firmwares via Human Interface Infrastructure

Round 1

Reviewer 1 Report

Discuss the practical implications and applications of reverse engineering UEFI firmware through the HII. How can this knowledge be used in real-world scenarios, and what are the potential benefits or risks associated with it?

Explain the legal and ethical considerations related to reverse engineering UEFI firmware and what precautions should be taken.

Consider including real-world case studies or examples to illustrate the practical application of your topic. This can make your work more engaging and informative.

Conclude your work by discussing potential future trends or developments in UEFI firmware reverse engineering.

can be  improved

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

The paper deals with a general software interface, UEFI, between any OS and its underlying platform firmware and its relation with a interface infrastructure, HII. A protocol-centered static analysis method is provided to find password policies and implementation. Reverse-engineering is performed in the interface repository in order to locate sensitive information. Hence a reverse-engineering systematic analysis is done to provide valuable insights into interface structure and discover potential enhancements for firmware security. The research has got very interesting results and it gives rise to to great potentials of forthcoming developments.

As a minor remark, this reviewer recommends to explain the meaning of many acronyms at the very first appearences in the text. Unexplained acronyms render difficult the reading.

There is an excess of acronyms in some cases unexplained, in other cases, explained much later than their first appearance.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

The paper presents a novel approach to the reverse engineering of UEFI firmwares.

No major issues were detected, just some minor typos and a simple consideration that I'm curious to discuss.

1. I think there it is a typo on "Case StudiE", probably it were "Case Studied" or "Case Studies".

2. I'm wondering if the paper should mention countermeasures to this approach in terms of freedom of UEFI (and interfaces) such as countermeasures implementable (or implemented) by coreboot / libreboot / linuxboot / u-boot UEFI firmwares. This will ensure that the password saved are stored inside a secure hardware enclave if available or using the state-of-the-art cryptography to avoid cracking. Probably it needs future investigation which would be easily a stand-alone paper, but a single line or footnote specifying the existence of open-source and free / libre UEFI can be useful.

I'm confident that the paper, with the little improvements specified in this letter would be in an acceptable form.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf