ZIKH26's Blog

前言

很久没发过 CTF 的 writeup 了，水一篇 CTF-IOT 的。前几天被学弟喊着看了一道西湖论剑的 IOT 题目，做题的时候忘记看 ASLR 等级了。因此被一个虚假的地址随机化困扰了许久……没有地址随机化之后果然通畅多了🫡。

前言

前几天在看雪上读了一篇关于 C++异常处理 的文章，写的通俗易懂，文章开始通过 demo 介绍了 try-catch 异常处理机制绕过 canary 检查。闲来无事也跟着 demo 做了一下，发现作者在原文中写到：

这里将返回地址填充成了 backdoor() 函数里 try 代码块里的地址，它是一个范围，经测试能够成功利用的是一个左开右不确定的区间（x）

看到这里我不禁疑惑，这种简单的利用中也会存在 玄学 无法确定的东西吗？我对这个左开右不确定区间感到好奇，打算去研究一下，这个成功利用的区间到底是如何来的。

本文从 gcc 源码入手，去探究区间问题。随后还分析了 try-catch 异常处理机制中源代码是如何完成 栈展开(Stack Unwinding) 的（本文为了避免出现过多非关键代码😶‍🌫️，因此删减了一些代码。但阅读中最好同时参考 gcc 源码，否则理解上可能有一些障碍）。

前言

这篇文章大概是 24 年四月写的，也是老笔记了。当初因为一些原因没有发，现在 CTF 打的越来越少，已经渐渐淡出了竞赛。这些笔记也分享出来（虽然真的很水🥹），让有需要的师傅有个参考（太菜勿喷😭）…

一直很好奇 AWD-PWN 如何出，但困难在于 check 脚本的编写。网上这方面的资料很少，就一直鸽了😶‍🌫️ 。最近因为要校内自己玩 AWD ，于是专门花时间去研究了一下。发现了 Q1IQ 师傅在 github 上开源了 AWD-PWN-Checker ，于是抱着学习的心态阅读了整个代码。在受益匪浅的同时，又在原基础上增加了一些功能… 下面是对这次 AWD-PWN 出题过程进行的记录😎

这次 AWD-PWN 的题目部署主要参考了两个开源项目 Cardinal AWD-PWN-Checker

平台部分的部署是由我同学 Timochan 完成，我只负责了漏洞程序的编写、 check 脚本的编写、以及 exp 的编写 。

前言

又是从之前文档里面扒出来的一个总结，再来水一篇博客。这篇应该写的非常早了，大概是 23 年 7 月写的，当时还在卷 glibc堆，对这个 obstack 的链子印象挺深的。

house of obstack 是目前网上较多的叫法，它由国外 repr 提出，由于不确定作者给它起的名字到底是什么，姑且称它为 house of obstack。它与 house of apple 相似，主要是触发的调用链变了，但思想不变。相较于 house of apple 的优点是在 glibc2.36 依然可以使用并且布置起来更简单一些。

前言

这篇文章也是好几个月之前写的了，当时因为忙了其他事情，一直没有整理发布，刚才无意中看到了以前的草稿，就索性发一下。Qiling 这个框架对于模拟运行二进制程序时的 hook 非常方便，可以很细致的获取或修改某个时刻的内存值，学习了该框架，可以后续在此基础上开发一些小工具。

其实网上关于 qiling-lab 资料已经非常多了，自学起来已经没有什么难度。本文也是照猫画虎完成了 qiling-lab 的 11 个挑战，并没有做其他的延伸学习，更多的记录是自己在学习过程时踩过的坑和一些思考。

前言

这篇关于 Windows Pwn 入门的草稿应该是在 24 年初的时候写的，当时忘记因为什么原因搁置了。时间转眼已经到了 24 年底，这一年经历了挺多意料之外的事情，所以感觉时间过的飞快。今天整理了一下之前写的草稿，算是再水一篇博客。

在 Linux 下的二进制漏洞利用已经较为熟悉的情况下，打算去了解一下 Windows 下的 PWN 。当时本意是希望在大三结束找实习时，可以对 Windows 平台的二进制方面漏洞利用有更多了解，但回过头来看，其实也没用上🥲。

前言

博客很久没有更新了，其实也写了很多 IOT 研究的文章，但因为保密不能公开。而本文写的是最近几天在搭建 QEMU 下 ARM Linux 运行环境的过程，这方面网上的文章比较多，没有什么保密性可言。

本文记录了交叉编译 Linux 内核、BusyBox 以及制作虚拟存储介质的过程。旨在根据不同设备的内核版本，搭建出一套匹配内核版本的 QEMU 仿真环境。之前研究几款路由器设备都是 2.6x 版本的 ARM 内核。使用 18.04 上安装的交叉编译工具链去编译的程序，在这种 2.6x 老内核中运行会报错 kernel too old。如果想编译一套相应的研究工具（如 gdbserver、ptrace、ltrace、小型反弹木马等等）会很麻烦，包括一些测试场景，可能会因为内核版本差异较大，产生一些异常。

因为网上有很多相关文章（大部分都是搞嵌入式的老哥写的），本文只是对自己学习这部分做一个记录和总结，帮助自己之后可以根据不同的研究需求去搭建特定环境。之前搞 IOT 仿真的时候，用的都是这个 编译好的配套环境，看完本文后，应该就能自己搞一套 QEMU 环境了😋。

本文记录了下面部分内容。

1. 配置交叉编译环境
2. 交叉编译 ARM Linux 4.1x 内核
3. 交叉编译 busybox
4. 构建磁盘文件镜像
5. 将 01-03 的产物成功用 QEMU 运行起虚拟机
6. 实现 QEMU 虚拟机的网络通信

前言

这是我收获的第一个 CVE 编号，在复现了 winmt 师傅的 CVE-2023-34644 后，他告诉我最新的固件虽然做了一些简单的处理，导致无法在未授权的情况下 RCE ，但因为没有从根源上对命令执行点做限制，所以在授权后，仍然可以进行 RCE 。我对最新的固件进行了分析，完整记录了授权后的 RCE 漏洞从分析到利用的过程。从提交漏洞到现在也有半年的时间了，并且锐捷官网也已经发布了最新的固件，现将该文章分享出来，供大家进行学习和研究。

已经配置好的环境：下载链接 (使用方法：先执行 net.sh 再运行 start.sh 即可)

参考文章：Building a Debian Bullseye QEMU image for AARCH64 | diozero

大概思路：先下载安装程序的基本文件，联网安装完之后从磁盘文件中提取出需要的 initrd.img 和 vmlinuz 文件。 QEMU 依赖提取的文件构建出 aarch64 环境。

前言

这是一道来自于 第六届强网拟态线下赛 有趣的 PWN 题，考察的是格式化字符串漏洞。我自认为格式化字符串的题目已经很熟练了，可在我的印象中格式化字符串漏洞无法一次向一个不存在的指针中写入数据，这道题颠覆了我的认知🥲。保护全开，只有一次 非栈上 格式化字符串漏洞利用的机会，之后触发 _exit 函数退出，唯一的信息是有栈地址末尾的两个字节。这可能是格式化字符串能利用的极限条件？！😶‍🌫️