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

Parsing Mach-O from a file object is broken #1113

Closed
nneonneo opened this issue Oct 6, 2024 · 1 comment
Closed

Parsing Mach-O from a file object is broken #1113

nneonneo opened this issue Oct 6, 2024 · 1 comment
Assignees

Comments

@nneonneo
Copy link

nneonneo commented Oct 6, 2024

Describe the bug
With the Python bindings, using either lief.parse or lief.MachO.parse to parse file objects (as opposed to filenames) results in incorrect parse results.

To Reproduce
Steps to reproduce the behavior:

  1. Download and unpack bugtest.so.zip
  2. Run the following script in the same directory:
import lief
print("lief.parse by filename:")
print(lief.parse("bugtest.so"))
print("lief.parse by object:")
print(lief.parse(open("bugtest.so", "rb")))
print("lief.MachO.parse by object:")
print(lief.MachO.parse(open("bugtest.so", "rb")))

Expected behavior
These three parses should produce identical outputs.

Observed behavior
The three parses produce wildly different results: logs.zip.

  • lief.parse(filename) produces a reasonable-looking parse of the file.
  • lief.parse(fileobj) produces a total mess: 4096 Unknown architecture messages, followed by a header that indicates 4096 commands, followed by one UNIXTHREAD command and 4095 THREAD commands which all have flavor=0x65745f5f, count=0x7478, pc=0x000000. In short: a completely broken parse, as if it's failing to properly advance the file pointer while reading the file.
  • lief.MachO.parse(fileobj) produces almost the same output as lief.parse(filename), except that the Binding Info and Export Info are missing from the DYLD_INFO_ONLY command. Unfortunately, the bindings are simply not parsed at all (bin.dyld_info.bindings is empty).

Environment:

  • macOS 14.6.1 (Intel), Python 3.10.11, lief 0.15.1
  • Tested in a virtual environment with only lief installed
  • Also tested with lief 0.16.0-ba294bd1, bug exists there too
  • Have verified that the bug is not apparently present with ELF or PE (haven't tested in depth though).
@romainthomas
Copy link
Member

Thank you for reporting @nneonneo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants