前文
一
我们首先把kaslr关掉
方便我们调试
#! /bin/sh
qemu-system-x86_64 \
-m 256M \
-nographic \
-kernel bzImage \
-append 'console=ttyS0 loglevel=3 oops=panic panic=1 nokaslr' \
-monitor /dev/null \
-initrd initramfs.cpio \
-smp cores=4,threads=2 \
-gdb tcp::2222 \
-cpu qemu64,smep,smap
关闭kaslr之后kernal_base的地址每次都是0xffffffff81000000
我们还要稍微改一下init脚本
让他权限是root
且每次直接拿出地址来
方便我们使用
#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs none /dev
insmod hackme.ko
chmod 777 /dev/hackme
cat /sys/module/hackme/sections/.text
cat /proc/kallsyms |grep _text
setsid /bin/cttyhack setuidgid 0 /bin/sh
echo 'sh end!\n'
umount /proc
umount /sys
然后效果就是这样
看得出来基地址是0xffffffff81000000
然后又是一套
当然我们还是要用有符号表的vmlinux
有符号便的vmlinux去哪找
只能自己编译
之前有研究
编译带符号表的linux内核
之前说过调内核题目会驱动挂不上
但是我们现在不挂驱动
那怕啥 用不完了
可以看到在关闭kaslr的情况下因为地址没有随机 gdb导入的函数表也能起作用了。
我们如果想更方便的调试
可以直接导入源码
用dir命令
就是
dir 源码根目录
就会有这种效果
非常好用。
通过我们对上面代码的分析
感觉pty_init没啥研究的，就是初始化
我们的ptmx初始化也没问题
只不过是文件打不开嘛
那我们就直接在ptmx_open函数下断点。
然后还是之前的脚本跑起来
让他尝试打开/dev/ptmx文件
int ptmx_fd = open("/dev/ptmx",0);
if (ptmx_fd < 0)
errExit("[-] bad open /dev/ptmx");
一路跟发现问题出在这里
devpts_acquire函数
它返回给我了一个-2
想想好像前面说过的那个错误号是2
估计是有点联系
跟进去看看
看源码
里面会报错的核心就是说找不到pts文件系统
可以看到进去之后直接就错了就出来了。返回值是-2 当然是32位返回值。
关于devpts跑去搜了一下
他说如果有pts条目并且该条目是devpts文件系统 就使用该系统
我就跑去dev文件夹看了一下 确实它没有pts文件夹
非常可恶
那就考虑需要去调一下pty_init
看看它为啥没给我pts文件系统。
但是pty_init系统初始化的时候就跑过了
所以首先要解决如何能调的上pty_init这个问题…
就方法也很简单
先gdb载入符号表，然后
下断点直接尝试连接端口
然后启动就行。
然后就有了。
调半天
很流畅
一点问题没有
……
我们再次检查思路
首先确定我们有devpty文件系统嘛？
cat /proc/filesystems
这个命令看一眼
有…
那挂载上了嘛？
我们掏出我们的init脚本看一眼
#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs none /dev
insmod /hackme.ko
chmod 777 /dev/hackme
#cat /sys/module/hackme/sections/.text
#cat /proc/kallsyms |grep _text
setsid /bin/cttyhack setuidgid 0 /bin/sh
echo 'sh end!\n'
umount /proc
umount /sys
好像没有……
把这两句话填init脚本里挂载一下试试…
mkdir -p /dev/pts
mount -vt devpts -o gid=4,mode=620 none /dev/pts
成了…… 大无语……
