CLI网络安全【免费下载链接】Ciphey⚡ Automatically decrypt encryptions without knowing the key or cipher, decode encodings, and crack hashes ⚡项目地址https://gitcode.com/gh_mirrors/ci/Ciphey点击查看免费下载本文以 Ciphey 仓库中的实现计划文档 docs/wait_athena.md 为主体结合 src/checkers/wait_athena.rs、src/storage/wait_athena_storage.rs、src/timer/mod.rs 等源码实现完整讲解 WaitAthena Checker 的设计动机、架构分工、核心数据结构与完整落地路径。读完本文你将理解 Ciphey 默认 Athena Checker 与 WaitAthena Checker 的行为差异掌握--top-results参数背后的全局存储、计时器联动与 A* 搜索集成机制并能在自己的编码破解场景中准确判断何时使用这一多结果收集模式。WaitAthena 是什么从找到即停到收集到超时Ciphey 的默认检查器是 Athena Checker见 src/checkers/athena.rs。它按顺序运行 LemmeKnow、密码、英语等子检查器一旦某个检查器判定当前文本是明文就立即返回并结束搜索。这种找到第一个合法明文就退出的策略对绝大多数密文是高效的但对歧义性编码ambiguous encodings不够友好——同一段密文可能存在多种合理解读例如多层编码、大小写不敏感文本、可被多种解码路径命中的字符串等用户往往希望看到全部可能性。WaitAthena Checker 正是为这一场景设计的变体。它在 docs/wait_athena.md 中被定义为athena.rs的精确克隆仅有三处关键差异结果收集而非立即返回把每次找到的明文存入一个全局列表而不是立刻结束程序计时器到期统一展示程序计时器timeout归零时一次性展示已收集到的全部明文计时器模块联动需要修改 timer 模块使其在倒计时结束时调用打印明文列表的函数。对应到实际代码src/checkers/wait_athena.rs 的文件头注释准确描述了这一定位WaitAthena checker is a variant of Athena that collects all plaintexts found during the search. While Athena exits immediately when a plaintext is found, WaitAthena continues checking and stores all plaintexts it finds until the timer expires.变更记录 docs/changes/2024-07-10-wait-athena-checker.md 进一步总结了该特性的权衡优点一次性提供多个潜在明文便于歧义密文的全方位分析与所有既有解码器/检查器保持兼容通过单一 CLI 参数--top-results启用自动禁用人类检查器避免打断搜索持续搜索直到计时器到期最大化候选明文数量。缺点即使已经找到合法明文也会继续搜索耗时会变长可能同时返回误报与真实明文所有结果需在计时器到期前常驻内存内存占用上升。八个关键设计澄清原文档记录了与项目维护者的讨论结论这些澄清约束了整套实现且均已在实际代码中落地#决策点结论1搜索器Searcher集成无需修改src/searchers/mod.rs 的搜索逻辑仅需新增 CLI 参数--top-results来决定使用标准 Athena 还是 WaitAthena。从当前源码看后续进一步将收集逻辑下沉到了 src/searchers/astar.rs见后文与 A* 搜索的深度集成2人类检查器交互WaitAthena 流程不涉及人类检查器自动接受所有潜在明文不逐条询问用户3去重逻辑不实现去重实际中重复明文极不可能出现4依赖要求lazy_static已是项目既有依赖无需新增任何依赖5性能考量无需对 WaitAthena 做特殊限流或优先级处理6与既有解码器兼容所有既有解码器只要实现checker_typetrait、遵循标准检查器模式即可正常工作7错误处理文档原计划对 mutex 中毒poisoning等存储错误直接panic实际实现改为恢复poisoned.into_inner()并记录警告日志见 src/storage/wait_athena_storage.rs8结果排序初始实现按发现顺序展示、不排序排序作为未来改进项核心数据结构线程安全的全局明文存储WaitAthena 的跨线程工作方式决定了需要一块检查器可写入、计时器可读取的共享存储。文档给出的方案是lazy_staticMutex实际实现位于 src/storage/wait_athena_storage.rs并在文档设计的基础上增加了decoder_name字段使每个结果都能追溯到产生它的解码器与检查器#[derive(Debug, Clone)] pub struct PlaintextResult { /// The plaintext text pub text: String, /// The description of the result pub description: String, /// The name of the checker used to generate the result pub checker_name: String, /// The name of the decoder used to generate the result pub decoder_name: String, } lazy_static! { static ref PLAINTEXT_RESULTS: MutexVecPlaintextResult Mutex::new(Vec::new()); }围绕这一静态容器模块暴露了三个核心函数add_plaintext_result(text, description, checker_name, decoder_name)构造PlaintextResult并压入全局 Vec写入前通过trace!记录来源检查器、文本与解码器写入后记录当前结果总数便于排查问题get_plaintext_results() - VecPlaintextResult克隆并返回全部结果供计时器到期后的展示逻辑使用clear_plaintext_results()清空结果供每次新的破解会话开始时调用避免上次运行的结果污染本次输出。值得一提的错误处理差异文档设计稿中对锁失败直接.unwrap()触发 panic实际代码则对Mutex::lock()的结果做了match处理遇到 poisoned 状态时调用poisoned.into_inner()恢复访问并输出warn!(Mutex was poisoned, recovering)。从源码结构看这是为 long-running 的搜索循环提供更强的健壮性——单一线程 panic 后其余线程仍能继续写入结果。模块注册位于 src/storage/mod.rs 中的pub mod wait_athena_storage;。WaitAthena Checker 的实现与 Athena 的对照src/checkers/wait_athena.rs 实现了CheckerWaitAthena的Checktrait。先看它的元信息pub struct WaitAthena; impl Check for CheckerWaitAthena { fn new() - Self { Checker { name: WaitAthena Checker, description: Runs all available checkers and stores results until timer expires, link: , tags: vec![wait_athena, all], expected_runtime: 1.0, popularity: 1.0, lemmeknow_config: Identifier::default(), sensitivity: Sensitivity::Medium, // Default to Medium sensitivity enhanced_detector: None, _phantom: std::marker::PhantomData, } } // ... }与 Athena 的对照src/checkers/athena.rs可看出expected_runtime从 Athena 的0.01调整为1.0语义上承认该检查器要一直运行到计时器到期两者默认敏感度都是Sensitivity::Medium都实现了with_sensitivity/get_sensitivity。在check()方法内执行顺序与原文档一致且新增了 Wordlist 检查器的分支对应 docs/changes/2024-07-01-wordlist-checker.md 引入的能力Regex 模式若配置了config.regex只运行RegexChecker这与 Athena 一致——用户用 regex 说明在找特定信息其余检查器全部关闭。识别命中后不经过人类检查器直接把text、description、checker_name、RegexChecker存入全局存储Wordlist 模式若配置了config.wordlist先运行WordlistChecker命中后存储结果LemmeKnow检测已知数据格式IP、邮箱、哈希等命中后存储PasswordChecker检测常见口令命中后存储EnglishChecker检测是否英文文本命中后存储。每个子分支的关键差异都在注释中标注// Store the result instead of returning immediately以及// No human checker involvement。也就是说WaitAthena 对每个候选明文都自动接受check_res.is_identified true并写入存储随后return check_res让上层流程继续推进——这保证了 A* 搜索能在top_results模式下继续扩展节点而不是像 Athena 那样因为人类检查器确认后立刻终止。模块注册位于 src/checkers/mod.rspub mod wait_athena;同时CheckerTypes枚举新增了CheckWaitAthena(CheckerWaitAthena)变体并在check、with_sensitivity、get_sensitivity三个方法中补齐了对应分支全局检查器注册表CHECKER_MAP也加入了(WaitAthena Checker, CheckerBox::new(Checker::WaitAthena::new()))这意味着 WaitAthena 可以作为普通检查器被搜索算法按名称调度。计时器改造到期后展示全部结果src/timer/mod.rs 承担了倒计时到期 → 展示结果的职责。start(duration)启动一个后台线程每秒推进time_spent并调用countdown_until_program_ends来自 src/cli_pretty_printing/mod.rs每 5 秒打印一次剩余时间。倒计时归零后let config get_config(); log::trace!(Timer expired. top_results mode: {}, config.top_results); if config.top_results { log::info!(Displaying all collected plaintext results); filter_and_display_results(); } else { log::info!(Not in top_results mode, skipping display_wait_athena_results()); }filter_and_display_results从wait_athena_storage::get_plaintext_results()取回全部结果委托给 CLI 美化模块的display_top_results(results)。与文档设计稿相比实际实现有两处健壮性调整文档中sender.send(()).expect(...)实际改为match记录warn!日志——注释说明这在 benchmark 场景下是预期行为结果展示从 timer 模块内联打印收敛到 src/cli_pretty_printing/mod.rs 的display_top_results保持所有 CLI 输出统一经由 pretty-printing 模块的架构约定。结果展示的实战细节display_top_resultssrc/cli_pretty_printing/mod.rs定义了完整的用户交互流程结果为空时输出No potential plaintexts found.非空时以 List of Possible Plaintexts 开头并输出结果总数超过 10 个结果时程序会以警告提示结果太多建议写入文件并询问Would you like to write to a file? (y/N)。若用户选择写入每个结果按Result #i、Decoder、Checker、Description四行组织默认文件名是$HOME/ciphey_text.txt若未选择写入或结果 ≤10则在终端逐条打印Result #i、Decoder、Checker、Description结果之间以---分隔最后输出 End of Top Results 。另外普通模式下的成功输出函数program_exiting_successful_decoding在top_results开启时会提前返回if config.top_results { return; }避免与计时器到期的汇总展示产生双重输出。配置项与 CLI如何开启 WaitAthena 模式Config 结构体新增top_results字段src/config/mod.rs 的Config结构体新增字段/// Whether to collect all plaintexts until timeout expires /// instead of exiting after finding the first valid plaintext pub top_results: bool,默认值为false即默认行为与过去完全一致找到第一个明文即退出。top_results也是 TOML 配置白名单中的合法键之一parse_toml_with_unknown_keys的known_keys数组包含top_results因此用户既可以通过命令行参数启用也可以在~/.ciphey/config.toml中持久化配置。CLI 参数src/cli/mod.rs 使用 clap 声明参数/// Show all potential plaintexts found instead of exiting after the first one /// Automatically disables the human checker #[arg(long)] top_results: bool,在cli_args_into_config_struct中// Set top_results mode if the flag is present config.top_results opts.top_results; // If top_results is enabled, automatically disable the human checker if config.top_results { config.human_checker_on false; }注意自动禁用人类检查器这一副作用既然要一口气收集全部候选明文自然不能再逐条弹出y/N询问这与设计澄清 #2 完全一致。实际命令形如ciphey -t SGVsbG8gV29ybGQh --top-results ciphey -t 密文 --top-results --cracking-timeout 10--cracking-timeout默认 5 秒决定了 WaitAthena 的收集窗口时间越长搜索树展开越充分、候选明文越多但内存与耗时也随之上升。首次运行向导 src/cli/first_run.rs 也会询问用户偏好找到第一个就停还是收集全部可能明文并将选择写入top_results配置键若用户选择了收集模式向导还会提示该模式下建议将 timeout 设置为 3 秒左右避免过高的倒计时导致机器卡顿。库接口集成perform_cracking的分流逻辑src/lib.rs 的perform_cracking是库级入口。它在top_results模式下做了三件事强制关闭人类检查器并清空上次遗留的结果let mut modified_config config; if modified_config.top_results { modified_config.human_checker_on false; // Clear any previous results when starting a new cracking session storage::wait_athena_storage::clear_plaintext_results(); } config::set_global_config(modified_config);输入文本的初始明文预检改用 WaitAthena。check_if_input_text_is_plaintext按配置分流if config.top_results { let wait_athena_checker Checker::WaitAthena::new(); wait_athena_checker.check(text) } else { let athena_checker Checker::Athena::new(); athena_checker.check(text) }这对应设计步骤 #8程序启动时先判断输入是否本身就是明文以节省 CPU 周期在收集模式下这一预检同样会把命中结果写入全局存储。继续执行 A搜索*由搜索器负责在收集模式下持续探索见下节。与 A* 搜索的深度集成源码现状设计文档在回顾性实现洞察Retrospective Implementation Insights一节中明确指出如果重新实现该特性应让 A搜索在top_results模式下即使找到合法明文也继续搜索*而不是依赖检查器侧存储结果——这样可以消除单独的全局存储机制让特性与核心搜索算法融为一体。从当前仓库源码看这一方向已经落地src/searchers/astar.rs 中当某节点被判定为成功结果时若get_config().top_results为真会把node.state.text的第一个明文、解码路径中最后一个解码器名称、检查器名称一起写入wait_athena_storage::add_plaintext_result(...)描述格式为Decoded successfully at depth {当前深度}随后只有在非top_results模式时才stop.store(true)并退出循环在top_results模式下搜索继续展开直到计时器到期触发展示。这意味着实际的 WaitAthena 收集路径有两条初始明文预检check_if_input_text_is_plaintext与 A* 搜索中的成功节点。两条路径共用同一存储最终由计时器统一汇总展示。测试策略与设计权衡原文档的测试计划分三层WaitAthena 检查器单元测试已实现于 src/checkers/wait_athena.rs 的#[cfg(test)]模块共 4 个用例test_check_english_sentence英文句子test valid english sentence应被识别test_check_dictionary_word单词exuberant应被识别源码中将文档示例的and换成了更具区分度的词test_default_sensitivity_is_medium默认敏感度为Sensitivity::Mediumtest_with_sensitivity_changes_sensitivitywith_sensitivity能正确切换到Low/High。集成测试验证 WaitAthena 能收集多个明文。可从 tests/integration_test.rs 与 src/lib.rs 的perform_cracking测试了解端到端调用的基准行为。手工测试用不同密文验证所有明文均被收集。实现中值得注意的工程取舍线程安全MutexVecPlaintextResult是全局唯一存储检查器线程与计时器线程都通过它交换数据poisoned 恢复策略取代了文档初版的 panic 方案提升长时搜索的健壮性错误处理除存储锁恢复外timer 的send失败也只记录日志不再 panic注释明确说明这在 benchmark 中是预期行为相关基准见 benches/benchmark_whole_program.rs用户体验超过 10 条结果时主动引导写入文件防止终端刷屏每条结果附带 Decoder / Checker / Description便于用户判断各候选明文的可信来源无去重按设计澄清 #3 不做去重接受极低概率的重复可能。潜在挑战线程安全存储机制必须保证多线程并发写入/读取安全——由Mutex保证所有访问点集中在 src/storage/wait_athena_storage.rs错误处理设计初版对 mutex 中毒与意外错误直接 panic实际代码已改为记录日志并恢复兼顾可诊断性与可用性用户体验输出必须清晰、有助益——包括结果总数、编号、来源解码器/检查器、描述以及超量时的落盘引导。未来改进方向原文档给出了明确的演进路线其中部分已在源码中实现与 A搜索更深集成*让搜索算法在top_results模式下持续搜索——已在 src/searchers/astar.rs 落地结果打分与排序按置信度对结果排序可结合明文熵、检查器置信分数、到达明文的解码器数量、是否含字典词/合法语法等指标从 src/searchers/astar.rs 的启发式函数generate_heuristic/calculate_string_worth看此类信号在项目内已存在去重策略若实践中重复明文成为问题可按规范化版本忽略大小写、归一化空白去重可配置结果上限防止超大结果集造成内存问题搜索过程进度反馈计时器到期前周期性提示已收集候选数结果分类按识别它们的检查器类型英文文本 / 口令 / 特定格式分组展示并行检查器执行既然不再命中即退可并行运行多个检查器加速内存优化尽量存储引用、按需拷贝置信度阈值可配置过滤低置信结果减少输出噪声导出功能把全部候选明文导出到文件便于对歧义/复杂编码做后续分析结果超过 10 条时的落盘引导已部分覆盖此能力。结语WaitAthena Checker 是 Ciphey 在效率优先与完整性优先之间提供的一个可切换选项默认 Athena 找到第一个合法明文即退出--top-results模式则把搜索窗口拉满到计时器到期借助Mutex保护的全局存储汇总全部候选明文并在倒计时归零时由 timer 模块统一展示。从 docs/wait_athena.md 的实现计划到 src/checkers/wait_athena.rs、src/storage/wait_athena_storage.rs、src/timer/mod.rs、src/searchers/astar.rs 的落地代码可以看到设计文档中的回顾性洞察让搜索算法而非检查器承担收集职责已经转化为实际架构。对使用者而言这条特性的价值在于面对歧义密文、多层编码或不确定的破解路径时ciphey -t 密文 --top-results能一次给出全部可能性再结合 Decoder / Checker / Description 逐条甄别让自动破解变成可解释的多解分析。赞分享CLI网络安全【免费下载链接】Ciphey⚡ Automatically decrypt encryptions without knowing the key or cipher, decode encodings, and crack hashes ⚡项目地址https://gitcode.com/gh_mirrors/ci/Ciphey点击查看免费下载相关推荐Ciphey WaitAthena Checker 与 --top-results 模式多明文收集机制的原理与使用指南Ciphey WaitAthena Checker 与 top results 模式多明文收集机制的原理与使用指南 导读 Ciphey 在默认模式下采用 AtCLI网络安全Ciphey 存储模块深度解析SQLite 缓存、WaitAthena 结果与静态数据资源的统一管理Ciphey 存储模块深度解析SQLite 缓存、WaitAthena 结果与静态数据资源的统一管理 本篇技术指南以 Ciphey 的 src/storageCLI网络安全Ultralytics Results 结果类深度解析engine.results 中 Boxes、Masks、Keypoints、Probs、OBB 与 Results 的完整使用指南Ultralytics Results 结果类深度解析engine.results 中 Boxes、Masks、Keypoints、Probs、OBB 与 R人工智能计算机视觉深度学习机器学习预训练上一篇ImageNet-1k冠军模型fbnetv3_g.ra2_in1k参数、性能与部署指南下一篇HOMER开发者指南如何扩展自定义协议和数据源创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考