TruffleHog 的 --max-decode-depth 怎么选？基于基准数据选择解码深度

TruffleHog 的 --max-decode-depth 怎么选基于基准数据选择解码深度【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehog当你用 TruffleHog 扫描仓库、文件系统或其他来源时凭证可能不只以明文出现base64 里套着 base64、UTF-16 里套着 base64 这类嵌套编码需要多轮解码才能还原。--max-decode-depth控制这个迭代解码的最大层数默认值是 5。这篇文章基于项目内的基准数据文档 docs/iterative_decoding_performance.md说明这个参数如何工作、不同深度带来什么成本以及如何为自己的扫描目标确定合适的深度。这个参数做什么参数定义在 main.go 中帮助文本写明Maximum depth of iterative decoding. Each decoders output is fed back through all decoders, up to this limit. 1 single pass, 2 chained decoding (e.g., base64 inside utf16).即每个解码器的输出会重新送进全部解码器最多迭代到指定深度。1是单次通过等价于引入该特性之前的行为2开启链式解码。docs/man/trufflehog.1 中列出的默认值为--max-decode-depth5。几个影响性能的关键机制来源为基准数据文档的 How it works 一节深度 0第一次通过时所有解码器都作用于原始 chunk与旧版行为一致。只有解码器真正产出了新数据才会进入下一层没有任何解码器产出新数据时循环提前退出所以没用到的深度层实际上免费。PLAINUTF-8解码器在 depth 0 时被跳过因为它是透传解码器其他解码器的输出已经是合法 UTF-8/ASCII。引擎里用一份seen列表防止重复处理相同数据见 pkg/engine/engine.go 的 iterativeDecode。传入小于 1 的值会被引擎初始化时修正为 1见 pkg/engine/engine.go。默认的解码器集合包括 UTF8、Base64、UTF16、EscapedUnicode、HTML见 pkg/decoders/decoders.go链式解码就是在这几个解码器之间反复迭代。基准数据扫描 trufflehog 仓库的结果文档中的基准条件是扫描 trufflehog 仓库约 4,500 个文件使用--no-verification和--concurrency1以便得到可对比的确定性结果。下表为文档记录的基准输出不是任何机器上必须得到的固定数值DepthWall timeUnique resultsDelta vs depth118.05s924—28.18s9273, 1.6%38.09s9284, 0.5%58.19s9284, 1.7%108.35s9328, 3.7%从这份数据可以读出文档给出的两个结论结果在 depth 3 时收敛。depth 4–5 在该语料上没有产生任何额外解码数据多出来的深度层对每个 chunk 只增加一次len() 0检查。depth 10 的少量差异不是解码造成的。文档明确说明depth 10 时 unique results 的小幅波动来自并发检测器 worker 去重顺序的既有非确定性而不是解码本身。深度带来的开销基准数据文档还给出两项成本说明内存开销。每有一个深度层产出新解码数据就存储一份输出副本通常比输入小因为 base64 解码体积缩小约 25%。防止重复处理的seen列表是一个字节切片数组depth 5 时典型 chunk 的该列表只有 0–3 个条目实现上不用哈希或 map。单解码器开销。该特性没有修改任何解码器单个解码器成本不变。文档以 base64 解码器处理随机数据为例文档示例数据Input sizeLatency/opAllocs100 B~250 ns96 B / 21 KB~2.25 µs96 B / 210 KB~44 ns96 B / 2其中 10 KB 一行反而很快文档的解释是随机字节很少能凑出合法 base64 子串未满足 20 字符的最低阈值解码器只需一次 O(n) 字符扫描就退出。文档给出的深度选择依据基准数据文档的 Choosing a depth 一节直接给出了对应关系DepthUse case1Legacy behavior, no chaining2Covers base64-in-base64, base64-in-UTF-16, base64-in-escaped-unicode5Default. Handles deeply nested configs with no measurable cost over depth 2按这张表落到操作上保持默认5默认值就是 5适合需要处理深层嵌套配置的场景。文档的结论是它在实测中相对 depth 2 没有可测量的额外成本。选 2你的目标里只需要覆盖常见的一层嵌套base64 套 base64、base64 套 UTF-16、base64 套 escaped-unicode时2 已足够基准数据也表明 depth 2 之后结果基本不再增长。选 1只要保持与引入该特性之前完全一致的单次通过行为时使用即不做任何链式解码。在自己的扫描目标上验证收敛文档基准用的是特定语料trufflehog 仓库换成你自己的目标后建议按同一方法验证固定--no-verification与--concurrency1文档用这两个参数保证比较的确定性在不同深度下分别跑同一目标对比 wall time 与 unique results。把下面的扫描目录替换为你实际要扫描的目录或文件路径# 基线单次通过 trufflehog filesystem 扫描目录 --no-verification --concurrency1 --max-decode-depth1 # 逐步加深 trufflehog filesystem 扫描目录 --no-verification --concurrency1 --max-decode-depth2 trufflehog filesystem 扫描目录 --no-verification --concurrency1 --max-decode-depth5判断方式沿用文档基准的做法当继续增大深度后 unique results 不再增长、耗时也没有可感知变化时说明当前语料上的解码已经收敛文档基准在 depth 3 收敛再往上调深度对该目标没有收益。注意文档的结论是针对其扫描语料得出的你的语料如果确实存在更深的嵌套编码收敛点可能不同以你自己多组深度下结果对比为准。限制与参考基准数字来自文档记录的特定扫描约 4,500 个文件的 trufflehog 仓库、--concurrency1只用于说明量级和收敛趋势不要当作固定预期。提高--concurrency后 wall time 受 worker 非确定性影响更大做深度对比时应像文档一样先固定并发。深度值下限为 1小于 1 的输入会被引擎修正为 1pkg/engine/engine.go。完整机制说明与数据出处docs/iterative_decoding_performance.md参数定义见 main.goman page 见 docs/man/trufflehog.1。【免费下载链接】trufflehogFind, verify, and analyze leaked credentials项目地址: https://gitcode.com/GitHub_Trending/tr/trufflehog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考