capa 库函数识别签名机制解析FLIRT 签名在 sigs/ 目录中的生成、加载与使用【免费下载链接】capaThe FLARE teams open-source tool to identify capabilities in executable files.项目地址: https://gitcode.com/GitHub_Trending/ca/capa导读本篇文章围绕 capa 仓库中的 sigs/README.md 展开深入讲解 capa 如何借助 FLIRT 签名识别并忽略被分析样本中的库函数从而降低误报并提升运行性能。你将了解到这些签名的来源与生成方式pcf、sigmake、它们与 IDA Pro 自带签名集的区别、在 capa 源码中的加载与匹配链路以及如何通过-s/--signatures参数使用或替换这些签名。一、为什么要为库函数准备签名capa 的核心能力是从可执行文件中提取特征并匹配规则从而识别恶意软件的能力capabilities。但在真实样本中绝大多数代码并不是恶意作者编写的它们来自 MSVC 运行库、ATL/MFC 框架、各类常见第三方库等编译器与框架的通用代码。这些库函数如果被当作能力参与规则匹配会带来两个问题误报增多恶意行为规则可能恰好命中某些库函数的特征把正常的库代码误判为恶意能力运行变慢引擎需要对库函数内部也做特征提取与规则匹配白费计算资源。为此capa 引入了库函数识别机制先识别出二进制中的库函数再在匹配时忽略它们。而识别手段正是 FLIRTFast Library Identification and Recognition Technology签名。正如 sigs/README.md 所述This directory contains FLIRT signatures that capa uses to identify library functions. Typically, capa will ignore library functions, which reduces false positives and improves runtime.二、sigs/ 目录里有什么当前仓库的sigs/目录下包含三个签名文件按文件名顺序组织覆盖不同的库来源文件覆盖范围依命名推断1_flare_msvc_rtf_32_64.sigMSVC 运行库RunTime Function的 32/64 位签名2_flare_msvc_atlmfc_32_64.sigMSVC 的 ATL/MFC 框架的 32/64 位签名3_flare_common_libs.sig常见库common libraries签名文件名的数字前缀并非随意如后文所述capa 会按文件名的字母顺序加载签名因此1_、2_、3_前缀保证了稳定的加载次序也方便维护者后续追加新签名。三、签名的来源FLAIR 工具链与独立生成FLIRT 签名本身是 Hex-Rays 生态中广泛使用的格式但 sigs/README.md 明确强调了一个关键事实These FLIRT signatures were generated by Mandiant using the Hex-Rays FLAIR tools such aspcfandsigmake. Mandiant generated the signatures from source data that they collected; these signatures are not derived from the FLIRT signatures distributed with IDA Pro.这包含两层含义生成工具是 FLAIRFLAIRFile Analysis and Inspection Resources是 Hex-Rays 随 IDA Pro 分发的一组工具其中pcf用于从目标二进制中创建 pattern 文件.patsigmake则负责把.pat文件合并、去重、处理冲突后生成最终的.sig签名文件。也就是说本仓库的签名链路是收集库的源数据 → 编译/获取目标二进制 →pcf提取函数模式 →sigmake汇总成.sig。数据来源是 Mandiant 自建这些签名并非从 IDA Pro 自带的 FLIRT 签名集如vc32rtf.sig、mfc42.sig等派生而来而是 Mandiant 依据自行收集的源数据独立生成的。因此在许可与内容上都与 IDA Pro 分发版解耦可以随 capa 一并开源分发。四、签名如何在 capa 中被加载源码调用链capa 对签名的使用有完整的一条链路全部集中在 capa/main.py 与 capa/loader.py 中。4.1 CLI 参数入口-s/--signatures在 capa/main.py 中通用参数注册函数install_common_args定义了签名参数if signatures in wanted: parser.add_argument( -s, --signatures, typestr, defaultSIGNATURES_PATH_DEFAULT_STRING, helppath to .sig/.pat file or directory used to identify library functions, use embedded signatures by default, )关键点短选项为-s长选项为--signatures既支持指向单个.sig/.pat文件也支持指向一个目录默认值为SIGNATURES_PATH_DEFAULT_STRING在 capa/main.py 中定义为字符串(embedded signatures)表示默认使用内嵌签名即仓库/发行包自带的sigs/目录用户无需任何配置即可获得库函数识别能力。4.2 默认签名路径的计算get_default_signatures()capa/main.py负责计算默认签名的文件路径它基于 capa 的安装根目录源码树或 PyInstaller 打包目录定位sigs/目录然后递归收集扩展名为.pat、.pat.gz、.sig的文件。这与sigs/目录下实际存放.sig文件的事实一致。当用户显式传入-s时capa/main.py 会据此设置args.signatures与args.is_default_signatures区分使用默认内嵌签名与用户自定义签名两种模式。4.3 签名文件的枚举与排序真正的文件收集逻辑位于 capa/loader.py 的get_signatures()def get_signatures(sigs_path: Path) - list[Path]: if not sigs_path.exists(): raise IOError(fsignatures path {sigs_path} does not exist or cannot be accessed) paths: list[Path] [] if sigs_path.is_file(): paths.append(sigs_path) elif sigs_path.is_dir(): logger.debug(reading signatures from directory %s, sigs_path.resolve()) for file in sigs_path.rglob(*): if file.is_file() and file.suffix.lower() in (.pat, .pat.gz, .sig): paths.append(file) paths [path.resolve().absolute() for path in paths] # load signatures in deterministic order: the alphabetic sorting of filename. # this means that 0_sigs.pat loads before 1_sigs.pat. paths sorted(paths, keylambda path: path.name) ...从这段实现可以总结出三个可复用的行为约定入参既可以是文件也可以是目录指向文件时直接使用指向目录时用rglob(*)递归搜索只保留.pat、.pat.gz、.sig三种后缀的文件大小写不敏感路径会被绝对化所有签名路径会经过resolve().absolute()归一化加载顺序是确定性的按文件名字母序排序加载所以1_flare_msvc_rtf_32_64.sig一定先于2_flare_msvc_atlmfc_32_64.sig被注册。若你自定义签名目录也应遵循用数字前缀控制优先级的命名习惯。4.4 签名注入 vivisect 分析流水线签名被枚举后最终在get_workspace()capa/loader.py中生效。该函数先以analyzeFalse的方式创建 vivisect workspace目的是抢在完整分析之前挂载签名分析器# lazy import enables us to not require viv if user wants another backend. import envi.exc import viv_utils import viv_utils.flirt ... # dont analyze, so that we can add our Flirt function analyzer first. vw viv_utils.getWorkspace(str(path), analyzeFalse, should_saveFalse) ... viv_utils.flirt.register_flirt_signature_analyzers(vw, [str(s) for s in sigpaths]) ... vw.analyze()也就是说capa 依赖viv_utils.flirt.register_flirt_signature_analyzers来自 vivisect 生态把签名注册为 vivisect 的函数分析器随后再执行完整的vw.analyze()从而在反汇编阶段就完成库函数的标记。此后被标记的库函数便从规则匹配中排除。4.5 适用前提仅 vivisect 后端 PE 文件签名匹配并非在所有场景下都启用。capa/main.py 的get_signatures_from_cli()做了两个前置判断def get_signatures_from_cli(args, input_format: str, backend: str) - list[Path]: if backend ! BACKEND_VIV: logger.debug(skipping library code matching: only supported by the vivisect backend) return [] if input_format ! FORMAT_PE: logger.debug(skipping library code matching: signatures only supports PE files) return [] ...因此有两个明确限制只有 vivisect 后端才会进行库函数匹配只有 PE 格式输入才支持签名识别ELF、shellcode 等格式会自动跳过。此外若默认内嵌签名路径缺失capa 会输出错误并提示先安装签名参见 capa/main.py。五、如何在实战中传入自定义签名尽管默认开箱即用但当你通过pip install flare-capa以库方式安装时默认签名并不会随包附带详见 doc/installation.md。此时需要显式指定签名目录$ capa -s /path/to/capa-sigs suspicious.exe也可以同时指定规则与签名$ capa -r capa-rules-v9.4.0/ -s /path/to/capa-sigs suspicious.exe参数含义对照参数说明-s, --signatures指定.sig/.pat文件或目录用于识别库函数默认使用内嵌签名-r, --rules指定规则文件或目录对应 capa/main.py 的规则参数若传入的路径不存在或不可访问get_signatures()会抛出IOErrorsignatures path ... does not exist or cannot be accessed并在 CLI 层以错误码退出对应E_INVALID_SIG。因此自定义签名时请务必确认路径有效、目录内文件为.sig/.pat/.pat.gz格式。六、许可与再分发注意事项sigs/README.md 最后一条关键信息关乎合规The signatures in this directory have the same license as capa: Apache 2.0.即sigs/目录下的签名文件与 capa 本身采用相同的Apache 2.0许可。这与签名非派生自 IDA Pro 分发签名的事实相辅相成——正是由于 Mandiant 独立生成签名capa 才能以 Apache 2.0 自由再分发。若你需要将 capa 的签名集成到自己的工具链中可以放心遵循 Apache 2.0 的条款保留许可声明、注明修改等。七、延伸阅读签名生成脚本生态仓库提供 scripts/match-function-id.py可用于函数级匹配验证安装与签名路径说明doc/installation.mdMethod 2 的Note on capa rules and library identification signatures一节签名加载的完整实现capa/loader.py枚举与排序、capa/loader.py注入 vivisectCLI 参数与默认签名逻辑capa/main.py、capa/main.py、capa/main.py。小结capa/sigs/是 capa 库函数识别能力的基石它以 Mandiant 用 FLAIR 工具链pcfsigmake独立生成的 FLIRT 签名为载体在 vivisect 后端的 PE 分析流程中标记并忽略库函数最终换来更低的误报与更快的运行速度。理解这条从签名生成、目录组织、确定性加载到 vivisect 注册的完整链路不仅能让你正确使用-s/--signatures参数也能帮助你为特定样本集定制属于自己的库函数签名集。【免费下载链接】capaThe FLARE teams open-source tool to identify capabilities in executable files.项目地址: https://gitcode.com/GitHub_Trending/ca/capa创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 6:05:39 · 阅读 1.2k capa 库函数识别签名机制解析：FLIRT 签名在 sigs/ 目录中的生成、加载与使用
capa 库函数识别签名机制解析FLIRT 签名在 sigs/ 目录中的生成、加载与使用【免费下载链接】capaThe FLARE teams open-source tool to identify capabilities in executable files.项目地址: https://gitcode.com/GitHub_Trending/ca/capa导读本篇文章围绕 capa 仓库中的 sigs/README.md 展开深入讲解 capa 如何借助 FLIRT 签名识别并忽略被分析样本中的库函数从而降低误报并提升运行性能。你将了解到这些签名的来源与生成方式pcf、sigmake、它们与 IDA Pro 自带签名集的区别、在 capa 源码中的加载与匹配链路以及如何通过-s/--signatures参数使用或替换这些签名。一、为什么要为库函数准备签名capa 的核心能力是从可执行文件中提取特征并匹配规则从而识别恶意软件的能力capabilities。但在真实样本中绝大多数代码并不是恶意作者编写的它们来自 MSVC 运行库、ATL/MFC 框架、各类常见第三方库等编译器与框架的通用代码。这些库函数如果被当作能力参与规则匹配会带来两个问题误报增多恶意行为规则可能恰好命中某些库函数的特征把正常的库代码误判为恶意能力运行变慢引擎需要对库函数内部也做特征提取与规则匹配白费计算资源。为此capa 引入了库函数识别机制先识别出二进制中的库函数再在匹配时忽略它们。而识别手段正是 FLIRTFast Library Identification and Recognition Technology签名。正如 sigs/README.md 所述This directory contains FLIRT signatures that capa uses to identify library functions. Typically, capa will ignore library functions, which reduces false positives and improves runtime.二、sigs/ 目录里有什么当前仓库的sigs/目录下包含三个签名文件按文件名顺序组织覆盖不同的库来源文件覆盖范围依命名推断1_flare_msvc_rtf_32_64.sigMSVC 运行库RunTime Function的 32/64 位签名2_flare_msvc_atlmfc_32_64.sigMSVC 的 ATL/MFC 框架的 32/64 位签名3_flare_common_libs.sig常见库common libraries签名文件名的数字前缀并非随意如后文所述capa 会按文件名的字母顺序加载签名因此1_、2_、3_前缀保证了稳定的加载次序也方便维护者后续追加新签名。三、签名的来源FLAIR 工具链与独立生成FLIRT 签名本身是 Hex-Rays 生态中广泛使用的格式但 sigs/README.md 明确强调了一个关键事实These FLIRT signatures were generated by Mandiant using the Hex-Rays FLAIR tools such aspcfandsigmake. Mandiant generated the signatures from source data that they collected; these signatures are not derived from the FLIRT signatures distributed with IDA Pro.这包含两层含义生成工具是 FLAIRFLAIRFile Analysis and Inspection Resources是 Hex-Rays 随 IDA Pro 分发的一组工具其中pcf用于从目标二进制中创建 pattern 文件.patsigmake则负责把.pat文件合并、去重、处理冲突后生成最终的.sig签名文件。也就是说本仓库的签名链路是收集库的源数据 → 编译/获取目标二进制 →pcf提取函数模式 →sigmake汇总成.sig。数据来源是 Mandiant 自建这些签名并非从 IDA Pro 自带的 FLIRT 签名集如vc32rtf.sig、mfc42.sig等派生而来而是 Mandiant 依据自行收集的源数据独立生成的。因此在许可与内容上都与 IDA Pro 分发版解耦可以随 capa 一并开源分发。四、签名如何在 capa 中被加载源码调用链capa 对签名的使用有完整的一条链路全部集中在 capa/main.py 与 capa/loader.py 中。4.1 CLI 参数入口-s/--signatures在 capa/main.py 中通用参数注册函数install_common_args定义了签名参数if signatures in wanted: parser.add_argument( -s, --signatures, typestr, defaultSIGNATURES_PATH_DEFAULT_STRING, helppath to .sig/.pat file or directory used to identify library functions, use embedded signatures by default, )关键点短选项为-s长选项为--signatures既支持指向单个.sig/.pat文件也支持指向一个目录默认值为SIGNATURES_PATH_DEFAULT_STRING在 capa/main.py 中定义为字符串(embedded signatures)表示默认使用内嵌签名即仓库/发行包自带的sigs/目录用户无需任何配置即可获得库函数识别能力。4.2 默认签名路径的计算get_default_signatures()capa/main.py负责计算默认签名的文件路径它基于 capa 的安装根目录源码树或 PyInstaller 打包目录定位sigs/目录然后递归收集扩展名为.pat、.pat.gz、.sig的文件。这与sigs/目录下实际存放.sig文件的事实一致。当用户显式传入-s时capa/main.py 会据此设置args.signatures与args.is_default_signatures区分使用默认内嵌签名与用户自定义签名两种模式。4.3 签名文件的枚举与排序真正的文件收集逻辑位于 capa/loader.py 的get_signatures()def get_signatures(sigs_path: Path) - list[Path]: if not sigs_path.exists(): raise IOError(fsignatures path {sigs_path} does not exist or cannot be accessed) paths: list[Path] [] if sigs_path.is_file(): paths.append(sigs_path) elif sigs_path.is_dir(): logger.debug(reading signatures from directory %s, sigs_path.resolve()) for file in sigs_path.rglob(*): if file.is_file() and file.suffix.lower() in (.pat, .pat.gz, .sig): paths.append(file) paths [path.resolve().absolute() for path in paths] # load signatures in deterministic order: the alphabetic sorting of filename. # this means that 0_sigs.pat loads before 1_sigs.pat. paths sorted(paths, keylambda path: path.name) ...从这段实现可以总结出三个可复用的行为约定入参既可以是文件也可以是目录指向文件时直接使用指向目录时用rglob(*)递归搜索只保留.pat、.pat.gz、.sig三种后缀的文件大小写不敏感路径会被绝对化所有签名路径会经过resolve().absolute()归一化加载顺序是确定性的按文件名字母序排序加载所以1_flare_msvc_rtf_32_64.sig一定先于2_flare_msvc_atlmfc_32_64.sig被注册。若你自定义签名目录也应遵循用数字前缀控制优先级的命名习惯。4.4 签名注入 vivisect 分析流水线签名被枚举后最终在get_workspace()capa/loader.py中生效。该函数先以analyzeFalse的方式创建 vivisect workspace目的是抢在完整分析之前挂载签名分析器# lazy import enables us to not require viv if user wants another backend. import envi.exc import viv_utils import viv_utils.flirt ... # dont analyze, so that we can add our Flirt function analyzer first. vw viv_utils.getWorkspace(str(path), analyzeFalse, should_saveFalse) ... viv_utils.flirt.register_flirt_signature_analyzers(vw, [str(s) for s in sigpaths]) ... vw.analyze()也就是说capa 依赖viv_utils.flirt.register_flirt_signature_analyzers来自 vivisect 生态把签名注册为 vivisect 的函数分析器随后再执行完整的vw.analyze()从而在反汇编阶段就完成库函数的标记。此后被标记的库函数便从规则匹配中排除。4.5 适用前提仅 vivisect 后端 PE 文件签名匹配并非在所有场景下都启用。capa/main.py 的get_signatures_from_cli()做了两个前置判断def get_signatures_from_cli(args, input_format: str, backend: str) - list[Path]: if backend ! BACKEND_VIV: logger.debug(skipping library code matching: only supported by the vivisect backend) return [] if input_format ! FORMAT_PE: logger.debug(skipping library code matching: signatures only supports PE files) return [] ...因此有两个明确限制只有 vivisect 后端才会进行库函数匹配只有 PE 格式输入才支持签名识别ELF、shellcode 等格式会自动跳过。此外若默认内嵌签名路径缺失capa 会输出错误并提示先安装签名参见 capa/main.py。五、如何在实战中传入自定义签名尽管默认开箱即用但当你通过pip install flare-capa以库方式安装时默认签名并不会随包附带详见 doc/installation.md。此时需要显式指定签名目录$ capa -s /path/to/capa-sigs suspicious.exe也可以同时指定规则与签名$ capa -r capa-rules-v9.4.0/ -s /path/to/capa-sigs suspicious.exe参数含义对照参数说明-s, --signatures指定.sig/.pat文件或目录用于识别库函数默认使用内嵌签名-r, --rules指定规则文件或目录对应 capa/main.py 的规则参数若传入的路径不存在或不可访问get_signatures()会抛出IOErrorsignatures path ... does not exist or cannot be accessed并在 CLI 层以错误码退出对应E_INVALID_SIG。因此自定义签名时请务必确认路径有效、目录内文件为.sig/.pat/.pat.gz格式。六、许可与再分发注意事项sigs/README.md 最后一条关键信息关乎合规The signatures in this directory have the same license as capa: Apache 2.0.即sigs/目录下的签名文件与 capa 本身采用相同的Apache 2.0许可。这与签名非派生自 IDA Pro 分发签名的事实相辅相成——正是由于 Mandiant 独立生成签名capa 才能以 Apache 2.0 自由再分发。若你需要将 capa 的签名集成到自己的工具链中可以放心遵循 Apache 2.0 的条款保留许可声明、注明修改等。七、延伸阅读签名生成脚本生态仓库提供 scripts/match-function-id.py可用于函数级匹配验证安装与签名路径说明doc/installation.mdMethod 2 的Note on capa rules and library identification signatures一节签名加载的完整实现capa/loader.py枚举与排序、capa/loader.py注入 vivisectCLI 参数与默认签名逻辑capa/main.py、capa/main.py、capa/main.py。小结capa/sigs/是 capa 库函数识别能力的基石它以 Mandiant 用 FLAIR 工具链pcfsigmake独立生成的 FLIRT 签名为载体在 vivisect 后端的 PE 分析流程中标记并忽略库函数最终换来更低的误报与更快的运行速度。理解这条从签名生成、目录组织、确定性加载到 vivisect 注册的完整链路不仅能让你正确使用-s/--signatures参数也能帮助你为特定样本集定制属于自己的库函数签名集。【免费下载链接】capaThe FLARE teams open-source tool to identify capabilities in executable files.项目地址: https://gitcode.com/GitHub_Trending/ca/capa创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考