ОБНОВЛЕНИЕ
После выяснения с помощью OP, что расширение __TEXT.__objc_methname
произойдет во время последующей обработки Mach-O существующего исполняемого файла, у меня был свободный sh взгляд на проблему.
Другим вариантом будет создание новой команды загрузки LC_SEGMENT_64
с новой __TEXT_EXEC.__objc_methname
записью сегмента / раздела (обычно __TEXT_EXEC
используется для некоторых вещей ядра, но по сути это то же самое, что __TEXT
). Вот краткое ПО C, чтобы проиллюстрировать концепцию:
#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
@autoreleasepool {
printf("%lx",[NSObject new]);
}
return 0;
}
Компилировать так:
gcc main.m -c -o main.o
ld main.o -rename_section __TEXT __objc_methname __TEXT_EXEC __objc_methname -lobjc -lc
Интересно, что только ld
до Высокой Сьерры 10.14.6 генерирует __TEXT.__objc_methname
, на Каталине нет никаких следов, все сделано по-другому.
UPDATE2 .
Играя с этим, я заметил права на выполнение для сегмента __TEXT
( и __TEXT_EXEC
в этом отношении) не требуются для __objc_methname
для работы. Более того, c имена сегментов и разделов не требуются:
Я мог бы выполнить:
__DATA.__objc_methname
__DATA_CONST.__objc_methname
__ARBITRARY.__arbitrary
или, в моем случае, последний __DATA
раздел
__DATA.__objc_classrefs
, где оригинал данные объединяются по имени селектора. Все в порядке, пока есть правильная строка с нулевым символом C с именем селектора. Если я намеренно сломаю «new \ 0» в шестнадцатеричном редакторе или MachOView, я получу
"+[NSObject ne]: unrecognized selector sent to instance ..."
при запуске моего исполняемого файла PO C, так что значение будет использовано наверняка.
Таким образом, для суммирования __TEXT.__objc_methname
самого раздела, скорее всего, есть подсказка отладчика, сделанная компоновщиком. Кажется, во время выполнения приложения нужны только имена селекторов в виде char*
в любом месте памяти.