Qanux's space

写在一切之前不得不说 N1CTF 的题目质量是真的高，下次出题我也要出好一点（其实已经出好了，不过打算花多点时间去优化😋😋，敬请期待）。这次比赛有两题我觉得非常有意思，一题是 heap_master，另外一题是 php_master。其中 php_master 当时并没有做出来，打算以后有时间再研究一下（出题人的预期解是拿到任意反序列化，可是有的师傅认为这道题目其实可以拿到 code exec），感觉如何突破 php 新加的 shadow heap 将会是一个热点。 前置内容我们都知道内核对物理内存的管理是按照页为基本单位进行的，进程运行起来所需要的数据也是存储在一个一个的物理页中，既然物理内存页可以存储进程的普通数据，那么它也一定可以存储进程虚拟内存与物理内存之间的映射关系。 事实上，内核也是这么干的，内核会从物理内存空间中拿出一个物理内存页来专门存储进程里的这些内存映射关系，而这种物理内存页我们将其称之为页表，从这里可以看出页表的本质其实就是一个物理内存页。 而内核会在页表中划分出来一个个大小相等的小内存块，这些小内存块我们称之为页表项 PTE（Page Table Entry ...

Begin又有 kernel 啦 好久没看 kernel 了，刚好 SCTF 上就来了一道简单题。结果由于生疏了打的巨慢，连血都没拿到😭（4血）上图为比赛时打通的截图。 由于题目比较简单，所以我打算用多种打法来解决这道题目，同时也当作是对 kernel 的康复训练。这篇文章只是对题目进行各种攻击手段的分析，不会对每个内核结构体的结构以及攻击手法的具体原理进行详细的讲解。本篇文章我会逐步增加题目的限制，然后从低级到高级用不同的攻击手段对题目进行求解。 题目分析关键代码：ioctl1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465__int64 __fastcall my_module_ioctl(__int64 a1, int a2, __int64 a3){ void *v5; // [rsp+30h] [rbp-E0h] __int64 v6; // [rsp+60h ...

去年就知道这个比赛很卷，没想到今年更卷。某某战队距离比赛结束还有40分钟时排名第一，比赛结束时排第二十一，真的逆天。这次比赛学长不是在实习就是去帮别的战队打，到头来pwn全都只能我一个人来打，真的好累喵😇。还好题目不是很难，一共五题pwn，前4题很快就打完了，最后一题巨抽象，本地不同的打法都通了，远程死活不同，真是让人道心破碎捏。 pstack这是本次比赛的签到题，主逻辑如下： 123456789101112131415int __fastcall main(int argc, const char **argv, const char **envp){ init(argc, argv, envp); puts("Let's start the construction for stack overflow exploit."); vuln(); return 0;}ssize_t vuln(){ _BYTE buf[48]; // [rsp+0h] [rbp-30h] BYREF puts("Can ...

house of water早就听 Csome 学长说过有种打法叫 house of water，但是当时没去看，时间久了就忘记这个东西了，现在记起来了就来学习一下。由于笔者的水平有限，文章不免会出现许多错误，希望各位师傅能过包容以及指正。这篇文章的程序的测试环境为 ubuntu 22.04.3 TLS。 概述这个打法由国际战队 blue water 提出的，下面来看看该团队对这个打法的描述： House of Water is a technique for converting a Use-After-Free (UAF) vulnerability into a t-cachemetadata control primitive, with the added benefit of obtaining a free libc pointer in thet-cache metadata as well. NOTE: This requires 4 bits of bruteforce if the primitive is a write primitive, as the L ...

写在最前面一直都知道渗透在网络安全中的重要性，可是一直都没用重视，于是在国赛决赛吃大亏。平时自己也在打打 vulnhub，但打的都是一些十分简单的靶场。国赛决赛结束后我就开始push校队的人去学习渗透，当然我这个新上任的队长肯定要起到带头作用，所以我也开始去练习春秋云境的靶场。很多人认为云境这个靶场比较贵，但是我认为能够用钱买知识是一件很划算的事情，而且春秋云境的靶场质量也比较高（还有国赛渗透也有很多内容来自这里面）这篇文章是关于 Initial 这个靶机的详细讲解，这个是云境中最简单的一题，同时也是我打的第一个关于 windows 渗透的题目，因此学到了很多的东西。 详细讲解flag1题目给出了一个ip地址 39.99.255.153，我们可以使用 nmap 来看看他开启了那些端口，命令为： 1sudo nmap --min-rate 10000 39.99.255.153 这段命令是以最小速率 10000 对全部端口（1-65535）进行扫描，10000 是权衡的结果，数字过大扫描速度快，但容易遗漏端口，数字过小则扫描时间过长，经验表明 10000 就是扫描的合适速度。- ...

一直觉得 v8 漏洞利用是一件非常好玩的事情，所以找时间入门了一下，这篇博客所使用的环境是 *CTF 2019 的 oob，相关附件读者可以自行上网搜索下载。这篇博客主要用于总结本人在入门 v8 漏洞利用时所学到的东西，由于 Qanux 又菜又爱玩，文章不免存在许多的问题，请读者多多包容 基本概念在开始之前，肯定有很多人想问 v8 是一个什么东西，下面是在知乎中搜到的对于 v8 的描述： V8引擎是由C++编写的Google开源高性能JavaScript和WebAssembly引擎，它用于Chrome和Node.js等。V8可以独立运行，也可以嵌入到任何C++应用程序中。V8支持众多操作系统，如Windows、linux、android等，也支持其他硬件架构，如IA32,X64,ARM等，具有很好的可移植和跨平台特性。 作为 js 引擎，V8 会编译 / 执行 JavaScript 代码，管理内存，负责垃圾回收，与宿主语言的交互等。通过暴露宿主对象 (变量，函数等) 到 JavaScript，JavaScript 可以访问宿主环境中的对象，并在脚本中完成对宿主 ...

PwnShell漏洞利用很久以前就听说过 php pwn，没想到就在这里遇到了。出题人自己实现了一个 php 扩展模块 vuln.so，很显然漏洞就来源于这里，通过逆向分析发现出题人在这个模块中实现的菜单堆，其漏洞函数如下： 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556unsigned __int64 __fastcall zif_addHacker(__int64 a1, __int64 a2){ __int64 v2; // rbp __int64 v3; // rdi __int64 v5; // rdx _BYTE *v6; // rax _DWORD *v7; // r12 _QWORD *v8; // rbx void *v9; // rax size_t v10; // rdx const void *v11; // rsi _BYTE *v12; // r13 __int64 ...

通常我们对内核的攻击都是基于知道内核各种地址的前提下进行的，为了加大攻击内核的难度， kaslr 由此而生，但内核会很容易泄露有关其位置的信息，如大量内核代码乐于在 printk() 调用中打印出内核指针值。在 大量工作 之后，通过修复内核代码来使用针对指针的特殊格式化指令，并在未设置 kptr_restrict 的情况下拒绝将实际指针值输出到日志中，从而基本解决了这个问题。根据需要还修改了各种 /proc 和 sysfs 文件。随着时间的推移，要想了解特定系统上的内核位置就变得更加困难了，但依然有漏网之鱼可以为我们提供内核的基址这里的主角是 /sys/kernel/notes ，在谷歌上找到的十分简略的描述： 12345What: /sys/kernel/notesDate: July 2009Contact: <linux-kernel@vger.kernel.org>Description: The /sys/kernel/notes file contains the binary representation of the running ...

基础知识既然说到llvm pass pwn，我们肯定要先了解llvm到底是一个什么东西学过编译原理的人应该都知道，编译过程主要可以划分为前端与后端： 前端把源代码翻译成中间表示 (IR) 后端把IR编译成目标平台的机器码。当然，IR也可以给解释器解释执行 然而，经典的编译器如gcc在设计上都是提供一条龙服务的： 你不需要知道它使用的IR是什么样的，它也不会暴露中间接口来给你操作它的IR。 换句话说，从前端到后端，这些编译器的大量代码都是强耦合的。 这样做有好处也有坏处。好处是，因为不需要暴露中间过程的接口，它可以在内部做任何想做的平台相关的优化。 而坏处是，每当一个新的平台出现，这些编译器都要各自为政实现一个从自己的IR到新平台的后端。 甚至如果当一种新语言出现，且需要实现一个新的编译器，那么可能需要设计一个新的IR，以及针对大部分平台实现这个IR的后端。 不妨想一下，如果有M种语言、N种目标平台，那么最坏情况下要实现 M*N 个前后端。这是很低效的。 因此，我们很自然地会想，如果大家都共用一种IR呢？ 那么每当新增加一种语言，我们就只要添加一个这个语言到IR的前端； ...

其实就是对各位大佬博客的各种摘抄和总结···，方便自己以后做题 结构体chunk: 123456struct chunk{ char prev_user_data[]; uint8_t idx; //低5bit为idx第几个chunk uint16_t offset; //与第一个chunk起始地址的偏移，实际地址偏移为offset * UNIT,详细请看get_meta源码中得到group地址的而过程！ char data[];}; 在释放后 chunk 头的 idx会变成0xff offset 会清零 group:12345678#define UNIT 16#define IB 4struct group { struct meta *meta; unsigned char active_idx:5; char pad[UNIT - sizeof(struct meta *) - 1];//padding=0x10B unsigned char storage[];// chunks}; 在mus ...