北京
Go语言自带的模糊测试功能，用起来挺方便，但跟Rust、C、C++生态里的LibAFL和AFL++这些顶尖工具比起来，差距明显。路径约束难解，结构化输入得手写解析器，整数溢出、goroutine泄漏、数据竞争、执行超时这些常见漏洞类型，原生工具根本检测不到。
有个团队干脆分叉了Go工具链，做了个项目叫gosentry。它保留了标准的testing.F工作流，底层换成了更强的模糊测试引擎。用gosentry跑go test -fuzz，默认调用的是LibAFL。原生支持结构体模糊测试，能跑基于语法的Nautilus模糊测试，还能检测之前发现不了的漏洞类型，一条命令就能生成覆盖率报告。
如果你已经有Go的模糊测试用例，不用重写。直接指向gosentry的二进制文件，同样的go test -fuzz接口，加几个新参数就能用。API不变，变的是引擎和周边工具，命令行调一调就行。
还能用--generate-coverage从已有的测试活动中生成覆盖率报告。在同一包下用同样的-fuzz目标运行，不需要指定语料库路径。gosentry会把测试状态存在Go的模糊缓存索引里，按包和模糊目标区分，重启测试会自动从已有语料库恢复。
这个项目的起点是他们发布了go-panikint来改进Go模糊测试的整数溢出检测。但发现光做这个不够，Go模糊测试生态缺的东西，Rust、C、C++研究者每天都在用的技术，Go这边根本没有。实际工作中经常遇到这些坑：复杂if分支导致路径约束无解，原生工具永远卡死；语法模糊测试想都别想；结构感知模糊测试得额外手工处理；有些漏洞类型默认不会崩溃或依赖外部库，模糊测试能触发危险行为但报不出来；生成覆盖率报告很麻烦；想让模糊测试在关键错误日志上崩溃，得手改代码。
gosentry的做法是保留开发者熟悉的部分：用testing.F写模糊目标，用f.Add创建初始语料库，用f.Fuzz传入输入。底层捕获模糊回调，构建带libFuzzer风格入口点的Go归档文件，通过基于Rust的LibAFL运行器在进程内执行。API还是老样子，但引擎、调度、检测器这些都强化了。这么设计是为了让开发者和安全研究者用起来没阻力。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
