最近做了一道国际赛SEKAI的取证题, 题目使用LiME对内核为5.15.0-43-generic的Ubuntu制作内存镜像, 需要自行制作Symbols 进行分析. 出题人让我们自行探索新版Linux内核下的取证策略. 尽管官方Volatility2提供制作profile和Volatility3提供制作Symbols的方案, 但在实际应用中, 均出现较多目前互联网尚未解决的问题. (具体详见GitHub关于Volatility的Issues.). 下文主要内容是基于官方文档、题目、实操步骤, 提供在新版Linux下的制作Symbols的解决方案.

从今年4月份开始，慢慢接触高版本的glibc，高版本glibc的堆题也使得国内ctf比赛进入到一个新的时期

本篇通过对 DownUnder CTF 2022 中一道题的讲解来介绍一种比较 trick 的通过侧信道读取文件内容的方法。

好久以前，在我完成 Glibc2.23 的基本堆利用学习以后，IO_FILE 的利用就被提上日程了，但苦于各种各样的麻烦因素，时至今日，我才终于动笔开始学习这种利用技巧，实属惭愧。

近几年，由于堆利用的条件越来越苛刻，加之几个常用的劫持 hook 被删除，IO 的地位逐渐有超过堆利用的趋势，因此为了跟上这几年的新潮，赶紧回来学习一下 IO 流的利用技巧。

在前段时间的网鼎杯某赛道中遇到了一个题，通过混淆的go源码分析各类函数调用、定义信息。但由于题目本身要求获得的信息过于简单，有不少人直接暴力搜索来解决。但当我们遇到更为复杂，更为巨大的混淆代码时，IDE所提供的简单分析功能也就无能为力了。这也就是我写下这篇文章的原因。

codeql是一款强大的静态扫描工具，通过codeql强大的自定义规则我们可以编写sql语句来搜索源码中我们可能感兴趣的代码。ctf中高版本libc的利用方法中很多都用利用了IO函数，即利用stdin/stdout/stderr->vtable 修改虚表指针指向对我们有用的伪造的vtable又或者其他存在可利用函数的_IO_xxx_jumps虚表，如：house_of_kiwi,因此我便诞生了使用codeql查找libc中所有跳转到IO的函数调用的想法，更方便的分析libc中的利用点，也看看能不能找出house_of_kiwi中使用的malloc_assert->fflush利用点。

前段时间2022虎符决赛结束，赛后从学长那看到了题目，其中出现了一道PowerPC64架构的pwn题，从架构方面来说比较少见，刚好之前看过一道PowerPC架构32位栈溢出的题目，于是放到一起整理一下。

之前周末忙着强网杯，对这道题只做了一半就搁置下来了，最后卡在绕过最新pebble模板引擎RCE那里，今天抽空来继续进行剩下的分析，正好题目里有几个在现实场景当中能用的trick顺便也分享了

这题名为 Loader，其本质也是从 .data 段中加载了程序的主要逻辑并运行，使用了无文件 PE 文件加载的相关技术。

因为这道题没加反调试等 check，所以比赛时我只是略扫了一下 load 的部分，主要精力都放在关键逻辑上了。但其实这题 loader 部分的 assembly 写得很有意思，于是赛后我又着重分析了一下相关部分的代码。

SSRF之前只有简单了解，进行二次学习后简单总结一下，希望能对正在学习SSRF的师傅们有所帮助

这题是 GLIBC 2.27-3ubuntu1.5 的版本，想着 2.27 可以直接 free 两次，但是这个 2.27-3ubuntu1.5 patch 了 double free，还加了 key，double_free 就没那么好搞，所以这题我用的是任意写 free_hook 为 system 进行getshell

很新颖的一道题目，比赛时花了将近一整天的时间做了出来（没抢到血 qaq，带哥们太猛了）。虽然 XCTF 的分站赛主办方都会公布 writeup，但还是很想记录并顺手分享一下我自己在解这道题目时的整个思考过程。尤其是这几年 CTF 中逆向方向其实已经把

.pyd 文件本质上是一个包含 Python 代码的库文件，可以被其他 Python 应用程序调用和使用。 通过使用Cython编译器，可以快速得把python文件打包为一个动态链接库，这个动态链接库也就是pyd。pyd相较于python源码本身可读性大大下降，很多人处于类似混淆得目的，也会使用这种形式对python代码进行保护

这里的rwctf_station-escape的主要基于长亭师傅在知乎的文章进行，在此基础上进行了比较详细的exp分析和调试

本文介绍了off by null的爆破法和直接法两类做法，并基于已有的高版本off by null的利用技巧做了一点改进，提出一种无特殊限制条件的直接法，更具有普适性。