Monero RPC 模糊测试（Fuzzing）框架解析：绕过传输层直测 core_rpc_server 处理器

区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载导读本文以 tests/fuzz/fuzz_rpc/README.md 为骨架结合 Monero 仓库中tests/fuzz/fuzz_rpc/目录的完整源码深入解析 Monero 官方 RPC 模糊测试fuzzing框架的设计思路、构建方式与运行流程。读完本文你将掌握Monero 如何在不启动真实服务器的情况下直接对core_rpc_server的各 RPC 端点处理函数进行模糊测试、Safe/Risky/Priority 三类端点如何划分与编排、FAKECHAIN回归测试模式如何构造虚拟区块链以及 ZMQ 发布端如何被纳入同一套模糊测试体系。为什么模糊测试要跳过传输层Monero 的 RPC 服务core_rpc_server对外通过 HTTP/JSON-RPC 与 ZMQ 两种途径暴露大量端点。传统做法是启动一个真实服务器、通过网络协议灌入随机请求再观察崩溃与内存错误——但这样做有一个显著缺陷传输层噪声大HTTP 解析、JSON 编解码、连接管理会消耗大量模糊测试输入fuzz input真正触达业务处理逻辑的路径占比很低端点覆盖不完整网络层入口难以稳定覆盖到每个处理函数的所有分支启动开销高每轮迭代都走完整的网络栈吞吐量受限。Monero 的做法是跳过传输层直接实例化core_rpc_server对象跳过 fake server 的搭建直接调用各 RPC 端点的处理函数。这样模糊测试的随机数据全部作用于 handler 内部的请求构造与业务逻辑效率与覆盖率都更高。该思想在 tests/fuzz/fuzz_rpc/README.md 开头即有明确说明。文件结构总览tests/fuzz/fuzz_rpc/目录下共 9 个文件职责划分清晰文件作用fuzz_rpc.cppRPC 模糊测试主入口包含LLVMFuzzerTestOneInput管理每一轮迭代fuzz_zmq.cppZMQ 模糊测试主入口同样包含LLVMFuzzerTestOneInputinitialisation.cpp初始化辅助函数配置 dummy 协议、P2P、core 对象生成随机区块、矿工、交易initialisation.h初始化相关类型声明与导出rpc_endpoints.cppRPC 端点请求/响应对象构造与端点函数调用封装以及三类端点映射表rpc_endpoints.hRPC 端点 fuzz 函数声明与映射表导出zmq_endpoints.cppZMQ 发布端点的请求构造与调用封装zmq_endpoints.hZMQ 端点声明README.md本文所基于的框架说明文档RPC 端点的三类划分Safe / Risky / Priorityrpc_endpoints.cpp将所有被模糊测试的 RPC 端点函数划分为三个映射表std::mapint, std::function...分别对应三类行为特征Priority优先级最关键、每轮迭代至少执行一次的端点。包括get_blocks、get_blocks_by_height、get_hashes、get_outs_bin、get_transactions、is_key_image_spent、send_raw_tx、get_output_distribution_bin、pop_blocks、getblocktemplate、submitblock、generateblocks、relay_tx、get_output_distribution映射键 0~13。这些端点大多直接读写区块链数据或涉及交易提交属于风险与价值双高的核心路径。Safe安全被视为稳定、不易失败的端点共 41 个映射键 14~54覆盖get_height、get_info、get_transaction_pool*系列、区块头查询系列、peer 列表、日志设置、set_bans/get_bans、hard_fork_info等只读或轻量写操作。Risky高风险更容易失败或提前返回尤其是没有有效区块链生成时包括start_mining、stop_mining、mining_status、save_bc、stop_daemon、update、add_aux_pow、flush_txpool、flush_cache、get_txids_loose映射键 55~65其中 59 空缺、72 即prune_blockchain被注释禁用。这些端点或会修改全局状态或在空链/脏数据下容易触发异常提前退出。从源码结构看safe_fuzz_targets中的键与priority_fuzz_targets的键连续衔接14 起而risky_fuzz_targets键位存在跳跃55~65 与 72说明映射键只是内部编号与端点实际 ID 无直接对应关系。完整定义见 rpc_endpoints.cpp。构建方式一个源文件编译出三个 fuzzer 变体同一份 fuzz_rpc.cpp 被编译成两个版本区别在于是否定义SAFE宏fuzz_zmq.cpp 则只编译单一版本。对应构建规则在 tests/fuzz/CMakeLists.txt并且整体受OSSFUZZ开关控制目标名宏定义行为fuzz_rpcSAFE只模糊测试 Safe 类端点fuzz_rpc_full无同时包含 Safe 与 Risky 端点fuzz_rpc_full_no_exceptionsCATCH_ALL_EXCEPTIONS无SAFE且吞掉全部异常仅捕获runtime_error与DB_ERROR之外的兜底分支也被静默fuzz_zmq无单版本 ZMQ 模糊测试链接rpc_pub库构建时还需要LIB_FUZZING_ENGINE环境变量指定 libFuzzer 或 AFL 等引擎fuzzer/FuzzedDataProvider.h头文件由 tests/fuzz/include 提供这是 LLVM 项目的单头文件工具用于把模糊输入字节流按需拆分为整数、字符串、布尔等类型。此外CMake 会为fuzz_unsafe_macro目标单独重编译 src/common/perf_timer.cpp 并定义FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION确保性能计时器在模糊测试构建下不会干扰并避免生产断言被误触发。运行流程逐层拆解第一步随机选择端点函数在 fuzz_rpc.cpp 中LLVMFuzzerTestOneInput先做输入门槛检查单轮迭代至少需要 512 字节输入不足则直接返回 0 跳过。随后根据是否定义SAFE决定is_safe_mode调用get_fuzz_targets(is_safe_mode)取回端点函数映射。非安全模式下会合并 priority safe risky 三张表安全模式则只取 safe 表并对键重新编号kv.first - 14见 rpc_endpoints.cpp。通过provider.ConsumeIntegralInRangeunsigned(1, 16)随机决定本轮要发送 1~16 条 RPC 消息。非安全模式下priority 端点保证至少出现一次先把 priority 表全部索引压入 selectors再随机洗牌随后再随机追加若干普通端点索引。调用el::Loggers::addFlag(...DisableApplicationAbortOnFatalLog)关闭致命日志导致的进程退出。第二步初始化 core 与 core_rpc_server每次迭代都会重新创建一个core_rpc_server对象并配齐 dummy 协议与 P2P 组件见 fuzz_rpc.cppinitialise_rpc_core()创建DummyProtocol与cryptonote::core解析命令行参数--regtest --offline --data-dir 临时目录临时目录为系统 temp 下的monero-fuzz-rpc然后调用core-init(vm)initialise_rpc_server(*dummy_core, provider.ConsumeBool())用随机布尔值决定本次迭代运行在restricted受限还是 unrestricted非受限RPC 模式——这直接对应真实节点中--restricted-rpc的语义见 src/rpc/core_rpc_server.cpp 中m_restricted的初始化。受限模式下get_info等端点会隐藏 alt 块数、连接数、对等节点列表等敏感信息core_rpc_server.cpp。初始化函数内部initialisation.cpp还通过模板实例化nodetool::node_servercryptonote::t_cryptonote_protocol_handlercryptonote::core作为 dummy P2P 节点core_rpc_server的构造函数正是接收(core, node_server, bool restricted)三个参数。fuzz_zmq不需要这一步——它不依赖 core/区块链直接创建 libzmq contextzmq_ctx_new并实例化zmq_pub发布器。第三步生成随机区块与交易FAKECHAINgenerate_random_blocksinitialisation.cpp是流程中最复杂的一环其核心是FAKECHAIN回归测试模式--regtest标志让区块链跳过对作者签名和交易 ID 的校验逻辑同时保留其余校验规则从而允许伪造的区块/交易被顺利接纳。具体流程区块缓存先用generate_genesis_block生成创世块再随机生成 1~4 个矿工账户account_base::generate、2~15 个区块输入不足时提前终止。每个区块按median_weight 300000、block_weight 100000计算奖励get_block_reward用construct_miner_tx构造带随机 nonce 的矿工交易累积coins余额。区块与交易会缓存在static变量中并通过provider.ConsumeBool()决定本轮是复用缓存还是重新生成——这保证了模糊测试过程中链状态的连续性。交易缓存随机生成 1~4 笔交易。每笔交易创建发送/接收账户、随机转账金额10000 ~ 1000000000、构造 10 个环签名输出条目其中 1 个为真实输出、其余为假输出view_tag取随机值最终通过construct_tx_and_get_tx_key构造带RangeProofPaddedBulletproof范围证明的 v2 交易序列化后缓存。上链先batch_start()开启数据库批量写然后调用add_new_block逐块加入再用handle_incoming_tx把交易送入交易池被接纳的交易哈希存入全局cached_tx_hashes供fuzz_get_transactions等端点使用真实存在的交易哈希做深度校验。若没有任何区块成功加入则batch_stop()后跳过本轮迭代。第四步真正的模糊测试selectors 全部确定后进入执行循环fuzz_rpc.cppfor (unsigned selector : selectors) { try { fuzz_targetsselector; } catch (const std::runtime_error) { // 已知的 monero runtime_error } catch (const cryptonote::DB_ERROR e) { // 随机值触发内部区块链 DB 检查时的已知错误 } }每个端点函数见 rpc_endpoints.cpp的模式高度统一声明对应的COMMAND_RPC_*::request与response结构体定义于 src/rpc/core_rpc_server_commands_defs.h用FuzzedDataProvider生成随机字段填充请求然后直接调用core_rpc_server上的on_*处理函数。以fuzz_get_blocks为例随机生成 0~16 个区块哈希、随机start_height、max_block_count、prune等标志位再调用rpc.on_get_blocks(req, res, ctx)。rpc_endpoints.cpp顶部定义了共享的connection_context ctx与epee::json_rpc::error error_resp模拟真实 HTTP 连接上下文与 JSON-RPC 错误通道。每轮迭代结束时调用get_db().batch_stop()关闭批量写入然后返回 0 进入下一轮。异常处理策略让 fuzzer 只对真正的崩溃负责模糊测试的输入完全随机必然触发大量业务层预期中的失败路径。Monero 在三个层面做了隔离已知异常静默std::runtime_error与cryptonote::DB_ERROR定义于 src/lmdb/error.h被显式捕获并忽略因为随机值触发内部 DB 检查报错是正常现象全量兜底fuzz_rpc_full_no_exceptions变体通过CATCH_ALL_EXCEPTIONS宏启用catch (...)兜底把一切异常都静默掉用于区分异常路径与真正未处理错误致命日志抑制DisableApplicationAbortOnFatalLog避免 easylogging 的致命日志直接 abort 进程。这样一来只有未被捕获的崩溃segfault、断言失败、越界等才会被 libFuzzer/AFL 报告为 bug信噪比大幅提升。ZMQ 模糊测试fuzz_zmq 的独立路径zmq_endpoints.cpp 定义了 4 个 ZMQ 发布端点 fuzz 函数键函数作用0fuzz_sub_request随机订阅字符串调用pub.sub_request1fuzz_send_chain_main随机高度 0~4 个随机区块调用pub.send_chain_main2fuzz_send_miner_data随机主版本、高度、难度、median weight、coins 与 0~3 条 backlog 条目调用pub.send_miner_data3fuzz_send_txpool_add构造 0~3 个txpool_event随机 blob 尝试解析为交易调用pub.send_txpool_addfuzz_zmq.cpp的最小输入门槛为 64 字节每轮随机发送 1~8 条 ZMQ 消息使用独立于 RPC 的zmq_targets映射表不经过 core/区块链初始化。其被 fuzz 的对象是 src/rpc/zmq_pub.h 中的zmq_pub发布器——模糊测试目标从请求处理扩展到了发布消息的构造与序列化。如何运行在配置了OSSFUZZ的构建环境中CMake 开关开启且提供LIB_FUZZING_ENGINE编译后在build/tests下得到fuzz_rpc、fuzz_rpc_full、fuzz_rpc_full_no_exceptions、fuzz_zmq四个可执行文件配合 libFuzzer 即可运行例如# 安全模式仅 Safe 端点 ./fuzz_rpc -runs10000 corpus_rpc # 完整模式Safe Riskypriority 每轮必跑 ./fuzz_rpc_full -runs10000 corpus_rpc_full # ZMQ 发布器模糊测试 ./fuzz_zmq -runs10000 corpus_zmq-runs之外的选项如-max_len、-jobs均遵循 libFuzzer 通用约定也可用 AFL 等引擎替换。仓库中 contrib/fuzz_testing/fuzz.sh 提供了通用模糊测试辅助脚本可作参考。小结Monero 的 RPC 模糊测试框架通过跳过传输层、直连 handler、FAKECHAIN 伪造链、三类端点分级编排四板斧把有限模糊测试输入的能量集中释放在 RPC 业务逻辑上并以fuzz_rpc/fuzz_rpc_full/fuzz_rpc_full_no_exceptions/fuzz_zmq四种变体覆盖不同风险偏好与异常策略组合。其设计思路与源码实现fuzz_rpc.cpp、initialisation.cpp、rpc_endpoints.cpp、zmq_endpoints.cpp对其他大型 C 项目做 RPC/API 层模糊测试具有直接借鉴价值——尤其是用宏开关控制端点集合静态缓存链上数据提升迭代效率显式区分已知异常与真崩溃这三个工程细节。赞分享区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载相关推荐浏览器模糊测试完全指南Awesome-Fuzzing中的BFuzz框架详解浏览器模糊测试是现代安全研究中的重要技术能够有效发现浏览器中的各种安全问题。在Awesome Fuzzing项目中的BFuzz框架是一个专门针对浏览器设计的输文档教程网络安全测试告别磁盘空间危机Czkawka/Krokiet开源清理工具全攻略告别磁盘空间危机Czkawka/Krokiet开源清理工具全攻略 你是否经常遇到磁盘空间不足的烦恼照片、视频、文档重复堆积临时文件占用宝贵空间相似图片占桌面应用.NET Runtime 模糊测试实战深入解析基于 SharpFuzz 与 libFuzzer 的库级 Fuzzing 框架.NET Runtime 模糊测试实战深入解析基于 SharpFuzz 与 libFuzzer 的库级 Fuzzing 框架 导读 本文以 dotnet/ru语言运行时标准库JIT编译编译器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考