objective-c – 以编程方式确定在另一个进程中加载​​了哪些模块? (OS X)

objective-c – 以编程方式确定在另一个进程中加载​​了哪些模块? (OS X),第1张

概述我想要做的事情我觉得非常简单,我只是不确定该怎么做. 具体来说,我只想获得在另一个进程中加载​​的模块列表(共享/动态库).以及获取该模块在给定进程中的起始地址. 通过GDB获取此信息非常简单.您只需连接到该流程,然后键入“info shared”.这是我想要的确切信息类型.如: Num Basename Type Address Reason | | Source | | | | | | | | 我想要做的事情我觉得非常简单,我只是不确定该怎么做.

具体来说,我只想获得在另一个进程中加载​​的模块列表(共享/动态库).以及获取该模块在给定进程中的起始地址.

通过GDB获取此信息非常简单.您只需连接到该流程,然后键入“info shared”.这是我想要的确切信息类型.如:

Num Basename
Type Address Reason | | Source
| |
| | | | | |
1 Adium
– 0x1000 exec Y Y /Applications/Adium.app/Contents/MacOS/Adium
(offset 0x0) 2 dyld
– 0x8fe00000 dyld Y Y /usr/lib/dyld at 0x8fe00000 (offset
0x0) with prefix “__dyld_” 3 WebCore
F 0x95b6a000 dyld Y Y
/System/library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore
at 0x95b6a000 (offset 0x95b6a000)

有谁知道如何以编程方式执行此 *** 作?显然模块负载是动态的,所以我需要确定它的位置.

解决方法 首先使用task_for_pID()来获取任务端口.

然后使用task_info找到“dyld所有图像信息地址”:

struct task_dyld_info dyld_info;mach_msg_type_number_t count = TASK_DYLD_INFO_COUNT;if (task_info(task,TASK_DYLD_INFO,(task_info_t)&dyld_info,&count) == KERN_SUCCESS){    // retrIEve dyld_info.all_image_info_addr;}

该地址将指向内存中的struct dyld_all_image_infos:

struct dyld_all_image_infos {    uint32_t version;    uint32_t infoArrayCount;    const struct dyld_image_info* infoArray;    // ...}

infoArrayCount和infoArray条目在这里很重要.您必须检索这些值(使用mach_vm_read)并遍历infoArray.每个条目都是struct dyld_image_info:

struct dyld_image_info {    const struct mach_header* imageLoadAddress;    const char* imagefilePath;    uintptr_t imagefileModDate;};

在此结构中,您有兴趣检索imageLoadAddress(内存中库的地址)和imagefilePath(内存中以NulL终止的文件路径的地址)的值.

重要说明:上面结构中标记为指针或uintptr_t的字段具有不同的字节大小,具体取决于正在运行的进程是32位还是64位.您可以通过查看dyld_info.all_image_info_format是否为TASK_DYLD_ALL_IMAGE_INFO_32或TASK_DYLD_ALL_IMAGE_INFO_64(应该可以工作,但我自己没有对此进行测试)来确定指针大小.

最后,这仍然不包括动态链接器本身的条目.要检索它,我发现的一种方法是遍历vm区域(即mach_vm_region),找到第一个看起来像是一个马赫音色的区域(检查MH_DYlinkER作为文件类型;参见mach-o文件格式了解更多信息).最后我记得检查,gdb和/或lldb也有这样做的功能.解析mach头也是判断进程是32位还是64位的一种可能方法.

检索所有dyld图像信息条目后,您可能还希望按地址对它们进行排序.

我建议不要查看newosxbook的vmmap实现代码.它已经过时了(因为它仍然使用DYLD_ALL_IMAGE_INFOS_OFFSET_OFFSET),它会做一些不必要的暴力破解.

总结

以上是内存溢出为你收集整理的objective-c – 以编程方式确定在另一个进程中加载​​了哪些模块? (OS X)全部内容,希望文章能够帮你解决objective-c – 以编程方式确定在另一个进程中加载​​了哪些模块? (OS X)所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址:https://www.54852.com/web/1068672.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2022-05-26
下一篇2022-05-26

发表评论

登录后才能评论

评论列表(0条)

    保存