Support arbitrary data at the beginning of the file?
I have a vendor firmware image that prepends signature and certificates to the actual IFD image. The image is not dumped from the flash chip, but is provided along with their firmware upgrade tool.
This doesn't seem to be part of any standard, I rather believe it's a custom behaviour from the vendor's upgrade tool. This is handled, for example, by UEFITool in FfsParser::parseGenericImage, which is called only if a regular IFD starting at 0 is not found.
Even if this is a non-standard customization, I think it's an interesting feature to have. I can make a PR to support this use case with a -generic flag that will scan the file until it finds a valid IFD. What do you think?
I like this idea.
One question: Will the header be completely discarded, or will it be copied to the modified firmware image?
the thing is we already support generic images without an IFD, for example edk2's OVMF. I suspect what happened however is that the signature caused our FV headers to be misaligned. How would you fix this if there was an image with no IFD but the certificates caused the FVH signatures to be out of alignment?
One question: Will the header be completely discarded, or will it be copied to the modified firmware image?
I would say discarded, as we would not be able to regenerate a valid signature (and it's not utk's responsibility)
How would you fix this if there was an image with no IFD but the certificates caused the FVH signatures to be out of alignment?
Good point, let me try if this is the case and I'll get back here
@GanShun , if the image has no IFD and it's misaligned, I guess that the parser would just fail at some point. What I would do is:
- add a flag to
FindSignatureto say "search anywhere, not just at offset 0 and offset 16"; - add a CLI flag to call
FindSignatureappropriately.
Then if it's an image that does not start at 0 and is not wrapped in an IFD, well, the parser will fail anyway, and we would still support all the previous use cases. Am I missing something?
I'd much rather it be seamless. Maybe we should allow searching the biosregion for any FV signature even if it's misaligned. The worry is that we may end up having false identifications of firmware volumes.