Posts

踩坑实录：在 VMware Ubuntu 22.04 Server 上部署 Minikube 的血泪史 背景与环境 最近想重新学习一下 Kubernetes，为了图方便，决定在本地 VMware 虚拟机里装一个 Minikube。原本以为是一路回车的事，没想到硬是折腾了一下午，经历了各种网络、内存、镜像和 CNI 的折磨。 环境信息： 虚拟机：VMware Workstation，Ubuntu 22.04 Server（无图形界面） 虚拟机 IP：192.168.65.194（NAT 模式） 宿主机代理：192.168.65.1:7890（HTTP/HTTPS 代理） 虚拟机配置：中途扩容至 4 核 8G，60G 硬盘 目标：使用 Docker 驱动启动 Minikube，并运行 Dashboard 及测试应用 本文记录了我这一路遇到的各种报错和最终的成功配置，希望能帮到遇到类似问题的朋友。 第一坑：宿主机代理与 GitHub 连接被拒 一开始按照官方文档下载 Minikube 二进制文件： x12@chenjx12:~$ curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:21 --:--:-- 0 curl: (7) Failed to connect to github.com port 443 after 21059 ms: Connection refused [sudo] password for x12: install: cannot stat 'minikube-linux-amd64': No such file or directory 原因：虚拟机是 NAT 网络，无法直接访问外网，需要走宿主机的代理。但宿主机默认只监听 127.0.0.1。 ...

Nginx cve-2013-2028漏洞环境搭建与复现 声明：测试环境为 Ubuntu 16.04 + Nginx 1.4.0，仅供安全研究使用 环境搭建 由于 cve-2013-2028 漏洞影响到的Nginx版本 1.3.9 和 1.4.0 已经在官方网站中被移除 所以我们需要在其他地方获取有漏洞的版本 方法一：Nginx官方GitHub仓库 这是目前最可靠的方法，Nginx 官方 GitHub 保留了所有历史版本 # 克隆 1.4.0 分支 git clone --single-branch --branch release-1.4.0 https://github.com/nginx/nginx.git nginx-1.4.0 cd nginx-1.4.0 # 验证分支 git log --oneline -3 方法二：从 GitHub 安全研究项目获取 有安全研究者专门整理了包含漏洞的 Nginx 版本 # 下载包含预编译二进制和源码的项目 git clone https://github.com/m4drat/CVE-2013-2028-Exploit.git cd CVE-2013-2028-Exploit # 项目中包含 Dockerfile 和 docker-compose，可以直接构建环境 准备环境 因为笔者自己是学习二进制安全方向的，所以将以源码分析为主要目标 这里我们结合前面两种方法的优点 用docker起 nginx1.4.0 的原生 Ubuntu 16.04 环境，但是下载官方的源码进行分析，这样既避免了编译器系统环境差异，也能做到二进制分析 ...

我的AFL++fuzzing入门之路（4） 00 引言：跨越鸿沟 回顾前三天： Day 1：在"教科书式test.c"上跑通AFL++，理解状态界面 Day 2：深入插桩原理，发现"平墙式memcmp让AFL失明"的致命问题 Day 3：用ASAN将"隐形漏洞"转化为"显性崩溃" 提出问题： 真实项目不是afl-cc test.c这么简单。面对libpng这类真实解析器： 如何编译带依赖的开源项目？ 如何应对无处不在的"平墙式"魔数检查（memcmp(header, "\x89PNG", 4)）？ 如何让AFL++不再"瞎猜"？ 本章目标： 以libpng 1.6.54为演示目标，掌握实战前的三大核心准备： 编译真实项目（带ASAN插桩） 构建高质量种子语料库 用字典破解"平墙式"困境 01 实战目标编译：以libpng为例 1st. 为什么选libpng 理由 说明 经典攻击面 图片解析器天生处理不可信输入（用户上传） 代码规模适中 约3万行，比内核简单，比test.c真实 历史漏洞丰富 CVE-2018-14550、CVE-2019-7317等，有参考案例 格式相对简单 PNG结构清晰：文件头+Chunk（IHDR/IDAT/IEND） 官方支持完善 Google OSS-Fuzz已集成，有现成字典参考 选什么版本？看了一下，最后决定选择1.6.54，存在已知CVE，CVE-2026-25646（png_set_quantize()堆溢出），1.6.55修复 CVE-2026-25646速览：png_set_quantize()函数在处理调色板（PLTE Chunk）时存在堆缓冲区溢出，存在30年之久。这正是ASAN的检测目标，也是我们Fuzzing的"猎物"。 2nd. 下载与依赖 # 下载源码 wget https://download.sourceforge.net/libpng/libpng-1.6.54.tar.gz tar -xzf libpng-1.6.54.tar.gz && cd libpng-1.6.54 # 验证版本 head -5 README README for libpng version 1.6.54 ================================ # 安装依赖 sudo apt update sudo apt install zlib1g-dev # libpng依赖zlib 3rd. 用afl-cc + ASAN编译 命令如下： ...

我的AFL++fuzzing入门之路（3） 00 前言回顾 在笔者的上一篇，也是 AFL++ Fuzzing 系列的第二篇中，我们从“汇编指令”深入到“策略机制”，完成了对 AFL++ 核心能力的解构： 插桩底层：通过 IDA 反编译，直观观察了 LLVM SanitizerCoverage 的内联插桩实现，解析了 __afl_area_ptr 与 guard 变量如何协作，以及 NeverZero 机制如何防止计数溢出，从指令级掌握了覆盖率追踪的底层逻辑； 反馈机制：通过“阶梯式”与“平墙式”代码的对比实验，量化了覆盖率反馈对 fuzzing 效率的决定性影响，验证了“覆盖率引导是 AFL 灵魂”这一核心思想，揭示了为何 memcmp 类检查是 fuzzing 的噩梦； 崩溃分析：借助 GDB 与 xxd 工具，我们完成了“触发崩溃→定位根因→验证输入”的完整闭环，学会了如何区分 ud2 指令触发的逻辑崩溃与内存破坏导致的异常。 虽然我们已经掌握了发现和分析崩溃的方法，但在真实漏洞挖掘中，存在一个更棘手的问题：并非所有的内存错误都会立即崩溃。大量的堆溢出、Use-After-Free 往往会“沉默”地破坏内存，直到程序运行很久后才随机崩溃，这让 AFL++ 难以捕获到有效的反馈信号。 为了解决“漏洞隐形”的问题，本文将引入 Sanitizer（消毒器） 机制。我们将重点探索 ASAN（地址消毒器）如何通过影子内存将“隐形漏洞”转化为“显性崩溃”，并结合实战演示其在 AFL++ 中的集成方法与性能权衡，进一步提升漏洞挖掘的深度与广度。 01 ASAN 深度解析（核心重点） 1st. 为什么需要ASAN 要回答这个问题，我们首先得知道 ASAN 是什么： ASAN 全名 AddressSanitizer（整合了 LeakSanitizer (LSAN)），是一个由 Google 开发的内存错误检测工具，能够精准捕捉堆溢出、栈溢出、Use-After-Free（UAF）等常见的内存安全问题。 那么，为什么我们的 Fuzzing 特别需要它？ 1. 很多内存错误是“沉默”的 在上一篇文章中，我们遇到的崩溃都是“立即触发”的（如 __builtin_trap 或空指针解引用）。但在真实世界中，很多严重的漏洞并不会立即让程序崩溃： ...

我的AFL++fuzzing入门之路（2） 00 前篇回顾 在笔者的上一篇，也是 AFL++ Fuzzing 系列的第一篇中，我们完成了以下工作： 理论基础：建立了对 AFL++ 的基础认知，包括其作为覆盖率引导模糊测试框架的定位、核心漏洞挖掘能力，以及编译时插桩的工作原理； 环境搭建：在 Ubuntu 24.04 虚拟机中完成了 AFL++ 的源码编译安装，解决了 Ubuntu Apport 与 core_pattern 的系统冲突； 实战入门：构造并测试了首个漏洞程序，在 2.7 秒内成功触发崩溃，同时掌握了 AFL++ 状态界面 8 区域的核心指标解读方法。 基于昨日的实践基础，本文将推进三个层面的深入探索： 插桩汇编表现：通过 IDA 反编译观察 AFL++ 使用 LLVM 的 SanitizerCoverage 在二进制层面插入的 inline 代码，理解 AFL++ 如何记录边覆盖率，从汇编指令级掌握覆盖率追踪的底层机制； 难度进阶：通过修改触发条件（从 “AFL++” 阶梯式扩展至平墙式），测试 AFL++ 的变异深度与效率边界，观察 havoc 策略在长模式匹配场景下的表现； 崩溃分析：引入 GDB 调试器对发现的崩溃进行根因定位，掌握调用栈回溯、寄存器状态检查等漏洞分析基础技能，完成从"发现崩溃"到"理解崩溃"的闭环。 01 汇编插桩 为了简单，咱直接素材复用，上一篇中的test.c使用afl-cc编译的，现在再用gcc编译一遍，然后放到不同的工具下比对 ❯ cat test.c #include <stdio.h> #include <string.h> int main(int argc, char *argv[]) { char buf[100]; FILE *f = fopen(argv[1], "r"); if (!f) return 1; fread(buf, 1, sizeof(buf), f); fclose(f); // 漏洞触发点：输入 "AFL++" 会崩溃 if (buf[0] == 'A' && buf[1] == 'F' && buf[2] == 'L') if (buf[3] == '+') if (buf[4] == '+') __builtin_trap(); // 触发崩溃（SIGTRAP） return 0; } afl-cc -o test test.c gcc -o test-gcc test.c 这里就得到了两个不同的可执行程序版本：有afl插桩的test和gcc编译的无插桩的test-gcc ...

我的AFL++fuzzing入门之路（1） 00 前言 最近学校上的事渐渐变少，遂想着找份实习充实一下自己，学习更多先进的前沿技术。 但是真正开始写简历时便越发惶恐，觉得能写的实在太少了， 思来想去再学点东西来扩充一下自己的技术栈，翻着网页发现收藏夹里的fuzz测试介绍。 而fuzz模糊测试是我在去年就见到过的，但是当时也只是匆匆一瞥，知道fuzz是一种自动输入寻找崩溃点的技术。 现在有空了，多篇介绍AFL的文章看下来发现这个功能很强大，而且和二进制方向有一定的互补， 所以就开始尝试学习了。 由于笔者也刚在这个领域入门，所以文章可能会有写不够准确甚至谬误，欢迎各位大佬斧正。 01 AFL++Fuzzing介绍 AFL++（American Fuzzy Lop Plus Plus）是目前最流行和最先进的模糊测试（Fuzzing）框架之一，是经典AFL（American Fuzzy Lop）的社区维护增强版。 它是由Google安全工程师Michał Zalewski开发的一款开源fuzzing测试工具。 其可以高效地对二进制程序进行fuzzing，挖掘可能存在的内存安全漏洞，如_栈溢出、堆溢出、UAF、double free_等。 由于需要在相关代码处插桩，因此AFL主要用于对开源软件进行测试。 配合QEMU等工具，也可对闭源二进制代码进行fuzzing，但执行效率会受到影响。 工作原理：通过对源码进行重新编译时进行插桩（简称编译时插桩）的方式利用自动产生测试用例来探索二进制程序内部新的执行路径。AFL也支持直接对没有源码的二进制程序进行测试，但需要QEMU的支持。 02 环境搭建 这里有两种选择，可以使用docker容器，也可以直接安装到本机 先附上docker容器搭建的方法： docker pull aflplusplus/aflplusplus:latest docker run -ti -v /path/to/your/code:/src aflplusplus/aflplusplus 为了能够详细的学习（？，笔者决定直接安装到Ubuntu24.04虚拟机里。 先更新系统和软件包： sudo apt update && sudo apt upgrade -y 安装依赖（没错，就是这么多），有LLVM/Clang、Python、Rust等： sudo apt install -y build-essential python3-dev automake cmake git \ flex bison libglib2.0-dev libpixman-1-dev python3-setuptools \ cargo libgtk-3-dev lld llvm llvm-dev clang \ gcc-$(gcc --version|head -n1|sed 's/\..*//'|sed 's/.* //')-plugin-dev \ libstdc++-$(gcc --version|head -n1|sed 's/\..*//'|sed 's/.* //')-dev \ ninja-build cpio libcapstone-dev wget curl python3-pip 找个好地方，克隆源码 ...

个人博客搭建 hugo + GitHub Pages/云服务器 以下仅为个人搭建记录，仅供参考 本来是写在微信公众号上的，后门租了服务器就整服务器上了，结果没注意服务器到期了……遂重新开到GitHub Pages上 本地hugo 先在Windows主机上创建一个文件夹用于放hugo 打开powershell winget install Hugo.Hugo.Extended 如是，hugo安装完成，下一步初始化 hugo new site . --force GitHub仓库-hugo源码 在GitHub上创建一个私有仓库，用于存放hugo源码以及文章草稿 copy这玩意在本地git关联 同步关联 本地初始化git，并且关联到github仓库 well，可以看到仓库中已经有推送的了 主题添加 会发现少了很多目录，这是因为git不推空目录，给hugo添加一下主题和第一篇文章，让git能把所有目录都推上去 git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod echo "theme = 'PaperMod'" >> hugo.toml git add . git commit -m "Add PaperMod theme and config" git push 文章添加 再给自己一个hello world： 在content目录下新建/post/hello-world.md --- title: "Hello World" date: 2026-03-07T22:00:00+08:00 draft: false tags: ["hugo", "博客"] categories: ["技术"] --- ## 欢迎来到我的博客 这是我的第一篇 Hugo 文章！ 然后让hugo帮我们处理一下： ...

欢迎来到我的博客 这是我的第一篇 Hugo 文章！

源码防护-fortify_source 由于第一篇FORTIFY刚接触也没咋碰到，了解的也不多 现在回过头来发现当时写的糊里糊涂， 所以本篇继续深入FORTIFY防护 Fortify Source 是什么 本质：GCC 的编译时/运行时缓冲区溢出检测机制，属于源码级保护（不是二进制层面的 NX/Canary 那种） 保护对象：标准库中的高风险函数（strcpy、memcpy、sprintf、gets 等），一般主要是和字符串相关的函数。 FORTIFY_SOURCE 是 GCC/glibc 提供的一种编译时 + 运行时联合防护机制，通过将危险的 C 库函数替换为带边界检查的安全版本（__*_chk 后缀函数），在编译期和运行期检测缓冲区溢出。 核心思想： 编译器在编译时尽可能推断出缓冲区大小，如果能在编译期判定溢出就直接报错；如果编译期无法确定，就插入运行时检查代码，在溢出发生的瞬间终止程序。 Fortify Source干了什么 要想知道Fortify Source干了什么，那就要先看看如果没有Fortify Source会发生什么 char buf[32]; strcpy(buf, user_input); //① memcpy(buf, src, len); //② sprintf(buf, "%s", str); //③ read(fd, buf, 1024); //④ 先来看这段源码，毫无疑问的，①②③④这四条语句都有安全漏洞： ①完全没有长度检查，溢出 ②len作为变量可能会>32 ③str也可能长度>32 ④1024>32毫无疑问的溢出 而编译器对这些代码没有任何反应，也就是说，对生成的代码不会做任何的边界检查 Fortify Source的工作机制 工作流程： 源代码：strcpy(buf, src) │ ▼ ┌───────────────────────────┐ │ 预处理阶段（宏替换） │ │ #include <string.h> │ │ FORTIFY 宏将 strcpy 替换为 │ │ __builtin___strcpy_chk() │ └───────────┬───────────────┘ │ ▼ ┌───────────────────────────────────┐ │ 编译阶段（GCC 内置函数处理） │ │ │ │ GCC 尝试用 __builtin_object_size() │ │ 推断 buf 的大小 │ │ │ ├──── 能确定大小 ────────────────────┤ │ │ │ │ ├─ 编译期可判定溢出 │ │ │ → 编译错误/警告 │ │ │ │ │ ├─ 编译期可判定安全 │ │ │ → 优化为普通 strcpy（零开销） │ │ │ │ │ └─ 编译期无法确定 │ │ → 插入运行时检查 │ │ → 调用 __strcpy_chk() │ │ │ ├──── 不能确定大小 ──────────────────┤ │ → 退化为普通 strcpy（无法保护） │ └──────────────────────────────────┘ 而工作流程中的三个关键组件： ...

FORTIFY fortify是轻微的检查，用于检查是否存在缓冲区溢出的错误。适用于程序采用大量的字符串或者内存操作函数，如: memcpy(): 描述：void *memcpy(void str1, const void str2, size_t n) 从存储区str2复制n个字符到存储区str1 参数：str1 – 指向用于存储复制内容的目标数组，类型强制转换为 void 指针 str2 – 指向要复制的数据源，类型强制转换为 void 指针 n – 要被复制的字节数 返回值：该函数返回一个指向目标存储区 str1 的指针 memset(): 描述：void *memset(void *str, int c, size_t n) 复制字符 c（一个无符号字符）到参数 str 所指向的字符串的前 n 个字符 参数：str – 指向要填充的内存块 c – 要被设置的值。该值以 int 形式传递，但是函数在填充内存块时是使用该值的无符号字符形式 n – 要被设置为该值的字节数 返回值：该值返回一个指向存储区 str 的指针 strcpy(): 描述：char *strcpy(char *dest, const char *src) 把 src 所指向的字符串复制到 dest，容易出现溢出 参数：dest – 指向用于存储复制内容的目标数组 src – 要复制的字符串 返回值：该函数返回一个指向最终的目标字符串 dest 的指针 ...