mach-o

问题 I wrote the below program to iterate over all images in memory and dump their string tables. #include <mach-o/dyld.h> #include <stdio.h> #include <string.h> int main(int argc, char** argv) { uint32_t count = _dyld_image_count(); for (uint32_t i = 0 ; i < count ; i++) { const char* imageName = _dyld_get_image_name(i); printf("IMAGE[%u]=%s\n", i, imageName); const struct mach_header* header = _dyld_get_image_header(i); if (header->magic != MH_MAGIC_64) continue; struct mach_header_64* header64

问题 I'm having a hard time understanding the absolute path that a @loader_path within a file refers to. user@local:~$ otool -L zlib.so zlib.so: @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) I want to know where the system looks to find libz.1.dylib. From some Mac documentation: @loader_path/ This

问题 I'm having a hard time understanding the absolute path that a @loader_path within a file refers to. user@local:~$ otool -L zlib.so zlib.so: @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) I want to know where the system looks to find libz.1.dylib. From some Mac documentation: @loader_path/ This

问题 I'm having a hard time understanding the absolute path that a @loader_path within a file refers to. user@local:~$ otool -L zlib.so zlib.so: @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) I want to know where the system looks to find libz.1.dylib. From some Mac documentation: @loader_path/ This

问题 I'm having a hard time understanding the absolute path that a @loader_path within a file refers to. user@local:~$ otool -L zlib.so zlib.so: @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) I want to know where the system looks to find libz.1.dylib. From some Mac documentation: @loader_path/ This

问题 Today I first encountered the fishhook library https://github.com/facebook/fishhook which can be used to dynamically rebind symbols in Mach-O binaries (they say for iOS, but I guess the code will also work on OS X). So far I only knew and used mach_override https://github.com/rentzsch/mach_override which aims at a similar goal (i.e. replacing one implementation of a function with another one), but rewrites the assembler statements of the beginning of the function to jump to a different

问题 Today I first encountered the fishhook library https://github.com/facebook/fishhook which can be used to dynamically rebind symbols in Mach-O binaries (they say for iOS, but I guess the code will also work on OS X). So far I only knew and used mach_override https://github.com/rentzsch/mach_override which aims at a similar goal (i.e. replacing one implementation of a function with another one), but rewrites the assembler statements of the beginning of the function to jump to a different

问题 I have a dylib and in order for the it to be able to run on my machine, I had to disable library validation in the target settings on xcode. Is it possible to get it signed without a paid developer account just for testing purposes? Any links or tutorials on how to go about doing that would help a great deal. 回答1: Depends on how you're getting the library. Building in Xcode If building in Xcode, you should be able to enable signing and tell it to use Team None and Sign to Run Locally all in

问题 Parsing an already-loaded Mach-O binary in memory... Sometimes the string table, symbol table, etc, are where they should be, and sometimes they're 0x1000 off. For example, I might run my program and baseOffset + cmd->symoff is accurate. Then I'll unit test and baseOffset + cmd->symoff + 0x1000 is accurate. baseOffset is always valid and pointing to a valid Mach header. 回答1: I figured it out by looking at dyld source code... It's not guarenteed to be 0x1000 off, however, the link edit offset

问题 Parsing an already-loaded Mach-O binary in memory... Sometimes the string table, symbol table, etc, are where they should be, and sometimes they're 0x1000 off. For example, I might run my program and baseOffset + cmd->symoff is accurate. Then I'll unit test and baseOffset + cmd->symoff + 0x1000 is accurate. baseOffset is always valid and pointing to a valid Mach header. 回答1: I figured it out by looking at dyld source code... It's not guarenteed to be 0x1000 off, however, the link edit offset