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

More options for LIEF::PE::ParserConfig #1150

Open
Ch40zz opened this issue Jan 4, 2025 · 0 comments
Open

More options for LIEF::PE::ParserConfig #1150

Ch40zz opened this issue Jan 4, 2025 · 0 comments

Comments

@Ch40zz
Copy link

Ch40zz commented Jan 4, 2025

I'm trying to use LIEF to parse PE Headers in memory, only supplying the first 0x1000 bytes as the rest of the data is not required.
LIEF does not allow me to only call parse_headers() manually as the function is private, so I tried to use the public LIEF::PE::Parser::parse() function and I noted a bunch of issues here:

  1. LIEF::PE::Parser::parse() only takes a std::vector<uint8_t> data and creates a copy, not by reference like all the other parsers
  2. When parsing a 0x1000 bytes PE header, even when disabling all options in LIEF::PE::ParserConfig it logs many warnings and even an error, although the header was parsed just fine and a valid LIEF::PE::Binary object was returned. The logged error is Can't read the padding content of section '.text' naturally as .text is the first section.

Given these issues I think a nice feature would be allowing to parse only the header and disabling all other parsing by adding more options to LIEF::PE::ParserConfig such that only parse_headers() will be executed. No errors should be printed when a valid object is returned from LIEF::PE::Parser::parse(). Data passed to parse() should never be copied in the first API invocation, only when necessary.

I also think it would be nice to somehow return the internal errorcodes to the user instead of letting the user rely on the logging. The parse() function currently gives absolutely no insight into why the parsing failed. It should probably return ok_error_t containing the binary object.

Thanks a lot for this project!

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