-
Notifications
You must be signed in to change notification settings - Fork 19
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
Comments
Original comment by Ronald Oussoren (Bitbucket: ronaldoussoren, GitHub: ronaldoussoren). Not having a binary sample is unfortunate, that makes it harder to fix the issue. |
Original comment by Ronald Oussoren (Bitbucket: ronaldoussoren, GitHub: ronaldoussoren). Added function This should help in decoding value of See issue #21. |
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:
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 |
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.
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.
The text was updated successfully, but these errors were encountered: