macho是否可以不通过task_info获取到dyldImageLoadAddress?


#1

因为最近需要搞一个遍历所有动态库的功能

比如在 ELF 中可以通过 .got.plt 表的第二项拿到 link_map 的地址, 进而可以遍历所有的 so.

在 osx 中如果可以取到 dyld_all_image_infos 内容就可以遍历所有的 image, 这个结构体的地址存放在 dyld:Section64(__DATA, __all_image_info), 按理说如果可以拿到 dyld 的加载地址就可以, 但是我阅读了 xnu 和 dyld 的部分源码和很多参考资料, 好像没有把 dyld 的地址像ELF那样写到某个位置, 都是通过 task_info+TASK_DYLD_INFO 取得, 实在无奈只能过来求助, 感谢.


#2

第二个是link_map?不是说是libc的版本ID么?还有在full relro的情况下got2还有没有保存link_map?
最后一个问题是那个_dl_runtime_resolve()的第二个参数index到底是怎么标记的?该怎么偏移才能指向后面的段啊,(有测试过都传入了0x28,0x10等等,不符合.rel.plt的下标啊)


#3

@ch4r0n :new_moon_with_face:来来来,顺便解决下我的问题


#4

:smiling_imp:


#5

你是看了程序员自我修养那本书吧. 有些没有讲到.

我写了几篇文章

PWN之ELF符号动态解析过程.md

linux进程动态so注入.md

通过解析runtime的elf程序进行注入


#6

通过最近的研究, 自己对这个问题回答下吧, 关于这个对runtime的macho解析有几种方法.

1. task_info

2. vm_region 这个原理就是内核有个表记录了所有虚拟内存映射 用户层访问不到, 可以参考下面
http://stackoverflow.com/questions/10301542/getting-process-base-address-in-mac-osx

3. 部分暴力内存搜索, 根据虚拟内存页和xnu的aslr特点, 可以限定内存搜索范围, 其实和上面有些类似
https://github.com/jmpews/evilMACHO/tree/master/dumpRuntimeMacho

#7

感谢,那个书上介绍的确实不全,验证过确实是link_map_obj了。
问下重定位时的地址问题,我在这边怎么构造都跳不到我自己要解析的函数地址 。
已知我构造的f_relplt, f_dynsym, f_dynstr三个数据的地址,那么f_relplt中的r_info和f_dynsym中的st_name两个下标怎么计算呢?
这里是我的计算方式:
r_info = ((f_dymsymAddr - dymsymAddr)/0x10 << 0x8) | 0x7
st_name = f_dynstrAddr - dynstrAddr
(f_xxxAddr为伪造的数据地址,dynstrAddr等等为程序原段地址)


#8

你是希望在 _dl_fixup 时进行劫持么?

如果你想要在这个过程中劫持确实需要伪造 ElfW(Rel) 也就是你说的 f_relplt, 首先这段代码在 http://code.metager.de/source/xref/gnu/glibc/elf/dl-runtime.c#45, 我看的 glibc-2.23.

具体的实现我也没看到我只能说可能出现问题的点,1. f_relplt 只在第一次延迟加载该符号时才会使用 .plt -> .got.plt -> .plt -> _dl_runtime_resolve -> _dl_fixup 是这么个调用流程 2. f_relplt 的结构体, 低8位表示重定位入口类型为, 高24位表示在 .dynsym 中的下标, 你这么算没啥问题感觉, 建议你到 gdb 里看下.


#9

弄了半天,最后提示symbol lookup error……不弄了。
你有fully RELRO保护下dl_resolve劫持的资料没?
这种保护下所有重定位在程序刚加载时就完成了,只能修改栈中的link_map,但这个链表的地址怎么找呢?


#10

大佬有没有时间帮我看个exp啊,里面有段爆破got低位最后指向syscall获得shell的代码不明白。求大佬留个邮箱什么的交流交流:smile:


#11

weibo: http://www.weibo.com/winter1ife
mail: jmpews@gmail.com

这个链表的地址怎么找 我在上面文章写了哇 linux进程动态so注入:问题3


#12

恩 好 我看看


#13

已发到邮箱👌


#14

不一样的,我说的是full RELRO保护的情况下,got都不含link_map和dl_resolve指针,查过一些资料,都说只能从栈入手来还原出这两个指针


#16

恩 你这个是一个原型 有很多细节的问题, 比如从什么地址开始搜索?搜索范围是多少?怎么判断搜索的字符串不是偶然的?还有就是你现在是这个是对自身而言,对于其他 task 还需要搜索到程序的 load_address.

在上面我列举了几个方法,写了一个demo,但是感觉文件架构没写好.

最近重写了另外一个 rtspy-(runtime spy), 可以参考下


#17

哦, 你说其他进程
只搜索目标进程 PROT_READ | PROT_EXEC 的内存, 可不可以实现?


#18

你说的和这个有点类似 但是还是有那个问题 就是搜索起始位置和搜索范围 否则的话搜搜范围太大了


#19

翻山越岭来给zz评论,太牛批了。。先有zz后有天, zz赛过活神仙。


#20

先有zz后有天, zz赛过活神仙。