Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Silently failing #96

Open
huang195 opened this issue Dec 10, 2020 · 0 comments
Open

Silently failing #96

huang195 opened this issue Dec 10, 2020 · 0 comments

Comments

@huang195
Copy link

Thank you for writing this super useful tool for people like me who find themselves all the sudden in need to parse an UEFI file. I've been using this tool to extract all the files and volumes from a BIOS image like so

root@08e899989698:/uefi-firmware-parser# bin/uefi-firmware-parser -e -b -p -q -o /tmp/volume /data/BIOS.ROM > /tmp/output
root@08e899989698:/uefi-firmware-parser# ls -al /tmp/volume/
total 15400
drwxr-xr-x   5 root root     4096 Dec 10 17:45 .
drwxrwxrwt   1 root root     4096 Dec 10 17:45 ..
drwxr-xr-x   4 root root     4096 Dec 10 17:45 volume-16777216
-rw-r--r--   1 root root   524288 Dec 10 17:45 volume-16777216.fv
drwxr-xr-x  73 root root     4096 Dec 10 17:45 volume-29360128
-rw-r--r--   1 root root  4194304 Dec 10 17:45 volume-29360128.fv

It shows that there are 2 Firmware Volumes in the BIOS image, but it didn't look right to us, so after talking to the BIOS manufacturer, we were told that the image should have 3 FVs instead of 2. After turning on --verbose, I saw a few error messages like the following:

INFO:root:GuidDefinedSection ee4e5898-3914-4259-9d6e-dc7bd79403cf 
INFO:root:GuidDefinedSection ee4e5898-3914-4259-9d6e-dc7bd79403cf Could not parse GUID object
INFO:root:FirmwareFileSystemSection 899407d7-99fe-43d8-9a21-79ec328cac21 Could not parse GuidDefinedSection

Apparently there were a few GuidDefinedSections that the parser wasn't able to parse for whatever reason. As a result, neither the FV nor all the other files on the FV were dump'ed at the end. I commented out a few lines of code to let the parser continue to dump despite a few errors, and I got the following result:

root@08e899989698:/uefi-firmware-parser# bin/uefi-firmware-parser -e -b -p -q -o /tmp/volume /data/BIOS.ROM > /tmp/output
root@08e899989698:/uefi-firmware-parser# ls -al /tmp/volume/
total 15400
drwxr-xr-x   5 root root     4096 Dec 10 17:45 .
drwxrwxrwt   1 root root     4096 Dec 10 17:45 ..
drwxr-xr-x   4 root root     4096 Dec 10 17:45 volume-16777216
-rw-r--r--   1 root root   524288 Dec 10 17:45 volume-16777216.fv
drwxr-xr-x 310 root root    28672 Dec 10 17:45 volume-18022400
-rw-r--r--   1 root root 11005952 Dec 10 17:45 volume-18022400.fv
drwxr-xr-x  73 root root     4096 Dec 10 17:45 volume-29360128
-rw-r--r--   1 root root  4194304 Dec 10 17:45 volume-29360128.fv

So, this now correctly shows that the BIOS image contains 3 FVs. A few suggestions are:

  1. Is it possible that when an error is preventing the whole FV from getting dumped, a warning message could be printed without having to use --verbose? That would have allowed us to more easily detect that the parser was having problems with one of the FVs as opposed to giving a false impression that everything was successfully parsed.

  2. Is it possible to change the default behavior so that the parser dumps as much information out as possible despite a few errors here and there?

Combining both 1 and 2 would be great, as it would allow as much information to be parsed while users are warned about those that cannot be parsed successfully.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant