Small Utopia

根据程序执行反馈的获取情况，可以将模糊测试分为白盒、黑盒和灰盒三类 一、白盒测试白盒测试通过分析被测程序的内部机制和执行被测程序时收集的信息来生成测试用例，白盒测试通常会对程序进行动态污点分析或符号执行以获取精确的程序分析和状态信息。 二、黑盒测试黑盒测试将测试对象当作黑盒，按照指定的规范随机生成测试用例。不提前分析程序内部机制也不接受反馈信息来更新测试用例。 三、灰盒测试灰盒测试的典型特点就是可以使用目标的执行反馈来指导测试用例的生成。

1. OverviewPadding Oracle：一些系统在解密密文时，会先验证其填充是否合法，如果不合法则会抛出异常。针对此行为的攻击即为padding oracle攻击 2. Lab Environment Seed虚拟机 Labsetup.zip 使用dcbuild和dcup命令启动docker环境 3. Task1：Getting Familiar with PaddingPadding：分组加密算法要求明文长度需要为分组长度的整数倍。因此需要padding填充末尾使长度满足要求 使用echo -n创建文件P，长度为5。-n参数表示结尾不带换行符 1echo -n "12345" > P 使用openssl命令对文件进行加密，并且对加密文件解密查看padding 12345# 加密openssl enc -aes-128-cbc -e -in P -out C# 解密openssl enc -aes-128-cbc -d -nopad -in C -out...

1.环境搭建 修改flag为学号 构建docker镜像（运行sudo ./build.sh，注意chmod +x修改权限），连接不稳定，可能需要多次尝试 开启docker，禁用ASLR。 使用netstat -antp查看ssh服务状态 登录容器ssh 0.0.0.0 -p 49153 -l seed 2. 漏洞利用运行镜像中vuln程序，vuln有setuid权限，因此可以尝试通过此来获取root shell。 查看vuln源代码： 12345678910111213141516171819202122232425262728293031323334353637383940#include <stdlib.h>#include <stdio.h>#include <string.h>#ifndef BUF_SIZE#define BUF_SIZE 12#endifint bof(char *str){ char buffer[BUF_SIZE]; unsigned int *framep; ...

摘要实现了模拟器Fuzzware，特点：减少了fuzz的input开销，节省了时间。 解决问题针对当前几种对固件模拟fuzz的方法的局限性进行了分析 high-level模拟：通过挂钩完全绕过MMIO的模拟。局限：过于high-level，无法发现外设驱动代码的漏洞。 pattern-based...

最近在使用vmware虚拟机跑项目复现，需要频繁使用github，因此在此记录下github加速的简单方法 https://zhuanlan.zhihu.com/p/432414619

摘要google针对c与c++库提出了新的fuzz driver自动化生成方式。 解决问题对C/C++库代码片段的slice_based_fuzz。 主要贡献基于google海量代码库进行测试，完成了Fudge可以有效的处理海量的代码。发现其中的安全漏洞 尚存不足fuzz基于源代码，可以考虑在编译源代码为可执行文件后加入动态符号执行等技术。（也在其Future Work中体现（还提到了Machine Learning）） Fudge具体过程Slicing...

项目链接：https://github.com/fuzzware-fuzzer/fuzzware 1. 环境Ubuntu22.04 docker 具体过程比较简单，可以直接看github readme 2. 复现1./run_docker.sh examples fuzzware pipeline --skip-afl-cpufreq pw-recovery/ARCH_PRO 由图可以看到刚开始运行时发现新的MMIO寄存器模型，由于MMIO Access Model中并不存在，因此会将其定义为新的模型，然后继续向下运行 建模完毕后，开始进行正常的fuzzing阶段。 一轮fuzzing结束后，根据反馈调整输入，开始下一阶段fuzzing。

解决问题对当下Windows系统软件的fuzz没有合适的方法。提出了Winnie对Windows闭源软件进行fuzzing。 主要贡献 提出了Winnie，可以对Windows闭源软件进行模糊测试 实现了windows系统的fork方法，使得可以不用每次执行都得从头开始，提高了fuzzing效率，其中fork新进程的速度达到310次/s显著高于windows自带CreateProcess91.9次/s，与WSL的fork速度相近。 尚存不足 由于闭源特性，无法全自动，需要人工参与fuzzer代码的生成 具体细节 生成fuzz代码 Target Identification：确认二进制程序中可以用于fuzz的输入点（读取用户输入的api或函数） Call-seq Recovery：恢复目标程序中函数体内对各个相关targetfunction调用的顺序（类似于fudge） Argument...

简介背景：模拟以MCU为处理器的固件设备并没有完全的模拟外设，导致fuzzing时外设需要实际物理设备，速度偏慢，且没有达到完全模拟。 主要实现了一个可以模拟在MCU下运行的固件的模拟器P2IM。通过自动化外设接口的建模来进行自动化，可扩展的模拟。 特点：对mcu架构下的寄存器进行分类识别，在qemu模拟时同时模拟这些寄存器值的操作，从而模拟出了firmware外设的一系列操作。保证了firmware在qemu上的稳定运行的同时加入了外设的模拟。 解决问题当时对固件的模拟需要软硬件结合，导致fuzz的效率很慢，因此提出了一种模拟器对固件完全模拟的思路，通过实现对固件外设寄存器的分类并模拟以达到完全模拟的目的。 主要贡献实现了对无硬件模拟 提出了P2IE（外设接口等效属性）：为了定义怎样的仿真是好的仿真 提出了MMIO寄存器四种模型：对四种模型的行为进行了定义 探索性执行技术 尚存不足 寄存器分类可能存在错误（eg:...

简介RTOS系统当下并没有很好的分析方式，因此作者提出了sfuzz工具，利用RTOS每一项任务的控制流都是独立的特点，从RTOS系统中切出独立的代码块进行fuzzing。 项目地址：https://github.com/NSSL-SJTU/SFuzz 解决问题解决了在当时RTOS领域模糊测试没有很好的分析方式的问题。 主要贡献 提出了RTOS系统的特点：每一项任务的控制流都是相互独立的，通过代码切片获取到独立的代码树，分别进行分析 使用了前向切片与后向切片，根据依赖和函数调用关系获取了代码片段以供fuzz 设计了SFuzz，对RTOS进行灰盒测试。 尚存不足具体内容sfuzzing一共分为四个模块，分别为Forward slicer，Control Flow Nodes Handler，Micro Fuzzing，Concolic Analyzer。 Forward Slicer由上图可知，forward...