ptrace向entry point进程注入shellcode，替换power的文件为sh，2起遍历pid杀掉sleep让sh执行shellcode，再次连接题目就能拿到shell。

开沙箱之后读0x1000个字节的shellcode，然后直接call过去
call之前不动任何寄存器，可以说非常友好了

dump一下沙箱的规则：

只允许read, wait4, ptrace

目标是读flag，但程序自身现在不能open和write，也不能fork一个进程出来
ptrace很强大，可以杀进程也可以读写进程内存和寄存器。
如果我们的shellcode太长，可以考虑用read二次延申。

题目开了ptrace，在运行容器的时候也给了docker强大的 CAP_SYS_PTRACE 权限，此时：

但是本题目环境不存在这两个问题

（后记中还讨论了用prtace在另一种特定情况下竞争绕过seccomp的可能）

注意本题的power虽然在chroot环境中，但还是作为root运行的，理论可以trace容器内的任意进程。那我们可以随意trace一个其他不受seccomp限制的进程，然后向其注入shellcode就可以摆脱seccomp和chroot了。

这里的shellcode就很自由了，可以是：
将power替换为sh，再次连接时候执行的power就会直接生成shell，注意在shellcode结尾加上循环，不然entrypoint执行结束容器就会退出，环境销毁。

容器中的进程有：

自己不能ptrace自己，xinted可以留给后续连接用，那就可以有以下思路：

生成第二段shellcode（注入sh执行的shellcode）：

生成第一段shellcode（发给程序的）：

然后编译一下：
gcc pwn.c --static -nostdlib -o pwn
直接dump生成二进制的text段即可，最后加上jmp到main的两字节就是最终exp了

这种解法10分钟内会有被蹭车的可能，而且因为拿到了无限制的容器内最高权限，打通之后可以删改flag也可以抓别人流量（）不知道是不是预期解

版主回复说在预期内，可以打通之后删flag防蹭车

然而远程环境其实是出网的，拿到本地shell之后显然有更优雅的做法QAQ

因为某些原因手写了长度和字符集受限的计算md5的shellcode之后就再也不想手写shellcode了，好在这题对shellcode本身没什么限制，可以自动生成，非常友好：

已知ptrace可以做的三件好事：

此外，非root用户在ptrace_scope=0时，也有机会逃逸seccomp （来自@cnitlrt和v3rdant.cn）

root用户可以随意trace其他进程，而非root用户只能trace自己的子进程。
然而，如果/proc/sys/kernel/yama/ptrace_scope设置为0，非root用户就能trace本用户的所有进程。

题目环境中pid比较稳定，几乎可以假设下一个次连接时的pid一定是本次连接+1，那么我们可以：

虽然有失败的可能，如果能在第二次连接启动的power进程执行prctl调用前附加上，我们就可以：

然而，docker中的/proc/sys/kernel/yama/ptrace_scope随宿主机的设置，在题目环境中，该值为1。所以如果本题的power不是以root运行的，该方法也不能用来解决本题。

作者刚学Linux的小菜鸡一枚，感谢师傅们读到这里，文中如有谬误还请评论指正

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！