我试图从Dyld_shared_cache中提取库,并需要修复外部引用。
例如,__DATA.__objc_selrefs部分中的指针通常指向mach-o文件之外的数据,以修复必须从dyld复制相应的c-字符串并将其附加到__TEXT.__objc_methname部分。
尽管根据我对Mach-O文件格式的理解,__TEXT.__objc_methname的这个扩展名将在它之后移动所有的部分,并迫使我修复引用它们的所有偏移量和指针。有没有一种在不破坏很多东西的情况下将数据添加到节中的方法?
谢谢!
发布于 2020-04-19 06:32:16
更新
在明确了__TEXT.__objc_methname的扩展将发生在对现有可执行文件的Mach-O后处理过程之后,我重新审视了这个问题。
另一个方法是创建一个新的load命令LC_SEGMENT_64,其中包含一个新的__TEXT_EXEC.__objc_methname段/节条目(通常__TEXT_EXEC用于某些内核内容,但本质上与__TEXT相同)。这里有一个快速的POC来稀释这个概念:
#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 __TEXT.__objc_methname**,(一直到高塞拉10.14.6 )才能在卡塔利纳岛上生成__TEXT.__objc_methname**,(没有任何踪迹),这是另一回事。
UPDATE2.
在玩这个游戏时,我注意到__TEXT段(以及__TEXT_EXEC )的执行权限对于__objc_methname来说并不是必需的。甚至不需要更好的特定段名和节名:
我可以成功:
__DATA.__objc_methname
__DATA_CONST.__objc_methname
__ARBITRARY.__arbitrary 或者在我的例子中,上一节__DATA
__DATA.__objc_classrefs,其中原始数据由选择器名称连接。只要有一个带有选择器名称的正确的以空结尾的C-字符串,这一切都很好。如果我故意破坏十六进制编辑器或MachOView中的"new\0“,我将得到
"+[NSObject ne]: unrecognized selector sent to instance ..."在启动我的POC可执行文件时,可以肯定地使用该值。
因此,要对__TEXT.__objc_methname节本身进行求和,很可能是链接器所做的一些调试器提示。应用程序运行时似乎只需要选择器名,就像内存中任何地方的char*一样。
https://stackoverflow.com/questions/61293156
复制相似问题