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 permissive parsing of unknown load commands #93

Closed
woodruffw opened this issue Jun 6, 2018 · 2 comments · Fixed by #107
Closed

More permissive parsing of unknown load commands #93

woodruffw opened this issue Jun 6, 2018 · 2 comments · Fixed by #107

Comments

@woodruffw
Copy link
Member

ruby-macho currently throws an exception (LoadCommandError) when it can't resolve a load command type to a class.

To prevent the future addition of load commands by Apple from fouling up the parser, we could allow the user to toggle more permissive behavior:

  • If the load command ID corresponds to a known class, instantiate that class
  • If the load command doesn't correspond to a known class, instantiate the generic LoadCommand class

We already hard-code this behavior for LC_PREPAGE, since Apple doesn't provide a public structure for it. This behavior could be made generic fairly easily.

@woodruffw
Copy link
Member Author

A potential problem: it's not really clear where to draw the line for permissive parsing -- there are lots of other little fields in a Mach-O binary that could be wrong but non-fatal (like cputype and cpusubtype). Thus, the permissive parser option needs to be opinionated: do unknown CPU types and header flag combinations cause an exception, while unknown load commands get a pass?

@woodruffw
Copy link
Member Author

Decided to go with just permissive load command parsing for now (non-default, the default remains strict) -- making other fields permissive is likely to lead to lots of problems.

woodruffw added a commit that referenced this issue Oct 8, 2018
* macho: Permissive load command parsing

Closes #93.

* test: Add permissive LC test
@lock lock bot added the outdated label Jan 1, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Jan 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant