尧图网站建设 
Wazuh FIMDB 数据库黑盒测试工具 fimdb_test_tool 使用指南编译、配置与 Action 驱动测试【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh导读本文围绕 Wazuh 仓库中 src/syscheckd/src/db/testtool/Readme.md 描述的FIMDB Testing Toolfimdb_test_tool展开讲解如何用这一黑盒工具对 Wazuh 文件完整性监控FIM底层数据库模块fimdb进行独立验证。读完本文你将掌握该工具的构建方式、配置文件字段含义、命令行参数、全部 Action 的输入输出格式并能直接复跑仓库自带的冒烟测试用例对 Wazuh 的 FIM 数据层做针对性调试与回归验证。工具定位面向 fimdb 模块的黑盒验证器fimdb是 Wazuh Syscheck文件完整性监控在5.x分支引入的 FIM 数据访问层负责把文件表file_entry与 Windows 注册表registry_key/registry_data的元数据持久化到 SQLite 数据库中。FIMDB Testing Tool 的定位见 Readme.md是一个黑盒工具用户通过命令行参数喂入配置与一组动作Action文件工具在内部调用 fimdb 的数据库接口并把每次调用的结果以 JSON 文件形式落盘供使用者自行分析验证无需关心数据库内部实现。整个模块位于 src/syscheckd/src/db其结构如下include/db.h、db.hpp、fimCommonDefs.h等对外接口与类型定义src/db.cpp、fimDB.cpp、file.cpp、registry.cpp等实现testtool/本文主角fimdb_test_tool的源码入口 main.cpp 与命令行解析 cmdArgsHelper.hsmokeTests/仓库预置的冒烟测试输入文件配置文件 各类 Action JSONtests/针对dbItem、fileInterface、registryInterface、FIMDB的组件测试。工具通过 factoryAction.h 将输入 JSON 中的动作名映射为具体执行类动作执行后统一把结果写到输出目录实现输入驱动、输出可断言的黑盒测试模型。说明原文档引用了architecture/FIM/db/下的两张 PlantUML 架构图类图与时序图在当前仓库快照中未包含该目录及.puml文件因此本文以源码为准展开讲解不插入图片。编译 Wazuh 与构建测试工具顶层编译命令按 Readme.md 的说明要运行针对特定 Wazuh 目标的测试需以 release 或 debug 模式构建整个项目make TARGETserver|agent|winagent DEBUG1其中TARGET决定构建目标serverWazuh 服务端manageragentLinux/Unix 代理端winagentWindows 代理端用于验证注册表相关能力。需要调试符号与更详尽日志时追加DEBUG1。testtool 自身的 CMake 构建fimdb_test_tool的可执行目标由 CMakeLists.txt 定义关键信息如下项目名fimdb_test_tool采用 C17 标准编译选项-g -Wall -Wextra -pthread产物输出到${CMAKE_BINARY_DIR}/bin即构建目录下的bin/fimdb_test_tool链接库为fimdb与dbsync并按平台追加pthread/dlWindows 下额外定义-DOS_TYPEOSType::WINDOWS从而在编译期切换 FIM 的表结构Windows 多出注册表相关表。也就是说该工具并不是独立小程序而是与fimdb、dbsync库一起编译的可执行文件运行前需保证这两个库已随 Wazuh 构建产出。配置文件结构详解文档给出的最小配置原文档要求先创建一个 JSON 配置文件其结构为{ storage_type: 0|1, sync_interval: 60, file_limit: 20, value_limit: 1, is_windows: false }字段含义原文档字段含义取值storage_type存储类型0 DISK磁盘1 MEMORY内存sync_interval完整性检查间隔秒file_limit文件表行数上限整数value_limit注册表表行数上限整数is_windows是否启用 Windows/注册表相关表true/false源码级事实工具实际解析的字段对照入口 main.cpp工具真正读取并校验的字段是三个缺失会直接抛出nlohmann::json异常const auto storageType{ jsonConfigFile.at(storage_type).getconst uint32_t() }; const auto fileLimit{ jsonConfigFile.at(file_limit).getconst uint32_t() }; const auto registryLimit{ jsonConfigFile.at(registry_limit).getconst uint32_t() };因此两点需要留意实际键名是registry_limit而非文档示例中的value_limit。仓库自带配置config.json使用的正是registry_limit。sync_interval、is_windows等字段在 main.cpp 中并未被解析它们在冒烟测试配置中仅作为上下文信息存在是否启用注册表表实际由编译期OS_TYPE决定见 CMakeLists.txt 的-DOS_TYPEOSType::WINDOWS。storage_type与底层存储路径的对应关系在 db.cpp 的DB::init中可以看到auto path {storage FIM_DB_MEMORY ? FIM_DB_MEMORY_PATH : FIM_DB_DISK_PATH};而两个宏定义于 db.h#define FIM_DB_MEMORY_PATH :memory: #define FIM_DB_DISK_PATH queue/fim/db/fim.db即storage_type1时使用 SQLite 内存库:memory:0时使用磁盘数据库queue/fim/db/fim.db。初始化时还会创建DBSync宿主类型AGENT、引擎SQLITE3、持久化管理PERSISTENT数据库实例由FIMDB::instance()单例持有。仓库自带的参考配置Linux 冒烟测试配置 config.json{ storage_type: 1, sync_interval: 60, file_limit: 20, registry_limit: 1, registry_sync: true, sync_response_timeout: 10, sync_max_interval: 100, thread_pool: 1, queue_size: 100 }Windows 冒烟测试配置 configWindows.json 将registry_limit调整为20其余一致。可以看到registry_sync、sync_response_timeout、sync_max_interval、thread_pool、queue_size等字段虽不参与工具解析但为将来扩展或与其他模块对齐保留了完整上下文。命令行参数与调用方式参数解析实现在 cmdArgsHelper.h其showHelp()输出的用法为Usage: fimdb_test_tool option(s) SOURCES Options: -h Show this help message -c JSON_CONFIG_FILE Specifies the json config file to initialize the module. -a ACTION_LIST Specifies the list of actions to exercise the module. -o OUTPUT_FOLDER Specifies the output folder path where the results will be generated.各参数说明参数必填说明-c是配置文件路径对应上文配置结构-a是逗号分隔的 Action JSON 文件列表按顺序依次执行-o是结果输出目录-h否打印帮助信息原文档给出的标准调用示例./fimdb_test_tool -c config.json -a input1.json,input2.json,input3.json -o ./output执行流程见 main.cpp解析命令行-a后的字符串按逗号切分成动作文件列表splitActions打开并解析配置文件读取storage_type/file_limit/registry_limit调用DB::instance().init(...)初始化数据库日志回调统一打印Level:Msg:依次解析每个 Action 文件读取action字段交给FactoryAction::create()生成执行器把body字段传入execute()全部执行完后调用DB::instance().teardown()释放资源并打印结果文件所在目录。配置不可用时会打印The config file is not valid. Please, check the config file data并退出任一环节异常则会打印异常信息并展示帮助文本。支持的 Action 全解析动作分发逻辑集中在 factoryAction.h共支持 8 种 Action传入未知动作名会抛出Invalid action: name。每种 Action 的body结构与输出格式定义于 action.h汇总如下Actionbody 关键字段行为输出 JSON 内容RemoveFilefile_path从数据库删除指定文件记录resultaction: RemoveFileGetFilefile_path按路径查询文件记录经回调回填resultvalue命中记录actionCountEntriestable、filter_type统计表行数filter_type见下resultvalue计数actionUpdateFiletable、data记录数组同步/更新文件行变更事件回调收集resultjsonEventactionSearchFilesearch_type及search_value_path/inode/dev按类型搜索文件resultvalue结果数组actionStartTransactiontable、thread_number、queue_size基于DBSyncTxn开启事务resultactionSyncTxnRowstable、data向当前事务同步一批行resultactionGetDeletedRows空获取事务中已删除的行回调写入txn_ops.jsonresultaction关键枚举定义于 db.hppCOUNT_SELECT_TYPECOUNT_ALL计数全部行、COUNT_INODE按inode,device去重计数——CountEntries的filter_type即取此枚举的整数值0/1FILE_SEARCH_TYPESEARCH_TYPE_PATH、SEARCH_TYPE_INODE——SearchFile的search_type使用。CountEntries的底层实现见 db.cpp 的DB::countEntries根据COUNT_SELECT_TYPE_MAP拼出count(*) AS count或count(DISTINCT (inode || , || device)) AS count通过SelectQuery构造 SQL 并回调取回计数。事务相关动作把回调输出集中写入txn_ops.json每条记录包含Operation type、value、action三部分。Operation type取值来自 testContext.h 的RETURN_TYPE_OPERATION映射MODIFIED、DELETED、INSERTED、MAX_ROWS、DB_ERROR、SELECTED、GENERIC。回调写入时以txn_callback_mutex保护避免多线程竞争导致文件损坏。输出结果与文件命名按 Readme.md 的约定假设传入-a input1.json,input2.json,input3.json且-o ./output则所有输出位于./output下命名为action_1.json、action_2.json、action_3.json。从 main.cpp 的源码看编号实际取自动作列表下标currentId idx从 0 开始因此前几个输出文件为action_0.json、action_1.json……数量与-a传入的文件个数一致即一输入一输出。每个 Action 输出文件的通用骨架为{ result: true, action: RemoveFile }查询类 Action 会额外附带value字段。以GetFile为例命中/etc/wgetrc时输出形如{ result: true, value: { ...: 命中记录的完整字段... }, action: GetFile }事务回调数据则在./output/txn_ops.json中累积每次回调追加一条data记录。实战复跑仓库自带的冒烟测试src/syscheckd/src/db/smokeTests/下按场景组织了完整的输入样例可以直接作为-a参数使用。场景一原子文件操作atomicFileOperations模拟插入→更新→删除→查询的完整生命周期共 7 个输入文件-a atomicFileOperations/SyncRow_1.json,atomicFileOperations/SyncRow_2.json,atomicFileOperations/CountFiles.json,atomicFileOperations/SyncRow_3.json,atomicFileOperations/DeleteFile.json,atomicFileOperations/CountFiles.json,atomicFileOperations/GetFile.json各文件对应动作SyncRow_1.jsonUpdateFile插入/etc/wgetrc含 path、inode、checksum、hash_md5/sha1/sha256、owner、permissions、size 等完整字段SyncRow_2.jsonUpdateFile插入/tmp/test.txtCountFiles.jsonCountEntriesfilter_type0COUNT_ALL、tablefile_entry此时应统计到 2SyncRow_3.jsonUpdateFile更新/tmp/test.txt的size1500、ownerfakeUserModifiedDeleteFile.jsonRemoveFile删除/tmp/test.txt再次CountFiles.json应统计到 1GetFile.jsonGetFile查询/etc/wgetrc。通过两次CountFiles的计数变化即可验证插入、更新、删除、查询四个原子操作的正确性。场景二文件事务FimDBTransaction事务流程涉及 8 个输入文件核心是StartTransaction→SyncTxnRows→GetDeletedRows→CountFiles的循环-a FimDBTransaction/StartTransaction.json,FimDBTransaction/SyncTxnRows_1.json,FimDBTransaction/GetDeletedRows.json,FimDBTransaction/CountFiles.json,FimDBTransaction/StartTransaction.json,FimDBTransaction/SyncTxnRows_2.json,FimDBTransaction/GetDeletedRows.json,FimDBTransaction/CountFiles.jsonStartTransaction.jsonStartTransactiontablefile_entry、thread_number2、queue_size100SyncTxnRows_1.jsonSyncTxnRows向事务提交/tmp/test_1.txt等行GetDeletedRows.jsonGetDeletedRows把事务内删除的行经回调写入txn_ops.json。该场景验证的是 dbsync 事务机制DBSyncTxn在 FIM 文件表上的行为txn_ops.json中的Operation type字段INSERTED/DELETED/MODIFIED等可用于断言每行数据的变更类型。场景三Windows 注册表事务Windows 目标下使用 configWindows.json事务表换为registry_key与registry_dataStartTransactionRegistryKey.jsonStartTransactiontableregistry_keySyncTxnRowsRegistryKey_1.jsonSyncTxnRows注册表键数据含pathHKEY_LOCAL_MACHINE\SOFTWARE、architecture[x64]等字段。注册表记录同样携带 checksum、owner、permissions、mtime 等与文件记录对齐的字段便于统一的数据模型。场景四CI 中的自动化用法该工具已接入仓库的 CI/ASAN 冒烟检查。在 src/ci/input/test_tool_config.json 中syscheckd与winsyscheckd两段分别配置了fimdb_test_tool的完整参数smoke_tests_path: src/db/smokeTests、各自的-a参数与output_folderCI 直接据此执行工具并核对返回码。src/Readme.md 也记录了实际执行示例RUNNING TEST TOOL阶段Linux 下直接运行bin/fimdb_test_toolWindows 目标下则通过 Wine 运行fimdb_test_tool.exe并指定configWindows.json分别产出fileTransaction、AtomicOperations、registryKeyTransaction、registryDataTransaction等输出目录。这意味着你在本地复现时可以完全复用 CI 的参数组合进行回归验证。常见问题与排查结合源码行为运行工具时可能遇到的典型问题如下配置文件无效或字段缺失入口只强制解析storage_type、file_limit、registry_limit任一项缺失都会导致nlohmann::json::parse/at()抛异常程序打印The config file is not valid...或Something went wrong configuring the database...并退出。请确保配置使用registry_limit而非文档示例中的value_limit。未知 Action 名FactoryAction::create()对 8 个已知动作之外的名字抛出Invalid action: name此时应检查 JSON 的action字段拼写。缺少命令行参数-c/-a/-o任一缺失都会触发Switch value: ... not found异常并打印帮助文本。输出目录不存在工具不会自动创建输出目录std::ofstream写文件失败时对应 Action 的result会为false请提前创建-o指定的目录。Windows 注册表相关表不可用若在非 Windows 平台执行注册表相关 Action会因表结构缺失而报错注册表能力的启用由编译期-DOS_TYPEOSType::WINDOWS决定见 CMakeLists.txt需要使用winagent目标或 Wine 环境。小结FIMDB Testing Tool 以配置文件初始化数据库 Action 文件驱动操作 JSON 落盘断言结果的简洁模型为 Wazuh FIM 数据层提供了一套可脚本化、可 CI 化的黑盒测试方案。无论是验证storage_type的两种存储形态内存:memory:与磁盘queue/fim/db/fim.db、文件与注册表两类表的增删改查还是 dbsync 事务同步与删除行获取都可以直接复用仓库smokeTests目录下的现成输入快速上手。结合 main.cpp、action.h 与 db.cpp 等源码你还可以按需扩展新的 Action把它改造成契合自身验证场景的专用测试工具。【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Wazuh FIMDB 数据库黑盒测试工具 fimdb_test_tool 使用指南：编译、配置与 Action 驱动测试
Wazuh FIMDB 数据库黑盒测试工具 fimdb_test_tool 使用指南编译、配置与 Action 驱动测试【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh导读本文围绕 Wazuh 仓库中 src/syscheckd/src/db/testtool/Readme.md 描述的FIMDB Testing Toolfimdb_test_tool展开讲解如何用这一黑盒工具对 Wazuh 文件完整性监控FIM底层数据库模块fimdb进行独立验证。读完本文你将掌握该工具的构建方式、配置文件字段含义、命令行参数、全部 Action 的输入输出格式并能直接复跑仓库自带的冒烟测试用例对 Wazuh 的 FIM 数据层做针对性调试与回归验证。工具定位面向 fimdb 模块的黑盒验证器fimdb是 Wazuh Syscheck文件完整性监控在5.x分支引入的 FIM 数据访问层负责把文件表file_entry与 Windows 注册表registry_key/registry_data的元数据持久化到 SQLite 数据库中。FIMDB Testing Tool 的定位见 Readme.md是一个黑盒工具用户通过命令行参数喂入配置与一组动作Action文件工具在内部调用 fimdb 的数据库接口并把每次调用的结果以 JSON 文件形式落盘供使用者自行分析验证无需关心数据库内部实现。整个模块位于 src/syscheckd/src/db其结构如下include/db.h、db.hpp、fimCommonDefs.h等对外接口与类型定义src/db.cpp、fimDB.cpp、file.cpp、registry.cpp等实现testtool/本文主角fimdb_test_tool的源码入口 main.cpp 与命令行解析 cmdArgsHelper.hsmokeTests/仓库预置的冒烟测试输入文件配置文件 各类 Action JSONtests/针对dbItem、fileInterface、registryInterface、FIMDB的组件测试。工具通过 factoryAction.h 将输入 JSON 中的动作名映射为具体执行类动作执行后统一把结果写到输出目录实现输入驱动、输出可断言的黑盒测试模型。说明原文档引用了architecture/FIM/db/下的两张 PlantUML 架构图类图与时序图在当前仓库快照中未包含该目录及.puml文件因此本文以源码为准展开讲解不插入图片。编译 Wazuh 与构建测试工具顶层编译命令按 Readme.md 的说明要运行针对特定 Wazuh 目标的测试需以 release 或 debug 模式构建整个项目make TARGETserver|agent|winagent DEBUG1其中TARGET决定构建目标serverWazuh 服务端manageragentLinux/Unix 代理端winagentWindows 代理端用于验证注册表相关能力。需要调试符号与更详尽日志时追加DEBUG1。testtool 自身的 CMake 构建fimdb_test_tool的可执行目标由 CMakeLists.txt 定义关键信息如下项目名fimdb_test_tool采用 C17 标准编译选项-g -Wall -Wextra -pthread产物输出到${CMAKE_BINARY_DIR}/bin即构建目录下的bin/fimdb_test_tool链接库为fimdb与dbsync并按平台追加pthread/dlWindows 下额外定义-DOS_TYPEOSType::WINDOWS从而在编译期切换 FIM 的表结构Windows 多出注册表相关表。也就是说该工具并不是独立小程序而是与fimdb、dbsync库一起编译的可执行文件运行前需保证这两个库已随 Wazuh 构建产出。配置文件结构详解文档给出的最小配置原文档要求先创建一个 JSON 配置文件其结构为{ storage_type: 0|1, sync_interval: 60, file_limit: 20, value_limit: 1, is_windows: false }字段含义原文档字段含义取值storage_type存储类型0 DISK磁盘1 MEMORY内存sync_interval完整性检查间隔秒file_limit文件表行数上限整数value_limit注册表表行数上限整数is_windows是否启用 Windows/注册表相关表true/false源码级事实工具实际解析的字段对照入口 main.cpp工具真正读取并校验的字段是三个缺失会直接抛出nlohmann::json异常const auto storageType{ jsonConfigFile.at(storage_type).getconst uint32_t() }; const auto fileLimit{ jsonConfigFile.at(file_limit).getconst uint32_t() }; const auto registryLimit{ jsonConfigFile.at(registry_limit).getconst uint32_t() };因此两点需要留意实际键名是registry_limit而非文档示例中的value_limit。仓库自带配置config.json使用的正是registry_limit。sync_interval、is_windows等字段在 main.cpp 中并未被解析它们在冒烟测试配置中仅作为上下文信息存在是否启用注册表表实际由编译期OS_TYPE决定见 CMakeLists.txt 的-DOS_TYPEOSType::WINDOWS。storage_type与底层存储路径的对应关系在 db.cpp 的DB::init中可以看到auto path {storage FIM_DB_MEMORY ? FIM_DB_MEMORY_PATH : FIM_DB_DISK_PATH};而两个宏定义于 db.h#define FIM_DB_MEMORY_PATH :memory: #define FIM_DB_DISK_PATH queue/fim/db/fim.db即storage_type1时使用 SQLite 内存库:memory:0时使用磁盘数据库queue/fim/db/fim.db。初始化时还会创建DBSync宿主类型AGENT、引擎SQLITE3、持久化管理PERSISTENT数据库实例由FIMDB::instance()单例持有。仓库自带的参考配置Linux 冒烟测试配置 config.json{ storage_type: 1, sync_interval: 60, file_limit: 20, registry_limit: 1, registry_sync: true, sync_response_timeout: 10, sync_max_interval: 100, thread_pool: 1, queue_size: 100 }Windows 冒烟测试配置 configWindows.json 将registry_limit调整为20其余一致。可以看到registry_sync、sync_response_timeout、sync_max_interval、thread_pool、queue_size等字段虽不参与工具解析但为将来扩展或与其他模块对齐保留了完整上下文。命令行参数与调用方式参数解析实现在 cmdArgsHelper.h其showHelp()输出的用法为Usage: fimdb_test_tool option(s) SOURCES Options: -h Show this help message -c JSON_CONFIG_FILE Specifies the json config file to initialize the module. -a ACTION_LIST Specifies the list of actions to exercise the module. -o OUTPUT_FOLDER Specifies the output folder path where the results will be generated.各参数说明参数必填说明-c是配置文件路径对应上文配置结构-a是逗号分隔的 Action JSON 文件列表按顺序依次执行-o是结果输出目录-h否打印帮助信息原文档给出的标准调用示例./fimdb_test_tool -c config.json -a input1.json,input2.json,input3.json -o ./output执行流程见 main.cpp解析命令行-a后的字符串按逗号切分成动作文件列表splitActions打开并解析配置文件读取storage_type/file_limit/registry_limit调用DB::instance().init(...)初始化数据库日志回调统一打印Level:Msg:依次解析每个 Action 文件读取action字段交给FactoryAction::create()生成执行器把body字段传入execute()全部执行完后调用DB::instance().teardown()释放资源并打印结果文件所在目录。配置不可用时会打印The config file is not valid. Please, check the config file data并退出任一环节异常则会打印异常信息并展示帮助文本。支持的 Action 全解析动作分发逻辑集中在 factoryAction.h共支持 8 种 Action传入未知动作名会抛出Invalid action: name。每种 Action 的body结构与输出格式定义于 action.h汇总如下Actionbody 关键字段行为输出 JSON 内容RemoveFilefile_path从数据库删除指定文件记录resultaction: RemoveFileGetFilefile_path按路径查询文件记录经回调回填resultvalue命中记录actionCountEntriestable、filter_type统计表行数filter_type见下resultvalue计数actionUpdateFiletable、data记录数组同步/更新文件行变更事件回调收集resultjsonEventactionSearchFilesearch_type及search_value_path/inode/dev按类型搜索文件resultvalue结果数组actionStartTransactiontable、thread_number、queue_size基于DBSyncTxn开启事务resultactionSyncTxnRowstable、data向当前事务同步一批行resultactionGetDeletedRows空获取事务中已删除的行回调写入txn_ops.jsonresultaction关键枚举定义于 db.hppCOUNT_SELECT_TYPECOUNT_ALL计数全部行、COUNT_INODE按inode,device去重计数——CountEntries的filter_type即取此枚举的整数值0/1FILE_SEARCH_TYPESEARCH_TYPE_PATH、SEARCH_TYPE_INODE——SearchFile的search_type使用。CountEntries的底层实现见 db.cpp 的DB::countEntries根据COUNT_SELECT_TYPE_MAP拼出count(*) AS count或count(DISTINCT (inode || , || device)) AS count通过SelectQuery构造 SQL 并回调取回计数。事务相关动作把回调输出集中写入txn_ops.json每条记录包含Operation type、value、action三部分。Operation type取值来自 testContext.h 的RETURN_TYPE_OPERATION映射MODIFIED、DELETED、INSERTED、MAX_ROWS、DB_ERROR、SELECTED、GENERIC。回调写入时以txn_callback_mutex保护避免多线程竞争导致文件损坏。输出结果与文件命名按 Readme.md 的约定假设传入-a input1.json,input2.json,input3.json且-o ./output则所有输出位于./output下命名为action_1.json、action_2.json、action_3.json。从 main.cpp 的源码看编号实际取自动作列表下标currentId idx从 0 开始因此前几个输出文件为action_0.json、action_1.json……数量与-a传入的文件个数一致即一输入一输出。每个 Action 输出文件的通用骨架为{ result: true, action: RemoveFile }查询类 Action 会额外附带value字段。以GetFile为例命中/etc/wgetrc时输出形如{ result: true, value: { ...: 命中记录的完整字段... }, action: GetFile }事务回调数据则在./output/txn_ops.json中累积每次回调追加一条data记录。实战复跑仓库自带的冒烟测试src/syscheckd/src/db/smokeTests/下按场景组织了完整的输入样例可以直接作为-a参数使用。场景一原子文件操作atomicFileOperations模拟插入→更新→删除→查询的完整生命周期共 7 个输入文件-a atomicFileOperations/SyncRow_1.json,atomicFileOperations/SyncRow_2.json,atomicFileOperations/CountFiles.json,atomicFileOperations/SyncRow_3.json,atomicFileOperations/DeleteFile.json,atomicFileOperations/CountFiles.json,atomicFileOperations/GetFile.json各文件对应动作SyncRow_1.jsonUpdateFile插入/etc/wgetrc含 path、inode、checksum、hash_md5/sha1/sha256、owner、permissions、size 等完整字段SyncRow_2.jsonUpdateFile插入/tmp/test.txtCountFiles.jsonCountEntriesfilter_type0COUNT_ALL、tablefile_entry此时应统计到 2SyncRow_3.jsonUpdateFile更新/tmp/test.txt的size1500、ownerfakeUserModifiedDeleteFile.jsonRemoveFile删除/tmp/test.txt再次CountFiles.json应统计到 1GetFile.jsonGetFile查询/etc/wgetrc。通过两次CountFiles的计数变化即可验证插入、更新、删除、查询四个原子操作的正确性。场景二文件事务FimDBTransaction事务流程涉及 8 个输入文件核心是StartTransaction→SyncTxnRows→GetDeletedRows→CountFiles的循环-a FimDBTransaction/StartTransaction.json,FimDBTransaction/SyncTxnRows_1.json,FimDBTransaction/GetDeletedRows.json,FimDBTransaction/CountFiles.json,FimDBTransaction/StartTransaction.json,FimDBTransaction/SyncTxnRows_2.json,FimDBTransaction/GetDeletedRows.json,FimDBTransaction/CountFiles.jsonStartTransaction.jsonStartTransactiontablefile_entry、thread_number2、queue_size100SyncTxnRows_1.jsonSyncTxnRows向事务提交/tmp/test_1.txt等行GetDeletedRows.jsonGetDeletedRows把事务内删除的行经回调写入txn_ops.json。该场景验证的是 dbsync 事务机制DBSyncTxn在 FIM 文件表上的行为txn_ops.json中的Operation type字段INSERTED/DELETED/MODIFIED等可用于断言每行数据的变更类型。场景三Windows 注册表事务Windows 目标下使用 configWindows.json事务表换为registry_key与registry_dataStartTransactionRegistryKey.jsonStartTransactiontableregistry_keySyncTxnRowsRegistryKey_1.jsonSyncTxnRows注册表键数据含pathHKEY_LOCAL_MACHINE\SOFTWARE、architecture[x64]等字段。注册表记录同样携带 checksum、owner、permissions、mtime 等与文件记录对齐的字段便于统一的数据模型。场景四CI 中的自动化用法该工具已接入仓库的 CI/ASAN 冒烟检查。在 src/ci/input/test_tool_config.json 中syscheckd与winsyscheckd两段分别配置了fimdb_test_tool的完整参数smoke_tests_path: src/db/smokeTests、各自的-a参数与output_folderCI 直接据此执行工具并核对返回码。src/Readme.md 也记录了实际执行示例RUNNING TEST TOOL阶段Linux 下直接运行bin/fimdb_test_toolWindows 目标下则通过 Wine 运行fimdb_test_tool.exe并指定configWindows.json分别产出fileTransaction、AtomicOperations、registryKeyTransaction、registryDataTransaction等输出目录。这意味着你在本地复现时可以完全复用 CI 的参数组合进行回归验证。常见问题与排查结合源码行为运行工具时可能遇到的典型问题如下配置文件无效或字段缺失入口只强制解析storage_type、file_limit、registry_limit任一项缺失都会导致nlohmann::json::parse/at()抛异常程序打印The config file is not valid...或Something went wrong configuring the database...并退出。请确保配置使用registry_limit而非文档示例中的value_limit。未知 Action 名FactoryAction::create()对 8 个已知动作之外的名字抛出Invalid action: name此时应检查 JSON 的action字段拼写。缺少命令行参数-c/-a/-o任一缺失都会触发Switch value: ... not found异常并打印帮助文本。输出目录不存在工具不会自动创建输出目录std::ofstream写文件失败时对应 Action 的result会为false请提前创建-o指定的目录。Windows 注册表相关表不可用若在非 Windows 平台执行注册表相关 Action会因表结构缺失而报错注册表能力的启用由编译期-DOS_TYPEOSType::WINDOWS决定见 CMakeLists.txt需要使用winagent目标或 Wine 环境。小结FIMDB Testing Tool 以配置文件初始化数据库 Action 文件驱动操作 JSON 落盘断言结果的简洁模型为 Wazuh FIM 数据层提供了一套可脚本化、可 CI 化的黑盒测试方案。无论是验证storage_type的两种存储形态内存:memory:与磁盘queue/fim/db/fim.db、文件与注册表两类表的增删改查还是 dbsync 事务同步与删除行获取都可以直接复用仓库smokeTests目录下的现成输入快速上手。结合 main.cpp、action.h 与 db.cpp 等源码你还可以按需扩展新的 Action把它改造成契合自身验证场景的专用测试工具。【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考