fiano icon indicating copy to clipboard operation
fiano copied to clipboard

Support arbitrary data at the beginning of the file?

Open insomniacslk opened this issue 7 years ago • 5 comments

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?

insomniacslk avatar Oct 15 '18 21:10 insomniacslk

I like this idea.

One question: Will the header be completely discarded, or will it be copied to the modified firmware image?

rjoleary avatar Oct 15 '18 21:10 rjoleary

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?

GanShun avatar Oct 15 '18 21:10 GanShun

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

insomniacslk avatar Oct 15 '18 21:10 insomniacslk

@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 FindSignature to say "search anywhere, not just at offset 0 and offset 16";
  • add a CLI flag to call FindSignature appropriately.

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?

insomniacslk avatar Oct 15 '18 21:10 insomniacslk

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.

GanShun avatar Oct 15 '18 21:10 GanShun