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

When parsing the path for an LC_RPATH, macholib should start at the str offset. #21

Open
ronaldoussoren opened this issue Mar 15, 2017 · 3 comments
Labels
bug Something isn't working minor

Comments

@ronaldoussoren
Copy link
Owner

Original report by Dwayne Yuen (Bitbucket: dwayneyuen, GitHub: dwayneyuen).


When parsing the string value for LC_RPATH, macholib should begin reading at the location specified by the offset. Instead, it appears that macholib simply reads from the end of second load command to the end of the entire command. If there are bytes between the cmd and the path, the result is that the path ends up containing incorrect bytes (and an incorrect length).

In my use case, this string eventually throws a unicode error when trying to serialize.

I am unfortunately not able to provide the binary sample that produces this error.

@ronaldoussoren
Copy link
Owner Author

Original comment by Ronald Oussoren (Bitbucket: ronaldoussoren, GitHub: ronaldoussoren).


Not having a binary sample is unfortunate, that makes it harder to fix the issue.

@ronaldoussoren
Copy link
Owner Author

Original comment by Ronald Oussoren (Bitbucket: ronaldoussoren, GitHub: ronaldoussoren).


Added function macholib.MachO.lc_str_value.

This should help in decoding value of macholib.mach_o.lc_str. Those
values are offsets in the data of a load command, the function will
return the actually value as a byte string.

See issue #21.

@ronaldoussoren
Copy link
Owner Author

Original comment by Ronald Oussoren (Bitbucket: ronaldoussoren, GitHub: ronaldoussoren).


Do you mean that the data in MachOHeader.commands is wrong? It is technically correct, although it is less useful than I'd like.

In particular, the rpath_command structure contains a field 'name' that contains the offset to the actual name, and the data int the MachOHeader.commands list contains the raw data including any "holes".

I've added a function "macholib.MachO.lc_str_value" that can return the actual bytes for an lc_str value, given the lc_str value and the item in MachOHeader.commands that contains the Structure containing the lc_str value. This will also strip NUL bytes from the end of the value.

For example:

for command in header.commands:
            if isinstance(command[1], dylib_command):
                print("dylib_command", lc_str_value(command[1].name, command))

This will print the shared library name for the dylib_command entries in the load commands of a MachOHeader instance.

The function was added in changeset 20a6a270e1bb

@ronaldoussoren ronaldoussoren added minor bug Something isn't working labels Jan 5, 2020
ronaldoussoren added a commit that referenced this issue Jan 5, 2020
This should help in decoding value of ``macholib.mach_o.lc_str``. Those
values are offsets in the data of a load command, the function will
return the actually value as a byte string.

See issue #21.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working minor
Projects
None yet
Development

No branches or pull requests

1 participant