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

Support arbitrary data at the beginning of the file? #200

Open
insomniacslk opened this issue Oct 15, 2018 · 5 comments
Open

Support arbitrary data at the beginning of the file? #200

insomniacslk opened this issue Oct 15, 2018 · 5 comments
Assignees
Labels
question Further information is requested

Comments

@insomniacslk
Copy link
Collaborator

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 insomniacslk added the question Further information is requested label Oct 15, 2018
@rjoleary
Copy link
Member

I like this idea.

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

@GanShun
Copy link
Member

GanShun commented Oct 15, 2018

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?

@insomniacslk
Copy link
Collaborator Author

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
Copy link
Collaborator Author

@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?

@GanShun
Copy link
Member

GanShun commented Oct 15, 2018

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.

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

No branches or pull requests

3 participants