avatar

目录
Memory_Monster_IV 姿势点分析

Memory Monster IV

这题其实是五月BJD3rd出多的一道题,正好六月nepnep承办安恒月赛,于是就放出来啦。Memory Monster系列主要都是考察对任意写的利用,大概没有后续题目了叭完结撒花

这题需要耐心调试才能做出来,下面就分析一下所有出现的考点叭~

0x0: 动态库的加载

现在大部分程序都是通过链接器ld进行动态链接的,程序的动态库可以通过lld命令查看:

c
1
2
3
4
5
6
% ldd Memory_Monster_IV 
linux-vdso.so.1 (0x00007ffdffbc4000)
librand.so => not found
libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007fde9b5a2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fde9b3b1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fde9b614000)

这里librand.so是自定义的库,操作系统中没有,所以需要改一下环境变量才能正常启动程序:

shell
1
2
3
% env LD_LIBRARY_PATH=./ ./Memory_Monster_IV
# banner
�(LG�index:

程序启动时会在环境变量中的动态库路径下寻找程序需要加载的动态库

同理,调试的时候可以:

shell
1
% env LD_LIBRARY_PATH=./ gdb ./Memory_Monster_IV

0x1: ASLR的随机化粒度

题目是开启了ASLR保护的,并且程序在打印banner之后就泄漏了execve的地址:

c
1
2
3
v2 = rand() & 0xFFF ^ &execve;
write(1LL, &banner, 7478LL);
write(1LL, &v2, 8LL);

虽然这里泄漏出的地址后三位是随机的,但是基本上可以忽略。因为目前操作系统默认开启的ASLR保护是粗粒度的(为了节省资源),并不会把地址随机得面目全非,下面是三次随机化出的libc基址:

Code
1
2
3
0x00007fe101978000
0x00007f802ae9c000
0x00007f119a00b000

可以看出被随机化的只有地址中间的7位,后面的3位并不会变,这也是为什么可以根据后3位的值反查出libc版本的原因(libc database)

对于这题而言,查出libc中execve函数地址的后3位然后还原即可

0x2: 一字节任意写改GOT表

这个是主要考点,对于能够多次修改,并且一次只能修改一字节的情况,最好的做法就是让修改的次数尽可能的少。

对于这题而言可以选择将writeGOT表改为与其地址最相似的one gadget地址

虽然能找到相似的地址,但是还是至少需要修改两次。这时就要考虑第一次的修改不能影响程序后续的正常运行,也就是说第一次修改后的GOT表中的函数得是个”nop函数”,什么操作都不要有,能直接ret是最好的。

对于这题而言,调试的时候微调一下地址就可以找到nop函数,调试一下自行体会吧

0x3: 标准输出重定向

攻击过程中会意外的调用close(1)关闭标准输出,这时需要对标准输出进行重定向,例如通过如下命令把stdout重定向到stderr

shell
1
exec 1>&2
文章作者: TaQini
文章链接: http://taqini.space/2020/06/26/DASCTF-June-Memory-Monster-IV-200pt/
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 TaQini
打赏
  • Wechat
    Wechat
  • Alipay
    Alipay

评论